社内文書をRAGへ入れたのに、『この半年で複数部門に共通して増えた顧客課題は何か』と聞くと、検索された数件の要約しか返ってこない。固有名詞を尋ねる質問には強いのに、文書を横断して関係や全体像をつかむ質問では答えが薄い。この違和感がGraphRAGを検討する入口です。
結論から言えば、GraphRAGは文書から人物・組織・製品・概念などのエンティティ（Entity）と、それらの関係（Relationship）を抽出してグラフ（Graph）にし、検索結果をLLMへ渡すRAGの一方式です。あらゆるRAGを置き換える万能技術ではありません。単純な事実検索なら通常のベクトルRAGが安く速いことが多く、関係の探索や文書集合（Corpus）全体のテーマ把握でグラフの価値が出ます。
最初に結論
GraphRAGとは、文書のチャンク（Chunk）を似ている順に探すだけでなく、文書から抽出したエンティティ・関係・コミュニティ（Community）などのグラフ構造を使って関連情報を検索し、LLMの回答根拠を組み立てる方法です。複数文書に散らばった関係や全体傾向の質問に向く一方、事前の抽出・要約・更新に費用がかかるため、通常のRAGで解けない重要質問に限定して比較検証します。
この記事のポイント
- ・通常のRAGは似た文章の取得が得意で、GraphRAGはエンティティ間の関係と全体構造を使える
- ・検索前にエンティティ・関係・コミュニティレポート（Community Report）を作るインデックス作成（Indexing）が必要になる
- ・Local Search、Global Search、DRIFT Searchは質問の粒度で使い分ける
- ・グラフを作ることを目的にせず、代表質問の正答・根拠・費用・更新時間で通常RAGと比較する
対象：社内文書検索やAI分析で、文書をまたぐ関係・全体傾向を答えにくいと感じているAI・データ活用の担当者
普通のRAGで全体像を答えにくい理由
一般的なRAGは文書を小さなチャンクへ分け、それぞれを埋め込み（Embedding）に変換し、質問と意味が近いチャンクを上位から取得します。『返品規約の期限は何日か』のように答えが一か所にあり、質問と本文の言葉が近い場合に有効です。
一方、『どの製品問題が複数地域の解約につながったか』という問いでは、製品名、障害、地域、顧客反応が別々の文書に登場します。一つひとつのチャンクは質問全体と似ていないため、必要な断片が検索上位へ集まらないことがあります。検索件数を増やすだけではノイズ（Noise）とコンテキスト（Context）の量も増え、関係を組み立てる負担がLLMへ移ります。
GraphRAGは、文書間にまたがるエンティティと関係をあらかじめ構造化し、関連する断片を接続した状態で取り出そうとします。ここでいうグラフは、必ずしも人手で完成させた企業オントロジーではなく、対象文書からLLMなどで抽出したグラフも含みます。
RAGとGraphRAGの違い
両者は排他的ではありません。Microsoft GraphRAGの実装でもテキストユニット（Text Unit）の埋め込みを利用し、グラフ情報とベクトル検索を組み合わせます。GraphRAGという名前だけで方式を判断せず、どの情報をグラフ化し、質問時に何を検索する設計かを確認してください。
| 観点 | 一般的なベクトルRAG | GraphRAG |
|---|---|---|
| 主なインデックス | チャンクと埋め込み | エンティティ、関係、コミュニティ、テキストユニットなど |
| 得意な問い | 特定箇所の事実・説明 | 関係探索、複数文書の統合、全体テーマ |
| 前処理 | 分割と埋め込みが中心 | 抽出、重複統合、コミュニティ生成、要約が加わる |
| 更新 | 変更したチャンクだけを再索引しやすい | グラフと要約への影響を考慮する |
| 費用・複雑さ | 比較的小さい | インデックス作成と運用が増える |
| 主な失敗 | 必要なチャンクを取得できない | 誤抽出・誤接続がグラフ全体へ影響する |
GraphRAGのインデックス作成はどう進むか
代表的な流れを理解すると、なぜ通常のRAGより準備が重いかが分かります。実装によって名称や順序は異なりますが、Microsoft GraphRAGでは文書をテキストユニットへ分割し、エンティティ、関係、主張（Claim）などを抽出し、グラフのコミュニティを階層的に検出してレポートを作ります。元のテキストユニットや説明の埋め込みも保持します。
- 1. 文書を分割する：出典と位置を失わないようにテキストユニットへ分けます。小さ過ぎれば関係の文脈が消え、大き過ぎれば抽出費用が増えます。
- 2. エンティティと関係を抽出する：人物、組織、製品、論点などと、それらがどう関係するかをLLMまたはルールで抽出します。
- 3. 重複と表記揺れを整理する：同じ対象を別名として分断したり、別対象を同一エンティティにまとめたりしないよう正規化します。
- 4. コミュニティと要約を作る：密接につながるエンティティ群を階層化し、各まとまりの主要テーマをレポートとして要約します。
- 5. 検索用インデックスと出典を保存する：グラフ、テキスト、埋め込み、元文書への参照を結び、回答から根拠へ戻れるようにします。
質問によって検索方式を選ぶ
Microsoft GraphRAGには複数の検索方式があります。これらはGraphRAG全般に必須の共通規格ではなく、同プロジェクトが提供する方法です。しかし、質問の範囲に合わせて検索戦略を変えるという考え方は、他の実装を比較するときにも役立ちます。
| 方式 | 向いている問い | 使う情報のイメージ |
|---|---|---|
| Local Search | ある人物・製品の周辺関係は何か | エンティティから近隣の関係とテキストへ広げる |
| Global Search | 文書群全体の主要テーマは何か | コミュニティレポートを集約して全体像を作る |
| DRIFT Search | 局所から始めて関連テーマも探索したい | コミュニティ情報で候補を広げ、局所検索を反復する |
| Basic Search | 答えがある記述を直接探したい | テキストユニットのベクトル検索を中心に使う |
向いている用途と、別の方法がよい用途
向いているのは、調査報告書から関係者と出来事をつなぐ、顧客の声から製品・課題・業界の関係を探る、論文群から研究テーマのつながりと全体傾向をまとめる、といった用途です。答えに必要な情報が複数文書へ分散し、関係そのものが意味を持つことが条件です。
一方、最新売上の集計や在庫数を求めるなら、GraphRAGよりText-to-SQLとセマンティックレイヤーが適します。規程の一文を引用する検索なら、通常のRAGとメタデータフィルターで十分な場合があります。既に信頼できるナレッジグラフ（Knowledge Graph）があり、その事実を厳密に問い合わせたいなら、グラフデータベースへ直接問い合わせ、結果だけをLLMに説明させる方が明確なこともあります。
- 複数文書の人物・企業・出来事を関連付ける調査
- 大量の自由記述から横断テーマと例外を見つける分析
- 特定のエンティティを起点に周辺の根拠を探索する質問
- 文書集合全体を俯瞰し、階層別に要約する質問
通常RAGと比較するPoCの進め方
GraphRAGを選ぶ前に、通常RAGが苦手な代表質問を集めます。グラフを作った後で都合のよい質問を選ぶと、本当の改善か判断できません。正答だけでなく、引用した根拠が質問を支持するか、更新が反映されるまでの時間、インデックス作成と検索の費用も記録します。
- 1. 失敗する重要質問を集める：局所事実、関係探索、全体要約を分け、専門家が期待回答と必須根拠を用意します。
- 2. 小さな文書集合で二方式を作る：同じ文書・同じ回答モデルを使い、通常RAGとGraphRAGの検索部分を比較します。
- 3. 品質と費用を測る：正確性、根拠の十分性、検索時間、トークン、インデックス更新時間を質問種別ごとに確認します。
- 4. 適用範囲を限定する：改善が明確な質問だけグラフ経路へ送り、単純質問は安価な検索へ振り分けます。
コスト、更新、誤ったグラフに注意する
グラフの抽出とコミュニティレポート生成にはLLM呼び出しが増えます。文書の追加・削除時にどこまで再計算するかも設計が必要です。更新頻度が高い文書集合では、インデックス作成時点の要約が古くならないよう、増分更新の挙動と再構築条件を検証してください。
さらに、LLMが誤ったエンティティや関係を抽出すると、見た目には整ったグラフでも前提が間違います。重要な関係はスキーマや検証ルールを用い、回答では元文書の引用を残します。グラフ上の近さは因果関係の証明ではありません。『関連している』を『原因である』と説明させない評価も必要です。
MicrosoftのGraphRAG公式文書も、インデックス作成が高コストになり得ることと、まずプロンプト調整を行うことを案内しています。既定設定を本番の文書集合へそのまま実行するのではなく、少量で抽出品質と費用を確かめます。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- GraphRAG Overview — Microsoft Research（最終確認：2026-08-07）：GraphRAGの目的、インデックス作成、検索エンジン、費用上の注意を参照。
- GraphRAG Methods — Microsoft Research（最終確認：2026-08-07）：Local Search、Global Search、DRIFT Search、Basic Searchとインデックス作成の構成を参照。
- GraphRAG: Unlocking LLM discovery on narrative private data — Microsoft Research（最終確認：2026-08-07）：研究プロジェクトの背景、リポジトリ、関連研究を参照。
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization — arXiv（最終確認：2026-08-07）：エンティティグラフとコミュニティ要約を用いた、文書群全体に関する質問への手法と評価を参照。
よくある質問
GraphRAGはベクトルデータベースを使わないのですか？
必ずしもそうではありません。グラフ情報だけでなく、エンティティの説明やテキストユニットの埋め込みを検索に使う実装があります。グラフデータベースとベクトル検索のどちらか一方ではなく、質問に合わせて組み合わせます。
通常のRAGをすべてGraphRAGへ置き換えるべきですか？
置き換える必要はありません。単一文書の事実検索は通常RAGの方が簡潔で安い場合があります。関係探索や全体要約など、通常RAGで失敗する重要質問を特定して、その部分だけ比較します。
GraphRAGとナレッジグラフの違いは何ですか？
ナレッジグラフはエンティティと関係を構造化して表すデータモデルです。GraphRAGはそのグラフを含む情報を検索し、LLMの回答コンテキストに使う仕組みです。GraphRAGが文書から自動生成したグラフを使う場合も、既存のナレッジグラフを使う場合もあります。
まとめと次の一歩
GraphRAGは通常RAGの上位互換ではなく、文書をまたぐ関係や全体傾向を答えるための追加設計です。索引作成の費用と更新遅延があるため、局所検索は通常RAGを残して使い分けます。