Graph-based Retrieval-Augmented Generation
断片の類似検索では届かない「関係」と「全体像」を、エンティティとエッジのグラフに構造化して扱う。GraphRAGの原理・仕組み・特徴、そして知財業務への活用を一枚に整理したリファレンス。
§01 なぜGraphRAGが必要か
GraphRAGを理解する鍵は、それが解こうとした従来RAG（VectorRAG）の構造的欠陥を先に押さえることにある。標準的なベクトルRAGは「文書をチャンクに分割 → 埋め込み → クエリに類似したtop-kチャンクを取得 → LLMへ渡す」という流れだが、ここに二つの限界がある。
知財の文脈で言えば、「ある基本特許の理論が、別ファミリーの実施例とどう関係し、第三の技術分野にどんな含意を持つか」という問いがまさにこれだ。VectorRAGは各トピックに最も近いチャンクを返すだけで、残りはLLMがハルシネーションで埋めがちになる。GraphRAGは、この「関係」と「全体像」を明示的なグラフとして持つことで応える。
§02 全体構造
GraphRAGは2024年4月にMicrosoftが提唱したもので、一文で言えばグラフ構造を活用したRAGの強化版。処理は「グラフ作成（インデックス化）」と「クエリ（Local / Global / DRIFT）」の二段に分解できる。
最も重要な設計思想は非対称性だ。重い意味処理（読み込み・エンティティ抽出・要約）をすべてインデックス時に前倒しし、繰り返されるクエリ時を安価にする。コミュニティのサマリーはクエリ時ではなくインデックス時に生成される——これがGraphRAGの中核的な仕掛けである。
§03 インデックス（グラフ構築）の原理
ここがGraphRAGの心臓部。文書からエンティティ・関係をLLMが抽出してグラフを組み、密結合したノード群をコミュニティに束ね、各コミュニティに要約を付けて埋め込む。5段階のパイプラインとして流れる。
Indexing pipeline
従来のグラフクエリはグラフ全体を走査するため、数百万ノードでは最適化しても遅い。コミュニティ検出は意味クラスタを事前計算する。ほとんどのクエリは局所的で、特定のサブシステムやトピックに関わる。コミュニティ検出はその局所性を明示化し、人間がドメインを「システム内のサブシステム、主題内のトピック」として階層的に捉える構造に対応させる。
結果として得られるのは、ベクトル検索とグラフ走査の両方を支えるハイブリッド検索層だ。ベクトルで開始点を見つけ、グラフで関係を探索する——純粋なベクトル検索でも純粋なグラフ走査でも不十分で、両者の組み合わせが本質になる。
§04 クエリ（検索）の原理
特定エンティティ中心の問い向け。クエリ内の関連エンティティを特定し、そのグラフ近傍（kホップ以内）へ展開して関連チャンクを集める。「この発明者が関わった技術系譜は」のような具体的な問いに強い。
データセット全体の理解を要する問い向け。コミュニティサマリーをMapReduce的に評価・再ランクし、俯瞰的な回答を生成する。「全特許群を通じた主要トレンドは」のような“森を見る”問いに対応。
2024年後半に追加された、LocalとGlobalを組み合わせる手法。あわせて動的コミュニティ選択など、安価なLLMで関連性判定を行い総トークンコストを下げる最適化も導入されている。
§05 特徴の整理
| 観点 | GraphRAG | 標準 VectorRAG |
|---|---|---|
| 大域的・俯瞰的な問い | 強い（コミュニティサマリー） | 弱い（窓を超える） |
| マルチホップ推論 | 可能（グラフ走査） | 困難（孤立チャンク） |
| 出典・根拠の追跡 | 高い（グラフに接地） | 限定的 |
| インデックスコスト | 非常に高い | 低い |
| 更新の容易さ | 重い（コミュニティ再構築） | 軽い |
| 実装の複雑さ | 高い | 低い |
強みの核心は、大域的な問いを巧く扱い、データセットが大きくてもスケーラビリティ問題に陥らず、グラフインデックスに情報を接地することでソース引用（出典追跡）が可能で解釈可能性が高い点。最後の一点は、根拠が問われる知財領域で決定的に重要になる。
弱みは率直に言ってコストだ。グラフの構築とクエリに複数のAPI呼び出しを要し、応答が遅くレート制限に当たりやすく、法外に高価になりうる。ある研究では1回の検索に約610,000トークンを要したと報告され、Microsoft自身も「小さく始める」ことを推奨している。加えて、同一エンティティが異なる名前で抽出されるエンティティ解決品質の課題も残る。
§06 軽量バリアント
コスト問題への回答が、2025年に普及したLightRAG等だ。コミュニティ走査を完全に回避し、ベクトルでエンティティと関係を直接取得して構造的文脈のためだけにグラフを使う。インクリメンタル更新は全体を再構築せず、新ノード・エッジを追加するだけで済む。
コスト差は劇的だ。GraphRAGで $4〜7 かかる文書処理が、LightRAGでは約 $0.15 で済むとの報告がある。LightRAGは法律データセットで特に優れた性能を示すとされ、構造化された規範文書を扱う知財・法務との親和性を示唆している。
使い分けの指針はシンプル。因果・依存関係・文書横断の統合を要する問いならLightRAGが好適、小規模データや単純な事実検索なら標準RAGで十分。フル機能のGraphRAGは、コーパス全体の俯瞰的洞察が繰り返し必要で、かつインデックスコストを正当化できる規模・用途に限るのが実務的だ。
§07 知財業務への活用
特許の前方/後方引用、ファミリー、出願人の系譜は本質的にグラフ構造を持つ。VectorRAGだけでは「似たクレームの断片」しか返せないが、グラフ層を足すと関係構造そのものを辿れるようになる。適用先を4つの角度から整理する。
「ある基本特許の周辺を、誰がどう設計回避してきたか」の追跡はマルチホップ推論の問題。引用1〜2ホップのLocal Searchで“設計回避系譜”を可視化できる。設計プリミティブ ⟨C/K|M|R⟩ の連鎖追跡と直結する。
「業界全体として、どの技術的課題が未解決のホットスポットか」は個別チャンク検索では答えられない大域的問い。Global Searchが効き、コミュニティ検出は課題×時系列マップのクラスタを半自動生成しうる（taxonomy生成の足がかり）。
大量特許全文にフルGraphRAGはコスト非現実的になりやすい。ローカル推論基盤（Mac mini + Ollama等）ならAPIトークン課金を回避でき、インデックスコストの壁を実質的に下げられる。重要サブセットのみフル、他は軽量、の二層運用が妥当。
出願人・発明者名寄せで「同一エンティティの別名抽出」問題が顕在化する。グラフ構築段階の判定根拠を必ずリネージとして残す設計を——係争・監査で「なぜ同一権利者と判定したか」を再現できる状態を、ベクトル層とグラフ層の両方で一貫して保持する。
いきなりフルGraphRAGを組むより、まず重要特許サブセットでLightRAG的な軽量グラフを立て、引用1〜2ホップのLocal Searchで“設計回避系譜”の可視化が機能するかを検証。価値が確認できてからGlobal Searchとコミュニティ検出へ拡張する——という段階導入が堅実。
※ 数値（コスト・トークン量・精度低下率）は公開ベンチマーク／実測レポートに基づく参考値であり、モデル・コーパス・設定に依存する。実運用前に自環境での検証を推奨。