レビュー待ちの間に別ブランチで修正を走らせたくて、Claude Codeのセッションを2つ起動したら、同じ作業ディレクトリでファイルが上書きし合ってハマったことがあります。同じフォルダで並列動作させるとチャット側の認識と実ファイルがズレるので、ブランチを切り替えた瞬間にもう片方のClaudeが壊れる、というのが典型的な詰まり方です。
この衝突を素直に解決してくれるのがGit worktreeで、Claude Code 2026.02以降は--worktreeフラグとしてネイティブ対応されています。2つのClaudeを物理的に別ディレクトリで動かせるので、機能開発と緊急修正を同じリポジトリで並行させても干渉しません。ここでは、使い始めから運用で詰まるところまでまとめておきます。
検証環境はmacOS Sonoma、git 2.45、claude-code 2026.04系を想定しています。
Claude Code –worktreeが解決する課題
まずは何を解決してくれる機能なのかを押さえておきます。ブランチ切り替え運用で何が詰まるのかを整理すると、--worktreeが「単なる便利機能」ではなくセッション設計の中心になる理由が見えてきます。
そもそもgit worktreeとは
Git worktreeは、1つのリポジトリに対して複数の作業ディレクトリを同時に持つための機能です。.gitディレクトリ（オブジェクトDB）は共有しながら、チェックアウトしているブランチと作業ファイルだけ別物にできます。
cd ~/projects/myapp
git worktree add ../myapp-hotfix hotfix/login-bug
git worktree list/Users/moha/projects/myapp a1b2c3d [main]
/Users/moha/projects/myapp-hotfix d4e5f6a [hotfix/login-bug]1行目がメインで作業しているディレクトリ、2行目が追加したworktreeです。同じリポジトリ履歴を共有しているので、片方でpushしたコミットはもう片方でgit fetchすれば普通に見えます。
従来のブランチ切り替えで起きる問題
worktreeを使わずにClaudeを並列で動かそうとすると、次のような問題が起きます。
- ファイル状態の不整合：片方のセッションで
git checkout other-branchした瞬間、もう片方のClaudeが読んでいたファイルが別物に差し替わる - TODO/計画の迷子：Claudeは作業ディレクトリを起点にコンテキストを組み立てるので、ブランチ切り替えで「編集したはずの関数が消える」ように見える
- ビルド成果物の汚染：
node_modulesや__pycache__がブランチ間で混ざって、どちらのClaudeも同じ依存で動いていると勘違いする
つまり、Claudeの問題というより1つの作業ディレクトリを2人のエージェントが共有している構図そのものが無理筋です。
ネイティブサポートで何が変わったか
従来はgit worktree addしてcdしてからclaudeを起動、という手順でしたが、ネイティブ対応後はclaude --worktree <name>だけで済みます。worktreeの作成・ブランチの作成・移動・セッション開始がワンコマンドに畳まれる、というのが実質的な変化です。
–worktreeフラグの基本的な使い方
実際にコマンドラインから起動するパターンをまとめます。ここはパターンが限られているので、一度覚えれば迷わなくなります。
新しいworktreeでセッションを開く
未作成のブランチ名を渡すと、新しいworktreeが作成されてその中でClaudeが起動します。
claude --worktree feature-search-filterCreating worktree at ../myapp-feature-search-filter
Checked out new branch 'feature-search-filter'
Starting Claude Code session in worktree...短縮形は-wで、同じ意味です。worktreeの配置場所はデフォルトだと親ディレクトリ側に作られます。プロジェクトディレクトリの横にmyapp-xxxが並ぶイメージです。
既存のworktreeを再利用する
既にworktreeを持っているブランチ名を渡した場合、新しく作らずその中でセッションを開きます。
claude -w hotfix/login-bugAttaching to existing worktree at ../myapp-hotfix-login-bug
Starting Claude Code session...昨日作った作業を翌日再開する場合、このコマンド1つで戻れるので、ブランチ名とworktree名を揃えておくと管理が楽です。
セッション内から作成するケース
フラグを使わずに、会話の中で「work in a worktree for this task」と頼む方法もあります。Claudeが裏でgit worktree addを実行して、新しいディレクトリへセッションを移してくれる挙動です。
ただしいつも同じ命名ルールになるとは限らない点には注意が必要です。明示的にブランチ名やディレクトリ名を含めて依頼した方が、後でworktree listしたときに迷子になりません。
2つのClaudeを同時に走らせる実践パターン
worktreeがあっても、複数セッションを同時に走らせるUIはClaude Code側にはないので、ターミナル側で工夫します。よく使われるのは次の3パターンです。
tmuxでペイン分割するパターン
tmuxを使うと、左右のペインでそれぞれClaudeを走らせつつ、一画面で両方の出力を追えます。
tmux new-session -s claude-parallel
# Ctrl-b % で左右分割
# 左のペイン
claude -w feature-search-filter
# 右のペインに移ってから
claude -w hotfix/login-bug[左ペイン] claude @ myapp-feature-search-filter
[右ペイン] claude @ myapp-hotfix-login-bug個人的にはこの構成が一番回しやすいです。片方がコードを書いている間にもう片方へ別タスクを投げておいて、どちらかが詰まったら支援する、という流れが取れます。
VSCodeで複数ワークスペースを開くパターン
VSCodeなら、worktreeごとに別ウィンドウを開いて統合ターミナルからClaudeを起動すれば、エディタの差分表示と連動できます。
- worktreeごとに独立した拡張機能設定（
.vscode/settings.json）が使える - 差分レビューも片方ずつウィンドウを切り替えるだけで済む
- ターミナルのカレントディレクトリを意識しなくてよい
シェルを切り替えるだけの最小構成
tmuxもVSCodeも使わない場合、ターミナルタブを2つ開いて片方ずつClaudeを起動するだけで十分です。手元で一番軽い構成ですが、両方の出力を同時に見たい場面だと疲れるので、作業量が増えたらtmuxに寄せるのが無難です。
運用で詰まりやすいポイント
起動までは簡単ですが、日常運用では別の落とし穴があります。使い込むほど効いてくるのはここの設計です。
不要なworktreeが溜まる問題
ブランチ単位で作ると、気づくとmyapp-*が10個以上並んでいる、という状況になります。マージ済みブランチのworktreeはgit worktree removeで消しておきます。
git worktree list
git worktree remove ../myapp-feature-search-filter
git worktree prune/Users/moha/projects/myapp a1b2c3d [main]
/Users/moha/projects/myapp-hotfix d4e5f6a [hotfix/login-bug]pruneは、ディレクトリ自体は消してしまったけれど管理レコードだけ残っている「死んだworktree」を掃除するコマンドです。月イチくらいで回しておくとリストが綺麗になります。
CLAUDE.mdやローカル設定の引き継ぎ
worktreeは作業ツリーを分けるだけなので、リポジトリにコミットされているCLAUDE.mdや.claude/はそのまま引き継がれます。ただし、ローカルだけで持っている.envやsettings.local.jsonはコピーされないので注意が必要です。
アンチパターンとしてよくあるのが、手でコピーを繰り返して片方だけ最新になる状態です。
# NG: 毎回手でコピーする運用
cp .env ../myapp-feature-xxx/.env
cp .env ../myapp-hotfix-yyy/.envこれだと.envを更新したときに全worktreeへ反映するのを忘れます。シンボリックリンクに切り替えておくと、メインのファイルを編集するだけで全worktreeに反映されます。
# OK: シンボリックリンクで共有する
cd ../myapp-feature-xxx
ln -s ../myapp/.env .env
ln -s ../myapp/.claude/settings.local.json .claude/settings.local.jsonlrwxr-xr-x 1 moha staff 16 4 23 10:12 .env -> ../myapp/.envCLAUDE.mdの設計ルール自体を深掘りする話は「Claude Code Plan Modeの使い方」にも書いているので、セットで読むとセッション設計のイメージが固まると思います。
node_modulesやvenvの扱い
依存関係ディレクトリは、worktreeごとに独立して持つか共有するかで方針が分かれます。
| 方式 | メリット | デメリット |
|---|---|---|
| worktreeごとに独立 | 依存バージョンが安全に分離できる | ディスク消費が倍々で増える |
| シンボリックリンクで共有 | ディスク節約、インストール不要 | 依存バージョンがズレるとビルドが壊れる |
| pnpmのワークスペース機能を使う | node_modulesを効率的に共有できる | ツール側の制約を受ける |
Pythonのvenvなら、worktreeごとに作るのが無難です。ライブラリバージョン違いでブランチを切るケースがあるので、共有すると事故ります。Nodeならpnpmを使っていれば基本的に問題になりません。
コストと並列度の設計
worktreeで並列実行が気軽になる反面、コスト面の設計は別途考える必要があります。このあたりは「Claude Codeのサブエージェント並列実行—コスト管理と設計のハマりどころ」とも共通する話です。
API課金の観点
Claude Codeのセッションは、それぞれ独立してコンテキストを持つので、2つ走らせれば実質的にトークン消費も倍になります。ただし、1セッションが長期化して圧縮（コンパクション）が走るケースと比べると、短い2セッションの方がトータルのコストは意外と少ないこともあります。
- 1本のセッションで20万トークンを往復するより、10万トークンのセッション2本の方が安く済む場合がある
- 片方を終了してから次を始める運用だと、worktreeの恩恵は薄い
- 並列させる分、レビュー負荷は上がるので純粋な生産性は1.5倍〜1.8倍が現実的なライン
現実的な並列度の目安
色々試した結論として、個人開発なら同時2セッションが限界だと感じています。3本以上はレビューと切り替えのコストで頭が追いつきません。
3本以上走らせたい場合は、タスクの性質を分けると回しやすくなります。
- 1本目：メインの機能開発（集中して見る）
- 2本目：テスト追加や軽いリファクタ（裏で走らせておいて結果だけ確認）
- 3本目：ドキュメント生成や定型作業（半自動で実行）
全部を能動的に監視するのではなく、「こちらは放っておく」前提の役割分担を組むのがコツです。
まとめ
今回の要点を整理しておきます。
- Claude Code 2026.02以降は
--worktree（-w）フラグをネイティブサポート。ブランチ切り替えによるセッション衝突を根本的に解消できる - 使い方は
claude -w <ブランチ名>の1コマンド。新規でも既存worktreeでも同じ形で使える - 並列実行はtmuxかVSCodeの複数ウィンドウと組み合わせるのが実用的
- 運用面では
.envのシンボリックリンク共有、不要worktreeの定期掃除、venv/node_modulesの方針決めが必須 - 現実的な並列度は2セッション程度。3本以上は役割を分けて監視コストを下げる設計にする
並列開発は道具が揃うほど「やればやるほど速くなる」と誤解しがちですが、実際には人間側の注意力がボトルネックです。worktreeはその中でも、少なくともファイルレベルの事故を減らしてくれるので、先に土台として入れておく価値があります。
