Claude Code のチーム機能とサブエージェントの使い分け
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 サイト保守を全てサブエージェントで組めたのは、作業の境界を全て発注書に落とせて、班同士が会話する必要が一度も生じなかったから。