チーム構成パターン

マルチエージェントチームの構成、チームサイズの選択、エージェントタイプの選択、および Claude Code の Agent Teams 機能のディスプレイモード設定に関するベストプラクティス。

このスキルを使用する場合

• タスクのためにスポーンするチームメートの数を決定する
• プリセットチーム構成から選択する
• 各ロールに適切なエージェントタイプ (subagent_type) を選択する
• チームメートのディスプレイモード (tmux, iTerm2, in-process) を設定する
• 標準的でないワークフロー用のカスタムチーム構成を構築する

チームサイジングのヒューリスティック

複雑性	チームサイズ	使用場面
シンプル	1-2	単一次元のレビュー、分離されたバグ、小規模機能
中程度	2-3	マルチファイル変更、2-3 の懸念事項、中規模機能
複雑	3-4	横断的関心事、大規模機能、深いデバッグ
非常に複雑	4-5	フルスタック機能、包括的レビュー、システム上の問題

経験則: すべての必要な次元をカバーする最小のチームから始めます。チームメートを追加すると調整オーバーヘッドが増加します。

プリセットチーム構成

レビューチーム

• サイズ: 3 名のレビュアー
• エージェント: 3x team-reviewer
• デフォルト次元: セキュリティ、パフォーマンス、アーキテクチャ
• 使用する場合: コード変更が多次元的品質評価を必要とする場合

デバッグチーム

• サイズ: 3 名の調査者
• エージェント: 3x team-debugger
• デフォルト仮説: 3 つの競合仮説
• 使用する場合: バグに複数の根本原因の可能性がある場合

フィーチャーチーム

• サイズ: 3 (1 名のリード + 2 名の実装者)
• エージェント: 1x team-lead + 2x team-implementer
• 使用する場合: 機能を並列作業ストリームに分解できる場合

フルスタックチーム

• サイズ: 4 (1 名のリード + 3 名の実装者)
• エージェント: 1x team-lead + 1x フロントエンド team-implementer + 1x バックエンド team-implementer + 1x テスト team-implementer
• 使用する場合: 機能がフロントエンド、バックエンド、テストレイアーにまたがる場合

リサーチチーム

• サイズ: 3 名のリサーチャー
• エージェント: 3x general-purpose
• デフォルト領域: 各メンバーに異なるリサーチ質問、モジュール、またはトピックを割り当て
• 機能: コードベース検索 (Grep、Glob、Read)、Web 検索 (WebSearch、WebFetch)
• 使用する場合: コードベースを理解する、ライブラリをリサーチする、アプローチを比較する、またはコードと Web ソースから並列して情報を収集する必要がある場合

セキュリティチーム

• サイズ: 4 名のレビュアー
• エージェント: 4x team-reviewer
• デフォルト次元: OWASP/脆弱性、認証/アクセス制御、依存関係/サプライチェーン、シークレット/設定
• 使用する場合: 複数の攻撃面をカバーする包括的なセキュリティ監査を行う場合

マイグレーションチーム

• サイズ: 4 (1 名のリード + 2 名の実装者 + 1 名のレビュアー)
• エージェント: 1x team-lead + 2x team-implementer + 1x team-reviewer
• 使用する場合: 大規模コードベースマイグレーション (フレームワークアップグレード、言語ポート、API バージョンバンプ) が並列作業と正確性検証を必要とする場合

エージェントタイプの選択

Agent ツールを使用してチームメートをスポーンする際、チームメートが必要とするツールに基づいて subagent_type を選択します:

エージェントタイプ	利用可能なツール	使用用途
general-purpose	すべてのツール (Read、Write、Edit等)	実装、デバッグ、ファイル変更が必要なすべてのタスク
Explore	読み込み専用ツール (Read、Grep、Glob)	リサーチ、コード探索、分析
Plan	読み込み専用ツール	アーキテクチャプランニング、タスク分解
agent-teams:team-reviewer	すべてのツール	構造化された結果を伴うコードレビュー
agent-teams:team-debugger	すべてのツール	仮説駆動型調査
agent-teams:team-implementer	すべてのツール	ファイル所有権の枠内での機能構築
agent-teams:team-lead	すべてのツール	チーム調整と協調

重要な区別: 読み込み専用エージェント (Explore、Plan) はファイルを変更できません。実装タスクを読み込み専用エージェントに割り当てないでください。

ディスプレイモード設定

~/.claude/settings.json で設定します:

{
  "teammateMode": "tmux"
}

モード	動作	最適な用途
"tmux"	各チームメートが tmux ペイン内	開発ワークフロー、複数エージェントの監視
"iterm2"	各チームメートが iTerm2 タブ内	macOS ユーザーの iTerm2 好みの場合
"in-process"	すべてのチームメートが同一プロセス	シンプルなタスク、CI/CD 環境

カスタムチームのガイドライン

カスタムチームを構築する際:

1. すべてのチームにはコーディネーターが必要 — team-lead を指定するか、ユーザーが直接調整する
2. ロールをエージェントタイプに合わせる — 利用可能な場合、特化したエージェント (reviewer、debugger、implementer) を使用する
3. 重複したロールを避ける — 同じことをしている 2 つのエージェントはリソースを無駄にする
4. 事前に境界を定義する — 各チームメートはファイルまたは責任の明確な所有権が必要
5. 小規模に保つ — 2-4 名のチームメートが最適。5 名以上は重大な調整オーバーヘッドを必要とする

トラブルシューティング

チームメートが Explore としてスポーンされたが、ファイルを書き込む必要がある。 Explore と Plan は読み込み専用エージェントです。subagent_type を general-purpose または適切な専化したエージェントタイプに変更します。実装タスクを読み込み専用エージェントに割り当てないでください。

チームが大きくなりすぎて、調整が進行を遅くしている。 各追加チームメートは通信オーバーヘッドを追加します。ロールを統合します: 1 つのエージェントが 2 つの次元をカバーできますか? 6 つの独立したタスクを行っている 4 人のチームは、通常 2 つのタスクをそれぞれカバーする 3 名のエージェントで対応します。

tmux モードがペインを表示していない。 チームメートをスポーンする前に tmux がインストールされていることと、セッションがすでに実行されていることを確認します。in-process モードは tmux なしで動作し、CI またはスクリプト環境に適しています。

2 人のレビュアーが同じ問題にフラグを立てている。 レビュー次元が重なっています。各レビュアーのフォーカス領域を再定義します: 1 人が正確性/ロジック、1 人がセキュリティ、1 人がパフォーマンス/スケーラビリティを担当。重複したカバレッジはトークンを無駄にし、重複した結果を生成します。

team-lead がチームメートをスポーンしているが、タスクを受け取っていない。 リードが Agent ツールを使用してチームメートをスポーンし、プロンプトで完全なコンテキストを渡していることを確認します。チームメートは事前の会話履歴なしで新規に開始します — 初期プロンプトですべての関連情報が必要です。

関連スキル

• parallel-feature-development — チーム構成後、作業ストリームを分解してファイル所有権を割り当てる
• team-communication-protocols — 組み立てられたチーム向けにメッセージング規範とシャットダウン手順を確立する