エージェントチーム入門
サブエージェント(子分)の次は、複数の Claude が「チーム」を組んで協調するしくみ。リーダー1人+メンバー数人が、共有のタスク板を見ながら作業を分担し、お互いに直接相談しながら進めます。強力ですが実験的機能でコストも大きいので、向き・不向きを知って使うのが大事です。
1エージェントチームとは
ひとことで言うと、「リーダー+メンバー」で働く複数AIのチーム。各メンバーはそれぞれ独立した Claude(=別々の記憶・別々のコンテキスト)で、共有のタスク板で仕事を取り合い、必要ならメンバー同士が直接メッセージを送り合います。
flowchart TD L["リーダー(あなたのセッション)
計画・まとめ役"] --> T["共有タスク板
やること一覧"] T --> A["メンバーA
独立したClaude"] T --> B["メンバーB
独立したClaude"] T --> C["メンバーC
独立したClaude"] A <-->|"直接相談"| B B <-->|"直接相談"| C A --> T B --> T C --> T T --> L
2サブエージェント/チーム/ワークフローの違い
「複数で動かす」しくみは3つあり、性格がまるで違います。混同しやすいのでここで整理します。
| しくみ | 動き方 | 連絡 | 向く仕事 | コスト |
|---|---|---|---|---|
| サブエージェント | 子分が働いて結果だけ親に返す | 親にだけ報告(子分同士は話さない) | 調査・レビューの分担 | 低〜中(要点に圧縮) |
| エージェントチーム | メンバーが対等に協調 | メンバー同士が直接相談・議論 | 議論しながらの並列作業 | 高(約7倍) |
| ワークフロー | スクリプトが大量の作業を確定的に統率 | スクリプトが制御(会話しない) | 大量・反復(/deep-research等) | 大(数を制御) |
最大の違いは「子分同士が話すか」。サブエージェントは話さない(親に報告のみ)、チームは話せる(対等な仲間)。
3有効化と始め方
実験的機能なので、まずスイッチを入れる必要があります。
- 環境変数で有効化
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を設定(またはsettings.jsonのenvに記載)して、Claude Code を再起動します。 - バージョンとプランを確認
claude --versionが v2.1.178 以降であること、有料プランであることを確認。 - 言葉でチームを立てるあとはふつうの日本語で「3人のチームメイトを立てて〜」と頼むだけ。メンバーの新規作成・タスク板・後片づけは自動です。
# 環境変数で有効化して起動(要再起動) $ export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 $ claude
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
🖥️表示モード(メンバーの見え方)
| モード | 見え方 | 操作の例 |
|---|---|---|
in-process(既定) | 1つの画面にメンバー一覧 | ↑↓で選び Enterで話しかける |
tmux | 画面を分割して各メンバーを表示 | tmux または iTerm2 が必要 |
auto | 環境に応じて自動(分割が無理なら一画面に) | — |
切り替えは /config または起動時に claude --teammate-mode tmux のように指定します。(VS Code 内蔵ターミナル等では分割表示に非対応。その場合は in-process で。実験的機能のため操作は変わりうる)
4仕組み:タスク板で協調する
チームの心臓は共有タスク板。リーダーがやることを並べ、メンバーが空いている仕事を自分で取り、終わったら次を取る——という流れで自律的に回ります。
タスクを取り合う
メンバーは未着手のタスクを自分で claim(確保)。依存関係があるタスクは前提が終わるまで取れない。
直接やり取り
メンバー同士が名前を指定してメッセージ。リーダーを通さず相談・指摘できる。
リーダーが統合
全員の結果をリーダーがまとめて最終的な答えにする。
sequenceDiagram participant U as あなた(=リーダー) participant T as 共有タスク板 participant A as メンバーA participant B as メンバーB U->>T: 計画を分解してタスクを並べる A->>T: 空きタスクを確保して着手 B->>T: 別の空きタスクを確保して着手 A-->>B: 「ここ依存してるよ」と直接相談 B-->>A: 「対応した、確認して」 A->>T: 完了に更新 B->>T: 完了に更新 T-->>U: 全タスク完了 U->>U: 結果を統合して報告
5向いてる仕事/向かない仕事
チームは「独立して並列に進められて、かつ議論が活きる」仕事でこそ輝きます。逆は単独のほうが速くて安いです。
向いている
観点別の並列レビュー(セキュリティ/性能/テスト)・競合する仮説のデバッグ・新モジュールを部位ごとに分担・フロント/バック/テストの横断作業。
向かない
順番待ちの作業・同じファイルを同時に編集・依存が多くて連絡だらけになる作業・ふつうの実装(単独が速く安い)。
6コストとサイズ感
チームは人数ぶんトークンを食います。便利さと費用のバランスを意識しましょう。
コストは約7倍
各メンバーが独立した Claude なので、単独セッションのおよそ7倍のトークンを使う場面も。価値の高い仕事に絞って。
3〜5人が目安
まずは3〜5人。1人あたり5〜6個の小さめタスク。「絞った3人 > 散らかった5人」。
7使ってみる:実例
認証まわりをチームで点検する例です。役割をはっきり分け、相互チェックまで頼むのがコツ。
認証モジュール(@src/auth/)をチームで点検したい。3人のメンバーを立てて、 役割を分けて: - 1人はトークン更新ロジック担当 - 1人はセッション管理担当 - 1人はセキュリティ観点でレビュー 各自が読んで所見を出したら、お互いの結果を相互チェックして、 意見が割れたら議論して合意してから、まとめて報告して。
こう頼むと、リーダーがメンバー3人を立て、タスク板に「トークン更新の確認」「セッション管理の確認」「セキュリティ監査」「結果の統合」を並べ、各メンバーが並列で読み始めます。途中で「セキュリティ担当→トークン担当:更新トークンの失効チェックが抜けてる」のようにメンバー同士が直接指摘し合い、最後にリーダーが統合して報告します。
8注意・制限(実験的機能)
現状の制限を知っておくと、ハマりません。
| 制限 | どうなる/対処 |
|---|---|
| セッション復元との相性 | /resume等でin-process メンバーは復元されない。再開後は新しく立て直す |
| タスク状態の遅れ | 完了マークが遅れて後続が止まることがある。手動で確認・更新を促す |
| 解散が遅い | メンバーは今の作業を終えてから抜ける。即終了は期待しない |
| 1セッション1チーム | 同時に複数チームは持てない/メンバーは自分のメンバーを立てられない(入れ子なし) |
| 分割表示の対応 | VS Code内蔵ターミナル等では分割不可 → in-process を使う |
次へ → 具体的に投げられるプロンプトは ✂️実践プロンプト集(チーム編)。考え方の全体像は 🏆上位エンジニアの組み立て方。