結論から言うと、Claude Codeで複数タスクを並列に進めたいなら、同じ作業ディレクトリでセッションを増やすのではなく、git worktreeでタスクごとに独立した作業ツリーを切って、その中で1つずつClaude Codeを走らせるのが基本形です。これはAnthropicの公式ドキュメントにも載っている標準的なワークフローで、リポジトリのクローンを複製するより軽く、履歴とリモート設定は共有したまま、ファイルの編集は互いに影響しない形で分離できます。
この記事では、なぜ「同じディレクトリで2つ動かす」が危ないのかから始めて、worktreeの仕組み、実際の手順、ハマりどころ、そして「そもそも並列にすべきか」の判断までを整理します。想定読者は、Claude Codeを日常的に使っていて「リファクタを走らせている間に別のバグ修正も進めたい」と思ったことがある方です。
同じディレクトリで2セッションは、なぜ危ないのか
Claude Codeはターミナルごとに独立したセッションとして起動できるので、タブを2つ開けば同じリポジトリで2つのClaudeを動かすこと自体はできます。問題は、2つのセッションが同じ作業ツリーと同じチェックアウト中のブランチを共有してしまうことです。
具体的には、次のような衝突が起きます。
- ファイル編集の衝突: セッションAがリファクタ中のファイルを、セッションBが別の目的で書き換える。それぞれのClaudeは相手の存在を知らないので、直前まで読んでいた内容と実際のファイルがずれたまま編集を重ねます。
- git操作の衝突: ブランチの切り替え、ステージング、コミットはリポジトリ単位の状態です。セッションAが
git checkoutした瞬間、セッションBの目の前のファイルツリーが丸ごと入れ替わります。 - 検証の混線: テストやビルドを走らせても、それが「どちらの変更を含んだ状態」なのか判別できなくなります。片方の変更が原因のテスト失敗を、もう片方のセッションが「自分のバグ」として直しにいく事故がありえます。
つまり並列化の障害はClaude Code側ではなく、「作業ツリーがひとつしかない」というgitの構造側にあります。だから解決策もgit側にあって、それがgit worktreeです。
git worktreeの仕組み——クローン複製との違い
git worktreeは、1つのリポジトリに複数の作業ツリー（working tree）を接続するgitの標準機能です。git cloneをもう1つ作るのと何が違うかというと、オブジェクトデータベース（コミット履歴の実体）と設定を共有する点です。
- 履歴・ブランチ・stash・リモート設定は全worktreeで共有。あるworktreeでコミットすれば、他のworktreeからもそのコミットが見えます
- 各worktreeは独立したディレクトリ・独立したチェックアウトを持つ。ファイルの編集は互いに一切影響しません
- 同じブランチを2つのworktreeで同時にチェックアウトすることは、gitがエラーで拒否します
最後の制約は、最初は不便に見えて、実は安全装置です。「同じブランチを2箇所で編集して片方が消える」という事故が構造的に起きません。並列作業は必然的に「1タスク=1ブランチ=1worktree」に誘導されます。
Claude Codeの公式ドキュメント（Common workflows）でも、複数セッションの並列実行にはこのgit worktreeを使う手順が案内されています。各Claudeインスタンスが独立した環境を持つので、互いを待たせることも干渉することもない、という整理です。
手順——worktreeを切って、その中でClaudeを起動する
やることは3ステップです。リポジトリが~/projectにあるとします。
# 1. タスク用のworktreeを新しいブランチ付きで作る
cd ~/project
git worktree add ../project-feature-a -b feature-a
# 2. worktreeに移動して環境を整える
cd ../project-feature-a
npm install # 依存はworktreeごとに必要（後述）
# 3. その中でClaude Codeを起動する
claude
git worktree add <パス> -b <ブランチ名>で、指定パスに新しい作業ツリーが作られ、同時に新ブランチがそこへチェックアウトされます。既存ブランチで作業したい場合は-bを外してgit worktree add ../project-bugfix bugfix-123のようにブランチ名を渡します。
2つ目のタスクも同じ要領です。
cd ~/project
git worktree add ../project-bugfix-b -b bugfix-b
cd ../project-bugfix-b && claude
これでターミナルのタブごとに、編集の衝突が起きない独立した作業環境でClaudeが1つずつ動きます。今どんなworktreeがあるかは一覧で確認できます。
git worktree list
# /Users/you/project abc1234 [main]
# /Users/you/project-feature-a def5678 [feature-a]
# /Users/you/project-bugfix-b 9012abc [bugfix-b]
タスクが終わってブランチをマージしたら、worktreeを片付けます。
git worktree remove ../project-feature-a
git worktree prune # 手動でディレクトリを消してしまった場合の掃除
ディレクトリの命名はproject-<タスク名>のように親ディレクトリ側へ並べると、エディタやターミナルからの見通しがよくなります。リポジトリの中にworktreeを切るとgitの管理対象と混ざって紛らわしいので、外に置くのが定石です。
ハマりどころ——worktreeが分離しないもの
worktreeが分離するのは「gitが追跡しているファイルのチェックアウト」だけです。逆に言うと、gitの外にあるものは何も引き継がれない。仕組みからの帰結として、最初に引っかかるのはここのはずです。
- 依存パッケージ:
node_modulesや.venvは未追跡なので、新しいworktreeは空の状態から始まります。worktreeを切るたびにnpm installなりのセットアップが必要です。逆に、依存を共有しないからこそ「片方でライブラリを更新したらもう片方が壊れた」も起きません。 - 環境変数ファイル:
.envや.dev.varsのような未追跡の設定ファイルもコピーされません。worktree作成直後のセットアップ手順に「元のディレクトリから設定ファイルをコピーする」を含めておく必要があります。 - 開発サーバーのポート: 2つのworktreeで同時に
npm run devすれば、当然同じポートを取り合います。worktreeごとにポートを変える環境変数を渡すか、同時にサーバーを立てるのは1つに絞るかを決めておきます。 - ディスクとビルドキャッシュ: 履歴は共有されるのでクローン複製よりずっと軽いものの、チェックアウトされたファイルと依存はworktreeの数だけ増えます。巨大なリポジトリでは無視できないコストです。
もうひとつ、Claude Code側の注意として、各セッションの権限設定やCLAUDE.mdはリポジトリのファイルとして共有されます（追跡されていれば全worktreeに同じものがチェックアウトされるため）。worktreeごとに挙動を変えたい場合だけ、未追跡のローカル設定を使い分けることになります。
並列にする価値がある場面、ない場面
手段が手に入ると全部並列にしたくなりますが、私の考えでは、並列化が効くかどうかはタスクの独立性で決まります。
向いているのは、互いに触るファイルが重ならない独立タスクの組み合わせです。たとえば「機能Aの実装」と「別モジュールのバグ修正」、「リファクタ」と「ドキュメント整備」。一方が長考している間にもう一方をレビューする、という時間の使い方ができます。
向いていないのは、同じファイル群を触るタスクを無理に分けることです。worktreeはファイルの衝突を防ぎますが、マージの衝突は防ぎません。同じ箇所を触る2タスクを並列にすると、分離した意味がなくなって、マージ時に人間が衝突解消を引き受けるだけです。それなら1セッションで順番にやる方が速い。
そして、本当のボトルネックになるのはマシンでもClaudeでもなく、自分のレビュー帯域だ、というのが私の見立てです。並列に走るセッションが増えるほど、出てくる差分をレビューして判断する側の負荷が増えます。エージェントの生成速度は並列でスケールしても、人間の確認は直列のままです。2〜3並列あたりで「Claudeを待つ時間」より「自分がレビューを待たせる時間」の方が長くなったら、それ以上増やす意味は薄いというのが私の判断です。
なお「マシンを分けたい」「終わるまで放置したい」タイプのタスクは、そもそもローカルの並列ではなく非対話実行に寄せる選択肢もあります。この住み分けは別記事に書きました。
Claude Codeヘッドレスモード入門｜claude -p を自動化に組み込む設計Claude Codeを非対話で実行するヘッドレスモード（claude -p）の使い方を解説します。出力をJSONで受ける方法、許可ツールと権限モードの固定、max-turnsによる暴走と費用の上限設計、CI・cronへの組み込みパターンと向かない用途までをまとめます。www.tentspace.net
セッションの区切り方はコンテキスト管理と地続き
worktreeによる並列は、突き詰めると「1タスク=1セッション=1作業ツリー」という区切りの話です。1つのセッションに複数タスクを混ぜない方がいいのは、並列でなくても同じで、コンテキストを混ぜると精度が落ちるからです。worktreeはその区切りをファイルシステムのレベルでも強制してくれる仕組みだと捉えると、位置づけがすっきりします。
Claude Codeのコンテキスト管理入門｜/compactより先に/clearを覚えるClaude Codeのコンテキスト管理を公式ドキュメントベースで整理します。/contextでの観測、auto-compactの挙動、/compactの指示付き圧縮と要約で細部が落ちるリスク、/clearで区切る基本方針、CLAUDE.md・サブエージェント・MCP設定で「そもそも入れない」設計までをまとめます。www.tentspace.net
まとめ
- Claude Codeの並列実行は、同一ディレクトリでのセッション追加ではなく、git worktreeで作業ツリーごと分けるのが公式ドキュメントにも載っている基本形
git worktree add ../project-x -b task-x→cd→claudeの3ステップ。終わったらgit worktree remove- worktreeが分離するのはgit追跡ファイルだけ。依存・環境変数・ポートは分離されないので、worktree作成時のセットアップ手順を決めておく
- 同じブランチの二重チェックアウトはgitが拒否する。この制約が「1タスク=1ブランチ=1worktree」を強制する安全装置になる
- 並列化の上限を決めるのはレビュー帯域。差分を追える本数までに絞る
まずは独立した2タスクで、worktreeを1つ切るところから試すのがおすすめです。片方をレビューしている間にもう片方が進む感覚をつかめれば、自分にとっての適正な並列数もすぐ見えてきます。