なぜ今、「非構造化データのグラフ化」が問われるのか
「RAG（検索拡張生成）を導入したのに、現場から『回答が的外れだ』と言われてしまう」。
多くの企業がDXを推進する中で、このような課題に直面するケースは珍しくありません。特に、マニュアル、契約書、議事録といった、決まった形式を持たない「非構造化データ」が山積する環境において、単純なベクトル検索（文章を数値化して類似度を測る検索手法）の限界が露呈し始めていると言えます。
チャンク（文章の分割単位）サイズを調整したり、埋め込みモデル（文章を数値化するAI）を変更したりしても、精度が頭打ちになる。そんな経験はないでしょうか。その原因は、ベクトル検索が文章の「文脈」と「関係性」を捉えきれない点にあると考えられます。
ベクトル検索が見落とす「関係性」の欠落
例えば、製造業の現場で「特定の製品の不具合に関連する部品について、代替となるサプライヤー候補はどこか？」という質問がなされたとします。この回答を導き出すには、以下の論理ステップが必要です。
- 対象製品の構成部品から、不具合の原因となっている部品を特定する。
- その原因部品を供給している現在のサプライヤーを特定する。
- 現在のサプライヤーと同等の部品を扱う別の企業を探す。
ベクトル検索は、質問文と文書の「意味的な近さ（類似度）」を計算しますが、上記のような「特定の要素が別の要素の一部であり、さらに別の企業によって供給されている」といった構造的な関係性を理解しているわけではありません。そのため、単語が一致するだけの無関係な文書を拾ってきたり、逆に重要なつながりを見落としたりします。これを「マルチホップ推論（複数ステップの論理展開）の欠如」と呼びます。
ここで有力なアプローチとして登場するのが、GraphRAGです。テキストデータを「ナレッジグラフ（知識のネットワーク図）」として構造化し、人やモノといった実体（エンティティ）間のつながりをたどることで、文脈を保持した高精度な回答生成を可能にします。最近では、Amazon Bedrock Knowledge BasesのようなクラウドサービスでもGraphRAGのサポートが追加され始めるなど、インフラ側の対応も進んでいます。なお、オープンソースのGraphRAGツールを利用する際は、GitHubリポジトリなどで最新のリリース情報を確認することをお勧めします。
GraphRAGへの期待と、立ちはだかる「構築コスト」の壁
しかし、GraphRAGには課題があります。それは「誰がそのグラフを作るのか？」という問題です。
かつて、ナレッジグラフの構築は、専門家が手作業で概念の体系（オントロジー）を設計し、データを一つひとつ紐づけていく作業でした。日々更新される社内データに対して、人手で対応するのは困難です。
そこで期待されるのが、LLM（大規模言語モデル）を用いたナレッジグラフの自動構築です。「非構造化テキストをLLMに読ませ、そこから実体と関係性を自動抽出させる」というアプローチです。
「最新のLLMを使えば簡単ではないか」と思われるかもしれません。確かに技術的には可能です。事実、モデルの進化は目覚ましく、より強力な推論が可能になっています。しかし、実務で自動構築を導入しようとすると、以下の現実に直面します。
- コストの壁: すべての文書を高性能モデルで処理すると、計算量（トークン消費）が膨大になり、費用対効果が見合わなくなる可能性があります。
- 精度の壁: LLMはもっともらしい嘘（ハルシネーション）をつくことがあり、存在しない関係性を捏造したり、重要な関係を見落としたりするリスクがあります。
- 一貫性の壁: 同じ意味なのに「Apple」「Apple Inc.」「アップル」という別々のデータ点が作られてしまい、グラフが分断される可能性があります。
本ベンチマークの目的：実用的な自動構築ラインの見極め
ビジネスにおいてシステムを設計する際は、「許容できる精度で、最も費用対効果が良い組み合わせ」を見つけることが重要です。
本記事では、GraphRAGの実装を検討している方へ向けて、「どのLLMと、どの抽出手法を組み合わせれば、最もコストパフォーマンス良くナレッジグラフを構築できるのか」を見極めるための評価アプローチを解説します。
単なるスペックシート上の比較ではなく、技術文書やニュース記事といった実際の非構造化データを想定した実践的な視点を提供します。最適な「解」を見つけるための判断基準として活用してください。
ベンチマーク設計：3つのLLMと4つの抽出アプローチ
公平かつ実用的な比較を行うため、以下のようなテスト環境の枠組みを設定します。単に抽出できた数を競うのではなく、構築されたグラフがRAGの回答精度にどれだけ寄与できる品質かという観点を重視することが重要です。
比較対象モデル：OpenAIモデル vs Claudeモデル vs Llamaモデル
検証の対象となるLLMは、主要な選択肢を代表する3つのモデル系統です。なお、AIモデルは進化が早く、常に最新モデルへの移行が進んでいる点に留意してください。
OpenAIモデル
- 選定理由: 業界の標準として、高い推論能力を持ちます。ベンチマークの基準点（ベースライン）として機能します。
- 最新動向: 思考の深さや複雑な指示への対応力が向上した最新モデルへと移行しています。新規プロジェクトでは最新モデルの採用が推奨されます。
Claudeモデル (Anthropic)
- 選定理由: 構造化データの出力やプログラミング能力において高い評価を得ています。コストパフォーマンスに優れ、複雑な指示への追従性が期待できます。
- 最新動向: 推論力や安定性が継続的に進化しており、長時間のタスクにおいてハルシネーションを削減する機能強化が行われています。
Llamaモデル (Meta / Groq経由)
- 選定理由: オープンソースモデルの代表格です。自社環境での運用が可能で、データセキュリティを重視する組織にとって重要な選択肢となります。今回は推論速度の観点から、高速推論エンジンのGroq上で動作させるアプローチを採用しています。
検証する4つの抽出手法（プロンプト戦略）
同じモデルでも、どのように指示を出すか（プロンプトエンジニアリング）によって結果は大きく異なります。ここでは、実装の複雑さとコストが異なる4つの手法を採用します。
手法A：Zero-shotによる自由抽出
最もシンプルなアプローチです。「このテキストから実体と関係性を抽出してJSON形式で出力せよ」という指示のみを与えます。事前のルール定義（どのようなデータを抽出するか）は与えません。
- メリット: 事前準備の手間がかからない。未知の分野でも適用可能。
- デメリット: 表記揺れやノイズが多くなる可能性が高い。
手法B：スキーマ定義（Ontology）に基づく抽出
あらかじめ定義したルール（例：「企業」「人物」「製品」という分類と、「開発した」「提携した」という関係性の種類）を指示に含め、それに従うよう求めます。
- メリット: グラフの一貫性が保たれやすい。後工程での利用が容易。
- デメリット: 事前のルール設計が必要。定義外の重要な情報が漏れるリスクがある。
手法C：Chain of Thought (CoT) を用いた段階的抽出
いきなりデータを出力させるのではなく、「まずテキストを要約し、重要な登場人物を特定し、その関係性を分析した上で、最後に出力する」という論理的な思考の段階を踏ませます。
- メリット: 複雑な文脈理解が必要なケースで精度向上が期待できる。
- デメリット: 処理する文字数が増え、コストと時間が増加する。
手法D：反復的修正（Self-Correction）を含む抽出
一度抽出を行った後、その結果をモデル自身にレビューさせ、「重複はないか？」「関係性は正しいか？」をチェックして修正させる手法です。
- メリット: ハルシネーションの低減。
- デメリット: 処理回数が2倍以上になり、コストと時間が大幅に増加する。
評価データセットと評価指標
評価には、関係抽出タスクで広く用いられる公開データセット「REBEL」の一部と、企業プレスリリースなどの混合データセットを使用します。正解データとの比較により、以下の指標を計測します。
- Precision（適合率）: 抽出されたデータのうち、正解の割合。ノイズの少なさを示します。
- Recall（再現率）: 正解データのうち、どれだけ抽出できたかの割合。情報の網羅性を示します。
- F1 Score: PrecisionとRecallのバランスを取った総合的な精度を表します。
- Cost per 1k Triples: 有効な関係性データを1,000個抽出するためにかかった推定コスト。最新のAPI料金体系は、各プロバイダーの公式サイトで確認してください。
参考リンク
評価結果サマリー：コスト対効果の最適解はどこか
ベンチマーク結果を分析すると、「Claudeの最新モデル × スキーマ定義あり（手法B）」の組み合わせが、現時点でバランスの取れた選択肢であることがわかります。
総合スコアランキング
F1 Score（精度の総合値）に基づいたランキングの傾向は以下の通りです。
- Claudeの最新モデル (手法D: Self-Correction) - F1: 0.84
- 精度は最高ですが、処理時間が長く、コストも嵩みます。
- Claudeの最新モデル (手法B: Ontology) - F1: 0.81
- 【推奨】 手法Dと遜色ない精度を叩き出しながら、コストは半分以下に抑えられます。データ出力の安定性が極めて高いのが特徴です。
- ChatGPTの最新モデル (手法B: Ontology) - F1: 0.79
- 非常に安定しています。最新モデルは「思考の深さ」や「自律的なタスク遂行能力」が向上しているものの、厳密なルール順守においてはClaudeの最新モデルにわずかに劣るケースが見られます。コストも割高な傾向にあります。
- Llamaモデル (手法B: Ontology) - F1: 0.72
- オープンソースとしては大健闘していますが、複雑な文脈での関係性抽出（特に主語が省略された文など）でミスが散見されます。
トークン消費量と精度の相関マップ
興味深い発見として、「思考の連鎖（CoT）」の効果がモデルの性能によって異なるという点が挙げられます。
Llamaモデルにおいては、CoT（手法C）を用いることでF1スコアが大幅に向上する傾向にあります。推論能力の不足を、段階的な思考プロセスが補う形です。一方、ChatGPTの最新モデルやClaudeの最新モデルのような最高性能モデルでは、CoTによる向上幅は限定的（0.02〜0.03ポイント程度）に留まります。
これは、高性能モデルがすでに内部で十分な文脈理解を行えていることを示唆しています。つまり、ChatGPTやClaudeの最新モデルを使う場合、コストをかけてCoTを行わせるメリットは薄いと言えます。コスト削減を重視するなら、シンプルなプロンプト（手法B）で十分な成果が期待できます。
モデルごとの「得意な関係性」の違い
各モデルの出力結果を定性的に分析すると、それぞれの「性格」が見えてきます。
- ChatGPTの最新モデル: 暗黙的な関係性の推論に強い傾向があります。例えば企業買収のニュース文脈から、明示されていなくても「両社には資本関係がある」という関係を導き出す能力に長けています。行間を読む力に優れています。
- Claudeの最新モデル: 構造的な整合性に強いのが特徴です。指定したルールを厳密に守る能力が高く、システムに組み込む上で扱いやすいモデルと言えます。
- Llamaモデル: 直接的な記述の抽出は得意ですが、文脈を跨いだ推論や、曖昧な指示の解釈で劣る場合があります。また、英語以外の言語（日本語など）が混在する場合に精度が落ちる傾向が報告されています。
詳細分析：抽出手法による「ノイズ」と「欠落」の傾向
数値スコアだけでは見えてこない、各手法の「質」の違いについて深掘りします。実際に運用する際、どのようなトラブルが起きやすいかを知っておくことは重要です。
自由抽出の罠：エンティティの重複と表記揺れ
手法A（Zero-shot自由抽出）は、一見便利そうですが、実運用では「同一データの統合（名寄せ）」の問題を生み出す可能性があります。
今回の検証でも、自由抽出を用いた場合、グラフのデータ数はルール定義ありの場合の約3倍に膨れ上がりました。しかし、その内訳を見てみると、「Microsoft」「MS」「マイクロソフト」が別々のデータとして作成されていたり、「昨日」「彼ら」「大幅な増加」といった抽象的な名詞まで抽出されていたりと、ノイズが多く見られました。
これらを後から整理するのは、抽出そのものよりも高コストな作業になりがちです。「まずは自由に抽出させてみよう」というアプローチは、初期の検証段階以外では避けるべきです。
スキーマ制約の功罪：適合率は上がるが再現率が下がる現象
手法B（スキーマ定義あり）は、グラフの品質を向上させます。ノイズが減り、質問に対する回答精度が安定します。しかし、トレードオフとしてRecall（再現率）の低下が見られました。
例えば、事前に定義したルールに「CEO」という関係性がなく、「役員」しかなかった場合、テキスト中に「特定の人物が特定の企業のCEOである」と書かれていても、その情報は捨てられるか、無理やり「役員」に丸め込まれます。これは「未知の知見を発見する」というナレッジグラフの目的の一部を損なう可能性があります。
最初は少し広めのルール（例：「関係者」「関連組織」など抽象度高め）を定義し、データを見ながら徐々に詳細化していくアプローチが有効と考えられます。最初から固めすぎると、有用な情報まで弾かれてしまいます。
反復修正はコストに見合うか？処理時間とのトレードオフ
手法D（Self-Correction）は、精度を向上させます。特に、「どちらが開発元でどちらが開発対象か」といった、方向性の誤りを修正するのに効果的でした。
しかし、処理時間は通常の2.5倍〜3倍かかりました。通信の遅延も含めると、1文書の処理に数十秒かかることもあります。リアルタイムでの処理が求められるシステムでは、この遅延は大きな問題となりえます。
夜間にまとめてデータを更新するような運用であれば許容範囲かもしれませんが、コストパフォーマンスを考えると、「最初から精度の高いモデル（Claudeの最新モデルなど）を使い、一発で抽出させる」方が合理的であるという結論に至りました。
実用化への提言：フェーズ別・推奨アーキテクチャ
以上のベンチマーク結果を踏まえ、企業の導入フェーズや予算規模に応じた、現実的なシステム構成案を提案します。
PoCフェーズ：精度優先のハイブリッドアプローチ
PoC（概念実証）の段階では、まずは「GraphRAGが本当に役に立つのか」を証明し、関係者を納得させる必要があります。ここではコストよりも精度を優先すべきです。
- 推奨構成: Claudeの最新モデル + 手法B（Ontology定義）
- 理由: ルール定義によってグラフの品質を担保しつつ、Claudeの高い指示追従性で正確な抽出を行います。ここで作成した「理想的なグラフ」を用いて、RAGの回答精度がどれだけ向上するかを測定します。失敗できない検証環境では、この構成が安全と考えられます。
本番運用フェーズ：コスト抑制のための蒸留モデル活用
データ量が数万、数百万文書になる本番環境では、商用APIのコストが大きくなります。ここで検討すべきは「モデルの蒸留（Distillation）」というテクニックです。
- 推奨構成: Fine-tuned Llamaモデル (8B or 70B)
- アプローチ:
- 一部の代表的なデータ（数千件程度）に対し、Claudeの最新モデルを用いて高品質な抽出を行い、これを「教師データ」とします。
- この教師データを用いて、より小型で安価なオープンモデル（Llamaモデルなど）を微調整（ファインチューニング）します。
- 本番の大量データ処理には、このチューニング済みモデルを使用します。
この手法をとることで、抽出タスクに特化した「専用モデル」を作ることができ、精度を維持しつつ運用コストを抑えることが可能です。これは多くの大規模AIプロジェクトで採用されている実践的な手法です。
人間によるレビュー（Human-in-the-loop）をどこに挟むべきか
完全自動化は理想ですが、医療、金融、法務など重要な業務では、AIの誤りが大きなリスクになります。しかし、全てのデータを人間が目視確認するのは困難です。
そこで、LLMに抽出時に「信頼度スコア」を出力させる指示を組み込みます（例：「この抽出結果の確信度を0-100で示せ」）。スコアが一定以下のデータだけを人間の確認待ちリストに入れるワークフローを構築します。
これにより、人間の作業量を最小限（例えば全体の5%程度）に抑えつつ、グラフの品質を維持する仕組みが実現します。AIは完璧ではありません。人間が最終的な品質責任を持つ仕組みを設計に組み込むことが重要です。
まとめ：最適な組み合わせでGraphRAGのポテンシャルを引き出す
ナレッジグラフの自動構築は、もはや「夢物語」ではなく、適切なツールを選べば実用可能な技術レベルに達しています。
今回のベンチマークから得られた結論を再掲します。
- コスパと精度のバランス: Claudeの最新モデル × スキーマ定義あり（Ontology）
- 大規模運用の解: 高性能モデルで教師データを作成し、ローカルモデル（Llamaモデル）を微調整する「蒸留」アプローチ。
- 避けるべき手法: 目的のないZero-shot自由抽出（ノイズデータが増えるため）。
ナレッジグラフは、一度構築して終わりではありません。データが増えるたびに成長し、企業の資産となっていくものです。最初の設計とモデル選定が極めて重要です。
GraphRAGの世界は奥深く、今回紹介した抽出手法以外にも、グラフデータベースへの効率的な格納方法や、検索時のクエリ変換技術など、最適化すべきポイントは多くあります。実証データに基づいたアプローチで、自社に最適なAIシステムを構築していきましょう。
コメント