Claude Codeでgit worktreeを使う方法｜並列作業の手順と注意点

Claude Codeでgit worktreeを使うと、1つのリポジトリから作業用のディレクトリを複数作り、それぞれで別のClaude Codeを同時に動かせる。手順は、git worktree add で作業ディレクトリを作るか、リポジトリの中で claude --worktree <名前> を実行して起動するだけだ。ブランチを切り替えずにhotfixやレビュー修正を並行でき、それぞれの変更を別々の作業ディレクトリで管理できる。

git worktreeを使う前に知っておくこと

git worktreeはGitの標準機能で、1つのリポジトリから複数の作業ディレクトリを作れる仕組みだ。.gitディレクトリを共有するので、cloneし直すよりずっと軽い。

普段の開発でよくあるのが「feature-Aを実装中にhotfixを頼まれた」という場面。checkoutで切り替えると、node_modulesの再インストールが走ったり、エディタのキャッシュが壊れたりする。worktreeなら別ディレクトリで作業するだけなので、feature-Aの状態はそのまま残る。

# 基本的なworktreeの作り方
git worktree add ../hotfix-login hotfix/login-bug
cd ../hotfix-login
# ここでhotfixを作業。元のディレクトリはfeature-Aのまま

checkoutとworktreeの使い分け

Claude Codeとworktreeの組み合わせが便利な理由

Claude Codeはgit worktreeをネイティブサポートしている。何が便利かというと、Claudeのセッションごとに独立した作業環境を持てる点だ。

メインの作業ディレクトリを汚さずにClaude Codeに作業させられるので、「Claudeが変な変更をしたけどresetしたら自分の変更も消えた」という事故がなくなる。

使い方

CLIの場合：

# 新しいworktreeでClaude Codeセッションを開始
claude --worktree feature-auth

# 名前を省略するとClaude側で自動命名
claude --worktree

Desktopアプリの場合は、セッションを始める前に、プロンプト欄の下にあるプロジェクトフォルダのメニューで「Worktree」をオンにする（初期状態はオフ）。保存済みの環境に設定しておくこともできる。

実践：3つのユースケース

ケース1：バグ修正の割り込み対応

feature-Aの実装中に「本番でログインできないユーザーがいる」と報告が来た場面を想定する。

# 今の作業はそのまま。別worktreeでhotfixを開始
claude --worktree hotfix-login

# Claude Codeに指示
> セッションCookieの有効期限チェックを修正して。
> テストも書いてPRを出して。

claude --worktree hotfix-login は、リポジトリの既定ブランチ（通常は main）から worktree-hotfix-login という新しいブランチを作って始まる。自分はfeature-Aの作業を続けながら、Claude Codeが別worktreeでhotfixを進める。PRが出たらレビューすればいい。

worktreeなしの場合：

1. git stash で現在の変更を退避（5秒）
2. ブランチ切り替え（2秒）
3. 依存関係の再インストール待ち（30秒〜2分）
4. hotfix作業
5. 元ブランチに戻る（2秒）
6. git stash pop（5秒。コンフリクトすると数分）
7. エディタが変更を再認識するまで待つ（10秒〜）

worktreeの場合：

1. claude --worktree hotfix-login（3秒）
2. 依存関係のインストール（そのworktreeで初回のみ。30秒〜2分）
3. hotfix作業（別ディレクトリ）
4. 終わったら git worktree remove で掃除（2秒）

worktreeは新しくチェックアウトした状態なので、初回は依存関係を入れ直す必要がある。.env のようにgitの管理外のファイルも入っていないので、必要ならプロジェクト直下の .worktreeinclude に書いておくと自動でコピーされる。それでも、今の作業を止めて戻す手間はなくなる。

ケース2：レビュー指摘の修正を並列で処理

PRに5件のレビューコメントがついた。互いに独立した修正なので、並列で対応したい。

# PRのブランチから始める（#はシェルのコメントにならないよう引用符で囲む）
claude --worktree "#123"
> レビューコメントを1件ずつ確認して、修正方針を出して。

# 修正ごとにworktreeを分けてClaude Codeに投げる（既定ブランチから始まる）
claude --worktree fix-validation
> バリデーションエラーのメッセージを修正して。PRの#comment-1を参照。

claude --worktree fix-types
> 型定義をstrict modeに対応させて。PRの#comment-3を参照。

5件を直列に対応すると各5分として25分。並列なら最長の1件分の時間で済む。ただし、名前を付けた --worktree は既定ブランチから新しいブランチを作る。PRの修正を1つのセッションで進めるなら "#PR番号" の形で始める（同じ番号では同じworktreeになるので、並列の分割には使えない）。修正ごとにworktreeを分けて並列にしたいなら、PRのブランチをチェックアウトした状態で設定の worktree.baseRef を "head" にしてから起動すると、各worktreeがPRの今の状態から始まる。どちらの場合も、別々のブランチに分けた修正は最後にPRのブランチへまとめ直す。

ケース3：サブエージェントによる大規模リファクタリング

これがworktreeの本領。エージェント定義ファイルにisolation: worktreeを指定すると、エージェントが自動的にworktree内で動く。

---
name: async-migration
description: 同期I/Oを非同期に移行するエージェント
isolation: worktree
---

# Claude Codeに大規模リファクタリングを依頼
> src/services/ 配下の同期ファイル操作をすべてfs/promisesに移行して。
> ファイルごとにworktreeを分けて並列で進めて。各worktreeでテストを通してからPRを出して。

10ファイルを逐次処理すると各3分 x 10 = 30分。worktreeで並列実行すれば、5並列なら約6分で完了する。

作業時間の比較

Node.jsプロジェクト（src/ 配下 約80ファイル）での目安：

大きいのは時間短縮だけでなく、コンテキストスイッチによる集中力の途切れがないこと。stashの出し入れで「あれ、どこまでやったっけ」がなくなる。

worktreeの設定まとめ

使ってみてわかった注意点

• ディスク容量：worktreeごとに作業ファイルのコピーができる。node_modulesはシンボリックリンクにならないので、大きいプロジェクトだとそこそこ食う。使い終わったらgit worktree removeで掃除する習慣をつけたほうがいい。
• 同じブランチは2つのworktreeで同時に開けない：Gitの制約。feature-Aをworktree-1で開いていたら、worktree-2では別ブランチにする必要がある。
• IDE連携：VS Codeは各worktreeを別ウィンドウで開けば問題ない。JetBrains系はプロジェクト設定が各worktreeに必要になる場合がある。
• 並列エージェントの数：CPUとAPIレートリミットに依存する。実用上は3〜5並列がバランスがいい。10並列にしても待ち時間で律速されてリニアには速くならない。

まとめ

git worktreeは「ブランチ切り替えのストレスをなくす」ためのGit標準機能。Claude Codeと組み合わせると、AIエージェントに安全な隔離環境を与えつつ並列実行できるのが強い。

特に効果が大きいのは以下の場面：

• hotfix割り込みが多いプロジェクト
• レビュー修正を素早く返したいとき
• 大量の定型的リファクタリング

claude --worktreeを1回試せば、stashに戻る気はなくなると思う。

AIエージェントを並列で動かすと、人がやる仕事は「何を任せるか決めて、結果を確かめる」に寄っていく。自社の業務のどこから任せられるか迷っている段階なら、まずは現在地を知るところからで十分だ。

無料のAI活用診断を受ける（6問・約1分） →