Claude Codeの同時実行agent数を安全に決める

結論：最大値ではなく、最初は小さな並列数で測る

根拠はClaude Code公式changelog、公式subagents、公式agent teamsです。最新更新の機能を、単なる速度競争ではなく監督可能な業務設計へ接続します。

並列化する前に実行単位を比較する

単位	向く課題	先に固定する境界
Workflow fan-out	独立した推論・調査をまとめる	同時数、入力、集約者
subagent	検索やレビューを別contextへ分離	tool、model、permission
agent teams	複数sessionを協調させる	共有task、通信、停止担当
CI worker	決められた検証を反復する	queue、secret、artifact保存

公式subagents文書は、subagentが独自context、system prompt、tool access、permissionで動き、メイン会話の文脈を節約すると説明します。agent teamsは複数sessionを一か所で監督する仕組みで、単一session内のsubagentと同一視できません。どの並列化でも、書き込み対象を分ける、結果のschemaを固定する、最後に人または親agentが統合する、という三つを先に決めます。

同時数を上げる前に見る4つのボトルネック

第一は推論の上限です。agent数を増やしても、同じAPIのrate limit、modelの利用枠、Gatewayの待ち時間で全体が伸びる場合があります。第二は共有repositoryです。複数agentが同じファイル、lockfile、生成物を変更すると、速さではなくmergeと再実行が増えます。第三は外部サービスです。MCP、GitHub、GitLab、データベースの同時接続には先方の制限があります。第四は人間のレビューです。並列結果を読める人数が一人なら、出口にqueueができます。

料金も別管理です。公式changelogは設定の最大範囲を示しますが、モデル料金、providerの利用枠、Workflowの追加費用を一律に約束する情報ではありません。実測では成功task数だけでなく、入力・出力token、retry、失敗、待機、レビュー時間、外部APIエラーを記録します。最大値を上げて総費用が増えた場合、速度改善が採算に合うかを業務単位で判断します。

導入手順：2から始めて上限を決める9ステップ

1. claude --versionとchangelogの対象versionを記録し、設定名を認識する実装か確認します。
2. 一つのtaskを独立したread-only調査、テスト、文書化などに分割し、同一ファイルを書かない形にします。
3. 各agentの入力schema、出力schema、model、permission、使用tool、禁止操作を台帳へ登録します。
4. CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS=2で非破壊のfixtureを実行し、成功、retry、rate limit、全体時間を記録します。
5. 4へ増やす前に、同時agentが同じbranch、worktree、MCP serverへ触れていないか確認します。
6. 2、4、8の順で一条件ずつ比較し、成功率、品質、token、外部エラー、レビュー時間を表にします。
7. agent teamsやsubagentを使う場合は、同じ数値が適用されると仮定せず、各公式文書の実行モデルを確認します。
8. 停止条件としてrate limit、重複編集、schema不一致、secret検出、レビューqueue超過を数値で定義します。
9. 採用値、例外、rollback、version更新時の再測定日をmanaged settingsや運用READMEの正本へ記録します。

既存のsubagentのモデル優先順位、遠隔subagent監督、maxEffortLevelの記事と組み合わせると、同時数だけでなく「誰を、どのmodelで、どの深さまで動かすか」を整理できます。並列数、モデル、努力上限を一度に変更すると原因が分からないため、変更は一項目ずつにします。

特に本番の書き込みを含むfan-outでは、並列数を増やす前にread-only調査を分離します。調査結果を親agentが採用し、変更は一つの作業者だけが行う構成なら、競合と承認の経路を短くできます。独立性を説明できないtaskは、速度よりも安全性を優先して直列化するのが判断の出発点です。

チェックリスト：fan-outを本番へ広げる前に

□対象versionを記録した　□Workflowとsubagentとteamを区別した　□同時数を1〜256の範囲で確認した　□独立した入力と書き込み境界がある　□同じMCPやAPIのrate limitを確認した　□retryと失敗を数えた　□tokenと実行費用を実測した　□review担当と集約schemaがある　□secretと破壊操作の停止条件を決めた　□rollbackと再測定日を決めた。

よくある質問

256にすれば速くなりますか？

保証されません。推論、API、repository、レビューがボトルネックになるため、2、4、8などで同じfixtureを測定します。

設定名は何ですか？

公式changelog 2.1.269の表記はCLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTSです。手元のversionで認識と適用範囲を確認してください。

agent teamsと同じですか？

同じとは限りません。sessionの数、通信、task共有、停止方法が異なるため、対象機能別に検証します。

公式情報と無料診断

設定名と上限は公式changelog、subagentのcontextと権限は公式subagents、複数sessionの監督は公式agent teamsを公開直前にreadbackしました。Miraigentの無料診断では、並列化する業務、停止条件、レビューqueue、費用計測を一枚の導入表へ落とし込みます。