8月7日、Quesmaが「I wired 4 models together in Claude Code. It backfired 4 ways on Terminal-Bench」と題した記事を公開した。4つのモデルを連携させたマルチエージェント構成でベンチマークに臨んだところ、単一モデルで首位を取ったエントリーの約2倍のコストをかけながら7位という結果に終わった——しかも4種類の失敗はいずれも、モデルの能力ではなく「委譲」という設計行為そのものが引き起こしたものだ。
構成の概要
実験では、Terminal-Bench 2.1というベンチマークを使用した。エージェントをサンドボックス化されたターミナルに投入し、コンパイル・パスワード回復など89のコマンドライン実タスクを各5回まで試行させて正答率を計測する環境だ。
Claude Codeのサブエージェント機能を活用し、以下の4モデルをサードパーティフレームワークなしで直結した構成で臨んだ。
| 役割 | モデル | 担当 |
|---|---|---|
| Orchestrator | Fable 5※ | 計画・委譲のみ。ファイル編集はしない |
| Scout | Haiku 4.5 | 読み取り専用の偵察 |
| Executor | Opus 5 | 編集・ビルド・デバッグ |
| Verifier | Sonnet 5 | 成果物のレビュー |
※「Fable 5」は元記事に記載されたモデル名だが、Anthropicの現行公式ラインナップには存在しない名称であるため、読者は内部実験モデルまたは記事執筆時点での仮称として参照されたい。
結果は78%のタスク解決率で7位、総コスト1,178ドル。単一モデルで首位に立ったエントリーの約2倍のコストで、ポジションは7番手だった。
最大の失敗：委譲がClaudeを「拒否」に追い込んだ
4つの失敗の中で最も致命的だったのが、セキュリティ系タスクの全拒否だ。
vulnerable-secret、break-filter-js-from-html、password-recoveryの3タスクは、5回の試行で一度も実行されなかった。Executorに回す前に、安全分類器が次のメッセージを返してゼロコストで終了した：
Claude Code can't respond to this message with Opus 5. Try rephrasing the request in a new session or change your model.
興味深いのは、同じ3タスクを単一エージェントのClaude Codeセッションから直接Opus 5に投げると、6回中6回すべて解決したという点だ。モデルが変わったわけでも、タスクが変わったわけでもない。変わったのは「フレーミング」だけだ。
別のエージェントから切り出されて渡ってくる「サブタスク」として受け取ると、「秘密を見つけろ」という指示が人間から直接届く場合より安全分類器に怪しく映るらしい。確かなメカニズムは不明だが、効果は証明されている。この3タスクが通っていれば、スコアは80.5%となり7位から3位に浮上していた。
3つの追加失敗
Verification（検証ステップ）を任意にしてスコアが48ポイント落ちた
Verifierの呼び出しはOrchestrator任せで、実際に呼ばれたのは全体の76%だった。このたった一つの設計判断が最大の精度格差を生んだ：
- Verifier呼び出しあり：解決率91%
- Verifier呼び出しなし：解決率43%
CLAUDE.mdに「verifies the work（成果物を確認する）」とは書いたが、「finishの前に必ずverifyせよ」とは書かなかった。検証をオプションにしたまま放置した結果、スキップされた25%のうち半数が失敗で終わった。
Executorに最高価格モデルを置いた
コストの内訳を見ると構造的な間違いが明らかだ：
| 役割 | モデル | コスト比率 | 金額 |
|---|---|---|---|
| Executor | Opus 5 | 58% | $689 |
| Orchestrator | Fable 5 | 33% | $390 |
| Verifier | Sonnet 5 | 7% | $82 |
| Scout | Haiku 4.5 | 2% | $24 |
出力トークン数とコストの相関係数はr=0.93。つまりコストはほぼ「誰がExecutorか」で決まる。最も安いHaikuをScoutに置いたが、Scoutはタスク解決率をたった1ポイントしか動かしていない。最も高いOpusを最もトークンを生成するポジションに置いた。
設計の意図は「安い手、高いブレイン」——すなわち単純な手作業は安価なモデルに、高度な判断・推論は高価なモデルに任せるという役割分担だった。しかし実際には、最も多くのトークンを生成する「手」の役割（Executor）に最も高価なOpusを配置しており、意図とコスト配分が真逆になっていた。
6回以上の委譲でシステムが崩壊した
委譲回数とコスト・成功率の関係：
- 3〜5回の委譲：解決率90%、平均2.41ドル/試行
- 6回以上の委譲：解決率50%、平均9.51ドル/試行
6回を超えると、同じ作業を再委譲し始め、トークンを4倍近く消費しながら成功率は半減した。「委譲を許可する」だけでなく「委譲回数に上限を設ける」ことが必要だ。
それでも見えた可能性
失敗ばかりではない。今回の実験には、次の設計への手がかりとなる数字も残った。
易しいタスクから難しいタスクへの解決率の変化は85%→79%→76%と緩やかな下降にとどまった。難しいタスクは1試行あたりのコストが2.4倍かかるにもかかわらず、複数モデルの協調自体は崩れなかった。つまりマルチエージェント協調の枠組みそのものは機能しており、今回の失敗は「連携が難しすぎた」のではなく、連携の条件を正しく整えられなかった設計の問題だと読める。
また1回の試行では78%だが、5回の試行機会を活かすと93%まで到達する。壁は能力の欠如ではなく、初回の信頼性にある。言い換えれば、Verifierの必須化や委譲上限の設定といった構造的な修正で、この差を縮められる余地が十分にある。
まとめ
この実験が示した核心は単純だ。マルチエージェント構成の問題は、モデルの能力ではなくフレームワークの設計にある。今回の4失敗はすべて、PromptやRoleの設計ミスから生じたものだ。次の実験として、ExecutorをSonnetかHaikuに降格させ、Opusを本当に難しい推論だけに使う再設計が予告されている。
詳細はI wired 4 models together in Claude Code. It backfired 4 ways on Terminal-Benchを参照していただきたい。
