Claude Code Agent Teamsによるマルチエージェント協調

#claude-code #agent-teams #multi-agent #ai-agent

Claude Code の Agent Teams は、複数の Claude Code セッションを連携させて並列作業を行う実験的機能だ。2026年2月にリリースされた。

単一のエージェントには限界がある。コンテキストウィンドウの制約、一度に一つの視点でしか考えられないこと、長時間の作業での集中力の分散。Agent Teams はこれらの問題に対して、「複数のエージェントに分担させ、互いに議論させる」というマルチエージェント協調のアプローチを取る。

この記事では、Agent Teams の設計思想と実践的な使い方を解説する。

サブエージェントとの使い分け

Claude Code には既に Task ツールによるサブエージェント機能がある。Agent Teams との違いを整理しておく。

観点	サブエージェント	Agent Teams
コンテキスト	独自のウィンドウ、結果を呼び出し元に返す	独自のウィンドウ、完全に独立
通信	メインエージェントへの報告のみ	チームメイト同士が直接メッセージ
調整	メインエージェントが全て管理	共有タスクリストで自己調整
向いている用途	結果だけ欲しいフォーカスタスク	議論・協調が必要な複雑なタスク
トークンコスト	低い（結果を要約して返す）	高い（各自が独立したインスタンス）

判断基準はシンプルだ：

「この調査の結果を教えて」→ サブエージェント
「複数の視点で検討して、互いに批判し合ってほしい」→ Agent Teams

サブエージェントは「部下に仕事を投げて報告を受ける」モデル。Agent Teams は「チームで議論して結論を出す」モデル。後者はコストが高いが、単一視点では見落としがちな問題を発見できる可能性がある。

アーキテクチャ

Agent Teams は4つのコンポーネントで構成される。

┌─────────────────────────────────────────────────────┐
│                    Team Lead                        │
│  ・チームの作成・管理                                │
│  ・タスクの分割・割り当て                            │
│  ・結果の統合                                        │
└─────────────────────┬───────────────────────────────┘
                      │
        ┌─────────────┼─────────────┐
        │             │             │
        ▼             ▼             ▼
┌───────────┐   ┌───────────┐   ┌───────────┐
│ Teammate A│◄─►│ Teammate B│◄─►│ Teammate C│
│           │   │           │   │           │
│ 独自の     │   │ 独自の     │   │ 独自の     │
│ コンテキスト│   │ コンテキスト│   │ コンテキスト│
└───────────┘   └───────────┘   └───────────┘
        │             │             │
        └─────────────┼─────────────┘
                      ▼
              ┌───────────────┐
              │  Shared Task  │
              │     List      │
              └───────────────┘

Team Lead（リーダー）

チームを作成した最初のセッションがリーダーになる。リーダーは固定で、途中で変更できない。

リーダーの役割：

チームメイトの生成（spawn）
タスクの作成と割り当て
チームメイトへの指示
結果の統合と報告
チームのクリーンアップ

Teammates（チームメイト）

独立した Claude Code インスタンス。それぞれが自分のコンテキストウィンドウを持ち、プロジェクトのコンテキスト（CLAUDE.md、MCP サーバー、Skills）を読み込む。

重要なのは、リーダーの会話履歴は引き継がないということ。spawn 時のプロンプトが唯一の初期コンテキストになるため、必要な情報は明示的に渡す必要がある。

Task List（共有タスクリスト）

全エージェントが参照できるタスクリスト。タスクには3つの状態がある：

pending（未着手）
in_progress（作業中）
completed（完了）

タスク間の依存関係も設定でき、依存先が完了するまでブロックされる。チームメイトは自己判断でタスクを claim（取得）できるため、リーダーが逐一指示しなくても作業が進む。

Mailbox（メールボックス）

エージェント間のメッセージングシステム。サブエージェントと違い、チームメイト同士が直接コミュニケーションできる。これが Agent Teams の最大の特徴だ。

message: 特定のチームメイトに送信
broadcast: 全チームメイトに同時送信（コストが高いので慎重に）

実践：チームの立ち上げと運用

有効化

Agent Teams は実験的機能のため、デフォルトで無効。settings.json で有効化する：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

チームの起動

自然言語でチーム構成を指示する：

PR #142 をレビューするチームを作って。
セキュリティ、パフォーマンス、テストカバレッジの
3つの観点で、それぞれ担当するチームメイトを spawn して。

Claude がタスクを分析し、適切なチーム構成を提案・実行する。明示的にチームメイトの数やモデルを指定することもできる：

4人のチームメイトを作って、各自 Sonnet を使って。

表示モード

2つの表示モードがある：

In-process（デフォルト）

全チームメイトがメインターミナル内で動作
Shift+Up/Down でチームメイトを選択
Enter でセッション表示、Escape で中断
どのターミナルでも動作

Split panes

各チームメイトが独自のペインを持つ
全員の出力を同時に確認可能
tmux または iTerm2 が必要

設定で切り替える：

{
  "teammateMode": "tmux"  // または "in-process"
}

Delegate Mode

リーダーが自分で実装を始めてしまうことがある。Delegate Mode を有効にすると、リーダーは調整専用ツール（spawn、メッセージ、シャットダウン、タスク管理）のみ使用可能になり、コードには触れなくなる。

Shift+Tab で切り替え。

Plan Approval

リスクの高いタスクでは、チームメイトに実装前の計画承認を要求できる：

認証モジュールをリファクタリングするチームメイトを spawn して。
変更を加える前に計画の承認を必須にして。

チームメイトは read-only の plan mode で作業し、計画をリーダーに送信。リーダーが承認するまで実装に入れない。

具体例①：並列コードレビュー

単一のレビュアーは、一度に一つの観点に集中しがちだ。セキュリティを見ているときはパフォーマンスを見落とし、パフォーマンスを見ているときはテストの抜けを見落とす。これはアンカリング効果の一種でもある。

Agent Teams では、観点ごとにチームメイトを割り当てることで、この問題を回避できる。

プロンプト例

PR #142 をレビューするチームを作って。3人のレビュアーを spawn：
- セキュリティ観点（認証、入力検証、インジェクション）
- パフォーマンス観点（N+1、メモリリーク、計算量）
- テストカバレッジ観点（エッジケース、エラーパス）

各自がレビューした後、互いの発見を共有して、
見落としがないか確認し合って。
最後に統合レポートをまとめて。

なぜ有効か

並列性: 3つの観点を同時に調査できる
専門性: 各チームメイトが自分の観点に集中できる
相互検証: 「セキュリティ担当が見つけた問題は、パフォーマンスに影響しないか？」といった横断的な議論が可能

単一エージェントに「3つの観点でレビューして」と頼むと、順番に見ていくため時間がかかり、最初の観点に引きずられやすい。チーム化することで、各観点が対等に扱われる。

具体例②：競合仮説デバッグ

原因不明のバグを調査するとき、単一エージェントは「最初に見つけたもっともらしい説明」で止まりがちだ。これは人間も同じで、アンカリング効果と呼ばれる。

Agent Teams では、競合仮説テストのアプローチを取る。複数の仮説を並列で検証し、互いに反証を試みることで、より確実な原因特定ができる。

プロンプト例

ユーザーから「アプリが1メッセージ送信後に切断される」という報告。
5人のチームメイトを spawn して、異なる仮説を調査させて：

1. WebSocket のタイムアウト設定
2. 認証トークンの有効期限
3. サーバー側のコネクション管理
4. クライアント側のエラーハンドリング
5. ネットワークレイヤーの問題

各自が調査した後、互いの仮説を反証しようとする
科学的な議論をさせて。
生き残った仮説を findings.md にまとめて。

なぜ有効か

アンカリング回避: 最初の仮説に固執しない
反証プロセス: 「この仮説が正しいなら、〇〇も起きているはず。確認した？」という批判的検討
並列検証: 5つの仮説を同時に調査できる

議論構造がポイントだ。単に並列で調査するだけでなく、「互いの仮説を反証しようとする」という指示により、生き残った仮説の信頼性が高まる。

落とし穴と対処

ファイル競合

2人のチームメイトが同じファイルを編集すると、上書きが発生する。

対処: タスク分割の段階で、各チームメイトが担当するファイルを明確に分ける。「フロントエンド担当は src/components/ のみ」のように。

リーダーが先走る

リーダーがチームメイトの完了を待たずに自分で実装を始めることがある。

対処:

Delegate Mode を有効にする
明示的に「チームメイトの作業完了を待ってから次に進んで」と指示する

タスクステータスの遅延

チームメイトがタスクを完了しても、ステータス更新を忘れることがある。依存タスクがブロックされたままになる。

対処: 定期的にタスクリストを確認し、実際の状態と乖離していればリーダーに更新を指示する。

セッション再開の制限

/resume や /rewind で再開しても、in-process のチームメイトは復元されない。リーダーが存在しないチームメイトにメッセージを送ろうとして失敗する。

対処: 再開後は新しいチームメイトを spawn し直す。

コストの急増

各チームメイトが独立したインスタンスを持つため、トークン使用量はチームサイズに比例して増加する。

対処:

本当にチーム化が必要か再考する（結果だけ欲しいならサブエージェントで十分）
チームメイトの数を必要最小限に抑える
broadcast の使用を控える

まとめ

Agent Teams が向いているケース

複数の独立した視点が価値を持つタスク（レビュー、調査）
議論や相互批判が品質を高めるタスク（設計検討、仮説検証）
並列作業が可能で、ファイル競合のリスクが低いタスク

Agent Teams が向いていないケース

順序依存の強いタスク（A の結果を見てから B を決める）
同一ファイルへの編集が必要なタスク
コスト効率が重要な定型作業

実験的機能としての位置づけ

Agent Teams はまだ実験段階にある。セッション再開の制限、タスク調整の不安定さ、シャットダウンの遅さなど、荒削りな部分が残っている。

それでも、「複数のエージェントが議論して結論を出す」というアプローチは、単一エージェントの限界を超える可能性を示している。特に、人間のチームでも有効な「複数視点でのレビュー」「競合仮説の検証」といったパターンは、Agent Teams でも同様に機能する。

コストと複雑さのトレードオフを理解した上で、適切な場面で活用することで、単一エージェントでは難しかったタスクに取り組めるようになるだろう。

抽出された概念

エージェントチームアーキテクチャ - Team Lead・Teammates・Task List・Mailbox による協調構造
マルチエージェント協調 - 複数エージェントが対等に協調するパターン（既存ノートに記載済み）
競合仮説テスト - 複数仮説を並列検証・相互反証するデバッグ手法（既存ノートに記載済み）