{
  "issue": "2026-09-26",
  "generated_at": "2026-09-26T07:00:00+09:00",
  "theme": {
    "title": "マルチエージェント協調は「並列に投げる」から「役割を絞った2体」に収束した — Fusion 型アーキテクチャが解いた失敗伝播問題",
    "category": "multi-agent-orchestration",
    "lede": "2025年半ば、Cognitionは自社ブログで「マルチエージェントを作るな」と名指しで警告した。分散した複数エージェントは互いの前提を共有できず、失敗が下流に伝播するというのがその理由だ。ところが同社は1年後、自社の主力製品に2体構成のマルチエージェント機構「Fusion」を実装し、2026年9月にはローカル環境にまで展開範囲を広げた。矛盾しているように見えるこの動きは、実は同じ問題意識から出た一つの結論だ — 「エージェントを増やすな」ではなく「役割と依存関係を先に固定してから、必要な分だけ増やせ」という設計原則への収束である。",
    "tldr": [
      "Cognitionは「分散マルチエージェントは前提の食い違いで失敗が伝播する」と自ら警告した後、lead+sidekickの2体だけに絞った制約付き構成「Fusion」を主力製品化し、2026年9月にローカル環境まで展開した。",
      "Anthropicは「コンテキスト汚染の回避・並列化・専門化」の3条件に該当する場合のみ複数エージェントを勧め、それ以外はまず単一エージェントで始めるようガイドラインで明言している。",
      "Sierraの Horizon は並列実行ではなく、数日〜数ヶ月にまたがる顧客対応を context engine で一本の文脈として繋ぐ、時間軸方向のオーケストレーションという別解を示した。"
    ],
    "sections": [
      {
        "heading": "分散型マルチエージェントはなぜ失敗が伝播するのか",
        "body_html": "<p>Cognitionの Walden Yan は自社ブログで、Flappy Bird クローンの実装を2つのサブエージェントに分割した例を示す。片方はマリオ風の背景を作り、もう片方はそれと噛み合わない鳥のデザインを作った。それぞれの行動は「事前に共有されていない前提」に基づいており、最後にそれらを統合する役目のエージェントは矛盾した成果物を渡されて詰む。Yanはこれを「行動には暗黙の意思決定が埋め込まれている」と表現し、コンテキストを完全に共有しない限り、分散したエージェントの行動は互いに矛盾しうると指摘した。</p><p>この主張の1年後、同じCognitionが Devin に実装したのが Fusion だ。ただしこれは「多数のエージェントに分散させる」設計ではなく、frontierモデルの lead 1体とコスト効率の良い sidekick 1体という2体構成に絞り込んでいる。lead が計画・曖昧さの解釈・レビューを担い、委譲するタスクごとに制約と成功基準を書いた <code>brief</code> を sidekick に渡す。エージェント数を増やすことと、責任範囲を分割すること自体は別問題であり、後者さえ設計できれば2体でも十分に効果が出る、というのがこの1年で固まった結論だ。</p>",
        "examples": [
          {
            "product": "Cognition「Don't Build Multi-Agents」（Walden Yan, 2025.06）",
            "approach": "分散型マルチエージェントはコンテキスト非共有により失敗が下流に伝播する",
            "detail": "Flappy Bird クローンを2つのサブエージェントに分割した結果、互いに矛盾する成果物（マリオ風背景＋非対応の鳥）が生まれた事例を根拠に、複数エージェントへの安易な分散を戒めている",
            "source_url": "https://cognition.com/blog/dont-build-multi-agents"
          },
          {
            "product": "Cognition Devin Fusion / Local Fusion",
            "approach": "lead（frontierモデル）とsidekick（低コストモデル）の2体構成に制約と成功基準付きでタスクを委譲",
            "detail": "2026年6月にDevin Cloudでプレビューし、9月11日にDesktop・CLIへ展開。エージェント数を絞り、委譲ごとにbriefで前提を明示することで『分散＝失敗伝播』の問題を回避している",
            "source_url": "https://cognition.com/blog/local-fusion"
          }
        ],
        "takeaway": "複数エージェント化を検討するなら、まず『エージェントの数』ではなく『委譲するタスクの境界と成功基準を明文化できるか』を先に問う。それが書けないなら2体でも失敗する。"
      },
      {
        "heading": "Anthropicの判断基準: いつマルチエージェントを使うべきか",
        "body_html": "<p>Anthropicは2026年1月のブログで、複数エージェントが単一エージェントを上回るのは「コンテキスト汚染の回避」「並列化」「専門化」の3条件に該当する場合に限られると明言した。例えば注文履歴を大量に取得する顧客対応と技術的な問題診断を同一エージェントに任せると、無関係な情報がコンテキストを汚染する。こうした場合はサブエージェントで作業を切り分けた方がよい、という具合だ。逆に言えば、この3条件に当てはまらない限りは単一エージェントで始めるべきだと釘を刺している。</p><p>4月の追補記事では、この判断をさらに5パターンに分解している。汎用性が高く推奨されるのは「orchestrator-subagent」で、タスク分解の境界が明確な場合に最小限の調整コストで機能する。Anthropic自身のResearch機能もこの型で、lead agentが3〜5体のsubagentに並列で調査を委譲し、最後に引用チェックを行う専用のverification subagentへ渡す。検証専用エージェントへの委譲は情報の受け渡し量が少なく、伝言ゲーム的な劣化が起きにくいという理由で最も推奨される具体パターンとして挙げられている。</p>",
        "examples": [
          {
            "product": "Anthropic「When to use multi-agent systems (and when not to)」（2026.01.23）",
            "approach": "コンテキスト汚染回避・並列化・専門化の3条件に該当する場合のみ複数エージェント化を推奨",
            "detail": "3条件に当てはまらないケースでは、数ヶ月かけて作った複雑なマルチエージェント構成を単一エージェント＋プロンプト改善で置き換えられた事例があると明記している",
            "source_url": "https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them"
          },
          {
            "product": "Anthropic Research（orchestrator-worker型）",
            "approach": "lead agentが3〜5体のsubagentへ並列調査を委譲し、専用の引用検証subagentで最終チェックする",
            "detail": "subagentへの委譲契約に目的・出力形式・使うツールとソース・作業範囲を明記することが、挙動を制御する上で最も重要な要素だったとしている",
            "source_url": "https://www.anthropic.com/engineering/multi-agent-research-system"
          }
        ],
        "takeaway": "複数エージェント化の是非を『技術的に可能か』で判断しない。コンテキスト汚染・並列化・専門化の3条件のどれにも当てはまらないなら、まず単一エージェントに戻す方が速い。"
      },
      {
        "heading": "並列ではなく時間軸のオーケストレーション: Sierra Horizon という別解",
        "body_html": "<p>ここまでの2社が扱っているのは「1つのタスクを同時にどう分割するか」という並列方向のオーケストレーションだが、Sierraが2026年7月に発表した Horizon は別の軸を扱う。数日から数ヶ月にまたがる顧客対応（ローン審査や保険の承認手続きなど）を、単発の会話ではなく一連の関与として捉え、context engineがすべてのやり取りを縫い合わせて1つの文脈として保持する。エージェントは決められた手順をなぞるのではなく、過去のやり取りの結果を踏まえて次にどう動くかを都度判断する。</p><p>これが「並列化」ではなく「時間軸方向の一貫性」の問題である点が重要だ。CognitionやAnthropicの議論がサブエージェント間でコンテキストをどう共有するかを扱うのに対し、Horizonは同一エージェント（あるいはその系譜）が数週間後の自分に対して、どうコンテキストを引き継ぐかを扱っている。マルチエージェント設計の論点は「空間的な分割」と「時間的な継続」の2軸に分けて考える必要があるという実例だ。</p>",
        "examples": [
          {
            "product": "Sierra Horizon（2026.07.16）",
            "approach": "context engineで数日〜数ヶ月にまたがる顧客対応を1つの文脈として繋ぎ、都度の関与ごとにエージェントが次の行動を再判断する",
            "detail": "成果報酬型（tokenではなく成果に課金）のモデルと組み合わせることで、単発対話の最適化ではなく関係全体の最適化を狙っている",
            "source_url": "https://sierra.ai/blog/horizon"
          }
        ],
        "takeaway": "『マルチエージェントにすべきか』を検討する前に、自分の課題が空間的な分割（並列サブエージェント）と時間的な継続（長時間軸の文脈保持）のどちらの問題なのかを切り分ける。"
      }
    ]
  },
  "editorial": "1年前に『マルチエージェントを作るな』と言った会社が、今は制約付きの2体構成を主力製品にしている。これは方針転換ではなく、同じ診断から出た一貫した結論だ — 問題は『エージェントの数』ではなく『前提の共有と責任範囲の明文化』であり、それさえ設計できれば2体でも3条件を満たす並列でも機能する。エージェント数を増やす前に、まず自分のタスクが本当にこの3条件のどれかに当てはまるのかを疑う姿勢が、今のところ最も再現性の高い判断基準になっている。",
  "quick_picks": [
    {
      "title": "Fusion、DevinのDesktop・CLIにも展開（Cognition, 2026.09.11）",
      "summary": "Devin CloudでテストしてきたFusion（lead+sidekickの2体構成）をローカル開発環境に拡大した発表。本文で扱った『分散させず役割を絞る』設計が実運用の主戦場にまで広がったことを示す。",
      "url": "https://cognition.com/blog/local-fusion"
    },
    {
      "title": "マルチエージェント協調パターン5選（Anthropic, 2026.04.10）",
      "summary": "orchestrator-subagent・generator-verifier・agent teams・message bus・shared stateの5パターンを整理し、まずorchestrator-subagentから始めることを推奨する記事。本文セクション2の判断基準をパターンとして具体化している。",
      "url": "https://claude.com/blog/multi-agent-coordination-patterns"
    },
    {
      "title": "How and when to build multi-agent systems（LangChain）",
      "summary": "LangChain自身のフレームワーク設計思想として、いつマルチエージェント化に踏み切るべきかをまとめた記事。AnthropicやCognitionとは別のベンダーが同じ結論（安易な分散を避け境界を先に決める）に至っている点が興味深い。",
      "url": "https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems"
    }
  ]
}