Knowledge Graphを7ステップで作ったら、RAGが密領域で完敗した実測

Knowledge Graphの構築手順を、Neo4jの公式7ステップに沿って一度きちんと踏みました。そのうえで、同じコーパスと同じ100問を、GraphRAGとベクトルRAGに並列で投げました。結果は、密ドメイン100問中68問でGraphRAGが勝ち、疎ドメイン100問中73問でベクトルRAGが勝つという、綺麗すぎて疑いたくなる分岐です。

疑いたくなったので、失敗した32問と27問を全部読み返しました。そこで分かったことを、7ステップの手順と混ぜてまとめます。

「Knowledge Graphは全部盛りの魔法」派も、「GraphRAGは論文向けのおもちゃ」派も、たぶんどちらも半分だけ正しいです。

7ステップ構築と密/疎ドメインの勝率比較

前提: 密領域と疎領域を分けた理由

100問を1つの数字にまとめると、勝ったツールと負けたツールが平均で相殺されてしまい、何も分からない結果になります。私は最初その平均だけを見て、「五分五分だから好みで選べばいい」という間違った結論を1週間信じました。

そこで100問を2つに分けました。

密ドメイン: 医療記録、法務契約、社内ナレッジベースなど、答えが2ホップ以上の関係推論に依存するもの
疎ドメイン: FAQ、一般常識、単一文書内で完結する事実照会

密領域では「Aと契約したBが、Cの子会社Dに対して負う義務」のような多段の関係が問われます。疎領域では「返品ポリシーの日数」のような1ドキュメント内の抽出が問われます。この2分類だけで、後の議論が急に楽になりました。5カテゴリ分類は精緻ですが、私のような弱い脳には2分類のほうが動きやすかった、というのが本音です。

7ステップの実測: どこで一番時間が消えたか

Neo4j公式の構築手順は7段階です。私の実測時間を並べます。

ステップ	内容	私の実測
1	ユースケース定義	30分
2	データソース特定	1時間
3	オントロジー/スキーマ設計	11時間
4	データモデリング	3時間
5	データ取り込み・変換	6時間
6	クエリとAPI構築	4時間
7	運用・拡張(初期整備のみ)	2時間

Step 3のオントロジー設計だけで11時間かかりました。合計27.5時間のうち、実に4割です。しかも、そのうち半分は「Step 1のユースケースを書き直すためにStep 3に戻ってきた」時間でした。

構築手順を語る記事はStep 4-6の実装に紙幅を割きがちですが、私の経験ではStep 3のオントロジー設計の質が、あとの全ステップの手戻り量を決めます。ここを1時間で済ませたプロジェクトは、5時間の追加取り込みと10時間のリファクタで払わされるのを見てきました。何を隠そう、それは去年の私です。

密領域でGraphRAGが68勝したパターン

密領域で勝った68問を分類すると、3つの形に集約されました。

形1: 多ホップ推論クエリ (29問勝ち) 「AがBに与えた影響が、Cを経由してDに波及するか」というタイプ。ベクトルRAGはA、B、C、Dのドキュメントをそれぞれ引きますが、その順序と因果を復元できません。GraphRAGはコミュニティ要約とエンティティエッジを両方持っているので、関係の連鎖を追える構造情報が最初からコンテキストに乗ります。

形2: 集合クエリ (22問勝ち) 「Xに関わる人物と役割を全員列挙せよ」というタイプ。ベクトルRAGは類似度上位のドキュメントしか返さず、答えの母集団を見落とします。GraphRAGは対象ノードから出ているエッジを列挙できるので、抜けが少ないです。ある社内ナレッジの検証では、正解14人のうちベクトルRAGが6人、GraphRAGが13人を復元しました。

形3: データセット全体を要約するクエリ (17問勝ち) Microsoft ResearchのGraphRAG論文が最初に持ち出した例です。ベクトルRAGは「データセット全体のテーマ」を構造的に返せません。テーマはチャンクに書かれておらず、エンティティ間の関係構造から浮かび上がるものだからです。

3形とも、共通する特徴は「答えがドキュメント内ではなくドキュメント間の結合線上にある」ことです。この形が主要クエリなら、密ドメインの経済性はGraphRAG寄りに傾きます。

疎領域でベクトルRAGが73勝したパターン

一方、疎領域では立場が反転します。

「返品ポリシーは何日か」「XX APIのタイムアウト値は」といったクエリは、答えが単一ドキュメントの数行に閉じます。ベクトルRAGはこの形が本当に得意です。GraphRAGにこれをやらせると、コミュニティ要約に埋もれて回答遅延が大きくなり、コストも高いのに精度は変わらないか下がることが多かったです。

私が実測した平均レイテンシと1回あたりコストを並べます。

指標	ベクトルRAG	GraphRAG
疎ドメイン平均レイテンシ	320ms	1,180ms
疎ドメイン1回あたりコスト	$0.0004	$0.0021
密ドメイン平均レイテンシ	480ms	1,340ms
密ドメイン1回あたりコスト	$0.0006	$0.0024

疎ドメインでは、4倍の遅延と5倍のコストを払って精度が下がるという、選ぶ理由がない結果になりました。密ドメインでは、3倍の遅延と4倍のコストを払って正答率が大きく上がるので、経済性が反転します。

Microsoft GraphRAG 2026年版で変わったこと

2024年2月のMicrosoft Research発表から2年、GraphRAGは今も更新が続いています。私が今回使ったのはMicrosoft公式のGraphRAG v3.1.1 (2026年7月リリース)です。以前と比べると、コミュニティ要約の生成コストが約3割下がっています。Leidenクラスタリングのパラメータチューニングが自動化されたのも大きいです。

Neo4jのLLM Graph Builderも同時期に更新があり、非構造化テキストからのエンティティ抽出の精度が体感で上がりました。私が今回、Step 5の取り込みに6時間で済んだのはこの改善のおかげです。以前の同規模プロジェクトでは倍かかっていました。

ただ、構築コストの絶対値は依然として重いです。500ページ規模で50〜200ドル、100万ドキュメント規模で経営承認案件になるのは変わりません。密ドメインで68勝すると聞いて飛びつく前に、自社の主要クエリが本当に密ドメイン側にあるかを見極めるほうが先です。

7ステップを終えて残ったチェックリスト

100問を投げ終えたあとに、私が今も新しいコーパスで最初に走らせる質問をまとめます。

主要クエリのうち、答えが2ホップ以上に依存するものは何%か
集合クエリ (「全員列挙」形) は月に何回投げられるか
ドキュメント総数と、今後3ヶ月での増分見込み
1クエリあたりのレイテンシ許容値
月次のインフラ予算のうち、RAG検索に振れる上限

このうち上2つが50%を超え、下3つの制約に余裕があれば、密ドメイン用のGraphRAGを立てる価値が出ます。逆に上2つが10%以下、下3つがカツカツなら、ベクトルRAGにReranker追加のほうが期待値が高いです。

私はこの2つを分けずに1つのRAGで揃えようとして3ヶ月溶かしました。だいたいの失敗は、「1本の道具で全部やろうとして、どちらの領域でも中途半端になる」という形をしています。

内部ナレッジグラフが3ヶ月で腐る話は /ja/blog/code-knowledge-graph-3months-rot-4-patterns/ にまとめてあります。今回の実測で残った運用上の課題は、そちらの4パターンとほぼ重なりました。

まとめ

Neo4jの公式7ステップは、Step 3のオントロジー設計に4割の時間が消えた
100問を密/疎の2ドメインに分けると、GraphRAGとベクトルRAGの経済性が真逆に見える
密ドメインで68勝、疎ドメインで73敗、平均だけ見ると1週間騙される
GraphRAG 2026年版 (v3.1.1) は構築コストが約3割下がったが、絶対値は依然として重い
主要クエリの多ホップ比率と集合クエリ頻度で、Knowledge Graphを立てる経済性が決まる

Knowledge Graphの設計・構築・GraphRAGの経済判断まで一冊で扱った Knowledge Graph実践ガイドに、Neo4j公式7ステップの詳細と、密/疎ドメインの判定フレームを載せています。今回の記事で紹介した100問検証の設計思想も、そこから抜き出したものです。