Verification-First Agentとは：回答を証拠から検証する設計
この記事で学べること
- 回答の自然さやAIの自己評価だけでは検証が完了しない理由
- 回答を作る役割と、証拠を確かめる役割を分ける理由
- AI以外の確認方法を優先して選ぶ基準
- 主張・証拠・確認結果の対応表を承認と実行へつなぐ方法
Verification-First Agentは主張・証拠・確認方法を同時に設計する
Verification-First Agentは、AIが主張を作る時点で、根拠と確認方法も対応付ける設計です。2026年7月30日のGoogle Researchと8月18日のAnthropicの発表は、AIの成果を出典、実行記録、外部実験へ結び付ける方向を示しました。承認、支払い、診断支援、公開、システム変更へ使う回答は、確認できた範囲だけを次の処理へ進めます。
この記事では、「Agentの回答を別のAIの評価だけに頼らず、第三者が追跡して検証できる形にするにはどうすればよいか」という問いに焦点を当て、確認済みの変化、影響を受ける判断、現時点で残る不確実性を扱います。
最後まで読むと、「Agentの回答を別のAIの評価だけに頼らず、第三者が追跡して検証できる形にするにはどうすればよいか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
回答を作る役割と証拠を確かめる役割を分ける
Generatorは回答や候補を作る役割、Verifierはその主張が証拠に支えられているかを確認する役割です。同じAIに「もう一度確認して」と依頼すると誤りを見つけられる場合もありますが、同じ前提や出典の誤りを共有すると、誤った結論へ再び同意する可能性があります。
Anthropicの蛋白質設計では、Claudeが複数の専門モデルを組み合わせて候補を作り、Adaptyv BioとTwist Bioscienceが実験室で独立に検証しました。公表された15の対象のうち14で結合する蛋白質が確認されています。[1] AIの自己判定ではなく、別の主体と方法による実験が結果を確かめました。
Google ResearchのScience Oneは、論文を作った後から出典を探すのではなく、主張を生成する時点で論文、コード、実験ログ、結果表へ結び付けるChain-of-Evidenceを提案しました。[2] 同研究は実験的な研究Prototypeであり、本番向け製品ではありません。報告された成果を、そのまま一般業務の性能保証へ置き換えることはできません。
証拠は主張を作る時点で結び付ける
回答が完成してから根拠を追加すると、文章に合う資料だけを後付けする危険があります。Verification-Firstでは、Agentが主張を作るたびに、証拠の識別子、取得時点、適用した規則、確認方法を同時に記録します。
たとえば経費精算Agentが「交通費12,300円は承認可能」と判断するなら、領収書の金額、出張期間、経費規程の上限、経路情報を対応付けます。回答文に資料名を表示するだけではなく、金額が一致したか、日付が期間内か、上限以下かを機械的に再実行できる形にします。
証拠は、主張の種類に合っている必要があります。存在する資料へのリンクは、数値の計算が正しいことを証明しません。テストに合格した記録は、利用規約への適合を単独では証明しません。主張と証拠の関係を細かく分けると、不足している確認が見えます。
検証方法は独立性と再現性で選ぶ
Verifierを別のLLMに限定する必要はありません。答えが一意に計算できる、規則が明文化されている、元システムへ照会できる場合は、生成AIより決定的な方法を優先できます。
| 主張 | 優先する確認方法 | 人へ送る条件 |
|---|---|---|
| 合計金額 | Calculator、SQL、再計算 | 入力不足、通貨不一致 |
| 規程への適合 | Rules Engine、版を固定した規程 | 例外条項、規程の競合 |
| 元データの存在 | Source API、署名済み文書 | 接続不能、出所不明 |
| Softwareの動作 | Unit Test、隔離実行 | 外部影響、再現不能 |
| 文章の妥当性 | 出典照合、専門家レビュー | 解釈が複数、影響が大きい |
| 物理的な性質 | 実験、測定、現物確認 | 測定条件が未確定 |
LLM-as-a-Judgeは、自由記述の品質や説明の分かりやすさを評価する補助手段として利用できます。ただし、金額、在庫、権限、物理的な結果など、外部に確認可能な事実までAIの意見だけで閉じないようにします。
主張・証拠・確認結果の対応表で判断を追跡する
Claim-Evidence Ledgerは、Agentの主張、証拠、検証結果、次の処置を一行で対応付ける台帳です。文章の引用一覧ではなく、どの主張が、どの確認に合格したかを追跡するために使います。
| 項目 | 記録例 |
|---|---|
| Claim ID | expense-2026-0819-07-limit |
| 主張 | 申請額は交通費上限以内 |
| 証拠 | receipt-07、policy-v4 §3.2 |
| 証拠の版と取得時刻 | policy-v4、2026-08-23 09:30 JST |
| 検証方法 | receipt totalと上限を決定的に比較 |
| 結果 | pass |
| 未確認事項 | 利用区間の業務目的 |
| 処置 | 人の確認へ送る |
| 実行者と承認者 | Agent ID、担当者ID |
一つの回答に複数の主張がある場合は、行を分けます。「申請を承認できる」という結論には、金額、日付、用途、領収書、重複申請など複数の条件があるためです。結論だけを一行にすると、どの条件が未確認か分からなくなります。
検証範囲と例外処理を指標にする
正答率だけでは、確認できなかった主張がどれだけ残ったか分かりません。運用では、Verification Coverage（検証対象にした主張のうち、必要な証拠と確認結果がそろった割合）と、未対応の例外を分けて記録します。
確認したい指標には、次があります。
- 証拠が一つ以上対応した主張の割合
- 主張を直接支える証拠まで確認できた割合
- 決定的な方法で再実行できた主張の割合
- 証拠不足、矛盾、期限切れで人へ送った件数
- 誤って実行を許可した件数と、誤って停止した件数
- 実行後に証拠を再現できなかった件数
Coverageを上げるために、弱い資料を形式的に付けてはいけません。証拠がない場合はunknown、証拠同士が異なる場合はconflictとして扱い、Retry、追加取得、人の確認、処理停止のいずれへ進むかを決めます。
Anthropicの実験は、大量のGPU計算と数週間の外部実験を含みます。[1] Google Researchの結果も研究課題での評価です。[2] 一般企業が再利用すべきなのは計算規模や数値ではなく、Generator、証拠、独立Verifier、人の判断を分ける構造です。
まとめ：Claim-Evidence Ledgerから影響の大きな判断の検証を始める
Verification-First Agentは、回答の後に自信を問い直す方法ではなく、主張を作る時点で証拠と検証方法を結び付け、合格した範囲だけを判断や実行へ進める設計です。AIが候補を作り、規則、計算、元システム、人、物理測定が適切な範囲を検証します。
最初は一つの高影響な判断を選び、結論を小さなClaimへ分け、Claim-Evidence Ledgerへ証拠と確認方法を記録します。未確認を失敗として隠さず、人へ送る条件として明示すると、Agentの回答品質と業務上の説明責任を同じ流れで扱えます。
参考文献
- 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日
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。