2026-09-26 発行（読了 6 分）
実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り
2025年半ば、Cognitionは自社ブログで「マルチエージェントを作るな」と名指しで警告した。分散した複数エージェントは互いの前提を共有できず、失敗が下流に伝播するというのがその理由だ。ところが同社は1年後、自社の主力製品に2体構成のマルチエージェント機構「Fusion」を実装し、2026年9月にはローカル環境にまで展開範囲を広げた。矛盾しているように見えるこの動きは、実は同じ問題意識から出た一つの結論だ — 「エージェントを増やすな」ではなく「役割と依存関係を先に固定してから、必要な分だけ増やせ」という設計原則への収束である。
Cognitionの Walden Yan は自社ブログで、Flappy Bird クローンの実装を2つのサブエージェントに分割した例を示す。片方はマリオ風の背景を作り、もう片方はそれと噛み合わない鳥のデザインを作った。それぞれの行動は「事前に共有されていない前提」に基づいており、最後にそれらを統合する役目のエージェントは矛盾した成果物を渡されて詰む。Yanはこれを「行動には暗黙の意思決定が埋め込まれている」と表現し、コンテキストを完全に共有しない限り、分散したエージェントの行動は互いに矛盾しうると指摘した。
この主張の1年後、同じCognitionが Devin に実装したのが Fusion だ。ただしこれは「多数のエージェントに分散させる」設計ではなく、frontierモデルの lead 1体とコスト効率の良い sidekick 1体という2体構成に絞り込んでいる。lead が計画・曖昧さの解釈・レビューを担い、委譲するタスクごとに制約と成功基準を書いた brief を sidekick に渡す。エージェント数を増やすことと、責任範囲を分割すること自体は別問題であり、後者さえ設計できれば2体でも十分に効果が出る、というのがこの1年で固まった結論だ。
Anthropicは2026年1月のブログで、複数エージェントが単一エージェントを上回るのは「コンテキスト汚染の回避」「並列化」「専門化」の3条件に該当する場合に限られると明言した。例えば注文履歴を大量に取得する顧客対応と技術的な問題診断を同一エージェントに任せると、無関係な情報がコンテキストを汚染する。こうした場合はサブエージェントで作業を切り分けた方がよい、という具合だ。逆に言えば、この3条件に当てはまらない限りは単一エージェントで始めるべきだと釘を刺している。
4月の追補記事では、この判断をさらに5パターンに分解している。汎用性が高く推奨されるのは「orchestrator-subagent」で、タスク分解の境界が明確な場合に最小限の調整コストで機能する。Anthropic自身のResearch機能もこの型で、lead agentが3〜5体のsubagentに並列で調査を委譲し、最後に引用チェックを行う専用のverification subagentへ渡す。検証専用エージェントへの委譲は情報の受け渡し量が少なく、伝言ゲーム的な劣化が起きにくいという理由で最も推奨される具体パターンとして挙げられている。
ここまでの2社が扱っているのは「1つのタスクを同時にどう分割するか」という並列方向のオーケストレーションだが、Sierraが2026年7月に発表した Horizon は別の軸を扱う。数日から数ヶ月にまたがる顧客対応（ローン審査や保険の承認手続きなど）を、単発の会話ではなく一連の関与として捉え、context engineがすべてのやり取りを縫い合わせて1つの文脈として保持する。エージェントは決められた手順をなぞるのではなく、過去のやり取りの結果を踏まえて次にどう動くかを都度判断する。
これが「並列化」ではなく「時間軸方向の一貫性」の問題である点が重要だ。CognitionやAnthropicの議論がサブエージェント間でコンテキストをどう共有するかを扱うのに対し、Horizonは同一エージェント（あるいはその系譜）が数週間後の自分に対して、どうコンテキストを引き継ぐかを扱っている。マルチエージェント設計の論点は「空間的な分割」と「時間的な継続」の2軸に分けて考える必要があるという実例だ。