Claude Code × Git Worktreeで並列開発する——AIに複数タスクを同時進行させる実践ガイド

エンジニアのゆとです。

Claude Codeで大きなリファクタリングを走らせている最中に、別の緊急バグ修正が入ったことはないだろうか。

「Claudeに任せてるのに止められない」「同じファイルを別ブランチで触ってコンフリクトが地獄になった」——そういう経験が何度かあって、Git Worktreeを使った並列開発スタイルに移行した。今では複数のClaude Codeセッションを同時に走らせながら、それぞれ独立して作業させている。

Claude Code 2.1系では -w / --worktree フラグが正式に追加されていて、起動時にworktreeを自動生成できる。これとGit Worktreeの仕組みを組み合わせると、コンフリクトなしの並列開発が現実的になる。

なぜ並列開発が必要になるのか

Claude Codeは非常に賢いが、1つのセッションは1つのコンテキストに縛られている。

リファクタリング中のセッションで「ちょっとこっちのバグも見て」とお願いすると、何が起きるか。Claudeは親切にも両方やろうとする。その結果、コンテキストが汚染されて、どちらの作業も中途半端になる。しかもstashしたり手動でブランチを切り替えたりする手間が発生して、「AIに任せた意味がない」状態になる。

「Claudeに任せる作業はタスク単位で完全に独立させる」という原則を守ると、この問題はほぼ消える。Git Worktreeはそのための道具だ。

Git Worktreeの基本

まず前提として、Git Worktreeの仕組みを整理する。

通常のGitは「1リポジトリ = 1ワーキングディレクトリ」だ。別ブランチで作業したければ、git checkout して今の作業を切り替える（stashするか捨てるか）しかない。

Git Worktreeはこの制約を外す。1つのリポジトリから複数のワーキングディレクトリを派生させる仕組みで、それぞれが独立したブランチで動く。ファイルシステム上に別のディレクトリが生えて、同じリポジトリのデータを共有しながら、作業領域は完全に分離される。

# 基本的な使い方
git worktree add <path> <branch>

# 例: featureブランチのworktreeを ../my-project-feature に作る
git worktree add ../my-project-feature feature/user-auth

# 新しいブランチを作りながらworktreeを追加する（-b フラグ）
git worktree add -b hotfix/null-check ../my-project-hotfix main

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

# worktreeを削除する
git worktree remove ../my-project-feature

git worktree list の出力はこんな感じになる：

/Users/yuto/my-project        abc1234 [main]
/Users/yuto/my-project-auth   def5678 [feature/user-auth]
/Users/yuto/my-project-fix    ghi9012 [hotfix/null-check]

メインのディレクトリと並列に、独立した作業ディレクトリが存在している状態だ。重要なのは、.git ディレクトリはメインのものが共有されること。git log、git fetch 等の操作はどのworktreeから実行しても同じリポジトリに対して働く。

Claude Codeの -w / --worktree フラグ

Claude Code 2.x系には -w（--worktree）フラグが組み込まれている。

claude -w
# または
claude --worktree
# 名前を指定する場合
claude --worktree feature-auth

このフラグを使って起動すると、Claude Codeが自動でworktreeを作成してその中でセッションを開始する。具体的には：

1. claude --worktree <name> を実行する
2. Claude Codeが git worktree add を実行して新しいディレクトリを作成する
3. そのディレクトリでClaude Codeセッションが開始される

--tmux フラグと組み合わせると、iTerm2またはtmuxのペインが自動で開く：

# iTerm2の場合（iTerm2がインストールされていれば自動検出）
claude --worktree feature-auth --tmux

# 従来のtmuxを使う場合
claude --worktree feature-auth --tmux=classic

これで「新しいworktreeを作る → そこでClaude Codeを起動する → 別ウィンドウで確認できる」という一連の流れがコマンド1本で済む。

実践ワークフロー：3タスクを同時進行させる

具体的なシナリオで手順を説明する。

状況

• main ブランチで本番稼働中
• feature/dashboard-v2 でダッシュボードのリニューアルを進行中（Claude Codeに任せている）
• 突然、ログイン周りのバグ修正が必要になった（緊急）
• さらに、別チームから依存パッケージのアップデート依頼が来た

3つを同時に走らせる。

ステップ1: 現在の状況を把握する

# 既存のworktreeを確認する
git worktree list

出力例：

/Users/yuto/my-project              abc1234 [main]
/Users/yuto/my-project-dashboard    def5678 [feature/dashboard-v2]

feature/dashboard-v2 のworktreeはすでにある（Claude Codeが --worktree で作ったもの）。

ステップ2: バグ修正用worktreeを作る

# mainから hotfix/login-error ブランチを作りながらworktreeを追加する
git worktree add -b hotfix/login-error ../my-project-hotfix main

# そのworktreeでClaude Codeを起動する
cd ../my-project-hotfix
claude --worktree --tmux

または最初から --worktree フラグで起動する：

# メインのプロジェクトディレクトリに戻って
cd /Users/yuto/my-project

# hotfixブランチのworktreeを作ってClaude Codeを起動
claude --worktree hotfix/login-error --tmux

Claude Codeに渡すプロンプト例：

mainブランチから作業している。
ログインフォームでメールアドレスの検証が失敗するバグを修正してほしい。
再現手順: 特殊文字を含むメールアドレス（例: user+test@example.com）でログインしようとするとエラーになる。
修正が終わったら git commit して、PRを作成できる状態にしてほしい。

ステップ3: パッケージ更新用worktreeを作る

cd /Users/yuto/my-project

claude --worktree chore/update-deps --tmux

Claude Codeに渡すプロンプト例：

mainブランチから作業している。
package.jsonの依存パッケージをすべて最新の安定版に更新してほしい。
更新後は npm test を実行してテストが通ることを確認すること。
破壊的変更がある場合は、対応方法を提示してほしい。

ステップ4: 全体の状況を管理する

# 全worktreeの一覧を確認する
git worktree list

/Users/yuto/my-project                  abc1234 [main]
/Users/yuto/my-project-dashboard        def5678 [feature/dashboard-v2]
/Users/yuto/my-project-hotfix           ghi9012 [hotfix/login-error]
/Users/yuto/my-project-update-deps      jkl3456 [chore/update-deps]

3つのClaude Codeセッションがそれぞれ独立して走っている。メインのターミナルウィンドウは空いているので、自分は確認・レビュー・次のタスク設計に集中できる。

コンフリクト回避のベストプラクティス

並列作業でコンフリクトが起きるのは、「同じファイルを複数のworktreeで同時に編集したとき」だ。これを避けるためのルールをいくつか決めている。

ルール1: タスクの作業ファイルを事前に把握する

Claude Codeにタスクを渡す前に「このタスクは何のファイルを触るか」をざっくり確認する。

このバグ修正でどのファイルが変更対象になりそうか教えて。作業前に確認したい。

大規模リファクタリングと細かいバグ修正が同じファイルを触りそうなら、どちらかを先に完了させてからもう一方を始めるほうが安全だ。

ルール2: 共通設定ファイルを触るタスクは直列にする

package.json、tsconfig.json、.env 等の設定ファイルは複数のタスクから触られやすい。特に依存関係の更新は必ずその他の作業と分けて、単独で走らせる。

ルール3: mainブランチを定期的に更新する

各worktreeで作業が終わってマージが完了したら、他のworktreeから最新のmainを取り込む：

# ダッシュボードのworktreeで
cd /Users/yuto/my-project-dashboard
git fetch origin
git merge origin/main

hotfixがmainにマージされたら、feature系のブランチもそれを取り込んでおかないと、後でコンフリクトが増える。こまめなrebase/mergeが長期的に楽になる。

ルール4: worktreeの命名規則を統一する

# 命名規則: <type>/<description>
feature/user-auth
hotfix/login-error
chore/update-deps
refactor/api-layer

後から git worktree list を見たときに、何がどのworktreeで動いているか一目でわかる。Claude Codeに渡す作業指示にも、このブランチ名を明記しておくと混乱しない。

トラブルシューティング

worktreeが消えない

git worktree remove を実行したのに消えない場合、「変更がある」とGitが判断して削除を拒否していることが多い。

# 強制削除する
git worktree remove --force ../my-project-hotfix

# worktreeのディレクトリを手動で消した後のクリーンアップ
git worktree prune

git worktree prune は、ディレクトリが存在しないworktreeの参照を削除するコマンドだ。ディレクトリを rm -rf した後はこれを実行しないとGitの内部参照が残り続ける。

同じブランチをworktreeに追加しようとしてエラーになる

Gitは同じブランチを複数のworktreeで同時にチェックアウトすることを禁止している。

fatal: 'feature/user-auth' is already checked out

このエラーが出たら、すでにそのブランチをチェックアウトしているworktreeがある。git worktree list で確認して、不要なものを削除してから作り直す。

Claude Codeがworktreeのパスを認識しない

--worktree フラグなしで起動して、手動でworktreeのディレクトリに移動した場合、CLAUDE.mdがメインのプロジェクトから読み込まれないことがある。

# worktreeのディレクトリで起動する（こちらが確実）
cd /Users/yuto/my-project-hotfix
claude

# または最初から --worktree フラグで起動する
claude --worktree hotfix/login-error

CLAUDE.mdはディレクトリ単位で検索される。worktreeのディレクトリに移動してから起動すれば、メインプロジェクトのCLAUDE.mdを辿って読み込んでくれる（.git ファイル経由でメインのリポジトリルートを特定するため）。

worktreeが増えすぎてディスク容量を圧迫する

worktreeは node_modules 等を共有しないので、Node.jsプロジェクトの場合はworktreeごとに npm install が必要になり、容量が増える。

方針は「使い終わったworktreeはすぐ削除する」だ。PRを出したら、そのworktreeはすぐ消す。

# まとめてクリーンアップするスクリプト
git worktree list --porcelain | grep "worktree " | awk '{print $2}' | tail -n +2
# → 使っていないworktreeのパスを確認してから手動で削除

tmuxと組み合わせた運用パターン

--tmux フラグを使うと、複数のworktreeセッションをターミナル上でまとめて管理しやすくなる。

# iTerm2環境での起動（自動でペイン分割される）
claude --worktree feature-auth --tmux
claude --worktree hotfix-login --tmux
claude --worktree chore-deps --tmux

それぞれが別ペインまたは別タブで開くので、切り替えが楽になる。tmux使いなら --tmux=classic で従来の動作に切り替えられる。

個人的には、worktreeを3つ以上同時に走らせるときは画面を縦に3分割して、左列にClaude Codeの出力、右列に自分の確認用ターミナルを置く配置が作業しやすかった。

まとめ

Claude Code × Git Worktreeの並列開発スタイルをまとめると：

• git worktree add でブランチごとに独立した作業ディレクトリを作る
• claude --worktree <name> でworktreeを自動生成しながらClaude Codeを起動する
• --tmux フラグで複数セッションをターミナル上で整理する
• 同じファイルを触るタスクは直列にして、コンフリクトを構造的に回避する
• 使い終わったworktreeは git worktree remove ですぐ削除して、git worktree prune で参照をクリーンアップする

「Claudeに大きな作業を任せている最中に別のことが来た」という状況は、Claude Codeをまともに使っているエンジニアなら必ず遭遇する。worktreeで分離する習慣をつけておくと、その場その場のアドホックな対応が減って、結果的に作業全体のスピードが上がる。

記事が見つかりません:

記事が見つかりません: