ProvenanceGuard：Multiverse ComputingがMCPエージェント向けに「出典が正しいか」を検証する手法を提案

何が起きたのか

Multiverse Computingのチーム（著者はAntonio Tiene、Ander Alvarez Sanz、Oliver Wirjadi）は2026年9月29日、Hugging Faceのブログで論文『ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents』を紹介する記事を公開した。同チームによると、この手法はModel Context Protocol（MCP）を通じて複数のツールを使うAIエージェント向けに設計されている。MCPは、AIエージェントが検索ツールやデータベースなど外部のツールを呼び出して情報を集めるための仕組みだ。

同チームの説明によれば、エージェントはMCPを通じて検索ツールの呼び出し、構造化された患者記録やアカウント記録の参照、データベースの照会、メタデータ（データの属性情報）の取得を行い、それらを一つの回答にまとめることができる。問題は、RAGAS faithfulness、MiniCheck、AlignScore、SummaCといった一般的な検証手法が、通常すべての証拠を統合してから主張に根拠があるかを判断し、どのツール出力がその主張を裏付けているかは一般に示さない点にある。

詳しい説明を読む

情報源を収集し、独立検証を行ってから Jev が判断します。

「クロスソース混同」とは何か

同チームは、対処すべき問題を「クロスソース混同」（cross-source conflation）と呼ぶ。ある主張が証拠のどこかでは確かに成り立つのに、誤った出典に帰属されてしまう現象だ。同チームの例では、カスタマーサポートのエージェントが「アカウント記録によると、このプランには30日間の返金期間が含まれます」と回答する。返金期間自体は事実かもしれないが、実際にはアカウント記録ではなくポリシー文書に書かれている。証拠を統合して見ればこの文には根拠があるように見えるが、個別に見れば帰属は誤っている。

同チームは臨床エージェントの例も挙げている。患者カルテのツールから得た個人の服薬情報が、回答の中で医学文献の知見として語られれば、誤解を招く。同チームは、データの機微な場面では、誤った帰属は誤った事実と同じくらい有害になり得ると考えている。

ProvenanceGuardの仕組み

同チームの説明によると、ProvenanceGuardは既存のMCPエージェントの中身には手を加えず（ブラックボックスのまま）、その上に置く「生成後の検証レイヤー」である。エージェントが回答を生成した後に動作し、取得済みのMCPログ（ツール出力とその出典IDを含む）を読み取る。エージェントの再学習は不要で、証拠を単一の匿名コンテンツに統合せず、出典の識別情報を最後まで保持する。同チームによれば、次の5つのステップを順に実行する。

1. 回答を具体的な主張に分解する。
2. 各主張について最も関連性の高い出典を見つける。
3. その出典が本当にその主張を裏付けているかを確認する。
4. その出典が、回答が明示または示唆する出典と一致するかを照合する。
5. 各主張の出典判定と、回答全体としての通過またはブロックの判断を出力する。

同チームによると、実験ではローカルモデルを使用した。MiniLMが関連する出典の特定を、DeBERTa NLI検証モデル（ある文が別の文を裏付けるかを判定するモデル）が裏付けの確認を、ローカルの言語モデルが主張の分解を担う。検証器は数値、日付、識別子などのリテラル値を厳格にチェックし、出典にない値は文がもっともらしく聞こえても通過しない。ブロックされた回答はRARR型の修復ステップで、出典に基づく書き換えか、安全な代替文（フォールバック文）への置き換えを試み、再検証される。同チームは、これらのモデルは評価時の設定にすぎず必須条件ではないこと、クラウドモデルに切り替える場合は再テストと再調整が必要であることを強調している。

同チームが公表したテスト結果

同チームによると、テスト対象は患者カルテや研究論文などのツールを使う医療エージェントで、実際のログを計281件取得した。主要なテストでは、人間の専門家が、システム開発に使ったデータとは別に取り分けておいた（ホールドアウト）40件の回答に含まれる361件の主張を確認した。その結果、専門家が通すべきでないとした139件の主張のうち、ProvenanceGuardは138件をブロックし、1件を通過させた。同時に、専門家が根拠ありとした67件の主張がレビューまたは修復に回された。出典を特定できる主張については、約86%で正しい出典を選んだと同チームは述べている。

同チームは同じ主張で他の4つの検証ツールとも比較した。下表の「Reject/block F1」は、ブロックすべき主張を捉えつつ不要なブロックを避けられているかを示す指標で、1に近いほど良い。

同チームはさらに次のように報告している。主張された出典を差し替え、裏付けとなる証拠は残した50件の管理されたケースでは、ProvenanceGuardはすべてを検出した。修復については、全ログテストでブロックされた173件の回答はすべて処理されたが、そのうち144件は実質的な書き換えではなくフォールバック文で終わった。再構築した複数出典のテストログでは、ブロックされた59件の回答がすべて処理され、フォールバック文で終わったのは2件のみだった。性能面では、同チームのローカル設定で1回答あたり約0.5秒を要するという。

限界と改善点

同チーム自身も弱点を指摘している。類似した出典が複数ある難しいテストでは、ProvenanceGuardのブロック判断のF1は0.846だったが、正確な出典を正しく特定できた主張は50.3%にとどまった。同チームは、類似した出典の区別が引き続き重要な改善課題だとしている。また、テストでは保守的な設定をとっており、根拠のない主張を通すよりも、根拠のある主張の一部を再確認に回すことを選ぶ。これは実運用で人手によるレビューの負担が増える可能性を意味する。

一般の読者にとっての意味

複数のシステムを同時に参照してから質問に答えるAIアシスタントは増えている。一般のユーザーにとって、この研究が示すのは次の点だ。AIが「〇〇の資料によると」と言うとき、その事実が本当であっても、実際にその出典から来たとは限らない。医療、カスタマーサポート、金融などの場面では、こうした誤った帰属が人々の情報判断に影響し得る。

同チームによると、NVIDIA NVFlowは金融エージェント向けにオプションの根拠検証ステージを統合した。このステージは、エージェントが取得したSECの抜粋と照らして完成した回答を検証し、ProvenanceGuardの出典を考慮した検証手法を採用している。同チームはまた、ProvenanceGuardがUC Berkeleyで開催されたAgentic AI Summit 2026でポスター発表されたとしている。一般のユーザーにとっては、重要な情報についてはAIが引用した元の出典を自分で確認することが、現時点でも現実的な対応だ。

よくある質問

このトピックの最新ニュースを見る

• AIニュース