Verification-First Agentとは：AIの回答を証拠で確かめる設計
この記事で学べること
- 自然な文章やAI自身の評価だけでは、回答の正しさを確かめられない理由
- 回答を作る役割と、証拠を確認する役割の違い
- 計算や規則との照合など、AI以外の検証方法の選び方
- 主張・証拠・確認結果を記録し、承認や実行につなげる方法
Verification-First Agentの基本：回答・根拠・確認方法の一体設計
AIが「この経費は承認できます」と回答しても、文章が自然であることや、AI自身が正しいと評価することだけでは、承認の根拠になりません。金額や日付、経費規程などを確認する必要があります。
Verification-First Agent（回答を作る段階から、証拠による検証を組み込むAIエージェントの設計）は、この確認をあらかじめ組み込む考え方です。AIエージェント（目的に応じて情報収集やツール操作などを行うAI）が判断を示すたびに、その根拠と確認方法も記録します。この記事では、こうした確認の対象となる個々の内容を「主張」と呼びます。
2026年7月30日のGoogle Researchと、8月18日のAnthropicの発表では、AIの成果を出典や実行記録、外部での実験に結び付ける取り組みが示されました。[1][2]
この考え方は、AIの回答を承認、支払い、診断支援、情報の公開、システム変更に使う場面で関わってきます。次の判断や処理に使うのは、必要な確認ができた範囲に限るという設計です。
では、別のAIによる評価だけに頼らず、第三者が回答の根拠をたどって確かめるには、何が必要なのでしょうか。以下では、研究事例と経費精算の例を使い、検証の方法、判断へのつなぎ方、現時点での限界を整理します。
回答の作成と検証の役割分担
回答や候補を作る役割をGenerator（生成役）、その内容が証拠に支えられているかを確かめる役割をVerifier（検証役）と呼びます。
同じAIに「もう一度確認して」と頼むことで、誤りが見つかる場合もあります。ただし、再確認でも同じ誤った前提や出典を使えば、同じ結論を正しいと判断する可能性があります。そこで、回答の作成と検証を分け、別の主体や方法で確認することが必要になります。
Anthropicのタンパク質設計の研究では、Claudeが複数の専門モデル（特定の用途に特化したAIモデル）を組み合わせ、候補を作りました。その候補を、Adaptyv BioとTwist Bioscienceが実験室で独立に検証しています。公表された15の対象のうち14で、対象に結合するタンパク質が確認されました。[1]
この事例では、AIの自己評価に加えて、外部の組織が実際の実験で結果を確かめています。
Google ResearchのScience Oneでは、主張を生成する時点で、関連する論文、コード（プログラム）、実験ログ（実験の実行記録）、結果表を結び付ける仕組みが提案されました。これがChain-of-Evidence（主張から根拠をたどれるようにした証拠のつながり）です。[2]
ただし、Science Oneは研究用の試作システムであり、実際の業務で使うための製品ではありません。研究で報告された成果が、そのまま一般業務での性能を保証するわけではない点に注意が必要です。
主張と証拠の同時記録
回答が完成した後で根拠を探すと、書いた文章に都合のよい資料だけを選んでしまうおそれがあります。そのため、Verification-Firstでは、AIが主張を作る時点で次の情報も記録します。
- 証拠の識別子（資料やデータを特定するID）
- 証拠を取得した日時
- 判断に適用した規則
- 主張の正しさを確認する方法
たとえば、経費精算を行うAIが「交通費12,300円は承認可能」と判断したとします。この判断には、領収書の金額、出張期間、経費規程の上限、経路情報を対応付けます。
さらに、申請額と領収書の金額が一致するか、利用日が出張期間内か、金額が上限以下かを、システムで繰り返し確認できるようにします。資料名を回答に添えるだけでは、これらを確認したことにはなりません。
証拠は、確かめたい内容に合っている必要があります。 実在する資料へのリンクがあっても、計算の正しさまでは証明できません。また、ソフトウェアの動作テストに合格しても、それだけで利用規約に適合しているとは言えません。
一つひとつの主張について「この証拠で何を確かめられるか」を分けて考えると、まだ確認できていない点が明確になります。
検証方法の選定基準：独立性と再現性
検証役は、別のLLM（大規模言語モデル。文章の理解や生成を行うAI）に限りません。計算で答えが決まる場合や、規則が明文化されている場合、元のシステムに問い合わせられる場合は、それぞれに合った確認方法を優先できます。
選ぶ際の基準は、独立性（回答を作ったAIと同じ誤りに依存しないこと）と再現性（同じ条件で確認をやり直せること）です。たとえば合計金額なら、決定的な方法（同じ入力と規則から同じ結果が得られる方法）である再計算が使えます。
| 確かめたい内容 | 優先する確認方法 | 人による確認が必要な場合 |
|---|---|---|
| 合計金額 | 計算ツールやSQL（データベースの検索・集計に使う言語）による再計算 | 入力情報が足りない、通貨が一致しない |
| 規程への適合 | ルールエンジン（定めた規則に沿って条件を判定する仕組み）と、使用する版を固定した規程 | 例外条項に該当する、規程同士が矛盾する |
| 元データの存在 | 元システムのAPI（システム間でデータをやり取りするための接続点）への照会や、署名済み文書の確認 | 接続できない、データの出所が分からない |
| ソフトウェアの動作 | 単体テスト（機能ごとの動作確認）や、隔離環境（ほかのシステムに影響を与えない環境）での実行 | 外部への影響がある、同じ結果を再現できない |
| 文章の妥当性 | 出典との照合や、専門家による確認 | 複数の解釈がある、判断の影響が大きい |
| 物理的な性質 | 実験、測定、現物確認 | 測定条件が決まっていない |
LLM-as-a-Judge（LLMを評価役として使う方法）は、自由記述の品質や説明の分かりやすさを確認する補助手段として使えます。ただし、金額、在庫、権限、実験結果など、外部で確かめられる事実は、AIの評価だけで確認を終えないようにします。
判断の根拠をたどるための証拠台帳
検証結果を承認や実行につなげるには、「何を、どの証拠で確認し、その後どう扱ったか」を記録する必要があります。
そのための仕組みがClaim-Evidence Ledger（主張・証拠・検証結果・次の対応を結び付けた台帳）です。以下では「証拠台帳」と呼びます。引用した資料の一覧に加えて、どの主張がどの確認に合格したかを記録します。
経費精算を例にすると、一つの主張に対して次のような情報を残します。
| 記録する項目 | 記録例 |
|---|---|
| Claim ID（主張を識別するID） | expense-2026-0819-07-limit |
| 主張 | 申請額は交通費の上限以内である |
| 証拠 | receipt-07（領収書）、policy-v4 §3.2（規程第4版の3.2項） |
| 証拠の版と取得日時 | policy-v4、2026年8月23日9時30分（日本時間） |
| 検証方法 | 領収書の合計金額と規程の上限を、同じ入力なら同じ結果になる方法で比較 |
| 検証結果 | pass（確認条件を満たした） |
| 未確認の事項 | 利用区間の業務目的 |
| 次の対応 | 人による確認へ回す |
| 実行者と承認者 | AIエージェントのID、担当者のID |
この例では、金額が上限以内であることは確認できています。しかし、利用区間の業務目的は未確認なので、人の確認へ回します。
一つの回答に複数の主張が含まれる場合は、主張ごとに行を分けて記録します。「申請を承認できる」という結論には、金額、日付、用途、領収書、重複申請の有無など、複数の条件が関わるためです。結論だけを一行にまとめると、どの条件が未確認なのか分からなくなります。
運用の評価指標と未確認事項への対応
正答率だけでは、確認できていない主張がどれだけ残っているかは分かりません。そこで、Verification Coverage（検証対象の主張のうち、必要な証拠と確認結果がそろった割合）と、まだ対応していない例外を分けて記録します。
運用状況を把握するための指標には、次のものがあります。
- 証拠が一つ以上ひも付いている主張の割合
- その証拠が主張を直接支えていることまで確認できた割合
- 同じ入力と規則で検証を再実行できた主張の割合
- 証拠不足、証拠の矛盾、期限切れを理由に、人の確認へ回した件数
- 誤って実行を許可した件数と、誤って処理を止めた件数
- 実行後に、検証に使った証拠を再現できなかった件数
検証できた割合を高く見せるために、関連の弱い資料を形式的に付けても意味はありません。証拠がなければunknown（未確認）、証拠同士が食い違っていればconflict（矛盾あり）として記録します。
そのうえで、Retry（再試行）、証拠の追加取得、人による確認、処理の停止のうち、どの対応に進むかを決めます。未確認の状態を残し、次の対応を明確にすることも、検証の仕組みの一部です。
研究成果を業務に取り入れる際の留意点
Anthropicの実験には、大量のGPU（多くの計算を並列に処理する半導体）を使った計算と、数週間にわたる外部での実験が含まれています。[1] Google Researchの結果も、研究課題を対象にした評価です。[2]
一般企業で参考になるのは、回答を作る役割、根拠となる証拠、独立した検証役、人による判断を分ける構造です。研究と同じ計算規模や成果の数値を、自社の業務にそのまま当てはめることはできません。
まとめ：証拠に基づく判断と未確認事項の明示
Verification-First Agentの中心にあるのは、AIが主張を作る時点で証拠と確認方法を結び付け、確認できた範囲を判断や実行に使う設計です。AIが作った候補を、規則との照合、計算、元システムへの問い合わせ、人の確認、実験や測定などで確かめます。
導入の検討では、影響の大きい判断を一つ取り上げ、結論を支える条件を分けてみると、必要な検証を整理しやすくなります。それぞれの条件について、証拠と確認方法を証拠台帳に記録し、未確認のまま残る事項と、人の確認が必要な条件を明示します。
何が確認済みで、何が未確認なのかを説明できれば、回答の品質を確かめるだけでなく、業務上の判断の理由も後からたどれるようになります。
参考文献
- Anthropic, How Claude is accelerating protein design and analytical chemistry, 2026年8月18日
- Google Research, Science One Framework: A verifiable autonomous research framework via Chain-of-Evidence, 2026年7月30日
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。