AI Agent Architecture

日本語 (Japanese)

English

日本語 (Japanese)

English

Appearance

マルチエージェント / Agent Teams — 単一エージェントを超えるスケール ​

サブエージェントを 1〜2 個並べても解けない問題に直面したとき、エージェントを「チーム」として組織化する。Orchestrator-Worker、Hierarchical Team、Swarm — 3 つの基本パターンと、その実装視点での選び方。

このドキュメントについて ​

サブエージェントの基本は カスタムサブエージェント で扱った。本ページでは 複数のエージェントを協調させる設計 に焦点を当てる。Anthropic Multi-Agent Research System や OpenAI Agents SDK の実装パターンを踏まえ、現実に「いつ Agent Team が必要になるか」を判断するためのガイド。

3 行で答える

  • 単一サブエージェントで処理時間が爆発したり、観点が混じり合うとき に Agent Team を検討する
  • 3 つの基本パターン: Orchestrator-Worker (統括者あり) / Hierarchical Team (役割固定) / Swarm (ハンドオフ協調)
  • コストは並列度・トークン消費の両面で線形以上に増える。導入は「単純化を試した後」が原則

関連: エージェント概念の分類 / カスタムサブエージェント / サブエージェント vs Skills / A2Aとは

なぜ「単一サブエージェント」では足りなくなるか ​

サブエージェントは独立コンテキストで動くが、それでも以下の壁にぶつかる。

これらに対する構造的な答えが 複数エージェントの組織化 = Agent Teams。

IMPORTANT

Agent Teams は「サブエージェントの上位互換」ではない。サブエージェントで足りるならサブエージェントで止める。導入判断のシグナルは後述する。

3 つの基本パターン ​

エージェント概念の分類 (agent-taxonomy) で挙げた設計パターンを、実装視点 で整理する。

パターン 1: Orchestrator-Worker ​

統括役 (Orchestrator / Lead) が複数の Worker サブエージェントにタスクを委任し、結果を集約する階層型。最も標準的 で、Anthropic Multi-Agent Research System もこの構成。

特徴内容
統括の所在中央集権 (Orchestrator が全タスク分解と集約を担う)
Worker 間通信原則なし (Orchestrator 経由)
並列性高 (Orchestrator が同時に複数 Worker を起動)
適するタスク探索的調査、コードベース横断分析、複数ソースからの情報統合
Claude Code での実装Main agent が Agent(subagent_type=...) を複数回呼ぶ

NOTE

Anthropic の報告では、Claude Opus 4 を lead、Claude Sonnet 4 を subagents とする構成が単一 Opus 4 を社内 research eval で 90.2% 上回った 一方、token 消費が性能差の 80% を説明する。性能改善は大きいがコストも比例して大きい。

パターン 2: Hierarchical Team ​

固定された役割 (Role) を持つエージェントが階層的に組織化される。CrewAI や AutoGen が代表例。Orchestrator-Worker よりも 役割の固定度が高い のが違い。

特徴内容
統括の所在Manager が階層トップだが、メンバー間にも一定のやり取り
エージェント間通信あり (Implementer ↔ Critic の往復)
並列性中 (役割固定なので並列度は限定的)
適するタスク反復的な改善ループ、要件→設計→実装→レビューの一連
Claude Code での実装カスタムサブエージェントを役割ごとに用意し、Main が指揮

パターン 3: Swarm ​

階層を最小化し、エージェント同士が ハンドオフ で次の担当者にタスクを渡す自律分散型。OpenAI Swarm (実験的、現在は Agents SDK) が代表例。

特徴内容
統括の所在なし (ハンドオフで動的に主導権が移る)
エージェント間通信ハンドオフ (ペイロード + コンテキストを次のエージェントに渡す)
並列性低〜中 (基本は直列的なフロー)
適するタスクカスタマーサポート、ワークフロー型業務 (申請 → 承認 → 通知)
Claude Code での実装現状の Claude Code サブエージェントには直接マッピングしにくい (A2A 対応待ち)

CAUTION

Swarm はパターン名であり、フレームワーク名 (OpenAI Swarm) とは区別する。Claude Code 環境では、Swarm 的な動作を実現するには A2A の本格対応か、独自のメッセージング基盤が必要になる。

3 パターンの選び方 ​

判断基準推奨パターン
探索的・タスク分解が動的Orchestrator-Worker
反復的な改善ループ (実装 → レビュー)Hierarchical Team
ワークフロー型 (申請 → 承認 → 通知)Swarm (将来) / 当面は Orchestrator で代用
とにかく速くしたい (並列重視)Orchestrator-Worker (並列起動)
コスト重視まず単一サブエージェントを試す

導入判断 — いつ Agent Team にするか ​

IMPORTANT

Agent Team は コストが線形以上に増える。Anthropic の報告で「性能差の 80% を token 消費が説明する」とされる通り、安易な多エージェント化は ROI が悪い。

導入シグナル ✅ ​

  • 単一サブエージェントで 1 セッションが 10 分以上 かかる
  • 5 ファイル以上を 同時並列でレビュー / 分析 したい
  • 「実装者と批判者を分けたい」品質要件がある
  • 役割ごとに 異なるツール権限 を与えたい (例: Implementer に Write、Reviewer に Read のみ)
  • 単一エージェントだと 観点が混じり合い 精度が劣化している

導入を見送るシグナル ❌ ​

  • タスクが 1 つで、並列化する旨味がない
  • コスト制約が厳しい (token 予算が限られる)
  • まだ単一エージェントを十分に磨いていない
  • デバッグ・観測性の準備ができていない (Agent Team は失敗の原因特定が難しい)

サブエージェントとの境界 — どこから "Team" か ​

「サブエージェント 1 個 = Agent Team か?」という素朴な疑問への答え:

段階構成主たる関心事
単一エージェントMain のみプロンプト設計
+ サブエージェントMain + 1〜2 個の Specialistコンテキスト保護、独立性
Agent TeamOrchestrator + 並列 Worker / 役割固定並列度、役割境界、コスト管理
Agent Mesh組織を跨ぐエージェント連携A2A プロトコル、AgentID、信頼境界

本ページは Agent Team の段階を扱う。組織横断 (Agent Mesh) は A2Aとは と エージェント ID を参照。

Claude Code での実装パターン ​

Claude Code 環境で Agent Team を実装するときの具体パターン。

並列 Worker 起動 (Orchestrator-Worker) ​

markdown
<!-- CLAUDE.md または プロジェクト指示 -->

## 複数ファイルレビュー時の指示

3 ファイル以上のレビュー依頼があった場合、以下の手順で並列実行する。

1. ファイルリストを Worker サブエージェントに分配する
2. `Agent(subagent_type="code-reviewer", description=..., prompt=...)` を **同一メッセージで複数並列起動**
3. 全 Worker の結果を統合して、観点ごとに集約したレビューコメントを返す

TIP

並列起動は 同一メッセージ内で複数の Agent(...) ツール呼び出し を実行することで実現される。逐次起動すると Orchestrator-Worker の利点が失われる。

Implementer + Critic ループ (Hierarchical Team) ​

markdown
<!-- CLAUDE.md -->

## コード生成 → レビュー → 修正のループ

1. Main が `Agent(subagent_type="implementer", ...)` で実装
2. Main が `Agent(subagent_type="critic", ...)` で批判的レビュー
3. Critic が「不合格」を返した場合、指摘事項を Implementer に渡して再実装
4. 最大 3 ループまで。それを超えたら Main がエスカレーション

実装パターンの応用例は サブエージェントを品質ゲートとして使う も参照。

サブエージェントの制約 — Team 化で詰むパターン ​

WARNING

Claude Code の現行仕様では、サブエージェントが他のサブエージェントを起動できない。これは Agent Team の組み方に影響する:

  • OK: Main → 複数 Worker (1 階層)
  • NG: Main → Worker → Sub-Worker (2 階層)
  • 回避策: Main が全 Worker を直接起動し、結果を統合する (Orchestrator が全責任を持つ)

長期実行・週跨ぎのタスクで階層が必要な場合は、サブエージェントではなく Agent Teams (別プロセス / Agent SDK / A2A) に移行する。詳細は姉妹サイトの understanding-llm / Part 10: マルチセッション協調 を参照。

アンチパターン ​

❌ 「とりあえず Multi-Agent」 ​

  • 単一エージェントで十分なタスクを Team 化してコスト爆発
  • 対策: 「単一で 3 回試して頭打ち」が確認できてから Team 化を検討

❌ 役割の重複 ​

  • "Reviewer A" と "Reviewer B" が同じ観点でレビューする
  • 結果: コスト 2 倍で精度は変わらない
  • 対策: 役割ごとに 観点を直交させる (Security / Performance / Style 等)

❌ Critic が常に "合格" ​

  • Implementer + Critic ループで Critic が機能していない
  • 対策: Critic 専用の合格基準を 品質ゲートとしての活用 の規範ラダーで明示

❌ 観測性なしで本番投入 ​

  • どの Worker が失敗したか追跡できない
  • 対策: 各サブエージェント呼び出しに correlation ID を付与し、ログを集約する

A2A 時代との接続 ​

組織を跨ぐエージェント協調が本格化すると、Agent Team は Agent Mesh へと拡張される。

組織内では Orchestrator-Worker (本ページ)、組織間では A2A プロトコル (what-is-a2a)、識別と委任は エージェント ID という三段ロケットになる。

関連ドキュメント ​

🔗 さらに深く: なぜ単一エージェントでは届かないか ​

本ページは Agent Team の実装視点 (What/How) を扱った。「なぜ 単一エージェントが Context Rot で頭打ちになり、複数セッション協調が必要になるのか」を LLM の構造から理解したい場合は、姉妹サイトを参照。

出典 ​

前へ: サブエージェントを品質ゲートとして使う

次へ: A2Aとは (Agent-to-Agent Protocol)

Released under the MIT License.

Copyright © 2025-2026 shuji-bonji