Claude Code を2〜3個同時に走らせる｜git worktree で並列開発する海外流儀

公開 2026-04-12 更新 2026-09-20

#Claude Code#git#開発効率#AI

Claude Code にリファクタを頼んだら、終わるまで画面の前で待つしかない。そんな時間が気になって、X や Reddit の Claude Code コミュニティを眺めていると、「同時に 2〜3 個起動している」という話が当たり前のように出てきます。海外ではだいぶ浸透してきた使い方なのに、日本語ではほとんど語られていません。

「1 つのプロジェクトで Claude Code を複数起動したら、ファイルの取り合いでカオスにならない？」と思いますよね。その通りで、1 つのディレクトリで並列起動するのは事故のもとです。そこで使うのが git worktree です。セットアップから運用のコツまでを順に紹介します。

2026年4月時点の情報です（Claude Code の挙動などは変わっていることがあります）。

git worktree とは

git worktree は、1 つのリポジトリから複数のワーキングディレクトリを作れる Git 標準の機能です。Git 2.5 から使えるのに、日本語の解説記事が少なく、マイナー扱いされがちです。

通常の git checkout との違いを表にすると分かりやすいです。

項目	`git checkout`	`git worktree`
ディレクトリ	同じ場所で切り替え	別ディレクトリに展開
同時作業	できない（切り替えが必要）	複数ブランチを同時に開ける
.git リポジトリ	1 つ	共有（容量が増えない）
stash の必要性	あり	なし

イメージとしてはこんな感じです。

my-project/              ← main ブランチ（本体）
my-project-refactor/     ← refactor ブランチ（worktree）
my-project-bugfix/       ← bugfix ブランチ（worktree）

1 つのリポジトリから、3 つの「作業場所」が生えている状態です。Git はこれらをまとめて管理してくれます。

Claude Code と相性がいい理由

Claude Code は 1 つのタスクを実行している間、基本的に他の作業が止まります。リファクタのように時間がかかる作業を投げたら、終わるまで待つしかありません。

そこで別の worktree を用意し、そこで別の Claude Code を起動します。

メイン：長時間かかるリファクタを任せる
worktree A：その間に新機能の実装を進める
worktree B：別の緊急バグ修正をさっと片付ける

これで 3 並列になります。それぞれ別ブランチなので、作業が混ざる心配はありません。同じディレクトリで複数起動すると、片方が書き換えたファイルをもう片方が前提にして作業を続けてしまい、お互いの変更を上書きし合う事故が起きます。作業場所ごと分けてしまえば、その心配ごと消えます。

「AI に待たされる時間」を「別の AI に働かせる時間」に変える。並列化のうまみは、これに尽きます。

セットアップ手順

1. worktree を追加する

メインのプロジェクトディレクトリで、追加したいブランチを worktree として展開します。

# 既存のブランチを worktree として開く
git worktree add ../my-project-refactor refactor

# 新しいブランチを同時に作って worktree として開く
git worktree add -b feature/new-login ../my-project-login

ブランチをすでに持っているなら上のコマンド、これから作る新機能なら下のコマンド、と使い分けます。これで my-project/ の隣に my-project-refactor/ と my-project-login/ ができます。リポジトリのクローンではないので、.git は共有されて容量もほとんど食いません。

2. それぞれで Claude Code を起動する

ターミナルを 3 つ（あるいは tmux のペインを 3 つ）開き、各 worktree で claude を起動します。

# ターミナル 1（メイン）
cd my-project
claude

# ターミナル 2（リファクタ用）
cd ../my-project-refactor
claude

# ターミナル 3（新機能用）
cd ../my-project-login
claude

3 つのターミナルで、独立した Claude Code が走ります。それぞれの Claude からは自分の worktree のファイルしか見えないので、指示が混ざることはありません。最初は 2 つから始めて、慣れてから 3 つに増やすのがおすすめです。同時に走らせる数が増えるほど、どの画面でどの指示を出したのかを自分が見失いやすくなります。ターミナルのタブやペインに、用途の名前を付けておくと迷いません。

3. 使い終わったら片付ける

# worktree を削除（ブランチは残る）
git worktree remove ../my-project-refactor

# 強制削除（未コミットの変更がある場合）
git worktree remove --force ../my-project-refactor

# 現在の worktree 一覧を確認
git worktree list

worktree を消してもブランチ自体は残ります。あとから worktree add で復活させることもできます。作業が終わった worktree を放っておくと、ディレクトリがどんどん溜まって、どれが生きているのか分からなくなります。git worktree list で今の一覧を見て、使い終わったものから消す習慣を付けておくと散らかりません。未コミットの変更がある状態で消そうとすると止められるので、先にコミットするか、捨てて構わないときだけ強制削除を使います。

運用スタイルの例

私が実際にやっている使い分けです。

worktree	用途	Claude Code への指示例
main	機能実装	「〇〇機能を実装して」
refactor	継続リファクタ	「このファイルを責務ごとに分割して」
bugfix	緊急バグ修正	「Issue #123 のバグを直して」
docs	ドキュメント整備	「README を最新の構成に合わせて更新して」

それぞれの Claude は自分の context しか持たないので、指示も履歴も完全に分かれます。用途ごとに会話が分かれていると、あとで「あの修正はどこで頼んだんだっけ」と探すときにも楽です。逆に、同じ会話に何でも詰め込むと、話題が混ざって Claude の判断もぶれやすくなります。

特に効くのは、次のような場面です。

PR を出してレビュー待ちの間に、別 worktree で次のタスクに着手する
巨大ファイルのリファクタを 1 つに任せて、別 worktree で小さい修正を進める
同じ機能を 2 つの方針で実装してみて、良い方を採用する（A/B 実験）
機能実装中に緊急バグが来ても、main の worktree ですぐ対応できる（作業中のブランチを中断しなくていい）

ハマりやすい点

まず、node_modules と .env は worktree ごとに用意が必要です。Git 管理外のファイル（node_modules/、.env、ビルド成果物など）は worktree に引き継がれないので、新しく作るたびにセットアップします。

cd ../my-project-refactor
npm install          # node_modules を作る
cp ../my-project/.env .env   # .env をコピー

ディスク容量は食いますが、それぞれが独立しているのは逆に安全でもあります。pnpm を使っていれば node_modules が実質シンボリックリンクなので、ほぼコストはかかりません。

次に、同じブランチを 2 つの worktree で開くことはできません。main を 2 つの worktree でチェックアウトするのは Git の制約で不可なので、並列化したいときはそれぞれ別のブランチを用意します。

worktree の置き場所は、リポジトリの外が無難です。my-project/my-project-refactor/ のようにリポジトリの中に作ると、.gitignore に追加しない限り、自分自身の変更として見えてしまいます。リポジトリの親ディレクトリに並べるのが一般的です。

workspace/
├── my-project/           ← 本体
├── my-project-refactor/  ← worktree
└── my-project-bugfix/    ← worktree

もうひとつ、Claude Code 同士で情報は共有されません。worktree ごとに起動した Claude Code は完全に独立しているので、「別の worktree で何をやったか」は伝わらず、全体の進捗は自分で把握しておく必要があります。ここは CLAUDE.md の共通化や、MCP サーバー経由の状態共有などで、将来的に解決できそうな領域です。