Claude Codeのgit worktree活用ガイド — 並列作業で手戻りをなくす実践テクニック

2026年4月9日

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の使い分け

やりたいこと	checkout	worktree
ちょっとブランチ確認	向いている	やりすぎ
別ブランチで長時間作業	stash地獄になりがち	快適
2ブランチの動作を比較	切り替え往復	並べて確認できる
CIが通るか手元で確認しつつ別作業	無理	できる

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

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

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

使い方

CLIの場合：

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

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

Desktopアプリの場合は「Code」タブの「Worktree Mode」をオンにする。セッションごとに自動でworktreeが作られる。

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

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

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

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

# Claude Codeに指示
> hotfix/login-bugブランチで、セッションCookieの有効期限チェックを修正して。
> テストも書いてPRを出して。

自分はfeature-Aの作業を続けながら、Claude Codeが別worktreeでhotfixを進める。PRが出たらレビューすればいい。

worktreeなしの場合：

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

worktreeの場合：

claude --worktree hotfix-login（3秒）
hotfix作業（別ディレクトリ）
終わったら git worktree remove で掃除（2秒）

コンテキストスイッチのコストがほぼゼロになる。

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

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

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

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

5件を直列に対応すると各5分として25分。並列なら最長の1件分の時間で済む。

ケース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ファイル）での目安：

作業	checkoutで切替	worktreeで並列
hotfix割り込み（1件）	2〜5分のオーバーヘッド	ほぼ0
レビュー修正5件（独立）	25分（直列）	5〜8分（並列）
10ファイルのリファクタリング	30分（直列）	6〜10分（5並列）
ブランチ間の動作比較	切替のたびに30秒〜2分	2つのターミナルで同時確認

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

worktreeの設定まとめ

設定方法	書く場所	動作
`--worktree <名前>`	CLIオプション	指定名のworktreeでセッション開始
`--worktree`（名前省略）	CLIオプション	自動命名でworktree作成
`isolation: worktree`	エージェント定義のfrontmatter	エージェント実行時に毎回worktreeを作成・自動削除
Worktree Mode: ON	Desktopアプリ設定	全セッションで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並列にしても待ち時間で律速されてリニアには速くならない。