Multiverse Computing、MCPエージェントの情報源誤りを防ぐ検証技術「ProvenanceGuard」を発表

要点

• Multiverse Computingの研究チームが、MCP（Model Context Protocol）を利用するAIエージェント向けの新検証手法「ProvenanceGuard」を発表した。

• 複数の外部ツールから得た証拠を統合する際に発生する、事実は正しいが出典が誤っている「情報源の混同（Cross-source conflation）」を防止する。

• エージェント本体の再学習を必要とせず、ツールの実行履歴（トレース）を活用して回答生成後の検証を行う。

• 回答を個別の主張に分解して情報源との照合を行い、主張ごとの判定および回答全体の公開可否（許可または遮断）を決定する。

• Multiverse Computingの研究チームは2026年9月29日、MCP（Model Context Protocol：AIモデルと外部ツールやデータを接続する標準仕様）を活用するAIエージェント向けに、回答の事実性と参照元を検証するフレームワーク「ProvenanceGuard」を発表した。同技術に関する研究論文『ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents』は、Hugging Faceのブログ記事および学術リポジトリのarXiv上で公開されている。

複数ツールの連携で生じる「情報源の混同」という課題

近年、外部ツールを呼び出して動作する大規模言語モデル（LLM）エージェントは、MCPを介して検索エンジン、アカウント情報や患者記録のデータベース、メタデータ取得ツールなど、多様な情報源にアクセスしてひとつの回答を作成できるようになっている。

しかし研究チームによると、こうした複数ツールの利用によって、回答の事実性を評価する難易度が上がっているという。RAGAS faithfulnessをはじめ、MiniCheck、AlignScore、SummaCといった従来の事実性検証システム（LLMの回答が根拠資料に基づいているかを判定するツール群）は、収集されたすべての証拠をひとつの大きな情報プールとしてまとめてから検証を行う「情報源を区別しない（Source-blind）」設計が一般的だった。この手法では、集められた証拠のどこかに該当する記述があれば検証を通過してしまうため、回答内で示された情報源と実際の出所が食い違っているケースを検知できないという問題があった。

研究チームはこの誤りのパターンを「情報源の混同（Cross-source conflation）」と呼んでいる。たとえば、カスタマーサポート向けのエージェントが「アカウント記録によると、このプランには30日間の返金期間が設定されています」と回答した場合、返金期間に関する規定自体は規約文書（ポリシー文書）に実在していても、アカウント記録には記載されていないことがある。証拠全体を合算すると事実自体は合致しているように見えるが、情報源の帰属としては誤りとなる。

同様の事例は医療分野のエージェントでも生じる。患者の病歴取得ツールから得られた個別の投薬内容を、回答内で医学論文などの文献から得られた一般的な知見であるかのように説明してしまうと、利用者に重大な誤解を与えかねない。研究チームは、機密性の高いデータを扱う環境においては、事実そのものの誤りだけでなく、情報の出所の誤りも同様に重大なリスクになり得ると指摘している。

再学習を行わずに機能する検証レイヤー「ProvenanceGuard」

こうした課題に対応するため、研究チームは情報源を意識した検証（Source-Aware Verification）を行う層として「ProvenanceGuard」を開発した。

ProvenanceGuardは、既存のMCPエージェントの内部構造を変更したり再学習させたりすることなく、回答生成後の検証レイヤー（ポストプロセス）として機能する。証拠をひとつの匿名のコンテキストに統合してしまうのではなく、処理パイプラインの全体にわたって各ツールの識別情報（ソースID）を保持し続ける点が特徴だという。

5段階の処理プロセスによる検証と判定

ProvenanceGuardは、エージェントが回答を作成する際に記録されたMCPの実行ログ（ツール出力とソースIDを含むトレース）を読み込み、以下の5つの処理を順番に実行する。

1. 主張の分解: エージェントが生成した回答文を、検証可能な個別の主張（クレーム）単位へと細かく分解する。
2. 情報源の特定: 分解された各主張に対して、最も関連性の高い情報源（ツール出力）を割り当てる。
3. 裏付けの確認: 割り当てられた情報源が、該当する主張を実際に支持しているかどうかを自然言語推論（NLI）などを用いて検証する。
4. 言及元との照合: 主張を支持している実際の情報源と、回答文の中で明示的または暗黙的に示されている情報源が一致しているかを比較する。
5. 最終判定の出力: 主張ごとの情報源判定結果を出力するとともに、回答全体としてそのまま出力してよいか（許可）、あるいは修正が必要か（ブロック）の判定を下す。

ブロックされた回答は修復プロセスへと送られる仕組みとなっており、これによって事実と出所の双方が正確な情報のみを利用者に提示できるとしている。