Agent Teamsのチームサイズとタスク粒度の決め方

Agent Teamsは何人から始めるべきか

Agent Teamsの人数に上限は決められていません。何人でもスポーンできます。ただし公式ドキュメントは、ほとんどのワークフローで3〜5人から始めることを勧めています。トークンコストがチーム人数に比例して増える一方、人数を増やしても速度は比例して伸びないからです。

チームを組むと、リード役のセッションに加えて各チームメイトが独立したコンテキストウィンドウを持ちます。5人のチームなら5人分のコンテキストが同時に走り、消費トークンはリード単体の何倍にもなります。調整コスト(誰が何をしているかの把握、メッセージのやり取り、衝突の回避)も人数分だけ確実に膨らむのが実情です。人数を増やせば速くなるとは限りません。一定の人数を超えると、追加のチームメイトが仕事量に比例して作業を速めてくれるわけではないからです。3人に絞って集中させたチームが、5人に分散させたチームより速く終わることは珍しくありません。

15件の独立したタスクがあるなら、3人のチームメイトから始めるのが妥当な出発点です。テストが必要なタスクなら、一人がセキュリティ観点、一人がパフォーマンス観点、一人がテストカバレッジ観点を担当する、というように役割で分けるとチームサイズの決定が具体的になります。人数を先に決めるのではなく、独立して進められる観点がいくつあるかを数えるほうが、遠回りに見えて早く適正値に着地します。

タスクの粒度は「1つの明確な成果物」を基準に切る

タスクが大きすぎても小さすぎても、Agent Teamsは機能を発揮しません。小さすぎるタスクは、チームメイトへの割り当てや報告の調整コストが、そのタスク自体の作業量を上回ってしまいます。逆に大きすぎるタスクは、チームメイトが長時間チェックインなしに走り続け、方向性がずれたときの手戻りが大きくなります。

ちょうどよい粒度は、1つの関数、1つのテストファイル、1件のレビューのように、単独で完結した成果物を生むタスクです。この基準に沿って切ると、チームメイトがどこまで終われば完了かを自分で判断でき、リードも進捗を追いやすくなります。

1人あたり5〜6タスクを持たせておくと、全員が手持ち無沙汰にならず、誰かが詰まったときにリードが再配分しやすくなります。リードが十分な数のタスクを作れていないと感じたら、「もっと細かく分けて」と指示すると、リードがタスクを切り直します。

タスクの割り当て方には2通りあります。リードが「このタスクはこのチームメイトに」と名指しする明示割り当てと、チームメイトが1つ終えるたびに未着手のタスクを自分で拾う自己申告です。粒度を均等にそろえておけば自己申告に任せても偏りが出にくく、逆に粒度がばらついているチームでは、重いタスクだけが最後まで残りやすいので明示割り当てのほうが安定します。

チームサイズとタスク粒度を同じ数式で考える

チームサイズとタスク粒度は、別々に決める設計変数ではありません。総タスク数 ÷ 1人あたり5〜6タスクという単純な割り算が、そのままチームサイズの妥当な目安になります。

15件のタスクなら15÷5=3人、24件のタスクなら24÷6=4人が出発点です。この数字が公式推奨の「3〜5人」の範囲に自然に収まるのは偶然ではありません。タスクを適切な粒度で切れていれば、チームサイズはほぼ自動的に決まります。逆に、この式から逆算して3人チームに対する切り出しタスク数が極端に少ない(5件未満)なら、タスクが大きすぎる兆候です。分割を検討する余地があります。

Agent Teamsには階層構造がありません。チームメイトは自分のチームメイトを持てず、リードだけがチーム全体を管理します。つまりタスクを深くネストして「サブチームに投げる」という設計はできず、フラットなタスクリストの中で粒度をそろえる以外に選択肢がないということです。この制約を先に理解しておくと、粒度設計で迷う場面が減ります。深い階層を前提にした設計は最初から候補に入れなくて済みます。

コンテキストを渡すときのチェックリスト

チームメイトはプロジェクトのCLAUDE.md、MCPサーバー、Skillsを自動で読み込みますが、リードの会話履歴は一切引き継ぎません。渡せる情報は、起動時のプロンプトに書いた内容だけです。

そのため、チームメイトを起動する指示には次を含める必要があります。

• 対象範囲(どのディレクトリ・どのモジュールか)
• 重点的に見るべき観点(セキュリティなら何を、パフォーマンスなら何を)
• 前提となる技術的な事実(認証方式、使用しているライブラリなど)
• 期待する報告の形式(重要度付きの一覧か、Yes/No判定か)

「認証まわりを見て」ではなく、「src/auth/のトークン処理・セッション管理・入力検証を確認し、重要度付きでissueを報告して。JWTはhttpOnly cookieに保存している前提」まで書き込むと、チームメイトは追加の質問なしに動き出せます。曖昧な指示は、チームメイトが的外れな範囲を調べ直す手戻りに直結します。

モデルの使い分けもチーム設計の一部

チームサイズを増やすとトークンコストが線形に増えることは既に触れましたが、コストは人数だけでなくチームメイトごとのモデル選択でも調整できます。全員をOpusで揃える必要はなく、探索や下調べを担うチームメイトはSonnetに、最終的な統合判断を担うリードだけをOpusにする、といった配分が可能です。

Claude Codeがチームメイトのモデルを決める優先順位は次のとおりです。

1. CLAUDE_CODE_SUBAGENT_MODEL環境変数がinherit以外に設定されていれば、それを使う
2. スポーンプロンプトの中でチームメイトごとに名指ししたモデル
3. Sub-agent定義から起動したin-processチームメイトなら、その定義のmodel
4. どれも指定がなければリードの現在のモデルを引き継ぐ

「4人チームでリファクタリングして、各チームメイトはSonnetを使って」のように、プロンプトの中でモデルまで指定できます。組織のavailableModels許可リストで弾かれた場合、Anthropic APIとClaude Platform on AWSでは、opusのようなファミリー名は許可リスト内の最新版に置き換わります。プロバイダ固有のモデルIDを使う面ではこの置き換えが働かず、リードのモデルにフォールバックします。effort(思考の深さ)は個別指定できず、チームメイトは全員リードのeffortレベルを引き継ぐ点も、コストを見積もるときに押さえておく必要があります。effortの調整そのものはeffortレベルの設定で個別に扱っています。

in-processチームメイトへのリクエストは、メイン会話のプロンプトキャッシュTTLバケットから外れ、既定では5分でキャッシュが切れます。1時間キャッシュを保ちたい場合はsubagentPromptCacheTtlを1hに設定すると、チームメイトのコストをさらに抑えられます。

待つこと・見守ることも設計の一部

チームサイズとタスク粒度を正しく決めても、運用の仕方を誤ると効果は薄れます。運用上の注意点は次の3つです。

リードが待たずに自分で実装を始めてしまうことがあります。これはチームメイトの作業と競合するため、「チームメイトの完了を待ってから進めて」と明示的に指示して止める必要があります。

ファイルの競合も典型的な失敗パターンです。2人のチームメイトが同じファイルを編集すると、片方の変更が上書きされます。タスクを切る段階で、担当するファイル群が重ならないようにしておくのが唯一の予防策です。

放置しすぎるとチームは無駄な作業を積み重ねます。定期的に進捗を確認し、うまくいっていないアプローチは早めに軌道修正することが、チームサイズの大小にかかわらず必要です。初めてAgent Teamsを使うなら、コードを書かせるタスクより先に、PRレビューやライブラリ調査のような境界の明確な調査タスクから試すと、実装の衝突リスクなしに感覚をつかめます。

TeammateIdle Hooksを使えば、チームメイトが作業を終えようとしたタイミングでチェックを挟み、基準を満たしていなければ終了をブロックしてフィードバックを返せます。人手での監視を減らしたい場合の選択肢です。

Sub-agentsで足りるときは無理にチームを組まない

チームサイズをどれだけうまく設計しても、そもそもAgent Teamsが向かない作業には向きません。Sub-agentsは1つのセッション内で完結しますが、独立したコンテキストウィンドウを持ち、リードの会話履歴とは分離された状態で結果だけを返します。順番に進めるタスクや、同じファイルを触るタスクは、Sub-agentsや並列サブエージェントのほうが調整コストなく速く終わります。

Agent Teamsが優位に立つのは、複数の観点が本当に独立して進められる場面に限られます。新機能の異なるモジュールをそれぞれ別のチームメイトに任せる、フロントエンド・バックエンド・テストを同時並行で進める、といったケースです。チームサイズを決める前に、そもそも独立した観点が何個あるかを数える作業に立ち返ると、SubagentsとAgent Teamsのどちらを使うべきかも同時に判断できます。

まとめ

Agent Teamsのチームサイズは「3〜5人」という数字だけを覚えるより、総タスク数を1人あたり5〜6タスクで割った値として導くほうが実務で使いやすい目安になります。粒度は関数・テストファイル・レビューのように単独で完結する成果物を基準に切るのが基本です。チームメイトには会話履歴が引き継がれない前提で、スポーンプロンプトに文脈を書き込みます。ファイル競合を避ける役割分担と、放置しすぎない見守りを組み合わせれば、人数を増やすこと自体を目的にせずに済みます。