GraphRAGをAzureで動かす方法｜Accelerator終了後の現行構成と実装手順【2026年版】

「graphrag azure」で最初に突き当たるのが、公式のGraphRAG Accelerator（Azure-Samples/graphrag-accelerator）が2025年5月27日にアーカイブされ、読み取り専用になっているという事実です。増分インデックスにも対応しないまま更新が止まっており、この2026年に新規で採用すべきものではありません。現在AzureでGraphRAGを動かす標準は、Microsoftのgraphragライブラリ（2026年5月時点でv3.1.0）を Azure OpenAI に接続する構成です。本記事は、旧アクセラレータ前提の情報を現行の手順に置き換え、構成の選択・実装・クエリ方式・コスト判断までを実装目線でまとめます。

まとめ：AzureでGraphRAGを動かす要点

• 旧GraphRAG Acceleratorはアーカイブ済み。AKSやAPIMを一括デプロイする構成だったが2025年5月27日で更新停止・読み取り専用。増分インデックス非対応で、新規構築の土台には使わない。
• 現行の最小構成は「graphragライブラリ＋Azure OpenAI」。ローカルでPoCを回し、必要ならコンテナ化してAzure上へ載せる。巨大なマネージド一式は不要。
• 使うモデルは gpt-4.1（チャット）と text-embedding-3系（埋め込み）が既定。旧記事のGPT-4・text-embedding-ada-002・api-version 2023-03-15-preview は現行の設定と食い違うため流用しない。
• ベクトルストアはLanceDBが既定、Azure AI Searchに切替可能。インデックスの成果物はparquetファイルとして出力される。
• クエリはGlobal・Local・DRIFTの3方式。全体俯瞰はGlobal、特定エンティティ周辺はLocal、両者の中間はDRIFTで使い分ける。
• コストの主因はインデックス時のLLM呼び出し。小規模データでも数ドル、更新頻度が高い用途や単純FAQには向かない。

GraphRAGとは：知識グラフでベクトルRAGの弱点を補う仕組み

GraphRAG（Graphs + Retrieval Augmented Generation）は、文書群から知識グラフを自動構築し、その構造をLLMの文脈として使うRAG手法です。Microsoft Researchが2024年に公表しました。通常のRAGは文書をチャンク化してベクトル類似検索で拾うため、複数文書にまたがる関係や、答えに二段階以上の推論が要る「マルチホップ質問」に弱いという弱点があります。ベクトル検索そのものの仕組みと限界はベクトル検索とセマンティック検索の違いで整理していますが、GraphRAGはこの弱点を、エンティティ（人物・組織・概念など）をノード、関係をエッジとした知識グラフで補います。

グラフ構築はLLMがテキストからエンティティと関係を抽出して行い、Leidenアルゴリズムで密に結び付くノード群（コミュニティ）を階層的に検出し、各コミュニティをLLMが要約します。この「コミュニティ要約」があるおかげで、データ全体を俯瞰する質問にも、局所を掘る質問にも同じインデックスで答えられます。単純なキーワード一致では拾えない間接的なつながりを辿れる点が、ベクトルRAGとの本質的な差です。

Azureで動かす現行の選択肢｜Accelerator終了後の4ルート

「AzureでGraphRAG」を実現する道は一つではありません。旧アクセラレータを前提にした解説が多く残っていますが、2026年時点の実態に沿うと選択肢は次の4つに整理できます。

旧GraphRAG Accelerator：アーカイブ済みで新規採用は非推奨

GraphRAG Acceleratorは、graphragパッケージの上にAzure上のAPIエンドポイント群を被せ、AKS・API Management・Azure AI Search・Cosmos DB・Storageをワンクリックでデプロイする「参考実装」でした。リポジトリにはThis repository was archived by the owner on May 27, 2025. It is now read-only. のバナーが出ており、増分インデックス（既存インデックスへの文書追加）に非対応という制約が残ったまま停止しています。デプロイの不具合報告も未対応のままなので、新規構築の土台にはせず、アーキテクチャの参照先に留めるのが妥当です。公式も、まずコアのgraphragライブラリで検証することを案内しています。

現行の推奨構成：graphragライブラリ＋Azure OpenAI

2026年の実務では、graphragライブラリをローカルで動かして実データでPoCを行い、成果が出てからコンテナ化してAzure Container Apps等へ載せる流れが基本です。埋め込みの保存先はLanceDB（既定）かAzure AI Searchを選べます。マネージドな大規模一式を最初から組むより、ライブラリ単体で意図した回答品質が出るかを先に確かめるほうが、コストも設計の手戻りも小さく済みます。

実装手順｜graphragライブラリからAzure OpenAIへの接続

インストールとプロジェクト初期化

Pythonは3.11〜3.13を用意します。インストールと初期化は次の2コマンドです。initを実行すると設定ファイルの雛形が生成され、既定のチャットモデルと埋め込みモデルを指定するプロンプトが出ます。

python -m pip install graphrag
graphrag init --root ./ragtest

settings.yamlのAzure OpenAI設定

生成されたsettings.yamlで、モデルプロバイダをAzureに切り替えます。旧記事にあるGPT-4やada-002ではなく、現行既定のgpt-4.1とtext-embedding-3系を指定します。APIキーはGRAPHRAG_API_KEY等の環境変数に逃がすのが基本で、キーを使わずAzureのマネージドIDで認証する方法（auth_method: azure_managed_identity）も選べます。

models:
  default_chat_model:
    type: chat
    model_provider: azure
    model: gpt-4.1
    azure_deployment_name: your-gpt41-deployment
    api_base: https://your-instance.openai.azure.com
    api_version: 2024-10-21
  default_embedding_model:
    type: embedding
    model_provider: azure
    model: text-embedding-3-small
    azure_deployment_name: your-embedding-deployment
    api_base: https://your-instance.openai.azure.com
    api_version: 2024-10-21

Azure OpenAI側では、指定したデプロイ名でチャットモデルと埋め込みモデルを事前にデプロイしておきます。インデックス構築では短時間に大量のトークンを消費するため、対象デプロイのTPM（毎分トークン数）クォータに余裕を持たせておくと処理が詰まりません。

インデックス作成とクエリ実行

./ragtest/inputにテキストを置き、indexでグラフとインデックスを構築します。完了すると./ragtest/outputにparquetファイル群（エンティティ・関係・コミュニティ要約など）が出力されます。クエリは--methodで方式を切り替えて実行します。

graphrag index --root ./ragtest
graphrag query --root ./ragtest --method global --query "全体の主要テーマは？"
graphrag query --root ./ragtest --method drift --query "AとBの関係は？"

クエリ方式の使い分け｜Global・Local・DRIFT

GraphRAGのクエリは対象範囲とコストが異なる3方式（＋シンプルなBasic）を持ちます。旧来のGlobal／Localに加え、2024年後半に追加されたDRIFTが、混在難易度の質問での既定的な選択肢になっています。

DRIFTは、まずLocal検索で質問を精緻化しつつコミュニティ情報を取り込み、追加の中間質問を生成しながら答えを組み立てます。全体俯瞰が要るならGlobal、単一の事実ならLocal、その中間で迷うならDRIFT、という切り分けが実装上の目安です。Globalは参照範囲が広くLLM呼び出しが増えるため、常用するとコストが跳ねます。

ストレージ構成の実際｜出力はparquet、グラフDBの常時トラバースではない

ここは旧解説で誤解が多い箇所です。graphragライブラリのインデックス成果物は、Cosmos DBのGremlin頂点・辺ではなくparquetファイルとして出力されます。クエリ時は、グラフDBに対してGremlinやCypher的なDSLでライブにトラバースするのではなく、このparquetアーティファクト（エンティティ・関係・コミュニティ要約）をロードし、埋め込みのベクトル検索と組み合わせて関連部分をLLMへ渡す、という流れです。「質問のたびにグラフDBを経路探索する」という説明は、実装と一致しません。

永続化の選択肢としては、Azure Blob Storage（成果物・ログ）、Azure Cosmos DB、Azure AI Searchの3系統がプラガブルに使えます。旧アクセラレータがCosmos DBに保持していたのはNoSQL（ドキュメント）モデルのグラフ構造で、各要素が1ドキュメントとして格納される形でした。ベクトル埋め込みは既定でLanceDB、切り替えでAzure AI Searchに載せられます。既存の全文検索基盤にGraphRAGを載せたい場合は、AI Searchをベクトルストアに指定する構成が現実的です。

コストと適用判断｜GraphRAGを使うべきでない場面

GraphRAGのコストは、質問応答時よりもインデックス構築時のLLM呼び出しに集中します。エンティティ抽出・関係抽出・コミュニティ要約で文書量に比例してAzure OpenAIを叩くため、数十KB程度の小さなデータでも数ドル規模の消費になり、大規模データでは金額も構築時間も大きく膨らみます。抽出だけ安価なモデルに寄せ、最終応答のみgpt-4.1を使うといったモデル分けがコスト抑制の定石です。

逆に、次のような用途では素直なベクトルRAGや他手法のほうが費用対効果で勝ります。単発の事実回答で足りる単純なFAQ、文書が頻繁に差し替わる更新頻度の高いデータ（増分インデックスの弱さが再構築コストとして効く）、応答レイテンシやランニングコストの制約が厳しいケースです。GraphRAGが本領を発揮するのは、判例・技術文書・社内ナレッジのように関係が絡み合い、多段推論が必要な固定的コーパスです。ベクトル不要の推論型アプローチであるPageIndexや、検索精度を上げるRRF（Reciprocal Rank Fusion）と比較し、対象データの性質で選ぶのが実務的です。

よくある質問

GraphRAG Acceleratorはまだ使えますか？

リポジトリは2025年5月27日にアーカイブされ読み取り専用です。デプロイ自体は可能でも増分インデックス非対応・不具合未修正のため、新規採用は非推奨です。現行はgraphragライブラリでの構築が案内されています。

graphragライブラリの最新バージョンは？

2026年5月28日時点でv3.1.0です。python -m pip install graphragで導入し、Pythonは3.11〜3.13に対応します。

Azure OpenAIではどのモデルを使えばよいですか？

チャットはgpt-4.1、埋め込みはtext-embedding-3-smallまたはtext-embedding-3-largeが現行の既定です。旧来のGPT-4・ada-002を前提にした設定は流用しないでください。

Global・Local・DRIFTはどう選びますか？

データ全体の俯瞰はGlobal、特定エンティティの関係確認はLocal、両方の性質を持つ質問はDRIFTです。Globalはコストが高いので常用は避けます。

Azure AI Searchは必須ですか？

必須ではありません。ベクトルストアは既定でLanceDBが使われ、既存の検索基盤に統合したい場合にAzure AI Searchへ切り替えます。

関連記事

• ベクトル検索とセマンティック検索の違い｜包含関係・仕組み・使い分けを実装目線で整理
• PageIndexとは？ベクトル不要の推論型RAGの仕組み・使い方・従来RAGとの違い
• RRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説
• Agentic RAGのアーキテクチャと構成要素を詳しく解説
• AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順