GraphRAGは、資料に登場する人物・組織・出来事などの関係を、回答づくりに利用するRAGの考え方です。 RAG（検索した外部情報を生成AIの回答に使う仕組み）を、「質問に似た文章を拾う」だけでなく、情報のつながりや資料全体の構造を使う方向へ広げます。
例えば「案件Aの担当者は誰？」と「複数の案件に共通する遅延要因は何？」では、必要な情報の集め方が違います。後者は、一つの報告書が見つかっても十分に答えられません。
この記事では、Microsoftの論文『From Local to Global: A GraphRAG Approach to Query-Focused Summarization』を中心に、関係図と事前要約を使う仕組み、通常のRAGとの違い、評価結果と限界を説明します。GraphRAGにはさまざまな方式があるため、ここでは同論文の方式と公式実装の補足に範囲を絞ります。原論文 v2（Darren Edgeほか）
「一つの事実」と「全体の傾向」では、必要な資料が違う
まず、次のような架空の社内資料があると考えてください。
| 資料 | 書かれている内容 |
|---|---|
| 案件Aの週報 | 担当は佐藤。承認待ちで着手が遅れた |
| 案件Bの議事録 | 承認待ちが続き、予定を変更した |
| 案件Cの報告 | 担当交代後の引き継ぎに時間がかかった |
| 案件Dの振り返り | 担当交代時に確認事項が伝わらなかった |
| 案件Eの記録 | 他部署への連絡が遅れた |
| 案件Fの報告 | 部署間の連絡待ちで作業が止まった |
「案件Aの担当者は誰？」なら、案件Aの週報を検索して答える方法が自然です。一方、「これらの案件に共通する遅延要因は何？」には、承認待ち、引き継ぎ、部署間連絡といった複数の論点を拾う必要があります。
*質問に必要な情報の範囲を示す架空例です。GraphRAGを実行した性能比較ではありません。*
質問と意味の近い文章を検索するベクトル検索では、上位に似た内容ばかりが集まり、別の論点が抜けることがあります。検索された一部の資料が、資料全体を代表しているとは限らないためです。
本記事で比較する「通常のRAG」は、このように関連する文章の断片を取得して回答する基本構成を指します。検索の多様化や複数回の検索などを含む、すべてのRAGの限界を述べているわけではありません。
RAGの基本はRAGと外部知識の解説で、検索を改善する方法は文書分割・Hybrid Search・Rerankerの解説で詳しく扱っています。
準備段階：資料から関係図とグループごとの要約を作る
Microsoft方式を理解するポイントは、質問を受ける前に、資料全体を整理しておくことです。標準的な処理では、LLM（文章を読み取り生成する大規模言語モデル）が情報の抽出と要約を担います。
文章から「何と何が、どう関係するか」を取り出す
まず資料を処理しやすい長さに分け、エンティティ（人物・組織・案件など、識別する対象）と、その間の関係を取り出します。
架空の文「案件Aの担当は佐藤。案件Aは承認待ちで遅れた」なら、次のように表現できます。
- 佐藤 → 担当する → 案件A
- 案件A → 遅延要因として記載 → 承認待ち
対象を点、関係を線で表したものが、ナレッジグラフ（知識の関係図）です。複数の資料から得た対象や関係をまとめることで、文章の置き場所をまたいだつながりを整理できます。
*本文の架空資料から対象と関係を取り出す独自模式図です。抽出した関係は、独立に検証された因果関係を意味しません。*
この関係図はLLMが資料を読み取って作るため、抽出ミスは起こり得ます。「承認待ちが原因と書かれている」という関係を抽出できても、因果関係を独立に検証したことにはなりません。
関係の密なまとまりを見つけ、要約する
次に、グラフの中から関係の密なまとまりを見つけます。これをコミュニティと呼び、Microsoftの標準方式ではLeiden法（つながり方からまとまりを検出する手法）を階層的に使います。
ここで分類する中心はグラフの対象であり、元のファイルを単に部署別フォルダーへ分ける処理ではありません。一つの資料に、複数のまとまりに関係する記述が含まれることもあります。
そのまとまりごとに、主要な対象や関係を説明するコミュニティレポートをLLMで作ります。前の例なら、「承認待ちが記載された案件群」「担当交代に関わる案件群」といった内容を要約するイメージです。実際のまとまりや要約は、抽出結果と設定によって変わります。
*原論文と公式Dataflowの考え方を基に作成した架空例です。実際の検出結果を再現した図ではなく、階層構造は省略しています。*
こうして、質問のたびに全文を読み直す代わりに利用できる、資料群の要約を準備します。抽出・統合・コミュニティ検出・レポート作成の流れは、公式Dataflowで確認できます。
質問時：事前要約から部分回答を作り、全体の回答にまとめる
準備済みの要約を使って資料全体に答える方法が、Global Searchです。ユーザーの質問を受けると、指定した階層のコミュニティレポートを利用して回答を作ります。
処理は、Map-Reduce（分割して処理し、結果を統合する方法）として説明できます。
- 要約を扱える量に分ける。 複数のレポートを、モデルに渡せる長さに区切ります。
- 同じ質問に対する部分回答を作る。 それぞれの要約群から、質問に答えるための論点を取り出します。
- 有用な内容を選んで統合する。 中間結果を評価・絞り込みし、最終回答を生成します。
「共通する遅延要因は？」という質問なら、ある要約群から承認待ち、別の要約群から引き継ぎの問題が見つかり、それらを合わせて答えるイメージです。この例は説明用で、実行結果ではありません。
事前要約は資料の内容を整理したもの、部分回答は今回の質問に答えるために作ったものです。この二つを区別すると、毎回同じ要約文を返す仕組みではないことが分かります。
*原論文と公式Global Searchを基に独自作成した模式図です。各処理に同じ質問と異なる要約群が入り、部分回答を選んで統合します。*
ただし、要約や統合には扱える文章量の上限があります。Global Searchという名前でも、元資料のすべての事実が最終回答へ漏れなく入る保証はありません。細かな階層のレポートほど処理量が増える可能性もあります。公式Global Search
通常のRAG・Local Search・Global Searchを使い分ける
GraphRAGには、全体的な要約だけでなく、特定の対象を起点に調べるLocal Searchもあります。公式実装では、質問と意味の近いエンティティを探し、関連する関係情報や元の文章などを組み合わせて回答します。公式Local Search
| 方法 | 入口と主に使う情報 | 合わせやすい質問の例 | 引き換えになる点 |
|---|---|---|---|
| 通常のRAGの基本構成 | 質問に関連する文章の断片 | 案件Aの担当者は誰か | 全体の傾向を問う場合は、取得した資料の偏りを確認する必要がある |
| GraphRAGのLocal Search | 関連する対象を起点に、関係情報と文章を集める | 案件Aに関わる部署と役割は何か | 対象や関係の抽出品質に影響される |
| GraphRAGのGlobal Search | コミュニティの要約から部分回答を作る | 複数案件に共通する遅延要因は何か | 要約の準備と複数回の生成処理が必要になる |
このため、「GraphRAGにするとベクトル検索をすべて捨てる」という理解は適切ではありません。公式Local Searchのように、意味の近さによる検索とグラフの関係情報を組み合わせる構成もあります。
原論文では何が改善されたのか
原論文v2では、ポッドキャストの書き起こしとニュース記事という二つの資料群を使い、各125問の全体理解を問う質問で比較しています。これらの質問もLLMで作成されており、実運用の問い合わせをそのまま集計した評価ではありません。通常のベクトルRAGに加え、グラフを作らず元の文章を分割・要約して統合する方法も比較対象です。
主な結果は、GraphRAGがベクトルRAGより、回答の包括性と多様性で優位だったというものです。一方、簡潔で直接的に答える観点では、ベクトルRAGが強い結果でした。
| 評価の観点 | 読み取れること | その結果だけでは分からないこと |
|---|---|---|
| 包括性 | 質問に対して幅広い論点や詳細を含められたか | 各記述がすべて正しいか |
| 多様性 | 異なる視点や内容を含められたか | 未記載の重要論点が一つもないか |
| 直接性 | 質問に対し明確・簡潔に答えられたか | 複雑な資料全体を十分に扱えたか |
評価にはLLMによる回答比較が含まれます。著者らは対象領域への一般化や、捏造率の比較に追加検証が必要だとしています。したがって、「正答率が一律に上がる」「ハルシネーション（根拠のない内容の生成）がなくなる」と読み替えないことが大切です。原論文 v2・評価と限界
筆者としては、この研究の価値は、全体を問う質問に対して、検索上位の断片を全体の代表として扱う問題へ別の設計を示した点にあると考えます。単に回答を長くすることではなく、どの範囲の資料から論点を集めるかを設計の対象にしています。
導入前に確認したいコストと限界
GraphRAGの負担は、質問への回答時だけではありません。公式リポジトリも、索引を作る処理が高コストになり得るため、小さく始めるよう案内しています。Microsoft GraphRAGリポジトリ
| 段階 | 発生する作業 | 比較時に記録したいこと |
|---|---|---|
| 初回の準備 | 対象・関係の抽出と要約、レポート生成 | 処理時間とモデル利用量、失敗した資料 |
| 質問への回答 | 要約群からの部分回答と統合 | 応答時間、質問ごとのモデル利用量 |
| 資料の変更後 | 変更した内容と派生した情報の整合確認 | 更新範囲、古い記述が回答に残らないか |
| 品質確認 | 抽出ミス・要約漏れ・出典の確認 | 対象名の混同、少数の重要事例の欠落 |
例えば「A社」と「株式会社A」が別の対象として扱われたり、同名の人物が混ざったりすると、関係図も変わります。要約が読みやすくても、元の資料との対応を確かめる必要があります。
小規模に評価するなら、同じ資料に対して「担当者を探す質問」「複数案件を横断する質問」「資料に答えがない質問」を用意すると比較しやすくなります。これは筆者の評価案です。通常のRAG、必要に応じて単純な全文要約も比較し、回答の良さと準備・更新の負担を一緒に判断します。
なお、2026年9月14日の確認時点で、Microsoftの公開リポジトリは保守中心で、新機能追加や新しいプルリクエストの受け付けを行わない方針を示しています。 同リポジトリはMicrosoftが正式にサポートする製品ではないとも説明されています。論文の仕組みを学ぶことと、公開実装を長期運用へ採用することは分けて判断してください。公式README
よくある疑問
GraphRAGはモデルを追加学習する方法？
ここで説明した方式の中心は、資料を加工して回答時に渡す情報を作ることです。モデルの重みを更新する追加学習とは目的と処理が異なります。使い分けはRAGとファインチューニングの違いも参考にしてください。
資料が少なくても必要？
少量の資料を一度だけ要約したい場合は、全文を扱える方法と準備コストを比較するのがよいでしょう。GraphRAGを採用する理由は、資料の数だけでなく、繰り返しどのような質問をするかにも左右されます。
グラフを作れば、資料にない答えも分かる？
関係を整理しても、資料にない事実が確認済みになるわけではありません。回答の根拠を元資料へ戻って確認し、資料から答えられない質問には、その不足を示せるかも評価対象にします。
GraphRAGを検討するときは、まず手元の質問を「一部の資料で答えられるもの」と「資料全体を見渡す必要があるもの」に分けてみてください。後者が多く、同じ資料群を繰り返し調べる用途なら、関係図と事前要約を作る価値を具体的に比較できます。
参考資料
- Darren Edgeほか：From Local to Global: A GraphRAG Approach to Query-Focused Summarization v2（CC BY 4.0）
- Microsoft GraphRAG：Dataflow
- Microsoft GraphRAG：Global Search
- Microsoft GraphRAG：Local Search
- Microsoft GraphRAG：公式リポジトリ
本文の社内資料と回答例は、仕組みを説明するための架空例です。記事作成時にGraphRAGを実行した性能検証は行っていません。
コメント