エージェントチームのコントロール

問題: Claude Code エージェントチームを有効にして最初のチームが動き始めたものの、リードが委任せずに自分で作業してしまう。チームメンバーが同じファイルを編集する。誰が実際に何をしているか見えない。これらの問題を解決するコントロールはすべて存在します。ただし、最初から分かりやすい場所にはありません。

クイックウィン: チームを起動した直後に Shift+Tab を押してデリゲートモードに切り替えます。リードはコードに触れなくなり、コーディネーションに集中します。

注意: このガイドはエージェントチームの概要と対になっています。まだチームを設定していない場合は先にそちらをお読みください。

表示モード

エージェントチームには、チームメンバーの監視と操作方法を変える 2 つの表示モードがあります。

インプロセスモード（デフォルト）

すべてのチームメンバーがメインターミナル内で動作します。キーボードショートカットで切り替えます。

どのターミナルでも動作します。追加のセットアップや依存関係は不要です。一度に一人のチームメンバーの出力を確認し、必要に応じて切り替えます。ほとんどのワークフローでインプロセスモードで十分です。

スプリットペインモード

各チームメンバーが専用のターミナルペインを持ちます。全員の出力を並べて確認でき、任意のペインをクリックして直接操作できます。複数のチームメンバーが難しい問題に同時に取り組む様子を見たい場合に便利です。

スプリットペインモードには tmux または iTerm2 が必要です。macOS では、iTerm2 内の tmux -CC が推奨される起動方法です。重要: スプリットペインモードは VS Code の統合ターミナル、Windows Terminal、Ghostty ではサポートされていません。tmux は一部の OS で互換性の問題があり、macOS で最も安定して動作します。

settings.json でお好みのモードを設定します。

3 つのオプション:

• "auto"（デフォルト）は、すでに tmux 内にいる場合はスプリットペインを使用し、そうでなければインプロセスにフォールバック
• "tmux" はスプリットペインを有効にし、tmux または iTerm2 内にいるかを自動検出
• "in-process" はすべてをメインターミナルに強制

セッションごとに CLI フラグで上書きできます。

デリゲートモード

デリゲートモードなしでは、リードがチームメンバーに割り当てたタスクを自ら始めてしまうことがあります。それは本来の目的を損ないます。コーディネートするよう指示したのに、工具を手に取って自分で作り始めてしまうわけです。

チームを起動した後、Shift+Tab を押してデリゲートモードに切り替えます。これによりリードはコーディネーション専用ツールのみ使用できるようになります: チームメンバーのスポーン、メッセージング、シャットダウン、タスク管理。リードはコードに直接触れられなくなり、オーケストレーションに専念します。

チームメンバーが個別の貢献者ではなくプロジェクトマネージャーとして行動してほしい場合にデリゲートモードを使います。4 人以上のチームメンバーがいる大規模なチームで特に重要です。リードの役割がすべてコーディネーションになるからです。実際に 4 人以上のチームメンバーセッションでデリゲートモードをオンにすると、リードの無駄なコンテキスト消費が目に見えて減少し、リードが自分のチームメンバーと作業を取り合うことがなくなります。

チームメンバーがまだ作業中なのにリードが先走っている場合は、直接伝えることもできます: 「チームメンバーがタスクを完了するまで待ってください」。自然言語での指示が効く場合もあります。ただし、セッションを通じて一貫した動作を確保するには、デリゲートモードが制約を自動的に強制します。

プラン承認ワークフロー

複雑またはリスクの高いタスクでは、チームメンバーに実装前にプランを立てるよう要求します。チームメンバーはリードがアプローチをレビューして承認するまで読み取り専用のプランモードで作業します。

ワークフロー:

1. チームメンバーがタスクを受け取り、読み取り専用モードに入る
2. チームメンバーがプランを作成し、リードにプラン承認リクエストを送信
3. リードがプランをレビューし、承認またはフィードバック付きで却下
4. 却下された場合、チームメンバーはプランモードのまま修正して再提出
5. 承認されると、チームメンバーはプランモードを終了して実装を開始

リードは自律的に承認判断を行います。最初のプロンプトを通じてその判断基準を設定します。「テストカバレッジを含むプランのみ承認」や「マイグレーションなしにデータベーススキーマを変更するプランは却下」と伝えます。リードは受け取るすべてのプランにこれらのルールをフィルターとして適用します。

プランモードは、チームメンバーが共有インフラを作業している場合、データベーススキーマに触れている場合、または複数ファイルにわたって変更を巻き戻すコストが高い場合に特に有効です。プランのコストは、悪い実装をロールバックするコストのほんの一部です。プラン承認が構造化された計画フェーズにどう組み込まれるかについては、エンドツーエンドのワークフローをご覧ください。

品質ゲートのためのフック

エージェントチームは自動品質チェックのために Claude Code のフックシステムと連携します。チームワークフロー専用に 2 つのフックが組み込まれています。

TeammateIdle: チームメンバーがアイドル状態になろうとするときに実行されます。コード 2 で終了するとフィードバックを送信し、チームメンバーの作業を継続させます。フォローアップタスクの自動割り当てや、早期に終了したチームメンバーのリダイレクトに使います。他のメンバーがまだ作業中にチームメンバーが主タスクを完了した場合、TeammateIdle フックを使えば手動の操作なしにレビュー作業やクリーンアップタスクをルーティングできます。

TaskCompleted: タスクが完了としてマークされようとするときに実行されます。コード 2 で終了すると完了をブロックしてフィードバックを送信します。品質ゲートを強制するために使います: テストのパス、リントチェックの成功、特定の受け入れ基準の達成を、タスクがクローズされる前に要求します。

これらのフックを使えば、すべてのチームメンバーを手動で監視することなく構造化された品質ゲートを構築できます。テストスイートを実行する TaskCompleted フックは、どのチームメンバーがコードを書いても、壊れたテストがあるタスクをクローズさせません。フックシステムの全体的なウォークスルーと設定については、フックガイドをご覧ください。

チームメンバーへの直接メッセージ

各チームメンバーは完全な独立した Claude Code セッションです。リードを経由せずに任意のチームメンバーに直接メッセージを送れます。

インプロセスモード: Shift+Up/Down でチームメンバーを選択し、入力して送信します。Enter を押してチームメンバーの完全なセッションを表示し、これまでの作業内容を確認します。チームメンバーが間違った方向に進んでいる場合は Escape で現在のターンを中断します。

スプリットペインモード: チームメンバーのペインをクリックしてそのセッションと直接操作します。各ペインはスタンドアロンの Claude Code セッションとまったく同じように動作します。

特定のチームメンバーをリダイレクトしたい場合、リードが持っていない追加のコンテキストを提供したい場合、または的を絞ったフォローアップ質問をしたい場合に便利です。コーディネーターを経由するよりも、直接ワーカーに話しかける方が早い場合もあります。

タスク管理

共有タスクリストは、チーム全体のすべての作業を調整します。リードがタスクを作成し、チームメンバーがそれをこなしていきます。タスクには pending（保留中）、in progress（進行中）、completed（完了） の 3 つの状態があります。タスクには依存関係を設定できます。未解決の依存関係を持つ保留中のタスクは、それらが完了するまでクレームできません。これはチームオーケストレーションの依存チェーンパターンを反映しています。

リードはタスクを特定のチームメンバーに明示的に割り当てることも、チームメンバーが利用可能なタスクを自由にクレームすることもできます。タスクを完了した後、チームメンバーは次の未割り当てでブロックされていないタスクを自律的に選択します。この自己クレーム動作により、リードの常時介入なしにチームが動き続けます。

タスクのクレームではファイルロックを使って、2 人のチームメンバーが同時に同じタスクを取り合う競合状態をブロックします。システムはタスクの依存関係を自動的に処理します: チームメンバーが他のタスクが依存するタスクを完了すると、ブロックされたタスクは手動操作なしにアンブロックされます。依存関係を待っていたチームメンバーは、その依存関係が解決された瞬間に作業を開始します。

タスクコーディネーションパターンについては、タスク分散と todo ワークフローをご覧ください。

チームサイズとモデルの選択

Claude はタスクの複雑さに基づいてチームメンバーの数を選択しますが、明示的に指定することもできます。

単一チーム内でモデルを混在させることもできます。戦略的コーディネーションのためにリードを Opus で、スコープを絞った実装のためにチームメンバーを Sonnet で動かします。これによりコストと能力のバランスをとります。リードはタスクの分解とプラン承認に強力な推論能力が必要です。スコープを絞った実装作業を行うチームメンバーは、多くの場合、コストのほんの一部で Sonnet で十分です。

コーディネーション重視のフェーズでさらにリードの応答を速くするには、エージェントチームとファストモードを組み合わせます。

トークンコストの管理

エージェントチームは単一セッションよりも大幅に多くのトークンを消費します。各チームメンバーが独自のコンテキストウィンドウを持ち、トークン使用量はアクティブなチームメンバー数に比例します。チームメンバーが実装前にプランモードで動作する場合、そのフェーズでは標準セッションの約 7 倍のトークンが必要です。

トークンの内訳:

• 各チームメンバーがプロジェクトコンテキスト（CLAUDE.md、スキル、プロジェクトファイル）を独立してロード
• コミュニケーションのコスト: エージェント間のすべてのメッセージが送信者と受信者両方のコンテキストを消費
• ブロードキャストはメッセージを受信するチームメンバー数だけコストを倍増させる
• リードはコーディネーション、タスク管理、結果の統合にトークンを消費

コストが見合う場合:

• 複数の視点が単一パスでは見逃す問題を発見できる調査やレビュータスク
• 並行仮説テストが順次的な推測より早く問題を解決するデバッグセッション
• 時間の節約がトークンの支出を正当化できる大規模な機能実装
• 徹底的な評価が後の高コストなミスを防ぐアーキテクチャの決定

コストを抑える場合:

• スコープを絞った実装作業を行うチームメンバーには Sonnet を使い、Opus はリードに残す
• 可能であればブロードキャストより直接メッセージを優先
• チームサイズをタスクが実際に必要とするものに限定（3 人の方が 6 人より良いことが多い）
• エージェント間通信が不要なルーティンタスクにはサブエージェントや単一セッションを使用
• 不必要な探索を防ぐために各チームメンバーに明確なスコープを設定

おおよその目安: 30 分稼働する 3 人チームは、同じ作業を順次行う単一セッションの約 3〜4 倍のトークンを消費します。トレードオフはスピードとカバレッジ対コストです。

チーム向け CLAUDE.md の最適化

すべてのチームメンバーは起動時に新鮮なコンテキストウィンドウで CLAUDE.md を読み込みます。リードの以前の会話は引き継がれないため、チームにとって CLAUDE.md の質が非常に重要です。CLAUDE.md が曖昧であれば、各チームメンバーは独自にコードベースを探索してトークンを無駄にします。3 人のチームメンバーが同時にコンテキストをロードする場合、そのコンテキストが素早い読み取りではなく探索に費やされると 3 倍のトークンコストになります。

3 つのルールでエージェントチームの効果が目に見えて向上します。

ルール 1: モジュール境界を記述する

CLAUDE.md でのモジュール境界が明確であるほど、Claude がチームメンバー間での作業分割をスマートに行えます。表を使います。

「チームを作成してファイルオーナーシップで分割」と伝えると、Claude は構造を読み取って各チームメンバーに明示的なファイルリストを割り当てます。コンフリクトはゼロになります。

ルール 2: プロジェクトコンテキストを短く実用的に保つ

スタック、エントリーポイント、テストコマンド、データベース。短い読み物であって、探索ではありません。

「このプロジェクトは何か」や「ファイルはどこにあるか」をリードに尋ねるチームメンバーがいてはなりません。「どのフレームワークか?」という一往復は、チームメンバーのコンテキストにもリードが答える際のコンテキストにもトークンを消費します。

ルール 3: 「検証済み」の意味を定義する

CLAUDE.md に動作確認の方法がリストアップされていれば、チームメンバーはリポートする前にそれらのシグナルを使って自己検証します。

Claude はタスクごとに検証を適応させます。クリーンアップタスクでは、チームメンバーが grep で削除を確認することがあります。機能追加ではテストスイートを実行します。プロジェクト全体のゲートがあれば、リードが自動的に適用できる「完了」の語彙が生まれます。

CLAUDE.md に明確なルールがあれば、チームメンバーはリードの介入なしに自分がやったことを正確に自己報告します。明確なルールを入れれば、明確なレポートが出てきます。プロジェクトファイルの整え方については、CLAUDE.md マスタリーをご覧ください。

まとめ

エージェントチームを効果的に運営するためのコントロールが揃いました。次のチームセッションでデリゲートモードから始めて、リードの動作がどう変わるか体感してください。TaskCompleted フックを追加してテストスイートを強制します。CLAUDE.md にモジュール境界を書いて、Claude に作業を自動分割させます。

コピーして使えるプロンプトについては、エージェントチームのユースケースとプロンプトテンプレートをご覧ください。よくある問題とトラブルシューティングについては、エージェントチームのベストプラクティスをご覧ください。これらのコントロールをまとめた完全なエンドツーエンドワークフローについては、エンドツーエンドワークフローガイドをご覧ください。