Agent Teams（エージェントチーム）

Agent Teams は、複数の Claude Code を同時に動かしてチームのように協力させる仕組みです。各メンバーが並列で動き、お互いにメッセージを送り合いながら協調作業できます。

Agent Teams とは

身近な例えで理解する

なぜ Agent Teams が必要なのか

1. 並列で作業が進む

1人が順番にやると時間がかかる作業も、3〜5人で分担すれば大幅に短縮できます。特に「調査」「実装」「レビュー」のように独立性の高い作業に効果的です。

2. 専門性を分けられる

「セキュリティ担当」「パフォーマンス担当」「テスト担当」のように、それぞれ異なる観点に集中させることで、1人で全部見るより品質が上がります。

3. チームメイト同士が議論できる

サブエージェントはメインエージェントに結果を返すだけですが、Agent Teams のメンバーはお互いにメッセージを送り合い、発見を共有したり、お互いの仮説に反証を試みたりできます。

サブエージェントとの違い

	サブエージェント	Agent Teams
コミュニケーション	メインに結果を返すだけ	メンバー同士が直接やり取り
コーディネーション	メインが全管理	共有タスクリストで自己調整
コスト	低い	高い（各メンバーが独立インスタンス）
向いている場面	結果だけ欲しい単純なタスク	議論・協調が必要な複雑なタスク

有効化

settings.json に以下を追加します（スターターキットの .claude/settings.json には設定済み）。

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

チーム設計の方法

効果的なチームを設計するには、タスクの性質に応じてメンバーの役割を決めます。

設計のポイント

• 独立した作業単位に分割する - 各メンバーが他のメンバーの完了を待たずに作業開始できるようにする
• 明確な責任範囲を定義する - 同一ファイルの並行編集を避けるため、担当領域を明確に分ける
• 3〜5名が最適 - 多すぎるとコーディネーションコストが増加する
• 1人あたり5〜6タスク - 多すぎず少なすぎない粒度にする

活用シーン

シーン	チーム構成例
PR レビュー	セキュリティ担当 + パフォーマンス担当 + テスト担当
バグ調査	仮説A調査 + 仮説B調査 + 仮説C調査（互いに反証）
新機能実装	フロントエンド担当 + バックエンド担当 + テスト担当
リサーチ	UX調査 + 技術調査 + 競合調査

並列実行のメリット

チームの起動方法

自然言語で Claude に指示するだけでチームを起動できます。

PR レビューの例

エージェントチームを作成して PR #42 をレビューしてください。
3つのレビュアーを起動:
- セキュリティに焦点を当てたレビュアー
- パフォーマンスをチェックするレビュアー
- テストを検証するレビュアー

機能実装の例

エージェントチームを作成して Issue #100 を実装してください。
4名のチーム:
- 解析担当: Issue の要件を分析してタスクを分解
- バックエンド担当: API エンドポイントの実装
- フロントエンド担当: UI コンポーネントの実装
- レビュー担当: 実装完了後にコードレビュー

バグ調査の例

エージェントチームを作成してバグを調査してください。
5つの仮説を並列で検証し、互いの理論に反証を試みるよう指示。

dev-issue-team コマンドとの連携

スターターキットには /dev-issue-team カスタムコマンドが用意されており、GitHub Issue の実装を Agent Teams で並列実行できます。

# Issue #42 を Agent Teams で実装
/dev-issue-team #42

このコマンドは以下を自動的に行います：

• Issue の内容を分析
• 適切なチーム構成を決定
• 各メンバーにタスクを割り当て
• 並列で実装を進行
• 結果を統合して PR を作成

チーム設定サンプル

Hooks を使って品質ゲートを設定し、チームの品質を担保できます。

{
  "hooks": {
    "TeammateIdle": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "全ての割り当てタスクは完了しましたか？未完了の場合、残りのタスクを確認して作業を続けてください。"
          }
        ]
      }
    ],
    "TaskCompleted": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "このタスクの成果物は品質基準を満たしていますか？テストは通っていますか？"
          }
        ]
      }
    ]
  }
}

表示モード

モード	操作方法	要件
in-process	Shift+Down でメンバー切り替え	なし
tmux	各メンバーが独自のペインで表示	tmux / iTerm2

表示モードは settings.json で設定できます。

{
  "teammateMode": "in-process"
}

具体的なチーム構成例

構成例1: PR レビューチーム

メンバー	役割	チェック観点
セキュリティレビュアー	セキュリティ脆弱性の検出	SQL インジェクション、XSS、認証・認可、機密情報露出
パフォーマンスレビュアー	パフォーマンス問題の検出	N+1 クエリ、メモリリーク、不要な再レンダリング
テストレビュアー	テストカバレッジの検証	テスト漏れ、エッジケース、モックの適切さ

構成例2: フルスタック実装チーム

メンバー	役割	担当領域
解析担当	要件分析とタスク分解	Issue 分析、設計ドキュメント
バックエンド担当	API 実装	エンドポイント、DB スキーマ、ビジネスロジック
フロントエンド担当	UI 実装	コンポーネント、スタイリング、状態管理
レビュー担当	品質検証	コードレビュー、テスト作成