ai-docs

Building multi-agent systems: When and how to use them

Properties1
tagsagents, multi-agent, subagents, context, orchestration, tools

原典: Building multi-agent systems: When and how to use them

一行要約

multi-agent は既定ではなく例外であり、単一エージェントでは越えられない制約を示せた3つの状況（context 汚染・並列化・専門化）に限って使う。そして分割は「仕事の種類」ではなく「context の境界」で切る。

要点

定義と範囲

A multi-agent system is an architecture where multiple LLM instances run with separate conversation contexts, coordinated through code.

multi-agent システムとは、複数の LLM インスタンスが別々の会話 context で動き、コードによって協調させられるアーキテクチャである。

扱うのは orchestrator-subagent パターン（lead agent が subagent を spawn して管理する階層モデル）に限定されている。agent swarm、capability-based、message bus といった他の協調パターンは別記事とされる。

まず単一エージェントから始める

Today, multi-agent systems are often applied in situations where a single agent would perform better, though this calculus continues to evolve as models improve. At Anthropic, we’ve seen teams invest months building elaborate multi-agent architectures only to discover that improved prompting on a single agent achieved equivalent results.

今日、multi-agent システムは単一エージェントの方がうまくいく状況にしばしば適用されている。ただしこの計算はモデルの改善とともに変わり続ける。Anthropic では、チームが手の込んだ multi-agent アーキテクチャの構築に何ヶ月も投じた末に、単一エージェントのプロンプトを改善すれば同等の結果が得られたと気づく、という例を見てきた。

コストは具体的な倍率で示される。

In our testing, multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks.

我々のテストでは、同等のタスクに対して multi-agent 実装は単一エージェント手法の通常 3〜10倍のトークンを使う。

内訳は context の複製・エージェント間の協調メッセージ・引き継ぎのための結果要約の3つ。

3つの状況（それ以外は協調コストが上回る）

when context pollution degrades performance, when tasks can run in parallel, and when specialization improves tool selection or task focus. Outside these situations, the coordination costs typically exceed the benefits.

context 汚染が性能を劣化させるとき、タスクが並列に走れるとき、専門化がツール選択やタスクへの集中を改善するとき。これらの状況の外では、協調コストが利益を上回るのが通例である。

(a) context 保護。 subtask が大量の context（1000 トークン超）を生むが、その大半が主タスクには無関係な場合に効く。subtask の定義が明確で、何を抽出すべきかの基準がはっきりしていること、そして参照・検索系の操作であることが条件として挙がる。

(b) 並列化。 ここは目的の取り違えが起きやすい点として名指しされている。

The primary benefit of parallelization is thoroughness, not speed.

並列化の主たる利益は徹底性であって速度ではない。

The tradeoff is higher token usage and often longer total execution time in exchange for more comprehensive results.

トレードオフは、より網羅的な結果と引き換えの、トークン使用量の増加と、しばしば長くなる総実行時間である。

(c) 専門化。 ツールセット・system prompt・ドメイン知識の3方向がある。ツール過多を疑う signal は3つ。

  • Quantity. An agent with too many tools (often 20+) struggles to select the appropriate one.

  • Domain confusion. When tools span multiple unrelated domains (database operations, API calls, file system operations), the agent confuses which domain applies to a given task.

  • Degraded performance. Adding new tools degrades performance on existing tasks, suggesting the agent has reached its capacity for tool management.

  • 量。ツールが多すぎるエージェント（しばしば20個以上）は適切なものを選ぶのに苦労する。

  • ドメイン混同。ツールが無関係な複数ドメイン（DB 操作、API 呼び出し、ファイルシステム操作）にまたがると、エージェントはどのドメインが当該タスクに当てはまるかを混同する。

  • 性能劣化。新しいツールの追加が既存タスクの性能を劣化させるなら、ツール管理の容量に達したことを示唆する。

ただし専門化にはルーティングの複雑さが付く。orchestrator が誤って振り分ければ結果は悪くなり、prompt の保守コストも増える。

multi-agent に移る前に試すこと

context 上限が近いなら compaction、ツールが 15〜20個以上あるなら Tool Search Tool が先に来る。

This can reduce token usage by up to 85% while improving tool selection accuracy.

これはツール選択の精度を改善しつつ、トークン使用量を最大 85% 削減しうる。

These thresholds will shift as models improve. Current limits represent practical guidelines, not fundamental constraints.

これらの閾値はモデルの改善とともに動く。現在の限界は実務上の指針であって、原理的な制約ではない。

最重要の設計判断 — context で切る

The key insight is to adopt a context-centric view rather than a problem-centric view when decomposing work.

鍵となる洞察は、仕事を分解するときに問題中心ではなく context 中心の見方を採ることである。

Dividing by context boundaries means an agent handling a feature should also handle its tests, because it already possesses the necessary context. Work should only be split when context can be truly isolated.

context の境界で分けるとは、ある機能を担当するエージェントがそのテストも担当するということだ。必要な context を既に持っているからである。仕事は context が本当に隔離できるときにだけ分割されるべきである。

逆に「計画担当・実装担当・レビュー担当」のように仕事の種類で切ると壊れる。

When agents are split by problem type, they engage in a “telephone game,” passing information back and forth with each handoff degrading fidelity. In one experiment with agents specialized by software development role (planner, implementer, tester, reviewer), the subagents spent more tokens on coordination than on actual work.

問題の種類でエージェントを分けると、エージェント同士が「伝言ゲーム」を演じ、情報を往復させ、引き継ぎのたびに忠実度が劣化する。ソフトウェア開発の役割（計画者・実装者・テスター・レビュアー）で専門化させたある実験では、subagent は実際の作業よりも協調に多くのトークンを費やした。

有効な分割境界問題のある分割境界
独立した調査経路（「アジアの市場動向」と「欧州の市場動向」）同じ仕事の逐次的な工程（同一機能の計画・実装・テスト）
綺麗なインタフェースで分かれた構成要素（API 契約が定まったフロントとバック）密結合な構成要素（絶えず往復が要るもの）
ブラックボックス検証（テストを走らせて結果を報告するだけの検証役）共有状態を要する仕事（頻繁に理解を同期する必要があるもの）

verification subagent と「早すぎる勝利」

一貫して効くパターンとして verification subagent（検証専任）が挙がる一方、その失敗モードも名指しされる。

The most significant failure mode for verification subagents is marking outputs as passing without thorough testing. The verifier runs one or two tests, observes them pass, and declares success.

verification subagent の最も重大な失敗モードは、徹底的なテストなしに出力を合格とマークすることである。検証役はテストを1つか2つ走らせ、通るのを見て、成功を宣言する。

The instruction “You MUST run the complete test suite before marking as passed” is essential. Without explicit requirements for comprehensive validation, verification agents take shortcuts.

「合格とマークする前に完全なテストスイートを走らせなければならない」という指示が不可欠である。網羅的な検証の明示的な要求が無ければ、検証エージェントは近道をする。

なお orchestrator が有能になるほど検証専任は要らなくなる方向にあり、Opus 4.5 級では subagent の仕事を直接評価できることが増えていると付記されている。

結論

Our advice? Start with the simplest approach that works, and add complexity only when evidence supports it.

我々の助言は？ 動く最も単純な手法から始め、証拠が支持するときにだけ複雑さを足せ。

そのまま使える具体例

検証役への指示は、曖昧な依頼ではなく具体的な基準で書く:

Run the full test suite and report all failures
 
You MUST run the complete test suite before marking as passed

（「make sure it works」ではなく）

移行前のチェックリスト（原典の3項目）:

  1. multi-agent が解く本物の制約があるか（context 上限・並列化の機会・専門化の必要）
  2. 分解が「仕事の種類」ではなく「context」に従っているか
  3. subagent が完全な context 無しに検証できる明確な検証点があるか

原典で言及されている関連文書

バックリンク