前の記事では、より底の層を扱いました。複数Agentがどう連携し、communication costを燃やしすぎないか、という話です。ただし土台が安定しても、品質が自動的についてくるわけではありません。
開発でよく見る流れがあります。1つのAgentにpatchを書かせ、同じAgentにreviewさせる。返事はlooks good。テストを走らせると、そのまま落ちる。連携が滑らかかどうかと、本番に出せるかどうかの間には、まだ1層まるごと方法論が足りません。
ここではその層を扱います。重要なのは、たくさんのAgentを呼べるかではありません。各ステップが本当に新しい情報を持ち込んでいるかです。以下の3つのpatternには研究の裏付けがあり、前提も単純です。どれか1つ欠けると、後段のreviewは簡単に演技になります。
Pattern 6：Challenge Loop
よくある偽reviewはこうです。Agent BにAgent Aのコードを見せると、「エラー処理を検討してください」「ここにリスクがある可能性があります」のような専門的に見えるコメントを返します。真面目にreviewしているように見えますが、情報量は低い。2ラウンド直してもbugは残ります。なぜなら、最初から最後まで誰もテスト可能な証拠を出していないからです。
より安定するルールはこれです。各challengeには必ず証拠を付ける。多いのは失敗するテストや再現できる反例です。場合によってはspecのどの条項を満たしていないかを直接指摘するだけでもよい。これらが出せないものはnoiseとして扱います。少し厳しく見えますが、効果はかなり違います。reviewが「ここが何となく変」から「この入力で失敗し、この受け入れ条件を満たしていない」に変わるからです。
2025年にはAIの迎合を測る研究があり、多くのLLM回答を調べた結果、58%に迎合傾向がありました。平たく言えば、モデルはユーザーに合わせやすく、前のモデルにも合わせやすい。reviewを意図的に対立的にしないと、自然にrubber stampへ滑ります。「reviewして」は空すぎます。「失敗を証明できる箇所を3つ探す」または「仕様違反の項目だけ返す」と頼むほうがよい。
追うべき数字が1つあります。challengeが実際の変更につながった割合です。1回のreviewで10点出て、コードやspecを変えたのが1点だけなら、命中率は20%未満で、そのラウンドは多くが演技です。問題はreviewerが弱いことではなく、promptが批判っぽい文章を生成する方向に連れていったことです。
このpatternはspec reviewで特に効きます。ある金融アルゴリズムのspecでは、challenge loopを6ラウンド回しました。R1でいきなり3つの本物の問題を捕まえました。データリーク、slippage modelの欠落、retry pathの上限なしです。R2ではdata split window（purge window）のbugが出ました。6ラウンド目で有効なchallengeが0になり、外部テストも全greenで終了。6ラウンド回したこと自体が厳密さではありません。重要なのは、各ラウンドが証拠を出し、判断する人が変えるべきか分かることです。
Challenge loopには収束上限も必要です。通常、主要な問題は最初の2-3ラウンドで出るべきです。それ以上引っ張ると、各ラウンドが長くなり、方向がずれることがよくあります。研究ではこの種の過剰思考ループを高頻度の失敗パターンとして分類しています。ラウンドが長いほど皆が頑張っているように見えますが、情報密度は下がります。
Pattern 7：クロスファミリーレビュー
モデルのself-reviewは、ほぼ飛ばしてよいです。
理由は単純です。モデルが何かを書いた直後、その推論経路はまだ熱い。自分の直前の論理に沿って成果物を見るので、実際より合理的に見えます。研究もかなり直接的です。Self-Correction Benchは64.5%の盲点率を測定し、2026年の別研究では、モデルが自分の成果物をreviewすると、他者のものより約5倍甘くなることが示されました。リスクのある内容も通しやすくなります。
Review予算は儀式ではなく独立性に使います。一番実用的なのは、異なるモデルファミリーで相互reviewすることです。ChatGPTが書いたものをClaudeに見せる。Claudeが書いたものをChatGPTに見せる。理由も実務的です。350以上のモデルを見た2025年の分析では、同じファミリー内のエラー相関が、異なるファミリー間より明らかに高いと分かりました。盲点を捕まえるには、reviewerに違う既存バイアスを持ち込ませる必要があります。
ただし神格化はしません。frontier model同士の出力類似度は依然として高く、ICML 2025の研究では最高で90%近くまで見えています。クロスファミリーレビューは命中率を上げますが、全知にはなりません。多くの盲点は全モデルで共有されます。specが曖昧、テストが弱い、背景知識が欠けている。ここはreviewerを替えても漏れます。
警戒したい反patternは「Validation Retreat」です。修正ループが詰まると、Agentはテストを変えて画面をgreenにし、解決したふりをしがちです。表面上は成功に見えますが、基準を緩めただけです。修正をreviewするときは、このラウンドでテストを触ったかを見る。触ったなら、specがそれを許可したか。変えたのは受け入れ基準か、本当のエラーか。
実戦例です。ChatGPTのCodexにpatchを書かせると、self-reviewはほぼ即通りました。その後、Claude Sonnetに受け入れ条件を1つずつ見せると、すぐ3つのcritical issueを捕まえました。しかも全部、新機能ではなく古い経路に隠れていました。Codexの注意は直前に変えた新しいロジックに集中していて、自然にそこが見えなかった。別ファミリーで見ると、視点は本当に変わります。
Reviewチームは大きければ良いわけでもありません。研究と実務はかなり似ていて、reviewerは2つ前後がsweet spotです。それ以上増やすと限界効用が落ち、調整コストだけ伸びます。一般的なコード変更では、書くAgent1つ、クロスファミリーreviewer1つ、明確なspecとテスト。このほうが3-4人のreviewerを積むより安定します。
Pattern 8：Spec駆動開発
多くの人はbugが多い原因をreview不足だと考えます。実際には、天井はたいていspecにあります。
最初にAgentへ渡すtaskが曖昧だと、その後に何ラウンドreviewしても、書くAgentとreviewerは同じ霧の中を探っています。実行可能なspecがないAI reviewは、構造的な循環です。両者が同じ曖昧な文章から推論し、当たれば幸運、外れれば一緒に外れます。
この話には数字があります。ClarifyGPTの研究では、spec refinementをフローに入れると、Pass@1が70.96%から80.80%へ上がりました。13.87%の改善です。多くの修正ループはコードを直しているように見えて、実はspecが本来明記すべきものを補っています。
複雑なhandoffでは、私はだいたい次のブロックを固定で入れます。
Objective
Context
Acceptance Criteria
Interface Contract
Anti-patterns
Review Checklistデータやbacktestに関係する課題なら、データ完全性の要求も足します。look-ahead禁止、transaction costを現実的に扱う、data split方法を明記する、などです。書くのは少し面倒ですが、後で爆発する大量の問題を前で止められます。
比較例：
- 以前のspec：「regime detectorを改めて、相対APRではなく絶対APRを見る」。
- 今のspec：最低限、objective、いくつかの受け入れ条件、データ完全性の制約、明確に禁止する実装を入れる。
このやり方は手間ですが、効果ははっきりしています。Codexが最初に返すものが欲しい形に近くなり、修正ループも平均3回から1-2回へ縮むことが多いです。
Specは厚ければ良いわけでもありません。簡単なtaskなら口頭指示と1-2個の受け入れ条件で十分です。中程度の複雑さの仕事に完全テンプレートを無理に当てると、フローは明らかに遅くなります。原則は、曖昧さを避けるところまで書くこと。余計なものは足さない。Specの役割は収束であり、頭の中の雑音を次のAgentに流し込むことではありません。
Bonus：3つのpatternを1本にする
よく使う開発パイプラインは短いです。
Spec（Structured Handoff）
→ Challenge Loop（specの穴を探す）
→ 実装
→ Cross-family Review（codeの穴を探す）
→ 修正
→ 完了中核原則は1つだけです。各ステップは新しい情報を持ち込む必要がある。2つのステップが同じモデルに同じ素材をもう一度考えさせているだけなら、削る方向にします。
Multi-agentの並行処理も同じです。DeepMindのorchestration scaling研究は参考になります。並行分割できるtaskは効果が80.9%増えることがあります。一方、本質的に直列推論の仕事では、性能が39%から70%落ちることがあります。Communication costも1.7倍という指数で伸びます。平たく言うと、Agentが増えると、やっているのではなく互いに待ち、その後に説明と検証へ時間を使うことが多い。
Agent数は大きくしすぎない。3-4個がだいたい上限です。それ以上はtoken消費が単一Agentフローの3.5倍前後まで膨らみやすい。モジュールが本当に独立して分けられるときだけ並行化する。それ以外は、短いフローと高い独立性のほうが安定します。
モデルは進歩し続けます。2024-2026年の研究にある具体的な数字は、そのうち書き換えられるはずです。盲点率は下がり、review toolは強くなり、spec生成もかなりまともになるでしょう。
それでも短期的には変わりにくい底の原則があります。Reviewには独立した視点が必要。Spec品質が上限を決める。ある地点以降の反復は、たいてい空回りです。今のself-review盲点率はまだ64.5%という桁にあります。モデルが進めば、この数字は必ず下がります。どの水準まで下がればself-reviewを主流程に戻す価値が出るのかは、まだ開かれた問題です。
関連記事
GitHub: https://github.com/p3nchan/orchestration-playbook
こぺんぎんの体験談
OpenClaw上で実際に走っている組み合わせはOpus / Sonnet / ChatGPTの3 Agentで、このChallenge → クロスファミリーreview → Spec駆動のフローもそこから育ちました。最も効いたのは、Opusが書いたspecをCodexに粗探しさせ、実装はSonnetに見せること。盲点が別ファミリーに捕まる命中率は、同ファミリーのself-reviewよりかなり高いです。Specを薄くしすぎない、challengeには証拠を付ける、reviewerは別ファミリーにする。この3つを一緒にやって初めて安定します。
よくある質問
Q: なぜAIのself-reviewは信頼しにくいのですか？
研究では、AIモデルが自分の成果物をreviewすると64.5%の盲点率があり、自分の書いたものには約5倍寛容になることが示されています。同じモデルに書かせて同じモデルにreviewさせると、多くの問題は見えません。解決策は別のモデルファミリーでreviewすることです。
Q: Challenge Loopとは何ですか？
Challenge Loopは対立的なreviewプロセスです。あるAgentが成果物を出し、別のAgentが問題を探します。ただし各challengeにはテスト可能な証拠が必要です。証拠のない批判は数えません。この方法は通常のreviewより本物の問題を見つけやすいことが分かっています。
Q: なぜspec品質はreview回数より重要ですか？
研究では、spec品質を改善するとコード正確率が13.87%上がり、reviewを1回増やすより効果が高いとされています。spec自体が曖昧だと、reviewerとcoderが同じ誤解を共有し、何度reviewしても発見できません。
— Penchan