Anthropic の公式ガイドは、マルチエージェント化が効くケースを「コンテキスト保護」「並列化」「専門化」の3つに整理する。コンテキスト保護とは、あるタスクの探索ノイズが次のタスクの推論を汚染するのを防ぐこと。並列化とは、独立した調査経路を同時に走らせて網羅性を上げること。専門化とは、ツールが15〜20個を超えると単一エージェントでは選択ミスが増えるため、担当を分けること。逆に同ガイドは「テレフォンゲーム問題」を名指しし、計画→実装→テストのようなワークフローの工程で分割すると、前工程の判断が引き継がれず品質が落ちると警告する。
この基準の下で最も安定するのが検証専用サブエージェントだ。検証は他の作業の結果を受け取って合否を返すだけで、他エージェントの途中経過を知る必要がない——つまりコンテキストが構造的に独立している。逆に「早すぎる合格判定」を防ぐため、テストスイート全体の実行のような明示的な完了条件を与える必要があるとも指摘されている。
", "examples": [ { "product": "Claude の Research 機能（Anthropic 公式）", "approach": "Lead agent が3〜5体のsubagentを並列生成し、独立したコンテキストで探索させてから引用付きで統合する", "detail": "内部評価で単一エージェント比90.2%の性能改善を報告する一方、トークン消費は通常のチャット比で約15倍かかると明記しており、並列化の利得とコストを両方定量化して公開している点が判断材料として貴重。", "source_url": "https://www.anthropic.com/engineering/multi-agent-research-system" }, { "product": "Claude（Anthropic 公式ガイド）", "approach": "『テレフォンゲーム問題』を名指しし、工程ではなくコンテキストの独立性で分割すべきと提言", "detail": "検証専用のサブエージェント（テストスイート実行など）だけは一貫して機能するという具体的な設計パターンを挙げている。", "source_url": "https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them" } ], "takeaway": "自分のタスクを『計画/実装/テスト』のような工程で割ろうとしていないか点検する。工程ではなく『他のサブエージェントの出力を見なくても完遂できるか』で線を引く。" }, { "heading": "Cognition は逆の結論 — コーディングでは全トレースを共有せよ", "body_html": "コーディングエージェント Devin を作る Cognition は「共有すべきは個別メッセージではなく、エージェントの全トレース」「アクションは暗黙の決定を伴い、決定が食い違えば結果も食い違う」という2原則を掲げる。実例として、2体のサブエージェントに同じ Flappy Bird 実装を並列に任せたところ、一方が『スーパーマリオ風』のグラフィックを、もう一方が非互換の鳥アセットを作ってしまった、という具体的な失敗を報告している。どちらも指示は誤読していないが、互いの暗黙の設計判断が見えなかったために結果が矛盾した。
この失敗はコーディング特有だ。前の判断（変数名、データ構造、UIのトーン）が後続のコードの前提になり続けるため、コンテキストを割った瞬間に暗黙の合意が失われる。そのため Cognition は並列コーディングを避け、単一スレッド設計をデフォルトにし、長時間タスクでは会話履歴を圧縮するレイヤーを挟むことで文脈を保つ方針を取る。
", "examples": [ { "product": "Devin（Cognition 公式ブログ）", "approach": "『共有すべきは個別メッセージではなくエージェントの全トレース』という原則を掲げ、並列コーディングを避けて単一スレッド設計をデフォルトにする", "detail": "検証として、2体のサブエージェントに同じ Flappy Bird 実装を並列に任せると設計判断が食い違って破綻するという具体例を報告。長時間タスクでは会話履歴を圧縮するレイヤーを挟み、単一スレッドのまま文脈を保つ。", "source_url": "https://cognition.com/blog/dont-build-multi-agents" }, { "product": "Claude Code（Cognitionによる分析）", "approach": "Cognition は同ブログで、Claude Code を『サブタスクを生成するが、そのサブタスクエージェントとは決して並行作業しない』設計の代表例として引用", "detail": "OpenAI の Swarm や Microsoft の AutoGen が推す並列マルチエージェント設計とは一線を画す事例として名指ししている。", "source_url": "https://cognition.com/blog/dont-build-multi-agents" } ], "takeaway": "コーディングのように『前の判断が次のコードの前提になる』タスクは、並列化よりも全トレース共有+圧縮を優先したほうが壊れにくい。" }, { "heading": "動的サブエージェント生成というインフラ側の解", "body_html": "LangChain の Deep Agents は、task() というビルトイン関数でサブエージェントをコードから動的に生成する仕組みを導入した。エージェント自身が軽量なインタプリタ上で実行されるコードを書き、ループ・分岐・Promise.all のような制御フローをターンごとのモデル判断ではなく確定的なコード実行として走らせる。公式には「分類して実行」「ファンアウトして統合」「敵対的検証」「生成してフィルタ」「トーナメント」「ドライになるまでループ」の6パターンが定義されている。
これは「マルチエージェントを使うべきか」という問いを、「この6パターンのどれに当てはまるか」という問いに置き換えるインフラだ。特に敵対的検証パターンは、Anthropic が指摘する『検証専用サブエージェントが最も安定する』という知見と一致しており、異なる企業が独立に同じ設計に収束していることを裏付ける。
", "examples": [ { "product": "Deep Agents（LangChain 公式）", "approach": "task() 関数でサブエージェントをコードから動的に生成し、制御フローをコードとして確定的に実行する", "detail": "『分類して実行』『ファンアウトして統合』『敵対的検証』『生成してフィルタ』『トーナメント』『ドライになるまでループ』の6パターンを公式に定義。うち敵対的検証パターンは、Anthropic の『検証専用サブエージェントが最も安定する』という知見と一致する。", "source_url": "https://www.langchain.com/blog/introducing-dynamic-subagents-in-deep-agents" } ], "takeaway": "マルチエージェントを検討するときは『対話的な役割分担』ではなく、この6パターンのどれかとしてコードで表現できるかをまず確認する。当てはまらないなら単一エージェントに戻したほうが安全。" } ] }, "editorial": "Anthropic と Cognition は正反対の結論を出しているように見えるが、実際は同じ基準を別の場所に適用しているだけだ。『他のエージェントの判断を見なくても仕事が完結するか』という一点で分割の可否を判断しており、独立した探索が多いリサーチではこの基準を満たしやすく、前の判断が次のコードの前提になり続けるコーディングでは満たしにくい、というだけの話だ。", "quick_picks": [ { "title": "Cognition『マルチエージェントで実際に機能しているもの』", "summary": "『書き込みは単一スレッドのまま、判断だけ複数エージェントで補う』という2パターン(レビューエージェント/より賢いモデルへのエスカレーション)を報告。本文で紹介した『コーディングでは並列化するな』という結論の、半年後の実践的な着地点にあたる。", "url": "https://cognition.com/blog/multi-agents-working" }, { "title": "Anthropic『AIエージェントのための実践的コンテキストエンジニアリング』", "summary": "サブエージェントは1,000〜2,000トークン程度に凝縮した要約だけをリードエージェントに返すべきと提言。本文で扱った Claude Research 事例と同じ設計思想を、より一般的なガイドラインとして書いたもの。", "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents" }, { "title": "OpenAI Agents SDK『マネージャー型』と『ハンドオフ型』", "summary": "中央のオーケストレーターが専門エージェントをツールとして呼ぶ『マネージャー』型と、会話の主導権ごと専門エージェントに渡し切る『ハンドオフ』型を明確に分けて文書化。本文のオーケストレーター/ワーカー型とは異なる第三の分割軸を提示している。", "url": "https://openai.github.io/openai-agents-python/multi_agent/" } ] }