Graph RAGとは？従来RAGとの違い・向く質問・設計上の注意点
AI新規事業
AI新規事業のPoC・立ち上げ、何から始めるべきかご相談ください
要件定義からリリースまで、Mojiがワンチームで伴走します。
Graph RAG（GraphRAG）は、RAGの検索・文脈構成に知識グラフを利用する設計群です。知識グラフでは、人・製品・組織・施策などのエンティティをノードとして、その間の関係をエッジとして表します。
本記事では、知識グラフを検索・文脈構成に用いるRAG設計群を「Graph RAG」と呼びます。ただし、グラフの作り方、検索対象、探索方法、要約の有無は実装ごとに異なります。Microsoft ResearchのGraphRAGは、エンティティ知識グラフとコミュニティ要約を用いる代表例として扱います。
RAG（Retrieval-Augmented Generation）は、生成モデルに検索で取得した外部情報を与えて回答を生成する枠組みです。原論文では、事前学習済みの生成モデルと、検索でアクセスする非パラメトリックな外部メモリを組み合わせています。RAG原論文：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
通常RAGであっても、ベクトル検索だけでなくキーワード検索、メタデータ絞り込み、再ランキングなどを組み合わせられます。Graph RAGは、それらを一律に置き換えるものではありません。RAGの基本的な流れは、RAG（拡張生成）とは？も参照してください。
結論：Graph RAGを検討するのは「関係」と「全体像」が回答根拠になるとき
Graph RAGをPoC候補に入れるのは、回答に必要な根拠が単一チャンクへ収まらず、エンティティ間の関係やデータ集合全体の構造にある場合です。代表的には、次の2種類があります。
- 複数の関係をまたぐ質問：「障害に関係した変更、その承認者、影響したサービスを整理して」のように、複数の対象と関係を結び付ける必要がある質問。
- コーパス全体を対象にする質問：「データセットの主要テーマは何か」のように、個別文書の抜粋ではなく、集合全体について問う質問。
Microsoft ResearchのGraphRAG論文は、コーパス全体に向けた質問を、単純な検索ではなくクエリ指向要約の問題として扱い、エンティティ知識グラフと関連エンティティ群のコミュニティ要約を用いる方式を提案しています。同論文での評価は、約100万トークン規模のデータセットにおける特定のグローバルなセンスメイキング質問を対象としたものです。したがって、あらゆる全体要約でGraph RAGが優位だとは限らず、通常RAGに階層要約、メタデータ集計、対象コーパスの事前分割を組み合わせる案とも比較してください。原論文：From Local to Global: A Graph RAG Approach to Query-Focused Summarization
通常RAGとGraph RAGの違い
観点 | 通常RAG（文書・チャンク検索中心の構成） | Graph RAG（知識グラフを使う構成） |
|---|---|---|
主な検索対象 | 文書チャンク、メタデータ、埋め込みベクトル | 実装により、文書チャンクに加えてエンティティ、関係、近傍、サブグラフ、要約など |
質問との適合 | 特定の規程、製品仕様、単一または少数の根拠文書で答えられる質問から検証しやすい | 複数エンティティの関係や、広いコーパスの論点を扱う質問でPoC候補になり得る |
索引作成 | 文書分割、属性付与、埋め込み、検索インデックス作成など | 左記に加え、エンティティ・関係の抽出や統合、グラフ作成を行う構成がある |
品質確認 | 必要な原文を取得できたか、回答が原文に忠実かを確認する | 左記に加え、エンティティ同定、関係の向き・種類、グラフから原文へ戻る経路を確認する |
追加で見積もる事項 | 埋め込み、検索、再ランキング、回答生成、更新処理 | グラフ抽出・要約・更新・検証を採る場合は、それらの処理と品質管理も見積もる |
上表は実務上の比較軸です。実際の適合性は、質問分布、文書量、表記ゆれ、アクセス制御、モデル、正解の定義、許容できる遅延・費用によって変わります。
Microsoft GraphRAG v3.1.2の標準インデックス処理は、非構造テキストからのエンティティ・関係・主張の抽出、コミュニティ検出、複数粒度のコミュニティ要約・レポート生成、テキストのベクトル化を含みます。これはGraph RAG一般に必須の工程ではなく、同実装の標準パイプラインです。Microsoft GraphRAG v3.1.2：Indexing overview（固定コミット）
Graph RAGの典型的な処理フロー
以下は、知識グラフを用いるRAGに見られる処理を、Microsoft GraphRAGの標準パイプラインを例に整理したものです。すべての実装が同じ手順を採るわけではありません。
- 原文を検索可能な単位に分ける：文書をTextUnitやチャンクに分割し、文書ID、版、更新日時、アクセス権限などの追跡情報を保持します。
- エンティティと関係を抽出する：原文から「プロジェクトA — 所有部門 — 開発部」「施策B — 依存する — API C」のような候補を作ります。
- 同一性と根拠を確認する：略称、表記ゆれ、同名の別人・別製品を区別します。ノードやエッジに、出所となる原文単位を関連付けます。
- 必要に応じてグループ化・要約する：関連するエンティティ群をまとめ、集合全体を問う検索で使う要約を作る構成があります。
- 質問に応じて探索対象を選ぶ：特定エンティティを問う場合は局所的な関係と原文を、広い論点を問う場合は要約群を参照する、といったルーティングを設計します。
- 回答時に原文根拠を提示できるようにする：グラフ上の関係や生成済み要約だけで結論を確定せず、回答に利用した原文を検証・表示できる状態を保ちます。
Microsoft GraphRAGの既定データフローでは、入力文書をTextUnitに分割し、エンティティ・関係を抽出した後、コミュニティ検出とコミュニティレポート生成を行い、TextUnit、グラフ出力、コミュニティレポートをベクトル化します。Microsoft GraphRAG v3.1.2：Default configuration workflow（固定コミット）
向く質問・向かない質問を3方式で判断する
質問の型 | 例 | 比較の出発点 | 確認したいこと |
|---|---|---|---|
単一事実の確認 | 「経費精算の上限額は？」 | 通常RAG | 最新版の規程と該当箇所を正確に取得・表示できるか |
関係をまたぐ調査 | 「障害Xに関係した変更と、その承認者・影響サービスを整理して」 | 通常RAGとGraph RAGを比較 | 必要な原文と関係を再現できるか。Graph RAGが関係の取得・説明を改善するか |
全体傾向の要約 | 「過去1年の顧客要望で繰り返される論点は？」 | Graph RAG、階層要約、メタデータ集計などを比較 | 対象集合の偏り、重要論点の網羅、各論点を裏付ける原文を確認できるか |
探索を繰り返す調査 | 「不足情報を追加検索し、矛盾があれば再調査して報告して」 | エージェンティックRAGを比較対象に加える | 検索、検証、再計画の制御が必要か。停止条件と人の確認を定義できるか |
Microsoft GraphRAG v3.1.2のクエリエンジンは、特定エンティティの理解に向くLocal Search、コミュニティレポートをmap-reduceで扱うGlobal Search、コミュニティ情報を局所検索へ加えるDRIFT Search、比較用のBasic Searchを区別しています。Global Searchはリソース集約的であり、データセット全体を理解する質問で良い応答を返すことがある、と説明されています。Microsoft GraphRAG v3.1.2：Query Engine overview（固定コミット）
Graph RAGとエージェンティックRAGは別の設計軸
Graph RAGは主に、知識をどのように構造化し、何を検索対象にするかに関わる設計です。エージェンティックRAGは主に、検索・評価・追加調査・再計画をどのような制御フローで反復するかに関わる設計です。
- Graph RAG：グラフ、原文、要約などを使って文脈を構成する。単発の問い合わせフローとして実装することも、複数段の探索として実装することもあります。
- エージェンティックRAG：通常の文書検索、グラフ探索、データベース照会などを、計画や検証の結果に応じて選び直す構成です。
- 両方を組み合わせる構成：エージェントが質問を分解し、局面に応じて文書検索、グラフ探索、根拠確認を使い分けます。
Agentic RAGに関するサーベイは、従来RAGの静的なワークフローに対し、反省、計画、ツール利用、マルチエージェント協調といった設計パターンをRAGパイプラインへ組み込むものとして整理しています。Graph RAGを採用しても、それだけでエージェンティックRAGになるわけではありません。エージェンティックRAGとは？も参照してください。Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
「Context Graph」や「Agent Graph」といった表現を見かけた場合は、Graph RAGの同義語と決めつけず、提唱元の資料でノード、エッジ、検索方法、更新方法、評価方法を確認してください。本記事では、こうした名称を独立した標準技術分類としては扱いません。生成AIシステムにおける設計レイヤーの整理は、生成AIの設計はどう変わった？で解説しています。
導入前に確認する6つのチェックリスト
- 質問ログに関係質問があるか：「誰が」「何に依存し」「どの変更を経て」といった、複数エンティティを結ぶ質問を抽出します。
- 関係の意味を定義できるか：「所有」「承認」「依存」「原因」「後継」など、エッジの種類と向きを業務上の言葉で定めます。
- エンティティを識別できるか：人名、顧客名、製品名、プロジェクト名の略称・表記ゆれ・同名を扱うルールを用意します。
- 原文へ戻れるか：ノード、エッジ、要約から、出所の文書、該当箇所、版、権限情報を追跡できるようにします。
- 更新と削除を運用できるか：追加・訂正・削除された文書に対し、どの範囲を再抽出・再要約・無効化するかを決めます。
- 比較評価の質問セットがあるか：通常RAGと同じ質問、同じ正解根拠、同じ制約で比較し、Graph RAGを追加する便益を測ります。
Mojiによる提案：小さく比較するPoC手順
以下は、特定製品に共通する必須手順ではなく、Graph RAGの導入可否を判断するためのMojiによるPoC設計提案です。
- 質問を30〜100件集める：実運用の質問を優先し、単一事実、関係探索、全体要約、回答不能を混在させます。
- 質問ごとに必要な根拠を注釈する：期待回答だけでなく、必要な原文、関係、回答時点、回答してはいけない条件を記録します。
- 通常RAGを比較対象として用意する：文書分割、メタデータ、検索、再ランキング、権限フィルタを対象要件に合わせて設定します。
- 関係質問に限定して最小グラフを作る：最初から全社ナレッジを対象にせず、ひとつの業務領域・文書集合で抽出精度と更新方法を確かめます。
- 構築・検索・回答・運用を分けて評価する：グラフが正しいか、必要な根拠を検索できたか、回答が根拠に忠実か、更新後に追従できるかを別々に見ます。
- 採用条件を先に決める：たとえば、関係質問の根拠取得が改善すること、単一事実質問の品質・遅延・運用負荷が許容範囲に収まることを、導入前に合意します。
評価テンプレート
次の表はMojiによる提案です。数値の閾値は、モデル、文書品質、質問の難易度、業務上の許容誤差に応じて設定してください。
評価層 | 確認項目 | 判定例 |
|---|---|---|
グラフ構築 | エンティティ同定 | 同名別人、略称、表記ゆれが誤統合されていないか |
グラフ構築 | 関係の正確性 | エッジの向き・種類・根拠文書が正しいか |
検索 | 根拠再現 | 回答に必要な原文、ノード、関係を取得できたか |
生成 | 根拠忠実性 | 取得していない因果や関係を回答が補っていないか |
運用 | 更新追従 | 文書の追加・削除・訂正後に古い関係や要約が残っていないか |
非機能 | コスト・遅延 | 索引作成、更新、問い合わせの各処理が要件内か |
GraphRAG-Benchは、単純な内容検索だけでは解きにくい多段推論を要するドメイン固有の問題を含み、グラフ構築、知識検索、回答生成、推論過程を横断して評価するベンチマークです。同研究では、手法ごとの効果が質問タイプにより異なり、すべてのGraphRAG手法が一律に改善するわけではないことも報告されています。実務の採用基準を直接与えるものではありませんが、最終回答だけでなく構築・検索・生成を分けて評価する際の参考になります。GraphRAG-Bench: Challenging Domain-Specific Reasoning for Evaluating Graph Retrieval-Augmented Generation
RAGは、最終回答だけでは検索と生成のどちらに改善余地があるかを判断しにくい構造です。評価データの作り方と根拠の持たせ方は、RAG評価データセットの作り方、評価設計全体はAIの評価とは？を参照してください。
Graph RAGを採用しない、または後回しにする条件
- 質問の大半が、ひとつの規程、マニュアル、チケットなどの原文で完結する。
- エンティティの表記ゆれや同名を扱う業務ルール、確認者、訂正フローを置けない。
- 文書追加、訂正、削除に対する再抽出・再要約・無効化の運用を設計できない。
- 回答根拠として原文提示が求められるのに、ノード、エッジ、要約から出所を追跡できない。
- 通常RAGの文書分割、メタデータ、検索、再ランキング、アクセス制御をまだ比較評価していない。
これらはGraph RAGが不適切だと一律に結論付ける条件ではなく、追加する構造と運用負荷に見合う検証が必要になりやすい条件です。グラフを使う場合も、原文の品質、アクセス制御、更新処理、回答根拠の確認は独立して設計してください。
まとめ
Graph RAGは、知識グラフを検索・文脈構成に使うRAG設計群です。複数エンティティの関係をまたぐ質問や、コーパス全体の論点を扱う質問では有力な選択肢になり得ます。一方、Graph RAGの具体的な構成と効果は実装・データ・質問タイプに依存します。
導入判断では、実際の質問を「単一事実」「関係探索」「全体要約」「反復調査」に分類し、通常RAG、Graph RAG、必要に応じて階層要約やエージェンティックRAGを同じ評価セットで比較してください。原文根拠の取得、関係の正確性、回答の忠実性、更新運用を分けて確認すると、グラフを追加する価値と追加しない判断の両方を説明しやすくなります。