Claude Code エージェントチーム

問題: API、データベースマイグレーション、テストカバレッジ、ドキュメントにまたがる大規模なリファクタリングがある。1つの Claude Code セッションは作業を直列にこなしていく。サブエージェントは並列化できるが、メインエージェントとしか通信できない。互いにメモを共有したり、意見を出し合ったり、直接連携することはできない。AIワーカーが実際に協調する必要が生じた瞬間、サブエージェントは限界を迎える。

すぐに試せる方法: Agent Teams を有効化して、1つのプロンプトでチーム構成を記述するだけ。

# 環境変数または settings.json に追加
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

そして Claude にこう伝える。

Create an agent team to refactor the payment module. Spawn three teammates:
one for the API layer, one for the database migrations, one for test coverage.
Have them coordinate through the shared task list.

チームリードが起動し、3人のチームメンバーがそれぞれの担当範囲に入り、共有タスクリストとメールボックスを通じて連携する。それぞれが自分のレーンを担当し、衝突も沈黙もない。

用語の注意: ここで扱う機能は Anthropic が提供する Claude Code 組み込みの Agent Teams (実験的機能) だ。Task ツールを使った独自のビルダー・バリデーター構成を作りたい場合は、ビルダー・バリデーターチェーンによるチームオーケストレーションを参照。どちらもマルチエージェント作業の実現手段だが、内部動作はまったく異なる。

この違いこそがこのページの核心だ。メインエージェントがスペシャリストを調整して答えを集めるだけでよければ、エージェントの基礎とエージェントパターンから始めよう。チームメンバー同士が話し合い、意見を出し合い、親スレッドを経由せずに直接連携する必要がある場合に、このページを読んでほしい。

Agent Teams とは何か

Agent Teams は、複数の Claude Code セッションを同じプロジェクト上で同時に動かす実験的モードだ。1つのセッションがリードになる。リードはタスクを割り当て、作業の方向を整え、結果をまとめる。他のチームメンバーはそれぞれ独自のコンテキストウィンドウで動作し、他のチームメンバーに直接メッセージを送ることができる。

サブエージェントとの違いは通信経路にある。サブエージェントは1つの親セッションの中に存在し、その親に答えを返すことしかできない。途中で発見したことは閉じ込められてしまう。2つのサブエージェント間の連携は常にメインエージェントを経由する。Agent Teams はそのホップを排除する。チームメンバーは直接メッセージを送り合い、共有リストからタスクを取り、リアルタイムで問題を議論できる。リードに許可を求めることなく、どのチームメンバーのセッションにも直接参加できる。

わかりやすいイメージとして、サブエージェントは別々の仕事をテキストで依頼するフリーランサーだ。Agent Teams は同じ部屋にいるチームで、それぞれが自分のパーツを担当しながら話し合いで同期を取る。タスクキューと実際のチームの違いだ。

なぜ今これが重要なのか

Anthropic は Opus 4.6 のリリースと同時に Agent Teams を実験的機能として公開した。これはエージェント作業にとって大きな前進だ。独立した開発者たちは OpenClaw のようなプロジェクトや手作りのオーケストレーションスクリプトを使って、数カ月間同様の仕組みを構築していた。Claude Code にそのパターンが組み込まれた。

これが重要な理由は3つある。

1. 組み込みはボルトオンより優れる。 共有タスクリスト、メールボックス、チームメンバーのライフサイクルは Claude Code 自体の一部だ。外部依存なし。壊れやすい仕組みなし。

2. マルチエージェントは成熟しつつある。 今エージェントチームの経験を積んでいる開発者は、ツールが進化するにつれて大きなアドバンテージを得るだろう。「Claude Code を使う」と「Claude Code チームを動かす」の差は今後急速に広がる。

3. 複雑なプロジェクトには単純な分岐ではなく対話が必要だ。 タスクを分割すれば並列作業ができる。Agent Teams は並列作業に加えてライブでの連携も可能で、チームメンバーがコンテキストを共有し、判断を議論し、より良い答えに一緒にたどり着ける。

Agent Teams を使うべき場面

チームを動かすと実際のトークンコストがかかり、単一セッションに比べて調整のオーバーヘッドが生じる。各チームメンバーが明確な担当範囲を持ちながら、グループチャットから恩恵を受ける場合に最も効果が高い。

効果的なユースケース

• リサーチとレビュー: 各チームメンバーが問題の異なる角度を調査し、見解を比較して互いの発見に疑問を投げかける
• 新規モジュールや機能: 各チームメンバーがファイルの重複なく1つのコンポーネントを担当
• 競合仮説でのデバッグ: 各チームメンバーが並列に異なる理論を検証し、他の仮説を積極的に反証しようとする
• レイヤー横断的な連携: フロントエンド、バックエンド、テストにまたがる変更で、各レイヤーに1名のチームメンバーを配置
• 議論とコンセンサス: 複数のチームメンバーがアーキテクチャ上の判断について対立する立場を議論し、最も優れた案に収束する
• 大規模な調査や分類: チームメンバーが大きなデータセットを分割して、それぞれの担当部分を独立して処理する

プロンプトテンプレートやマーケティング、リサーチ、非開発業務を含む10以上のシナリオは、Agent Teams ユースケースとプロンプトテンプレートを参照。

チームがコストに見合う場面

Agent Teams は単に「エージェントを増やす」ものではない。調整レイヤーであり、そのレイヤーが価値を持つのはコラボレーション自体が結果を変える場合だけだ。

チームが通常コストに見合う場合:

• 各チームメンバーが明確なレーンを担当できる
• 1つのレーンでの発見が別のチームメンバーの行動を変える
• 視点を比較することが仕事の一部
• 1つのメインスレッドだけで進めると作業が著しく遅くなるか質が落ちる

チームが通常コストに見合わない場合:

• 1人のエージェントできれいに終わらせられる
• 作業がほぼ直列
• 全員が同じファイルを編集する
• 複数の独立した出力とまとめが必要なだけ

最後のケースはサブエージェントが勝る。ワーカーが話し合う必要がなければ、話し合いのために設計されたシステムにコストを払う必要はない。

スキップすべき場面

直列の作業、同じファイルへの編集、タイトな依存関係がある場合は、単一セッションかサブエージェントパターンの方がコストが低く、すっきり動く。ワーカーが話し合う必要がなければ、調整レイヤーは純粋なコスト増だ。完全に独立した並列編集には /batch の方がシンプルで、ワークツリーの分離も自動で行ってくれる。非同期ワークフローは調整レイヤーなしで基本的な並列実行をカバーする。よくある落とし穴と回避策は、エージェントチームのベストプラクティスを参照。

サブエージェント vs Agent Teams: 適切なツールの選択

どちらも作業を並列化する。動作する層が異なる。決め手となる問いは、ワーカーが実際に互いと話し合う必要があるかどうかだ。

サブエージェントは、素早く、狭い範囲で作業して結果を返す必要がある場合に適している。チームは、ワーカーがコンテキストを共有し、互いに意見を出し合い、自分たちで調整を行う必要がある場合に適している。大規模プロジェクトでは両方を組み合わせる。まずプランで役割と境界を設定し、次に実行でチームを動かす。

サブエージェントが最初にどうルーティングされるかについては、サブエージェントのベストプラクティスを参照。

ステップバイステップ: 初めてのチーム

実際の使用では、チームメンバーが20〜30秒で起動し、最初の1分以内に結果を出し始める。3人チームの実行は、同じ作業を1つのセッションで直列処理した場合の約3〜4倍のトークンを使う。複雑なタスクでは時間の節約がそのコストを十分に補う。

ステップ1: 有効化する

シェルで環境変数を設定する。

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

または settings.json に記述してセッションをまたいで有効にする。

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

ステップ2: 作業とチームを記述する

平易な言葉で。誰が何をするか具体的に。

Create an agent team to review our authentication system. Spawn three teammates:
- Security reviewer: audit for vulnerabilities, check token handling
- Performance analyst: profile response times, identify bottlenecks
- Test coverage checker: verify edge cases, find untested paths
Have them share findings and coordinate through the task list.

チームブリーフに何を書くか

最初のチームプロンプトは多くの人が思う以上に重要だ。曖昧なブリーフは曖昧な連携を生む。

優れたチームブリーフには以下が含まれる。

• 全体的な目標
• チームメンバーの役割
• ファイルまたはシステムの境界
• チームメンバーが連携すべき点
• 完了の定義

例:

Create an agent team to ship the billing refactor.

Team:
- API teammate: own route handlers and webhook flow
- Data teammate: own schema, migrations, and backfills
- Test teammate: own integration coverage and failure cases

Coordination points:
- align on the event model before code changes
- flag any contract mismatch immediately
- do not edit the same file without discussing it first

Done means:
- migrations apply cleanly
- webhook flow still passes
- billing test suite is green

このプロンプトはチームに役割、境界、連携ポイント、完了ラインを与えている。それがなければ「連携する」はたいてい「たくさん話す」だけを意味する。

ステップ3: チームの形成を確認し、必要に応じて軌道修正する

Claude はあなたのセッションをリードに変え、チームメンバーを起動し、共有リストにタスクを積む。あなたのリクエストに合うと判断した場合、Claude がチームを提案することもある。いずれにせよ、ハンドルはあなたの手にある。

キーボードショートカットで確認と操作ができる。Shift+上/下でチームメンバーを選択、Ctrl+Tでタスクリスト、Enterでセッションに入る、Escapeで中断。

ステップ4: 後片付け

作業が完了したら、チームを解散する。

Ask all teammates to shut down, then clean up the team.

必ずリードを通じて後片付けを行う。チームメンバーが1人でも生きている間はリードが後片付けをしないため、チームメンバーを先に終了させる必要がある。

表示モード、デリゲートモード、プラン承認、フック、タスク割り当て、トークンコストの詳細は、Agent Teams Advanced Controls を参照。

アーキテクチャ: 各パーツの構成

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

チームとその設定はローカルのディスクに保存される。

• チーム設定: ~/.claude/teams/{team-name}/config.json
• タスクリスト: ~/.claude/tasks/{team-name}/

すべてのチームメンバーが独自のコンテキストウィンドウを持つ。起動時に、チームメンバーは通常の Claude Code セッションと同様のプロジェクトコンテキストを読み込む: CLAUDE.md、MCPサーバー、スキル。リードからのスポーンプロンプトも読む。リードの会話履歴は継承しない。

通信は、自動メッセージ配信、アイドル通知、共有タスクリスト、ダイレクトメッセージ (特定のチームメンバーのみ)、ブロードキャスト (全員に一斉送信、チームサイズに比例してコストが上がるため慎重に使う) で行われる。

チームメンバーはスポーン時にリードの権限設定を引き継ぐ。特定のチームメンバーのモードはスポーン後に変更できるが、スポーン時には変更できない。

チームセットアップでの CLAUDE.md の活用、チームの行動の調整、トークンコストの管理については、Agent Teams Advanced Controls を参照。

さらに深く学ぶ

これはハブページだ。3つのコンパニオンガイドが各パーツについてさらに詳しく説明している。

• Advanced Controls: 表示モード、デリゲートモード、プラン承認、品質ゲートフック、タスク割り当て、トークンコスト管理、チーム向け CLAUDE.md の最適化
• Use Cases and Prompt Templates: コードレビュー、デバッグ、フルスタック機能、アーキテクチャ決定、マーケティングキャンペーンのコピペ可能なプロンプトと、段階的な入門パスを含む10以上の実世界シナリオ
• Best Practices and Troubleshooting: 実証済みのプラクティス、プランモードの動作、トラブルシューティングガイド、現在の制限事項、v2.1.33 から v2.1.45 の最新修正
• End-to-End Workflow: ブレインダンプからプロダクションまでの完全な7ステップパイプライン: プランニング、コントラクトチェーン、ウェーブ実行、ビルド後検証

チームが動いている間インタラクティブな作業をさらにキビキビさせたい場合は、Opus 4.6 のレスポンスを2.5倍高速化するFast Modeを確認しよう。

スケールでの調整

チームが大きくなるにつれ、難しい問いは「これを並列化できるか?」から「オーケストレーションを実際にどう管理するか?」に変わる。スケールで効果的なパターンが3つある。

1. 再利用可能なスポーンプロンプトテンプレート。 よく使うラインナップ (レビューチーム、ビルドチーム、リサーチチーム) のプロンプト形式を少数ストックしておく。それぞれが役割、ファイル境界、完了基準を定義するため、セッションのたびに作り直す必要がない。それらのテンプレートが組み込まれるワークフローについては、エンドツーエンドワークフローガイドを参照。

2. 権限プリセット。 チームをスポーンする前に、最もよく使う操作を権限設定で事前承認しておく。そうしないと、起動したばかりのチームが最初の10分間、承認プロンプトに溺れることになる。

3. 共有ランタイムコンテキストとしての CLAUDE.md。 モジュール境界、検証コマンド、運用コンテキストがしっかり書かれた CLAUDE.md は、チームメンバー1人あたりの探索コストを大幅に削減する。3人のチームメンバーが1つの明確な CLAUDE.md を読む方が、3人が独立してコードベースを探索するよりはるかに安上がりだ。

マルチエージェントスペクトラム

Agent Teams は、Claude Code 内のマルチエージェントパターンの一端に位置する。それぞれの位置を知ることで適切な選択ができる。

必要に応じて組み合わせよう。協調的な探索フェーズにはチームを使い、実装に移って厳格な品質ゲートが必要になったらビルダー・バリデーターペアに切り替える。長時間動くチームセッションは、あらゆるマルチエージェントワークフローと同様に、コンテキスト戦略によって生き死にが決まる。

エージェントチームの経験を今積んでいくことは、マルチエージェントツールの進化に伴って複利で効いてくる。今週レビュータスクから始めてみよう。コストは小さく、チームメンバーが実際に連携する様子を見れば、複雑な作業への考え方が変わるだろう。