GraphRAG企業導入で詰まる3つの壁

「Knowledge Graph実践ガイド」の第6章を書いていて、私はNTT東日本のGraphRAG導入コラム(column-674)を何度も読み返しました。個人のPCでMicrosoft GraphRAGを触っている限り、書けば書くほど「なるほど、動くじゃないか」で完結します。会議室に運ぶ絵を描き始めた瞬間、私はフレームワークの隙間に落ちました。

この記事で書くのは、実務での大規模導入レポートではありません。私は受託先の実務レポートは持っていません。公開ドキュメントを突き合わせて、個人PoCから企業導入へ橋を渡すときにどこが4ステップの間から抜けているかを、自分の頭で3つに整理した話です。ふりだけの実務体験は書きません。

NTT東日本の4ステップは、間違ってはいない

NTT東日本のコラム column-674 は、GraphRAG導入を次の4ステップで整理しています。

この4ステップ自体は破綻していません。むしろ「何から始めるか」の道しるべとして、私が知る限り日本語圏で最も体系的な整理です。私も本の第6章で、同じ骨格を素直に紹介しました。

以下の3つの壁は、私がMicrosoft GraphRAGの公式ドキュメントと、LinkedInの本番導入論文(arXiv 2404.17723)を、この4ステップと重ねながら読んで気づいたものです。NTT東日本の資料に「3つの壁がある」と書かれているわけではありません。 ここは私の解釈です。帰属を分けておかないと、読み手にNTT名義の主張を植え付けてしまいます。

壁1: エンティティ抽出の品質 — Step 2とStep 3の間に落ちる

Step 2「データ整備と前処理」は、PDFやWordの表記統一とメタデータ付与までを扱います。この段階で「機械が処理しやすい形式」にはなります。

ただしGraphRAGの成否は、そこから先の抽出の品質にほぼ支配されます。テキストが綺麗になっただけでは、GraphRAG本体がエンティティと関係をどれくらい正確に取れるかは別問題です。同じ会社名が「株式会社◯◯」と「◯◯」で別ノードに立てば、集計クエリの分母がずれます。エンティティが分散すれば、コミュニティ検出が本来まとまるべき塊を刻みます。

Microsoft GraphRAGは公式ドキュメント上、Standard GraphRAGとFast GraphRAGの2つのインデックス方式を並べています。Standardはtext unitごとにLLMでエンティティと関係を抽出し (claimsはoptional)、FastはNLTKやspaCyの名詞句抽出と共起で置き換える構成です。抽出プロンプトを自分のドメインに合わせて調整するためのAuto Tuningコマンド (graphrag prompt-tune) も公式に用意されています。ただし調整は一発では収束しません。何度か回して、固有名詞の粒度を合わせていく作業です。

問題は、この抽出品質チューニングが4ステップのどこに書かれていないかです。データ整備担当の仕事なのか、エンジン選定担当の仕事なのか、フレームワーク上は空欄です。個人PoCで自分1人で回している間は、暗黙に自分が全部やっているので気づきません。担当を分けた瞬間、この空欄に責任が落ちて、誰も直しません。

壁2: 誰がどのサブグラフを見ていいか — Step 3の前に落ちる

Step 3「検索・生成エンジンの選定」の候補として、NTTのコラムも、私の本の第6章も、Microsoft GraphRAG / Neo4j / Amazon Neptune / Difyといった選択肢を並べます。並べてから思うのは、実は選定より前に決めておかないといけないことがある、ということです。行内アクセス制御です。

Microsoft GraphRAGのGlobal Searchは、公式ドキュメントで「holistic questions about the corpus by leveraging the community summaries」を扱う設計と説明されています。コーパス全体のコミュニティ要約を横断的に見にいく設計です。技術的には強力ですが、社内文書に権限境界がある場合、Global Searchは部門横断で全部見てしまう動きになりがちです。

私が公式リポジトリと公式ドキュメントを読んだ範囲では、GraphRAG本体に行内(row-level)のアクセス制御は組み込まれていません。プライバシーとセキュリティについてはMicrosoft Privacy Statementへのリンクがあるだけで、権限境界の実装ガイドはユーザー側に委ねられています。LinkedInの論文もサポートチケット検索という同一部門内のユースケースであり、部門横断の権限問題には正面から答えていません。

これはStep 3(エンジン選定)より前に、権限境界の設計が終わっている必要があることを意味します。エンジンを選んでから「Global Searchを制限する層を自作する」ことになると、選定基準がその制限に飲まれます。個人PoCで動かしているうちは権限境界がないので、この壁は見えません。ここは、4ステップの並びの外側にひっそり立っている壁です。

壁3: 更新頻度とグラフ再構築 — Step 4の後に控える

Step 4「精度検証と評価・改善」は、パイロット評価とチューニングを扱います。ここまで通れば動くものはできます。ただ、社内文書は日々更新されます。3つ目の壁はここに立ちます。

Microsoft GraphRAGはv0.4.0でIncremental Indexingを導入し、update CLIコマンドで既存インデックスに新規ドキュメントを継ぎ足せるようになりました。差分更新自体はサポートされています。GitHub Discussion #511では、差分更新の要件と一貫性の課題が長く議論されていました (その後Issue #741に引き継がれ、v0.4.0で実装に至っています)。

ただし、コミュニティ検出はグラフ全体の構造に依存するアルゴリズムです。ノードを追加すれば、その周辺のコミュニティ境界は変わりえます。差分更新は「同じIDのノードや関係を消さずに続きから継ぎ足す」ことを可能にしますが、大規模な追加後にコミュニティレポートを再生成する必要が出ることがあり、そこは全体再計算に近い挙動になります。

さらに現時点で、Microsoft GraphRAGの公式リポジトリは「maintenance mode」と明記されていて、新機能追加や大きなPRは積極的に受け付けていません。差分更新の運用ノウハウは、公式が今後磨き込んでくれる期待値を高めにしないほうが安全、というのが私の読みです。この壁も、個人PoCではまず可視化されません。1回インデックスを組んで動く姿を見せて満足するからです。書いていて、しばらく前の自分がそこにいました。

まとめ

NTT東日本の4ステップは、企業導入の道しるべとして正確です。ただし、個人PoCから社内展開に橋を渡すとき、ステップの間と外側に3つの壁が立ちます。

• 壁1: エンティティ抽出の品質(Step 2とStep 3の間)
• 壁2: 行内アクセス制御(Step 3の前)
• 壁3: 更新頻度とグラフ再構築(Step 4の後)

いずれも「フレームワークが悪い」という話ではなく、フレームワークは”何をどの順番でやるか”の骨格で、実装の泥は各社が自分で拾う設計になっています。私がPoCで満足していた自分に気づいたのも、この骨格を読み返して、間と外側に何が抜けているかを書き出してからでした。

関連: Knowledge Graphを7ステップで作る前に、AIエージェントが「見えていない」3層を可視化するは、7ステップの構築フローに入る前段としての可視化ワークです。本記事は、その先の企業導入編にあたります。

本記事の3つの壁と、企業導入で使えるパターンの全体像は、Knowledge Graph実践ガイドの第6章に収録しています。