Claude Codeの並列実行7つの方法を比較｜おすすめサブエージェント10選つき【2026年8月】

「Claude Codeに作業を頼むと、終わるまで次の指示が出せない」 「並列実行を調べたら、tmuxやgitコマンドの話ばかりで閉じてしまった」

この記事は、そんなあなたのためのClaude Code並列実行ガイドです。公式ドキュメントが定義する並列化の全体像に沿って、7つの方法を「結局どれを選べばいいか」が分かる形で比較します。tmuxは使いません。Windowsのままで大丈夫です。

並列まわりは仕様変更がとても速い領域です。本記事は2026年8月時点の公式ドキュメントに基づき、コマンドの実在確認は手元のClaude Code v2.1.205で行いました（執筆時点で確認した最新版はv2.1.228で、手元はそれより23リビジョン古い環境です）。バージョンで挙動が変わる箇所には都度バージョン番号を添えています。

Claude Codeの基本操作がまだ不安な方は、先にClaude Codeの使い方マスターで土台を固めてからどうぞ。

Claude Codeの並列実行とは？【まず全体像】

Claude Codeの並列実行とは、複数のセッションやサブエージェントを同時に動かし、独立した作業を並行して進めることです。

普段は「1つの会話（セッション）で1つの作業」ですが、やり方を知っていれば「調査はA、実装はB、レビューはC」と同時に走らせられます。Claude Code自体をこれから知る方は、先にClaude Codeとはの解説をどうぞ。

公式が定義する「4つの手段」と「3つの道具」

Anthropicの公式ドキュメントには、並列実行の専用ページ「エージェントを並列実行する」があります。ページの冒頭で、並列化の手段は4つに整理されています（和訳）。

Claude Codeが複数のタスクを同時にこなす方法を比較します：サブエージェント、エージェントビュー、エージェントチーム、動的ワークフロー。

あわせて、手段そのものではなく「並列を支える道具」として、次の3つが挙げられています（英語版の記述です。日本語版はクロスセッション・メッセージングがまだ反映されておらず、2つと書かれています）。

• git worktree：セッションごとに別の作業フォルダを持たせ、ファイルの衝突を防ぐ仕組み
• クロスセッション・メッセージング：別々に動くセッション同士で連絡を取り合う仕組み
• /batch：サブエージェントとworktreeを組み合わせた「パッケージ済みの使い方」

本記事ではこの整理に沿いつつ、読者が実際に選ぶ単位で7つの方法として紹介します（4つの手段＋worktree＋/batch＋スクリプト向けのヘッドレス実行）。

【一覧表】7つの方法をひと目で比較

方法	ひとことで言うと	動かし方	向いている人	難しさ	トークンの重さ
サブエージェント	1つの会話の中で部下に別作業をさせる	「別々のサブエージェントで並行して」と頼む	まず試したい人	★☆☆	軽〜中（減ることも）
エージェントビュー	複数の作業を1画面で見張る	claude agents／claude --bg "…"	複数案件を同時に回したい人	★☆☆	並列数に比例
git worktree	作業フォルダを物理的に分けて複数起動	claude --worktree 名前 を別ターミナルで	ファイル衝突が心配な人	★★☆	並列数に比例
/batch	大きな変更を5〜30本のPRに分割	/batch 指示	gitで開発している人	★★☆	重い
動的ワークフロー	数十〜数百エージェントを台本で回す	ultracode:／/deep-research	大規模な監査・調査をしたい人	★★☆	とても重い
Agent Teams	AI同士が相談しながら進める（実験的）	環境変数で有効化（設定方法）	分担と議論をさせたい人	★★★	とても重い
ヘッドレス（claude -p）	スクリプトから1回ずつ呼ぶ	claude -p "…"	CI/CDに組み込みたい人	★★★	使い方次第

迷ったらこれ：公式の「選び方」の考え方

公式ドキュメントは「誰が作業を仕切るか」で選ぶよう案内しています（和訳・要約）。

• Claudeが1つの会話の中で割り振り、結果を回収する → サブエージェント
• あなたが独立した作業を渡して、あとで様子を見る → エージェントビュー
• Claudeが計画・割り当て・監督まで担う → Agent Teams（実験的）
• 台本（スクリプト）が計画を持って回す → 動的ワークフロー

そのうえで「作業が同じファイルを触るなら、worktreeで分離する」が公式の答えです。まず試すならサブエージェント、複数の案件を同時に回したいならエージェントビュー、と覚えておけば大きく外しません。

【方法1】サブエージェント｜いちばん手軽で、コストの節約にもなる

設定ゼロ。日本語で頼むだけ

サブエージェントは、公式が並列の手段の筆頭に挙げているものです。定義はこうです（和訳）。

1つのセッションの中で動く、委任された作業係。自分専用のコンテキスト（作業机）でサイドタスクをこなし、要約を返します。 （出典：公式ドキュメント「エージェントを並列実行する」）

インストールも設定も要りません。公式ドキュメントの並列リサーチのサンプルを日本語にすると、こう頼むだけです。

それぞれのサブエージェントが独立に調べ、最後にClaudeが結果をまとめます。公式も「調査どうしが依存し合わないときに最も効果的」と説明しています。なお、v2.1.198以降サブエージェントは既定でバックグラウンド（画面に出さず裏で動く形）で実行され、裏の作業はセッション内の /tasks で確認・停止できます。

サブエージェントだけは「コストが減る」使い方がある

並列化は基本的にトークン消費を増やしますが、サブエージェントには例外的な性質があります。公式のコストガイドの案内がこちらです（和訳）。

テスト実行やビルドのような冗長な出力を伴う作業はサブエージェントに委任してください。冗長な出力はサブエージェント側のコンテキストに留まり、メインの会話には要約だけが返ります。

大量のログでメインの会話を汚さずに済む、節約方向の使い方です。逆に詳細な結果をたくさん返させると、サブエージェントの結果はメインの会話に戻るぶんコンテキストを大きく消費し得る、と公式が注意しています。返させるのは要約まで、が鉄則です。

同時に動かせる数の上限【バージョンで違う】

「何個まで同時に動かせるのか」も、公式ドキュメントに明記があります。

これは「同時に20」という上限で、セッション全体で起動できる合計数には上限がありません。

isolation: worktree でファイル衝突を防ぐ

複数のサブエージェントに同時にファイルを書き換えさせたい場合は、定義ファイルに isolation: worktree と書くと、毎回一時的なworktree（分離された作業フォルダ）の中で動くようになります。公式のサンプルがこちらです。

---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---

Apply the requested refactor across every affected file, then run the tests
and report the results.

サブエージェントが変更を加えなかった場合、worktreeは自動で片付けられます。定義ファイルの書き方は、後半の「おすすめサブエージェント10選」でまとめて解説します。

【方法2】エージェントビュー（claude agents）｜複数の作業を1画面で見張る

日本語記事にほぼ載っていない「公式の並列画面」

エージェントビューは、公式が並列4手段の1つに数えている機能です。ターミナルで次を実行すると開きます。

claude agents

公式の定義はこうです（和訳）。

claude agents で開くエージェントビューは、すべてのバックグラウンドセッションを見るための1つの画面です。何が動いているか、どれがあなたの入力を待っているか、どれが終わったか。新しいセッションを送り出し、状態をひと目で見張り、必要なときだけ介入できます。 （出典：公式ドキュメント Agent view）

並列との関係では、次の一文が核心です（和訳）。

ここで入力したプロンプトは、それぞれが新しいセッションとして起動します。（中略）この方法で複数を並列に走らせることができます。

プロンプトを打つたびにセッションが1本増えていく。ターミナルを何枚も開かずに並列を管理できる、非エンジニアの方に最も向いた方法だと筆者は考えています。位置づけはリサーチプレビュー（研究段階での公開）です。

claude --bg で作業を裏に投げる

一覧画面を開かず、コマンドから直接バックグラウンドに投げることもできます。

claude --bg "flakyなSettingsChangeDetectorテストを調査して"

プロンプトはそのまま後ろに書きます（-p と組み合わせる形は受け付けられません）。--name でセッションに名前を付けたり、--agent code-reviewer のようにサブエージェント定義を担当として指定したりもできます。

起動すると、管理用コマンドが次のように案内されます（--name "flaky-test-fix" と名前付きで起動した場合の例。手元のv2.1.205では、これらのコマンドは claude --help の一覧には出てこず、この案内で提示される形でした）。

backgrounded · 7c5dcf5d · flaky-test-fix
  claude agents             list sessions
  claude attach 7c5dcf5d    open in this terminal
  claude logs 7c5dcf5d      show recent output
  claude stop 7c5dcf5d      stop this session

会話の途中から今のセッションを裏に回したいときは、セッション内で /bg を実行します。会話を裏へコピーして手元でも作業を続けたいときは /fork です（v2.1.212以降。それより前のバージョンでは /fork の動きが異なります）。

ファイルの衝突はClaude Codeが自動で防ぐ

「同時に動かしたらファイルの取り合いになるのでは？」という心配には、公式がこう答えています（和訳）。

エージェントビュー・/bg・claude --bg のどれから始めたバックグラウンドセッションも、あなたの作業ディレクトリで開始します。ファイルを編集する前に、Claudeはそのセッションを .claude/worktrees/ 配下の分離されたgit worktreeへ移動させます。並列セッションは同じチェックアウトを読めますが、書き込みはそれぞれ自分専用の場所に行います。

分離の設定を自分で書く必要はなく、書き込みが発生する時点で自動的に隔離されます（作業フォルダがgitリポジトリでない場合などは対象外です）。

使う前に知っておく注意点

【方法3】git worktree｜作業フォルダを分ける、いちばん確実な分離

claude --worktree の1行でOK。手動のgitコマンドは不要

git worktree（ワークツリー）は、同じリポジトリの履歴を共有したまま、ファイル一式をもう1セット持つ別フォルダを作れる仕組みです。セッションごとに別のworktreeで動かせば、編集は絶対にぶつかりません。

多くの解説記事は git worktree add から始まる手動手順を紹介していますが、いまのClaude Codeには専用フラグがあります。

claude --worktree feature-auth

この1行で、リポジトリ直下の .claude/worktrees/feature-auth/ にworktreeが作られ、worktree-feature-auth という新しいブランチでClaudeが起動します。短縮形は -w。名前を省略すると bright-running-fox のような名前が自動で付きます。公式ドキュメントでも、手動のgitコマンドは「特定の既存ブランチをチェックアウトしたいとき」「worktreeをリポジトリの外に置きたいとき」の例外扱いです。

別のターミナルでもう1回叩けば、それが並列

複数起動に対する公式の答えは、拍子抜けするほどシンプルです（和訳）。

別のターミナルで、違う名前を付けて同じコマンドをもう一度実行してください。2つ目の分離されたセッションが始まります。

tmuxのような追加ツールは要りません。Windows Terminalのタブを2枚開き、それぞれで claude --worktree 名前 を実行するだけです。初めて使うフォルダでは、先に一度 claude を普通に起動して信頼確認のダイアログに答えておいてください（済んでいないと --worktree はエラーで止まります）。

.envは自動では持ち込まれない（.worktreeinclude）

worktreeは「まっさらなチェックアウト」なので、gitで管理していない .env のようなファイルは入っていません。プロジェクト直下に .worktreeinclude というファイルを作ってパターンを書いておくと（書式は .gitignore と同じ）、worktree作成時に自動でコピーされます。ただしコピーされるのはパターンに一致し、かつ .gitignore で除外されているファイルだけです。gitで管理しているファイルは元からworktreeに入っているためコピー対象外で、「書いたのにコピーされない」ときはそのファイルがgit管理下にないかを疑ってください。あわせて .claude/worktrees/ を .gitignore に足しておくとメイン側が散らからない、と公式が案内しています。依存パッケージのインストールはworktree側で改めて必要です。

片付けと、Windowsでの注意

対話セッションを終了すると、Claudeがworktreeの中身を確認し、変更もコミットもない名前なしのworktreeは自動削除、それ以外は「残すか消すか」を確認してくれます。-p（ヘッドレス）で作った分だけは自動で片付かないため、git worktree remove で手動削除します。

【方法4】/batch｜1つの大きな変更を5〜30本のPRに分ける

/batch は、セッション内で使うコマンド（正確にはバンドルされたスキル）です。公式の定義を訳すとこうなります。

コードベース全体にわたる大規模な変更を並列で進めます。コードベースを調査し、作業を5〜30個の独立した単位に分解して計画を提示します。承認すると、単位ごとに1つのバックグラウンドサブエージェントを、分離されたgit worktreeで起動します。各サブエージェントは担当分を実装し、テストを実行し、プルリクエストを開きます。gitリポジトリが必要です。 （出典：公式ドキュメント Commands）

使い方は /batch に続けて指示を書くだけで、公式の例は /batch migrate src/ from Solid to React（src/ をSolidからReactへ移行して）です。手元のv2.1.205にも組み込まれていることをプログラム内の文字列で確認しました。

位置づけは公式の言うとおり「サブエージェント＋worktreeのパッケージ済みの使い方」です。gitリポジトリが必須で、最終的にプルリクエストを開くところまで走るため、開発者向けの方法と考えてください。同じ形の修正を大量のファイルへ一括適用したいときに向き、前の結果を待つ作業には向きません。

【方法5】動的ワークフロー（ultracode）｜数十〜数百エージェントを1回で回す

動的ワークフローは、並列4手段の中で最も規模が大きいものです。公式の定義はこうです（和訳）。

動的ワークフローは、サブエージェントを大規模にオーケストレーション（指揮）するJavaScriptのスクリプトです。あなたが説明したタスクに合わせてClaudeがスクリプトを書き、ランタイムがそれをバックグラウンドで実行します。その間もあなたのセッションは操作できます。 （出典：公式ドキュメント Dynamic workflows）

スクリプトを自分で書く必要はありません。プロンプトにキーワード ultracode を含めるか（例：ultracode: src/routes/ 配下のAPIエンドポイントを認可チェック漏れがないか監査して）、「ワークフローで実行して」と自分の言葉で頼めば起動します。

調べもの専用に /deep-research <質問> というバンドル済みワークフローもあり、複数の角度からWeb検索を並列に走らせ、ソースを突き合わせた出典つきレポートを返します。進捗は /workflows で確認できます。

規模の上限は公式に明記されています。同時に動くのは最大16エージェント（CPUコアが少ないマシンではそれ以下）、1回の実行で合計1,000エージェントまで。実行中に追加の指示は出せません。利用条件はv2.1.154以降・全有料プランで、Proプランのみ /config の「Dynamic workflows」の行から有効化が必要です。

【方法6】Agent Teams｜AI同士が相談しながら進める（実験的）

Agent Teams（エージェントチーム）は、複数のClaude Codeを「リーダーと複数のチームメイト」に分けて、1つのチームとして動かす機能です。リーダーが作業を割り振り、チームメイトは共有のタスクリストから仕事を取っていきます。

サブエージェントとの最大の違いは、チームメイト同士が直接メッセージをやり取りしながら進められることです。サブエージェントは結果をメインの会話に報告するだけなのに対し、Agent Teamsでは「調査担当が見つけた情報を実装担当へ直接渡す」ような、人間のチームに近い連携ができます。

ただし、公式ドキュメントの冒頭には "Agent teams are experimental and disabled by default."（Agent teamsは実験的機能で、デフォルトで無効）と明記されています。環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を設定しない限り一切動かず、仕様変更のペースも速い機能です。有効化のコピペ用コードとチームメイトの操作方法は、Agent Teamsの使い方解説にまとめています。

選ぶ基準はシンプルです。メンバー同士の連携や議論が本当に必要な仕事かどうか。結果だけ欲しい作業ならサブエージェントで足ります。

加えてAgent Teamsは、トークン消費が重い手段です。ただし「1回で大量のエージェントが動くから重い」のではなく、チームメイト1人ひとりが独立したClaude Codeとして自分のコンテキストを抱え、終了するまで消費し続けるという意味で重くなります。公式も「使用量は稼働中のチームメイトの人数と、それぞれが動いている時間に比例する」と明記し、対策として「チームを小さく保つ」「終わったチームメイトは終了させる」を挙げています。

表示モード・制限事項・コストの削減策・古い解説記事の誤情報の見分け方も同じ記事で解説しています。実験的機能でバージョンごとの変化も激しいので、試す前に一読することをおすすめします。

【方法7】ヘッドレス実行（claude -p）｜スクリプトやCIから呼ぶ

-p を付けると、Claude Codeを対話画面なしで1回だけ実行できます。公式の例がこちらです。

claude -p "Find and fix the bug in auth.py" --allowedTools "Read,Edit,Bash"

シェルスクリプトに組み込める形なので、「これを複数同時に走らせれば並列になるのでは」と考える方も多いはずです。ただ、ここには知っておくべき事実があります。

スクリプトから呼ぶ用途に公式が推奨しているのは --bare（フックやMCPサーバーなどの自動読み込みを省いて起動を速くするモード）です。ただし --bare はOAuthの認証情報を読まないため、APIキー（ANTHROPIC_API_KEY）の設定が必須で、サブスクのログインだけでは動きません。また --output-format json を付けると、応答の total_cost_usd（クライアント側の推計値で、実際の請求とはずれることがあります）で実行ごとの支出を追跡できます。

【よくある誤解】並列実行にtmuxは必要ありません

公式ドキュメントにtmux並列の手順は載っていない

日本語の解説記事では「tmux（1つのターミナルを複数画面に分割するツール）を入れて、区画ごとにClaude Codeを起動する」という手順がよく紹介されています。

ただし2026年8月時点で、並列実行の公式ページ（agents）・worktrees・agent-view・headlessの各ドキュメントの全文を確認した範囲では、tmuxを使ってClaude Codeを並列起動する手順は公式に存在しません。公式がtmuxに触れているのは、Agent Teamsの「split panes（分割表示）」という表示機能の要件と、次に紹介する --tmux フラグの2か所だけで、どちらも「Claude Codeを何本も並列に立ち上げる手順」ではありません。しかもsplit panesのほうには「tmuxは一部のOSで既知の制限があり、伝統的にmacOSで最もよく動作する」（和訳）という注記まで付いています。tmux前提の並列手順は、公式が用意した道ではなく、コミュニティが編み出した運用と理解しておくのが正確です。

補足すると、--tmux というフラグ自体は実在します。手元のv2.1.205の claude --help にもあり、公式のCLIリファレンスにも「worktree用のtmuxセッションを作る。--worktree が必要」（和訳）と記載があります。ただしこれはworktreeを1つ作るときにtmuxセッションも用意するためのフラグで、複数セッションを並列に起動するためのものではありません。筆者は挙動そのものを検証していないため、本記事では紹介にとどめます。

Windowsの人はどれを選べばいいか

【コピペ可】おすすめサブエージェント10選

もう1つの疑問「どんなサブエージェントを用意すればいいか」に答えます。サブエージェントには最初から組み込まれているもの、公式が定義例を示しているもの、コミュニティで定番化しているもの（自分で作る）の3層があり、本記事では確度の高い順に10個を選びました。

#	名前	どんな作業を任せるか	出どころ
1	Explore	ファイル探し・コード検索・コードベースの調査	組み込み（公式）
2	Plan	計画立案のためのリサーチ（プランモード時）	組み込み（公式）
3	General-purpose	複合的な調査・複数ステップの作業全般	組み込み（公式）
4	code-reviewer	コードの品質・ベストプラクティスのレビュー	公式ドキュメントの定義例
5	debugger	エラーの原因調査と修正	公式ドキュメントの定義例
6	data-scientist	データ分析・集計	公式ドキュメントの定義例
7	database-query-validator	データベースクエリの検証	公式ドキュメントの定義例
8	security-reviewer	セキュリティ観点のレビュー	公式が役名として言及（定義は自作）
9	test-runner	テスト実行と失敗レポート	公式が役名として言及（定義は自作）
10	docs-writer	ドキュメントの作成・校正	コミュニティ定番（自作）

まず知っておく：組み込みサブエージェント（設定不要）

Claude Codeには最初からサブエージェントが組み込まれていて、場面に応じてClaudeが自動で使い分けます。中心になるのは表の上3つです。

• Explore：読み取り専用の高速な調査係。WriteとEditが禁止されているので、コードベースを壊す心配なく探索を任せられます
• Plan：プランモード（実装せず計画だけ立てるモード）中のリサーチ担当。こちらも読み取り専用です
• General-purpose：サブエージェントが使えるすべてのツールを持つ万能型。複数ステップの作業やコード修正まで任せられます

このほかに claude（汎用の受け皿。バックグラウンドセッションの既定の担当でもあります）・statusline-setup・claude-code-guide を合わせた計6種が組み込みです。なお、ExploreとPlanは調査を速く安く保つためCLAUDE.mdを読み込みません。またv2.1.198以降、Exploreは常にHaikuではなく、メインの会話のモデルを引き継ぐ仕様です（Claude APIではOpusが上限）。

公式がドキュメントに定義例を載せている4つ

code-reviewer・debugger・data-scientist・database-query-validator の4つは、公式サブエージェントページの末尾にある「Example subagents」に完全な定義例が掲載されています。そちらのcode-reviewerはレビュー観点のチェックリストまで書き込んだ長めの定義なので、まずは同じページの冒頭に載っている、最小構成のcode-reviewerの公式サンプルから見てみましょう。そのまま .claude/agents/code-reviewer.md として保存すれば、自作サブエージェントの第一歩になります。

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

frontmatter（ファイル冒頭の設定欄）がサブエージェントの性格付け、本文がそのままシステムプロンプト（そのサブエージェントへの指示書）になります。

コミュニティで定番の3つ（自分で作る例）

security-reviewer・test-runner・docs-writer は、公式が定義ファイルを配布しているものではなく、利用者が自分で作る定義の定番パターンです。ただし3つで根拠の強さが違います。security-reviewerとtest-runnerは、公式のAgent Teamsドキュメントに「一度定義すればサブエージェントとしてもチームメイトとしても使い回せる役の例」として名前がそのまま登場します（定義の中身は非掲載）。docs-writerは公式には出てこず、解説記事で定義例が公開されている役で、api-documenter の名前で紹介されることもあります。

ゼロから書かなくても、Claudeに「セキュリティ観点でコードをレビューするsecurity-reviewerというサブエージェントを作って」と頼めば、定義ファイルの作成ごと任せられます。test-runnerのような冗長な出力が出る役割は、方法1の「コストが減る使い方」との相性も抜群です。

定義ファイルの置き場所と主なfrontmatter

自作の定義ファイルは、次の2か所が基本です。

置き場所	有効範囲
.claude/agents/	今のプロジェクトのみ
~/.claude/agents/	すべてのプロジェクト

このほかに管理者設定・起動時の --agents フラグ・プラグインを合わせた5系統があり、同名の場合は「管理者設定 → --agents → プロジェクト → ユーザー → プラグイン」の順で優先されます。ファイルの追加・編集は数秒で自動反映され再起動不要です（その場所に初めてagentsフォルダを作ったときだけ再起動が必要）。

主なfrontmatterフィールドは次のとおりです。

フィールド	意味
name（必須）	識別名。小文字とハイフンで付ける
description（必須）	どんなときに任せるか。Claudeはここを見て委任を判断する
tools	使わせるツールを限定する
model	sonnet／opus／haiku／fable／フルのモデルID、または inherit（既定。呼び出し元と同じ）
isolation	worktree を指定すると一時worktreeで隔離実行
memory	セッションをまたいだ学習メモを有効化
skills	起動時に読み込ませるスキル
mcpServers	使えるMCPサーバーを限定する

skills フィールドでSkillsの手順書を最初から読み込ませたり、mcpServers でMCPの接続先をサブエージェントごとに絞ったりできます。

【注意】/agentsコマンドではもう作れません

古い解説記事には「/agents コマンドの対話ウィザードで作成する」とありますが、このウィザードはv2.1.198で廃止されました。現在の /agents は、Claudeに作成を頼むか .claude/agents/ を直接編集するように、という案内を表示するだけです。ウィザードの手順を載せた記事は、v2.1.197以前の情報だと判断してください。

コストを抑える書き方

公式は、単純なタスクを担当するサブエージェントに model: haiku を指定するコスト管理を案内しています。応用として、Explore という名前で model: haiku のサブエージェントを自作すると組み込みのExploreを上書きでき、探索作業を低コストのモデルに固定できます（これも公式ドキュメント記載のテクニックです）。

並列にすると料金はどうなる？【公式の数字だけで説明】

増えるのは「速さ」だけではなく「使う量」

並列化でいちばん誤解が多いのがここです。公式ドキュメントは、並列全般について、複数のセッションやサブエージェントを同時に動かせばトークン使用量はその分増えると述べたうえで、エージェントビューの制限事項にこう明記しています（和訳）。

レート制限は適用されます。バックグラウンドセッションは対話セッションと同じようにサブスクリプションの使用量を消費するため、10個のエージェントを並列で動かすと、1個のときのおよそ10倍の速さでクォータ（プランの利用枠）を消費します。

かかる時間は短くなっても、こなした仕事の量に応じた使用量は同じようにかかります。並列化は待ち時間を圧縮する技術であって、安く済ませる技術ではないと理解しておくのが安全です。なお、ネット上で見かける「開発速度3倍」「作業時間70%短縮」のような数字には公式の根拠がないため、本記事では引用しません。

手段別の重さ（軽い順の目安）

重さの目安	手段
軽〜中（使い方次第で節約にも）	サブエージェント
並列数に比例	エージェントビュー・worktreeでの複数起動
重い	/batch（5〜30のサブエージェント＋PR作成まで走る）
とても重い	動的ワークフロー（1回で最大1,000エージェント）／Agent Teams（人数ぶん、終了まで消費し続ける）

最後の2つは重くなる理由が違い、公式にもどちらがより重いかを比べた記述がないため、本記事では順位をつけていません。

公式が挙げる節約のコツ

• 単純な作業のサブエージェントには model: haiku を指定する
• テストログのような冗長な出力はサブエージェントに閉じ込め、要約だけ受け取る
• 並列数を欲張らない（10並列は10倍の速さで枠を消費する）

どのプランなら使える？

プラン条件が公式に明記されているのは動的ワークフローだけ（全有料プランで利用可。Proは /config で有効化）で、それ以外の手段には「どのプランから使えるか」という記載自体がありません。確かなのは、Claude Code自体が無料プランには含まれないこと、そして並列実行は使用量を並列数ぶん消費するため、プランの利用上限に普段より早く到達しやすいことです。上限の仕組みとプラン選びはClaude Codeの料金プランで詳しく解説しています。

並列にしても速くならない5つのケース

公式ドキュメントは、並列（Agent Teams）が向かない条件をはっきり書いています。「逐次的なタスク、同じファイルの編集、依存関係の多い作業には、単一セッションかサブエージェントのほうが効果的」（和訳）。この公式の整理を土台に、実務目線の2つを加えた5つのケースをまとめます。

1. 前の結果を使う、順番のある作業：並列にできないので、待ち時間が増えるだけです
2. 同じファイルを複数が書き換える作業：worktreeで分離しない限り、編集が衝突します
3. 依存関係が多い作業：前工程待ちが多発し、並列の意味がなくなります
4. 1つずつが数分で終わる小さな作業：セッションを分ける手間のほうが大きくなります
5. レビューと修正を何往復もする作業：あなたの確認がボトルネックになり、並列でも速くなりません

当てはまる仕事は、無理に並列化せず1つのセッションで進めるほうが結果的に速く、安く済みます。

並列を成功させるコツ：手段より先に「作業の切り方」

どの方法を選んでも、並列がうまくいくかどうかは「タスクをどう切るか」でほぼ決まります。

1. 「触るファイルが重ならない」単位に割る：公式もAgent Teamsについて「各メンバーが別のファイル群を担当するように作業を分割せよ」と案内しており、この原則はどの手段でも共通です
2. 共通ルールを先にCLAUDE.mdへ書いておく：自作サブエージェントやバックグラウンドセッションは作業フォルダのCLAUDE.mdを読み込むため、前提を1か所にまとめると個別の指示が短く済みます
3. 最初は読み取り専用のタスクで試す：調査やレビューのような「読むだけ」の並列なら、ファイル衝突の心配なしに感覚をつかめます

よくある質問（FAQ）

まとめ：まず試すなら「サブエージェント」か「claude agents」

並列実行は、手段を選んで作業の切り方さえ決めれば、tmuxも手動のgitコマンドも要らないところまで公式機能が整っています。まずはサブエージェントへの並列リサーチか、claude --bg で1本裏に投げるところから試してみてください。

並列を本格的に使い始めると、プランの利用上限との付き合い方が次のテーマになります。Claude Codeの料金プランで自分のプランの上限を把握しておきましょう。チームでの分担と議論まで踏み込みたくなったらAgent Teamsへ、基本操作の復習は使い方マスターへどうぞ。