LLMの根本的な制約：なぜ「賢そう」なのに間違えるのか

ChatGPTやClaudeのような大規模言語モデルは、膨大なテキストから言語パターンを学習することで、流暢で一見正確な文章を生成します。しかしその内部は、事実を「知っている」のではなく、「出現しやすい言葉の並び」を確率的に生成するメカニズムです。

LLMはさまざまな能力が高いものの、事実情報を把握・活用するのがまだ苦手と考えられています。LLMが知識を学ぶ際は学習したテキスト情報に依存しており、知識レベルでの相互関係を捉える学習方法にはなっていないという課題があります。 AIDB

この限界が「ハルシネーション（幻覚）」を生みます。LLMは根拠のない情報でも自信を持って回答するため、特に事実の精度が要求されるビジネス用途では深刻な問題になります。

ナレッジグラフはこの問題に対する構造的な補完策として位置づけられています。

ナレッジグラフとは何か：トリプレットとグラフ構造

ナレッジグラフとは、人間の知識をグラフ構造でデータ化したものです。グラフ構築では、「情報」をノード（点）で、「関係性」をエッジ（線）で表現します。ノードはエンティティ（人物、場所、物事など）を指し、エッジはそれらの間の関係を示します。例えば「東京は日本の首都である」という情報は、「東京」と「日本」というノードを「首都」というエッジで結びつけます。 NTTデータ

この表現形式を「トリプレット（三つ組）」と呼び、（主語、述語、目的語）という構造で知識を記述します。

（東京）─[首都]→（日本）
（田中社長）─[所属]→（○○株式会社）
（A製品）─[競合]→（B製品）

既存のナレッジグラフは保存されている情報に基づいて4種類に分類されます。百科事典型（Wikidataなど一般知識を網羅）、常識型（日常的な判断に必要な知識）、特定分野型（専門的な知識）、複合型（テキスト・画像・音声など複数形式を統合）です。 AIDB

通常RAGの限界とGraphRAGが解決すること

RAG（Retrieval-Augmented Generation）は、LLMの知識不足を外部文書の検索で補う手法として広く使われています。しかし、通常のRAGではテキストをチャンクに分割してベクトル検索するため、複数のドキュメントにまたがる情報を統合して回答する必要がある場合、別々の知識として扱われ、これらを統合して回答を生成してくれるかどうかはLLMの頑張り次第になります。 Zenn

具体的な問題を例で示します。「東京から屋久島まで何時間かかるか」という質問に対して、「東京→羽田空港の時間」と「羽田→屋久島の時間」が別ドキュメントに存在する場合、ベクトル検索では両者を統合した回答が不安定になります。GraphRAGを用いれば関連する知識は統合された上でコンテキストとして与えることができるので、LLMの認知負荷が下がると考えられます。 Zenn

また別の問題として、RAGではテキストをそのままプロンプトに入れるため（しかも複数のテキストを連結して大量に）、「lost in the middle」現象——長いコンテキストの中間部に入った情報をLLMが見落とす——が起きやすいです。GraphRAGを用いれば、コンテキストとして与える情報を圧縮できるため、この問題が緩和されると考えられています。 Zenn

Microsoft GraphRAGと「コミュニティ検出」

2024年にMicrosoftがオープンソースで公開した「Microsoft GraphRAG」は、この分野における実装の大きな転換点となりました。

Microsoftは2024年末にGraphRAG 1.0をリリースし、本番稼働への準備が整った重要なマイルストーンを迎えました。設定の合理化・ドキュメントの改善・Azure AI Foundryとのより良い統合が導入されました。このライブラリは進化を続けており、2026年3月の最新リリースではパフォーマンス最適化と新しいクエリ機能が追加されています。 Programming Helper

Microsoft GraphRAGの特徴は「コミュニティ検出と階層的要約」の組み合わせです。通常のGraphRAGがエンティティと関係を取得してLLMのコンテキストとして渡す手法全般を指すのに対し、Microsoft GraphRAGはコミュニティ検出と階層的要約を組み合わせた特定の実装です。 Qiita局所的な質問（特定の人物や事実）にも、大局的な質問（「このドキュメント全体の主要テーマは何か」）にも対応できる点が特徴です。

ただし、コストの問題もあります。インデックス作成はベクトルRAGの100〜1000倍のコストがかかりますが、LazyGraphRAGはMicrosoft Researchが開発した変形版で、インデックスコストをフルGraphRAGの0.1%に削減します。 Articsledge

実装スタックと構築の流れ

2025年現在、オーソドックスな方法として、LangChainを用いてNeo4j上でグラフデータベースを構築するのが一般的です。他にもデータベースとしてはAmazon Neptune、GraphRAGフレームワークとしてLlamaIndexの利用も選択肢に入ります。 Zenn

テキストからナレッジグラフを構築する手順は次のようになります。

  1. ドキュメントの読み込み：PDF・Markdown・CSVなどの原文書をLangChainで取り込む
  2. エンティティと関係の抽出：LLMに対して「主語・述語・目的語の形でエンティティと関係を抽出せよ」というプロンプトを与える
  3. グラフデータベースへの格納：抽出したトリプレットをNeo4jに保存する
  4. Cypherクエリによる検索：質問文に含まれるキーワードと一致・類似するノードを検索し、関連するサブグラフを取得する
  5. LLMによる回答生成：取得したグラフ情報をコンテキストとしてLLMに渡す

1万トークンのドキュメントでも数百回のLLM呼び出しが発生することがあるため、APIコストには注意が必要です。 Qiita

実際の導入事例

NTTデータ：契約書リスク審査への適用

企業における契約書のリスク審査は、重要かつ多大な労力を要する業務です。NTTデータはナレッジグラフとLLMを組み合わせることで、契約書に含まれるリスクを自動的に判定し、その根拠を可視化して出力する検証を行いました。リスクとなる項目を「誰が（主語）」「何をする（述語）」「何に対して（目的語）」という形で整理し、リスクのパターンを定義した上で、契約書の文章から情報を抽出します。 NTTデータ

この手法を用いて実際の契約書を対象に検証を行った結果、リスク判定精度および審査理由の出力精度が向上することが確認されました。また、企業に関するニュース記事を集めて企業同士の関係を抽出した検証では、約73%の関係性を正確に抽出できました。 NTTデータ

医療・ライフサイエンス分野

医療分野では、Cedars-Sinaiがアルツハイマー研究のために160万エッジを持つグラフを構築しています。また、Precina Healthは1%の月次HbA1c低下（標準治療の12倍速）を達成しています。 Articsledge

レコメンドシステムへの応用

ナレッジグラフはレコメンドシステムにも有効で、ユーザーと商品をエンティティとして、購入・閲覧・評価などの関係でエッジを結ぶことでグラフを構成します。「妊婦用の靴」と検索したユーザーが滑りにくい靴を購入した場合、そのデータから「妊婦用の靴は滑りにくい方が好ましい」という暗黙知をナレッジグラフが獲得できます。 Insightedge

GraphRAGの限界と導入判断の基準

ナレッジグラフは万能ではありません。導入前に理解しておくべき制約があります。

GraphRAGにも独自の限界があり、ベクトルベースのRAGよりも高い精度を達成するためにはユースケースに依存します。LLMを使用してエンティティと関係性を抽出してナレッジグラフを作成するという追加ステップが発生します。新しいデータが到着するたびにグラフを維持および更新することは、継続的な運用負担になります。 Note

「とりあえずナレッジグラフを入れてみよう」は避けてください。グラフの構築・維持には継続的なコストがかかります。まず通常のRAGで検証し、「関係を辿る質問に答えられない」という具体的な課題が出てから導入を検討するのが現実的です。 Qiita

ノード数の目安として、数百以下であればNetworkXなどのインメモリグラフで十分であり、Neo4jのような外部グラフデータベースは不要です。数千以上になる場合にNeo4j + GraphRAGの導入を推奨します。 Qiita

デロイトの調査によると、75%の組織がGenAIをパイロット導入している一方、97%がROIを証明することに苦労しています。GraphRAGはサプライチェーンのリスク分析（隠れた依存関係の発見）や360度顧客インサイトなど、従来不可能だった高価値なユースケースを実現することでROI課題に直接応えます。 Salfati Group

LLMの流暢さとナレッジグラフの事実的な確実性は、互いの弱点を補う関係にあります。その統合が進む現在、「Vector or Graph」ではなく「Vector plus Graph」という設計思想が企業のAI基盤の標準になりつつあります。