Claude Code Agent Teamsで実現するマルチエージェント協調開発 ─ セットアップから実践ワークフローまで

Claude Codeの/agentsコマンドを叩いたことはあるだろうか。2026年2月、Anthropicは実験的機能「Agent Teams」を公開した。従来のsubagentsが「親に報告して終わり」の一方通行だったのに対し、Agent Teamsはエージェント同士が直接メッセージを送り合い、共有タスクリストで進捗を管理しながら協調開発を行う。いわば、AIペアプログラミングからAIチーム開発への進化だ。

本記事では、有効化の手順から実践的なチーム構成パターン、そしてsubagentsとの使い分け判断フローまでを一気に解説する。

Agent Teamsとは何か ── subagentsとの決定的な違い

subagentsの限界：親経由の一方通行コミュニケーション

Claude Codeには以前からsubagentsという仕組みがある。Taskツールで子エージェントを起動し、結果を受け取るものだ。しかしsubagentsには構造的な制約がある。子エージェント同士は互いの存在すら知らない。すべての情報は親エージェントを経由するしかなく、「上司が部下に個別指示を出し、報告を受ける」一方通行モデルだ。

3つの独立した調査タスクを並列実行するなら問題ない。だが、フロントエンドの実装がバックエンドのAPI仕様に依存し、テストが両者の完了を待つような場面では、親がすべてを仲介するボトルネックが発生する。

Agent Teamsの核心：直接メッセージング＋共有タスクリスト

Agent Teamsはこの制約を根本から取り払う。チームメンバー間で直接メッセージ（1対1）やbroadcast（全員宛）で通信でき、共有タスクリストで全員がリアルタイムに進捗を把握する。比喩で言えば、「チーム全員がSlackチャンネルで会話しながらカンバンボードを共有する」モデルだ。

Agent Teamsの構成要素は4つある。

subagentsとの違いを公式ドキュメントの比較表で整理する。

セットアップ：3分で始めるAgent Teams

有効化の設定

Agent Teamsはデフォルトで無効化されている。有効化はsettings.jsonに環境変数を追加するだけだ。

// ~/.claude/settings.json
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

シェルで直接設定する場合は以下でもよい。

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

表示モードの選択

Agent Teamsには2つの表示モードがある。

in-process（デフォルト）: すべてのteammateがメインターミナル内で動作する。Shift+Downでteammate間を切り替え、直接メッセージを送れる。追加ソフト不要でどのターミナルでも動く。

split-panes: 各teammateが独自のペインを持ち、全員の出力をリアルタイムに並列表示する。tmuxまたはiTerm2が必要。

// split-panesモードを強制する場合
{
  "teammateMode": "tmux"
}

デフォルトの"auto"は、tmuxセッション内で実行中ならsplit-panes、それ以外ならin-processを自動選択する。

tmuxでの起動手順はシンプルだ。

# tmuxをインストール（未導入の場合）
brew install tmux

# tmuxセッション内でClaude Codeを起動
tmux new-session -s agent-teams
claude

iTerm2の場合はit2 CLIをインストールし、iTerm2 → Settings → General → Magic → Enable Python APIを有効にする。正直、tmuxのほうが手軽に始められる。

実践ワークフロー：フロント＋バック＋テストの3エージェント同時開発

チーム構成の設計

ユーザー管理機能の追加を例に、3エージェント構成のワークフローを見ていこう。Agent TeamsではTeam Leadに自然言語で指示するだけでチームが構成される。

ユーザー管理機能を実装するためのAgent Teamを作成してください。

チーム構成：
1. バックエンド担当 - src/api/ 配下にユーザーCRUDのREST APIエンドポイントを実装
2. フロントエンド担当 - src/components/ 配下にReactコンポーネントを実装。
   バックエンドのAPI仕様が確定してからfetchコードを書くこと
3. テスト担当 - バックエンドとフロントエンドの両方が完成後に結合テストを作成

各担当はディレクトリ単位で責務を分離し、同一ファイルへの同時編集を避けてください。

タスク依存関係とblockedByの活用

Agent Teamsの強力な機能の一つが、タスク間の依存関係管理だ。タスクには3つの状態がある: pending（未着手）→ in progress（作業中）→ completed（完了）。

依存先タスクが完了すると、ブロックされていたタスクは自動的にアンブロックされる。上記の例では、以下のような依存関係が形成される。

[バックエンドAPI実装] ─── completed ───→ [フロントエンドfetch実装] が自動アンブロック
         │
         └──── completed ─┐
                          ├──→ [結合テスト作成] が自動アンブロック
[フロントUI実装] ── completed ─┘

Team Leadがタスクを作成する際、依存関係を指定すると、依存先が完了するまでそのタスクはclaimできない。タスクのclaimにはファイルロック機構が使われており、複数のteammateが同時に同じタスクを取ろうとしても競合しない。

エージェント間メッセージの実例

実際のワークフローでは、バックエンド担当がAPI仕様を確定した時点でフロントエンド担当に直接通知するといった連携が発生する。

message（1対1）の例: バックエンド担当がフロントエンド担当に「APIのレスポンス形式を{ users: User[], total: number }に確定しました。ページネーションは?page=1&limit=20のクエリパラメータです」と送信する。

broadcast（全員宛）の例: Team Leadが「認証方式をJWTからセッションベースに変更します。全員、Cookieベースの認証を前提に実装してください」と全体通知する。

ここで重要な注意点がある。broadcastはteammate全員のコンテキストにメッセージが追加されるため、トークン消費がエージェント数分発生する。API仕様の確定通知のように全員が知るべき情報にはbroadcastが適切だが、特定の担当者だけに関係する内容はmessage（1対1）を使うべきだ。

ハマりポイントと対策 ── 人間チーム開発の問題がAIでも再現される

よくある失敗パターン3選

失敗1：メソッド名・データ構造の不整合

複数エージェントが独立して実装すると、フロントがgetUsers()を呼んでいるのにバックエンドはfetchAllUsers()を実装している、といった不整合が起きる。実際に5エージェント体制で開発した事例では、6件の命名不整合が報告されている。

対策として、Team Leadが最初に共通インターフェース（型定義やAPI仕様）を作成し、broadcastで全員に共有する。TypeScriptなら型定義ファイルを先に書いてしまうのが効果的だ。

失敗2：エージェントが多すぎてトークン消費が爆発

Agent Teamsは各teammateが独立したClaude Codeインスタンスを持つため、トークン消費はエージェント数に対して線形にスケールする。5体以上になると、broadcastのたびにコストが膨らむ。

公式ドキュメントでも3〜5体が推奨されている。個人的には、まず3体で始めて必要に応じて増やすアプローチが堅実だと感じている。1体あたり5〜6タスクが生産性の目安だ。

失敗3：依存関係の設計ミスでデッドロック

タスクAがBの完了を待ち、BがAの完了を待つ循環依存を作ると、両方が永遠にブロックされる。タスクの依存関係はDAG（有向非巡回グラフ）でなければならない。設計段階で「A → B → C」のように一方向の流れを意識しよう。

ファイル競合と回避策

Agent Teamsにはファイルロック機構があり、同時claimの競合は防止される。しかし、2つのteammateが同じファイルを編集すると上書きが発生するリスクがある。設計段階でディレクトリ単位の責務分離を徹底することが最も確実な対策だ。

# 良い分離の例
バックエンド担当 → src/api/, src/models/
フロントエンド担当 → src/components/, src/hooks/
テスト担当 → tests/

subagents vs Agent Teams：どちらを使うべきか判断フロー

以下のフローで判断すると迷いにくい。

タスクの性質を確認
│
├─ 単一の複雑なタスク
│  → 通常のClaude Code（チーム不要）
│
├─ 複数の独立した並列タスク
│  │
│  ├─ エージェント間の通信が不要
│  │  → subagents（調査の並列実行、独立したファイルレビュー等）
│  │
│  └─ エージェント間の通信が必要
│     → Agent Teams
│
└─ 依存関係のある複数タスク
   │
   ├─ 作業中に仕様変更・方針転換がありえる
   │  → Agent Teams（直接メッセージングが威力を発揮）
   │
   └─ 仕様が確定しており結果だけ必要
      → subagents + 親エージェントが順序制御

判断基準を3つに整理する。

1. エージェント間の通信が必要か？ 不要ならsubagentsで十分。調査タスクの並列実行、独立したコードレビューなどが該当する
2. タスクに依存関係があるか？ あるならAgent TeamsのblockedByによる自動アンブロックが有効
3. 作業中に仕様変更が起こり得るか？ あるならAgent Teamsの直接メッセージングで、変更を即座に関係者に伝達できる

まとめ：AIチーム開発の時代へ

Agent Teamsは、Claude Codeの使い方を「1人の優秀なアシスタントへの指示出し」から「AIエンジニアチームのマネジメント」に変える実験的機能だ。

まだ荒削りな部分もある。セッション復元で既存teammateが消える制約や、トークン消費の大きさは今後の改善が期待される。しかし、subagentsとの違いを理解し、通信が必要な場面でAgent Teams、独立並列作業ならsubagentsと使い分けることで、今の段階でも開発効率を大きく向上できる。

自律開発システムのデーモンからAgent Teamsを起動し、フロント・バック・テストの3エージェントが協調して機能を実装する。そんなアーキテクチャが現実的になりつつある。AI協調開発が当たり前になる未来に備えて、今のうちに手を動かしておく価値はあるはずだ。

参考リンク

• Orchestrate teams of Claude Code sessions - 公式ドキュメント
• From Tasks to Swarms: Agent Teams in Claude Code
• Claude Code Agent Teams: The Complete Guide 2026