GraphRAGとは？仕組み・RAGとの違いと導入の判断基準

ドキュメントの確認日：2026年10月26日。 MicrosoftのGraphRAGドキュメント、同プロジェクトのリポジトリ、Neo4jとLlamaIndexのドキュメントを確認しています。以下の比較は、ドキュメントに記載された仕組みの分析であり、性能テストの結果ではありません。製品へのフィードバックを扱う例は、説明用のものです。

GraphRAGとは何ですか？

Microsoft GraphRAGは、質問を受ける前に文書群の全体像を用意します。大規模言語モデル（LLM）で文書からエンティティと関係を抽出し、つながりのあるエンティティをコミュニティにまとめ、その要約を生成します。クエリエンジンは、こうして作られた構造を使って質問に答えます。Microsoftの概要ページでは、この手法と主な検索モードを説明しています。

エンティティとは、顧客、製品、人物、プロジェクトなど、データの中で名前を持つ対象です。関係はエンティティ同士を結びます。たとえば「顧客が製品を使う」「プロジェクトがサービスに依存する」といったつながりです。これらがナレッジグラフを構成します。コミュニティは、つながりのあるエンティティの集まりで、その要約は文書群のその一角で何が起きているかを示します。

文書群を、さまざまな建物が並ぶキャンパスにたとえてみましょう。ベクトル検索は、質問に似た内容がある部屋を探します。グラフの関係は部屋同士をつなぎ、コミュニティの要約は上階の通路から見渡すような全体像を示します。キャンパス全体で何が起きているかを知りたいとき、似た部屋をいくつか集めるだけでは、建物の一角を丸ごと見落としかねません。

これは、検索拡張生成（RAG）アプリでよく起こる失敗の背景にある問題です。RAGは、モデルが回答する前に、検索で得た根拠を渡す仕組みです。「エクスポートに関する規定」は正しく見つけられても、「これらのインタビュー全体を通して、顧客は何に不満を感じているか」への回答は表面的になることがあります。後者には、文書群を広くカバーする必要があります。答えを直接述べた一節が、そもそも存在しない場合もあるのです。

「Graph RAG」は、グラフを使う検索システム全般を指す言葉でもあります。本記事で中心に扱うのはMicrosoftの実装です。別のフレームワークでグラフを使うアプリを作っても、Microsoft方式のコミュニティレポートが自動的に生成されたり、同じグローバル検索手法が使われたりするわけではありません。

GraphRAGはどのような仕組みで動きますか？

大きく変わるのはインデックス作成の段階です。GraphRAGは、元のデータから説明文を生成し、後の検索で再利用できるようにします。Microsoftの標準インデックス作成方式では、抽出と要約にLLMを使い、グラフのクラスタリングでコミュニティ構造を作ります。

各処理は、次のように前段の出力を受けて進みます。

1. 文書をテキストユニットに分割します。 元の文章をチャンクに切り分けます。各チャンクと元の文書の対応を残すことで、抽出した項目の出典をたどれるようにします。
2. エンティティと関係を抽出します。 LLMが各テキストユニットを読み、見つかったエンティティと、そのつながりを記述します。
3. グラフを統合します。 一致するエンティティや関係の説明をまとめ、要約します。ドキュメントに記載された統合ルールでは、エンティティの名称と型、関係の始点と終点を使います。
4. コミュニティを検出します。 グラフクラスタリングのアルゴリズムであるHierarchical Leidenが、つながりのあるエンティティを、粒度の異なる階層にグループ化します。
5. コミュニティレポートと埋め込みを作成します。 LLMがコミュニティを要約します。検索対象の生成物には、類似度検索に使う数値表現である埋め込みも作成します。

この流れは、Microsoftのインデックス作成データフローに基づきます。主張の抽出は任意の追加ワークフローで、デフォルトでは無効です。標準のグラフとレポートを作るために、主張を抽出する必要はありません。

製品フィードバックの文書群なら、あるインタビューにAtlasプロジェクト、エクスポートの失敗、承認プロセスが登場するかもしれません。別の会話では、Atlasと共有ワークスペースのつながりが語られているかもしれません。こうした関係を抽出できれば、文書ごとに言い回しが違っていても、コミュニティレポートで関連する問題をまとめられます。

この段階には弱点もあります。関係を抽出し損ねたり、別々のエンティティを統合したり、同じ対象の別名を別エンティティとして扱ったりすると、その後の要約も歪んだ構造を引き継ぎます。きれいにつながったグラフも、あくまで文章を解釈した結果です。

Microsoftのデフォルト構成では、インデックスの出力を列指向ファイル形式のParquetテーブルに保存し、埋め込みを設定済みのベクトルストアに書き込みます。この構成に、独立したグラフデータベースは必須ではありません。インデックス作成の概要を参照してください。

Global・Local・DRIFT・Basicの検索モードをどう使い分けますか？

検索モードは、回答にどのような根拠が必要かで選びます。グローバル検索は文書群全体の傾向を捉え、ローカル検索は関連するエンティティの周辺から探します。ほかのモードは、より広い探索や、比較の基準となるベクトル検索を提供します。

グローバル検索：文書群全体のテーマを捉える

「これらの文書全体に共通する主なテーマは何か」という質問にMicrosoft GraphRAGを検討する最大の理由が、グローバル検索です。階層の中から選んだレベルのコミュニティレポートを、回答の材料として使います。

処理方式はmap-reduceです。バッチごとに処理してから、結果を統合します。map段階では、レポートのバッチから、評価付きの要点を含む部分回答を生成します。reduce段階では、有用な要点を選び、最終回答にまとめます。コミュニティレポートを詳細にすると、回答の具体性と必要なリソースの両方が増える可能性があります。グローバル検索のドキュメントを参照してください。

顧客フィードバックを確認する製品責任者にとって、期待できるのは、より広い範囲をカバーした回答です。導入時の手順、承認、共同作業といった複数の領域を、回答に盛り込める可能性があります。類似した文章の取得件数を増やすだけでは、こうした異なる領域がそれぞれ含まれるとは限りません。

ただし、グローバル検索が行うのはレポートの統合です。各問題に言及した顧客数を正確に数える処理ではありません。意思決定に頻度順のランキングが必要なら、集計単位と重複排除の方法を明確にして数え、その結果をモデルに説明させてください。

ローカル検索：エンティティとその周辺を調べる

ローカル検索は、「Atlasプロジェクトはエクスポートの問題とどうつながっているか」といった質問に向いています。意味的に関連するエンティティを見つけ、そこにつながるグラフ情報と元の文章を集め、回答のコンテキストウィンドウに収まるように絞り込みます。ローカル検索のドキュメントを参照してください。

文書をまたいで散在する関係が回答の鍵になる場合に有効です。グラフが検索の起点とつながりを示し、元の文章が詳しい根拠を補います。ただし、ローカル検索も類似度による照合と限られたコンテキストを使うため、関連する関係をすべて拾える保証はありません。

DRIFT検索：広い文脈から掘り下げる

DRIFTは、関連するコミュニティ情報から始めて、ローカル検索で調べる追加の質問を組み立てます。最初の大まかな回答を手がかりに、より具体的な調査の方向を見つけていく探索的な質問に適しています。DRIFTのドキュメントを参照してください。

たとえば「これらの顧客にとって、共同作業が難しいのはなぜか」という質問から、承認、共同での管理責任、エクスポート後の引き継ぎを個別に調べる流れが生まれるかもしれません。日常的な質問の標準モードにする前に、追加の検索によって有用な根拠が得られるかを評価してください。

Basic検索：比較の基準を残す

Basic検索は、ベクトル検索で類似するテキストチャンクを取得します。Microsoftは、クエリ方式を比較しやすくするためにこのモードを用意しています。「エクスポートの規定には何と書かれているか」といった範囲の狭い質問では、有用な比較対象になります。クエリエンジンのドキュメントを参照してください。

GraphRAGとRAGの違いは？質問とインデックスで比較する

質問に確実に対応できる検索方式のうち、最もシンプルなものを選びます。以下では、向いている質問、インデックス作成時の処理、保守を分けて比較します。設計上の特徴を整理したものであり、実測したコストや速度の順位ではありません。

ハイブリッド検索が解決するのは、文書群全体の統合とは別の問題です。Microsoftのハイブリッド検索のドキュメントでは、全文検索とベクトル検索の結果を組み合わせる方法を説明しています。アプリが正確な製品コードを見つけられないなら、まずハイブリッド検索を検討してください。語句の検索に問題があるとき、グローバルなコミュニティ要約を導入するのは回り道です。

エージェンティックRAGは、検索の進め方を変えます。LangGraphのエージェンティック検索チュートリアルで示されているように、モデルが検索の実行を選び、関連性を評価し、質問を書き換えて再検索することがあります。次にどの根拠を集めるかをアプリ自身で判断する必要があるなら、エージェンティックRAGが候補になります。

これらの方式は組み合わせられます。エージェントがグラフ検索器を呼び出すことも、グラフを使う検索器がハイブリッド検索から始めることもできます。判断すべきなのは、実際に確認した失敗を、どの追加の仕組みが解決するかです。すべてを一度に導入すると、その見極めが難しくなります。

GraphRAGのインデックス作成で処理が増える理由

標準のGraphRAGでは、通常のベクトルインデックスに必要な埋め込みの処理に、生成処理が加わります。文書数に掛ければコストを見積もれるような、根拠のある万能の倍率はありません。処理量は文章の内容、抽出の設定、生成するグラフとレポートに左右されます。

試験導入の計画では、次のように整理すると役立ちます。

インデックス作成の処理量 ＝ チャンク処理 ＋ 抽出処理の各パス ＋ 説明文の要約 ＋ コミュニティレポート ＋ 埋め込み。

これは試験導入で処理を把握するための考え方であり、ベンダーの料金計算式ではありません。段階ごとに処理量を記録すれば、データを増やしたときに何が増えるのかが見えてきます。

チャンクが、繰り返し発生する抽出処理の量を左右します。 チャンクが増えるほど、解析するテキストユニットも増えます。チャンクのサイズや重複幅によって、抽出器が同じ文脈を繰り返し読む量も変わります。Microsoftの設定には、追加の抽出サイクルを制御するmax_gleaningsもあります。どのチャンクも必ずLLM呼び出し一回分で済むとは考えないでください。設定リファレンスを参照してください。

グラフの規模が、後続処理で扱う量を左右します。 多種多様なエンティティと関係を含む文書群では、同じ程度の文書量でも、狭いテーマを扱う文書群より、統合すべき説明文が増える可能性があります。同じ対象への言及が繰り返されると統合対象の説明文が増え、多様なつながりが、レポートを必要とするコミュニティの構造を形作ります。これは抽出と要約の仕組みによるもので、文書数だけでは決まりません。

レポートには、さらに生成処理が必要です。 コミュニティの内容を要約する必要があり、階層ごとに粒度の異なる概観が作られます。埋め込みも引き続きインデックスの一部です。処理量を左右する要素を洗い出すには、標準方式のタスク一覧から確認するとよいでしょう。

キャッシュを再利用すれば、モデルの処理を繰り返さずに済む場合があります。 Microsoftは、後のインデックス作成で使えるように、LLM呼び出しの結果をキャッシュします。新規構築と更新は別々に測定してください。キャッシュを使った再実行の結果だけでは、新しい文書群に必要な処理はわかりません。キャッシュ設定を参照してください。

クエリ実行時の処理は、別枠で見積もる必要があります。グローバル検索のmap-reduceやDRIFTの探索では、インデックス作成が終わった後も、モデルの処理が複数回発生する場合があります。インデックス作成の試験がうまくいっても、回答の待ち時間が許容範囲に収まるとは限りません。

文書が新しくても、要約のテーマは古いままになり得ます

新しい文書がストレージに届いても、グローバル検索が使うレポートまで最新になるわけではありません。鮮度の目標は、クエリが実際に読む派生インデックスまで含めて設定する必要があります。

Microsoftはgraphrag updateを提供しています。現行CLIの説明では、デフォルトで新しいインデックスをupdate_outputに書き込みます。設定には、既存の出力を保持するため、更新用の保存先を別に指定する項目もあります。つまり差分更新は可能ですが、更新コマンドだけでは同期方針は完成しません。CLIリファレンスと更新用ストレージを参照してください。

Atlasについて以前の説明を訂正する、サポート窓口でのやり取りを考えてみてください。新しい文書は存在するのに、本番で使われているコミュニティレポートは古い状況を説明し続けることがあります。直接検索すれば訂正内容を見つけられたとしても、保守上の不備です。

実際に導入するバージョンと設定で、追加、訂正、削除をテストしてください。元のチャンク、抽出された関係、ローカル検索とグローバル検索の両方の回答を確認します。ここで挙げたCLIドキュメントだけでは、すべての変更が、アプリの必要とする意味や動作を保って自動的に反映されるとは確認できません。

運用で必要なのは、インデックスのバージョンを確認できることと、どの時点までの情報を取り込んでいるかが明確であることです。整合性のある生成物一式を公開してから、クエリの参照先をそのバージョンへ切り替えます。変化の速いレコードについて即時に回答する必要があるなら、レポートの更新プロセスを評価する間も、直接検索できる経路を用意しておいてください。

Graph RAGを構築する、ほかの二つの選択肢

Neo4jとLlamaIndexは、抽出、保存、クエリの設計が異なるグラフ検索の構成要素を提供しています。「GraphRAG」を互換性のある単一の製品として扱わず、それぞれのドキュメントに記載された仕組みを評価してください。

Neo4jでGraphRAGを構築する

Neo4j GraphRAG for Pythonには、VectorCypherRetrieverが含まれます。まず類似するノードを見つけ、次に検索クエリを実行して追加の文脈を集めます。CypherはNeo4jのグラフクエリ言語です。このパッケージは、ベクトルと全文検索のインデックスを使うハイブリッド検索や、質問をデータベースクエリに変換するText2Cypherも提供します。Neo4jの検索器ガイドを参照してください。

この方法は、関連ノードを見つけた後にどの関係をたどるか、明示的に制御したい開発者に向いています。たとえば、プロジェクトを検索してから、定義済みのグラフクエリで、そのプロジェクトにつながる依存先を取得できます。

Neo4jのグラフ構築ツールは、LLMによるエンティティと関係の抽出、グラフへの書き込み、重複エンティティの解消にも対応しています。ドキュメントには、設定を変更しない限り、抽出エラーが起きたチャンクを無視できるエラー処理が記載されています。クエリが動くかだけでなく、取り込みに抜けがないかも確認してください。Knowledge Graph Builderガイドを参照してください。

押さえておきたいのは、ベクトル検索の後にグラフクエリを実行するだけでは、Microsoft方式の階層的なコミュニティレポートは作られないことです。幅広いテーマをまとめる必要があるなら、その層をどう構築するかまで決めてください。

LlamaIndexのプロパティグラフを使う

LlamaIndexのPropertyGraphIndexは、グラフの構築と検索を取りまとめます。プロパティグラフは、ラベル付きのエンティティ、その属性、エンティティ間の関係を保持します。抽出器はチャンクに対して動作し、SchemaLLMPathExtractorでは、許可するエンティティと関係のパターンに抽出対象を制限できます。VectorContextRetrieverは、埋め込みが作られたグラフノードを見つけ、そこにつながるパスを取得します。検索オプションによって、元の文章も取得できます。プロパティグラフガイドを参照してください。

この方法は、アプリケーションフレームワークの中で、抽出器や検索器を柔軟に設定したい開発者に向いています。ドキュメントに記載された挿入、アップサート、削除の操作は、グラフを維持するための構成要素になります。ただし、情報源の変更や、そこから抽出した事実をどう扱うかは、アプリ側で方針を定める必要があります。

使える操作はグラフストアによって異なります。デフォルトのSimplePropertyGraphStoreはグラフデータベースではなく、Cypherにも対応していません。保存先と検索方式はセットで選んでください。また、プロパティグラフのインデックスに、Microsoft方式のグローバル要約ワークフローが含まれるとは考えないでください。

GraphRAGの使い方：実際の失敗を起点に評価する

対象を絞った文書群と、人が回答を確認できる質問から始めます。Microsoftのリポジトリは、インデックス作成に大きなコストがかかり得ると注意を促しています。スタートガイドでも、大規模な処理に進む前に、小さなデータセットで学ぶことを勧めています。

ワークスペースと認証情報の設定が済んだら、現行ドキュメントに記載されたCLI構文で、次のコマンドを実行できます。

graphrag index --method standard
graphrag query "What are the main themes across these documents?" --method basic
graphrag query "What are the main themes across these documents?" --method global

現行のCLIリファレンスでは、質問は位置引数として渡します。

出力は、網羅性と根拠の両方で評価してください。テーマの数が増えても、存在しないつながりを作り出していれば問題は解決していません。重要なテーマをそれぞれ根拠までたどり、期待したテーマのうち何が欠けているかを記録し、異なる集団が都合のよい一般論にまとめられていないかを確認するよう、レビュー担当者に依頼します。

開発者は、既存の事実検索が許容できる水準を保ちながら、苦手な種類の質問を改善できた場合にのみ、グラフを採用してください。運用担当者は、訂正や削除にも対応できる更新手順を求めてください。システムを発注する側も、グラフの可視化を回答改善の証拠として受け入れる前に、実際の用途を代表する文書で同じ検証を求めるべきです。

根拠はすでに揃っているのに、モデルが繰り返し形式や振る舞いを誤るなら、RAGとファインチューニングの違いを見直してください。インデックスを高度化することで改善できるのは、根拠へのアクセスです。生成時のあらゆる失敗に対して、自動的に正しい対処になるわけではありません。

GraphRAGに過度な期待を寄せていませんか？

確実に言えるのは、「グラフを使えばRAGがよくなる」という一般論よりも限定的なことです。特定のグラフとクエリ手法が、特定の種類の根拠収集を改善する可能性があります。

つながりがあることは、正しさの証明にはなりません。 抽出した関係もコミュニティレポートも、間違うことがあります。検索できる形にした解釈として扱い、出典をたどれる状態を保ってください。グラフのパスは検索過程の確認を容易にしますが、その基になった主張が正しいと証明するものではありません。

つながりを多く示す回答が、より網羅的とは限りません。 幅広く見える要約でも、ほかとつながりのない懸念を取りこぼすことがあります。少数の意見に現れるテーマや、まとめにくい例外も評価対象に含めてください。製品の判断を変え得るものなら、なおさらです。

コミュニティの要約は、頻度の集計表ではありません。 言及の繰り返し、エンティティ同士のつながり、モデルによる重要度の判断は、重複を除いた顧客数を数えることとは別です。あるテーマが最も多いと述べる前に、分析の単位を定めてください。

リポジトリのコードは、Microsoftのマネージドサービスではありません。 Microsoftのリポジトリに関する案内では、このコードを、Microsoftが公式にサポートする製品ではなく、手法を示すための実装と説明しています。デプロイ、監視、データ更新の責任者は、別途決める必要があります。

GraphRAGについてよくある質問

来週、何から始めればよいですか？

現在のアプリがうまく答えられない、テーマを問う質問を取り上げてください。そして、よい回答を作るには文書群のどの範囲から、どのような根拠が必要かを特定します。その失敗を中心に小規模なGraphRAGの評価を組み、既存の検索器を比較対象として残します。

文書群全体をまとめる機能が繰り返し求められ、派生インデックスの管理を担う人がいるなら、今すぐ試す理由があります。レポートを検証するより速く文書群が変わる場合や、テーマを扱う回答の網羅性を判断できる人がいない場合は、導入を待ってください。主な用途が、すでに安定している事実検索なら、現在の設計を維持します。グラフを残すかどうかにかかわらず、根拠を持って検索方式を選べることが、有用な成果です。

AIシステム構築の実践ガイドを受け取るには、ニュースレターに登録してください。