「複数のAIエージェントに別々の仕事をさせたい。でも単純にサブエージェントを並べるだけじゃ、お互いの進捗を知れないし、発見した問題を共有できない……」
Claude Code 2026年2月のアップデートで、そのジレンマをそのまま解決する機能が登場した。Agent Teams——複数のClaude Codeインスタンスが、共有タスクリストとメールボックスを介して直接コミュニケーションしながら並列で動く、実験的マルチエージェント機能だ。
本記事では、Agent Teamsの有効化から実際のチーム構成パターン、コスト管理まで、実装コードを交えて解説する。特に「Subagentsとどう違うのか、どっちを使えばいいのか」という疑問に、設計の観点から答えていく。
AIエージェントの基本設計パターンについては、マルチエージェントオーケストレーション完全版で体系的にまとめているので、合わせて参照してほしい。
そもそもAgent Teamsとは何か
Agent Teamsは、複数のClaude Codeインスタンスをチームとして協調させる仕組みだ。1つのセッションが「チームリード」として機能し、タスクを分解して「チームメイト」に振り分ける。
チームメイトは独立したClaude Codeインスタンスで、それぞれ自分のコンテキストウィンドウを持つ。重要なのは、チームメイト同士が直接メッセージを送り合える点だ。単なる「親が子に指示して結果を受け取る」構造ではない。
2026年2月5日、Claude Opus 4.6と同時にResearch Previewとして公開された。現在も実験的機能（experimental）として提供されており、デフォルトでは無効になっている。必要なバージョンはClaude Code v2.1.32以降だ。
アーキテクチャの全体像
| コンポーネント | 役割 |
|---|---|
| Team Lead | メインセッション。チームを作成し、タスクを分解・割り当て・結果を統合する |
| Teammates | 独立したClaude Codeインスタンス。割り当てられたタスクを実行する |
| 共有タスクリスト | 全員が参照・クレームできる作業リスト。依存関係も管理 |
| メールボックス | エージェント間のメッセージング。LeadとTeammateの双方向で動く |
チーム設定と共有リストはローカルに保存される:
- チーム設定:
~/.claude/teams/{team-name}/config.json - タスクリスト:
~/.claude/tasks/{team-name}/
SubagentsとAgent Teams、何が違うのか
正直、最初はこの2つの違いがピンと来なかった。どちらも「並列で複数のエージェントを動かす」に見える。でも、設計思想がまるで異なる。
| Subagents | Agent Teams | |
|---|---|---|
| コンテキスト | 独自ウィンドウ、結果はメインに戻る | 独自ウィンドウ、完全に独立 |
| 通信 | メインエージェントへの一方向報告のみ | チームメイト同士が直接メッセージ可能 |
| 調整方式 | メインエージェントが全作業を管理 | 共有タスクリストで自律調整 |
| 最適ケース | 結果だけが重要な単発タスク | 議論・協力が必要な複雑な作業 |
| トークンコスト | 低い（結果がメインコンテキストに要約） | 高い（各チームメイトが独立インスタンス） |
一言で言えば:
- Subagents = 「結果を持ってくる部下」
- Agent Teams = 「互いに議論できるチーム」
依存関係のないリサーチや単発の変換タスクならSubagents。セキュリティレビューとパフォーマンスレビューと実装を同時進行させて、お互いの発見を共有させたいならAgent Teams、という判断になる。
有効化から最初のチーム起動まで
まず環境の確認から始めよう。
ステップ1: バージョン確認と有効化
# バージョン確認（v2.1.32以降が必要）
claude --version
# 方法A: 環境変数で有効化（セッション限定）
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
# 方法B: settings.jsonに永続設定（推奨）
# 場所: ~/.claude/settings.json
~/.claude/settings.json に以下を追加すれば、毎回の設定が不要になる:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
動作環境: Claude Code v2.1.32+, macOS / Linux
注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
ステップ2: 表示モードの選択
Agent Teamsには2つの表示モードがある:
// ~/.claude/settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
},
"teammateMode": "in-process" // "auto"（デフォルト）| "in-process" | "tmux"
}
in-processモード（推奨スタート）: 全チームメイトがメインターミナル内で動く。Shift+Downでメンバー間を移動。tmux不要なので、どのターミナルでも動作する。
split-paneモード（tmux/iTerm2）: 各チームメイトが独立したペインに表示。全員の出力を同時確認できる。tmuxまたはiTerm2が必要。
# split-paneモードを使う場合のtmuxインストール（macOS）
brew install tmux
# セッション開始
tmux new-session -s agent-team
# その後tmux内でClaudeを起動する
claude
ステップ3: 最初のチームを起動する
チームの起動は自然言語で指示する。Claude側がタスクを分解してチームメイトを生成する:
CLIへの入力例（そのままコピーして使える）:
「Agent Teamを使って、このCLIツールの設計を3つの角度から検討してください。
1人目はUX担当（ユーザー視点で使いやすさを評価）、
1人目はアーキテクチャ担当（技術的な設計を評価）、
1人目は悪魔の代弁者（問題点と代替案を提示）。
それぞれが検討した後、お互いの発見を共有して最終提案をまとめてください。」
チームが起動すると、リードのターミナルに全チームメイトと現在の担当タスクが表示される。Shift+Downでメンバーを切り替えて直接メッセージを送ることもできる。
6つのチーム構成パターン
実際に使ってみて効果が高かったチーム構成をまとめた。それぞれ「なぜこの構成か」の理由と入力プロンプトをセットで紹介する。
パターン1: 多角レビュー型（セキュリティ×パフォーマンス×テスト）
コードレビューで最もよく使う構成。1人が1つの観点に集中することで、見落としが減る。
「PR #142をAgent Teamでレビューしてください。
チーム構成:
- セキュリティレビュアー: 認証、入力バリデーション、シークレット管理に集中
- パフォーマンスレビュアー: N+1クエリ、メモリリーク、レイテンシに集中
- テストカバレッジレビュアー: テストの欠如、エッジケース、モックの妥当性に集中
3人がそれぞれレビューした後、発見内容を共有して優先度付きの改善リストを作ってください。」
なぜ効果的か: 1人のレビュアーは「ある観点を探し始めると、その後もその観点に引っ張られる」傾向がある。独立した3人が異なるフィルターで見ることで、この認知バイアスを避けられる。
パターン2: 競合仮説型（バグ原因の並列調査）
「原因が分からないバグ」に強い構成。それぞれが別の仮説を持ち、互いの理論を否定しようとするよう設計する。
「ユーザーが報告している問題: アプリが1回メッセージを送った後に接続を切断する。
5人のチームメイトを作成して、それぞれ異なる仮説で調査してください。
重要: チームメイトは互いの理論を積極的に反証しようとすること。
科学的な議論のように進め、発見をfindings.mdに随時記録してください。」
これは実際にAnthropicが社内でCコンパイラを書くプロジェクトで使った手法に近い。単一エージェントは1つの仮説を見つけるとそこで止まりやすいが、複数エージェントが互いに反証する構造では、生き残った仮説が真の原因である確率が高まる。
パターン3: 独立モジュール型（並列実装）
依存関係のない複数モジュールを同時実装する場合に最適。重要な前提: 各チームメイトに異なるファイルセットを割り当てること。同じファイルを複数のチームメイトが編集すると競合が発生する。
「新機能の実装をAgent Teamで並列化してください。
- メンバー1: src/auth/ 認証モジュール（ファイル変更はこのディレクトリのみ）
- メンバー2: src/api/ APIエンドポイント（ファイル変更はこのディレクトリのみ）
- メンバー3: src/ui/ フロントエンドコンポーネント（ファイル変更はこのディレクトリのみ）
- メンバー4: tests/ テスト（メンバー1-3の実装完了後にクレーム可能なタスクとして設定）
メンバー4のタスクは、メンバー1-3のタスクに依存関係を設定してください。」
パターン4: 段階的承認型（計画→レビュー→実装）
リスクの高い変更に使う構成。チームメイトが計画フェーズで止まり、リードが承認してから実装に移る。
「認証モジュールのリファクタリングをAgent Teamで進めてください。
アーキテクトのチームメイトを1人作成し、以下の条件を設定してください:
- まず変更計画だけを作成して、実装には進まないこと
- 計画には: 変更対象ファイル、リスク評価、ロールバック手順を含めること
- 計画をリードに送信して承認を待つこと
- 承認基準: テストカバレッジの変更を含まない計画は却下」
パターン5: 調査統合型（マルチソースリサーチ）
複数のライブラリや技術を同時に調査して比較する場合に有効。
「新しいジョブキューライブラリの選定をAgent Teamで調査してください。
- 調査員A: BullMQ（Redis based, Node.js）の実装例とベンチマーク
- 調査員B: pg-boss（PostgreSQL based）の実装例とベンチマーク
- 調査員C: Inngest（クラウドネイティブ）の実装例とベンチマーク
各自が調査後、以下の軸で比較レポートを作成してください:
- セットアップの複雑さ（1-5点）
- スケーラビリティ
- エラーハンドリングの容易さ
- 月次コスト試算（100万ジョブ/月の場合）」
パターン6: フロントエンド×バックエンド×インフラ横断型
スタック全体に影響する変更（例: 認証方式の変更）に有効。それぞれのレイヤーの専門家が独立して影響を評価する。
「JWTからセッション認証への移行をAgent Teamで設計してください。
- フロントエンド担当: Reactクライアント側の変更箇所を洗い出す
- バックエンド担当: Expressサーバー側の変更箇所を洗い出す
- インフラ担当: Redis/DBスキーマの変更と移行手順を設計する
3人が調査後、breaking changeが発生する箇所をリードに報告してください。」
【要注意】よくある失敗パターンと回避策
失敗1: 同じファイルを複数のチームメイトが編集する
❌ 「3人のチームメイト全員でsrc/utils.tsを改善してください」
⭕ 「チームメイト1はutils.ts、チームメイト2はhelpers.ts、チームメイト3はtypes.tsを担当してください」
なぜ重要か: ファイルの競合が発生し、後から書いた方が前の変更を上書きする。タスク分解の段階で、各チームメイトに「異なるファイルセット」を割り当てるのが鉄則。
失敗2: チームメイトが前の会話履歴を引き継がないことを忘れる
❌ 「さっきの会話のコンテキストを踏まえて実装してください」（チームメイトには届かない）
⭕ スポーンプロンプトに必要なコンテキストを全て含める
「セキュリティレビューのチームメイトを作成してください。
スポーンプロンプト: 'src/auth/モジュールのセキュリティレビューをしてください。
このアプリはJWTをhttpOnlyクッキーに保存しています。
Node.js 22、Express 5を使っています。
認証フロー、トークン管理、入力バリデーションの3点に集中して、
各問題にCRITICAL/HIGH/MEDIUMの重大度を付けて報告してください。'」
失敗3: チームサイズを大きくしすぎる
❌ 10人のチームメイトを作成して小さなタスクを並行処理
⭕ 3〜5人を基本とし、タスク1人あたり5〜6件の粒度で設計する
なぜ重要か: チームメイトが増えると通信オーバーヘッドも増加する。実用的には「3人×6タスク」より「5人×2タスク」の方が効率が悪い場合もある。Subagentsで十分なレベルのタスクにAgent Teamsを使わない。
失敗4: リードが自分でタスクをやり始める
チームリードが委任せず自分でタスクを実装し始めることがある。気づいたら:
「チームメイトが自分のタスクを完了するまで待ってください。
あなたは調整とレビューに集中してください。」
失敗5: セッションの途中切れでやり直しになる
❌ in-processモードで長時間の作業中に/resumeを使う
⭕ split-paneモードを使うか、作業を短い単位に分割する
既知の制限: in-processモードでは/resumeと/rewindがチームメイトを復元しない。セッションが切れると全チームメイトを再スポーンする必要がある（2026年3月時点の制限）。
コスト管理と適正なモデル選択
Agent Teamsを使う上で最大の懸念はコストだ。正直に書く: 予想より大幅に消費することがある。
トークンコストの実態
| 構成 | 目安のコスト倍率 | 理由 |
|---|---|---|
| 単一セッション | 1x（基準） | 1つのコンテキストウィンドウ |
| Subagents × 3 | 1.5〜2x | 結果がメインコンテキストに要約されて戻る |
| Agent Teams × 3人 | 3〜7x | 各チームメイトが独立インスタンス、Opus 4.6が自動割り当て |
チームメイトにはOpus 4.6が自動で割り当てられる。これが高コストの主因だ。モデルを明示的に指定することで削減できる:
「4人のチームメイトでリファクタリングを並列化してください。
各チームメイトにはSonnetを使ってください。」
コスト削減の実践的アプローチ
コスト効率の判断フロー:
1. タスク間に相互依存・議論が必要か？
→ No: Subagentsを使う（コスト低）
→ Yes: 次のステップへ
2. 各タスクが独立したファイルセットを持つか？
→ No: 単一セッション+サブエージェントの組み合わせを検討
→ Yes: Agent Teamsを使う
3. チームサイズは3〜5人に抑えられるか？
→ No: タスクを再設計して絞り込む
→ Yes: 開始
settings.jsonでのコスト設定例
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
},
"teammateMode": "in-process",
"env": {
"MAX_THINKING_TOKENS": "5000"
}
}
注意: ProプランはレートリミットにAgent Teams使用中に頻繁に当たる。本格運用にはMaxプラン（$200/月）が現実的だという声が多い。
Hooksを使った品質ゲートの実装
Agent Teamsには、タスク完了時やチームメイトがアイドルになった際に自動実行されるHooksが用意されている。これを使って品質ゲートを設定できる。
// ~/.claude/settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
},
"hooks": {
"TaskCompleted": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "bash -c 'cd $TASK_WORKDIR && npm run test 2>&1 | tail -20'"
}
]
}
],
"TeammateIdle": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "echo 'Teammate completed. Checking output quality...'"
}
]
}
]
}
}
Hookのexit codeが2の場合、タスク完了をブロックしてフィードバックをチームメイトに送れる。例えばテストが失敗した場合にタスクを「完了」にさせない、といった使い方ができる。
利用可能なHook:
TeammateIdle: チームメイトがアイドル状態になった時。exit 2でフィードバックを送り続行させるTaskCreated: タスクが作成される時。exit 2で作成をブロックしてフィードバックTaskCompleted: タスクが完了とマークされる時。exit 2で完了をブロックしてフィードバック
現在の制限事項（2026年3月時点）
実験的機能なので、正直に制限を書いておく。これらを踏まえて使い方を設計することが重要だ。
- セッション再開不可（in-processモード）:
/resumeと/rewindがin-processチームメイトを復元しない。切れたら再スポーン必要 - タスクステータスのラグ: チームメイトがタスクを完了とマークしないことがある。手動で更新かリードに指示する
- シャットダウンが遅い: チームメイトは現在のリクエストやツール呼び出しを完了してからシャットダウンする。時間がかかる
- 1セッション1チームのみ: リードは同時に1チームしか管理できない
- ネスト不可: チームメイトが自分のサブチームを作ることはできない。チームを作れるのはリードだけ
- split-paneの制限: VS Code統合ターミナル、Windows Terminal、Ghosttyでは動作しない。tmuxまたはiTerm2が必要
参考・出典
- Orchestrate teams of Claude Code sessions — Anthropic公式ドキュメント（参照日: 2026-03-27）
- Claude Code Agent Teamsの始め方。Subagentsとの違いと注意点 — Zenn（参照日: 2026-03-27）
- Claude Code Agent Teamsの細かい運用上の注意点 — Classmethod DevelopersIO（参照日: 2026-03-27）
- Building a C compiler with a team of parallel Claudes — Anthropic Engineering Blog（参照日: 2026-03-27）
まとめ：今日から始める3つのアクション
- 今日やること:
settings.jsonにCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を追加して、パターン1（多角レビュー型）を既存のPRで試してみる - 今週中: コストを測定しながら、Subagentsで十分なタスクとAgent Teamsが必要なタスクを自分のプロジェクトで仕分けする
- 今月中: CLAUDE.mdを整備して、チームメイト全員に共有すべきプロジェクト規約を記載する（これだけでトークン消費が大幅に改善する）
あわせて読みたい:
- マルチエージェントオーケストレーション完全版｜8パターン×4SDK実装ガイド — LangGraph・CrewAI・OpenAI Agents SDKでの実装比較
- GPT-5.4 mini/nano比較｜サブエージェント最適モデル選定 — Subagentsに使うモデルをコストと性能で選ぶ方法
- Anthropic Mythosリーク完全解説｜Capybaraは何を変えるのか
この記事はAIgent Lab編集部がお届けしました。AIエージェント導入の相談は株式会社Uravationまで。
