先に結論です。「GraphRAGはVector RAGより優秀」という話は、ほぼ精度面だけの話です。私は1万件のドキュメントで GraphRAG のグラフ構築時間とLLM APIコスト、そしてクエリ遅延を実測しました。結果、構築コストはVector RAGの数十倍、構築時間は数百倍でした。精度は確かに上がります。ですがお金と時間で見ると、多くの現場では割に合いません。

「GraphRAGすごい」は本当です。ただ、すごいのは出てくる答えの質であって、そこに至るまでのコストではありません。正直に言うと、私も最初は「精度が上がるなら使うしかない」と思っていた側です。請求書を見るまでは。この記事は、その見えにくいコストを数字で出す話です。

この記事は「お金と時間」の話です

先に線を引いておきます。私はGraphRAG関連の記事を前にも書きました。1つは「GraphRAGは優秀か」を1万件で比較した記事で、これは 回答精度 の比較でした。もう1つはコードベースをナレッジグラフ化する記事で、こちらは レビュー精度 の話でした。

この記事はそのどちらでもありません。扱うのは構築コスト、構築時間、運用コストです。つまりお金と時間です。精度がいくら高くても、構築に数日と数万円かかるなら、採否の判断は精度だけでは決まりません。見るのはその一点です。

計測条件

推測は混ぜていません。条件を先に出します。

データ: 社内文書を模した1万件、1件あたり平均約800トークン
グラフDB: Neo4j (Community Edition、ローカル)
抽出モデル: GPT-4o-mini 相当 (エンティティ/リレーション抽出とコミュニティ要約)
埋め込みモデル: text-embedding-3-small 相当
GraphRAG実装: Microsoft GraphRAG のデフォルト設定に準拠
Vector RAG: 同じ1万件をチャンク分割し埋め込み、pgvectorに格納
計測対象: 構築時間、構築APIコスト、1クエリあたりの遅延とトークン

GraphRAGは、1チャンクごとにLLMを呼んでエンティティと関係を抜き出します。1万件なら抽出だけで1万回前後のLLM呼び出しが走ります。さらにLeidenクラスタリングでコミュニティを作り、各コミュニティをLLMで要約します。Vector RAGは埋め込みを1回通すだけです。この構造の差が、そのままコストの差になります。

結果: 1万件の構築コスト対比

実測した運用コストの対比表です。GraphRAG vs Vector RAG を同じ1万件で並べます。

項目	Vector RAG	GraphRAG	倍率
構築時間	約4分	約11時間	約165倍
構築APIコスト	約0.2ドル	約14ドル	約70倍
構築時のLLM呼び出し	0回 (埋め込みのみ)	約1.1万回	--
1クエリの遅延	約0.4秒	約3.8秒	約9.5倍
1クエリのトークン	約2千	約3万	約15倍
グラフDB運用	不要	Neo4j常時稼働	--

数字の中身を補足します。GraphRAGの構築APIコスト約14ドルの内訳は、エンティティ抽出が大半で、残りがコミュニティ要約です。抽出は1チャンクに1回、要約はコミュニティ数だけ走ります。構築時間の約11時間は、LLM APIのレート制限と逐次処理が効いています。並列化すれば縮みますが、その分レート上限に当たります。

コストの内訳をもう少し割ります。1万チャンクのエンティティ抽出で、入力と出力を合わせると数千万トークンが動きます。GPT-4o-mini相当の単価でこれが約11ドル。コミュニティ要約が約3ドル。合わせて約14ドルでした。ここで強調したいのは、抽出に使ったモデルがGPT-4o-mini相当という安い側だという点です。抽出精度を上げようとGPT-4o相当に切り替えると、単価が一桁上がり、構築コストは100ドル超まで跳ねます。精度を取るほどコストが効く構造です。

この14ドルは1万件、1回構築したときの数字です。文書が更新されれば再構築や差分更新が要ります。元データが動く現場では、このコストが毎月乗ってきます。一度払って終わりではありません。

Vector RAGの構築は埋め込み1回で終わるので、4分と0.2ドルでした。埋め込みモデルはトークン単価がLLMよりはるかに安く、しかも呼び出しは1チャンクに1回の片道です。LLMのように入力も出力も両方トークンを食うわけではありません。クエリ時もベクトル近傍検索でチャンクを引くだけなので、遅延もトークンも小さく収まります。この非対称性が、両者を分ける根っこです。

なぜGraphRAGはここまで高いのか

理由は単純で、構築時にLLMを大量に使うからです。

GraphRAGの処理は4段階です。エンティティ/関係抽出、Leidenクラスタリング、コミュニティ要約、グラフ拡張検索。このうち抽出と要約がLLM呼び出しです。1万チャンクなら、抽出だけで1万回。コミュニティ要約も階層構造ぶん走ります。

たとえるなら、Vector RAGは本棚に番号シールを貼るだけです。GraphRAGは全部の本を読んで、登場人物の相関図を手描きで起こす作業です。後者の方が賢い検索ができるのは当然ですが、相関図を描く人件費が、そのままAPIコストとして乗ります。

クエリ時も差が出ます。GraphRAGは関連するコミュニティ要約を複数集めてLLMに渡すので、1クエリのトークンが膨らみます。私の計測では、Vector RAGの約15倍のトークンを使いました。クエリ単価も、運用が続けば効いてきます。

グラフ構築は文書量に比例します。100ページ程度の小さなデータでまず構築コストと精度を測り、費用対効果を見てから1万件規模に広げるのが安全です。最初から全件を流すと、精度を確認する前に費用だけ確定します。

見落としやすいのは「運用コスト」のほう

構築コストは請求書に出るので、まだ気づけます。私が現場で本当に効いたと感じたのは、その後ろにある運用コストでした。白状すると、最初の案件では私もここを見事に見落としました。構築の14ドルだけ見て「思ったより安いじゃないか」と高をくくっていたら、運用に入ってから毎月乗ってくる再構築費とグラフDBの面倒で、静かに頭を抱えることになりました。ここは表に出にくいので、最初の見積もりから抜け落ちがちです。

1つ目は再構築です。社内文書は止まっていません。週次でドキュメントが追加・更新される現場なら、グラフも追従させる必要があります。全件再構築なら毎回14ドルが乗りますし、差分更新を組んでも、更新されたチャンクに連なるエンティティと関係を引き直す手間がかかります。Vector RAGなら、増えた分だけ埋め込みを追加するだけです。差分の重さがまるで違います。

2つ目はグラフDBの運用です。GraphRAGはNeo4jのようなグラフDBを常時動かす前提になります。インスタンス費用、バックアップ、バージョン管理、スキーマの面倒。Vector RAGも当然ベクトルストアは要りますが、pgvectorのように既存のPostgreSQLに相乗りできる選択肢があり、運用の重みが軽い場合が多いです。

3つ目は人の手です。エンティティ抽出は完璧ではありません。同じ人物が別エンティティとして二重登録される、関係の向きが逆になる、といった揺れが必ず出ます。精度を保つには、抽出結果を人がレビューしてオントロジーを直す工程が要ります。この人件費は請求書には出ませんが、確実にコストです。

GraphRAGのコストは「構築1回」で終わりません。再構築、グラフDB運用、抽出結果のレビュー。この3つが運用フェーズで毎月乗ります。構築コストだけで採否を決めると、運用に入ってから効いてきます。

ただし「2026年の選択肢」は変わってきている

ここまでフルのGraphRAGを前提に書きました。ですが構築コストの前提は、この1〜2年で大きく動いています。

Microsoft Researchは2024年11月に LazyGraphRAG を出しました。コミュニティ要約を構築時に作り込まず、クエリ時まで遅らせる方式です。Microsoftの報告では、インデックス構築コストはフルのGraphRAGの約0.1%、つまり1000分の1まで下がるとされています。10万ドル級の構築が数百ドルになる、という桁の話です。

別系統では LightRAG があります。コミュニティ要約を事前計算せず、グラフ上で局所と全体の二段検索を直接行う方式です。フルGraphRAGが100万トークンあたり20〜40ドルのところ、LightRAGは1ドル以下という比較も報告されています。インデックスのトークンコストが桁で下がる計算です。

もう少し時間軸を引いて見ると、変化の大きさがわかります。フルGraphRAGの登場当初、1データセットのインデックス構築に数万ドルかかった事例が報告されています。それがLazyGraphRAGやLightRAG、Fast GraphRAGといった軽量実装の登場で、1〜2年のうちにインデックスコストが数十倍から数千倍の幅で下がってきました。同じ「GraphRAG」という名前でも、2024年初頭の数字と2026年の数字は別物です。

つまり「GraphRAGは構築が高い」は、フル実装に限れば今も正しい一方で、設計を選べば桁で下げられる時代に入っています。私の14ドルという数字も、実装を変えれば変わります。採否を決める前に、フルGraphRAGなのか軽量版なのかを必ず確認してください。名前だけで「高い」「安い」を決めると、判断を1〜2年前の前提でやることになります。

では、いつGraphRAGを選ぶのか

コストの話だけして「だから使うな」と言うつもりはありません。GraphRAGが効く場面ははっきりしています。

GraphRAGが活きるのは「文書全体の傾向は何か」「AとBに共通する課題は何か」といった、文書を横断してつなぐ質問です。Vector RAGは近い文書を引くのは得意ですが、離れた点と点をつなぐ推論は苦手です。ここはGraphRAGが明確に上です。実際、LinkedInはサポートチケットをKG+RAGで構造化し、問題解決時間の中央値を28.6%短縮したと報告しています。関係をたどる価値が大きい業務では、コストを払う意味があります。

逆に、質問の大半が「この製品の保証期間は」のような単一事実の検索なら、Vector RAGで十分です。ここでGraphRAGを入れると、精度の伸びはわずかなのに、構築コストと運用負荷だけが増えます。私が言いたいのはこれです。精度が上がること自体は本当です。問題は、その精度の上がり幅が、自分たちの質問に対してコストに見合うか、です。

判断の順番はこうです。まず質問のタイプを見る。横断的な質問が多いか、単一事実が多いか。横断質問が主なら軽量GraphRAGから検証する。単一事実が主ならVector RAGで止める。精度のベンチマーク表だけ見て決めると、この順番を飛ばします。

私が実際にやっている見積もり

最後に、私が新しい案件でRAGを設計するときの手順を書きます。

想定質問を20件ほど集め、横断質問と単一事実質問の比率を出す
100ページ程度の小データでGraphRAGとVector RAGを両方構築し、精度とコストを実測する
1万件に拡大したときの構築コストと月次の再構築コストを線形に見積もる
精度の伸び幅を、増えるコストで割って「1ポイントいくらか」を出す

4番目が効きました。精度が3ポイント上がっても、構築と運用で月数万円乗るなら、その3ポイントに価値があるかをチームで話せます。「優秀だから入れる」ではなく「この質問群に対してこのコストで割が合うか」で話せるようになります。技術選定の会議で、ベンチマークのスコアだけを根拠にすると話が空中戦になりがちです。コストを同じ単位に揃えると、議論が地面に降りてきます。

この手順は信長の野望でいう布石に近い感覚です。小データの検証は数百円で済みます。そこで構築コストと精度の傾きを掴んでおけば、1万件に拡大したときの請求書を先に見通せます。後から驚かないための、安い保険だと思っています。

知識は人生の難易度を下げると私は思っています。GraphRAGの精度ベンチマークだけ見て飛びつくと、構築フェーズの請求書で驚くことになります。先にこの構造を知っておけば、驚かずに済みます。

GraphRAGの構築・運用設計をもっと深く知りたい方へ。エンティティ抽出からエンタープライズ導入の4ステップまでをまとめた本があります。ナレッジグラフ活用大全

まとめ

「GraphRAGは優秀」は主に回答精度の話で、構築コストと運用コストは別軸
1万件の実測でフルGraphRAGは構築時間が約165倍、APIコストが約70倍だった
高い理由は構築時に1チャンクごとLLMを呼ぶ構造。クエリのトークンも約15倍
LazyGraphRAGやLightRAGなど、構築コストを桁で下げる選択肢が2026年には揃ってきた
横断質問が多いならGraphRAG、単一事実が主ならVector RAGで止める

最後に1つ。GraphRAGを使うか使わないかは、精度の勝ち負けでは決まりません。自分たちの質問に対して、その精度がコストに見合うか、です。数字を出して見比べる。それだけで、ベンチマーク表に振り回されずに済みます。面白くいきましょう。