Claude Codeの並列実行・並列開発のやり方と使い分け

Claude Codeにタスクを頼むと、終わるまで数分から数十分待つことになります。待っている間に別のタスクも進められれば、1日に片付く量は大きく変わります。

ただ、Claude Codeで並列に動かす方法はいまや何通りもあり、どれを使えばいいか迷いやすくなっています。この記事では、公式ドキュメントにある方法を一覧にして使い分けを整理します。後半では、toneの開発チームが毎日回している並列開発のやり方と、実際に詰まったところを紹介します。

タスクごとに作業フォルダを分ければ、エージェントを同時に動かせる

なお、Claude Codeの機能は変わるのが早いので、この記事の内容は2026年11月時点のものです。

Claude Codeで並列に動かす方法の一覧

公式ドキュメントの「エージェントを並列実行する」では、複数のタスクを同時に進める方法として5つを挙げています。これに、よく組み合わせて使う仕組みを足すと次のようになります。

どの方法でも、同時に動かすほどトークンの使用量は増えます。公式ドキュメントも、複数のセッションやサブエージェントを同時に動かすとトークンの使用量が倍増すると注意しています。

ここからは、よく使うものを順に見ていきます。

複数のセッションとgit worktree

いちばん基本になるのが、ターミナルやアプリでClaude Codeのセッションを複数開くやり方です。このとき問題になるのが作業フォルダです。同じフォルダで2つのセッションがファイルを書き換えると、お互いの変更がぶつかります。

そこで使うのがgit worktreeです。1つのリポジトリから、ブランチごとに別の作業フォルダを作れます。Claude Codeにはworktreeを作って起動するオプションがあります。

claude --worktree feature-auth

-wと短く書くこともできます。worktreeは.claude/worktrees/feature-auth/に作られ、worktree-feature-authというブランチで作業が始まります。名前を省くと自動で名前が付きます。

公式ドキュメントにある、知っておくと便利な点は次のとおりです。

• 片付け：名前を付けずに始めたセッションで変更がなければ、終わるとworktreeとブランチが自動で消えます。変更が残っているときは、残すかどうかを聞かれます
• gitignoreされたファイル：.envのようにgitignoreしているファイルは、そのままではworktreeにありません。.worktreeincludeに書いたパターンに一致するものはコピーされます
• PRから始める：claude --worktree "#1234"で、そのPRの変更を取り込んだworktreeを作って始められます

デスクトップアプリでも、セッションを始める前に「Worktree」をオンにすれば、セッションごとに別のworktreeで動きます。

サブエージェント

サブエージェントは、1つのセッションの中で作業を分けて任せる仕組みです。サブエージェントは自分の作業を終えると、結果の要約をメインのセッションに返します。

調べ物を手分けさせるのに向いています。たとえば「認証まわりとDBまわりを別々に調べて」と頼めば、それぞれの調査が並列に進み、メインのセッションには要点だけが戻ります。メインの会話が細かいログで埋まらないのも利点です。

サブエージェントの定義にisolation: worktreeと書くと、そのサブエージェントは自分専用のworktreeで作業します。実装を並列で任せるときはこれを使います。

エージェントビュー

エージェントビューは、バックグラウンドで動いている複数のセッションを1つの画面で見渡す機能です。claude agentsで開きます。claude --bg "<指示>"とすれば、ターミナルからセッションをバックグラウンドで始められます。

2026年11月時点ではリサーチプレビューです。

エージェントチーム

エージェントチームは、リーダー役のセッションが複数のメンバーをまとめて進める仕組みです。メンバー同士で直接やり取りもできます。

実験的な機能で、デフォルトでは無効です。使うときはsettings.jsonのenvに"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"を書きます。チームを作るコマンドはなく、「3人のメンバーで別々の角度から調べて」のように自然な言葉で頼みます。

公式ドキュメントは、メンバーは3〜5人から始めるよう勧めています。また、メンバーはworktreeで分けられないので、ファイル単位で担当を分けるよう書かれています。調整の手間がかかるぶん、1つのセッションよりもかなり多くのトークンを使う点にも注意が必要です。

/batchと動的ワークフロー

同じ種類の変更を大量に行うなら/batchが便利です。コードを調べて作業を5〜30の独立した単位に分け、承認すると単位ごとにworktreeでサブエージェントを動かします。各サブエージェントは実装してテストを実行し、PRを作るか、何が起きたかを報告します。

/batch migrate src/ from JavaScript to TypeScript

動的ワークフローは、もっと大きな仕事向けです。多数のサブエージェントの動かし方をスクリプトにして、結果を確かめながら進めます。/deep-research <質問>で調べ物に使えるほか、プロンプトにultracodeと書いても始まります。

クラウドとデスクトップアプリ

手元のPCを使わずに並列で動かすならクラウドが手軽です。claude --cloud "<指示>"を実行するたびに、独立したクラウドのセッションが1つ作られます。セッションごとに、Anthropicが管理する別々の仮想マシンで動くので、作業フォルダの衝突を気にする必要がありません。ブラウザのClaude Code on the webからも使えます。

デスクトップアプリでは、サイドバーの「+ New」で新しいセッションを開き、複数のセッションを並べて表示できます。

どれを使えばいいか

やりたいことから選ぶと、次のようになります。

迷ったら、まず「複数のセッション＋worktree」から始めるのがおすすめです。仕組みが単純で、何が起きているかを追いやすいからです。

並列にしてよいタスク、しないほうがよいタスク

方法を選ぶ前に、そもそも並列にしてよいタスクかを見分ける必要があります。worktreeでフォルダを分けても、最後にmainへマージするときに衝突すれば手戻りになります。

並列にしないほうがよいのは、次のようなタスクです。

• 同じファイルを大きく書き換える：マージするときに衝突します。1つのタスクにまとめるか、順番に進めます
• 片方の結果をもう片方が使う：APIを作るタスクと、そのAPIを呼ぶ画面を作るタスクは、APIが決まってからでないと進められません
• 共有の環境を変える：共有のDBにマイグレーションを適用するような作業は、並列で動かすと危険です。人が確認してから順番に進めます

逆に、触るファイルが重ならず、片方の結果を待たずに進められるタスクは並列に向いています。バグ修正と別画面の改善、ドキュメントの更新などです。

toneの開発チームが毎日回している並列開発

ここからは、toneの開発チームで筆者が毎日回している並列開発を紹介します。Claude Codeを使っているのは筆者1人ですが、この1か月でClaude Codeに作ってもらったPRは170本を超えました。

流れ

依頼はPCから出すこともあれば、外出先からスマートフォンで出すこともあります。どちらの場合も、受け取ったClaude Codeのセッションが司令塔になり、次の流れで最後まで進めます。

1つの依頼をPRとスクリーンショットまで仕上げる流れ

1. 計画：依頼をタスクに分け、タスクごとにブランチ名と使うポートを決めます
2. worktreeを作る：タスクごとにorigin/mainからworktreeを作ります
3. 実装してPRを作る：タスクごとに実装用のサブエージェントを立て、それぞれのworktreeで実装、テスト、PRの作成まで進めます
4. 別のエージェントがレビューする：実装とは別のエージェントがPRをレビューし、指摘をPRにコメントします
5. 指摘を直して動作確認する：実装したエージェントが指摘を1つずつ判断して直し、ブラウザで画面を確かめてスクリーンショットをPRに貼ります
6. 片付ける：push済みで未コミットの変更がないことを確かめてから、worktreeを消します

人がするのは、最初の依頼と、最後にPRを見てマージするかどうかの判断です。この手順はClaude Codeのスキルとしてリポジトリに置いてあり、「実装して」「直して」と頼めば毎回同じ流れで進みます。

レビューの指摘への対応がPRに残る

たとえばあるPRでは、レビュー用のエージェントから9件の指摘が付きました。実装したエージェントはそのうち7件を直し、残りの2件は理由をPRのコメントに書いて見送っています。

指摘ごとに「直したか、見送ったか、なぜか」が残るので、人はこのコメントと動作確認のスクリーンショットを見れば、マージしてよいかを判断できます。並列で何本ものPRが届いても、1本ずつコードを最初から読み直さずに済みます。

回してみて分かった詰まりどころ

並列開発を毎日回すなかで、いくつも詰まりました。worktreeを作るだけでは解決しない、運用の問題です。

• ポートがぶつかる：worktreeごとに開発サーバーを立てると、同じポートを取り合います。タスクに番号を振り、フロントエンドは3010番台、バックエンドは8090番台というように番号からポートを決めています
• 依存パッケージの準備が遅い：worktreeは新しい作業フォルダなので、node_modulesがありません。毎回npm ciすると時間がかかり、容量も1本あたり1GBを超えます。シンボリックリンクで共有すると、ツールによっては正しく動きません。いまはmacOSのAPFSのクローン機能で、容量をほとんど使わずに複製しています
• ディスクが足りなくなる：ビルドのキャッシュなどで、worktree1本あたり数百MBを使います。始める前に空き容量を確かめ、足りなければ始めないようにしています
• 同時に動かすのは4本まで：本数を増やすと、開発サーバーやビルドでマシンが重くなり、PRを確かめる人の手間も増えます。両方を考えて上限を4本にし、超えるときは前のタスクが終わるのを待ってから次を始めます
• ほかの作業を壊さない：別のセッションが作業中のworktreeや、本体のチェックアウトには触らないよう、エージェントへの指示に明記しています。片付けのときも、自分が作ったworktreeだけを消します
• 共有の環境は人が確認する：開発用の共有DBへのマイグレーションや本番に影響する操作は、実行する前に必ず人に確認します

どれも、1本だけ動かしているときには起きなかった問題です。並列にする本数を増やす前に、ここを決めておくと手戻りが減ります。

並列にすると「どれが終わったか」が分からなくなる

並列で動かす本数が増えると、今度は人の側の管理が大変になります。どのタスクを頼んだか、どれが終わってレビュー待ちか、どれが止まっているかを覚えておくのは難しくなります。

並列で動かしているタスクが進行中か未着手かを、リストでひと目で確かめられる

toneの開発チームでは、多くの依頼をtoneのタスクとしてClaude Codeに渡しています。Claude CodeはMCPでtoneにつながっていて、作業を始めるとタスクを「進行中」にし、PRのURLや作業の要約をタスクのコメントに書き戻します。チームのメンバーはtoneのリストを開けば、どのタスクが誰のエージェントでどこまで進んでいるかが分かります。

エージェントの着手から完了報告までが、タスクのアクティビティに残る

設定の手順は「Claude Codeのタスク管理をMCPを使ってチームで共有する」で紹介しています。並列で動かすツールの移り変わりは「Vibe Kanban終了で振り返るAIコーディングのタスク管理」にまとめています。

おわりに

Claude Codeの並列実行の方法を整理し、toneの開発チームでの回し方を紹介しました。

まずは複数のセッションとworktreeで、触るファイルが重ならないタスクを2本同時に動かすところから始めてみてください。本数を増やすときは、ポートや依存パッケージ、同時に動かす本数の上限を先に決めておくと詰まりにくくなります。