エージェントチーム

エージェントチームは、複数の Claude Code インスタンスを協調させる機能です。1つのセッションがリードとして作業を割り振り、結果をまとめます。チームメイトはそれぞれ独自のコンテキストウィンドウで独立して動き、互いに直接やり取りします。リードを通さずに、任意のチームメイトへ直接話しかけることもできます。

• 調査・レビュー、新しいモジュールや機能、競合する仮説でのデバッグ、フロントエンド・バックエンド・テストをまたぐ変更に向く
• チームメイトどうしがメッセージを送り合い、共有のタスクリストで仕事を取り合える
• 調整のぶん、1つのセッションよりトークンを大きく使う
• 順番に進める作業・同じファイルの編集・依存の多い作業には、1つのセッションかサブエージェントのほうが向く

チームを作る前に、軽い手段で足りないかを確かめてください。サブエージェントは1つのセッションの中で動き、セッション間のメッセージなら、自分で動かすセッションの間で Claude に調査結果を渡させられます。方式の比べ方は並列作業の選び方を見てください。

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

素早く絞った作業をして報告する働き手が欲しいならサブエージェント、調査結果を共有し、互いに異論を出し、自分たちで調整させたいならエージェントチームを使います。

有効にする#

環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を 1 にします。シェルの環境でも、settings.json でも構いません。

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

有効にすると、普通の委任の動きも変わります。Claude が自分でサブエージェントに名前を付けることがあり、エージェントチームが有効な間は、名前を付けられたサブエージェントはチームメイトとして起動します。頼んでいなくてもチームができることがあるということです（「Claude がチームを始めるしくみ」と、「サブエージェントの代わりにチームメイトが起動する」の節を参照）。

チームメイトを起こすには対話セッションが要ります。-p の非対話モードでは（Agent SDK のセッションを含む）、Claude はチームメイトを起こさず、名前を付けられたサブエージェントは、エージェントチームが有効でも普通のサブエージェントとして動きます。

最初のチームを作る#

有効にしたら、やりたいことと欲しいチームメイトを自然な言葉で書きます。Claude がチームメイトを起こし、プロンプトに沿って調整します。次の例は、3つの役割が独立していて、互いを待たずに調べられるのでうまくいきます。

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Spawn three teammates to explore this from different angles:
one on UX, one on technical architecture, one playing devil's advocate.

Claude は、Task ツールのあるセッションで共有のタスクリストを作り、視点ごとにチームメイトを起こし、調べさせ、終わったら結果をまとめます。

Claude がチームを作らずサブエージェントを使うことがあります。サブエージェントもチームメイトと同じエージェントパネルに出るので、パネルを見ただけではチームができたか分かりません。サブエージェントになっていたら、エージェントチームを使うよう明示して頼み直します。

リードの端末では、プロンプト入力の下のエージェントパネルにチームメイトが並びます。

チームメイトやサブエージェントが1つでも動いている間、アイドルのチームメイトの行がパネルに残り、選んでトランスクリプトを見たり、仕事を足したりできます。パネル内のエージェントがすべてアイドルになると、アイドルの行は30秒後に隠れ、そのチームメイトの次のターンで再び現れます（隠れている間も、チームメイトは動いていて宛先として使えます）。

アイドルが3つを超えると、4つ目以降の行は、2 idle agents（5つがアイドルのとき）のように数を示す1行にまとまります。選んで Enter で開き、Esc で閉じます。作業中・失敗したチームメイトと、いま見ているチームメイトは、常に自分の行を持ちます。

チームを操る#

やりたいことを自然な言葉でリードに伝えると、チームの調整・タスクの割り当て・委任はリードが行います。

表示モードを選ぶ#

既定は "in-process" です。teammateMode の値は次のとおりです。

it2 のインストールか tmux への切り替えを提案するセットアップのプロンプトは、"auto" か "tmux" で、端末が iTerm2 で、フォールバックとして tmux が使えるときに出ます。既定を変えるには ~/.claude/settings.json の teammateMode を設定します。

{
  "teammateMode": "auto"
}

1回のセッションだけなら、フラグで渡します。--teammate-mode は実験的なフラグで、claude --help には出ません。

claude --teammate-mode auto

split-pane モードには、tmux か、iTerm2 と it2 CLI が必要です。手動で入れるには次のとおりです。

• tmux：システムのパッケージマネージャーで入れる
• iTerm2：it2 CLI を入れ、「iTerm2 → Settings → General → Magic → Enable Python API」で Python API を有効にする

チームメイトとモデルを指定する#

Claude がタスクに応じて人数を決めますが、指定もできます。

Spawn 4 teammates to refactor these modules in parallel. Use Sonnet for
each teammate.

チームメイトごとのモデルは、次のうち最初に当てはまるものから決まります。

1. 起動のプロンプトがそのチームメイトに名指ししたモデル
2. サブエージェントの定義から起こしたチームメイトなら、その定義の model（inherit はリードのモデルを選ぶ）
3. CLAUDE_CODE_SUBAGENT_MODEL（inherit 以外が設定されているとき）
4. リードの現在のモデル

CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 を設定すると、最初の2つは適用されません。すべてのチームメイトのモデルは、CLAUDE_CODE_SUBAGENT_MODEL が inherit 以外で設定されていればそれから、そうでなければリードの現在のモデルから決まります（v2.1.257 以降）。v2.1.251 より前は、この順で CLAUDE_CODE_SUBAGENT_MODEL が先頭でした。

選ばれたモデルは、組織の availableModels の許可リストで確認されます。許可リストが値を拒否したときの代替は次のとおりです。

• opus のようなファミリーの別名：Anthropic API と Claude Platform on AWS では、許可リストが認める、そのファミリーの最新バージョンで動く。プロバイダー固有のモデル ID を使うプロバイダーで、この代替が働かないときは、ブロックされた別名も、次の項目のように戻る
• そのほか、ブロックされた値（代替が働かないプロバイダーのファミリーの別名、許可されたバージョンがないファミリーを含む）：リードのモデルで動く。CLAUDE_CODE_SUBAGENT_MODEL を設定していれば、先にそのモデルを同じ規則で試す

既定では、チームメイトはリードのeffortを引き継ぎます。split-pane では v2.1.186 以降が該当し、それより前はリードのセッションの effort を split-pane のチームメイトへ渡していませんでした。

実装の前に計画させる#

複雑・危険な作業では、実装の前に計画させられます。リードがプランモードのときに Claude が起こしたチームメイトは、計画ができるまで読み取り専用のプランモードで動きます。先にリードをプランモードにしてから頼みます。

Spawn an architect teammate to refactor the authentication module.

チームメイトが計画を終えると、リードへ計画の承認の要求を送ります。Claude Code は、リードが内容を見ずに、要求が届いた時点でリードのセッションで計画を承認します。チームメイトの編集やコマンドは、下の「権限」の節のとおり、引き続き権限プロンプトを通ります。承認されると、チームメイトはプランモードを抜けて実装を始めます。

チームメイトに直接話しかける#

各チームメイトは、完全で独立した Claude Code セッションです。直接メッセージを送って、追加の指示・質問・方向の修正ができます。

• in-process：エージェントパネルで上下キーで選び、Enter でセッションを見て、入力でメッセージを送る。選んだチームメイトで x を押すと止める。Ctrl+T でタスクリストを切り替える
• split-pane：チームメイトのペインをクリックして直接操作する。各チームメイトは自分の端末の全体を持つ

in-process のチームメイトを見ている間、プレーンテキストとスキルはそのチームメイトへ送られ、組み込みのコマンドはリードのセッションへ送られます。次の安全策があります。

• /compact・/clear・/rewind はリードの会話に作用するので、この画面から実行する前に Claude Code が確認する
• /model と /fast はチームメイトではなくリードのモデルと fast mode を設定するので、この画面からは実行されない。理由が通知で出る

チームメイトのモデルと fast mode は、起こしたときに決まります。

タスクを割り当てて取り合う#

共有のタスクリストがチーム全体の作業を調整します。リードがタスクを作り、チームメイトがこなします。タスクの状態は pending・in progress・completed の3つです。タスクは別のタスクに依存でき、未解決の依存があるタスクは、依存が完了するまで取れません。Task ツールを持たないエージェントは、共有のタスクリストでなくメッセージで調整します。

• リードが割り当てる：どのタスクをどのチームメイトに渡すかをリードに伝える
• 自分で取る：チームメイトは、タスクを終えると、次の未割り当てで、ブロックされていないタスクを自分で取る

複数のチームメイトが同じタスクを同時に取ろうとする競合は、ファイルのロックで防がれます。

チームメイトを終了させる#

名前で呼んで、セッションを穏やかに終わらせます。たとえば researcher というチームメイトなら次のとおりです。

Ask the researcher teammate to shut down

リードが終了の要求を送ります。チームメイトは承認して穏やかに終わるか、理由を添えて拒否できます。チームの共有ディレクトリは、セッションの終了時に自動で片づけられるので、別の後片付けの手順はありません。

フックで品質のゲートを作る#

チームメイトの作業の終わり、タスクの作成・完了のときに、フックでルールを強制できます。

しくみ#

Claude がチームを始めるしくみ#

チームを始めるには、Claude にチームメイトを頼みます。エージェントチームが有効な間に、Claude が Agent ツールを name つきで呼ぶと、チームメイトが起動します（フォークの場合や、呼び出し自体が isolation を渡す場合は除く）。Claude Code は起動の確認を求めません。Claude は、あとでメッセージを送れるよう、普通のサブエージェントにも自分で名前をつけます。これも同じ規則に従うので、頼んでいなくてもチームができることがあります。サブエージェントのままにしたいなら、エージェントチームをオフにします（下の「サブエージェントの代わりにチームメイトが起動する」の節）。

構成要素#

各エージェントのメールボックスは、~/.claude/teams/{team-name}/inboxes/{agent-name}.json の JSON ファイルです。Claude Code は、読むたびにすべての項目を検証し、メッセージ形式に合わない項目はエラーとして報告してファイルから消し、有効なメッセージは配信し続けます（v2.1.207 より前は、壊れた項目が1つあると毎秒エラーが出て、ファイルを手で消すまでそのメールボックスへの配信が止まりました）。

メッセージが送られたと報告されるのは、宛先のメールボックスのファイルへの書き込みが成功したときだけです（プレーンテキストでも、計画の承認や終了の要求のような構造化メッセージでも）。ディスクが満杯・メールボックスのディレクトリに書けないなどで失敗すると、送信側のエージェントにエラーが返り、何も送られません。エラーメッセージと回復の手順はエラー一覧の「Failed to write to a teammate's inbox」を見てください。

タスクの依存は Claude Code が自動で管理し、チームメイトが、ほかのタスクが依存するタスクを完了すると、依存するタスクのブロックを外します。チームとタスクは、セッションから決まる名前でローカルに保存されます。名前は session- に、セッション ID の最初の8文字を続けたものです。

どちらも Claude Code が起動時に自動で作り、チームメイトの参加・アイドル・離脱に合わせて更新します。チームの設定ディレクトリは、セッションの終了時に消されます。タスクリストのディレクトリはローカルに残り、アップロードされないので、再開したセッションでもタスクが残ります。保持期間は、セッションのトランスクリプトと同じ cleanupPeriodDays と保持の掃除の規則に従います。

チームの設定には、各メンバーの名前とエージェント ID を持つ members 配列があります。リードの項目のエージェントタイプは常に team-lead です。チームメイトの項目には、リードが起こすときに名指ししたエージェントタイプ（組み込みのタイプでもサブエージェントの定義でも）が入り、名指しがなければこのフィールドは省かれます。チームメイトはこのファイルを読んで、ほかのメンバーを知れます。プロジェクトにはチームの設定の同等物がなく、.claude/teams/teams.json のようなファイルは設定として認識されません（Claude は普通のファイルとして扱います）。

チームメイトにサブエージェントの定義を使う#

どちらの表示モードでも、チームメイトを起こすときに、プロジェクト・ユーザー・管理・プラグインのサブエージェントのスコープにあるサブエージェントのタイプを指せます。security-reviewer や test-runner のような役割を1回定義して、委任されたサブエージェントとしても、エージェントチームのチームメイトとしても使い回せます。定義を使うには、チームメイトを頼むときに名指しします。

Spawn a teammate using the security-reviewer agent type to audit the auth module.

Claude Code は名指しされたサブエージェントの定義を読み、次の部分をチームメイトに適用します。

Claude が、もう動いていない in-process のチームメイトにメッセージを送ると、Claude Code は同じセッションの中でそれを復帰させ、保存されていた会話を戻して、メッセージを次のプロンプトとして渡します。セッションを再開したあとは、「制限」の節のとおり、この復帰は行われません。復帰させるチームメイトに、プロジェクトの .claude/agents/ や --add-dir のディレクトリから来た定義を当て直すのは、エージェントのファイルのあるフォルダを信頼している場合だけです。親のフォルダを信頼しても数えられません。それまでは、定義のツールも指示もなく、Claude Code がすべての in-process のチームメイトに足すツールだけで復帰します。

権限#

チームメイトはリードの権限モードで始まります。ただし dontAsk モードは引き継ぎません。リードが --dangerously-skip-permissions で動いていれば、すべてのチームメイトもそうなります。起こしたあとで個々のチームメイトの権限モードを変えられますが、起こす時点でチームメイトごとの権限モードは設定できません。

チームメイトの権限プロンプトはリードのセッションに出るので、そこで自分で承認します。計画の承認は設計上の例外で、リードのセッションが、あなたへの別のプロンプトなしでチームメイトの計画を承認します。

エージェント間のメッセージ#

あるエージェントが別のエージェントへ SendMessage でメッセージを送ると、Claude Code は受け手に、そのメッセージがあなたではなく別の Claude セッションから来たことを伝えます。チームメイトは、あなたの代わりに権限プロンプトを承認したり同意を与えたりできず、操作を拒否されたチームメイトが、別のチームメイトに中継して確認を回避することもできません。チームの外の、あなたの別の Claude Code セッションから届いたメッセージにも、同じ規則が適用されます。

auto モードでは、分類器がエージェント間のメッセージに2つの確認を行います。

• ほかのエージェントから中継された承認の主張を、あなたからの確認ではなく、信頼できない入力として扱う
• Claude Code が配信する前に、すべてのメッセージ（プレーンなものも、終了の要求や計画の承認の応答のような構造化メッセージも）を確認する。ブロックされたメッセージは、受け手に届かない

コンテキストと通信#

各チームメイトは自分のコンテキストウィンドウを持ちます。起こされたとき、通常のセッションと同じプロジェクトの文脈（CLAUDE.md・MCP サーバー・スキル）を読みます。リードを --setting-sources で起動すると、チームメイトも同じ制限された読み込み元から読みます（v2.1.281 より前は、split-pane のチームメイトはすべての設定の読み込み元を読みました）。チームメイトはリードからの起動プロンプトも受け取りますが、リードの会話履歴は引き継ぎません。

情報の共有のしかたは次のとおりです。

• メッセージの自動配信：チームメイトが送ったメッセージは受け手に自動で届き、リードが更新を確認しに行く必要はない
• アイドルの通知：チームメイトが作業を終えて止まると、最終的な答えを添えて自動でリードに通知する。ターンが API エラーで終わったチームメイトは、失敗したことをエラーの文面とともにリードに通知する
• 共有のタスクリスト：Task ツールを持つエージェントは、タスクの状態を見て、取れる作業を取れる
• チームメイトへのメッセージ：名前で特定のチームメイトに送る。全員に送るには、宛先ごとに1通ずつ送る

リードは、起こすときにすべてのチームメイトに名前をつけ、どのチームメイトも、その名前でほかのチームメイトにメッセージを送れます。あとのプロンプトで参照できる決まった名前が欲しいなら、起動の指示で、それぞれを何と呼ぶかをリードに伝えます。

トークンの使用量#

エージェントチームは、1つのセッションよりトークンを大きく使います。各チームメイトが自分のコンテキストウィンドウを持ち、使用量は動いているチームメイトの数に応じて増えます。調査・レビュー・新機能の作業では、多くの場合、そのぶんの価値があります。日常の作業では1つのセッションのほうがコスト効率がよく、詳しくはコストを抑えるを見てください。

in-process のチームメイトのリクエストは、メインの会話のキャッシュ TTL の区分の外にあり、キャッシュは既定で5分保持されます（Claude のサブスクリプションでも同じ）。1時間保つには、subagentPromptCacheTtl を 1h にします。API は1時間のキャッシュ書き込みを、より高い料金で請求します。

使い方の例#

並列の探索が価値を持つ作業の例です。

並列でコードレビューをする#

1人のレビュアーは、一度に1種類の問題に注意が向きがちです。レビューの基準を独立した領域に分ければ、セキュリティ・性能・テストのカバレッジに同時に十分な注意が払われます。プロンプトで、チームメイトごとに別の視点を割り当てて、重ならないようにします。

Spawn three teammates to review PR #142:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

各レビュアーは同じ PR を、別のフィルターで見ます。3人が終えたら、リードが結果をまとめます。

競合する仮説で調べる#

原因がはっきりしないとき、1つのエージェントは、もっともらしい説明を1つ見つけると探すのをやめがちです。チームメイトに、自分の説を調べるだけでなく、ほかの説に反論させるよう、プロンプトで対立の構図を作ります。

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

鍵は議論の構造です。順番に調べると、ある説を調べたあとの調査がそれに引きずられます（アンカリング）。複数の独立した調査役が互いに反証しようとすれば、生き残った説が真の原因である可能性が大きく高まります。

ベストプラクティス#

チームメイトに十分な文脈を渡す#

チームメイトは CLAUDE.md・MCP サーバー・スキルを自動で読みますが、リードの会話履歴は引き継ぎません。作業固有の詳細は、起動のプロンプトに入れます。

Spawn a security reviewer teammate with the prompt: "Review the authentication module
at src/auth/ for security vulnerabilities. Focus on token handling, session
management, and input validation. The app uses JWT tokens stored in
httpOnly cookies. Report any issues with severity ratings."

チームの人数を決める#

チームメイトの数に厳密な上限はありませんが、実際上の制約があります。

• トークンコストは線形に増える：各チームメイトが自分のコンテキストウィンドウを持ち、独立してトークンを消費する
• 調整の負担が増える：チームメイトが増えると、通信・タスクの調整・衝突の可能性が増える
• 収益が逓減する：ある数を超えると、チームメイトを足しても、作業は比例して速くならない

多くのワークフローでは、3〜5人のチームメイトから始めます。並列の作業と調整のしやすさの釣り合いが取れます。独立したタスクが15あるなら、まず3人が目安です。作業が同時進行の恩恵を受けるときだけ増やします。絞った3人は、散らばった5人にしばしば勝ります。

タスクの大きさを揃える#

• 小さすぎる：調整の負担が利益を超える
• 大きすぎる：チームメイトが確認なしに長く動き、無駄になる危険が増える
• ちょうどよい：関数・テストファイル・レビューのように、明確な成果物を出す、自己完結した単位

チームメイトの完了を待たせる#

リードが、チームメイトを待たずに自分でタスクを実装し始めることがあります。そのときは、次のように伝えます。

Wait for your teammates to complete their tasks before proceeding

調査とレビューから始める#

エージェントチームが初めてなら、境界がはっきりしていて、コードを書かない作業（PR のレビュー・ライブラリの調査・バグの調査）から始めます。並列の実装に伴う調整の難しさなしに、並列の探索の価値が分かります。

ファイルの衝突を避ける#

2人のチームメイトが同じファイルを編集すると、上書きが起きます。チームメイトごとに別のファイルを担当するよう、作業を分けます。

見守って操縦する#

チームメイトの進み具合を確認し、うまくいかない方法を修正し、結果が出たらまとめます。チームを長く放置すると、無駄になる危険が増えます。

トラブルシューティング#

チームメイトが現れない#

Claude に起こすよう頼んでもチームメイトが現れないとき：

• in-process モードでは、プロンプト入力の下のエージェントパネルに出る。上下キーで選び Enter で見る
• アイドルのまま消えたチームメイトの行は、止まったのではなく隠れている。アイドルの行は、パネル全体がアイドルになって30秒後に隠れ、そのチームメイトの次のターンで再び現れる。アイドルが3つを超えると、余りの行は N idle agents の1行にまとまり、Enter で展開される。隠れた行は、名前でそのチームメイトにメッセージを送ると戻る
• 渡したタスクが、チームを使うに値するほど複雑かを確かめる。チームメイトを起こすかどうかは Claude がタスクから決める
• split-pane を明示的に頼んだなら、tmux が入っていて PATH にあるかを確かめる（which tmux）
• iTerm2 なら、it2 CLI が入っていて、iTerm2 の設定で Python API が有効かを確かめる

サブエージェントの代わりにチームメイトが起動する#

エージェントチームが有効な間は、リードのセッションで Claude が名前をつけたサブエージェントは、チームメイトとして起動します。Claude は自分でサブエージェントに名前をつけられるので、チームの作業として頼んでいない委任でも、これが起きます。名前をつけたサブエージェントを、サブエージェントとして起動するようにするには、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を 0 にして、エージェントチームをオフにします。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "0"
  }
}

新しいセッションは要りません。設定ファイルの env の値は、保存したときに動いているセッションに適用し直され、Claude がサブエージェントを起こすたびに変数が読み直されるので、次に Claude が名前をつけるサブエージェントは、サブエージェントとして起動します。

ユーザーの settings.json で 0 にすると、シェルのエクスポートは上書きされます。ほかの設定の読み込み元が、エージェントチームを有効にしていることもあります。

• 優先度の高い設定ファイル：プロジェクト設定・ローカル設定・--settings のペイロードは、ユーザー設定のあとに適用されるので、それらのどれかの env が変数を 1 にしていれば、そちらが勝つ。設定の優先順位を参照
• 管理設定：管理設定はほかのすべての読み込み元のあとに適用される。組織がそこでエージェントチームを有効にしているなら、管理者に管理側の値を変えてもらう

変更のあとも、Claude はサブエージェントに名前をつけることがあり、その名前は SendMessage の宛先として使えます。Claude は、各サブエージェントが完了したときにその結果を受け取ります。

権限プロンプトが多すぎる#

チームメイトの権限の要求はリードへ上がり、手間になることがあります。チームメイトを起こす前に、権限設定で、よく使う操作を事前に承認しておくと、割り込みが減ります。

エージェントが途中で止まる#

チームメイトが、エラーに遭ったあと、回復せずに止まることがあります。in-process モードならエージェントパネルでそのチームメイトを選んで Enter を押す、split モードならペインをクリックして出力を確かめ、次のどちらかをします。

• 追加の指示を直接渡す
• 作業を引き継ぐ代わりのチームメイトを起こす

リードや別のチームメイトからのメッセージは、失敗した API リクエストの再試行を待っている in-process のチームメイトを起こすので、再試行の待ち時間いっぱいを待たずに、すぐ再試行します。リードも早く止まることがあり、すべてのタスクが完了する前にチームが終わったと判断してしまいます。そのときは、続けるよう伝えます。

残った tmux のセッション#

Claude Code のセッションが終わったあとに tmux のセッションが残っていたら、片づけが完全ではなかった可能性があります。セッションを一覧して、チームが作ったものを終わらせます。

tmux ls
tmux kill-session -t <session-name>

制限#

エージェントチームは実験的な機能です。現時点の制限は次のとおりです。

• in-process のチームメイトのセッションは再開できない：/resume と /rewind は in-process のチームメイトを復元しない。再開後、リードがもう存在しないチームメイトにメッセージを送ろうとすることがある。そのときは、新しいチームメイトを起こすようリードに伝える
• タスクの状態が遅れることがある：チームメイトがタスクを完了にし忘れて、依存するタスクをブロックすることがある。タスクが止まって見えたら、作業が実際に終わっているかを確かめ、タスクの状態を手で更新するか、チームメイトを促すようリードに伝える
• 終了に時間がかかることがある：チームメイトは、いまのリクエストやツールの呼び出しを終えてから終了するので、時間がかかることがある
• 1セッションに1チーム：セッションはちょうど1つのチームを持ち、そのセッションに閉じる。別の名前つきのチームを作ったり、セッションをまたいでチームを共有したりはできない
• チームの入れ子はできない：チームメイトは、自分のチームメイトを起こせない。チームを管理できるのはリードだけ
• in-process のチームメイトからはバックグラウンドのサブエージェントを使えない：in-process のチームメイトのサブエージェントは前面で動く（チームメイトのバックグラウンドの作業は、リードのプロセスより長く生きられないため）。チームメイトが、定義に background: true を設定したサブエージェントを起こすと、Claude Code はエラーを返す。チームメイトの run_in_background: true の要求も、エラーになるか、静かに前面で実行される
• リードは固定：メインのセッションが、その存続のあいだリードになる。チームメイトをリードに昇格させたり、リードを移したりはできない
• 権限は起動時に決まる：チームメイトは、上の「権限」の節の権限モードで始まる。起こしたあとに個々のチームメイトの権限モードは変えられるが、起こす時点でチームメイトごとの権限モードは設定できない
• split pane には tmux か iTerm2 が必要：既定の in-process モードは、どの端末でも動く。split-pane モードは、VS Code の統合ターミナル・Windows Terminal・Ghostty では使えない

関連：軽い委任にはサブエージェント、自分のセッション間のやり取りにはセッション間のメッセージ、自動の調整なしで自分で複数のセッションを動かすにはworktreeがあります。