この記事の音声は準備中です。
音声の一覧・再生リストへGraphRAG とナレッジグラフ
この記事の目的
ベクトル検索が苦手な質問 — 多段の関係をたどる問い、全体を集約する問い — に対して、グラフ型の知識表現(ナレッジグラフ・GraphRAG外部の知識ソースを検索し、結果を LLM の入力に加えて回答の根拠にする手法。検索の判断を Agent に任せる構成は Agentic RAG と呼ばれる。)を使うべきかどうかを判断できるようになります。「グラフは強力そう」で飛びつくのではなく、通常の RAG で足りるかをまず見極め、要るなら構築・維持コストを織り込んで選べる状態がゴールです。
対象読者
- 通常の RAG を運用していて、「関係をたどる質問」「件数を数える質問」に弱いと感じているエンジニア
- GraphRAG の導入を検討し、その効果とコストを見積もりたいエンジニア
前提知識
- RAG 実装パターン — 通常の RAG(ベクトル・キーワード・ハイブリッド検索)。本記事はそれで足りないときの発展形
- RAG と Agent の関係・使い分け — 検索構成の選択
本文
概要: まず通常の RAG で足りるかを問う
| 対象 | 正本 | 本記事 |
|---|---|---|
| 通常の RAG(ベクトル・キーワード・ハイブリッド検索) | RAG 実装パターン | — |
| データの前処理・埋め込みテキストや画像を、意味的な近さが距離に対応する数値ベクトルに変換したもの。RAG・記憶・分類の土台で、「何が近いか」はモデルで変わるため自社データで評価して選ぶ。モデル変更は全チャンクの再インデックスを伴う。 | データ前処理 / 埋め込み | — |
| グラフ型知識表現(GraphRAG) | 本記事 | 使いどころの判断・構築・型・評価 |
GraphRAG は万能薬ではありません。多くの質問は通常の RAG で足ります。本記事の最初の問いは「その質問は、本当にグラフでないと解けないのか」です。グラフの構築・維持コストは大きいため、通常の RAG で届かないと確認できてから検討します。
ナレッジグラフの基礎
ナレッジグラフ(knowledge graph)は、知識を**エンティティ(節点)と関係(辺)**のネットワークで表したものです。「山田(人)— 所属 →(部署)営業部」「規定 A —参照→ 規定 B」のように、事実を「主語 – 関係 – 目的語」の三つ組で持ちます。
- エンティティ: 人・組織・製品・文書・概念など、区別したい対象
- 関係: エンティティ間のつながり(所属・参照・依存・因果など)
- スキーマ: どんなエンティティ型・関係型を許すかの設計。緩くすると構築は楽だが検索が不安定、厳しくすると精度は上がるが構築が大変、というトレードオフです
ベクトル検索が「意味の近い断片」を返すのに対し、グラフは「つながりをたどる」ことができます。この差が、後述の「向く質問」を生みます。
LLM によるグラフ構築の現実
ナレッジグラフの構築は、かつては人手が中心でした。LLM は文書からエンティティと関係を抽出してグラフを自動構築できますが、精度には現実的な限界があります。
- 抽出: 文書から三つ組を取り出す。表現の揺れ(「営業部」「営業本部」)や暗黙の関係の取りこぼしが起きます
- 正規化・名寄せ(重複解決): 同じ実体を指す別表記を 1 つにまとめる工程が最も難しく、最も品質を左右します。名寄せを誤るとグラフが分断・混線し、たどれなくなります
- 精度は完璧にならない: LLM 抽出のグラフには誤り・欠落が必ず残ります。「グラフがあるから正確」ではなく、抽出品質を評価し、重要部分は人手で確認する前提で設計します
- コストがかかる: 大量文書を LLM で処理する構築コストと、更新のたびの再抽出コストは無視できません
GraphRAG の型
GraphRAG(グラフを検索に使う RAG)には主に 3 つの型があります。
| 型 | 仕組み | 向く場面 |
|---|---|---|
| エンティティ検索 + グラフ辿り | 質問からエンティティを特定し、そこから関係をたどって関連情報を集める | 「A と関係するものは」「A から B への経路」 |
| コミュニティ要約型 | グラフをコミュニティ(密につながった塊)に分け、各塊の要約を事前生成しておき、全体的な問いに答える | 「全体の傾向は」「主要なテーマは」 |
| ベクトル検索との併用 | 通常のベクトル検索の結果を、グラフの関係でたどって補強する(ハイブリッド) | 事実検索 + 関係の補完 |
実務では③の併用が現実的な出発点です。通常の RAG を土台に、関係をたどる部分だけグラフで補う構成なら、全面グラフ化のコストを避けられます。
向く質問と向かない質問
GraphRAG が効くかどうかは、質問の型で決まります。
- 向く質問: 「A と B の関係は」「A に依存しているものを全部」「この規定を参照している文書は」といった多段の関係をたどる問い。「全体でいくつあるか」「主要なカテゴリは」といった集約・俯瞰の問い(ベクトル検索は断片しか返せず、全体を数えられません)
- 向かない質問: 「◯◯の手順は」「エラーコード X の意味は」といった単純な事実検索。これらは通常の RAG のほうが速く・安く・正確です
判断の要点は、**「グラフでしか解けない質問が、実際にどれだけあるか」**です。ユーザーの実際の質問ログを見て、関係たどり・集約の質問が主要な割合を占めていなければ、グラフの投資は回収できません。
構築・維持コストと「本当にグラフが要るか」
GraphRAG の最大の論点はコストです。
- 構築コスト: 抽出・名寄せ・スキーマ設計。文書量に比例します
- 維持コスト: 文書が更新されるたびにグラフを更新する必要があります。エンティティ・関係の追加削除、名寄せのやり直しは、通常の RAG の再インデックス(埋め込みの選定と運用)より複雑です
- スキーマ変更の波及: 「こういう関係も持ちたい」となるとスキーマ変更が発生し、既存グラフの作り直しにつながります
- 判断: 通常の RAG で失敗している質問を洗い出し、そのうち「関係たどり・集約」が本質的な割合を占め、かつグラフの維持コストを払う価値があると確認できてから導入します。多くの場合、通常の RAG の改善(ハイブリッド検索・メタデータ・チャンク設計)のほうが費用対効果が高いです
評価
GraphRAG も、感覚でなく評価で判断します。
- 通常の RAG との A/B: 同じ質問セットで、通常の RAG と GraphRAG を比較します。グラフが本当に効いている質問の割合を測ります(評価データセットの構築と保守)
- グラフ自体の品質: 抽出したエンティティ・関係の正確性を、サンプルの人手確認で測ります。グラフが誤っていれば、それに基づく回答も誤ります
- コスト対効果: 精度の向上と、構築・維持コスト・レイテンシを併せて見ます。わずかな精度向上のために大きな維持コストを払う構成は、実務では割に合いません
実務での注意点
アンチパターン
- 通常の RAG で足りるのに GraphRAG を導入する → 大きな構築・維持コストを払って、単純な事実検索はむしろ遅く・複雑になる → 質問ログで「関係たどり・集約」が本質的な割合か確認してから検討する
- LLM 抽出のグラフを「正確」と信じる → 抽出・名寄せの誤りが回答の誤りになる → 抽出品質を評価し、重要部分は人手確認する
- 名寄せ(重複解決)を軽視する → 同一実体が分裂してグラフがたどれなくなる → 名寄せを構築の最重要工程として設計・評価する
- グラフの更新運用を設計せずに構築する → 文書更新に追従できず、グラフが陳腐化する → 維持(更新・名寄せのやり直し)のコストを最初に見積もる
- 精度向上だけで採否を決める → 維持コスト・レイテンシを見落とす → コスト対効果で通常の RAG 改善と比較する
チェックリスト
- 通常の RAG で失敗している質問を洗い出し、その型(関係たどり・集約か)を確認した
- グラフでしか解けない質問が、実際の質問ログで本質的な割合を占めると確認した
- スキーマ(エンティティ型・関係型)を、緩さと精度のトレードオフで設計した
- 抽出・名寄せの品質を評価し、重要部分の人手確認を設計した
- グラフの更新・維持(文書更新への追従)の運用とコストを見積もった
- 通常の RAG との A/B で、グラフが効く質問の割合を測った
- 精度だけでなくコスト対効果(維持コスト・レイテンシ込み)で採否を判断した
関連トピック
- RAG 実装パターン — 通常の RAG(まずこちらで足りるかを判断する前提)
- RAG と Agent の関係・使い分け — 検索構成の選択
- 埋め込み(embeddings)の選定と運用 — ベクトル検索併用型で使う埋め込み層
- LLM 向けデータ前処理パイプライン — グラフ構築の入力となるデータの整備
- 評価データセットの構築と保守 — 通常の RAG との A/B 評価
- 構造化出力 — LLM にエンティティ・関係を三つ組で抽出させる形式強制
参考資料
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization — グラフをコミュニティに分け全体的な問いに答える GraphRAG の代表的アプローチ(アクセス日: 2026-07-08)