GraphRAGガイド：ナレッジグラフがベクトルRAGに勝つとき、負ける

GraphRAGガイド：ナレッジグラフがベクトルRAGに勝つとき、負ける

GraphRAGは死んでいませんが、デフォルトの選択肢でもありません。microsoft/graphragは2026年7月18日にv3.1.1をリリースし、GitHubスター数は35,088に達しています。そして2026年のベンチマーク論文3本が、プレーンなベクトル検索に頻繁に負けることを堂々と報告しています。つまり、このGraphRAGガイドが答えるべき問いは一つだけです。ナレッジグラフはインデックスコストに見合うのか、ということです。

GraphRAGを使うべきか？結論から

質問がエンティティをまたぐ場合、あるいはコーパス全体にまたがる場合にGraphRAGを使ってください。「最大の顧客が同時に販売しているサプライヤーはどこか？」のような問いです。シングルホップの事実検索、頻繁に更新されるドキュメント、レイテンシ予算が厳しい場面では、バニラRAGまたはハイブリッドRAGのままにしてください。グラフがコストを回収できるのはマルチホップの質問だけで、それ以外では費用が増えるだけです。

GraphRAGは死んでいませんし、デフォルトでもありません。質問がマルチホップまたはコーパス全体にまたがる場合にインデックスコストを回収でき、そうでない場合は損失になります。

要点をまとめると：

• GraphRAGはマルチホップとコーパス全体の質問で勝ち、バニラRAGはシングルホップの検索で勝ちます。
• 2026年のベンチマークはまちまちです。グラフは集計に役立ちますが、細かい要約の精度を下げる場合があります。
• コストはクエリ時ではなくインデックス時に発生します。LLMの抽出呼び出しが原因です。
• 何かを構築する前に、まず自分のコーパスでBasic Searchをコントロールとして実行してください。

すでに動作するベクトルRAGパイプラインを運用している場合、判断すべきはその上にグラフを載せる価値があるかどうかだけです。下のテーブルがその議論の全体を6行で示しています。バニラのままにすべきと書かれている行は、ベンダーが認めるよりも正直な答えです。BM25とベクトルのハイブリッド検索は、グラフなしでこれらのケースの大半をカバーします。

GraphRAGとは何か：チャンクからコミュニティへ

GraphRAGは、バラバラのチャンクではなくナレッジグラフに対する検索拡張生成です。インデックス時にLLMがドキュメントからエンティティと関係を抽出し、Leidenアルゴリズムがそれらのエンティティをコミュニティにグループ化し、各コミュニティに要約が付与されます。クエリ時に、グラフとその要約が、チャンクに対するtop_kウィンドウでは構造的に回答できない質問に答えます。

パイプラインの全体像：

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

2つのフェーズが処理を担います。インデックスフェーズが高コストな側です。すべてのチャンクに対してエンティティと関係を抽出するLLM呼び出しが発生し、コミュニティ要約にも追加の呼び出しが必要です。クエリフェーズにこそリターンが現れます。グラフが関係を明示的に保存するため、「最大の顧客が同時に販売しているサプライヤーはどこか？」という質問は、正しい2つのチャンクが同じtop_kウィンドウに入ることを祈るのではなく、走査になります。

要約が重要なのは、Global Searchが実際に読むのがそれらだからです。コーパス全体の質問は、生のチャンクではなく事前に書かれたコミュニティの文章から回答されます。そしてすべてのエッジはLLMの判断であり、実際のグラフデータベースでCypherでクエリできるトリプルとして保存されます。この設計こそがインデックスコストが支配的になる理由であり、以下の数値がそれを具体的に示します。

本質を捉えるなら、バニラRAGはパッセージを検索し、GraphRAGは構造を検索します。埋め込みモデルの選択はベクトル層にとって依然として重要であり、ベクトルデータベースは説明を保存し続けますが、グラフが新しい荷重部材です。公式のIndex Overviewドキュメントが各ステージを詳しく説明しています。

GraphRAGの4つのクエリメソッドとは？

GraphRAGのクエリエンジンは4つのメソッドを提供します。Local Search、Global Search、DRIFT Search、Basic Searchです。Local Searchは特定のエンティティから外側に推論し、Global Searchはコーパス全体でコミュニティ要約を集計し、DRIFT Searchは両方を再帰的にブレンドし、Basic Searchはプレーンなベクトルベースラインです。5つ目の機能であるQuestion Generationは、エンジンと並列ではなくその上に位置します。

2026年7月30日にmicrosoft.github.io/graphrag/query/overview/のライブドキュメントを確認したところ、メソッド数は4つでした。多くのランキングガイドは2つか3つしか挙げていません。同じ確認で、IndexとQueryの両方の概要ページに「lazy」という単語がゼロ回しか出現しないことも分かりました。これは以下のコストセクションに関係します。

注目すべきは最後の行です。Basic Searchは組み込みのバニラベクトルベースラインであり、自分のコーパスでグラフとプレーンな検索をA/B比較して、グラフがコストに見合っているかを検証するために存在します。これは些細なことではなく、このガイドの意思決定手順全体が1つの機能に凝縮されています。まずBasic Searchを実行してください。実際に受ける質問に対してLocal、Global、DRIFTのいずれもBasic Searchを上回らなければ、グラフはアップグレードではなくコストです。

2026年のベンチマークは何を発見したか？

2026年のベンチマーク論文3本は、GraphRAGがマルチホップおよびマルチファクト集計タスクで有効だが、それ以外ではバニラRAGを下回ることが多いと報告しています。そのうちの1本は、グラフが負ける場所を特定するためにベンチマークを構築しました。3本すべてが、勝敗はコーパスサイズではなく質問タイプに依存すると結論づけています。エビデンスは、GraphRAGが状況依存的でありデフォルトではないことを示しています。

4つ目の取り組みとして、GraphRAG-Bench（リポジトリ）は16分野と20の教科書にわたって9つのGraphRAGメソッドを評価し、より広い角度から同じ結論に到達しています。

3本の論文すべてが一点で収束します。グラフはマルチホップ集計でコストを回収し、細かい想起では損失になるということです。

私たちの読み：ハイプサイクルがダメージを与え、これらの論文がその修正です。どれもグラフが無用だとは言いません。一貫して述べているのは、GraphRAGをコーパス全体のテーマに強くする集計ステップが、そのまま細かい詳細をぼかすステップでもあるということです。WildGraphBenchが最も明確な例です。グラフは中程度のソース数からのマルチファクト集計を助け、同じ評価内で要約の精度を下げました。これは矛盾ではなく、1つのメカニズムが2回現れているだけです。

実務上の帰結は、文献だけでは判断できないということです。論文はテストすべき質問タイプを教えてくれますが、あなたのコーパスがそのいずれに該当するかは教えてくれません。それこそが、上記メソッドセクションのBasic Searchコントロールの役割です。

GraphRAGのコストはどれくらいか？（LazyGraphRAGの注意点を皆が間違って繰り返す件）

GraphRAGのコストはインデックス時の請求であり、クエリ時のものではないからこそ、人々を驚かせます。すべてのチャンクからエンティティと関係を抽出するLLM呼び出し、さらにコミュニティ要約のパスが、高価にしている原因です。クエリが1回も実行される前に、前払いで支払います。クエリ時は安くなりますが無料ではありません。Global SearchはコミュニティごとにLLM呼び出しでファンアウトするため、上記のメソッドテーブルで「高」とマークしています。

公開されている唯一のハードな数値はMicrosoft Research由来です。2024年11月25日、チームはLazyGraphRAGのインデックスコストがベクトルRAGと同一であり、フルGraphRAGの**0.1%**であると報告しました。また、GraphRAGグローバル検索のクエリコストの4%で、テストした競合メソッドをローカル・グローバル両方のクエリタイプで上回りました（Microsoft Research）。これらはMicrosoftのブログに掲載されたMicrosoftの数値であり、そのように報告しています。私たち自身が価格付きのインデックスを実行したわけではありません。

ここで、多くの記事が見落としている修正です。LazyGraphRAGはpip installのオプションではありません。Microsoft自身の2025年6月6日の編集者注記によれば、Microsoft DiscoveryとAzure Localに搭載されたものであり、オープンソースパッケージには含まれていません。2026年7月30日に公式のIndex OverviewとQuery Overviewページを確認したところ、両ページに「lazy」という単語はゼロ回しか出現しません。つまり、LazyGraphRAGを今日午後にも起動できるバリアントとして挙げているガイドは、オープンソースの世界ではもはや真実でない主張を繰り返しています。

今日できること：抽出モデルをローカルで実行する。Ollama経由でローカルモデルにインデックスステップを向けることで、最も高価なフェーズからトークンごとのAPI料金を除去でき、セルフホストのベクトルストアと組み合わせれば、残りのコストをほぼゼロに抑えられます。

実際にメンテナンスされているGraphRAGライブラリはどれか？

最も引用される6つのGraphRAGライブラリのうち2つは、6ヶ月と9ヶ月プッシュがありません。2026年7月30日にGitHub APIからこれらの数値を取得しました。以下のセンサスは、古いまとめ記事が省略する確認であり、コミットする前に再実行するコマンドも記載しています。LightRAGとmicrosoft/graphragがアクティブなもので、nano-graphragとfast-graphragはアバンダンウェアに向かっています。

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

私たちの読み：スター数は虚栄の指標であり、プッシュ日が重要な数値です。LightRAGとmicrosoft/graphragはどちらも活発にメンテナンスされており、Graphitiがテンポラルグラフの角度で続いています。nano-graphragとfast-graphragは、古い記事が評判だけで推薦し続けている2つであり、どちらも半年間リリースがありません。

選び方：4つの公式クエリメソッドを備えたリファレンス実装が欲しければmicrosoft/graphrag、最もアクティブなプロジェクトと軽いフットプリントが欲しければLightRAG、すでにそのベンダーのデータベースを運用しているならneo4j-graphrag-pythonのようなベンダーメンテナンスのライブラリを選んでください。最終プッシュがプロジェクトより半年古いものは避けてください。

Graphitiにはスコープを限定した注記が必要です。そのテンポラルグラフ設計は時間認識データに対する検索のために構築されており、エージェントメモリと重複します。これについてはGraphitiとテンポラルグラフメモリのガイドで別途カバーしています。より広い分野については、RAGツールランドスケープを参照してください。

200日目以降に壊れるもの：グラフドリフトと再抽出

グラフドリフトはローンチ後に支払う税金であり、実務者が第一に挙げる反対理由には根拠があります。すべてのチュートリアルはグラフを一度構築するものとして扱います。実際のチームは200日目で詰まります。

3つのものが劣化します。第一に、ドキュメント更新時の再インデックス。40件のドキュメントが変更された場合、それらを再埋め込みするだけでは不十分です。変更されたチャンクに対してLLM抽出を再実行し、新しいエンティティを既存のグラフと照合し、影響を受けるコミュニティとその要約を再計算する必要があります。あるMediumガイドはインクリメンタル更新を簡単と呼びます。r/Ragの実務者は同意しません。約600件のドキュメントに対してBM25+BGE-M3を運用している2026年4月25日のスレッドの投稿者は率直に述べています。「LLMベースのエンティティ/関係抽出はノイズが多く、ドキュメント更新時の再インデックスは辛そうだ。」

第二に、エンティティ解決の劣化。「Acme Corp」「Acme」「ACME Corporation」が数ヶ月間隔で異なるドキュメントに登場し、本来1つであるべきものが3つのノードに分裂します。自動的にマージするものはありません。

第三に、抽出時には正しかった関係が、静かに正しくなくなること。reports_toエッジが古くなってもアラートは来ません。

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

コードベースは最悪のケースであり、最も興味深いケースです。オートコンプリートは今や「graphrag for codebase」「graphrag claude code」「graphrag mcp server」を候補に出しており、コードベースは毎時変わるグラフです。コミットごとに呼び出しエッジが書き換えられ、シンボルが移動し、関数が削除されます。これはナイトリーの再インデックスでは完全に追跡できないスケジュールのグラフドリフトです。だからこそ、真剣なコードグラフツールはtree-sitterやLSPのような決定的パーサーにエッジを任せ、LLMはその周囲の文章、つまりdocstring、コミットメッセージ、レビュースレッドに限定します。リポジトリをグラフ化するなら、動きの遅い層をLLMで、動きの速い層をパーサーでグラフ化してください。

開発者はGraphRAGについて実際に何を言っているか？

現役の開発者は意見が分かれており、Googleもそれを認識しているようです。「graphrag vs rag」で2位にランクインしているRedditスレッドがあり、これは検索エンジンがこのトピックにベンダーのコピーではなくピアの意見を求めていることを示しています。

懐疑は現実です。r/Ragの2024年スレッド「常に（ナレッジ）グラフRAGを通常のRAGより推薦しますか？」（10ポイント、86%アップボート）で、u/EncartaItはこう書いています。「見つけたチュートリアルはすべて過度に単純化されていて、ナレッジグラフパターンの強い根拠を示していない。」u/Prestigious_Run_4049はより直接的でした。「グラフRAGはただのハイプだと思う。皆話すのが好きでクールに聞こえるが、実際のユースケースで使っている人はいない。」全員が同意するわけではありません。u/pytheryxは本番環境の経験から、グラフ検索はtop_kが返す以上のチャンクからコンテキストを必要とするリスト型の質問で勝つと指摘しています。彼のホワイトペーパーコーパスは完全な回答に約50チャンクを必要とします。

2026年のスレッドはより穏やかです。u/Popular_Sand2773：「大半のグラフRAGセットアップはスケールでズルをする。標準のベクトル検索やメタデータ検索でシードノードを見つけて、そこから歩き回る。」約3億アーティファクトのシステムを運用するu/ggone20：「スケールでは、実際の質問に答えるためにグラフなしでは文字通りやっていけない。」

私たちの読みは両スレッドで最も鋭い議論と一致します。転換点は質問の複雑さであり、コーパスのサイズではありません。これは上記のベンチマークが発見したことでもあり、ツールをマルチホップ作業にスコープする実務者の側に立ち、死んだと呼ぶ側の立場には立ちません。

Techsyのアプローチ

クライアント構築で私たちが使っているシーケンスは、意図的に退屈なものです。

第一に、ハイブリッド検索の天井を証明する。私たちが聞く「グラフが必要だ」というリクエストの大半は、実際にはチャンキングまたはリランキングの問題が変装したものです。まともなリランカーを備えたBM25+ベクトルパイプラインは、チームが期待する以上に回答します。

第二に、何かを構築する前に、自分のコーパスでBasic Searchをコントロールとして実行する。4つ目のクエリメソッドはまさにそのために存在します。自分のデータで、自分の質問に対して、グラフとA/B比較できるプレーンなベクトルベースラインです。

第三に、測定された質問クラスがそのコントロールに失敗したときだけグラフを構築する。マルチホップまたはコーパス全体のクエリが外れるなら、正当なケースがあります。外れないなら、インデックスコストとドリフトの問題を回避できたということです。

検索スタックにセカンドオピニオンが必要ですか？無料相談はこちら。

著者について

Mert BaturはTechsy.ioの共同創設者であり、チームはB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを提供しています。Techsyチームが実際に本番環境で使用しているLLMツールスタックについて執筆しています。クライアント構築では検索アーキテクチャの意思決定を担当し、ハイブリッド検索で十分なケースと、コーパスに実際にグラフが必要なケースを判断しています。LinkedInでつながってください。

よくある質問

GraphRAGはどのように動作しますか？

GraphRAGはドキュメントをナレッジグラフにインデックスします。LLMが各チャンクからエンティティと関係を抽出し、Leidenアルゴリズムがそれらのエンティティをコミュニティにクラスタリングし、各コミュニティに要約が付与されます。クエリ時にエンジンはグラフとその要約を検索するため、異なるチャンクに存在する事実を接続できます。

GraphRAGはRAGとどう違いますか？

標準のRAGは最も類似度の高いtop-kチャンクを取得してモデルに渡します。GraphRAGは構造を取得します。エンティティ、それらの間の関係、事前に書かれたコミュニティ要約です。その追加構造がマルチホップとコーパス全体の質問への回答を可能にし、同時にインデックスを遅く高価にしている原因でもあります。

GraphRAGはいつ使うべきですか？

質問がエンティティをまたぐ場合、あるいはコーパス全体にまたがる場合に使用してください。サプライヤーの重複質問や、数千件のドキュメントにわたる反復テーマ分析などです。シングルホップの事実検索、頻繁に更新されるコーパス、レイテンシやコスト予算が厳しい場合はスキップしてください。プレーンなハイブリッドパイプラインがすでにその質問クラスに回答できているなら、グラフは価値を加えずにコストを増やします。

GraphRAGは死にましたか？

いいえ、しかしデフォルトでもありません。2026年のベンチマークは、日常的なタスクでバニラRAGを下回ることが多いことを示しており、それがハイプを終わらせました。一方で、マルチホップと集計の質問では依然として勝っています。正直なフレーミングは状況依存的です。GraphRAGは正しい質問タイプに対してコストを回収し、それ以外では損失になります。

GraphRAGのクエリメソッドは何ですか？

公式のクエリエンジンは4つを提供します。エンティティ中心の質問のためのLocal Search、コーパス全体の集計のためのGlobal Search、両方の再帰的ブレンドであるDRIFT Search、プレーンなベクトル検索のBasic Searchです。5つ目の機能であるQuestion Generationがその上に位置します。最も重要なのはBasic Searchです。グラフとA/B比較するコントロールだからです。

GraphRAGのインデックスコストはどれくらいですか？

コストはインデックス時に発生します。すべてのチャンクからエンティティと関係を抽出するLLM呼び出しと、コミュニティ要約が原因です。Microsoft ResearchはLazyGraphRAGのインデックスコストがフルGraphRAGの0.1%であり、ベクトルRAGと同一であると報告しましたが、そのバリアントはMicrosoft製品に搭載されたものであり、オープンソースライブラリではありません。私たち自身が価格付きのインデックスを実行したわけではありません。

OllamaでGraphRAGをローカル実行できますか？

はい。microsoft/graphragライブラリでは、Ollamaがサーブするローカルモデルにインデックスとクエリを向けることができ、抽出ステップからトークンごとのAPI料金を除去できます。コストの代わりに速度と品質をトレードします。ローカルモデルはエンティティ抽出が弱いため、ノイズの多いグラフと、控えめなハードウェアでの長いインデックス実行を想定してください。

LightRAGとMicrosoft GraphRAGはどちらが良いですか？

最適化の対象が異なります。LightRAG（38,353スター、2026-07-30プッシュ）は最もアクティブで実行が軽量です。microsoft/graphrag（35,088スター、v3.1.1）は4つの公式クエリメソッドを備えたリファレンス実装です。効率的な本番グラフにはLightRAG、仕様に忠実な動作とBasic SearchコントロールにはMicrosoftを選んでください。

GraphRAGは誰がいつ作りましたか？

Microsoft ResearchがGraphRAGを作成しました。チームは2024年に論文を発表し、MITライセンスの下でオープンソースのmicrosoft/graphragリポジトリをメンテナンスしています。ドキュメントはmicrosoft.github.io/graphragにあります。リファレンスライブラリは2026年7月18日にv3.1.1に到達し、LightRAGやGraphitiを含むサードパーティ実装のアクティブなエコシステムがその周囲に成長しています。

結論：グラフがコストに見合うとき

エビデンスは一方向を指しています。以下が私たちの立場です。

• GraphRAGは死んでいません。状況依存的であり、2026年のベンチマークがそれを明確に述べています。
• マルチホップのエンティティ質問とコーパス全体の集計でインデックスコストを回収します。シングルホップの検索では損失になります。
• コストはインデックス時の請求であり、皆が引用する安価なバリアントであるLazyGraphRAGは、オープンソースライブラリに到達しませんでした。
• グラフはローンチ後に劣化します。エンティティ解決がドリフトし、関係が古くなるため、再インデックスの予算を確保してください。
• 何かを構築する前に、自分のコーパスでBasic Searchをコントロールとして実行してください。

一文でまとめると、ナレッジグラフは質問がマルチホップまたはコーパス全体にまたがるときにコストを回収し、それ以前には回収しません。検索スタックにセカンドオピニオンが必要なら、無料相談をご利用ください。