上の 1 枚は、この記事の内容を手描き風にまとめたグラレコです。「作る」と「指摘する」の非対称性から、社内組織との対応、Evaluator を強くする設計ルールまで、まずはこの図で全体の輪郭をつかんでもらえればと思います。
はじめに 🎯
Generator / Evaluator パターンは、成果物を作る LLM エージェント（Generator）と、その成果物を読んで指摘を返す LLM エージェント（Evaluator）を別々の呼び出しに分け、指摘を Generator に戻して反復する構成です。
Anthropic は 2024 年 12 月の「Building Effective Agents」で、この構成を evaluator-optimizer ワークフローとして紹介しています。2026 年 3 月には Anthropic Labs が planner / generator / evaluator の 3 エージェント構成で数時間規模の自律開発を回した結果を公開し、2026 年 9 月に公開された Harness-of-Harness 論文も Project Planner / Developer / QA Tester という同じ形の分業を採っています。名前は違いますが、「作る役」と「指摘する役」を分けるという骨格は共通です。
この構成が効く理由は、「作る」と「指摘する」が難しさの違う仕事で、LLM は後者のほうが得意だからです。本記事では、この非対称性を説明している研究（検証の非対称性、generation-verification gap、CriticGPT）、自分で自分を採点すると甘くなることを示した研究、そして実際に役割を分けたときに何が起きるかを示す 3 つの実装例を整理します。そのうえで、この構図が人間の組織でレビュー・QA・監査が開発から独立している理由と同じであることを見ていきます。
想定読者は、Claude Code や Codex のようなコーディングエージェントを日常的に使っていて、サブエージェントやマルチエージェント構成をこれから組もうとしている方です。
この記事で得られることは次のとおりです。
- 🧩 「作る」と「指摘する」の難しさの差を説明する 3 つの研究
- ⚠️ なぜ「自分で自分を指摘する」では効かないのか
- 🛠️ Anthropic の evaluator-optimizer、Anthropic Labs のハーネス、Harness-of-Harness の QA Tester に共通する設計
- 🏢 開発 / QA / 監査という社内組織の構図との対応関係
- 📐 Evaluator を強くするための 8 つの設計ルールと、その限界
💡 本記事で引用している数値は、Anthropic の技術記事と査読付き論文（ICLR 2024 / 2025）、arXiv 論文に基づいています。各ソースは末尾の「参考」にまとめています。
「作る」と「指摘する」は難しさが違う仕事です 🧩
最初に、この記事の主張の土台になる考え方を押さえておきます。
検証の非対称性
AI 研究者の Jason Wei は 2025 年 7 月のブログ「Asymmetry of verification and verifier's rule」（公開時のタイトルは verifier's law で、URL にその名残があります）で、あるタスクは解くよりも検証するほうがはるかに簡単だという性質を「検証の非対称性（asymmetry of verification）」と呼んでいます。
例として挙げられているのは数独と Instagram です。数独は解くのに時間がかかりますが、答えが合っているかの確認は自明です。Instagram のようなサービスを作るにはエンジニアチームが何年もかかりますが、サイトがちゃんと動いているかの確認は素人でも短時間でできます。
同じブログでは、検証しやすいタスクの性質が 5 つ挙げられています。
| 性質 | 意味 | ソフトウェア開発での例 |
|---|---|---|
| Objective truth | 何が良い解かについて合意がある | テストが通る、仕様の項目を満たす |
| Fast to verify | 1 つの解を数秒で検証できる | ユニットテスト、型チェック |
| Scalable to verify | 多数の解を同時に検証できる | CI で並列に回せる |
| Low noise | 検証結果が解の品質と強く相関する | フレーキーでないテスト |
| Continuous reward | 良し悪しを順位付けできる | 通ったテストの数、ルーブリックの点数 |
そしてブログの結論は、「AI にタスクを解かせる訓練のしやすさは、そのタスクの検証しやすさに比例する」（verifier's rule。公開当初の呼び名は verifier's law です）という一文です。解けるタスクのうち検証しやすいものは、いずれ AI に解かれる、とも書かれています。
ここで大事なのは、この非対称性が「AI に限った話ではない」という点です。数独も Instagram も、人間にとっても解くより確認するほうが簡単です。LLM はこの非対称性を人間と同じように、あるいは人間よりも強く受けているだけです。
次の図は、「作る」と「指摘する」の探索空間の違いを示しています。
作る側は、設計・命名・順序・エッジケースといった無数の選択肢の中から 1 つの組み合わせを選び続けなければなりません。指摘する側は、すでに目の前にある 1 つの成果物を、仕様やテストという基準に照らすだけです。探索空間の大きさが根本的に違います。
「強い」の意味を決めておきます
タイトルの「指摘するほうが強い」は、指摘する側が偉いという意味ではありません。この記事では「強い」を次の 3 つの意味で使います。
| 「強い」の意味 | 内容 |
|---|---|
| 精度が高い | 同じモデルでも、作らせるより指摘させるほうが当たりやすい |
| コストが低い | 指摘は成果物 1 つを読めばよく、生成のように候補を組み立て直す必要がない |
| スケールする | 候補が増えても検証コストは線形にしか増えず、候補を増やすほど良い解を拾える |
この 3 つがそろっているので、「作る役」の出力を「指摘する役」に通すだけで品質が上がり、しかもその構成は候補の数やループの回数を増やすほど効いてきます。作り手がいなければ成果物はゼロなので、指摘する側だけで何かができるわけではありません（ここは後で社内組織の話に戻ってくるときの伏線です）。
なぜ LLM は「指摘」のほうが得意なのか 🔍
検証の非対称性は直感的な話でしたが、LLM についてはもう少し具体的な研究があります。3 つ紹介します。
理由 1: 同じモデルでも「検証」のほうが「生成」より得意
Song らの論文「Mind the Gap: Examining the Self-Improvement Capabilities of Large Language Models」（ICLR 2025）は、モデルが自分の出力を検証し、フィルタや重み付けをして、そのデータで自分を蒸留する「自己改善」の枠組みを数学的に定式化しています。
その中心にあるのが generation-verification gap という量です。素の生成分布と、検証で選び直した分布の差を表していて、この差が大きいほど自己改善の余地が大きくなります。論文は複数のモデルファミリーとタスクで実験し、この gap の変種が事前学習の FLOPs に対して単調に増加するというスケーリング現象を報告しています。
次の図は、この gap の考え方を示しています。
ポイントは、同じモデルが「作る」ときと「選ぶ」ときで実力が違うことが、経験則ではなく測定可能な量として扱われている点です。事前学習の計算量が増えるほどこの差は広がるので、「指摘する側が強い」という性質は今後のモデルでも弱まる方向にはなさそうです。
理由 2: 検証はデータ量に対してスケールする
もう少し古い研究ですが、Cobbe らの「Training Verifiers to Solve Math Word Problems」（OpenAI、2021 年）は、小学校の算数文章題データセット GSM8K を作ったうえで、多数の候補解を生成して verifier が最も高く採点したものを選ぶ手法を提案しています。
結果として、データ量が十分にあるときは、verification は fine-tuning ベースラインよりもデータ量に対して効果的にスケールすると報告されています（データが少ない領域では逆に fine-tuning に劣ることも本文に書かれています）。また同じ論文は、検証させる候補の数を増やすほど性能が上がることも示しています。ただし一定数を超えると verifier を欺く解が混ざって頭打ちになるので、無限に増やせばよいわけではありません。前のセクションの「候補を増やすほど良い解を拾える」は、この後者の結果に対応しています。
理由 3: 訓練された批評モデルは人間のレビュアーよりバグを見つける
3 つ目は OpenAI の CriticGPT です。論文「LLM Critics Help Catch LLM Bugs」（2024 年 6 月）は、モデルが書いたコードの問題点を自然言語で指摘する「critic」モデルを RLHF で訓練しています。
報告されている数値は次のとおりです。
| 項目 | 結果 |
|---|---|
| 自然発生したバグを含むコードでの批評の比較 | モデルの批評が人間の批評より 63% のケースで好まれた |
| バグ検出数 | コードレビューで報酬を得ている人間の contractor より多くのバグを検出 |
| 学習データへの適用 | 「flawless」と評価された ChatGPT の学習データから数百件の誤りを発見（多くは非コードタスク） |
| 限界 | hallucinated bugs（存在しないバグの指摘）があり、人間を誤らせうる |
| 人間との組み合わせ | 人間＋critic のチームは critic 単体と同程度のバグを検出しつつ、hallucination は少ない |
「指摘する側が強い」を LLM について最も直接的に示しているのがこの結果です。同時に、指摘する側も間違える（hallucinated bugs）ことと、人間が最終判断に入ると誤指摘が減ることも同じ論文が示しています。この 2 点は後半の設計ルールで使います。
3 つの研究をまとめると次のようになります。
| 研究 | 何を示したか | この記事での含意 |
|---|---|---|
| Song ほか（ICLR 2025） | 同じモデルでも検証 > 生成。差はモデル規模とともに拡大 | 役割を分けるだけで品質が上がる根拠 |
| Cobbe ほか（2021） | 生成して verifier で選ぶほうがデータ効率が良い | 候補やループを増やすほど効く根拠 |
| McAleese ほか（2024） | 訓練された critic は人間のレビュアーよりバグを見つける。ただし誤指摘もある | 指摘に証拠を求め、人間が最終判断する根拠 |
ただし「自分で自分を指摘する」は効きません ⚠️
ここまで読むと、「じゃあ Generator に『自分の成果物をレビューして』と言えばいいのでは」と思うかもしれません。これが効かない、というのがこのセクションの話です。
外部フィードバックなしの自己修正は性能を下げることがある
Huang らの「Large Language Models Cannot Self-Correct Reasoning Yet」（ICLR 2024）は、外部のフィードバックなしにモデルが自分の初期回答を直そうとする intrinsic self-correction を検証しています。結論は明快で、推論タスクでは外部フィードバックなしに自己修正できず、場合によっては自己修正後に性能が下がると報告されています。
自分の成果物には甘くなる
Anthropic Labs の 2026 年 3 月の記事には、この現象がもっと生々しく書かれています。
When asked to evaluate work they've produced, agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre.
自分が作ったものを評価させると、人間の目には明らかに平凡でも自信を持って褒める、ということです。記事はこれを、Generator 自身に批判させるより独立した Evaluator を懐疑的に調整するほうがはるかに扱いやすい、という設計判断の根拠にしています。
「自分が生成したか」に関係なく、馴染みのある出力を高く評価する
Wataoka らの「Self-Preference Bias in LLM-as-a-Judge」（2024 年）は、この甘さの原因に一歩踏み込んでいます。GPT-4 に有意な self-preference bias があることを定量的に示したうえで、LLM は perplexity が低い（自分にとって馴染みのある）出力を、自分が生成したかどうかに関係なく高く評価すると分析しています。
つまり甘さの本質は「自分の作品への愛着」ではなく、「読み慣れた文体への好意」です。これは同じモデルを Evaluator に使う場合にも残るバイアスなので、後で限界として触れます。
分けると何が変わるのか
3 つの研究を合わせると、「同じ呼び出しの中で自己採点させる」構成には構造的な問題があることが分かります。同じコンテキストで作ったものを見ているので、作ったときの思い込みをそのまま引き継いでしまいます。
まず、自己採点の構成です。
次に、役割を分けた構成です。
違いは 3 つです。Evaluator は別の呼び出しなので Generator の思い込みを持っていません。成果物は凍結されているので、評価中に対象が変わりません。Evaluator は読み取り専用なので、問題を見つけても黙って直せず、指摘として出すしかありません。このうち「別の呼び出し」は次のセクションで見る 3 つの実装例すべてに入っていて、「凍結」と「読み取り専用」は Harness-of-Harness が最も明示的に規定しています。
実際に分けるとどうなるか：3 つの実装例 🛠️
例 1: Anthropic の evaluator-optimizer ワークフロー（2024 年 12 月）
Anthropic の「Building Effective Agents」は、エージェント構成の基本パターンを整理した記事で、その中の 1 つが evaluator-optimizer です。定義は「1 つの LLM 呼び出しが応答を生成し、別の呼び出しが評価とフィードバックをループで返す」というシンプルなものです。
記事が挙げている適用条件は 2 つです。明確な評価基準があることと、反復で測定可能な改善が得られることです。目安として、人間がフィードバックを言語化するとモデルの応答が目に見えて良くなるタスクで、かつモデルがそのフィードバックを自分で出せるなら、このパターンが合うとされています。例としては、細かなニュアンスを詰めていく文芸翻訳と、追加の検索が必要かを Evaluator が判断する複数ラウンドの検索が挙げられています。
なお、この記事は LLM とツールが事前に定義されたコードパスで編成される「ワークフロー」と、LLM が自分でプロセスとツールの使い方を決める「エージェント」を区別していて、evaluator-optimizer は前者に分類されています。ループの形が固定されているぶん、挙動が読みやすいということです。
例 2: Anthropic Labs のハーネス（2026 年 3 月）
2026 年 3 月 24 日に Anthropic Labs の Prithvi Rajasekaran が公開した「Harness design for long-running application development」は、evaluator-optimizer と同じ「作る役と採点する役を分ける」構造を、数時間規模の自律開発に適用した実践記録です。構成は planner / generator / evaluator の 3 エージェントです。
| ロール | やること |
|---|---|
| Planner | ユーザーの 1〜4 文のプロンプトを、詳細なプロダクト仕様に展開する。スコープは野心的に、実装細部ではなくプロダクト文脈と高レベルの技術設計に集中する |
| Generator | 仕様から機能を 1 つずつスプリント方式で実装する。各スプリントの終わりに自己確認をしてから QA に渡す |
| Evaluator | Playwright MCP で実行中のアプリをユーザーのように操作し、UI・API・DB の状態を検査する。基準ごとに採点し、合格基準を下回れば詳細なフィードバック付きで不合格にする |
1 スプリントの流れをシーケンスで追うと次のようになります。
ここで注目したいのはスプリント契約です。「矩形塗りつぶしツールは、クリックとドラッグで矩形領域を塗れる」といった検証可能な基準の一覧を Generator が提案し、Evaluator がレビューして合意したうえで、Evaluator は基準ごとに閾値を設けて、1 つでも下回れば不合格にします。何を作るかと同時に、何をもって合格とするかを先に決めているわけです。
この記事では 3 エージェント構成に先立ってフロントエンドデザインの実験が行われていて、そこで次の 4 軸のルーブリックが使われています。ハーネスの Evaluator はこれを下敷きに、プロダクトの深さ・機能・ビジュアル・コード品質を見る基準に組み替えて使っています。
| 軸 | 見るもの |
|---|---|
| Design Quality | 統一感、雰囲気づくり、視覚的な一貫性 |
| Originality | テンプレート的な見た目を避け、独自の判断があるか |
| Craft | タイポグラフィの階層、間隔、色の調和 |
| Functionality | ユーザーが理解でき、タスクを完了でき、アクションを見つけられるか |
そして、この構成の効果を示す比較が記事に載っています。レトロゲームメーカーを作らせたときの、ソロエージェントとフルハーネスの比較です（モデルはどちらも Claude Opus 4.5 です）。
| 構成 | 時間 | コスト | 結果 |
|---|---|---|---|
| ソロエージェント | 20 分 | $9 | 中核のゲームプレイが壊れており、レイアウトも画面の大半が空白になるなど粗い |
| フルハーネス | 6 時間 | $200 | 複数のエディタと AI 統合を備え、プレイ可能な状態まで仕上がっている |
記事自身が書いているとおり、ハーネスは 20 倍以上高コストです。それでも出力品質の差は一目で分かるレベルだった、というのがこの実験の結論です。
もう 1 つ、この記事で重要なのは Evaluator の「甘さ」との戦いです。初期の Evaluator は、正当な問題を見つけておきながら「大したことではない」と自分を説得して承認してしまう挙動を示したと書かれています。対処は、評価ログを読み、人間の判断と乖離している例を集めて QA プロンプトを更新する、というチューニングを数ラウンド回すことでした。Evaluator を分けただけでは終わらず、Evaluator 自体を監視する必要があるということです。
記事の締めくくりにある次の一文も、設計者にとって重要な指針です。
every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing, both because they may be incorrect, and because they can quickly go stale as models improve.
Evaluator を置くこと自体が「モデルは自分の成果物を正しく採点できない」という仮定の表明です。この仮定はモデルの進化で古くなりうるので、新しいモデルが出るたびに検証し直すべきだ、というスタンスです。
例 3: Harness-of-Harness の QA Tester（2026 年 9 月）
3 つ目は、2026 年 9 月 1 日に arXiv で公開された Shanghai AI Lab の論文「Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement」です。Codex CLI や OpenCode のような既存のコーディングエージェントを外側から包み、Project Planner → Developer → QA Tester の 3 ロールを何十ループも回す枠組みで、QA Tester が Evaluator に相当します。
この論文の QA Tester には、判定のルールがはっきり書かれています。
verified になるのは、候補に紐付いた実行記録がその挙動を支持する場合だけです。観測された失敗、未達の要件、回帰、そして証拠不足は、すべて gap として記録されます。「証拠がないから、たぶん成功しているだろう」という推定は許されません。Appendix には「ソースコードに存在するだけでは挙動の検証とは見なさない」とも書かれています。
そしてこの論文の面白いところは、3 つのロールが別のモデルでも別のハーネスでもない点です。同じモデル・同じハーネスを、ロール別のプロンプトと権限制御のもとで 3 回呼び出しているだけです。QA Tester の独立性は、モデルが違うことによる独立性ではなく、「実装者とは別の呼び出しで、凍結された候補を読み取り専用で見る」という手続き上の独立性です。
この手続きの効果は、アブレーションで数値化されています。Codex + GPT-5.5 で GameCraft-Bench の 45 タスクを 3 ループ回したとき、QA Tester は毎回動かすがその証拠を次の Planner に渡さない「w/o Evidence Feedback」条件では、スコアが 71.52 から 65.23 に落ちています（−6.28 ポイント）。指摘を出すだけでなく、次の計画に流し込むところまでがセットで効いているということです。
3 つに共通していること
3 つの実装例を並べると、共通する設計が見えてきます。
| 観点 | evaluator-optimizer（2024） | Anthropic Labs ハーネス（2026） | Harness-of-Harness（2026） |
|---|---|---|---|
| 分離の単位 | 別の LLM 呼び出し | 別のエージェント（別コンテキスト） | 別の呼び出し（同じモデル・同じハーネス） |
| Evaluator の権限 | 評価とフィードバックのみ | 実行中アプリの操作と検査。フィードバックはファイルで返す | 凍結された候補の読み取りと実行のみ |
| 判定の形式 | 合格 / 不合格＋フィードバック | 基準ごとの採点、1 つでも閾値未満で不合格 | 主張ごとに verified / gap、証拠不足は gap |
| 合格基準の決め方 | 明確な評価基準を前提 | スプリント契約＋ルーブリック（フロントエンド実験の 4 軸を組み替えたもの） | 仕様と開発ドキュメントから毎回導出 |
| 指摘の行き先 | Generator に戻す | Generator に戻す | 次ループの Planner に渡す（証拠束） |
「別の呼び出し」「基準を先に決める」「指摘を次に流す」の 3 点が全部に入っていて、「読み取り専用」は Harness-of-Harness が明文化しています。
筆者の観察
筆者の手元でも、Generator が作った成果物を別の Evaluator エージェントに渡すと、Generator 自身に確認させたときには出てこなかった指摘が一度にまとまって返ってくることを繰り返し経験しています。Generator に「問題ないか確認して」と頼むと「問題ありません」で終わることが多いのに、同じ成果物を Evaluator に見せると仕様との差分や未処理のケースが次々に挙がってきます（正直、最初は「さっきまで大丈夫と言っていたのに」と思いました）。
ただし、良いことばかりでもありませんでした。Evaluator に Claude Fable や GPT-6 Astra のような、その時点で最も賢いクラスのモデルを使ったときは、指摘が尽きなくなりました。1 ラウンド目の指摘を Generator に直させて再提出すると、Evaluator は直した箇所の周辺から新しい指摘を見つけてきます。それを直すとまた次の指摘が出て、「修正 → 再評価 → 新しい指摘」のループが終わりませんでした。指摘の一つ一つは筋が通っているので、どこで止めればよいかを Evaluator 自身は教えてくれません。
振り返ると、これは Evaluator が壊れていたのではなく、正しく動きすぎていたのだと思います。検証が生成より容易である以上、賢い Evaluator ほど、目の前の成果物と「もっと良い状態」との差分を見つけ続けられます。差分がゼロになる成果物は存在しないので、「指摘がなくなったら終わり」という終了条件は、賢い Evaluator に対しては成立しません。終了条件は Evaluator の外側で、合格基準とラウンド数として先に決めておく必要がありました。この経験は後半の設計ルール ③ と ⑧ に入れています。
この記事を書いたきっかけはその 2 つの体験ですが、上で見てきたとおり、「指摘がまとまって出る」ことも「賢い Evaluator ほど指摘が止まらない」ことも、筆者の環境に固有の話ではなく、研究と実装の両面で裏付けのある一般的な性質です。
社内組織と同じ構図です 🏢
ここまでの話は、人間の組織でずっと前からやってきたことと同じ形をしています。
開発 / QA / 監査の分離
ソフトウェア開発の組織では、作る人と検査する人を分けるのが普通です。開発チームが作ったリリース候補をコードフリーズし、QA やレビュアーが独立して検査し、指摘は記録されて次の計画に反映されます。
人間の組織の流れは次のようになります。
これを Generator / Evaluator パターンに置き換えると、次のようになります。
2 つの図は、ノードの名前を入れ替えただけでほぼ同じです。
独立性が価値の源泉
「分ける」こと自体が目的ではなく、独立していることが指摘の価値を生みます。この点をいちばん明確に定義しているのが、ソフトウェアの検証と妥当性確認の規格 IEEE Std 1012 です。この規格は、独立した検証（IV&V: Independent Verification and Validation）の独立性を 3 つの要素で定めています。
| IEEE 1012 の独立性 | 人間の組織での意味 | Generator / Evaluator での対応 |
|---|---|---|
| Technical independence | 開発に関わっていない人が検証する。解に近すぎる人が見落とす誤りを「新鮮な視点」で見つける | Evaluator を別の呼び出し・別のコンテキストにする。Generator の思い込みを持ち込まない |
| Managerial independence | 検証組織が開発組織から分離され、指摘を制限なく報告できる | Evaluator は読み取り専用で、指摘を Runtime や証拠束に記録する。Generator が指摘を握りつぶせない |
| Financial independence | 検証の予算が開発組織から独立していて、予算不足で検証を省いたり、報告を曲げたりする圧力を受けない | Evaluator のトークン予算を Generator と別に確保する。コスト圧力で評価をスキップしない |
Technical independence の説明にある「解に近すぎる人が見落とす誤り」は、Huang らの intrinsic self-correction の話と、Anthropic Labs の「自分の成果物を自信を持って褒める」の話そのものです。人間について以前から言われてきた原則（IEEE 1012 では 1998 年の改訂で明文化されました）が、LLM についても成り立っています。
人間のレビューにも同じ弱点がある
一方で、人間のレビューが常に理想的に働いているわけではありません。
Fagan が 1976 年に IBM で提案したコードインスペクションは、overview / preparation / inspection / rework / follow-up という工程（1986 年の改訂版では先頭に planning が加わり 6 工程）を持つ構造化された手法で、それなりに工数のかかるものでした。その後、レビューはもっと軽量な形に変わっていきますが、Bacchelli と Bird が 2013 年に Microsoft で行った調査では、レビューの最大の動機は欠陥の発見であるにもかかわらず、実際のコメントはコードの改善（可読性・不要コードの削除・コーディング慣習）と、変更の意図を確認する質問が多数を占め、欠陥の指摘は 9 カテゴリ中 4 番目（全体の約 14%）にとどまっていたと報告されています。
つまり人間のレビュアーも、構造がなければ本質的な指摘より軽い指摘に流れがちだということです。Anthropic Labs の Evaluator が「正当な問題を見つけながら承認してしまった」話や、CriticGPT が「nitpick（小さな不満）を減らすように訓練された」話は、これと同じ弱点への対処です。
四つの目の原則
金融や内部統制の世界には「四つの目の原則（four-eyes principle）」や「職務分掌（separation of duties）」という考え方があります。1 人が起案から承認まで通してはいけない、作った人が承認してはいけない、というルールです。
Harness-of-Harness の single-writer boundary（成果物を書けるのは Developer だけ）と QA Tester の読み取り専用は、この原則を LLM エージェントの権限設計として実装したものだと読めます。Developer は書けるが承認できず、QA Tester は判定できるが書けない、という形です。
指摘する側が「偉い」わけではない
ここで、冒頭で決めた「強い」の意味に戻ります。指摘する側が強いのは、検証が生成より容易だからです。QA だけの組織で製品が生まれないのと同じで、Evaluator だけでは成果物はゼロです。
社内組織の話でよく起きるのは、「指摘する側が強い」を「指摘する側が上」と読み替えてしまうことです。組織設計として大事なのは上下ではなく、作る側と指摘する側が手続きとして独立していることと、指摘が証拠付きで次の計画に流れることです。この 2 点が崩れると、指摘は「甘い承認」か「重箱の隅」のどちらかになります（人間でも AI でもです）。
Evaluator を強くする 8 つの設計ルール 📐
ここからは、3 つの実装例と研究から抽出した設計ルールです。自分のエージェント構成に Evaluator を入れるときのチェックリストとして使えます。
① 別の呼び出し・別のコンテキストにする
同じモデルでかまいません。Harness-of-Harness は同じモデル・同じハーネスで手続き上の独立性だけを作り、ハーネス単体（Vanilla）からの改善（Codex + GPT-5.5 の GameCraft-Bench で 49.58 → 71.52）を得ています。なお、同論文のアブレーションで測られているのは「証拠を次の計画に流す経路」の効果で、分離の有無を直接比較した条件はありません。大事なのは Generator の会話履歴を Evaluator に持ち込まないことです。Claude Code ならサブエージェントがちょうどこの単位になります。
② 読み取り専用にして、成果物を凍結する
Evaluator に書き込み権限を与えると、問題を見つけたときに黙って直してしまい、指摘が記録に残りません。読み取り専用にすることで、見つけた問題は指摘として出すしかなくなります。評価中に成果物が変わらないよう、評価対象は凍結します。
③ 合格基準を先に決める
Anthropic のスプリント契約とルーブリック、Harness-of-Harness の Preservation Gate（壊してはいけないもの）と Acceptance Gate（最小の受け入れ検証）は、どちらも「作る前に、何をもって合格とするか」を決めています。基準が後付けだと、Evaluator は Generator の出力に合わせて基準を緩めてしまいます。
④ 判定は証拠に紐付ける
「たぶん動く」を許さないルールです。Harness-of-Harness の「証拠不足は gap」「ソースコードに存在するだけでは検証ではない」が最も厳格な形です。Evaluator の出力形式を「主張 → 観測した証拠 → verified / gap」に固定すると、根拠のない合格が構造的に出せなくなります。
⑤ Evaluator の甘さを監視する
Evaluator を分けただけでは終わりません。Anthropic Labs は評価ログを読んで人間の判断との乖離を集め、QA プロンプトを数ラウンド更新しています。Evaluator の判定を定期的にサンプリングして人間が採点し直す運用を、最初から組み込んでおくのが現実的です。
⑥ 指摘に再現手順を要求し、人間が最終判断する
CriticGPT の論文が示すとおり、批評モデルは存在しないバグを指摘することがあります。対策は 2 つで、指摘に再現手順や該当箇所の引用を必須にすること、そして人間が最終判断に入ることです。同じ論文で、人間＋critic のチームは critic 単体より hallucination が少ないと報告されています。
⑦ 指摘を次の計画に流す
指摘をその場で直して終わりにせず、verified は「壊してはいけないもの」として、gap は「次に直すもの」として次の計画の入力にします。Harness-of-Harness のアブレーションで、この経路を切ると 6 ポイント以上落ちました。
⑧ 終了条件を Evaluator の外で決める
賢い Evaluator ほど指摘は尽きません。筆者が Claude Fable や GPT-6 Astra を Evaluator にして経験した無限ループは、「指摘がゼロになるまで直す」を終了条件にしていたことが原因でした。3 つの実装例はどれも、終了を Evaluator の判断ではなく外側の構造で決めています。Anthropic Labs はスプリント契約の基準をすべて満たしたら合格にし、それ以上の改善点があっても次のスプリントに送ります。Harness-of-Harness は Planner が優先事項を最大 3 つに絞り、ループ数 T を外から与えています。evaluator-optimizer も「明確な評価基準がある」ことを前提条件にしています。
具体的には、次の 3 つを Evaluator のプロンプトではなく、ループを回す側（Runtime やオーケストレータ）に持たせます。
- 合格基準の閾値: 受け入れ基準をすべて満たしたら合格にする。「改善できる点」は指摘として記録するが、合格を妨げない
- ラウンド数の上限: 例えば 3 ラウンドで打ち切り、残った gap は次の計画に送る
- 指摘の分類: 受け入れ基準の未達と回帰だけを「不合格の理由」にし、それ以外は「次回への提案」として別枠に出させる
Anthropic Labs の記事の後半にも、この話と地続きの観察があります。より新しいモデル（Claude Opus 4.6）ではスプリント構造を撤去してハーネスを簡略化したうえで、Evaluator は「有る・無しの固定の判断ではなく、タスクが現在のモデルの単独でこなせる範囲を超えているときにコストに見合う」と整理されています。モデルの素の能力が上がるとその境界は外側に動き、境界の内側では Evaluator は不要なオーバーヘッドになり、境界の外側では引き続き効いた、と書かれています。Evaluator を強くすることと、Evaluator を回す回数を増やすことは別の話で、後者には明示的な上限が要ります。
Claude Code での最小構成
Claude Code のサブエージェントを使う場合、.claude/agents/ に Evaluator を定義します。ポイントは tools を読み取り系に絞ることと、本文で「修正しない」「証拠なしに verified にしない」を明示することです。
---
name: evaluator
description: Generator の成果物を読み取り専用で検査し、主張ごとに verified / gap を証拠付きで返す QA 担当
tools: Read, Grep, Glob, Bash
---
あなたは QA 担当です。成果物を修正してはいけません。ファイルの作成・編集・削除は禁止です。
手順:
1. 仕様と受け入れ基準を読み、検証可能な主張（claim）を列挙する
2. 各主張について、テスト実行・ログ・該当コードの引用など観測できる証拠を集める
3. 証拠が主張を支持する場合のみ verified とする。失敗・未達・回帰・証拠不足はすべて gap とする
4. gap には、再現手順、該当ファイルと行、期待される挙動を必ず添える
出力形式:
- verified: 主張 / 証拠（コマンドと結果、またはファイル:行）
- gap: 主張 / 観測した事実 / 再現手順 / 推奨する修正
- preservation_constraints: 次の作業で壊してはいけない verified 項目
Bash を許可しているのはテストを実行させるためですが、シェル経由でファイルを書き換えることは技術的には可能です。厳密に読み取り専用にしたい場合は Bash を外して、テストの実行結果は Generator 側が添付する運用にしてください。
Evaluator のプロンプトでやりがちな表現と、置き換え案も載せておきます。
| やりがちな表現 | 何が起きるか | 置き換え案 |
|---|---|---|
| 「問題がないか確認してください」 | 「問題ありません」で終わる | 「仕様の各項目について、verified か gap かを証拠付きで判定してください」 |
| 「気になる点があれば教えてください」 | スタイルの指摘に流れる | 「受け入れ基準の未達と回帰を最優先で報告してください」 |
| 「必要なら修正してください」 | 黙って直して指摘が残らない | 「修正は禁止です。gap として報告してください」 |
| 「だいたい動いていれば OK です」 | 証拠なしに合格を出す | 「証拠がない主張は gap として扱ってください」 |
| 「指摘がなくなるまで繰り返してください」 | 賢いモデルほど指摘が尽きず、ループが終わらない | 「受け入れ基準をすべて満たしたら合格にし、改善提案は別枠で記録してください」 |
Evaluator の出力例
上の定義で動かしたとき、Evaluator から返ってくる出力のイメージです（架空のタスクで、形式を示すための例です）。
## verified
- 主張: CSV アップロード後に一覧が更新される
- 証拠: `npm test -- upload.spec.ts` が 3/3 pass（実行ログ添付）
- 主張: 空ファイルをアップロードするとエラーメッセージが表示される
- 証拠: `src/upload.ts:42-51` でサイズ 0 を検出し `EmptyFileError` を投げる。`upload.spec.ts` の "rejects empty file" が pass
## gap
- 主張: 10MB を超えるファイルは拒否される
- 観測した事実: サイズ上限のチェックがコード上に存在しない。`grep -rn "MAX_SIZE" src/` は 0 件
- 再現手順: 11MB の CSV をアップロードすると 200 が返り、一覧に追加される
- 推奨する修正: `upload.ts` の入口でサイズ判定を追加し、`upload.spec.ts` に上限超過のケースを足す
- 主張: アップロード中はボタンが二重送信を防ぐ
- 観測した事実: 該当する実装もテストも見つからない。証拠不足のため gap
## preservation_constraints
- CSV アップロード後の一覧更新（verified）
- 空ファイルのエラー表示（verified）
「証拠不足のため gap」の行が、このパターンの肝です。実装があるかどうか分からないものを「たぶん大丈夫」で通さず、次のループの作業項目に落としています。
指摘を受け取る側の作法
Evaluator を強くすると、今度は Generator が指摘の処理で詰まります。受け取る側にも 3 つのルールを置いておくと、ループが回りやすくなります。
| ルール | 内容 | 根拠 |
|---|---|---|
| 優先順位をつけてから直す | 受け入れ基準の未達と回帰を先に、スタイルや好みは後に回す。指摘を上から順に全部直そうとしない | Harness-of-Harness の Planner はブロッカーと回帰を機能拡張より優先し、優先事項を最大 3 つに絞る |
| verified を壊さない | 修正のたびに preservation_constraints を確認し、直した箇所に隣接する回帰面を再テストする | Harness-of-Harness の Developer は baseline → change → retest のサイクルで作業する |
| 異議は証拠で返す | 指摘が誤りだと思ったら「そんなことはない」ではなく、再現手順が再現しないことをログで示す | CriticGPT の hallucinated bugs への対処は人間の最終判断。Generator 側も証拠で反論できる形にしておく |
3 つ目は意外と大事で、Evaluator の誤指摘を Generator が黙って受け入れて「修正」してしまうと、正しかったコードが壊れます。指摘に証拠を求めるなら、反論にも証拠を求める、という対称なルールにしておくのが安全です。
いつ Evaluator を分けるべきか
最後に、どんなときにこの構成が割に合うかを判断する目安です。Anthropic の適用条件と、検証の非対称性の 5 性質をもとにしています。
基準が作れない領域では Evaluator も基準なしに採点することになり、甘さと重箱の隅の両方が出やすくなります。その場合は先に基準を作るほうが効きます。
限界と注意点 ⚠️
「指摘する側が強い」は便利な原則ですが、無条件ではありません。読みながら気になった点を挙げておきます。
検証しにくい領域では効きが落ちます。 検証の非対称性は「検証しやすいタスク」でこそ効きます。Anthropic Labs の記事でも、DAW（音楽制作ソフト）を作らせた例で、Claude は実際に音を聞けないため、音楽的な良し悪しについては QA のフィードバックループが効きにくかったと書かれています（機能面のギャップは Evaluator が捕捉しています）。主観的な品質や、観測手段がない挙動については、Evaluator を分けても限定的です。Jason Wei も、エッセイのファクトチェックのように検証のほうが生成より時間がかかる逆方向の例があることに触れています（デマを論破するには生成の一桁多いエネルギーが要る、という Brandolini の法則です）。
コストは確実に増えます。 Anthropic Labs の例ではハーネスはソロの 20 倍以上のコストでした。Harness-of-Harness でも 3 ループ回すとトークンは Vanilla の約 3.2 倍です。「同じ品質をより安く」ではなく「コストをかけた分だけ品質が上がる」構成なので、単発で十分なタスクには向きません。
Evaluator も間違えます。 CriticGPT の hallucinated bugs、Anthropic Labs の Evaluator の甘さは、どちらも Evaluator 側の失敗です。さらに Wataoka らの self-preference bias は「馴染みのある文体を高く評価する」性質なので、同じモデル族を Evaluator に使う限り完全には消えません。Harness-of-Harness の QA Tester も同じモデルを使っているため、モデル固有の盲点（特定の種類のバグを見落とす癖など）は Generator と Evaluator で共有されている可能性があります。
指摘の粒度が問題になります。 人間のレビューが軽微な指摘に流れやすいのと同じで、Evaluator も基準がなければ nitpick を量産します。「指摘がガンガン出る」こと自体は良いことですが、その指摘が受け入れ基準の未達なのか、好みの問題なのかを分ける仕組み（優先度、ルーブリック）がないと、Generator が指摘の海に溺れます。
賢い Evaluator ほど、指摘は止まりません。 筆者が Claude Fable や GPT-6 Astra を Evaluator にしたときに起きた無限ループは、Evaluator の性能が上がるほど起きやすくなります。指摘の一つ一つが正しいぶん、Generator 側も「これは無視してよい」と判断しにくく、修正と再評価が延々と続きます。対処は設計ルール ⑧ のとおり、終了条件を Evaluator の外に置くことです。Evaluator の賢さは「見つける力」であって「止める力」ではありません。
「指摘が多い」と「良い指摘」は別です。 筆者の観察で「指摘がまとまって出てくる」と書きましたが、量が出ること自体は Evaluator が機能している証拠であって、その指摘が正しいことの証拠ではありません。次の表のような失敗パターンは、Evaluator を分けても普通に起きます。
| 失敗パターン | 症状 | 対処するルール |
|---|---|---|
| 甘い承認 | 問題を見つけながら「軽微」として合格にする | ⑤ 甘さの監視、④ 証拠なしは gap |
| 重箱の隅 | スタイルや好みの指摘で、受け入れ基準の未達が埋もれる | ③ 基準を先に決める、受け取る側の優先順位 |
| 幻のバグ | 存在しない問題を指摘し、Generator が正しいコードを壊す | ⑥ 再現手順の要求、人間の最終判断 |
| 基準の後付け | Generator の出力を見てから合格ラインを決める | ③ 基準を先に決める |
| 指摘の消失 | その場で直して終わり、次の計画に残らない | ⑦ 次の計画に流す |
| 終わらないループ | 修正するたびに新しい指摘が出て、いつまでも合格に到達しない | ⑧ 終了条件を外で決める、③ 基準を先に決める |
指摘だけでは物は生まれません。 最後にもう一度書いておきます。Evaluator が強いのは Generator が成果物を出しているからです。組織でも同じで、指摘する側の強さを「作る側を支える構造」として使うのか、「作る側を萎縮させる構造」として使うのかで、同じ仕組みの結果はまったく変わります。
まとめ 🏁
AI エージェントも、人間の組織も、「作る」より「指摘する」ほうが強い構図は同じです。理由は検証が生成より容易だからで、LLM についてはそれが generation-verification gap として測定され、事前学習の計算量とともに差が広がることまで分かっています。一方で、自分で自分を採点すると甘くなることも、人間と LLM の両方で確認されています。
だから、やることはシンプルです。作る役と指摘する役を別の呼び出しに分け、指摘する役は成果物を直接編集しない役割にして、判定には証拠を付けさせ、その指摘を次の計画に流す。 そして、いつ止めるかは Evaluator に任せず、合格基準とラウンド数として先に決めておきます。Anthropic の evaluator-optimizer も、Anthropic Labs のハーネスも、Harness-of-Harness の QA Tester も、名前は違いますがこの骨格を共有しています。そしてこれは、IEEE 1012 が独立検証の条件として定めてきたことや、四つの目の原則とまったく同じです。
この記事で一つだけ持ち帰ってもらうなら、「Generator に『確認して』と頼むのをやめて、別の Evaluator に『証拠付きで判定して』と頼む」です。同じモデルで、明日から試せます。
参考 📚
- Anthropic. Building Effective Agents. 2024-12-19
- Prithvi Rajasekaran (Anthropic Labs). Harness design for long-running application development. 2026-03-24
- Jason Wei. Asymmetry of verification and verifier's rule. 2025-07-15（公開時のタイトルは "verifier's law"）
- Yuda Song, Hanlin Zhang, Carson Eisenach, Sham Kakade, Dean Foster, Udaya Ghai. Mind the Gap: Examining the Self-Improvement Capabilities of Large Language Models. ICLR 2025
- Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024
- Nat McAleese, Rai Michael Pokorny, Juan Felipe Ceron Uribe, Evgenia Nitishinskaya, Maja Trebacz, Jan Leike. LLM Critics Help Catch LLM Bugs. 2024-06-28
- Koki Wataoka, Tsubasa Takahashi, Ryokan Ri. Self-Preference Bias in LLM-as-a-Judge. 2024
- Karl Cobbe ほか. Training Verifiers to Solve Math Word Problems. 2021
- Haoyang Yan ほか. Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement. arXiv:2609.01481, 2026-09-01. CC BY 4.0
- IEEE Std 1012, IEEE Standard for System, Software, and Hardware Verification and Validation（IV&V の独立性の定義。解説: NASA IV&V Overview）
- M. E. Fagan. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal 15(3), 1976
- Alberto Bacchelli, Christian Bird. Expectations, Outcomes, and Challenges of Modern Code Review. ICSE 2013
- 関連する日本語記事: rizumita. LLMはなぜ『批判』が得意なのか？設計・実装品質を高めるAIレビューファースト開発術. Zenn, 2025-06-11