Claude Codeのagent teams（エージェントチーム）は、1つのセッションをリーダーにして、複数のClaude Codeを「メンバー」として同時に動かす機能です。メンバーは共有のタスクリストで仕事を取り、互いに直接メッセージを送り合います。確認時点では実験的な機能で、既定では無効です。この記事では、有効にする方法、最初のチームの作り方、タスクと連絡の管理、終了と後片付けまでを順に説明します。
この記事は、2026年10月29日に確認したAnthropicの公式資料をもとに、編集部が手順と注意点をまとめたものです。記事中の依頼文は説明用の例です。編集部はagent teamsを実際に動かして検証しておらず、実測の結果は含みません。実験的な機能のため、名前や動きが今後変わる可能性があります。利用中のバージョンと公式資料を照らし合わせてください。
Claude Code agent teamsとは：リーダーとメンバーで分担する仕組み
agent teamsでは、最初に起動したセッションが「チームリーダー」になり、作業の割り振り、メンバーの起動、結果のまとめを担当します。メンバーはそれぞれ独立したClaude Codeで、自分専用のコンテキスト（一度に扱える会話や資料の範囲）を持って作業します。リーダーを通さずに、利用者が特定のメンバーへ直接話しかけることもできます。
| 構成要素 | 役割 |
|---|---|
| チームリーダー | メンバーを起動し、作業を調整する最初のセッション |
| メンバー（teammates） | 割り当てられたタスクに取り組む、別々のClaude Code |
| タスクリスト | メンバーが取り、完了させる作業の共有一覧 |
| メールボックス | エージェント同士がメッセージをやり取りする仕組み |
公式資料が向いている例として挙げているのは、調査とレビュー、独立した新機能やモジュールの分担、原因が分からない不具合を複数の仮説で並行して調べる作業、フロントエンド・バックエンド・テストのように層をまたぐ変更です。反対に、順番に進める作業、同じファイルを編集する作業、依存関係の多い作業では、1つのセッションかサブエージェントの方が効果的だとされています。仕様の詳細はagent teamsの公式資料にあります。
agent teamsとサブエージェントの違い
どちらも作業を並列にできますが、指揮の仕方が違います（サブエージェント側の仕様はサブエージェントの公式資料を参照）。サブエージェントは、メインの会話から呼ばれて仕事をし、結果を呼び出し元へ返します。agent teamsのメンバーは、タスクリストを共有し、自分で仕事を取り、互いに直接連絡します。
| 観点 | サブエージェント | agent teams |
|---|---|---|
| コンテキスト | 専用の範囲を持ち、結果は呼び出し元へ戻る | 専用の範囲を持ち、完全に独立している |
| 連絡 | 呼び出し元へ結果を返す（名前を付けて起動されたもの同士は、メッセージも送れる） | メンバー同士が直接メッセージを送る |
| 調整 | メインの会話がすべてを管理する | メッセージとタスクリストで自律的に調整する |
| 向いている作業 | 結果だけが必要な、焦点の絞れた作業 | 議論や協力が必要な、複雑な作業 |
| トークン消費 | 比較的少ない | 多い（メンバーごとに別のClaudeが動く） |
公式資料は、チームを作る前に、より軽い方法で足りないかを確かめるよう案内しています。結果を受け取るだけならサブエージェント、自分で開いた複数のセッション間で情報を渡すだけならセッション間のメッセージ機能、手作業で並行させるならGitのworktreeが選択肢です。メンバー同士が意見を出し合い、互いの結論を検証し合う必要があるときに、agent teamsを使う価値があります。
agent teamsを有効にする
agent teamsは既定で無効です。環境変数CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSを1にすると有効になります。シェルで設定するか、settings.jsonのenvに書きます。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}有効にする前に知っておきたい点が3つあります。
- 通常の委任にも影響する。有効な間は、Claudeが名前を付けたサブエージェントは、メンバーとして起動します。Claudeは自分の判断でサブエージェントに名前を付けることがあるため、チームを頼んでいなくてもチームができる場合があります。名前付きのサブエージェントを通常のサブエージェントとして動かしたいときは、
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSを0にしてagent teamsを無効にします。 - 対話のセッションが必要。
-pによる非対話実行やAgent SDKのセッションでは、メンバーは起動しません。 - 使える場所が限られる。確認時点のClaude Code Desktopの公式資料では、agent teamsはCLIの機能で、Desktopでは使えないと説明されています（Desktopの使い方はDesktopの記事）。
設定の置き場所や優先順位はsettings.jsonの記事で解説しています。プロジェクトの設定や組織の管理設定で有効・無効が上書きされることもあるため、効かないときは設定の出どころを確かめます。
最初のチームを作る
有効にした後は、作業内容と欲しいメンバーを普通の言葉で伝えるだけです。Claudeがメンバーを起動し、タスクリストを作って作業を調整します。
最初は調査やレビューで試す
公式資料は、慣れないうちは、コードを書く必要がなく範囲のはっきりした作業（PRのレビュー、ライブラリの調査、不具合の調査など）から始めるよう勧めています。並列で実装すると、ファイルの取り合いや調整の手間が一度に出てくるためです。たとえば次のように、観点の違う3人にレビューを分担させる依頼が考えられます。
agent teamsでチームを作って、src/auth/ の変更をレビューしてください。メンバーは3人で、名前はreviewer-security、reviewer-performance、reviewer-testsとします。それぞれセキュリティ、性能、テストの不足を担当し、指摘を重大度つきでまとめてください。最後にリーダーが一覧にしてください。ファイルは変更しないでください。Claudeはチームを作らずに、サブエージェントで済ませることもあります。メンバーとサブエージェントは同じパネルに並ぶため、パネルの表示だけではチームができたと判断できません。その場合は、agent teamsを使うよう明示して依頼し直します。
人数とモデルを決める
人数の上限は決まっていませんが、公式資料は多くの場合3〜5人から始めることを勧めています。人数が増えるほどトークンの消費と調整の手間が増え、人数を増やしてもその分だけ速くなるわけではないためです。タスクはメンバー1人あたり5〜6個に分けると、全員が手を止めずに進められ、詰まった人の作業をリーダーが割り振り直しやすい、とされています。
メンバーのモデルは、確認時点（v2.1.251以降）の公式資料では、依頼文でそのメンバーに指定したモデル、サブエージェント定義のmodel、環境変数CLAUDE_CODE_SUBAGENT_MODEL、リーダーの現在のモデル、の順に決まります。費用を抑えたい場合、公式資料はメンバーにSonnetを使うことを挙げています。セキュリティ担当のように何度も使う役割は、サブエージェント定義を作っておき、その種類を指定してメンバーを起動することもできます。
メンバーに十分な前提を渡す
メンバーはプロジェクトのCLAUDE.md、MCPサーバー、スキルを自動で読み込みますが、リーダーの会話の履歴は引き継ぎません。対象のフォルダー、見てほしい観点、使っている技術、報告の形式など、作業に必要な前提は起動時の依頼に含めます。後から指示を出しやすいよう、上の例のように各メンバーの名前も指定しておきます。
表示モードを選ぶ
表示は、すべてのメンバーを1つのターミナル内で切り替えるin-processと、メンバーごとに画面を分割するsplit panesの2種類です。in-processはどのターミナルでも使えます。split panesにはtmuxか、iTerm2とit2コマンドが必要で、確認時点ではVS Codeの統合ターミナル、Windows Terminal、Ghosttyでは使えません。既定はin-processで、~/.claude/settings.jsonのteammateModeで変更できます。
agent teamsのタスクとメッセージを管理する
チームが動き出したら、リーダーに普通の言葉で指示を出して調整します。タスクには「未着手」「作業中」「完了」の状態があり、ほかのタスクの完了を待つものは、待っている間ブロック中として表示されます。リーダーが割り当てることも、作業を終えたメンバーが次の未割り当てのタスクを自分で取ることもできます。複数のメンバーが同じタスクを同時に取らないよう、タスクの取得はファイルのロックで制御されています。
メンバーに直接話しかける
既定の表示（in-process）では、リーダーの入力欄の下にメンバーの一覧が出ます。上下の矢印キーでメンバーを選び、Enterでそのメンバーの会話の記録（トランスクリプト）を開いて、直接メッセージを送れます。選んだメンバーでxを押すと停止し、Ctrl+Tでタスクリストの表示を切り替えます。メンバーの画面を見ている間でも、/compact・/clear・/rewindはリーダーの会話に働くため、実行前に確認が出ます。/modelと/fastは、この画面からは実行できません。
メンバー同士の連絡は、名前を指定して1人ずつ送る方式です。全員に伝えたい内容は、宛先ごとに送ります。名前を決めておけば、「reviewer-securityに追加で確認して」のようにリーダーへ指示を出しやすくなります。
実装の前に計画を出させる
リスクのある作業では、メンバーに計画を先に立てさせられます。リーダーをプランモードにしてからメンバーの起動を頼むと、そのメンバーは計画ができるまで読み取り専用で動きます。ただし公式資料によると、起動後にそのメンバーの権限モードを変えていなければ、計画の承認依頼はClaude Codeが自動で承認し、リーダーが内容を審査するわけではありません。承認後、メンバーはプランモードを抜けて実装に入ります。それでも、ファイルの編集やコマンドは通常どおり許可の確認を通り、その確認はリーダーのセッションに表示されるため、そこで止められます（権限モードによっては確認自体が出ない点は、次の項を参照してください）。
計画の内容をリーダーに審査させたい場合は、動いているin-processのメンバーの画面を開いた状態でShift+Tabを押し、そのメンバーをプランモードにします。この場合は、自動承認ではなくリーダーが計画を承認するか、修正を求めます。利用者に承認を求める仕組みではない点に注意してください。
許可の確認はリーダーの画面に集まる
メンバーはリーダーの権限モードを引き継いで始まります。ただしdontAskモードは引き継がれず、逆にリーダーが--dangerously-skip-permissionsで動いていると、メンバー全員も同じになります。メンバーの許可の確認はリーダーのセッションに表示されます。確認が多すぎて止まりがちな場合は、よく使う操作を事前に権限設定で許可しておくと流れやすくなります。なお、メンバーから届いたメッセージは利用者本人の指示としては扱われず、メンバーが利用者の代わりに許可を出すこともできません。
agent teamsを終了して結果を確かめる
メンバーを終わらせるときは、名前で指定して終了を依頼します。たとえば「reviewer-securityに終了するよう伝えて」と頼むと、リーダーが終了の依頼を送り、メンバーは承諾して終了するか、理由を添えて断ります。メンバーは実行中のリクエストやツールの呼び出しを終えてから止まるため、終了には時間がかかることがあります。
後片付けは基本的に自動です。チームの設定（~/.claude/teams/の下）はセッションの終了時に削除されます。一方、タスクリスト（~/.claude/tasks/の下）は終了後もディスクに残り、一定期間後に自動で整理されます。split panesでtmuxのセッションが残ってしまった場合は、tmux lsで一覧を確かめ、該当するものをtmux kill-session -t セッション名で終了します。
終わり方で注意したいのは、完了の判断です。公式資料には、メンバーがタスクを完了にし忘れて後続が止まる、リーダーが全タスクの完了前にチームを終えようとする、といった例が挙げられています。編集部としては、リーダーのまとめを読むだけで完了とせず、タスクリストの状態と、実際に変わったファイルや報告の中身を自分で照らし合わせることをおすすめします。止まっているように見えるタスクは、作業が本当に終わっているかを確かめてから、状態を更新するようリーダーに伝えます。
hooksで完了の基準を守らせる
完了の基準を機械的に守らせたい場合は、hooksが使えます。次のフックが終了コード2を返すと、指摘を伝えた上で、それぞれ次のように動きを変えられます。
- TeammateIdle：メンバーが手を止める直前に動く。指摘を伝えて作業を続けさせる。
- TaskCreated：タスクの作成時に動く。作成を止めて指摘を伝える。
- TaskCompleted：タスクを完了にする時に動く。完了を止めて指摘を伝える。
agent teamsの制限と費用の注意
確認時点の公式資料が挙げている主な制限は、次のとおりです。
- 再開でメンバーが戻らない。
/resumeや/rewindでは、in-processのメンバーは復元されません。再開後にリーダーが存在しないメンバーへ連絡しようとしたら、新しいメンバーを起動するようリーダーに伝えます。 - 1セッションに1チーム。チームはそのセッション専用で、別のチームを追加したり、セッション間で共有したりできません。
- 入れ子にできない。メンバーは自分のメンバーを作れず、チームを管理できるのはリーダーだけです。リーダーを途中で別のメンバーへ交代することもできません。
- 起動時はメンバーごとにモードを指定できない。全員がリーダーと同じモードで始まり（
dontAskを除く）、メンバーごとのモードは起動した後にしか変えられません。
費用の面では、メンバーごとに別のClaudeが動くため、トークンの消費はおおむね人数に比例して増えます。費用に関する公式資料は、メンバーにSonnetを使う、チームを小さく保つ、起動時の依頼を絞る、作業が終わったメンバーは終了させる（動いている間は消費が続くため）、といった方法を挙げています。また、同じファイルを2人が編集すると上書きが起きるため、担当するファイルを分けて依頼します。使用量の確かめ方は使用量の記事で扱っています。
まとめ：agent teamsは、独立した調査やレビューから小さく始める
最初は、環境変数で有効にし、ファイルを変更しないレビューや調査を3人程度のチームに任せます。メンバーへの前提の渡し方、タスクの状態の読み方、終了の手順を一度通してから、担当ファイルを分けた実装へ広げると、調整の失敗や無駄な消費を抑えられます。チームが必要かどうかは、メンバー同士の議論や検証が成果を上げる作業かで判断します。
業務の中で複数のAIに役割を分けて任せる仕組みを作る場合は、誰が何を担当し、どこで人が確認するかの設計が欠かせません。業務に合わせた分担と確認の設計は、PLaiのAI社員導入支援でも相談できます。
