第6章: サブエージェントとマルチエージェント論争

ハーネス設計で、エンジニアが最も激しく意見を戦わせる論点があります——1つのエージェントで解くか、複数のサブエージェントに分けるか。 この問いには、業界を代表する2社が真っ向から対立する答えを出しています。Anthropic は「マルチエージェントは効く」と言い、Cognition は「マルチエージェントを作るな」と言う。 本章はこの論争を公平に解きほぐし、あなた自身が判断するための軸を提供します。

設計上の最大の論争

Anthropic の「How we built our multi-agent research system」と、Cognition の「Don't Build Multi-Agents」。 タイトルからして正面衝突です。しかし両者をよく読むと、対立の根っこには共通の論点——コンテキストをどう扱うか——があることが見えてきます。

Anthropic — オーケストレーター・ワーカー

Anthropic が推すのは オーケストレーター・ワーカーパターン。リードエージェントが全体計画を持ち、専門サブエージェントが それぞれクリーンなコンテキストウィンドウで深い作業を並列に行います。 各サブエージェントは数万トークン以上を探索しても、親には凝縮した要約（しばしば1,000〜2,000トークン）だけを返すのが肝。 これにより詳細な検索コンテキストはサブエージェント内に隔離され、リードは統合・分析に集中できます。

graph TD
  L[リードエージェント\nオーケストレーター]
  L --> W1[サブエージェント1\nクリーンな文脈で探索]
  L --> W2[サブエージェント2]
  L --> W3[サブエージェント3]
  W1 --> R[凝縮した要約を返す\n1000〜2000トークン]
  W2 --> R
  W3 --> R
  R --> L
  style L fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style W1 fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style W2 fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style W3 fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style R fill:#14b8a6,stroke:#0d9488,color:#fff

性能面では、Opus 4 をリード・Sonnet 4 をサブエージェントにした構成が、単一の Opus 4 を90.2%上回ったと報告されています。 並列探索が効く調査タスクで、マルチエージェントの価値が示された形です。

Cognition — 「マルチエージェントを作るな」

対して、Devin を運営する Cognition の Walden Yan は真逆を主張します。ナイーブなマルチエージェントは 「サブエージェント同士が互いの作業のコンテキストを持たない」ため、矛盾した暗黙の決定を下し、悪い結果を生むというのです。 彼が掲げる2原則はこうです。

Cognition の推奨は単一スレッドの線形エージェント。極端に長いタスクには、会話履歴を圧縮する専用モデルを足します （第4章のコンパクションと同じ発想）。皮肉なことに、彼らは Claude Code の「サブエージェントはコードを実行せず質問に答えるだけ」という意図的なシンプルさを好例として挙げています。

対立の解釈 — タスク特性で選ぶ

では、どちらが正しいのか。一次情報を丁寧に読むと、両者はドメインで使い分けるべきという整理が見えてきます。 Anthropic 自身も「理想の技法はユースケース次第」「マルチエージェントは並列探索が報われる複雑な研究・分析向き」と限定しています。 Cognition は「プログラミングや長文執筆のような『深く狭い』ドメインでは、記憶の一貫性と論理的整合性が最重要」と主張します。

つまり「書き込みが衝突しうるタスク（コーディング）＝単一」「読み取り中心で並列探索が効くタスク（調査）＝マルチ」という軸で整理できます。 両者は対立するタイトルを掲げながら、「コンテキスト共有が鍵」という点ではむしろ一致しているのです。

コスト — マルチは約15倍

実利的な制約も忘れてはいけません。Anthropic によれば、マルチエージェントはトークン消費が約15倍（単一エージェントですらチャットの約4倍）。 したがって「タスクの価値が、増分コストを賄えるほど高い」場合にのみ経済合理性があります。 性能が+90%でも、コストが15倍なら、安価な定型タスクには割に合いません。