この記事で分かること
「Claude CodeにAgent Teamsという新機能が追加されたが、Subagentsと何が違うのか分からない」——そんな声が開発者の間で増えています。
両者はどちらも複数のAIエージェントを活用する仕組みですが、通信モデル・適したユースケース・トークンコストが大きく異なります。誤った選択は、予算の数倍ものトークン消費や、並列作業のメリットを活かせない非効率な開発につながりかねません。
この記事では、Agent TeamsとSubagentsの構造的な違いを整理したうえで、「自分のプロジェクトではどちらを使うべきか」を判断するための3つの軸と、Agent Teams運用の要となるCLAUDE.mdの設計パターンを解説します。
Claude Codeを日常的に使うエンジニアやテックリードの方に、実務で迷わない判断軸を持ち帰っていただける内容です。
Claude CodeのAgent TeamsとSubagentsとは
Claude Codeには、AIエージェントを複数使って作業を並列化する仕組みが2種類あります。それがSubagentsとAgent Teamsです。いずれも単一のClaude Codeセッションで複数のエージェントを動かせる点では共通していますが、通信モデルと得意なタスクの種類が根本的に異なります。
Subagentsとは—単発タスクの「手足」
Subagentsは、メインエージェント（オーケストレーター）が子エージェントにタスクを投げ、子エージェントが実行結果を報告するという一方向の委任モデルです。Claude Code 1.0の段階からビルトインで利用でき、追加設定なしで動作します。
ファイルを横断的に調査する・ドキュメントを読んでまとめる・ユニットテストを一括実行するといった互いに独立したタスクに向いています。子エージェント同士は直接通信せず、あくまでオーケストレーターへの報告のみを行います。
Agent Teamsとは—協調する「開発チーム」
Agent Teamsは、Team Lead（メインセッション）と複数のTeammates（独立したClaude Codeインスタンス）が、共有タスクリストとメールボックスを通じて双方向に通信しながら開発を進める仕組みです。
2025年に実験的機能（Research Preview）として追加され、環境変数1行で有効化できます。
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1コンポーネント実装・テスト作成・型定義のように、互いが参照し合うタスクを並列で処理することが最大の強みです。ファイル競合もロック機構で自動回避されます。
Agent TeamsとSubagentsの構造の違い
両者の本質的な違いは「エージェント間の通信方向」にあります。この違いが、適したユースケースを大きく分けます。
Subagentsの通信モデル—一方通行の報告
Subagentsはオーケストレーター（メインエージェント）から各子エージェントへの一方通行の委任構造をとります。子エージェントは割り当てられたタスクを独立して実行し、完了したらオーケストレーターへ結果を報告するだけです。
子エージェント同士は互いの存在を知らないため、あるエージェントの出力が他のエージェントの入力になるような依存関係のある作業には向きません。
Agent Teamsの通信モデル—相互通信と共有リスト
Agent Teamsでは、Team LeadとTeammatesが共有タスクリストとメールボックスを介して双方向に通信します。
- 共有タスクリスト：チーム全体で参照・更新できるタスクキュー。誰が何をやっているか全員が把握できる
- メールボックス：特定のTeammateに非同期でメッセージを送る仕組み。「型定義が完成したので実装を開始してください」のような引き継ぎが可能
- ファイルロック：同じファイルへの同時書き込みを防ぐ自動ロック機構
この仕組みにより、「AさんがAPI仕様を確定したらBさんが実装を開始する」という依存関係のある並列作業をAIエージェントが自律的に調整して進められます。
【比較表】Agent Teams vs Subagents 7つの観点
| 観点 | Subagents | Agent Teams |
|---|---|---|
| 通信方向 | 一方通行（オーケストレーター→子） | 双方向（共有リスト + メールボックス） |
| エージェント間連携 | なし（独立実行のみ） | あり（タスク依存関係に対応） |
| セットアップ | 設定不要（ビルトイン） | 環境変数1行で有効化 |
| トークン消費 | 低〜中 | 高（通信オーバーヘッドあり） |
| ファイル競合対策 | なし | ファイルロック自動 |
| セッション再開 | 可能 | 不可（制約あり） |
| 適したタスク | 独立した単発・並行作業 | 依存関係のある並列開発 |
どちらを使うべきか—3つの判断軸
「Agent TeamsとSubagentsのどちらを選ぶか」は、以下の3つの軸で判断するとシンプルに決まります。
判断軸①：依存関係を「オーケストレーターが静的に制御できるか」
最も重要かつ誤解されやすい判断基準です。
「タスク間に依存関係がある → Agent Teams」と単純に考えがちですが、これは不正確です。直列のパイプライン型依存関係（「Aが終わったらBを開始、Bが終わったらCを開始」）であれば、オーケストレーターが子エージェントを順番に呼び出すSubagentsで十分対処できます。単純な順序制御のためだけにAgent Teamsを使うのは、通信オーバーヘッドが増えるだけのオーバーエンジニアリングです。
Agent Teamsが本領を発揮するのは、依存関係が複雑・動的で、オーケストレーターが逐一制御するよりエージェント同士が自律的に調整した方が効率的な場面です。たとえばAとBが並行して走りながら共有インターフェースについて相互に擦り合わせ、その結果をCが受け取って実装を進める——というように「誰が何を待っているか」が動的に変わる状況です。
判断の問いは「依存関係があるか？」ではなく、「オーケストレーターがその依存関係を事前に把握して順番に制御できるか？それともエージェント同士の自律的な相互調整が必要か？」です。
判断軸②：ファイルの競合リスクはあるか
複数のエージェントが同じファイルやモジュールを同時に編集する可能性がある場合、ファイルロック機構を持つAgent Teamsが安全です。
Subagentsにはファイル競合対策がないため、同一ファイルへの並列書き込みが発生すると上書き競合が起きます。共通のユーティリティ関数やスタイルシートを複数エージェントが触る可能性がある開発では、Agent Teamsを選択してください。
判断軸③：トークンコストの許容範囲
Agent Teamsは通信オーバーヘッドと各Teammateのコンテキスト保持により、同じ作業をSubagentsで行う場合と比較してトークン消費量が大幅に増加します。実際に「見積もりの7倍のトークンを消費した」という報告もあります。
予算・レートリミットの制約が厳しい場合は、Subagentsを基本とし、「依存関係のある並列作業」の場面でのみAgent Teamsを使うハイブリッド戦略が現実的です。
Agent Teamsの具体的なユースケース
Agent Teamsが真価を発揮するのは、複数のエージェントが互いの作業を参照しながら進める必要があるシナリオです。
ユースケース①：フロントエンド機能の並列実装
新しいユーザープロフィール画面を実装する場面を例に取ります。
- Teammate A：型定義（UserProfile型）を作成
- Teammate B：Aの型定義が完成し次第、APIフェッチロジックを実装
- Teammate C：Aの型定義が完成し次第、UIコンポーネントを実装
- Teammate D：BとCが完成し次第、統合テストを作成
この作業フローでは、AとB・Cの間、B・CとDの間に明確な依存関係があります。共有タスクリストを通じてTeammatesが互いの完了状態を把握しながら進めることで、待機時間を最小化した並列開発が実現します。
ユースケース②：マイクロサービスの同時開発
認証サービス・注文サービス・通知サービスを同時に開発する場合、各サービスのインターフェース定義（APIスキーマ）を先に確定してから、各サービスの実装を並列で進めるという流れにAgent Teamsは最適です。
Subagentsの場合、オーケストレーターが手動でスキーマ定義の完了を確認してから実装タスクを投げる必要がありますが、Agent Teamsならその調整を自律的に行います。
CLAUDE.mdがAgent Teams運用の要になる理由
Agent Teamsを効果的に運用するうえで、CLAUDE.mdの設計が品質を左右する最重要要素です。
全Teammatesにルールを自動適用する仕組み
プロジェクトルート直下のCLAUDE.mdに記述したルールは、全てのTeammatesに自動で読み込まれます。個別のTeammateに毎回プロンプトでルールを説明する必要がなく、チーム開発で言えば「オンボーディングドキュメント + コーディング規約」が全員に自動配布されるイメージです。
Team Leadだけが知っているルールをTeammatesが破る、というような品質のばらつきが起きにくくなります。
効果的なCLAUDE.mdの書き方3つのポイント
- コードから読み取れない情報に絞る：ディレクトリ構造・型の命名規則・テスト方針など、コードを読んでも分からないプロジェクト固有の文脈を記述する。自明なことを書きすぎるとトークン消費が増えるだけ
- 簡潔に保つ：CLAUDE.mdは全Teammatesのコンテキストに含まれるため、冗長なほどトークンコストが増加する。1セクションあたり3〜5行を目安にする
- 禁止事項を明示する：「このファイルは絶対に直接編集しない」「外部APIの呼び出しは必ず既存のラッパー関数を使う」のような制約を明記することで、Teammatesの逸脱を防げる
Agent Teamsのデメリットと注意点
Agent Teamsは強力な機能ですが、現時点では以下の制約を理解したうえで使う必要があります。
注意点①：トークン消費は見積もりの数倍になることも
Agent Teamsでは、各Teammateが独自のコンテキストウィンドウを持つため、同じコードベースの情報を複数のTeammatesが重複して保持します。加えて、通信（共有タスクリスト・メールボックス）のオーバーヘッドも発生します。
実際の報告では、安いモデルで並列タスクを実行したところ、見積もりの7倍のトークンを消費したケースがあります。本格運用にはMaxプラン（$200/月）が推奨されており、ProプランではレートリミットにすぐBSに当たるという声も多くあります。
コストを抑えるには、①タスク粒度を細かくしすぎない、②独立タスクはSubagentsに任せる、③CLAUDE.mdを充実させてTeammatesの試行錯誤を減らす、という3点が有効です。
注意点②：セッション再開不可・実験的機能ゆえの制約
現在のAgent TeamsはResearch Preview（実験的機能）であり、セッションの中断・再開ができません。途中でセッションが切れると、進行中のTeammatesのコンテキストが失われます。
また、実験的機能ゆえにAPIや挙動が変更される可能性があります。本番環境の重要なリリース作業には使わず、まずは開発環境での検証用途から始めることをお勧めします。
まとめ—プロジェクトに合った選択をするために
Agent TeamsとSubagentsの使い分けを整理します。
- 依存関係が複雑・動的でエージェント同士の自律調整が必要 → Agent Teams：直列パイプライン程度の順序制御ならSubagentsで十分。Agent Teamsが真価を発揮するのは、誰が何を待つか動的に変わる複雑な並列開発
- タスクが独立、または直列パイプラインで順序制御できる → Subagents：オーケストレーターが順番に呼び出せばよい。シンプルで低コスト
- コスト制約が厳しい → Subagentsを基本に：Agent TeamsはMaxプラン前提と考えておく
- CLAUDE.mdを必ず整備する：全Teammatesへのルール自動適用が、Agent Teams運用品質の鍵
Claude CodeのAgent Teamsは、正しく使えばソフトウェア開発の生産性を大幅に向上させる強力なツールです。一方で、適切なユースケース選定とコスト管理なしには逆効果になりかねません。
Solvageでは、Claude CodeをはじめとするAI開発ツールの導入・運用支援を行っています。「どの機能から導入すべきか」「コスト対効果の試算をしたい」といったご相談も、ぜひお気軽にどうぞ。