🎥 YouTubeでも公開しています
独立Verifier Agent：AIに自己採点をさせない開発・運用設計
AIエージェントに設計、実装、テスト、レビューまで任せられるようになると、一見すると開発は非常に速くなる。
要件を与える。
AIがコードを書く。
AIがテストを実行する。
AIが「問題ありません」と報告する。
しかし、ここには見落としやすい問題がある。
実装したAgent自身に、その実装が正しいかを最終判定させてよいのか。
人間の開発でも、作った本人だけがレビューをして、そのまま本番へ反映することは危険である。実装者は、設計意図や自分が置いた前提に引っ張られやすい。見たいものを見て、見落とした問題を検証対象から外してしまうことがある。
AIエージェントでも同じである。
そこで必要になるのが、独立したVerifier Agentである。
これは、実装を行ったAgentとは別のAgentが、根拠、権限、仕様との整合、テスト結果、変更範囲を確認し、検証結果を報告する仕組みである。
目的は、AIを信用しないことではない。
作る役割と検証する役割を分け、自己採点を避けることである。
「テストが通った」と「要求を満たした」は違う
実装Agentがテストを実行し、すべて成功したとしても、それだけで要求を満たしているとは限らない。
例えば、次のようなことが起こり得る。
- 実装した機能に合わせて、テスト自体を弱く変更している
- 異常系や権限不足のケースをテストしていない
- 既存機能への影響範囲を確認していない
- 本番と異なる開発環境だけでテストしている
- 要件に含まれる運用・監査・安全性をコードテストの対象にしていない
- 仕様書が更新されているのに、古い要求を前提に実装している
つまり、テスト成功は重要な証拠の一つではあるが、合格そのものではない。
Verifier Agentは、単にテスト結果を読むのではなく、次の問いを独立して確認する。
- この変更は、要求・チケット・設計書のどの記述を満たすためのものか
- その根拠は現在も有効な版か
- 実装範囲と要求範囲に抜けや過剰な変更はないか
- テストは要求された振る舞いを本当に検証しているか
- 権限・ポリシー・監査記録に影響していないか
- 未検証の領域やUnknownは何か
ここで初めて、「テストが通った」という技術的事実を、「安全に進められる変更か」という判断へつなげられる。
Verifier Agentは、実装Agentと何が違うのか
重要なのは、名前だけ別のAgentを用意することではない。検証の独立性を、役割・入力・権限・評価基準において確保することである。
| 観点 | 実装Agent | Verifier Agent |
|---|---|---|
| 主な目的 | 要求を実現する変更を作る | 要求・根拠・制約への適合を確認する |
| 主な入力 | 要件、設計、既存コード | 要件、変更差分、テスト証跡、ポリシー、監査条件 |
| 成果物 | コード、設定、テスト、変更提案 | 合格・要修正・保留の検証報告 |
| 見る視点 | 実現可能性、保守性、実装効率 | 抜け、矛盾、権限、例外、回帰リスク |
| 実行権限 | 許可された範囲で変更を作成 | 原則として変更せず、検証と差し戻しに限定 |
| 成功条件 | 機能が動くこと | 根拠を伴って、受け入れ可能性を説明できること |
Verifier Agentは、実装Agentの説明を鵜呑みにしない。
変更差分、実際のテスト結果、仕様書、ポリシー、既存の運用ルールを照合し、必要なら「この主張を裏づける証拠が不足している」と報告する。
検証対象は、コードだけではない
AIによる変更で問題になりやすいのは、コードの文法ミスだけではない。
例えば、AIが顧客向けの通知機能を実装した場合、Verifier Agentが確認すべき対象は広い。
- 実装が仕様どおりか
- 送信対象者の抽出条件は正しいか
- 配信停止や同意状態を尊重しているか
- 送信前に必要な承認があるか
- テンプレートに機密情報や不適切な表現が含まれないか
- 二重送信や再送の制御があるか
- 監査ログとDecision Traceが残るか
- 障害時にどこまで再試行するか
- 本番環境で必要な設定が揃っているか
このように、Verifier Agentは機能単位のテストだけでなく、業務・権限・運用・監査を横断して確認する必要がある。
企業システムでは、「動くコード」よりも「安全に運用できる変更」の方が重要である。
証拠に基づく検証報告をつくる
Verifier Agentの出力は、「問題ありません」という一文であってはならない。
少なくとも、何を確認し、何が確認できず、どの根拠に基づいて結論を出したのかを示す必要がある。
例えば、検証報告は次のように構成できる。
| 項目 | 内容 |
|---|---|
| 判定 | 合格 / 要修正 / 保留 |
| 対象変更 | Pull Request、コミット、設定変更、リリース候補 |
| 要求との対応 | どの要求・受入条件をどの実装が満たすか |
| 参照根拠 | 設計書、チケット、API仕様、ポリシーの版と箇所 |
| テスト証跡 | 実行コマンド、結果、対象範囲、実行環境 |
| 権限・ポリシー確認 | 変更に伴うデータ利用、送信、承認条件 |
| 指摘事項 | 不足しているテスト、仕様との差異、潜在リスク |
| Unknown | 取得できない資料、未実施の検証、確認不能な領域 |
| 次のアクション | 修正、追加テスト、人の承認、追加調査 |
例えば、Verifier Agentは次のように報告できる。
判定：要修正
通常のポイント付与と月間上限チェックのテストは成功しています。
一方で、退会済みユーザーと停止中ユーザーを除外する受入条件に対するテスト証跡を確認できませんでした。
また、本番用の環境変数の設定はリリース候補に含まれていないため、デプロイ前に運用担当者の確認が必要です。
この報告は、実装者を責めるためのものではない。人がレビューやリリース判断を行うための、構造化された根拠である。
同じモデルを使っても、検証は分離できる
「独立したVerifier Agent」と聞くと、実装Agentとは異なるAIモデルを使わなければならないように思えるかもしれない。
もちろん、異なるモデル、異なるプロンプト、異なる検索経路を使うことは、同じ誤りを繰り返すリスクを下げる一つの方法である。
しかし、もっと重要なのは、検証の役割を実装から切り離すことだ。
同じモデルを利用する場合でも、少なくとも次を分けられる。
- 実装時の会話履歴と、検証時の会話履歴を分離する
- 実装Agentの自己説明だけを検証入力にしない
- 変更差分とテストログを直接参照する
- 仕様書・ポリシー・受入条件を別経路から取得する
- Verifier Agentには変更権限を与えない
- 合格判定だけでなく、保留とUnknownを正式な結果にする
- 高リスク変更は人の最終承認を必須にする
これにより、「自分で作った前提を自分で正しいと判断する」構造を避けられる。
Verifier Agentを万能な承認者にしない
Verifier Agentが存在しても、すべての変更を自動合格にしてはいけない。
特に、権限変更、個人情報の取扱い、顧客への外部送信、課金、契約、重要な本番設定などは、人の最終承認を残すべきである。
Verifier Agentの判定は、人の判断を置き換えるものではない。
人が判断する前に、必要な証拠と確認漏れを整理するもの
である。
また、Verifier Agentが確認できなかった情報は、合格として扱わない。ログが欠落している、必要な文書への権限がない、テスト実行環境が不明である、といった場合は、Unknownまたは保留として明示する。
「確認できないが、たぶん問題ない」という扱いを避けることが、検証の信頼性を支える。
結び：AIの品質は、AI自身の自己評価だけでは保証できない
AIエージェントが実装を担う時代には、コード生成能力だけでなく、検証の仕組みそのものが重要になる。
実装Agentに設計、実装、テスト、最終判定まで任せれば速そうに見える。しかし、それは同じ前提、同じ見落とし、同じ評価基準の中で完結する危険な構造でもある。
だからこそ、作るAgentと検証するAgentを分ける。
- 実装Agentは、要求を実現する
- Verifier Agentは、要求・根拠・権限・テスト証跡を確認する
- 人は、重要な変更について最終判断を行う
この分離によって、AI活用は単なる自動化から、説明可能で継続的に改善できる開発・運用プロセスへ進む。
AIに自己採点をさせない。
それはAIを疑うためではない。
組織が、AIの成果を責任を持って利用するための基本設計である。
Chinoba
Intelligence as Relationship
Research Platform
founded by
Masao Watanabe
AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance
Related Research
この記事は Chinoba Knowledge Base の一部です。
コメント