TL;DR（要約）: 複数のClaude Codeエージェントを並行実行するには、各セッションに専用のgit worktreeを割り当て（claude -w <name>ならフラグ1つで作成可能）、直接監視しないセッションはclaude --bgでバックグラウンドに回し、エージェントの作業が完了する前にマージの順序を決めておきます。ブランチを分離していても、統合時には競合が発生するためです。1つのチェックアウトを2つのセッションで共有すると、あるエージェントのコミットにもう一方の書きかけコードが混ざってしまう原因になります。本ガイドは、すでにClaude Codeを利用しており、2〜5個のセッションを同時に動かしたい開発者を対象としています。
始まりは2つ目のターミナルです。1つ目のターミナルでClaude Codeに認証モジュールのリファクタリングをさせている間に、別のターミナルを開いて新しいセッションに不安定な日付テストの修正を依頼します。さらに3つ目を開いてドキュメントの更新も頼むとしましょう。20分後、3つのセッションが同一のワーキングディレクトリに書き込みを行い、git statusには指示した覚えのないファイルが並び、どのセッションがconfig.tsを変更したのか誰にも分からなくなってしまいます。
複数のClaude Codeエージェントを動かすこと自体は簡単です。ターミナルを増やせば済みます。しかし、セッション同士がお互いの作業を壊さないように実行するには、3つの判断が必要です。各セッションのファイルをどこに配置するか、直接画面を見ていないセッションの状況をどう把握するか、そして作成されたブランチをどの順序でマージするかです。本記事では、Claude Codeの組み込みコマンドと、検証用のリポジトリで再現した2つの失敗例を交えて、この3つのポイントを解説します。git worktreeを初めて使う方は、まずAIコーディングエージェントのためのgit worktree解説ガイドやgit worktreeのリファレンスをご覧ください。
チェックアウトの共有で複数のClaude Codeエージェントが破綻する理由
複数のClaude Codeエージェントを並行実行するとは、同一リポジトリに対して2つ以上のセッションが同時に作業を行い、それぞれが独自のタスクと独自のコンテキストウィンドウを持つ状態を指します。セッション同士はお互いの存在を認識していません。各自がまるで自分しかいないかのようにファイルを読み、編集し、テストを実行し、コミットします。
1つのチェックアウトには、1つのワーキングディレクトリ、1つのインデックス、そして1つのHEADしかありません。そのため、「自分しかいないかのように振る舞う」アプローチはすぐに破綻します。私たちは、検証用のPythonリポジトリにおいて、エージェントに見立てた2つのシェルスクリプトで最もありがちな失敗を再現しました。エージェントBは書きかけのtruncate()をtextutils.pyに保存しています。一方、エージェントAは別のファイルで自分のタスクを終え、多くのプロンプトが指示するようにgit add -A && git commitでコミットを実行しました。
$ git show --stat --format='%an: %s' HEAD
agent-a: add slugify
slug.py | 2 ++
textutils.py | 4 ++++
2 files changed, 6 insertions(+)
$ python3 -m pytest -q
1 error in 0.09s
エージェントAのコミットにエージェントBの書きかけの関数が巻き込まれ、テストスイートのインポートすら通らなくなりました。何かを上書きしたわけではありません。インデックスが共有されていたため、エージェントAのコミットにエージェントBの仕掛品が巻き込まれてしまい、Gitの履歴上はエージェントAが壊れたコードを書いたことになってしまったのです。同一ファイルを編集した場合のトラブルについては、2つのコーディングエージェントが同一ファイルを編集すると何が起きるかで解説しています。
worktreeを分けて複数のClaude Codeエージェントを実行する
解決策は、セッションごとに専用のワーキングディレクトリを用意することです。Claude Codeにはそのためのフラグが標準で備わっています。
# interactive sessions, one task each, each in its own worktree
claude -w auth-refactor
claude -w flaky-date-test --tmux # opens the session in its own tmux or iTerm2 pane
# fire-and-forget work: starts in the background and prints an id
claude --bg "update the README examples for the new config format"
worktreesのドキュメントによると、claude -w <name>はworktree-<name>という新しいブランチを作成し、.claude/worktrees/<name>/にworktreeを展開します。別の名前を指定して2つ目のターミナルを立ち上げれば、完全に隔離された2つ目のセッションが得られます。実際に実行してみたところ、Gitは新しいworktreeをlocked状態として一覧表示しました。これにより、実行中のセッションの背後でgit worktree pruneによって削除されるのを防げます。また、agent viewのページによれば、--bgまたは/bgで開始されたバックグラウンドセッションも、ファイルを編集する前に.claude/worktrees/以下の専用worktreeに自動的に移動します。
無駄なトラブルを避けるために、セットアップで押さえておくべきポイントが3つあります。
- フォルダをignoreする。 worktreeはリポジトリの内部に配置されるため、ドキュメントでも推奨されているように
.claude/worktrees/を.gitignoreに追加しない限り、メインのチェックアウトでgit statusを実行した際に.claude/が未追跡として表示されてしまいます。 - クリーンなチェックアウトになる点に注意する。 新しいworktreeには
node_modulesや仮想環境（virtualenv）、.envは存在しません。コピーが必要なgit追跡対象外のファイル（.envなど）は.worktreeincludeファイルに指定し、worktreeごとに依存関係のインストールが必要になることを見込んでおきましょう。 - ヘッドレス実行の後は自分でクリーンアップする。 対話型セッションでは終了時にworktreeの削除を確認してくれます。しかし、
claude -pで実行されたプロセスは自動でクリーンアップされないため、git worktree unlockを実行してからgit worktree removeで手動削除する必要があります。
バックグラウンドセッションはシェルから管理します。以下の説明はバージョン2.1.283のclaude --helpに基づいています。
| コマンド | 動作・機能 |
|---|---|
claude --bg "<task>" |
バックグラウンドでセッションを開始して直ちに復帰し、IDを出力する |
claude agents |
実行中のセッション一覧を表示するagent viewを開く（スクリプト用には--json） |
claude logs <id> |
バックグラウンドセッションの直近のターミナル出力を表示する |
claude attach <id> |
現在のターミナルでバックグラウンドセッションを開く |
claude stop <id> |
セッションを停止する。会話履歴は保持され、claude attach <id>で再開できる |
--bgは-pと組み合わせることができません。スクリプトを用いた並列展開を行う場合、AnthropicのClaude Codeのベストプラクティスガイドでは、--allowedToolsと--permission-mode dontAskを指定したclaude -pのシェルループ処理が紹介されています。各実行が専用のディレクトリを持てるよう、-wと組み合わせて使用してください。
隔離されたClaude Codeエージェントもマージ時には競合する
worktreeを使うことで、作業中にセッション同士が互いの邪魔をするのを防ぐことができます。しかし、作業成果の互換性が自動的に保証されるわけではありません。2つのworktreeブランチで同様の変更を行い、それぞれtextutils.pyの末尾に関数を1つ追加した上で両方をマージしてみました。
$ git merge agent/slugify
Fast-forward
$ git merge agent/truncate
Auto-merging textutils.py
CONFLICT (content): Merge conflict in textutils.py
Automatic merge failed; fix conflicts and then commit the result.
どちらのエージェントも間違ったことはしていません。双方が同じ場所にコードを追加したため、Git側で順序を判断できなかっただけです。4〜5個のセッションを動かす実際のコードベースでは、ルーティングテーブル、__init__.pyのエクスポート定義、チェンジログ、ロックファイルなど、あらゆる処理が触れるファイルで日常的に発生します。チェックアウトを共有していた場合との違いは、競合が明確かつ可視化され、原因を特定できる点にあります。この影響を最小限に抑えるための習慣が3つあります。
- 機能単位ではなくファイル単位でタスクを分割する。 ルーターの変更を必要とする2つのタスクがあるなら、1つのタスクにまとめるか、順番に実行する2つのタスクに分けます。
- マージ順序を固定し、残りはリベースする。 最初のブランチをマージしたら、次のセッションには
mainを取り込んでリベースし、レビュー前にテストを再実行するよう指示します。そのコードを書いたセッション自身が、コンフリクトを解決するための文脈を最も把握しています。 - worktreeにはタスクに応じた名前を付ける。 1時間後に
git worktree listを確認した際、claude -w agent2よりもclaude -w fix-date-testのほうが圧倒的に判別しやすくなります。
実際のところ、最大のボトルネックはGitではなく、5つもの差分をレビューする人間側にあります。キューの適切な規模感については、人間のレビューが並列エージェントのボトルネックになる理由とレビュー設計で解説しています。
サブエージェント、エージェントチーム、独立セッションの使い分け
現在、Claude Codeには並行してタスクを実行する方法がいくつか用意されており、並列エージェントの概要ドキュメントに並べて記載されています。これらはどれを選んでも同じというわけではありません。最も重要になるのが「分離性」です。
| 選択肢 | 実行内容 | ファイルの分離方式 | 推奨される利用シーン |
|---|---|---|---|
| Subagents | 1つのセッション内で動く補助エージェント。それぞれが独自のコンテキストウィンドウを持つ | サブエージェントがisolation: worktreeを設定しない限りチェックアウトを共有 |
1つのタスクの中で調査、レビュー、または並行読み取りが必要な場合 |
/batch |
1つの変更を5〜30個のサブエージェントに分割して実行 | サブエージェントごとに1つのworktree | 多数のファイルにまたがる大規模で機械的な変更を行う場合 |
| Agent teams | タスクリストを共有し相互にメッセージを送受信するリーダーセッションとチームメイト | なし（ドキュメントでは作業対象ファイルを分けるよう指示） | 作業の途中でチームメイト同士の連携が必要な場合（実験的機能、デフォルト無効） |
Separate sessions (-w, --bg, Desktop) |
独立したセッション | セッションごとに1つのworktree | 個別にレビューする独立したタスクを実行する場合 |
Cloud sessions (claude --cloud) |
プッシュされたブランチをクローンして隔離されたVM上で動くセッション | セッションごとに1つのVM | ローカルマシンを拘束したくない作業を行う場合 |
独立したタスクには、worktreeを用いた独立セッションを使用してください。各タスクが相互に依存しており、チームメイト同士の連携が必要な場合はagent teamsを使用し、各チームメイトには異なるファイルを割り当てるようにします。agent teamsのドキュメントにも「2人のチームメイトが同じファイルを編集すると上書きが発生する」と率直に警告されています。どの方法を選択しても、利用枠は共有されます。agent viewのドキュメントにも「10個のエージェントを並行実行すると、1個の場合の約10倍の速さでクォータを消費する」とはっきり記されています。
複数のClaude Codeエージェント運用におけるSharklyの位置づけ
自分のノートPC上で2〜3個のセッションを動かし、すべての差分を自分でレビューするのであれば、前述のコマンドだけで十分であり、Sharklyは必要ないかもしれません。しかし、セッションの担当者が複数人に増えたり、「日付テストの修正はどのセッションで行われているか？」を確認する時間のほうが修正にかかる時間よりも長くなったりすると、状況は一変します。
すでにあるコーディングエージェントを、Sharklyはチームとして統合します。各作業単位はTask（タスク）となり、接続されたComputer上でClaude Code Runtimeを実行するAgent（エージェント）に割り当てられ、担当者（Assignee）を設定すると実行が開始されます。デフォルトの作業ディレクトリ設定であるCreate temporary directoryを使用すると、各タスクに個別のディレクトリが割り当てられ、リポジトリに基づく実行には隔離されたgit worktreeが用意されます。手動でworktree名を付ける手間もなく、claude -wと同等の分離が実現します。エージェントがローカルマシンの既存環境を再利用する必要がある場合も、Run in isolated worktreesにより、各タスクの成果を専用のagent/<agent>/<task>ブランチに出力します。また、エージェントのMax concurrency (assigned tasks)（最大同時実行数）によって同時実行数を制限できるため、前述したレビュー上限をチーム全体に見える形で設定できます。
進捗状況、実行履歴、結果はタスクに集約され、人間の判断が必要なものはInbox（受信トレイ）に届きます。作業内容が勝手にマージされることはありません。人間がworktreeの変更内容をレビューし、保持、マージ、または破棄を決定した上でタスクをDone（完了）にします。Sharkly自体はトークンを販売していないため、実行料金は引き続きユーザー自身のClaude Codeプランに対して請求されます。設定手順はAgentsの機能紹介ページで、実行の仕組みはSharklyによるエージェントの並列実行の仕組みで詳しく解説しています。
ターミナルを3つ以上使い分けており、すべてのClaude Codeセッションの結果をレビュー担当者が確認しやすい1か所にまとめたい――まさにその課題を解決するためにSharklyは設計されています。
よくある質問（FAQ）
Claude Codeエージェントは同時にいくつまで実行できますか？ 公式ドキュメントでは、独立したセッションの数に上限は設けられていません。サブエージェントはデフォルトで最大20個の同時実行が可能で、agent teamsのページでは3〜5人のチームメイトから始めることが推奨されています。実質的な上限となるのは、プランの利用枠、ノートPCのCPUやメモリリソース、そして1日に人間がレビューできる成果物の量です。6つ目のセッションを追加する前に、レビューキャパシティの計算をしておく価値は十分にあります。
並行して動くClaude Codeセッションは利用制限（上限枠）を共有しますか？ はい、共有されます。ProプランおよびMaxプランでは、5時間枠と週間制限を含め、ClaudeとClaude Codeの間で利用制限が共有されており、並行して動くすべてのセッションが同じ枠から消費されます。なお、ANTHROPIC_API_KEYが設定されている場合、Claude Codeは代わりにAPI経由で課金されます。
claude --worktreeは.envや依存関係もコピーしてくれますか？ いいえ、コピーされません。各worktreeはクリーンなチェックアウト状態になります。.envなど必要なgit追跡対象外のファイルは.worktreeincludeに追加し、worktreeごとに依存関係のインストール手順を実行してください。
同じリポジトリ上でClaude CodeとCodexを並行実行できますか？ はい、可能です。守るべきルールは同じで、「セッションごとに1つのworktreeを用意し、マージ順序を決めておく」ことです。ルーティング面でのアプローチについては、単一コードベースでClaude CodeとCodexを併用・並行運用するガイドで解説しています。
