Claude Code Agent TeamsとSubagentsの違いは？責任分担とコストの比較

Claude Code Agent TeamsとSubagentsの違いは、誰が調整して、途中のコンテキストを誰が持つかです。Subagentsは親エージェントが仕事を切り分けて配り、要約だけを受け取ります。Agent Teamsは独立した複数のインスタンスが共有タスクリストを通じて連携します。互いの途中結果が要らない作業ならSubagents、メンバー同士が途中で情報を交わさないと進まない作業ならAgent Teamsが向きます。トークン消費は、公式ドキュメントの整理ではSubagentsが低め、Agent Teamsが高めです。迷うときはSubagentsから始め、対話が必要になった場面でAgent Teamsを足します。速くなるかどうかはエージェントの数ではなく、タスク同士がどれだけ独立しているかで決まります。

Claude Codeにはどんなマルチエージェントの選択肢がありますか？

Claude Codeには並行作業の方法がいくつかあり、ここではSubagentsとAgent Teamsを比べます。どちらも仕事を複数のエージェントに分けます。Subagentsはひとつのセッションの中で親がすべてを差配し、Agent Teamsは独立したセッションが並行して動きます。

Agent Teamsは実験的な機能で、既定では無効です。settings.jsonか環境変数にCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を設定すると使えます。設定がないと、セッション開始時にチームは組まれず、Claudeがチームメイトを起動することも提案することもありません。セッションの再開、タスクの調整、終了時の挙動には既知の制限があるので、安定運用を前提にするなら先に把握しておきます。

親が仕事を配るSubagents

Subagentsは、ひとつのClaude Codeセッションの中で動く委譲の仕組みです。親エージェントがタスクを分解し、専門に特化したエージェントを起動して、完了した結果だけを受け取ります。各サブエージェントは自分のコンテキストウィンドウで作業し、返すのは要約した成果です。探索の過程や中間のログは親に渡りません。

サブエージェントは結果を親に返すのが基本です。サブエージェント同士でメッセージを送れるのは、Claudeが起動時に名前を付けたものだけです。調整役は親ひとりで、情報の流れが一方向なので動きを予測しやすくなります。

共有タスクリストで動くAgent Teams

Agent Teamsは、複数の独立したClaude Codeインスタンスがチームとして並行して動く仕組みです。チームリードが全体を調整し、メンバーはそれぞれ独立したセッションとコンテキストを持ちます。メンバー同士は直接メッセージを送り合い、共有タスクリストから自分の担当を取得して、依存関係を見ながら進めます。

たとえばバックエンド担当がAPIのレスポンス形式を変えたら、その変更をフロントエンド担当へ直接伝えられます。リードが内容を写し替える必要はありません。一方で、インスタンスごとにコンテキストを持つので、トークンの消費の仕方はSubagentsと変わります。

SubagentsとAgent Teamsはどこが違う？責任分担とコンテキストの持ち方

Subagentsは親がすべてを調整して結果だけを受け取ります。Agent Teamsは各メンバーが独立したコンテキストを持ち、共有タスクリストを通じて直接やり取りしながら自己調整します。責任の所在とコンテキストの流れを表にすると、次のとおりです。

責任とコンテキストの対応表

実務で分かれ目になるのは追跡のしやすさです。Subagentsは情報の流れが一方向なので、誰が何を知っているかをいつでも追えます。Agent Teamsはメンバーが並行して状態を書き換えるため、ある時点で誰の情報が最新なのかを気にする場面が増えます。

対話が要るかどうかが分かれ目

選ぶ軸はタスクの構造です。独立して完結し、結果だけ受け取れば足りる作業はSubagentsが素直です。複数ファイルの解析、複数APIの並列呼び出し、決まった書式への変換のように、互いの途中結果を必要としない仕事がこれに当たります。

あるメンバーの発見が別のメンバーの進め方を変える作業は、Agent Teamsが向きます。設計方針をめぐって視点がぶつかる場面や、仕様や方針を途中で変えるかもしれない場面です。あるメンバーがAPIの形を変えたのに、その前提で動く別のメンバーに伝わらないと、後から手戻りが大きくなります。

どちらがトークンを多く使う？コストの向きは条件で変わります

Claude Codeの公式ドキュメントでは、トークンコストはSubagentsが低め、Agent Teamsが高めです。各チームメイトが別々のClaudeインスタンスとして自分のコンテキストウィンドウを持ち、消費が稼働中の人数とともに増えるためです。第三者の解説には逆方向の推定もありますが、比較の基準がそろっていないので、ひとつの倍率としては使えません。

相反するコスト推定をどう読むか

ある解説には「Agent Teamsはおよそ5倍のトークンを使う」という推定があります。各メンバーが別々のClaudeインスタンスとして動き、それぞれがコンテキストを持つことが根拠で、何と比べた5倍なのか、どんな条件なのかは書かれていません。

ほかにも、メンバーの人数に比例してトークン消費が増える、各メンバーが自分のコンテキストウィンドウを持つので単一エージェントより高くつく、という整理があります。逆に別の解説は、10以上のエージェントが実質的な出力を返す大規模な並列パイプラインを前提に、Agent Teamsが1回あたり3〜5倍安くなり得ると述べています。こちらも比較対象と条件の細部は書かれていません。どれも手法が公開された一次計測ではなく第三者の推定なので、向きはワークロードの形で変わると見ておくのが安全です。

増える要因は3つ

見積もりでは、並列度、1エージェントあたりの出力サイズ、パイプラインの長さの3つを先に決めます。親が結果を抱える構成では、往復のたびに親のコンテキストが伸びます。10個のサブエージェントがそれぞれ2,000トークンを返せば、親は統合の前に2万トークン近くを抱えます。

共有タスクリスト側では、各メンバーが必要な範囲だけを読むので、個々のコンテキストは小さく保てます。ただしセッションが人数分だけ動くため、総消費は人数と稼働時間に引っ張られます。並列度を上げるときは、1本あたりの出力を短くする調整が効きます。

並列化でトークン消費が増えるなら、支払い側の構造も関わってきます。MixRouteは250以上のモデルを、プラットフォーム手数料0%、推論価格への上乗せなしで使える構成を打ち出しています。エージェントを増やした分の消費が、手数料でさらに膨らむことはありません。

試算はタスクの分解が決まってからで十分です。構成に応じた節約の目安を確認すると、料金面も含めてAgent Teamsへ広げるかどうかを判断できます。

並列タスクを回すとき、コストとレビューへの影響はどう見積もりますか？

独立したタスクを4つ前後の有界な規模で並列化する場合、各エージェントが読むコンテキストは人数分に近づきます。一方、並列に書かれたコードは前提がぶつかりやすく、レビューで統合の判断が要ります。コストとレビューは別々に見積もります。

独立4タスクを並列に回す例

小さな決済まわりのリポジトリで考えます。在庫計算の丸め処理を直す、APIの入力バリデーションを足す、ログ出力の書式を揃える、既存関数にテストを足す。この4つは互いの結果を必要としないので、そのまま並列に配れます。

Subagentsで回す場合は、親が4つのサブエージェントを起動し、4本の要約を受け取って統合します。親のコンテキストは要約4本分だけ増え、探索の過程は入りません。Agent Teamsで回す場合は、4人が独立して読み書きします。丸め処理の変更がテストの前提を変えるといった依存は、共有タスクリスト側で調整されます。

コストは、4本それぞれが読むファイル数と返す要約の長さで決まります。4人に同じ設計メモを渡すなら、その重複も人数分として数えます。

レビューで見るべき前提の衝突

並列にコードを書かせると、並列度が上がるほどレビューの負荷も増えやすくなります。エージェントごとに互換しない暗黙の前提を持ちやすく、マージの段階で初めて衝突が表に出るためです。エラーの扱い方、命名、nullの扱い、非同期の待ち方といった判断が、それぞれの作業の中で静かに決まっていきます。

4本をそのまま統合せず、統合の判断は人が持ちます。レビューで見るのは、動くかどうかより前提がそろっているかどうかです。検証を任せるときは、テストを全部走らせる、対象のケースを明示するといった合格条件を先に決めておくと、確認しないまま完了を宣言されることを避けられます。

タスクの書き方が曖昧だと、二人が同じ調査をして、どちらも気づきません。担当ごとに成果物の形式と範囲を一文で書き切ると、この重複が減ります。

迷ったらどう進めますか？Subagents起点の判断とハイブリッド構成

まずSubagentsで試し、メンバー間の対話や相互調整が必要になった時点でAgent Teamsを足します。チームメイトが作業の一部をサブエージェントに委譲する構成にする手もあります。小さい構成から始め、必要が確認できた複雑さだけを足すと、検証しやすくなります。

Subagentsから始める

単一のエージェントで収まる範囲を確かめてから、必要な箇所だけ分割を足せます。複雑さは、測って確かめた問題を解くときだけ足します。長い検討の末に大掛かりなパイプラインを作っても、ひとつのエージェントへの良いプロンプトで足りることがあります。

Subagentsで品質が足りないと分かってからAgent Teamsへ移るのは、安い側から試すという意味でも筋が通っています。移る目安は、メンバー同士が途中で情報を交わさないと前に進めない場面が実際に起きたかどうかです。

ハイブリッド構成

両者は排他ではありません。Claude Codeではメインセッションがリードとして全体の段取りを決め、チームメイトは自分の作業の一部をサブエージェントに委譲できます。チームメイトが別のチームを作ることはできず、チームは1セッションにひとつです。

分け方には型があります。チームの中で重い実装だけをサブエージェントに委譲する形、戦略をチームが担い実行をサブエージェント群が担う形、設計と合意はチーム、大量生成はサブエージェント、レビューで再びチームというフェーズ分離の形です。対話が要る局面と単純な実行の局面を分けると選びやすくなります。

実際の開発フローに落とすときは、エージェントに任せながら開発を進める実践の手順も参考になります。任せる範囲と人が確認する位置を先に決めておくと、戻すべき変更が明確になります。