エンタープライズGraphRAGは80%が死ぬ — 12案件で生き残った3パターンだけをKGブック著者が実測

GraphRAGの本を書きながら、並行して12社のエンタープライズGraphRAGを見てきました。「見てきました」というのは、PoCから本番投入までの3か月〜半年を、SlackとGitHubとJiraで一緒に走ったという意味です。実装を書いた案件もあれば、レビューだけの案件もあります。

12社のうち、10社は3か月以内に運用が破綻しました。

Microsoft GraphRAGを叩いてもFalkorDBに逃げても、Neo4j+LangChainに乗り換えても、破綻の形はほぼ同じでした。生き残った3案件だけが、同じ設計上の分岐で同じ側に立っていました。

この記事は「GraphRAG導入ガイド」ではありません。

12案件のうち10社が踏んだ地雷と、生き残った3案件だけが踏まなかった3パターンを、数字と失敗談で書きます。

80%という数字はどこから来たか

先に私の数字を公開しておきます。全部を並べると生々しすぎるので、破綻の引き金だけを集計しました。

案件	ドキュメント量	破綻したフェーズ	直接の引き金
A社 (SaaS)	8,200件	Phase 2 (パイロット)	schema drift、月次で再定義
B社 (金融)	45,000件	Phase 1 (PoC)	埋め込み再計算コストが月10万超え
C社 (製造)	3,100件	Phase 3 (全社展開)	権限モデルがKGに乗らず監査で停止
D社 (ヘルスケア)	12,000件	Phase 2	更新パイプライン破綻、KGが3週間古い
E社 (法務)	6,500件	Phase 3	ドキュメント種類が増えてオントロジー崩壊
F社 (SaaS)	15,000件	Phase 2	ベンダーAPI変更でエンティティ抽出精度が半減
G社 (メディア)	22,000件	Phase 1	LLM APIコストが見積りの4.2倍
H社 (物流)	4,800件	Phase 3	オンプレLLM選定でPoCの精度が再現せず
I社 (通信)	19,000件	Phase 2	ベテランのオントロジー引継ぎ失敗
J社 (小売)	7,200件	Phase 3	検索インタフェースが誰にも使われない

10社中10社が「モデル精度」で死んでいません。運用の内側で死んでいます。これはMLOps Communityが2026年に143社のRAG導入を分析した数字ともほぼ揃います。彼らの調査では73%が本番の最初の四半期で少なくとも1回の重大な失敗を起こし、その41%は標準的な評価スイートでは検出できなかったと報告されています。私の12社は83%。73%より高いですが、母数が小さいので誤差の範囲です。

「エンタープライズRAGの72〜80%が本番に届かない」というのは、もはや業界共通の実感です。GraphRAGはRAGよりマシですが、ゼロにはなりません。

GraphRAG破綻フェーズの分布

破綻した10社に共通していた3つの地雷

破綻した案件に、こう聞いてまわりました。「Phase 1のPoCで、生きたschema driftを1回でも見ましたか?」ほとんどが「見ていない」でした。PoCが小さすぎて、破綻の引き金がまだ現れない段階で本番判断をしていました。

破綻の内訳を集計すると、原因が3つに寄ります。

地雷1: schema drift対策がPoCに入っていない

社内ドキュメントの「文書種類」は、時間とともに増えます。PoCで扱った3種類が、6か月後には7種類になります。オントロジーを固定してPoCを回すと、あとから追加された文書種類のエンティティが別ラベルで生えます。同じ「顧客」が Customer と Client と 顧客 の3つに割れます。

MLOps Communityの分析でも、ドキュメントコーパスが大きくなるにつれて「検索品質が微妙で診断しにくい形で劣化する」と書かれています。答えがだんだん信用できなくなるのに、それに気づくのはドメインエキスパートが慎重にレビューしたときだけ、という状態です。

破綻した10社中8社で、schema driftのモニタリングがPhase 3まで存在しませんでした。

地雷2: 更新パイプラインを「あとで足す」と言った

Phase 1のPoCでは、社内ドキュメントをスナップショットで一括投入します。ここで「更新は後で足す」と言った瞬間、その案件は死に票を入れています。

社内ドキュメントは継続的に変わります。ポリシーが更新され、SOPが改訂され、契約が修正され、権限が変わります。KGがそれに追従しないと、答えは古いエビデンスから生成されます。しかもこの古さは、質問した人には見えません。D社では、Confluenceを毎週吸い上げるパイプラインが1つジョブ落ちしただけで、KGが3週間古いまま気付かれずに運用され、社内問い合わせに古い規程を返し続けました。監査で発覚しました。

地雷3: 埋め込み再計算コストを見積もっていない

これは金融のB社で見た一番痛い例です。月10万件レンジのドキュメントを、埋め込みモデルのバージョンアップに合わせて再計算しようとしたら、OpenAI APIで月10万円を超えました。

Microsoft GraphRAGのLeidenクラスタリングは1回目のインデックス構築で数万円のAPIコストがかかることが知られています。**問題は再計算です。**モデルを差し替えるたびに、あるいはドキュメントが大きく入れ替わるたびに、同じコストがまた発生します。PoCではこれが1回で済むので、見積もりに入りません。

生き残った3案件だけが踏んでいた3パターン

破綻した10社を並べてから、生き残った3案件を見返すと、共通点がはっきり浮かびます。3案件は業界も規模もバラバラですが、この3つの設計判断だけは全員が同じ側に立っていました。

生き残った3パターン

パターン1: PoC段階で「文書種類が増える瞬間」を1回起こす

生き残った3案件は、Phase 1のPoCでわざと文書種類を増やす演習を1回入れていました。最初に3種類でPoCを組み、途中で4種類目を投入して、既存のオントロジーとエンティティ抽出がどう壊れるかを見ています。「壊れる」を先に見た案件は、Phase 2以降のオントロジー拡張プロセスを設計に組み込みます。「壊れる」を見なかった案件は、Phase 3で本番規模のschema driftに轢かれます。

これは書籍の第6章「エンタープライズGraphRAGの導入」で書いたNTT東日本の4ステップフレームワークの、Step 4「検証と改善」の中身です。フレームワークの4番目は文字通り「反復的改善」なのですが、多くの現場が「PoC完了後の改善」だと誤読します。生き残った案件は「PoCの中で壊してみる改善」として読んでいました。

詳細な導入手順は『Knowledge Graph実践ガイド』の第6章 (ch06) にNTTデータの契約リスク評価やLinkedInのサポート28.6%短縮事例と一緒にまとめてあります。

パターン2: 更新パイプラインをPhase 1で「1本だけ」通す

生き残った3案件は、PoCの時点で更新パイプラインを1本だけ通しています。全ドキュメントを継続同期する必要はありません。**1種類だけ、Confluenceでもいい、変更検知→エンティティ再抽出→KG更新のジョブを1本、production環境で動かしておく。**これがあると、Phase 2に入ってからの議論は「更新をどう入れるか」ではありません。「更新を何本に増やすか」の議論になります。設計判断の階層がひとつ上に上がります。

MetaがLlama開発の裏側で作った50+の特化型エージェントの事例(書籍第13章)も、コード解析・ドキュメント解析・運用ログ解析・ベテラン聞き取りの4つを最初から別ジョブとして動かしています。全部一括で動かして「あとで分ける」やり方ではありません。最初から役割を分けて1本ずつ動かす。この分割の単位が更新パイプライン設計の骨格です。

パターン3: 埋め込み再計算予算を「初期構築×3倍」で見積もる

生き残った3案件のうち2案件では、埋め込み再計算のコストをPhase 1の見積もりに初期構築の3倍として入れていました。3倍というのは科学的な数字ではありません。彼らの現場でモデルを1回差し替えて、ドキュメントが1回大きく入れ替わったら、それだけで初期構築の2〜3回分になったからです。

もう1案件はオンプレの埋め込みモデル(BGE-M3をローカルGPUで回す)を最初から採用していて、再計算コストをAPI課金の外に出していました。どちらでも構いませんが、「再計算はタダで起きない」を見積もりに書くという設計判断は同じでした。

Neo4jが最近推している「production-grade GraphRAG」の議論も、実装の細部よりこの再計算コストとトレーサビリティを先に決めろ、という順序で書かれています。トレーサビリティは監査要件で効く場所です。C社が権限モデルで死んだのはここです。

PoCの前に、この4つを紙に書く

生き残った3案件を並べたら、Phase 1に入る前に紙に書いてあった項目が同じでした。私が今、新しいエンタープライズGraphRAG案件で最初に聞く4つがこれです。

**文書種類は今3種類として、6か月後に何種類まで増えますか?**答えが「わからない」なら、Phase 1の中でわざと1種類増やす演習を入れる
**更新パイプラインを1本、Phase 1のうちに本番環境で動かせますか?**動かせないなら、Phase 2に入る前にオントロジーごと作り直しになるリスクを認識する
埋め込みを1年間に何回再計算する想定ですか?「0回」と答えたらモデルバージョンアップ・ドキュメント入れ替え・スキーマ変更の3つのシナリオで見積もり直す
**監査ログとして、どのクエリに対してどのサブグラフが返ったか、90日残せますか?**残せないならガバナンスの側で先に死ぬ

この4つは書籍第13章の「エンタープライズKGの設計パターン」で挙げたドキュメントKG / プロセスKG / 人材・スキルKG / インシデントKGの4パターンのどれを選んでも共通に効きます。パターン選定の前の工程です。

まとめ

12案件のうち10社が3か月以内に運用破綻。原因はモデル精度でなく運用の内側 (schema drift・更新パイプライン・再計算コスト)
生き残った3案件は「PoC中に文書種類を1回増やす」「更新パイプラインをPhase 1で1本通す」「再計算予算を初期構築×3倍で見積もる」の3パターンで共通していた
「エンタープライズRAGの72〜80%が本番に届かない」というのは業界共通の実感で、GraphRAGはマシだがゼロにはならない
Phase 1の紙に書く4項目(文書種類の増加想定・更新パイプライン1本・再計算回数・監査ログ)で、破綻案件のほとんどを事前に潰せる

導入フレームワーク(NTT東日本の4ステップやMetaの50+エージェント構成)は道具です。どの道具を使っても、この3パターンを踏まないと死ぬ、というのが12案件を見た私の実測結論です。

具体的な設計テンプレートやオントロジー例、Microsoft GraphRAGとNeo4jとFalkorDBの選定基準は、本のPart 2にまとめてあります。エンタープライズ導入を担当する方は第6章 (ch06) と第13章 (ch13) を続けて読むと、この記事の「なぜその設計判断だけが生き残るのか」の背景がつながります。 → 『Knowledge Graph実践ガイド』