ProvenanceGuard：MCPエージェント向けソース認識型事実検証手法

記事のサマリー（TL;DR）

• Multiverse Computingは、Model Context Protocol（MCP）を利用するLLMエージェントの回答を検証する手法「ProvenanceGuard」を論文「ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents」として発表しました。
• 既存の事実性検証手法（RAGAS faithfulness、MiniCheck、AlignScore、SummaCなど）は、証拠をまとめて扱うため、ある主張がどのツール出力（ソース）によって支持されているか、回答が示すソースと実際に支持しているソースが一致しているかを区別できないという課題に対応するものです。
• 医療エージェントの実トレース281件から抽出した361件の主張を人手で確認した評価では、専門家が「不支持」と判断した139件の主張のうちProvenanceGuardは138件を検出し、見逃しは1件でした。

詳細

問題設定：どこかで支持されていることと、正しいソースで支持されていることは別問題

Model Context Protocol（MCP）を利用するツール使用型のLLMエージェントは、検索ツールの呼び出し、構造化された患者記録や口座記録の参照、データベースへの問い合わせ、メタデータの取得などを組み合わせ、それらを一つの回答に統合します。そのため、従来の「事実性」の検証だけでは捉えきれない問題が生じるとされています。

RAGAS faithfulness、MiniCheck、AlignScore、SummaCといった既存の検証システムの多くは、証拠がすでにプールされた状態で、ある主張がその証拠全体によって支持されているかどうかを判定します。しかし通常の形式では、どのMCPツールの出力が各主張を支持しているのか、また回答が名指ししているソースと実際に支持しているソースが一致しているのかまでは示しません。

筆者らが「cross-source conflation（ソース間の混同）」と呼ぶ失敗パターンは、証拠のどこかには真である主張が、誤ったソースに紐づけられてしまうケースです。ソースを区別しない検証器は、その事実がプール内に存在する限り通過させてしまいますが、ソースを認識する検証器はそれを通過させるべきではないとされています。

例として、カスタマーサポートエージェントが「口座記録によると、このプランには30日間の返金期間があります」と回答するケースが挙げられています。返金期間自体は実在する事実であっても、それが記載されているのはポリシー文書であり、回答が名指しする口座記録ではない場合があります。両者をまとめて扱えば主張は支持されているように見えますが、分けて扱えば帰属が誤っていることが分かります。データの取り扱いに敏感な場面では、誤った帰属は誤った事実と同程度に問題になり得るとされています。同様のパターンは臨床エージェントでも見られ、患者履歴ツールから得られた患者固有の投薬情報を、医学文献由来の知見であるかのように回答が提示した時点で、誤解を招く内容になるとしています。

ある主張が一つのMCPソースによって支持されていても、回答は別のソースに帰属させてしまうことがあります。ソースを区別しない採点方式は、プールされた証拠の中に支持があることを確認して通過させますが、ProvenanceGuardは、支持しているソースが回答の述べる（あるいは暗に示す）ソースと一致するかどうかを別途確認します。

ProvenanceGuardの仕組み

ProvenanceGuardは、ブラックボックスのMCPエージェントの上に乗る、生成後の検証レイヤーです。エージェントが回答を生成した後に動作し、証拠を一つの匿名化されたコンテキストにまとめることはありません。代わりに、ソースの識別情報をパイプライン全体で保持します。エージェントの再学習を行わずに、ツール出力とそのソースIDを含むMCPトレースを読み取ります。

その上で、以下の5つの処理を順に実行します。

1. 回答を個別の主張に分解する
2. 各主張に最も関連するソースを特定する
3. そのソースが実際にその主張を支持しているかを確認する
4. そのソースと、回答が名指しまたは示唆しているソースを比較する
5. 主張ごとのソース判定と、回答全体としての許可・ブロックの判定を出力する

ブロックされた回答は、RARR方式の修復処理を経て再検証されることがあります。

論文の実験では、キャプチャしたトレースを管理された環境でオフライン処理できるよう、ローカルモデルを使用しています。具体的には、関連ソースの特定にMiniLM、ソースが主張を支持しているかの検証にDeBERTaベースのNLI検証モデル、回答を主張に分解する処理にローカル言語モデルを用いています。検証器は数値、日付、識別子といったリテラルな値も厳密にチェックし、文として自然に聞こえるというだけでは、ソースに存在しない数値や日付、識別子を通過させることはないとしています。較正されたこれらの意思決定ステップはこれらの信号を統合します。回答がブロックされた場合、RARR方式の修復ステップがソースに基づいた修正または安全なフォールバックを試み、それを検証器が再度チェックします。

これらの具体的なモデルは評価に用いた構成であり、ProvenanceGuardの必須要件ではないと説明されています。同じ主張・ソース・判定のステップは、チームがクラウドサービスを選好する場合にはホスト型モデルにも適用可能であり、その場合は新たなテストと較正が必要になるとしています。報告されている結果はローカル構成によるものです。その保守的な判定方針は、速さよりも正しいソースを特定することが重視される、データの取り扱いに敏感なレビュー用途に適しているとされています。

評価結果

ProvenanceGuardは、患者記録や研究論文などのツールを使用した医療エージェントの回答に対して評価されました。これにより281件の実トレースが得られました。医療分野は、患者記録由来の事実と一般的な研究由来の事実を同一のソースとして扱うことができないため、有用なテストケースであるとしています。同様の手法は、エージェントがツール出力とソースIDの記録を保持している限り、他分野にも適用可能だとしています。

主要なテストでは、システム開発に使用したデータとは別に用意した40件の回答から抽出した361件の主張を、人間の専門家が確認しました。最も直接的な結果として、専門家が「通過させるべきではない」と判断した主張139件のうち、ProvenanceGuardは138件を検出し、1件を見逃しました。また、専門家が「支持されている」と判断した主張のうち67件についても、レビューまたは修復に回しました。これは、支持されている主張の一部を再確認する方向に倒した、慎重な設定を反映しているとしています。ソースを特定できる主張については、このテストで約86%の確率で正しいソースを選択できたとしています。

同一の主張セットに対して、他の4つの支持検証手法との比較も行われました。ProvenanceGuardは、論文の指標である「ブロックすべき主張をどれだけ捕捉しつつ、不要なブロックを避けられるか」という評価で最も高いスコアを記録しました。比較対象となった他の検証手法は、どのツール出力が各主張を支持しているかを示すものではありませんでした。ProvenanceGuardはその対応関係を記録するため、レビュアーは各主張についてチェックされたソースと、それに基づく判定結果を確認できます。

比較結果（Reject/Block F1、主張とソースIDの対応関係の出力有無）は以下の通りです。

この結果は、同一の評価用主張セットに対する二値の支持判定指標に基づくものです。ProvenanceGuardは、ブロック判定の精度でソースを区別しない手法と同等かそれ以上のスコアを示しつつ、主張ごとのソース判定も生成するとしています。

類似したソースが複数存在する場合の検証

複数の類似したソースを含む、より難易度の高い別のテストでは、ProvenanceGuardはブロックすべき主張の判定でF1スコア0.846を記録しましたが、正確なソースを特定できたのは主張の50.3%にとどまりました。類似したソースを区別することは、今後改善が必要な重要な課題であるとされています。

また、誤帰属に焦点を当てた制御実験も行われました。支持する証拠はそのままに、名指しされたソースのみを変更した50件のケースについて、ProvenanceGuardは50件すべての入れ替わりを検出しました。この結果は、明確なソースの誤りを検出できることを示す一方、前述のテストは多数のもっともらしいソースの中から選択することの難しさを示しているとしています。

ブロックされた回答の修復

ブロックは、ブロックされた回答に対して何らかの対処ができて初めて意味を持つとしています。RARR方式の修復ループと組み合わせたフルトレースでの実行では、ブロックされた173件の回答すべてが処理され、そのうち144件はフォールバックテキストで終わっています。これは実質的な書き換えではなく、検証不可能な回答を作り出すよりも避けることをシステムが選択した結果であると説明されています。

再構成した複数ソースのテストトレースでは、新たに行った修復実行により、当初ブロックされた59件すべての回答が処理され、最終的にフォールバックとなったのはわずか2件でした。

オフラインのゲートとしてのオーバーヘッドは小さく、報告されているローカル構成では1回答あたりおよそ0.5秒程度で、NLIおよびルーティングの呼び出し自体は数十ミリ秒単位であるとしています。

Multiverse Computingにとっての位置づけ

エージェントが単一パッセージのRAGから複数ツールを用いるMCP構成へ移行するにつれ、ある事実が実際にどのソースから来たのかという問いは、些末な付随情報ではなく、事実性の意味そのものの一部になりつつあるとしています。ProvenanceGuardは、そのソースとの結びつきを主張ごとに可視化します。Multiverse Computingにとっては、必要に応じて機密性の高いトレースを管理された環境に保ちながら、既存のエージェントを検証する手段になるとしています。今回の医療分野の研究は一つの利用例であり、エージェントのトレースがツールとソースを保持している限り、同様の手法を他の分野にも適用できるとされています。

この適用例はすでにNVIDIA NVFlowにも見られ、同システムの金融エージェント向けに、任意で利用できるグラウンディング検証ステージが統合されています。これは、完了した回答を、エージェントが取得したSEC（米証券取引委員会）の抜粋と照合し、元のロールアウトや学習データを変更することなく、別個の判定結果を保存するものです。NVFlowでの実装はProvenanceGuardのソース認識型検証アプローチを使用しており、上述の修復ループはより広範な研究システムに属するものだとしています。

ProvenanceGuardは、UCバークレーで開催されたAgentic AI Summit 2026においてポスター発表としても紹介されました。

ルーティングとNLIの導出過程、較正に関するアブレーション実験、複数ソースを用いたストレステストの詳細、完全な結果表を含む技術詳細は、Hugging Face上の論文全文で確認できるとしています。