AIエージェントに社内データベースやAPIを接続したのに、的外れな回答が返ってくる。その原因は接続方法ではなく、LLMに渡すコンテキストの質にあるかもしれません。

この記事でわかること

  • MCPが解決する課題と、それだけでは足りない理由
  • ツール過多が引き起こす「行動のハルシネーション」
  • GraphRAGがMCPの弱点を補う仕組み
  • 両者を組み合わせた実装アーキテクチャの考え方

MCPとは何か — LLMと外部ツールをつなぐ標準規格

https://modelcontextprotocol.io/

MCP（Model Context Protocol）は、Anthropicが2024年末にオープンソースとして公開した標準規格です。LLMと外部ツール・データベース・APIの接続方法を統一し、個別のハードコード統合を不要にします。ClaudeやCursorなど主要なAIツールがすでに対応しており、「AI版USB-C」とも呼ばれています。

MCPの登場前は、LLMに外部データを渡すために「データ取得 → 整形 → プロンプトへ注入 → 出力のパース」という多段パイプラインを手動で組む必要がありました。MCPを導入すると、ツールを定義するだけでLLMが適切なものを選び、組み合わせて実行します。静的なプロンプト応答ループから、動的なエージェント的振る舞いへの転換です。

MCPの落とし穴 — ツール過多と「行動のハルシネーション」

MCPは強力ですが、万能ではありません。グラフデータベースMemgraphのCEO、Dominik Tomicevic氏はTechRadarへの寄稿で、MCPが抱える構造的な課題を指摘しています（参考）。

最大の問題は「ツール過多」です。接続できるツールが増えるほど、LLMが正しいツールを選ぶ精度は下がります。テキスト生成で起きるハルシネーションと同じ構造が、ツール選択にも現れるのです。Tomicevic氏はこれを「行動のハルシネーション」と表現しています。構文的には正しいクエリを生成しても、スキーマやデータ関係を理解していなければ、意味のない結果が返ります。

もう一つの課題はコンテキスト不足です。LLMはツールの「使い方」は知っていても、「何のために使うべきか」を判断する背景知識を持ちません。巨大なファイルシステムへのアクセス権だけ与えて、索引を渡さないようなものです。

GraphRAGが解決すること

GitHub - microsoft/graphrag: A modular graph-based Retrieval-Augmented Generation (RAG) system
A modular graph-based Retrieval-Augmented Generation (RAG) system - microsoft/graphrag
GitHub

ここで注目されているのがGraphRAGです。Microsoftが2024年に提唱し、GitHubで3万2千スター超を獲得しているオープンソースプロジェクトで、従来のRAG（Retrieval-Augmented Generation）をナレッジグラフで拡張する手法です。

従来のRAGは、ベクトル検索で関連テキストを取得してLLMに渡します。単純な質問には有効ですが、データ間の複雑な関係や暗黙の構造を扱うのは苦手です。GraphRAGはここにナレッジグラフ層を追加します。エンティティ（人物・組織・概念など）とその関係性を構造化された形式で保持し、LLMが「データがどうつながっているか」を把握できるようにします。

処理の流れはこうです。まず入力テキストからエンティティと関係性を抽出し、グラフを構築します。次にグラフのコミュニティ（密に結びついたノード群）を階層的に検出し、各コミュニティの要約を生成します。検索時には、ローカル検索（特定エンティティの周辺を探索）とグローバル検索（コミュニティ要約を横断して全体像を把握）の2モードを使い分けます。

MCP × GraphRAG — 組み合わせで生まれる実用性

MCPとGraphRAGは競合する技術ではなく、補完関係にあります。役割を整理すると次のようになります。

MCPは「接続と実行」を担います。LLMがどのツールを呼び出し、どんなアクションを実行するかの仕組みです。GraphRAGは「文脈と判断」を担います。構造化された知識を提供し、LLMが適切なツールを選び、妥当なアクションを取れるよう導きます。そしてRAGは「関連情報の取得」を担い、ベクトル検索でテキストベースの参考情報を補完します。

この3層構造により、ツール選択の精度が上がります。ナレッジグラフがエンティティ間の関係を保持しているため、LLMはタスクに関連するツールを正確に特定できます。また、ナレッジグラフにアクセス権限や依存関係、ビジネスロジックをエンコードしておけば、ガードレールとして機能します。LLMが不適切な操作を実行するリスクを構造的に抑えられるのです。

導入時の注意点

GraphRAGの導入にはコストがかかります。インデックス構築時にLLMを呼び出してエンティティを抽出するため、データ量に応じたAPI費用が発生します。また、ナレッジグラフの鮮度を保つには定期的な再構築が必要です。

ツール過多の問題には、MCPで公開するツールを最小限に絞り、タスクごとにスコープを明確に定義するアプローチが有効です。複雑なワークフローは小さなステップに分解し、各ステップに必要な機能だけを渡す設計が推奨されています。

セキュリティも無視できません。MCPを通じた不正なデータアクセスやプロンプトインジェクションによる意図しないアクション実行など、ツール接続が増えるほどリスクも増大します。どのツールが使われ、なぜ選択され、どんなアクションが実行されたかを追跡できる仕組みが不可欠です。

まとめ

MCPはLLMと外部システムをつなぐインフラとして定着しつつありますが、接続だけでは信頼性の高いAIシステムは作れません。GraphRAGでコンテキストの質を高め、ツール選択に構造的な判断根拠を与えることで、実用レベルのエージェント構築に近づきます。AIエージェントの精度に悩んでいるなら、接続方法よりもコンテキスト設計を見直すのが先決です。