原典: Multi-agent coordination patterns: Five approaches and when to use them
一行要約
building-multi-agent-systems が「使うか否か」を決めた後の続編で、5つの協調パターンをそれぞれの壊れ方で切り分ける。選択の軸は毎回「context をどこで切るか」と「情報の流れ方」に還元される。
We’ve seen teams choose patterns based on what sounds sophisticated rather than what fits the problem at hand. We recommend starting with the simplest pattern that could work, watching where it struggles, and evolving from there.
問題に合うかではなく、高度に聞こえるかでパターンを選ぶチームを見てきた。動きうる最も単純なパターンから始め、どこで苦しむかを見て、そこから進化させることを勧める。
要点
5つのパターンと適用条件
| パターン | 向く条件 |
|---|---|
| Generator-verifier | 品質が決定的に重要で、評価基準を明示できる出力 |
| Orchestrator-subagent | タスク分解が明確で、subtask が有界 |
| Agent teams | 並列・独立で長時間走る subtask |
| Message bus | イベント駆動のパイプラインで、エージェントが増えていく |
| Shared state | 協働作業で、互いの発見の上に積み上げる |
1. Generator-verifier — 最も単純で、最も多く壊れる
生成役が出力し、検証役が基準に照らして受理か差し戻しを判定する。差し戻しならフィードバックが生成役へ戻り、受理か上限回数まで繰り返す。
失敗の仕方が具体的に名指しされている。
The verifier is only as good as its criteria. A verifier told only to check whether output is good, with no further criteria, will rubber-stamp the generator’s output. Teams most often fail by implementing the loop without defining what verification means, which creates the illusion of quality control without the substance.
検証役はその基準の質を超えない。「出力が良いか確認せよ」としか言われず他に基準の無い検証役は、生成役の出力に判子を押すだけになる。チームが最もよく失敗するのは、検証が何を意味するかを定義しないままループを実装することで、これは実質を伴わない品質管理の幻想を生む。
他に2つの限界。生成と検証が分離可能な技能だと仮定している点（創造的な案の評価が案出と同じくらい難しいなら検証役は問題を捕まえられない）と、ループが収束しない点（上限回数とフォールバック — 人間へのエスカレーション、留保つきで最良案を返す — が要る）。
2. Orchestrator-subagent — 階層
lead agent が計画・委譲・統合を行い、subagent は結果を返す。Claude Code がこのパターンで、主エージェント自身がコードを書きファイルを編集しつつ、大きなコードベースの探索や独立した問いの調査を背景の subagent に投げる。
The orchestrator becomes an information bottleneck.
orchestrator が情報のボトルネックになる。
セキュリティ担当の subagent が認証の欠陥を見つけ、それがアーキテクチャ担当の分析に影響する場合、orchestrator がその依存を認識して適切に流さなければならない。引き継ぎが数回重なると重要な詳細は失われるか要約で消える。
Sequential execution also limits throughput. Unless explicitly parallelized, subagents run one after another, meaning the system incurs multi-agent token costs without the speed benefit.
逐次実行もスループットを制限する。明示的に並列化しない限り subagent は順番に走るので、システムは速度の利益なしに multi-agent のトークンコストだけを払う。
3. Agent teams — 違いは worker の永続性
The difference from orchestrator-subagent is worker persistence. The orchestrator spawns a subagent for one bounded subtask, and the subagent terminates after returning a result. Teammates stay alive across many assignments, accumulating context and domain specialization that improve their performance over time.
orchestrator-subagent との違いは worker の永続性である。orchestrator は有界な subtask 1つのために subagent を spawn し、subagent は結果を返した後に終了する。teammate は多くの割り当てをまたいで生き続け、context とドメインの専門性を蓄積して、時間とともに性能を上げていく。
壊れ方は3つ。独立性が絶対条件であること（teammate 同士は中間の発見を共有できないので、互いの仕事が影響し合うと衝突する）、完了検知が難しいこと（2分で終わる者と20分かかる者が混在する）、そして共有資源が両方を悪化させること（同じファイルを編集する）。
4. Message bus — 柔軟さの代償は追跡不能
publish / subscribe の2つの原始的操作で繋ぐ。新しい能力を持つエージェントを、既存の結線を変えずに追加できる。
The flexibility of event-driven communication makes tracing harder. When an alert triggers a cascade of events across five agents, understanding what happened requires careful logging and correlation.
イベント駆動通信の柔軟さは追跡を難しくする。1つのアラートが5つのエージェントにまたがるイベントの連鎖を引き起こしたとき、何が起きたかを理解するには入念なログと相関付けが要る。
If the router misclassifies or drops an event, the system fails silently, handling nothing but never crashing.
ルータがイベントを誤分類または取りこぼすと、システムは静かに失敗する。何も処理しないが、決してクラッシュもしない。
5. Shared state — 中間者を消す代わりに終了条件が要る
中央の調停者を置かず、全員が読み書きする永続ストアで協調する。coordinator が単一障害点でなくなる利点がある一方、振る舞いの問題が出る。
The harder failure mode is reactive loops. For example, Agent A writes a finding, Agent B reads it and writes a follow-up, Agent A sees the follow-up and responds. The system keeps burning tokens on work that isn’t converging.
より厄介な失敗モードは反応ループである。たとえばエージェント A が発見を書き、B がそれを読んで追記し、A がその追記を見て応答する。システムは収束しない仕事にトークンを燃やし続ける。
Duplicate work and concurrent writes have known engineering fixes (locking, versioning, partitioning). Reactive loops are a behavioral problem and need first-class termination conditions: a time budget, a convergence threshold (no new findings for N cycles), or a designated agent whose job is to decide when the store contains a sufficient answer.
重複作業と同時書き込みには既知の工学的解決がある（ロック、バージョニング、分割）。反応ループは振る舞いの問題であり、一級の終了条件を必要とする。時間予算、収束閾値（N サイクル新しい発見が無い）、あるいはストアが十分な答えを含んだかを判断する専任のエージェント。
Systems that treat termination as an afterthought tend to cycle indefinitely or stop arbitrarily when one agent’s context fills.
終了条件を後回しにしたシステムは、無限に循環するか、どれか1つのエージェントの context が埋まった時点で恣意的に止まる。
選び分けは「context をどこで切るか」に帰着する
In our previous post, we argued for context-centric decomposition, which divides work by what context each agent needs rather than by what type of work it does. That principle applies here too. The patterns differ in how they manage context boundaries and information flow.
前回の記事では context 中心の分解を主張した。仕事の種類ではなく、各エージェントがどの context を必要とするかで分けるというものだ。その原則はここにも当てはまる。パターンが異なるのは、context の境界と情報の流れをどう管理するかである。
4つの2択として整理されている。
| 比較 | 問い | 分かれ目 |
|---|---|---|
| orchestrator-subagent vs agent teams | worker が context をどれだけ長く保つ必要があるか | subtask が短く有界なら前者。多段の作業で慣れが効くなら後者 |
| orchestrator-subagent vs message bus | ワークフローの構造がどれだけ予測可能か | 手順が事前に既知なら前者。イベントから創発するなら後者 |
| agent teams vs shared state | 互いの発見が必要か | 交わらない区画に分かれるなら前者。発見がリアルタイムに流れるべきなら後者 |
| message bus vs shared state | 仕事が離散イベントとして流れるか、知識として蓄積するか | 段階的に処理するなら前者。蓄積した発見の上に積むなら後者 |
判断の合図も付いている。orchestrator に条件分岐が溜まってきたら message bus へ。teammate が最終結果だけでなく互いに通信し始めたら shared state へ。message bus でエージェントが行動を起こすためでなく発見を共有するために publish しているなら、shared state の方が合っている。
そのまま使える具体例
Generator-verifier を実装するときに必ず決めること:
- 検証の基準を明示する（「良いか確認せよ」は判子を押させるだけ）
- 上限反復回数を決める
- 上限に達したときのフォールバック（人間へエスカレーション / 留保つきで最良案を返す）
Shared state を使うときの終了条件（どれか1つは必須）:
- 時間予算
- 収束閾値（N サイクル新しい発見が無い）
- 「十分な答えが揃ったか」を判断する専任エージェント
原典で言及されている関連文書
- building-multi-agent-systems — 前編。「使うか否か」と context 中心の分解
- agent-teams — Claude Code の agent teams の実装
- sub-agents — orchestrator-subagent の subagent 側
- multi-agent-research-system — orchestrator-subagent の実運用例