この記事の目次
Claude Codeのエージェントチームとは何か？
Claude Codeのエージェントチームは、リーダー役のエージェントが複数のチームメンバーに作業を割り振り、共有のタスクリストで進捗を管理しながら並行して作業を進める仕組みである。1つの指示に対して1つのエージェントが順番に処理していく通常の使い方とは異なり、複数の担当が同時に動く点が特徴になる。
似た言葉に「サブエージェント」がある。サブエージェントは特定の役割(コードレビュー担当、テスト担当など)を持つ個別のエージェントを定義する仕組みで、エージェントチームはそのサブエージェントを含む複数のエージェントを、1つのタスクリストの下でどう束ねて動かすかという運用側の話にあたる。サブエージェントを自分で作る手順は本記事では扱わないので、サブエージェントの作り方を先に押さえておくと理解が早い。Claude Codeがそもそもどういうループでタスクを進めるかはエージェントの動作原理にまとめている。
エージェントチームは何から始めればいいのか？
エージェントチームを試すには、設定ファイルで機能を有効にしたうえで、CLIから最初のチームを起動するという2段階の準備が必要になる。具体的な設定項目名やコマンド名はアップデートで変わる可能性があるため、公式ドキュメントの該当ページと合わせてsettings.jsonの基本的な書き方、CLIの基本操作を確認しながら進めるのが確実である。
本記事の対象は有効化そのものではなく、有効化した後に「何をどう分担させるか」という判断の部分にある。設定の細部まで踏み込むと既存の解説記事と重複してしまうため、ここでは「まず試せる状態にする」という最低限の案内にとどめる。
どんなタスクならチームに分担する価値があるのか？
分担に向くタスクは、タスク同士が独立していて、担当範囲を一文で説明でき、成果物が重ならないという3条件を満たすものである。逆にこの条件が崩れていると、並行して動かしてもかえって手戻りが増える。
公式ドキュメントでは、複数のファイルにまたがるコードレビューを並行して進めるケースや、1つの問題に対して複数の仮説を同時に検証するケースが挙げられている。どちらも「担当が重ならない」「途中経過を待たずに進められる」という共通点を持つ。個人開発の小さなリポジトリでも、法人の開発チームが抱える規模の大きいプロジェクトでも、この見極め軸自体は変わらない。
| 比較軸 | 分担に向くタスク | 分担に向かないタスク |
|---|---|---|
| タスク間の独立性 | 互いの結果を待たずに進められる | 片方の出力がもう片方の入力になる |
| 成果物の重なり | 触るファイルや領域が分かれている | 同じファイルや同じ設計判断に触れる |
| 担当範囲の説明のしやすさ | 一文で言い切れる | 説明すると複数の条件が混ざる |
なぜ分担がうまくいかなくなるのか？
分担がうまくいかなくなる原因は、同一ファイルへの同時書き込み、暗黙の依存関係、担当範囲の粒度が粗すぎることの3つに整理できる。この節では原因の理解に絞り、対処のためのチェックは次の見出しで扱う。
1つ目は、複数のメンバーが同じファイルを同時に編集しようとして競合が起きるケースである。エージェントチームは並行して動くため、担当範囲が事前に分かれていないと、この衝突は起きやすくなる。2つ目は、あるタスクの結果が別のタスクの前提になっているのに、両方を同時に投げてしまうケースである。片方が未完了のまま、もう片方が誤った前提で進んでしまう。3つ目は、担当範囲を「フロントエンドを直しておいて」のように大きくくくりすぎるケースで、この場合は結局どこまでを誰が触るかがエージェント任せになり、後から見て責任範囲が曖昧になる。
これらはいずれも、リーダー役が最初にタスクを割り振る段階の設計に起因する構造的な問題であり、実行中に偶発的に起きる不具合とは性質が異なる。
着手前に何を確認すればトラブルを避けられるか？
前節の3つの原因に対応する形で、着手前に次のチェックを「はい/いいえ」で自己診断すると、分担の破綻をある程度事前に防げる。
- 各メンバーが触るファイルやディレクトリが重なっていないか
- あるタスクの出力を別のタスクが前提にしていないか(依存関係があるタスクを同時に投げていないか)
- 担当範囲を一文で説明できる粒度まで分割できているか
- 破壊的な変更(ファイル削除、設定変更など)を伴うタスクには承認フローを設定したか
- 途中経過を確認せずに最後まで走らせても問題ない範囲か
「いいえ」がある項目は、チームに投げる前にタスクを分割し直すか、担当範囲を書き直すことで解消できる場合が多い。前節が原因の理解、この節が実行前の確認という役割分担になっている点は意識しておくとよい。
リーダーはメンバーにどう指示を出せばいいのか？
エージェントチームへの指示は、担当範囲・成果物の粒度・依存関係の有無・完了条件という4要素を含めると、メンバー間の衝突を減らせる。この4要素をそのままテンプレートとして使うと、着手前チェックとも噛み合わせやすい。
担当範囲: [触ってよいファイル・ディレクトリを明示]
成果物の粒度: [完成として提出してほしい単位。関数単位/ファイル単位/機能単位など]
依存関係: [他のメンバーの完了を待つ必要があるか。あるなら何を]
完了条件: [レビュー観点やテストの通過など、完了とみなす基準]たとえば「ユーザー認証まわりのAPIエンドポイントを修正する」というタスクなら、担当範囲を src/api/auth/ 配下に限定し、成果物の粒度を「エンドポイント単位でのプルリクエスト」とし、依存関係を「データベーススキーマの変更が別メンバーで進んでいる場合はそれを待つ」と書き、完了条件を「既存のテストが通ること」とする、といった具合になる。曖昧な一文の指示よりも、この4要素を埋める形で指示文を組み立てるほうが、後から担当範囲のずれに気づいて手戻りするリスクを減らせる。指示文の設計そのものについてはプロンプトの書き方も参考になる。
権限やコストはどう変わるのか？
エージェントチームでは、権限の設定がチーム全体の動きに影響し、複数のエージェントが並行して動く分だけトークンの消費も単一エージェントの場合より増える傾向がある。ただし具体的な数値や仕様は更新される可能性があるため、断定的な数字をここに書く代わりに、確認の手順を示しておく。
権限まわりは、破壊的な操作(ファイル削除、外部への書き込みなど)を含むタスクをチームに任せる前に、セキュリティ設定の確認方法で承認フローの設定状況を見ておくと安心できる。トークンの消費量については、トークン使用量の確認方法を使って、チームを起動する前後で実際の消費量を自分の環境で確認するのが確実である。企業のプロジェクトで継続的にエージェントチームを使う場合は、この確認を毎回のワークフローに組み込んでおくと、想定外のコスト増に気づきやすい。
まとめ
エージェントチームの分担設計は、タスクの見極め、構造的な原因の理解、着手前チェック、指示文の型という4つの視点をそろえると、自己診断できる状態になる。ここまでの内容を自分の言葉で説明できれば、本記事の完了条件は満たしている。
ただし、ここで得た型を自分のプロジェクトにそのまま当てはめようとすると、担当範囲の切り方やタスクリストの粒度で迷う場面が出てくる。月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」では、こうした設計の型を自分の手で試しながら身につけていける。