この記事のポイント
Agent Teamsは、Team Leadと複数のTeammatesが独立したコンテキストを持ち、共有タスクリストとMailboxを通じて協調作業を行う機能- 軽量なsubagentsとは異なり、各エージェントが相互にメッセージを送受信し、観点の異なるレビューや並列タスクを実行できる点が特徴
- 表示モードには単一ターミナル内で動作するin-processと、tmuxやiTerm2を用いてペイン分割するsplit panesがあり、用途に応じて選択可能
- 複数のエージェントが稼働するためトークン消費は標準セッションより大幅に増える傾向にあり、チーム規模の抑制やTeammateへの軽量モデル適用が推奨される
- 大規模リポジトリのリファクタリングや多角的なテスト・品質改善など、人間チームでも分業が必要な複雑なタスクにおいて特に効果を発揮する
Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
Claude Code Agent Teamsは、単一のAIセッションによる開発支援を超え、リーダーと複数のTeammateが連携してタスクを遂行する実験的なマルチエージェント機能です。共有タスクリストやエージェント間メッセージングを活用し、実装・テスト・ドキュメント作成といった異なる役割を並列で進行させることが可能になります。
本記事では、Agent Teamsの構成要素やsubagentsとの違い、in-processとsplit panesによる表示モードの使い分けに加え、トークン消費が増大しやすいコスト構造への対策や具体的なセットアップ手順について、2026年2月時点の情報を基に体系的に解説します。
目次
Agent Teamsの有効化設定（環境変数／settings.json）
teammateMode設定とtmux／iTerm2によるペイン分割
Claude Code Agent Teamsとは？
Claude Code Agent Teamsは、複数のClaude Codeセッションを「チーム」として協調動作させるための実験的機能です。1つのセッションがリーダー（Team Lead）となり、複数のTeammateにタスクを割り振り、それぞれの結果を統合します。
従来のClaude Codeは「1つのセッション＝1人のAIペアプロ」として振る舞うのが基本でした。Agent Teamsでは、これを**「1人のプロマネ＋複数の専門エンジニア」構成に拡張したイメージ**になります。リーダーが全体方針とタスク分割を行い、Teammateがそれぞれの観点で実装や調査を進める前提です。
公式ドキュメント上では、チームは「共有タスクリスト」「エージェント間メッセージング」「中央管理」を軸に、複数セッションを連携させる仕組みとして説明されています。
Agent Teamsでできること・構成要素
ここでは、Agent Teamsを構成する主要コンポーネントと、その役割を整理します。イメージとしては、1つのプロジェクトルームの中で、リーダーと複数メンバーが共有ToDoとチャットを使って作業する構造です。
リーダー／メンバー／タスクリスト／メッセージング
Agent Teamsは、次の4つの要素で構成されます。
まず、構成要素の関係を表形式で整理します。
| コンポーネント | 役割・概要 |
|---|---|
| Team Lead（リーダー） | チームを作成し、タスクを定義・割当し、結果を統合するメインのClaude Codeセッション。 |
| Teammates（メンバー） | それぞれが独立したClaude Codeセッションとして動作し、固有のコンテキストでタスクを実行する。 |
| Shared Task List（共有タスクリスト） | 全メンバーが参照するタスクリスト。状態（pending / in progress / completed）と依存関係を扱える。 |
| Mailbox（メッセージング） | エージェント間のメッセージング機構。質問、レビュー依頼、成果物共有に利用される。 |
タスクリストは、「何を」「誰が」「どの順番で」やるかを明示する役割を持ちます。依存関係があるタスクは、依存が解決するまで要求（claim）できない設計です。
Mailboxは、Agent Teamsの中核です。Teammate同士で直接やり取りできるため、たとえば**「テスト担当が実装担当にフィードバック」「ドキュメント担当がコード担当に不明点を質問」**といった相互作用が自然に行えます。
in-process／split panes表示モード
Agent Teamsでは、ターミナル上での表示モードとしてin-processとsplit panesの2種類が提供されています。
どちらを使うかで、メンバーの出力の見え方や操作性が変わります。
次のような違いがあります。
| モード名 | 概要 | 主な要件・制約 |
| :--- | :--- |
| in-process | 1つのターミナル内で全Teammateが動作し、選択して直接話せるモード。 | 追加要件なし。どのターミナルでも動く。 |
| split panes | Teammateごとに別ペインで表示して、全員の出力を同時に見られるモード。 | tmux または iTerm2 が必要。VS Code統合ターミナル等では非対応。 |
in-processでTeammateに話しかける操作は、公式ドキュメントでは次のように整理されています。
- Shift+Up/Down：Teammateの選択
- そのまま入力：選択中Teammateへメッセージ送信
- Enter：Teammateのセッションを表示
- Escape：Teammateの現在ターンを中断
- Ctrl+T：タスクリスト表示の切り替え
Delegate（調整役）モードとPlan-first実行
Agent Teamsには、リーダーを**「調整役専任」にするDelegateモードと、実装前に必ず計画承認を挟むPlan Approval（Plan-first）**が用意されています。
-
Delegateモード
リーダーが自分ではコードを書かず、Teammateのスポーンやタスクの割り当て・再配分、メッセージングのハブといった、「プロジェクトマネジメント」業務だけを担うモードです。 -
Plan Approval（Plan-first）
Teammateがまず計画（Plan）だけを提示し、承認されるまで実装に進まないようにできます。これにより「方向性のズレた実装が大量に走る」リスクを抑えられます。
Agent Teamsと他機能との違い
次に、Agent TeamsをClaude Code内の他機能や、他社のマルチエージェント機能と比較し、どのような位置づけで捉えるとよいかを整理します。
subagentsとの違い・使い分け
Claude Codeのsubagentsは、軽量な分担を行う際に適した機能です。Agent Teamsとの違いを、観点別に整理すると次のようになります。
| 観点 | subagents | Agent Teams |
|---|---|---|
| スコープ | 単一セッション内での子エージェント。 | 複数セッション（リーダー＋複数Teammate）での協調作業。 |
| コンテキスト | 親から必要な情報だけ受け取り、要約を返す。 | 各Teammateが独立のコンテキストウィンドウを持つ。 |
| コミュニケーション | 親への報告が中心。 | Teammate同士が直接メッセージをやり取りできる。 |
| 典型的な用途 | ログ要約、テスト実行、ドキュメント検索など「結果だけ欲しい」タスク。 | 観点の異なるレビュー、仮説の並列検証など「調整」が必要なタスク。 |
| コスト | 比較的低い（要約中心）。 | メンバー数と稼働時間に比例して増えやすい。 |
「結果だけ教えてほしい」ならsubagents、「複数エージェントに役割分担させたい」ならAgent Teamsという整理にしておくと、選択がしやすくなります。
シングルエージェント運用との違い
通常のClaude Codeセッションでも、plan modeを活用することで計画立案と実装は行えます。ただし、以下のような点でAgent Teamsとは性質が異なります。
- 単一セッションでは、同じエージェントが観点を切り替えながら順番に見る。
- Agent Teamsでは、セキュリティ／パフォーマンス／テストなどの観点を別々のTeammateに割り当てて並列に検証できる。
- シングルセッションはコンテキストの連続性を重視する一方、Agent Teamsは各Teammateが独立した視点で動ける。
そのため、Agent Teamsは「1本のPRを複数観点からレビューする」「大規模な変更で複数レイヤーを同時に触る」といった、人間でもレビューアを複数人アサインするケースで真価を発揮します。
Agent Teamsの料金
Agent Teamsは、強力である一方、トークンコストが大きくなりやすい機能でもあります。このセクションでは、料金の考え方と既知の制限、コストを抑えるための方針を整理します。
課金モデルとトークン消費の傾向（標準セッション比）
Claude Codeは、Claudeのサブスクリプション（Pro／Max／Teams／Enterprise）またはClaude Console等のAPI課金に基づいて利用します。
Agent Teams専用の「別サブスク」があるというより、複数セッションが並列稼働するぶんトークン消費が増えるのが本質です。
公式の「Manage costs effectively」では、Agent TeamsはTeammateが plan mode で動く場合、標準セッションよりおおよそ7倍トークンが増え得る、という目安が示されています（※Teammateごとに独立したコンテキストを持つため）。
実験機能としての制限
Agent Teamsはプレビュー機能のため、デフォルトでは無効となっています。既知の制限として、公式ドキュメントでは概ね次の点が挙げられています。
| 項目 | 内容 |
|---|---|
| 再開（in-process） | in-processのTeammateは「/resume」や「/rewind」で復元されない （再開後は再スポーンが必要になる場合がある）。 |
| タスク状態の反映 | タスク状態の反映が遅れることがある （完了扱いにならず依存タスクがブロックされる等）。 |
| シャットダウン | シャットダウンが遅くなることがある （現在処理中の呼び出しが終わってから終了する）。 |
| 同時チーム数 | 1セッションあたり同時に管理できるチームは1つ （新しいチームはクリーンアップ後）。 |
| ネスト | ネストしたチームは不可 （Teammateは自分のチーム/Teammateを作れない）。 |
| split panes要件 | split panes は tmux / iTerm2 が必要。 VS Code統合ターミナル等では非対応。 |
Agent Teamsのユースケース
ここからは、Agent Teamsをどのような場面で使うと効果的かを具体的なユースケースで見ていきます。どれも「人間チームでも分業することが多い」タイプのタスクです。
大規模リポジトリの調査・リファクタリング
モノレポや長年育ってきたプロダクトでは、「どこをどう変えるべきか」を把握するだけでも一苦労です。このようなケースで、Agent Teamsは次のような使い方ができます。
- リーダー：リポジトリ全体のゴールと制約を把握し、タスクを分解する。
- Teammate A：アーキテクチャと依存関係の分析担当。
- Teammate B：ボトルネックや重複コードの検出担当。
- Teammate C：互換性・影響範囲の確認担当。
タスクリストを介して観点ごとの結果を集約することで、**「どこから手を付けるべきか」「影響範囲がどこまでか」**を短時間で整理できます。
テストコード生成・品質改善タスクの分担
テストコードの整備や品質改善タスクも、Agent Teamsと相性の良い領域です。
- リーダー：対象モジュール・優先度・完了条件を定義。
- Teammate A：ユニットテストの追加・補完。
- Teammate B：統合テスト・E2Eテストの整備。
- Teammate C：リンタ・静的解析結果の対応。
Mailboxでレビュー依頼や差分の相談を回し、リーダーが統合する流れにすると扱いやすくなります。
ドキュメント整備・ナレッジベース構築
コードだけでなく、ドキュメント整備にもAgent Teamsは使えます。
- Teammate A：既存README/設計書を読み込み、構造や不足箇所を洗い出す。
- Teammate B：docstringやコメントの生成を担当する。
- Teammate C：チュートリアルやクイックスタート草案を作る。
リーダーは、各Teammateからの成果物を統合し、最終アウトプットの一貫性を担保します。
エージェント基盤（MCP／skills等）との組み合わせ
Claude Codeは、MCPやskills／hooksによって外部システムと連携できます。Agent Teamsはこれらと組み合わせることで、より多様なユースケースに広がります。
- Teammate A：Issue管理（例：GitHub Issues）からチケット一覧を取得し、優先度整理。
- Teammate B：デザイン仕様やUI要件を元にフロント実装方針を検討。
- Teammate C：ログ/監視からエラーパターンを集計し、改善案を作る。
Agent Teamsのセットアップ方法
ここからは、Agent Teamsを実際に使い始めるためのセットアップ手順を、できるだけ具体的に整理します。
前提環境（Claude Code・サブスクリプションなど）
Agent Teamsを利用するには、まずClaude Code自体が動作している必要があります。
- 対応OS：macOS／Linux／Windows（WSL含む）
- インストール方法：
- macOS／Linux／WSL：
curl -fsSL https://claude.ai/install.sh | bash - Windows PowerShell：
irm https://claude.ai/install.ps1 | iex
- macOS／Linux／WSL：
- 必要なアカウント：
- Claudeのサブスクリプション（Pro／Max／Teams／Enterprise）またはClaude Console等
既にターミナルで「claude」コマンドが動作し、通常のClaude Codeセッションを開始できている状態であれば、Agent Teamsの準備に進めます。
Agent Teamsの有効化設定（環境変数／settings.json）
Agent Teamsはデフォルトでは無効化されており、明示的に有効化フラグを設定する必要があります。「~/.claude/settings.json」に環境変数を追加します。
// ~/.claude/settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
設定を追加したら、Claude Codeを再起動（またはターミナルセッションを再起動）して反映させます。
teammateMode設定とtmux／iTerm2によるペイン分割
表示モードは「in-process / split panes」の2種類ですが、設定キー 「teammateMode」の値は 「auto / in-process / tmux」 です（※「split-panes」という値は設定としては使いません）。
- teammateModeの設定例
// ~/.claude/settings.json
{
"teammateMode": "auto" // "in-process" または "tmux" も指定可能
}
"auto"：tmux内なら split panes、それ以外は in-process。"in-process"：常に in-process。"tmux"：split panes を有効化し、端末に応じて tmux / iTerm2 を自動判定する。
- tmuxの例（macOS）
brew install tmux
tmux new -s my-session
claude
tmuxセッション内でAgent Teamsを起動すると、Teammateごとにペインが割り当てられ、各エージェントの出力を同時に監視しやすくなります。
Agent Teamsの基本的な使い方
セットアップが完了したら、実際にAgent Teamsをどのように操作するかを見ていきます。ここでは、概念レベルに留めます。
チームの作成と役割設計（プロンプト設計のポイント）
Agent Teamsの起点になるのは、「どのロールのTeammateを何人用意するか」という設計です。
典型的なプロンプト例は次のようなイメージです。
このリポジトリの新機能Xを実装するAgent Teamを作りたいです。
- Team Lead: 全体設計とタスク分解、進捗管理を担当
- Teammate 1: バックエンド実装担当
- Teammate 2: フロントエンド実装担当
- Teammate 3: テストコードとドキュメント整備担当
それぞれの役割と完了条件を決め、共有タスクリストを作ってください。
ポイントは、ロールの責任範囲と成果物、チーム全体のゴール/制約を明確にすることです。
タスクリストの追加・ステータス管理・依存関係
チームが立ち上がると、共有タスクリストを使って作業を調整します。タスクには「pending / in progress / completed」の状態があり、依存関係を持たせることもできます。
【運用イメージ】
- リーダーがタスクを作成し、担当Teammateを割り当てる（または自己要求を許可する）。
- Teammateが作業を進め、完了したらタスクを完了にする。
- 依存タスクがある場合、依存が完了するとブロックが解除される。
メンバー間メッセージングと（タスク要求の）ファイルロック
Mailboxを使うと、Teammate同士で次のようなやり取りができます。
- 実装担当からテスト担当への「この仕様でテストケースを設計してほしい」という依頼。
- ドキュメント担当から実装担当への「このパラメータの型と制約を確認したい」という質問。
- 各Teammateからリーダーへの進捗報告やリスク共有。
また公式ドキュメントでは、タスクの「要求（claim）」処理が、同一タスクを複数Teammateが同時に要求しようとした場合の競合（レースコンディション）を防ぐために、ファイルロックを使う旨が説明されています。
チーム設定の保存・再利用とクリーンアップ
チームとタスクはローカルに保存されます。公式ドキュメントでは、代表例として次が示されています。
- Team config：~/.claude/teams/{team-name}/config.json`
- Task list：
~/.claude/tasks/{team-name}/
頻出するチーム構成をテンプレとして再利用する運用もできますが、作業が終わったら シャットダウン → クリーンアップ の順で後始末するのが安全です。
Claude Code Agent Teamsのよくある質問
利用可能な環境（OS・エディタ・アカウント種別など）
Q. Agent Teamsはどの環境で利用できますか？
A. Agent TeamsはClaude Codeの機能であり、Claude Codeが動作する環境が前提です。表示モードのうち split panes は tmux / iTerm2 が必要で、VS Code統合ターミナル等ではサポートされない点に注意が必要です。
また、サブスクリプションまたはAPI課金の前提があるため、無料利用だけで本格運用するのは現実的ではありません。
チーム人数・タスク数の実用的な上限目安
Q. 1つのチームにどのくらいのTeammateを入れるのが現実的ですか？
A. 公式に「人数上限の目安」が固定で示されているわけではありませんが、Teammate数と稼働時間に応じてコストが増えるため、まずは少人数で始め、並列化の効果が出る範囲を見極めるのが現実的です。
タスク数も、依存関係が複雑になりすぎない粒度で管理し、必要ならラウンドを分けて回すのが扱いやすいです。
subagentsや他ツールとの併用可否
Q. Agent Teamsとsubagents、他社エージェントツールは併用できますか？
A. 併用は可能ですが、実務上は次のような使い分けが現実的です。
- 同一リポジトリ内の軽量タスク：subagents（結果要約中心）。
- 観点の異なるレビューや大規模改修：Agent Teams（役割分担＋調整）。
- 非コード領域も含む広範な自動化：必要に応じて別の基盤を併用。
重要なのは、「どこまでをClaude Codeの責務にし、どこからを別基盤に任せるか」をあらかじめ決めることです。
まとめ
最後に、Claude Code Agent Teamsのポイントを振り返ります。
Claude Code Agent Teamsは、次のような理由で「並列化の効果」を出しやすい機能です。
- リーダー＋複数メンバーの構成で、調査・設計・実装・レビューなどを同時進行で回せる。
- 各メンバーが独立したセッション（コンテキスト）を持ち、タスクリストとメッセージングでゆるく連携できる。
- subagents（単一セッション配下）と比べて、役割分担と並列作業の自由度が高く、大きめのタスク分割に向く。
一方で、Agent Teamsは「実験的機能」という前提があるため、最初から本番の中核に据えるより、PoC〜限定運用で“使いどころ”を見極めるのが現実的です。
- 複数エージェントが同時に動く分、トークン消費や待ち時間が増えやすく、チーム人数とタスク粒度の設計が成果に直結する。
- 重要な操作（マージ、デプロイ、削除など）は、人間の承認ポイントを置いてガードレールを作るほうが安全。
- 後処理（shut down → clean up）まで含めて運用を決めておくと、チームの“後始末漏れ”が起きにくい。
まずは3〜4人規模の小さなチームで、「リポジトリ調査」「設計案作成」「テスト観点の洗い出し」など、独立しやすい作業に限定して試すのがおすすめです。
そこで得た成功・失敗パターンをもとに、標準のチーム構成やプロンプトを固めていけば、導入コストが完全な“サンクコスト”になりにくく、再現性のある使い方に寄せられます。
