Claude CodeのSubagentsとAgent Teams、結局どう使い分けるべきか ── 3つの実務シナリオで徹底比較
はじめに
Claude Codeには、複数のAIエージェントを並行稼働させる仕組みが2つ存在します。
- Subagents: メインセッションから子エージェントを呼び出し、結果を報告させる仕組み。標準機能。
-
Agent Teams: 複数のClaude Codeインスタンスが「チームリード」のもとで共有タスクリストとメッセージングを介して協業する仕組み。2026年2月にOpus 4.6と共に登場した実験的機能で、
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSを明示的に有効化しないと動作しません。
どちらも「並列化」という見た目は同じですが、コミュニケーション構造がまったく違います。Subagentsは親子の一方通行(委任→報告)、Agent Teamsはピアツーピア(チームメイト同士が直接メッセージを送り合える)です。
この違いが実務上どれだけの差を生むのか──「速いか遅いか」だけでなく「トークンコストに見合う判断の質の差が出るのか」を、以下3つの業務シナリオで実測検証しました。
- シナリオA: AWS設計書からTerraform(IaC)への変換
- シナリオB: 頻度は低いがビジネス影響のあるバグの根本原因分析
- シナリオC: 実装コードに対する複数専門観点でのレビュー
結論を先に言うと、Agent Teamsは全シナリオでSubagentsの2.5〜4.7倍のトークンを消費した一方、単純な集約では出てこない「発見」も3シナリオ全てで確認できました。ただしその発見の中身と価値はシナリオごとに大きく異なります。以下、詳細を見ていきます。
用語整理とアーキテクチャの違い
| 観点 | Subagents | Agent Teams |
|---|---|---|
| 構造 | 親子階層(1対多)。委任元(オーケストレーター)が全てを仲介 | チームリード+チームメイトによるピアツーピア |
| 通信 | 子から親への一方向報告のみ。子同士は連携不可 | メールボックス的な仕組み(SendMessage)でメンバー間の直接連携が可能 |
| 状態 | 標準機能、常時利用可能 | 実験的機能。デフォルト無効、環境変数での有効化が必要 |
| 向いている場面 | 独立したサブタスクを並行処理し、要約だけ受け取りたい場合 | メンバー間ですり合わせ・議論・相互チェックが必要な場合 |
比喩で言うなら、Subagentsは「個別に発注する専門業者」、Agent Teamsは「同じ会議室で議論しながら動くプロジェクトチーム」に近い構造です。
検証方法
環境と計測方法に関する注記
今回の検証はAgent SDK経由の非対話環境で実施したため、対話型CLIの /usage コマンドは使用できませんでした。代わりに、Agent(Task)ツールでサブエージェント/チームメイトを起動するたびに返る <usage> メタデータ(subagent_tokens / tool_uses / duration_ms)を実測値として集計しています。
この数値には委任元(オーケストレーター/チームリード)自身が消費したトークンは含まれません。 つまり以下で示す数値は「委任先エージェント群が消費した分」の比較であり、全体の絶対コストではなく、両パターンの相対的なコスト差を見るための指標として扱ってください。厳密な絶対コストを知りたい場合は、実際の対話型CLIセッションで /usage を実行して突き合わせる必要があります。
各シナリオの担当分割
公平な比較のため、Subagents/Agent Teamsで同じ「担当領域の分割」を採用しています。
- A: network / compute / security の3領域 + 最終レビュー担当
- B: 証拠整理担当 + 複数の仮説検証担当(Subagentsは5仮説を委任元が事前列挙、Agent Teamsは3〜4名が自律的に仮説を選択)
- C: security / performance / test-coverage(QA)の3観点 + 最終統合担当
シナリオA: AWS設計書 → Terraform変換
何を検証したか
VPC・サブネット・ルーティング(network)、EC2/ECS/Lambda/ALB(compute)、IAM/セキュリティグループ/KMS(security)の3領域にモジュールを分割し、リソース間の依存関係(サブネットID、セキュリティグループID、IAMロールARNなど)の配線が必要になる、実務でよくあるIaC変換タスクです。
結果サマリ
| Subagents | Agent Teams | |
|---|---|---|
| 消費トークン(委任先合計) | 248,043 | 614,284(2.5倍) |
| 壁時計所要時間 | 約26分21秒 | 約15〜20分(概算) |
| 委任/起動回数 | 7回 | 11回(revive含む) |
| 最終検証 | validate: Success(plan未実行、認証情報なし) | validate: Success、plan: 73 add / 0 change / 0 destroy |
| Critical/High指摘 | 0件 | 0件 |
Agent Teamsの方がトークンは大幅に多く消費した一方、実際にplanコマンドまで実行し「73リソースが矛盾なく追加できる」ところまで確認が取れています。これはチームメイト同士がお互いの実装状況を把握しながら統合テストまで進められたためと考えられます。
何が起きたか:インターフェース交渉というAgent Teams特有の挙動
Subagentsパターンでは、オーケストレータが事前に全モジュール間の変数名を決めて各サブエージェントに明示しました。その結果、モジュール間の変数名不整合は最終的に0件でした。ただしこれは「Subagentsというパターンの特性」ではなく、「委任者が設計を統制した結果」です。委任元の設計スキルに品質が依存する、と言い換えられます。
一方Agent Teamsでは、compute-engineerが作業開始直後にnetwork-engineer/security-engineerへ自発的にSendMessageで変数名を照会し、返信を得てから配線を確定させました。人間が事前に設計を握らなくても、エージェント同士が動的にインターフェースをすり合わせたわけです。
ただしこの自律的すり合わせは完全ではありませんでした。Lambda関数のVPC内配置フラグについて、security-engineerは lambda_vpc_enabled、compute-engineerは place_lambda_in_vpc という別名のまま合意し、reviewerが検知して初めて「対応不要」と処理されています。すり合わせても不一致が残るケースがある、という点は率直に記録しておくべきでしょう。
コストのハブ化という副作用
チームメイト別のトークン消費を見ると、著しい偏りがあります。
| チームメイト | 呼び出し回数 | 消費トークン | 活動時間 |
|---|---|---|---|
| network-engineer | 3 | 116,537 | 約5.7分 |
| compute-engineer | 2 | 143,244 | 約9.1分 |
| security-engineer | 5 | 266,813 | 約51分 |
| reviewer | 1 | 87,690 | 約7.0分 |
security-engineerは他の2名からの問い合わせが集中し、呼び出し回数・トークン・活動時間のすべてで突出しました。IAM/セキュリティグループはネットワークとコンピュートの両方から参照される「ハブ」的な位置づけになりやすく、これは今回のタスク構造に起因する部分もありますが、Agent Teamsでは特定メンバーへの負荷集中(ホットスポット化)が起こりうるという一般的な教訓として記録に値します。
実務上の注意点
同一のファイルシステム上でSubagents実行の直後にAgent Teams実行を行ったところ、compute-engineerが既存の(Subagentsパターンで実装済みの)modules/compute/を「参考」として読みに行っていたことが自己申告で判明しました。2パターンを継続して検証する際は、完全に別のワークツリー・ディレクトリで実行するか、参照禁止を明示するべきです。この点は検証設計の反省点として記事に残しておきます。
シナリオB: 低頻度バグの根本原因分析
何を検証したか
決済処理での「DB上は成功しているのにクライアントには失敗が返り、リロード再送で二重注文が発生する」という、複数の変更(インフラ設定変更+アプリデプロイ)が絡み合う複合障害を想定したケースです。時系列の矛盾を見抜けるか、複数仮説を正しく評価できるかを見る、根本原因分析の実力が試されるシナリオです。
結果サマリ
| Subagents | Agent Teams | |
|---|---|---|
| 消費トークン(委任先合計) | 71,864 | 335,938(4.7倍) |
| 壁時計所要時間 | 約7分36秒 | 約8分22秒 |
| 検証した仮説数 | 5(委任元が事前列挙) | 3〜4(各自が自律的に選択) |
| 最終結論の確信度 | 中〜高 | 中 |
3シナリオの中でトークン倍率が最も大きかったのがこのシナリオです。
Subagentsの弱点:重複作業とオーケストレーターへの負荷集中
Subagentsパターンでは、5つのhypothesis-testerが全員独立に「対象コードベースがこの環境に存在しない」ことを確認・報告していました。同じ調査(コードベース検索)が5回重複して発生していたことになります。evidence-collectorの時点で「コードベースなし」と明記しておけば防げた可能性が高く、これはSubagentsパターン特有の弱点というより、委任プロンプト設計の問題です。
また、サブエージェント同士が連携できないため、メインセッションが同一のタイムライン全文を5回コピーして各hypothesis-testerのプロンプトに含める必要がありました。情報の受け渡しコストがオーケストレーター側に集中するという、Subagentsの構造的な特徴が明確に表れた部分です。
一方で良い点もありました。仮説4(外部決済起因)・仮説5(WorkerQueueLag起因)は、結果が原因より時系列的に先に発生しているという明確な反証パターンがあり、hypothesis-testerはそれぞれ自律的にこれを見抜いて確度「低」と正しく棄却しています。事前に5仮説を人間側で列挙していたため、仮説同士の重複はゼロでした。
Agent Teamsで起きたこと:自律的な仮説選択の落とし穴
Agent Teamsパターンでは、hypothesis-A/B/Cの3名がそれぞれ自律的に仮説を選ぶ設計にしたところ、全員が独立に「idempotency設計不備」という同一仮説に収束するという事態が発生しました。SendMessageで数往復のやり取りを経て役割を再調整し(A=idempotency設計、B=決済外部要因、C=DB設定変更)、ようやく重複が解消されています。
これはSubagentsパターン(委任元が5仮説を事前列挙し重複ゼロ)とは対照的です。「エージェントに自律性を持たせる」ことは、必ずしも探索の多様性を担保しないことを示す実例と言えます。人間が仮説の枠組みを与えるSubagentsの方が、むしろ網羅性で優れていたわけです。
ただし、収束後の相互反証は価値を生みました。hypothesis-AとCが決済とDBのレイテンシ内訳をそれぞれ独立に計算し、結果が一致することを確認した結果、hypothesis-Cは自分の仮説を「単独の根本原因」から「増幅・トリガー要因」へと自己修正しています。これは単純な並列集約(Subagents)では起きない、Agent Teamsならではのプロセスです。単一の仮説検証者による自己申告ではなく、独立した2系統の計算が一致したことで結論の裏付けが強化された、という点は根本原因分析というタスクの性質上、価値の高い協調だったと言えます。
最終的な結論の確信度は、Subagentsが「中〜高」、Agent Teamsが「中」でした。両者はほぼ同じ結論(idempotency設計不備が主因、DBプール縮小・決済リトライが増幅要因)に到達していますが、Agent Teamsの方がやや保守的な評価に留まっています。これは、evidence-leadが「二重注文の直接証拠はログに存在しない」という限界情報をチーム全体に明示的に伝播させたことが影響していると考えられます。
シナリオC: 複数専門観点でのコードレビュー
何を検証したか
決済リトライ・idempotency-key対応・管理用注文削除APIを追加する差分に対し、SQLインジェクション・カード番号平文ログ・認可欠如・N+1クエリ・ブロッキングリトライ・テスト未追加などを意図的に仕込んだサンプルアプリをレビュー対象としました。
結果サマリ
| Subagents | Agent Teams | |
|---|---|---|
| 消費トークン(委任先合計) | 36,554 | 119,062(3.3倍) |
| 壁時計所要時間 | 約1分39秒 | 約5分25秒 |
| 統合後の指摘件数 | Critical 3 / High 4 / Medium 3 / Low 4(概算) | Critical 5 / High 2 / Medium 2 / Low 3(計12) |
| revive発生 | - | 0件(全員1回の呼び出しで完結) |
3シナリオの中でトークン倍率が最も小さかったのがこのシナリオです。理由の一つとして、Agent Teamsでreviveが1件も発生しなかったことが挙げられます(シナリオA・Bでは複数回のrevive=セッション再開が発生し、そのたびにコンテキスト再読込のオーバーヘッドが生じていました)。
観点間の対立をどう解消するか
両パターンとも、3つの専門観点(security/performance/test-coverage)が独立にSQLインジェクションや認可欠如などの重大な指摘に到達し、この点では高い一致を見せました。興味深いのは「評価が割れた指摘」の扱われ方の違いです。
Subagentsパターンでは、「N+1クエリの重大度」についてperformance-reviewerが Critical、security-reviewerが Low と評価し、対立したままでした。サブエージェント同士は互いの結果を見られないため自然には解消されず、最終的にオーケストレーター(人間側の判断代理)が統合判断を下す必要がありました。
Agent Teamsパターンでは、同種の対立が「決済リトライの二重課金リスク」という指摘で発生しました。performance-engineerは「現状ダミー実装につき再現不可能」としてHigh、qa-engineerは「設計契約の欠陥で実装差し替え時に即顕在化する」としてCritical寄りと評価し、両者は無理に一本化せずleadの判断に委ねました。ここでのleadの裁定が示唆に富んでいます。「技術的な再現性」と「ビジネスリスク」を別軸として整理した上で、後者を優先してCriticalを採用し、その理由を明示しました。これは委任元である人間が単独で統合判断するよりも、踏み込んだ質の高い推論だったと評価できます。
つまり、対立の「解消」自体はSubagentsでもAgent Teamsでも(最終的に人間ないしlead役が)行っているが、Agent Teamsでは判断の過程(評価軸の切り分け)がチーム内で言語化され、レビューの成果物として残る、という違いがありました。
定量比較まとめ
| シナリオ | Subagentsトークン | Agent Teamsトークン | 倍率 | Agent Teamsの主な強み | Agent Teamsの主なコスト・弱点 |
|---|---|---|---|---|---|
| A: IaC変換 | 248,043 | 614,284 | 2.5倍 | チームメイト間の自律的なインターフェース交渉、plan実行までの統合確認 | 変数名不一致が交渉後も一部残存、特定メンバー(security-engineer)へのハブ化 |
| B: 根本原因分析 | 71,864 | 335,938 | 4.7倍 | レイテンシ内訳の相互検算による仮説の自己修正 | 全員が同一仮説に独立収束(探索の多様性欠如)、再調整コスト大 |
| C: コードレビュー | 36,554 | 119,062 | 3.3倍 | 対立点(二重課金リスク)をleadが評価軸を立てて明確に裁定 | reviveなしでもコスト高は継続 |
全シナリオに共通して観察された制約として、完了済み(セッション終了済み)のチームメイトへのSendMessageは名前指定で失敗する(addressableでなくなる)という挙動があります。シナリオA・B双方でreviewer/lead役が最終統合前にメンバーへ再確認しようとして、少なくとも一部失敗していました。これはAgent Teamsパターン全般に再現性のある制約と考えられます。
ビジネス視点での考察
コストと価値のトレードオフ
3シナリオを通じて、Agent Teamsのトークンコストは一貫してSubagentsの2.5〜4.7倍でした。これを「高い」と見るか「妥当」と見るかは、協調によって生まれた発見がビジネス上どれだけの価値を持つか次第です。
- シナリオAでは、Agent Teamsは実際にterraform planの実行(73リソースの整合性確認)まで到達しました。IaCにおいて「デプロイ前に矛盾なく計画が通る」ことの価値は、トークンコストの数倍を正当化しやすいと考えられます。
- シナリオBでは、コストが最も跳ね上がった(4.7倍)一方で、最終結論の確信度はSubagentsの方がやや高い(中〜高 vs 中)という結果でした。これは「協調コストをかけたのに、むしろ人間が仮説を与えた方が良い結果だった」ケースであり、自律性に協調コストを払う価値が必ずしもないタスクがあることを示しています。
- シナリオCでは、コストが最も小さく(3.3倍)、かつ評価軸を切り分けた裁定という質的な向上が見られました。「独立した専門観点を持つメンバーが、対立点についてのみ協調する」構造は、コストパフォーマンスが比較的良い使い方だったと言えます。
意思決定の質という切り口
金額換算しにくい価値として、意思決定の「理由」が言語化されて残るかどうかは見逃せません。シナリオCのlead裁定(技術的再現性とビジネスリスクの評価軸分離)は、単なる「Critical判定」という結論だけでなく、なぜそう判定したかの推論過程がレビュー成果物に残っています。これは、後から監査する立場(セキュリティ担当、経営層への説明責任を持つマネージャーなど)にとって価値のあるアウトプットです。Subagentsパターンでは、この種の判断はオーケストレーター(人間)の頭の中で完結してしまい、成果物には残りにくい傾向がありました。
組織設計のアナロジー
今回観察された挙動は、そのまま人間の組織設計の教訓に置き換えられます（個人的にすごく興味深い）。
- ハブ化(シナリオA): 依存関係が集中する役割(今回のsecurity-engineer)に負荷が偏るのは、人間のチームでも「みんなが同じ人に確認を取りに行く」現象と同じです。役割設計の時点で、ハブになりやすい領域を意識しておく必要があります。
- 自律性と多様性のトレードオフ(シナリオB): 「各自の判断に任せる」ことは必ずしも探索の幅を広げません。むしろ人間が最初に仮説の枠組み(スコープ)を割り振った方が、重複なく網羅的な検証ができました。これは実際のブレインストーミングやインシデント対応でも起こりうる現象です。
- 対立の裁定コスト(シナリオC): 専門性の異なるメンバー間の意見対立は、最終的に誰か(lead、あるいは人間)が評価軸を立てて裁定する必要があります。この「裁定」自体に価値を持たせられるかどうかが、協調コストを払う意味を左右します。
導入判断のための簡易フレームワーク
今回の3シナリオの結果から、以下のような判断軸を提案します。
| 判断軸 | Subagentsが向く | Agent Teamsが向く |
|---|---|---|
| タスクの分解可能性 | 領域が明確に独立し、依存関係が薄い | 領域間の依存関係やインターフェース調整が必要 |
| 検証の性質 | 網羅性が重要(仮説の枠組みは人間が与えられる) | 相互検算・相互反証によって結論の確度を上げたい |
| 最終判断の重み | 人間(オーケストレーター)が最終判断を引き受けられる | 判断理由の言語化・監査可能性が求められる |
| コスト感度 | 高い(トークンコストを抑えたい) | 中〜低(コストより成果物の質・確認の深さを優先) |
| 機能の成熟度要件 | 標準機能で安定運用したい | 実験的機能のリスクを許容できる |
まとめ
3つの実務シナリオで検証した結果、Agent TeamsはSubagentsに対して一貫して2.5〜4.7倍のトークンコストがかかりました。その対価として得られたのは、単純な「速さ」や「並列度」ではなく、
- チームメイト同士が自発的にインターフェースをすり合わせる挙動(シナリオA)
- 独立した計算の一致による結論の裏付け強化(シナリオB)
- 対立点に評価軸を立てて言語化する裁定プロセス(シナリオC)
といった、協調そのものが生む質的な価値でした。一方で、仮説の探索多様性(シナリオB)のように、自律性に任せた結果むしろSubagents(人間が枠組みを与える方式)の方が優れていた場面もありました。
現時点でAgent Teamsは実験的機能であり、セッション再開時のコンテキスト再読込や、完了済みメンバーへのメッセージ送信失敗といった運用上の粗さも残っています。実務導入を検討する際は、「協調によって生まれる質的価値が、2.5〜4.7倍のコスト差を正当化できるタスクかどうか」を見極めた上で、段階的に適用範囲を広げていくのが現実的な進め方だと考えられます。
検証環境について(補足)
本検証はAgent SDK経由の非対話環境で実施しており、対話型CLIの /usage コマンドではなく、Agent(Task)ツール呼び出し時の <usage> メタデータから委任先エージェント単体の消費トークンを集計しています。委任元(オーケストレーター/チームリード)自身のトークン消費は含まれていないため、本記事の数値は絶対コストではなく、両パターンの相対的な比較指標として参照してください。