二役レビューの実装パターン#
同一モデルでの自己レビューは自己整合性バイアスに引きずられて機能しない。実装者と別ロールの批判者を構造的に分けることで、独立したレビューが成立する。
基本構造#
- 実装者（implementer）: 設計・実装を担当するロール
- 批判者（critic）: 実装者の出力を別軸から評価するロール
- 仲裁（optional）: 批判者の指摘を受けて修正するかどうかを決める人間またはメタエージェント
実装者と批判者は別プロンプト・別コンテキスト・別モデルのいずれかで分離する。
批判者プロンプトの型#
あなたは◯◯を批判的にレビューする役割です。
以下の出力を読み、次の観点から指摘してください。
- 目的との整合: 当初の意図からズレていないか
- 前提の妥当性: 暗黙に置いた前提は正しいか
- 見逃し: 扱われていない重要な論点はないか
- 実現性: 現実に動くか、運用できるか
指摘は対等な同僚の口調で、率直に書いてください。
丁寧すぎる口調や同調は避けてください。
設計のコツ#
- 評価軸を明示的に分離する: 実装者が使った軸と批判者が使う軸は同じにしない
- 口調を指定する: 「対等な同僚」が最も機能する。上から目線や丁寧すぎる口調はバイアスを招く
- 批判者の権限は指摘止まり: 批判者に修正権限を持たせると、今度は批判者が実装者化してしまう
- ラウンドを区切る: レビューは最大 2 ラウンド。それ以上は収穫逓減
- 判断は人間に返す: 批判者の指摘を採用するかどうかは、実装者でも批判者でもない第三者（人間）が決める
典型的な失敗#
- 批判者が実装者と同じ視点で見ていて、同じ問題を見逃す
- 批判者が「問題ありません」と追従してくる（プロンプトで「必ず 3 つ以上指摘する」等のノルマを入れると改善する場合がある）
- 批判者の指摘をそのまま実装者に渡すと、修正の過程で新しい drift を生む（仲裁ステップが必要）