【Claude Code 連載第66回】Claude Code セッションのチームを調整する — エージェントチームという実験

よっしー

こんにちは。よっしーです(^^)

背景
1. 一言でいうと何か
2. どういう場面で役立つか
3. コマンド・プロンプトの実例と解説
4. まとめ＋次回予告

背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. 一言でいうと何か

このページは、複数の Claude Code インスタンスを「チーム」として動かす——リーダーが1つ、チームメンバーが複数、共有タスクリストとメールボックスで互いに直接やり取りする——という実験的機能の解説です。

第64回の並列化4アプローチのうち、最後まで残っていた2つのうちの1つ。前回（第65回）のエージェントビューが「あなたが引き継いで監視する」形だったのに対し、こちらは「Claude が分割・割り当て・同期する」形です。

最初に、この機能の最大の前提を置きます。

エージェントチームは実験的機能であり、デフォルトでは無効になっています。settings.json または環境に CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を追加して有効にしてください。その変数がない場合、セッション開始時にチームが設定されず、チームディレクトリが書き込まれず、Claude はチームメンバーをスポーンまたは提案しません。

つまり変数を入れるまで、この機能は存在しないのと同じです。加えて原文はセッション再開・タスク調整・シャットダウン動作に既知の制限があると明記しています（後述）。

もう1つ、記述の基準時点が明示されています。このページは v2.1.178 時点のエージェントチームについて説明しています。そして旧仕様の名残が丁寧に否定されています。**v2.1.178 より前は、最初にチームを作成して名前を付けるよう Claude に依頼し、Claude は TeamCreate と TeamDelete ツールを使用してセットアップと削除を行いました。両方のツールはもう存在しません。**古い記事や設定を持っている人は、ここで一度捨てる必要があります。

仕組みの核は subagents との対比で語られています。subagents（単一セッション内で実行され、メインエージェントにのみ報告できる）とは異なり、リーダーを経由せずに個別のチームメンバーと直接対話することもできます。

2. どういう場面で役立つか

原文は「最も強力なユースケース」を4つ挙げています。共通しているのは、チームメンバーが互いを待たずに動けることです。

シーン1：調査とレビュー

複数のチームメンバーが問題のさまざまな側面を同時に調査し、その後、各自の調査結果を共有して相互に検証できます。

「相互に検証」がポイントで、これは subagents ではできません。あとで見る「競合する仮説での調査」が、この形の極北です。

シーン2：新しいモジュールまたは機能

チームメンバーが互いに干渉することなく、それぞれ別々の部分を担当できます。ここでの前提はファイルの縄張りが分かれていること。これは第64回でも強調された、エージェントチーム最大の落とし穴に直結します。

シーン3：競合する仮説でのデバッグ

**チームメンバーが異なる理論を並列でテストし、より迅速に答えに収束できます。**原文は後段で、その理由を説明しています——順序付き調査はアンカリングに悩まされます。1つの理論が探索されると、その後の調査はそれに向かってバイアスされます。

シーン4：クロスレイヤー調整

フロントエンド、バックエンド、テストにまたがる変更で、それぞれ異なるチームメンバーが担当します。

不要・向かないケース

原文が明確に列挙しています。**エージェントチームは調整オーバーヘッドを追加し、単一セッションよりも大幅に多くのトークンを使用します。**そのうえで——

順序付きタスク・同じファイルの編集・多くの依存関係を持つ作業。この場合は単一セッションまたは subagents がより効果的です。
**結果だけあればよいタスク。**結果を報告する必要がある迅速で焦点を絞ったワーカーが必要な場合は subagents を使用してください。
**ルーチンタスク。**単一セッションがより費用効果的です。
**VS Code の統合ターミナル・Windows Terminal・Ghostty で分割ペイン表示をしたい場合。**分割ペインモードはサポートされていません（既定の in-process モードは任意のターミナルで動く）。
セッションを再開して続けたい場合。制限事項の筆頭がこれです。/resume と /rewind は in-process チームメンバーを復元しません。
**チームメンバーにさらにチームを作らせたい場合。**ネストされたチームなし。チームメンバーは独自のチームメンバーを生成できません。

3. コマンド・プロンプトの実例と解説

このページの「コード例」は大半が自然言語のプロンプト例です。設定ファイル2つ、CLI 3つ、あとはすべて Claude に投げる英語の指示文。フェンス付きブロックは14本あり、本記事ではすべて原文どおり引用します。

前提の再掲：実験的機能／既定で無効／CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS が必要／記述は v2.1.178 時点／TeamCreate・TeamDelete は現存しない。

有効化する

~/.claude/settings.json などに書きます。

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

シェル環境または settings.json を通じて設定できます。

最初のチームを立てる

セットアップコマンドはありません。実行したいタスクとチームメンバーを自然言語で説明するだけです。原文の例。

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.

この例は、3つの役割が独立しており、互いに待つことなく問題を探索できるため、うまく機能します。——なぜこの例が良いのかを原文自身が説明しているのが親切です。

するとClaude は共有タスクリストを作成し、各視点のチームメンバーを生成し、問題を探索させ、完了時に調査結果を統合します。

リーダーの画面にはプロンプト入力の下のエージェントパネルが出ます。操作は3つ。

上下矢印: チームメンバーを選択する
Enter: 選択したチームメンバーのトランスクリプトを開き、直接メッセージを送信する
Escape: 選択したチームメンバーの現在のターンを中断する

パネルの表示挙動には細かい仕様があります。**v2.1.199 以降、アイドル状態のチームメンバーの行は、他のチームメンバーまたはサブエージェントがまだ作業中の間、パネルに留まります。パネル内のすべてのエージェントがアイドル状態になると、アイドル行は30秒後に非表示になり、チームメンバーの次のターンで再表示されます。**重要なのは次の一文です。チームメンバーは非表示中も実行中で対応可能な状態が続きます。——消えた＝止まった、ではありません。

また3人以上のチームメンバーが同時にアイドル状態の場合、最初の3行を超える行は、折りたたまれたチームメンバーをカウントする単一の行に折りたたまれます。例えば、5人がアイドル状態の場合は 2 idle agents のようになります。

表示モードを選ぶ

2モードあります。In-process（すべてメインターミナル内、追加セットアップ不要、任意のターミナルで動作）と分割ペイン（各チームメンバーが独自のペイン、tmux または iTerm2 が必要）。

**デフォルトは "in-process" です。**ここに移行時の注意があります。v2.1.179 より前は、デフォルトは "auto" でした。そのため、以前に分割ペインを開いたアップグレードされたセッションは、モードを明示的に設定しない限り、1つのターミナルに留まります。

設定値は4つ。"in-process" / "auto"（既に tmux セッション内で実行している場合または使用しているターミナルが iTerm2 の場合は分割ペインを有効にし、それ以外の場合は in-process にフォールバック）/ "tmux"（ターミナルに基づいて tmux または iTerm2 を使用するかどうかを自動検出）/ "iterm2"（v2.1.186 以降、it2 CLI が必要）。

{
  "teammateMode": "auto"
}

単一セッションだけならフラグで渡します。

claude --teammate-mode auto

なお tmux については注意書きがあります。tmux には特定のオペレーティングシステムでの既知の制限があり、従来は macOS で最も効果的に動作します。iTerm2 で tmux -CC を使用することが、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.

ここに引っかかりやすい仕様があります。チームメンバーはデフォルトではリーダーの /model 選択を継承しません。変えたい場合は/config で Default teammate model を設定し、リーダー追従にしたいならDefault (leader’s model) を選択します。

一方努力レベルは継承します。チームメンバーはリーダーの努力レベルを継承します。分割ペインモードではこれは v2.1.186 から適用されます。——**モデルは継承しない、努力は継承する。**この非対称は覚えておく価値があります。

プラン承認を要求する

リスクの高い作業では、実装前にプランを出させられます。

Spawn an architect teammate to refactor the authentication module.
Require plan approval before they make any changes.

チームメンバーはリーダーがアプローチを承認するまで、読み取り専用プランモードで動作します。却下されるとチームメンバーはプランモードのままで、フィードバックに基づいて修正し、再提出します。

ここが設計上の分岐点です。**リーダーは自律的に承認決定を下します。つまり人間に確認は来ません。**原文は対処法も書いています。リーダーの判断に影響を与えるには、プロンプトで「テストカバレッジを含むプランのみを承認する」や「データベーススキーマを変更するプランを却下する」などの基準を指定してください。

承認基準を自然言語で先に渡しておかないと、リーダーが独断で通す——これは設計を理解していないと事故になる箇所だと思います（この評価は筆者のもので、原文はリスクとしては書いていません）。

チームメンバーと直接話す

各チームメンバーは、完全で独立した Claude Code セッションです。In-process なら上下矢印で選択、Enter で表示してメッセージを入力、選択したチームメンバーで x を押してそれを停止、Ctrl+T でタスクリストを切り替え。分割ペインならペインをクリック。

ここに混同しやすい仕様があります。In-process チームメンバーを表示している間、プレーンテキストと skills はそのチームメンバーに送信されますが、組み込みコマンドはリーダーのセッションで実行されます。

具体的にはチームメンバーのモデルと高速モードはそれが生成されるときに固定されるため、/model と /fast はリーダーの設定のみを変更します。v2.1.199 以降は通知が表示されますが、**それより前のバージョンでは、指示なしでリーダーに適用されました。**例外は /effort で、チームメンバーの後続のターンに適用されます。これはチームメンバーがリーダーの努力レベルに従うためです。

タスクの割り当てと自己要求

共有タスクリストはチーム全体の作業を調整します。タスクには3つの状態があります。保留中、進行中、完了。タスクは他のタスクに依存することもできます。未解決の依存関係を持つ保留中のタスクは、それらの依存関係が完了するまで要求できません。

割り当ての形は2つ。リーダーが割り当て（どのタスクを誰に渡すか指示する）と自己要求（タスクを完了した後、チームメンバーは独立して次の未割り当て、ブロック解除されたタスクを選択します）。

実装上の配慮も明記されています。タスク要求はファイルロックを使用して、複数のチームメンバーが同時に同じタスクを要求しようとするときの競合状態を防ぎます。

終わらせる

シャットダウンも自然言語です。

Ask the researcher teammate to shut down

リーダーはシャットダウンリクエストを送信します。チームメンバーは承認して適切に終了するか、説明付きで却下できます。

後片付けは不要になりました。チームの共有ディレクトリは、セッションが終了すると自動的にクリーンアップされるため、別のクリーンアップステップはありません。

hooks で品質ゲートをかける

チーム専用のフックイベントが3つあります。すべて終了コード2が制御の合図です。

TeammateIdle：チームメンバーがアイドル状態になろうとしているときに実行されます。終了コード2でフィードバックを送信し、チームメンバーを動作させ続けてください。
TaskCreated：タスクが作成されているときに実行されます。終了コード2で作成を防止し、フィードバックを送信してください。
TaskCompleted：タスクが完了としてマークされているときに実行されます。終了コード2で完了を防止し、フィードバックを送信してください。

「勝手に完了扱いにさせない」「勝手に休ませない」を機械的に強制できる、ということです。

アーキテクチャ

構成要素は4つ。

コンポーネント	役割
チームリーダー	チームメンバーを生成し、作業を調整するメイン Claude Code セッション
チームメンバー	割り当てられたタスクで動作する個別の Claude Code インスタンス
タスクリスト	チームメンバーが要求して完了する共有作業項目リスト
メールボックス	エージェント間の通信用メッセージングシステム

実体はローカルのファイルです。**各エージェントのメールボックスは ~/.claude/teams/{team-name}/inboxes/{agent-name}.json にある JSON ファイルです。**堅牢化も入りました。Claude Code はメールボックスファイルを読み取るときにすべてのエントリを検証します。メッセージ形式と一致しないエントリはエラーとして報告され、ファイルから削除されます。有効なメッセージは引き続き配信されます。v2.1.207 より前では、1つの不正なメールボックスエントリが毎秒繰り返しエラーを引き起こし、ファイルを手動で削除するまでそのメールボックスの配信をブロックしていました。

チーム名は自動です。**名前は session- の後にセッション ID の最初の8文字が続きます。**保存先は2か所。

チーム設定：~/.claude/teams/{team-name}/config.json
タスクリスト：~/.claude/tasks/{team-name}/

寿命が違います。チーム設定ディレクトリはセッション終了時に削除されます。タスクリストディレクトリはローカルに保持され、アップロードされることはないため、再開されたセッションはタスクを保持します。保持期間はセッショントランスクリプト用に既に制御している同じ cleanupPeriodDays に従います。

設定ファイルを手で触るなという警告もあります。チーム設定はセッション ID と tmux ペイン ID などのランタイム状態を保持しているため、手動で編集したり、事前に作成したりしないでください。次の状態更新時に変更が上書きされます。

同様に、プロジェクトレベルのチーム設定に相当するものはありません。プロジェクトディレクトリ内の .claude/teams/teams.json のようなファイルは設定として認識されません。Claude はそれを通常のファイルとして扱います。

依存関係の解消は自動です。チームメンバーが他のタスクが依存するタスクを完了すると、ブロックされたタスクは手動介入なしにブロック解除されます。

subagent 定義をチームメンバーとして使い回す

役割の定義を1か所にまとめられます。任意の subagent スコープ（プロジェクト、ユーザー、プラグイン、または CLI 定義）から subagent タイプを参照できます。

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

**チームメンバーはその定義の tools 許可リストと model を尊重し、定義の本体はチームメンバーのシステムプロンプトに追加の指示として追加されます。**ただし例外があります。チーム調整ツール（SendMessage やタスク管理ツール）は、tools が他のツールを制限している場合でも、チームメンバーが常に利用できます。

反映されないフィールドも明記されています。subagent 定義の skills と mcpServers frontmatter フィールドは、その定義がチームメンバーとして実行される場合は適用されません。チームメンバーは、通常のセッションと同じように、プロジェクトおよびユーザー設定から skills と MCP servers をロードします。

権限 — ここが一番読むべき節

チームメンバーはリーダーの権限設定で開始します。リーダーが --dangerously-skip-permissions で実行する場合、すべてのチームメンバーも同様に実行します。そして生成後、個別のチームメンバーモードを変更できますが、生成時にチームメンバーごとのモードを設定することはできません。

エージェント同士が権限を回避できないように、明示的な防御が組まれています。

1つのエージェントが SendMessage 経由で別のエージェントにメッセージを送信する場合、受信エージェントには、あなたからではなく別の Claude セッションから来たことが通知されます。チームメンバーは権限プロンプトを承認したり、あなたに代わって同意を提供したりすることはできません。また、アクションが拒否されたチームメンバーは、チェックをバイパスするために別のチームメンバーにそれをリレーすることはできません。auto mode では、別のエージェントからリレーされた承認クレームは、あなたからの確認ではなく、信頼できない入力として分類器によって扱われます。

「エージェント経由の同意ロンダリング」を封じているわけです。第47回のオートモード分類器がここでも効いています。

そして人間側の運用。**チームメンバーの権限プロンプトはリーダーセッションに表示されるため、そこで自分で承認してください。**唯一の例外が前述のプラン承認で、リーダーセッションはあなたへの別のプロンプトなしにチームメンバープラン承認を付与します。

コンテキストと通信

各チームメンバーは独自のコンテキストウィンドウを持っています。生成されると、チームメンバーは通常のセッションと同じプロジェクトコンテキストをロードします。CLAUDE.md、MCP servers、および skills。また、リーダーからの生成プロンプトを受け取ります。

ただしリーダーの会話履歴は引き継がれません。——ここが実務で一番効きます。リーダーとさんざん議論した内容は、生成プロンプトに書かない限り伝わりません。

共有の仕組みは4つ。自動メッセージ配信（リーダーは更新をポーリングする必要はありません）、アイドル通知（v2.1.198 以降、ターンが API エラーで終了するチームメンバーは、通常に完了したように見えるのではなく、失敗したことをリーダーに通知し、エラーテキストを含めます）、共有タスクリスト、チームメンバーメッセージング。

最後のものには制約があります。**全員に到達するには、受信者ごとに1つのメッセージを送信してください。**ブロードキャストはありません。

名前づけの実務的なコツも書かれています。後のプロンプトで参照できる予測可能な名前を取得するには、生成指示でリーダーに各チームメンバーを何と呼ぶかを指示してください。

subagents との比較表

	Subagents	エージェントチーム
コンテキスト	独自のコンテキストウィンドウ。結果は呼び出し元に返される	独自のコンテキストウィンドウ。完全に独立
通信	メインエージェントにのみ結果を報告	チームメンバーが互いに直接メッセージを送信
調整	メインエージェントがすべての作業を管理	自己調整を伴う共有タスクリスト
最適な用途	結果のみが重要な焦点を絞ったタスク	議論と協力が必要な複雑な作業
トークンコスト	低い：結果がメインコンテキストに要約されて返される	高い：各チームメンバーが個別の Claude インスタンス

判断軸は原文が一言でまとめています。ワーカーが互いに通信する必要があるかどうかに基づいて選択してください。

ユースケース例

**並列コードレビュー。**単一のレビュアーは一度に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 から動作しますが、異なるフィルターを適用します。

**競合する仮説での調査。**こちらはより攻撃的です。

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.

**議論構造はここでの重要なメカニズムです。**そして結論。複数の独立した調査官が互いに積極的に反証しようとしている場合、生き残る理論は実際の根本原因である可能性がはるかに高くなります。

この2例は、エージェントチームでしかできないことを示しています。subagents は互いに反証できません。

ベストプラクティス

**十分なコンテキストを渡す。**生成プロンプトに具体を詰め込む例です。

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人のチームメンバーで開始してください。**理由は3つ——トークンコストは線形にスケール／調整オーバーヘッドが増加／収穫逓減。原文の一文が効いています。3人の焦点を絞ったチームメンバーは、5人の散らばったチームメンバーよりもしばしば優れています。

タスク粒度の目安も具体的です。チームメンバーあたり5〜6個のタスクを持つことで、過度なコンテキストスイッチングなしに誰もが生産的に保たれます。15個の独立したタスクがある場合、3人のチームメンバーが良い出発点です。サイズ感は小さすぎる＝調整オーバーヘッドが利益を超える／大きすぎる＝チェックインなしで長時間動作し、無駄な努力のリスクが増加／ちょうど良い＝関数、テストファイル、またはレビューなど、明確な成果物を生成する自己完結型ユニット。

**リーダーが自分で実装し始めたら。**原文が対処プロンプトを用意しています。

Wait for your teammates to complete their tasks before proceeding

**始め方。**エージェントチームが初めての場合は、明確な境界があり、コードを書く必要がないタスクから開始してください。PR をレビューする、ライブラリを調査する、またはバグを調査します。

**ファイル競合の回避。**第64回でも出た最重要点がここでも繰り返されます。2人のチームメンバーが同じファイルを編集すると、上書きが発生します。作業を分割して、各チームメンバーが異なるファイルセットを所有するようにしてください。——エージェントチームは worktree で分離されないので、この設計は人間の仕事です。

**放置しない。**チームを長時間無人で実行させると、無駄な努力のリスクが増加します。

トラブルシューティング

**チームメンバーが表示されない。**確認順は、パネルを見る → アイドル状態で消えたチームメンバー行は停止されていなく、非表示になっています（チームメンバーに名前でメッセージを送信して、非表示の行を戻してください）→ タスクがチームを必要とするほど十分複雑かを確認 → 分割ペインなら tmux の存在確認。

which tmux

iTerm2 なら**it2 CLI がインストールされ、Python API が iTerm2 の設定で有効になっていること**を確認します。

**権限プロンプトが多すぎる。**チームメンバーを生成する前に、権限設定で一般的な操作を事前承認して、中断を減らしてください。

チームメンバーがエラーで停止する。****チームメンバーはエラーが発生した後、回復する代わりに停止する可能性があります。対処は直接追加の指示を与えるか置き換えチームメンバーを生成する。改善も入っています。v2.1.198 以降、リーダーまたは別のチームメンバーからのメッセージは、失敗した API リクエストの再試行を待機している In-process チームメンバーをウェイクアップするため、完全な再試行遅延を待つ代わりに、すぐに再試行されます。

**リーダーが作業完了前にシャットダウンする。**リーダーは、すべてのタスクが実際に完了する前に、チームが完了したと判断する可能性があります。これが発生した場合は、続行するよう指示してください。

孤立した tmux セッション。

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

制限事項（全9項目）

実験的機能なので、ここは省かず全部挙げます。

In-process チームメンバーでのセッション再開なし：/resume と /rewind は復元しない。リーダーは存在しなくなったチームメンバーにメッセージを送信しようとする可能性があります。
タスクステータスが遅延する可能性：チームメンバーはタスクを完了としてマークできず、依存タスクをブロックすることがあります。
シャットダウンが遅い可能性：現在のリクエストまたはツール呼び出しを完了してからシャットダウンする。
セッションあたり1つのチーム：追加の名前付きチームを作成したり、セッション間でチームを共有したりすることはできません。
ネストされたチームなし：リーダーのみがチームを管理できます。
In-process チームメンバーからのバックグラウンドサブエージェントなし：run_in_background や background: true を要求するとエラーが返されます。理由はチームメンバーのバックグラウンド作業がリーダーのプロセスより長く存在できないため。
リーダーは固定：チームメンバーをリーダーに昇格させたり、リーダーシップを譲渡したりすることはできません。
権限は生成時に設定：生成後に個別変更は可、生成時のメンバー別指定は不可。
分割ペインには tmux または iTerm2 が必要：VS Code の統合ターミナル、Windows Terminal、または Ghostty ではサポートされていません。

なお朗報が1つ。CLAUDE.md は正常に動作します。チームメンバーは作業ディレクトリから CLAUDE.md ファイルを読み取ります。これを使用して、プロジェクト固有のガイダンスをすべてのチームメンバーに提供してください。

4. まとめ＋次回予告

エージェントチームはリーダー1＋チームメンバー複数で、共有タスクリストとメールボックスを通じて互いに直接メッセージを送り合う構成。
実験的機能で既定は無効。****CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を設定するまで、チームは形成されず提案もされない。
**記述は v2.1.178 時点。****TeamCreate / TeamDelete はもう存在しない。**セットアップもクリーンアップも自動。
subagents との選択軸は1つ——**ワーカーが互いに通信する必要があるか。**必要なければ subagents のほうが安く速い。
立ち上げは自然言語だけ。「3人スポーンして、UX・アーキテクチャ・悪魔の代弁者で」と言えば立つ。
モデルは継承しない（/config の Default teammate model で決める）、努力レベルは継承する。
**プラン承認はリーダーが自律的に判断する。**人間に確認は来ないので、承認基準をプロンプトで先に渡す。
権限の抜け道は塞がれている。別エージェントからのリレー承認は信頼できない入力として扱われる。権限プロンプトはリーダーセッションに出るので人間が承認する。
**リーダーの会話履歴はチームメンバーに引き継がれない。**必要な文脈は生成プロンプトに書く。
保存先は**~/.claude/teams/{team-name}/（セッション終了で削除）と ~/.claude/tasks/{team-name}/（残る）。**設定ファイルは手で触らない。
TeammateIdle / TaskCreated / TaskCompleted フックの終了コード2で、休止・作成・完了をそれぞれ止められる。
人数は3〜5人、1人あたりタスク5〜6個が目安。3人の焦点を絞ったチームは、5人の散らばったチームより優れていることが多い。
最大の落とし穴はファイル競合。worktree で分離されないので、縄張りは人間が設計する。
コストは**単一セッションより大幅に多い。**ルーチン作業には向かない。

次回予告（暫定）：第64回で示された4アプローチのうち最後に残った**動的ワークフロー（workflows）を取り上げ、「スクリプトが計画を保持する」**とはどういうことか、コードベース全体の監査や大規模移行での使い方を扱う予定です。