Claude Codeエージェントチーム - 設定からショートカットまで

Claude Codeエージェントチームは、Opus 4.6のリリースと同時に提供が開始されました。正直なところ、現段階ではこの機能は効率的とは言い難い状況です。トークン消費が大きく、エージェント間の調整にかかるオーバーヘッドも無視できません。

しかし、Tom (@tomcrawshaw01) 氏のガイドを読んで認識が変わりました。アーキテクチャそのものは理解しておく価値があります。プレビュー段階で使い方を把握しておけば、正式リリース時に確実に差がつきます。

単独エージェントがチームを構築する

リードエージェントがタスクを分解し、並列で動作する複数のチームメイトに作業を分配します。

サブエージェントとの根本的な違いは、チームメイト同士が直接メッセージをやり取りできる点です。単にリードに結果を報告するだけでなく、発見した情報を共有し、互いの作業に対して指摘を行うこともあります。

セットアップは30秒で完了する

この機能は実験的であり、デフォルトでは無効になっています。1行追加するだけで有効化できます。

settings.jsonのenvブロックにCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSを値"1"で追加します。シェルの環境変数として設定することも可能ですが、settings.jsonに記述すればセッションをまたいで永続化されるため、より実用的です。

覚えるべきショートカットは少ない

チームが稼働し始めたら、リードとチームメイトを切り替えながら進捗を確認します。覚える操作は多くありません。

• Shift+Up / Shift+Down - チームメイトの切り替え（インプロセスモード。最も頻繁に使用する操作）
• Enter - 選択中のチームメイトのセッション詳細を表示
• Escape - 選択中のチームメイトの現在のターンを中断
• Ctrl+T - 共有タスクリストの表示/非表示を切り替え
• Shift+Tab - Delegateモードの切り替え。リードをコーディネーション専任にし、自らコードを書かせない
• Split-paneモード - チームメイトのパネルをクリックして直接操作

Delegateモードは重要です。これを有効にしないと、リードがチームメイトに委任せず自分でコードを書き始めることがあります。

ターミナルの互換性に差がある

Split-paneモードはtmuxとiTerm2でのみ動作します。VS Codeの統合ターミナル、Windows Terminal、Ghosttyは公式にはサポート対象外です。

Ghosttyを使用している場合は、デフォルトのインプロセスモードでShift+Up/Downによるチームメイト切り替えを使用することになります。

チームメイトの出力を並べて確認したい場合は、tmuxセッション内でClaude Codeを起動します。デフォルトのteammateModeは"auto"であり、tmuxを検出すると自動的にSplit-paneモードに切り替わります。

私自身は、iTerm上でtmux new -s {my-project}を実行してからclaude --teammate-mode tmuxで起動しています。これにより、チーム全体の活動をフルスクリーンで確認できます。

タスクの流れ

作業はタスクリストを中心に管理されます。リードがタスクを作成し、チームメイトがそれを引き受けます。

• リードがタスクリストを作成すると、チームメイトは次の未割り当てタスクを自動的に取得する
• タスク間の依存関係がサポートされており、先行タスクが完了して初めて後続タスクが解放される
• リードに指示することで、特定のタスクを特定のチームメイトに割り当てることが可能
• チームメイトのシャットダウンにはプロトコルがある。リードがシャットダウン要求を送信し、チームメイトが確認した後、終了する
• 完全なクリーンアップ手順：すべてのチームメイトがシャットダウンしたことを確認した上で、リードにクリーンアップを指示する

「チーム」という言葉を含む簡単なプロンプトで機能は自動的に起動します。しかし、より精密な制御が必要な場合は、チームメイトの総数を定義し、各メンバーに名前と役割を割り当て、委任範囲を設定し、タスク間の依存ルールを記述した外部ファイルを指定します。

トークン消費は想像以上に早い

各チームメイトは独立したClaude Codeセッションです。並列実行すればコストは急速に増大します。いくつかの対策が有効です。

• チームメイトに対して具体的なスポーンプロンプトを記述する。リードの会話履歴は引き継がれず、CLAUDE.mdとMCPサーバーのコンテキストのみが自動的に読み込まれる
• 2つのチームメイトが同一ファイルを編集すると上書きが発生する。作業はファイル単位で分割する
• コード生成ではなく、リサーチやコードレビューから始める。その方が調整の複雑さが低い
• タスクの単位は小さく具体的に保つ。単一の関数や単一のテストファイルが適切な粒度である

事前に知っておくべき制約

これはプレビュー版です。荒削りな部分があるのは想定通りです。事前に把握しておくことで、不要なストレスを回避できます。

• /resumeや/rewindを使用すると、インプロセスのチームメイトが終了する。リードに新しいチームメイトの生成を指示する必要がある
• タスクのステータス反映にラグが生じることがある。チームメイトが作業を完了してもタスクを完了にマークしない場合、後続タスクがブロックされたまま残る。手動で確認し、リードに更新を依頼する
• 1セッションにつき1チームまで。チームメイトがサブチームを作ることはできない
• チームを作成したセッションがリードとして固定される。リーダーの交代やチームメイトの昇格はセッション中にできない

プレビュー版は荒削りであり、コスト効率の問題も未解決のままです。しかし、マルチエージェントワークフローがどこに向かっているのかを理解したいのであれば、最も確実な方法は自分で有効にして試すことです。ツールは実際に触ってみなければ、正しく評価することはできません。