作る役と確かめる役の分離（maker-checker）

成果物を作った主体に自分で採点させない原則。AI エージェントでは「エージェントを分ける」だけでは足りず、接続・規律・重み（モデル）の 3 層を塞いで初めて機能する

概要

作った本人に自分の答案を採点させないという、金融の four-eyes principle 由来の原則。自分の出力をレビューするモデルは、間違えたのと同じ場所から評価するので誤りの大半を見逃す。AI エージェントのループ・レビュー・テスト生成・ファクトチェックのどこにでも現れる。

ただし AI エージェントでは、検証役を別エージェントにしただけでは成立しない。呼ばれているか（接続）・逃げ道がないか（規律）・同じ盲点を共有していないか（重み）の 3 層を全部塞いで初めて機能する。

詳細

検証を機能させる 3 層

層	塞がないと起きること	塞ぎ方
接続	定義しただけのエージェントは呼ばれない。一覧に載り、定義ファイルもあるので「ある」ように見える	呼び出しを実際に書く。`grep -rn "<agent-name>" .claude/` で定義ファイル以外からの参照を確かめる
規律	「自明だから検証不要」で素通りする。書き手が確信を持って間違えた箇所こそ、検証者にも自明に見える	主張ごとに証拠（実行したコマンド・検索クエリ・URL）を書く欄を作り、空欄を可視化する
重み	サブエージェントは既定で親と同じモデルを継承し、事実に関する事前分布を共有する	検証役の `model` を明示してティアを跨がせる

規律は「文章」ではなく「埋める欄」にする

「証拠を書くこと」と散文で指示しても、守らなくても報告の体裁は成立する。証拠カラム付きの表にすると、守らなかったことが空欄として残り、下流のゲートで機械的に差し戻せる。

記憶を証拠にしない（「知っている」「一般的にそうだ」は証拠ではない）
「未確認」は「試したうえで取れなかった」場合に限り、何を試したかを書かせる
ソース元に無く記事側で足された主張を優先して検証する（ハルシネーションの最大の発生源）
受け取る側にもゲートを置く。未検証の「確認済み」は、検証しないより悪い — 推測が確認に洗浄されて下流が信用してしまう

モデルを跨がせる設計

執筆側	検証側	理由
sonnet	opus	非相関化
opus	sonnet	証拠必須にすると判定の大半は外部ツールの返り値で決まり、推論の深さへの依存が下がるので許容できる
—	haiku は不可	「証拠が主張を支持しているか」の判定が最初に劣化する

文体やタグのような taste の検査は、共有事前分布による盲点が問題にならないので継承のままでよい。ティア分離の動機はコスト削減ではなく非相関化で、「安いから下げる」ではなく「違うから跨がせる、ただし下げすぎない」になる。

エージェントを分ければ見ている文脈がずれ、モデルを変えれば間違え方がずれる。片方だけでは足りない。

分離しても正しさは保証されない

GMO ペパボのレビューループでは、6 体のレビュアーの指摘を別エージェントに渡して妥当性を判定させたが、検証役が妥当な指摘を却下するリスクは常にあり、AI 同士の判断が一致しても正しいとは限らない。分離が断つのは自己採点バイアスであって、判定の正しさではない。期待値は「フィルタとしてある程度機能する」程度に置く。

現れる場所

ループの停止判定 — 作業するモデル（generator）とは別に、停止条件だけを見る採点役（evaluator）を新しいコンテキストで立てる。作る役に完了を自己申告させると「嘘で止まる」（エージェントループ設計）
テスト生成 — 実装を書いた主体と期待値を決める主体を分ける。実装だけを見て書かれたテストは、バグを正解として固定する（テストの導出元）
ミューテーション検査の委任 — 検査を専用サブエージェントに分け、使うモデルも実装側と変える（ミューテーションテスト）
自己改善ループ — 評価の基準は人間が定義する。評価が不正確だと反復を重ねるほど性能が落ちる（自己改善エージェント）

「モデル共感」との緊張関係

自己改善エージェントの文脈では、同じモデル同士をコーチと選手にすると失敗パターンを「自分ごと」として理解でき性能が上がる、という報告もある（モデル共感）。改善案を出す役には共有された事前分布が効き、合否を判定する役には害になる、と役割で分けて考えるとよい。