Claude Code のチーム機能とサブエージェントはいつ使い分けるのか — 「P2P で連携できるなら常にチームが上位互換」への答え
Claude Code のサブエージェントを 4〜5 並列で回して、本番稼働している複数サイトの保守を日々出荷しています。その運用の設計は別記事「Claude Code のサブエージェント並列で本番サイト群を保守する」にまとめました。この運用を人に説明すると、ほぼ必ず同じ疑問が返ってきます。
Claude Code にはチーム機能（Agent Teams）がある。エージェント同士が P2P で直接メッセージをやり取りして、共有タスクリストを自分たちで取り合いながら協働できる。一方、サブエージェントは親に結果を返すだけで、エージェント同士は会話できない。なら、チーム機能は常にサブエージェントの上位互換では？
もっともな直感です。「できることが多い方が強い」は多くの場面で正しい。しかし、この二つは「機能の多寡」で並ぶものではなく、別の道具です。本記事は「チーム機能を試してみた」報告ではなく、サブエージェント並列を実務で回している立場から、両者の機構の違いに照らして「なぜ自分は今のところ全部サブエージェントで組んでいるのか」を書きます。
前提: 機能仕様は公式ドキュメント（Agent Teams / サブエージェント）の記載に厳密に沿っています。なお Agent Teams は実験的機能で、デフォルトでは無効です。ドキュメントには CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定しないと「セッション開始時にチームは構成されず、Claude はチームメイトを spawn も提案もしない」と明記されています。この点だけでも「常に上位互換」ではないのですが、それは本質ではないので機構の話に入ります。
二つの機構を、ドキュメントの定義で並べる
公式ドキュメントの比較表が、両者の違いをそのまま言い当てています。要点を引きます。
- コンテキストの持ち方: どちらも独立したコンテキストウィンドウを持つ。サブエージェントは結果を呼び出し元（親）に返す。チームメイトは完全に独立している。
- 通信経路: サブエージェントは親エージェントにだけ結果を報告する（エージェント同士は会話しない）。チームメイトは互いに直接メッセージを送り合う。
- 協調の仕方: サブエージェントは親エージェントが全ての作業を管理する。チームは共有タスクリストを持ち、各自が自律的に協調する（タスクは pending / in progress / completed を持ち、依存関係やファイルロックで奪い合いを制御する）。
- 向いている用途: サブエージェントは「結果だけが重要な、焦点の定まったタスク」。チームは「議論と協働を要する複雑な作業」。
- トークンコスト: サブエージェントは低い（結果が要約されて親コンテキストに戻る）。チームは高い（チームメイトそれぞれが独立した Claude インスタンスで、コストはチームメイト数に比例して増える）。
ドキュメント自身の言葉でまとめると、こうです。「素早く焦点の定まった、報告を返すワーカーが欲しいときはサブエージェント。チームメイトが知見を共有し、互いに反論し合い、自分たちで協調する必要があるときはチーム」。
つまり両者を分ける軸は「機能の多い少ない」ではなく、ワーカー同士が互いに通信する必要があるかどうかです。
「P2P できる方が強い」がなぜ直感として湧くか
先の疑問はこう分解できます。「チームはサブエージェントができること（独立コンテキストで並列に働く）を全部でき、その上さらにエージェント間通信ができる。上位集合なのだから上位互換だ」。
集合として見れば、確かにチームの能力はサブエージェントを包含しているように見えます。しかしソフトウェアの道具は、能力の集合の大小だけで優劣が決まりません。その能力を使わないときに、能力の存在そのものがコストになるからです。エージェント間通信という自由度は、使わなくても、制御と検証の難しさとして必ず効いてきます。ここが直感の盲点です。
サブエージェントの本質は「明確なタスクを切り出して、結果だけ回収する」
サブエージェントは、ドキュメントの言葉を借りれば「それぞれが独自のコンテキストウィンドウ、カスタムシステムプロンプト、固有のツールアクセス、独立した権限を持つ」ワーカーです。親が仕事を切り出して手渡し、ワーカーは独立に働いて要約を返す。この一方通行こそが道具の本質で、そこから実務上の利点が芋づる式に出てきます。
タスクの境界が指示書として書けるなら、次が全部手に入ります。
- コンテキストが小さく、安い。探索やビルドログといった大量出力はサブエージェント側に留まり、親には要約だけが戻る（ドキュメントは「大量の出力を生む処理を隔離する」ことをサブエージェントの代表的用途に挙げています）。
- 失敗が局所化する。一つの班が転んでも、独立コンテキストなので他に波及しない。API エラーで途中終了しても、その班の失敗として親に報告される。
- 指示書がそのまま再現可能な仕様になる。切り出せる境界を文章化した時点で、それは「何をどう測って良しとするか」まで含んだ発注書になる。人間のチームの引き継ぎメモに近いが、毎回まっさらな新人に渡す前提で書く。
- 権限を非対称に作れる。ツールを allowlist / disallowedTools で絞り、
permissionModeで読み取り専用にもできる。本番書き込み禁止・共通パッケージ改変禁止といった制約を、班に最初から課せる。
私が 8 サイトのモノレポ保守を全てサブエージェントで組み、ある 1 日に 12 本の PR を出荷できたのは、扱った作業が「監視基盤の構築」「404 の正規化」「クエリの実装+計測」「画像欠損の回収」のように、境界を事前に指示書として書き切れたからです。各班の結果は司令塔（メインセッション）に集約すれば十分で、班同士が会話する必要が一度も生じませんでした。会話が要らないなら、会話できる機構は要りません。
チーム機能の本質は「対等なエージェントが相互通信しながら協働する」
では、チーム機能はどこで効くのか。ドキュメントは強い用途をはっきり挙げています。
- 調査とレビュー: 複数のチームメイトが問題の別々の側面を同時に調べ、互いの発見を共有し反論し合う。
- 競合する仮説を並べたデバッグ: それぞれが別の仮説を並行して検証し、科学的な議論のように互いの説を反証しようとして、生き残った説が真の原因に近づく。
- 層をまたぐ協調: フロント・バック・テストにまたがる変更を、それぞれ別のチームメイトが持つ。
- 新しいモジュールや機能: 互いに踏まないよう、各自が別の一片を所有する。
共通しているのは、タスクの境界を事前に書き切れないという性質です。仮説デバッグでは、最初にどの仮説が正しいか分からないから並べて反証させる。レビューでは、一人だと一種類の問題に引っ張られるから、複数の視点を突き合わせる。ここでは「対等なエージェントが議論する」こと自体が価値を生みます。共有タスクリストを各自が自律的に取り合う形も、この「境界が動く」作業に噛み合います。
言い換えると、サブエージェントが発注書で回るのに対し、チームは会議で回る。会議が価値を生むのは、議事を事前に発注書へ落とせないときだけです。
「通信できる自由度」はタダではない
ここが「常に上位互換」への直接の反論です。エージェント間通信という自由度は、三つのコストと引き換えです。
- コンテキスト消費: チームメイトはそれぞれ独立した Claude インスタンスで、トークンはチームメイト数に比例して増える。ドキュメントも「単一セッションよりも著しく多くのトークンを使う」「定型作業なら単一セッションの方がコスト効率が良い」と明記しています。
- 制御の難しさ: チームは実験的機能で、既知の制約がある。セッションの再開で in-process のチームメイトが復元されない、タスク完了マークの取りこぼしで依存タスクが詰まる、シャットダウンが遅い、1 セッション 1 チーム、チームメイトはさらに子チームを spawn できない、リードは固定、といったものです。自律協調の裏返しとして、状態が分散し、追いにくくなる。
- 検証の難しさ: エージェントが互いに送り合ったメッセージや、自分たちで claim したタスクは、集約点を一つ通りません。分散した会話のどこで何が確定したかを、後から裏取りするのは高くつきます。
サブエージェントの一方通行は、この裏返しです。司令塔が唯一の集約点であるという制約が、そのまま利点になります。私の運用では、完了報告をそのまま信じず司令塔が本番のレスポンスを独立に検証し（別記事の原則 5）、越権が必要な操作は司令塔が握って人間に上げます（同・原則 4）。この「報告の裏取り」と「権限管理」は、集約点が一つだから単純に書ける。通信経路が網目状に広がると、同じ検証と権限管理が一気に難しくなります。
自由度は、使うときだけ価値になり、使わないときはコストとして残る。だから「P2P できる方が常に強い」は成り立ちません。
判断基準を一つに圧縮する
長く書きましたが、実務では一つの問いに圧縮できます。
指示書が書けるなら、サブエージェント。書けないなら、チームを検討する。
境界を切り出して発注書に落とせるタスク（調査・実装+計測・回収など）は、独立コンテキストで安く、失敗が局所化し、権限を非対称にでき、司令塔一点で検証できるサブエージェントで組む。逆に、事前に境界を書けず、エージェント同士の議論・相互レビュー・競合仮説の突き合わせそのものが成果を左右する作業（原因不明のデバッグ、多視点レビュー、層をまたぐ探索）では、通信コストと制御の難しさを払ってでもチームを検討する。
保守という仕事は、その大半が前者でした。だから今のところ全部サブエージェントで足りています。これは「チーム機能が劣る」という話ではなく、手元のタスクが会議を必要としていない、というだけの話です。
なお、この判断はエージェント運用の設計思想とも地続きです。エージェントにどこまで自律を許し、どこで人間や司令塔が握るかについては「AI エージェントのハーネス設計と自律性」も合わせて読むと、通信自由度のトレードオフが立体的に見えます。
まとめ
- Claude Code のサブエージェントとチーム機能（Agent Teams）は、機能の多寡で並ぶものではなく、ワーカー同士が互いに通信する必要があるかで分かれる別の道具。
- ドキュメントの定義では、サブエージェント = 親にだけ結果を報告する、焦点の定まったワーカー（低コスト）、チーム = 互いに直接メッセージし共有タスクリストを自律協調する対等なエージェント群（高コスト・実験的）。
- サブエージェントの本質は「明確なタスクを切り出し、結果だけ回収する」。境界が書けるなら、小さく安いコンテキスト・失敗の局所化・再現可能な指示書・非対称な権限が手に入る。
- チームの本質は「対等なエージェントが相互通信しながら協働する」。境界を事前に書けず、議論・相互レビュー・競合仮説の突き合わせが価値を生む作業に向く。
- 「P2P できる方が常に強い」は誤り。通信の自由度はコンテキスト消費・制御・検証の難しさとトレードオフで、使わないときはコストとして残る。司令塔が唯一の集約点である方が、報告の裏取りと権限管理が単純になる。
- 一つに圧縮すると、指示書が書けるならサブエージェント、書けないならチームを検討。8 サイト保守を全てサブエージェントで組めたのは、作業の境界を全て発注書に落とせて、班同士が会話する必要が一度も生じなかったから。