Claude Code × git worktree 並列開発ガイド|複数タスクを衝突なく同時進行【2026】
結論:git worktree を使うと、1つのリポジトリに対して「別々の作業ディレクトリ+別ブランチ」を複数並べられる。各ツリーで Claude Code を起動すれば、機能開発とバグ修正を同時に走らせても、ファイルが物理的に分かれているので編集が干渉しない。Claude Code v2 系には --worktree(-w)という専用フラグがあり、面倒な git worktree add を手打ちせずにこの環境を自動で作れる。
- 要点1:worktree は「checkout を切り替える」のではなく「checkout を増やす」。だからブランチ切替の stash 退避地獄から解放される。
- 要点2:
claude --worktree feature-auth一発で、隔離された作業コピーと新ブランチを作ってその中で Claude Code が起動する。 - 要点3:サブエージェント並列(1セッション内で複数 Task を動かす)とは別軸。worktree は「複数の Claude Code プロセスを別の作業コピーで走らせる」ためのもの。
対象読者:Claude Code を日常的に使っていて、「2つの作業を行ったり来たりするのがつらい」「並行作業でファイルがぶつかる」と感じている開発者・エンジニア・PM。
今日やること:自分のリポジトリで claude --worktree を1回叩いて、2タスク同時進行の感覚を掴む。
正直、Claude Code を1枚のターミナルで使っていると、すぐにこの壁にぶつかる。「機能Aを実装させてる最中に、本番でバグが見つかった。でも今のブランチには中途半端な差分が乗っていて、切り替えるには git stash するしかない。戻ってきたら、どこまでやってたか分からなくなる」——この「作業の取り違え」と「ブランチ切替コスト」を構造的に消すのが git worktree だ。本記事は2026年6月時点の git 公式・Claude Code 公式ドキュメントを根拠に、なぜ worktree なのか、基本コマンド、Claude Code の native 機能、運用のコツ、そしてサブエージェント並列との使い分けまでをまとめる。

なぜブランチ切替ではなく worktree なのか
多くの人が「並行作業=ブランチを切り替える」と考えている。だが git checkout(あるいは git switch)は、1つの作業ディレクトリの中身を丸ごと別ブランチの状態に書き換える操作だ。ここに3つの痛みがある。
- 未コミット差分の退避が必須:作業途中で別ブランチに移るには、変更を
git stashするかコミットするしかない。stash は積み上がると「どれが何の作業だったか」が分からなくなる。 - 作業の取り違え:同じディレクトリで2つのタスクを切り替えると、ビルド成果物・
node_modules・キャッシュが混ざり、「さっきまで動いてたのに」が起きる。AI エージェントに任せている場合、Claude Code は今いるディレクトリのファイルを見て編集するので、切替直後の中途半端な状態を前提に動いてしまうリスクがある。 - 並行作業の衝突:2つの Claude Code セッションを同じディレクトリで動かすと、片方の編集がもう片方のファイルを上書きする。これは事故そのものだ。
git worktree はこの発想を変える。1つのリポジトリ(共有された履歴・remote)に対して、独立した作業ディレクトリを複数ぶら下げる。各ディレクトリは別のブランチをチェックアウトし、自分のファイルを物理的に別の場所に持つ。だから「切り替える」必要がない。タスクAのツリーとタスクBのツリーが最初から別の場所にあり、それぞれで Claude Code を起動すれば、編集が物理的にぶつからない。Claude Code 公式ドキュメントも「各セッションを自分の worktree で動かせば、片方の編集がもう片方のファイルに触れることはない」と明記している。
worktree が共有するもの・しないもの
worktree は履歴(.git のオブジェクト DB)と remote を共有する。一方で、作業ファイル・チェックアウト中のブランチ・ビルド成果物は各ツリー独立だ。重要な制約として、git は同じブランチを2つの worktree で同時にチェックアウトすることを既定で拒否する(--force でのみ上書き可能)。これは「同じブランチに2方向から編集が入る」事故を防ぐための安全装置で、worktree を「1ツリー=1ブランチ」で運用すべき理由でもある。
git worktree の基本コマンド
まずは素の git でやってみる。Claude Code の native 機能は内部的にこれを実行しているので、挙動を理解しておくと運用が楽になる。手順は次の通り。
- 新しいブランチで worktree を作る。リポジトリのルートで実行する。
../に置くことで、メインのチェックアウトの外に作業ディレクトリができる。git worktree add ../project-feature-a -b feature-aこれは「
feature-aという新ブランチを作り、それを../project-feature-aディレクトリにチェックアウトする」操作。-bを付けない場合、パス末尾の名前(この例ならproject-feature-a)と同名のブランチが自動生成される。 - 既存ブランチで worktree を作る。すでにある
bugfix-123ブランチを別ディレクトリに展開したいときはこう書く。git worktree add ../project-bugfix bugfix-123 - そのツリーで Claude Code を起動する。
cd ../project-feature-a && claude別のターミナルを開いて
../project-bugfixでclaudeを起動すれば、2つのタスクが別ファイル・別ブランチで同時進行する。 - worktree の一覧を確認する。
git worktree listメインの worktree を先頭に、各ツリーのパス・現在のコミット・ブランチ(または
detached HEAD)が並ぶ。スクリプトで扱うなら--porcelainでパースしやすい形式に切り替えられる。 - 使い終わったら削除する。
git worktree remove ../project-feature-aremoveは未コミット変更や未追跡ファイルが残っているとデフォルトでは消さない(--forceが必要)。手動でディレクトリをrmしてしまった場合はgit worktree pruneで管理情報($GIT_DIR/worktrees配下の残骸)を掃除する。
各 worktree のルートには .git というファイル(ディレクトリではない)が置かれ、そこから本体リポジトリの $GIT_COMMON_DIR を参照している。だから履歴やリモートは1か所に集約され、ディスクの肥大化も最小限で済む。1点だけ注意:worktree は新規チェックアウトなので、各ツリーで依存インストール(npm install など)や仮想環境のセットアップを個別に行う必要がある。
Claude Code の native worktree 機能(–worktree フラグ)
2026年6月時点で、Claude Code は worktree を native サポートしている。git worktree add を手打ちしなくても、--worktree(短縮形 -w)を渡すだけで、隔離された worktree を作ってその中でセッションを起動してくれる。手順はこうだ。
- 名前を付けて起動する。
claude --worktree feature-auth既定では、リポジトリルートの
.claude/worktrees/<名前>/に worktree を作り、worktree-<名前>という新ブランチをチェックアウトしてその中で Claude Code を起動する。上の例なら.claude/worktrees/feature-auth/に作られ、ブランチはworktree-feature-authになる。 - 別ターミナルで2本目を起動する。名前を変えてもう一度叩けば、2つ目の隔離セッションが立ち上がる。
claude --worktree bugfix-123これで「片方は機能実装、もう片方はバグ修正」が、別ブランチ・別ファイル・干渉ゼロで並走する。
- 名前を省略すると自動命名される。
claude --worktreebright-running-foxのような名前を Claude が生成する。とりあえず1本切りたいときに便利。 - セッション中に頼む方法もある。会話の途中で「worktree で作業して」と頼むと、Claude Code が
EnterWorktreeツールで worktree を作る。すでに worktree 内にいる場合は、.claude/worktrees/配下の別ツリーへ直接切り替えることもできる(元の worktree はディスク上にそのまま残る)。
初回だけ注意点がある。あるディレクトリで初めて --worktree を使う前に、一度 claude を素で起動して workspace trust ダイアログを承認しておく必要がある。承認前に --worktree を使うとエラーで終了し、「先にそのディレクトリで claude を実行せよ」と促される(-p と併用した場合も同じ)。また、worktree の中身がメインのチェックアウトに未追跡ファイルとして現れないよう、.gitignore に .claude/worktrees/ を追加しておくのが公式推奨だ。
ベースブランチと .env の引き継ぎ
native worktree は既定で origin/HEAD(リポジトリのデフォルトブランチのリモート最新)から分岐する。remote 上のクリーンな状態から始められるのが狙いだ。逆に「自分の手元の未 push コミットを引き継ぎたい」場合は、settings.json で worktree.baseRef を "head" にする。
{
"worktree": {
"baseRef": "head"
}
}
この設定は "fresh"(既定)か "head" のどちらかのみで、任意の git ref は指定できない。特定の PR から分岐したいときは、PR 番号を # 付きで渡せる。
claude --worktree "#1234"
これは origin から pull/1234/head を fetch し、.claude/worktrees/pr-1234 に worktree を作る。レビューのためにブランチ全体を隔離して動かしたいときに効く。
もう1つ実務で重要なのが、gitignore されたローカル設定ファイルの引き継ぎだ。worktree は新規チェックアウトなので、.env や .env.local のような未追跡ファイルは持ち込まれない。プロジェクトルートに .worktreeinclude を置くと、ここに書いたパターンに一致しかつ gitignore されているファイルだけが新しい worktree に自動コピーされる(追跡済みファイルは二重コピーされない)。
.env
.env.local
config/secrets.json
並列運用のコツ——命名・共有設定・マージ
worktree を「ただ作れる」段階から「事故なく回す」段階に上げるための実務ノウハウをまとめる。
- 命名は「目的」で揃える:
--worktree feature-auth--worktree bugfix-login-500のように、ブランチ名がそのまま worktree 名になる前提で「何のための作業か」が一目で分かる名前にする。git worktree listや.claude/worktrees/のディレクトリ一覧が、そのまま「いま走っている作業の地図」になる。 - 1ツリー1ブランチを守る:前述の通り git は同一ブランチの二重チェックアウトを拒否する。
--forceで無理に通さない。タスクが分かれているならブランチも worktree も分ける。 - 共有設定は
.worktreeincludeに集約:チームで使うなら、どのローカル設定ファイルを worktree に引き継ぐかを.worktreeincludeに明文化しておく。新メンバーが--worktreeを叩いても.env不足で詰まらない。 - 各ツリーで環境構築を忘れない:依存インストール・ビルド・マイグレーションは worktree ごとに必要。「メインでは動くのに worktree で動かない」の大半はこれ。
- マージは通常のブランチ運用そのまま:worktree のブランチは普通の git ブランチなので、作業が終わったら push して PR を出し、main にマージする。マージ後は
git worktree remove(または native の場合はセッション終了時の片付け)でツリーを消し、ブランチも削除する。worktree が増えすぎると認知負荷が上がるので、「終わったら消す」を徹底する。
後片付けの自動・手動の境界
native worktree のクリーンアップは、変更の有無で挙動が変わる。未コミット変更・未追跡ファイル・新規コミットがいずれも無い状態でセッションを終えると、worktree とブランチは自動削除される(セッションに名前を付けている場合は、後で使えるよう削除前に確認される)。逆に何らかの変更が残っていれば「残すか消すか」を尋ねられ、残せばディレクトリとブランチが保持される。
注意すべき例外が2つある。1つは -p(非対話実行)と --worktree を併用したケースで、終了プロンプトが無いため自動削除されない——git worktree remove で手動削除する。もう1つは、--worktree で自分が明示的に作った worktree は、cleanupPeriodDays 設定による定期掃除の対象外で、自動では消えない点だ(自動掃除の対象はサブエージェントやバックグラウンドセッションが作った一時 worktree)。「作ったのに勝手に消えない/消える」の混乱は、この境界を知っていれば避けられる。
サブエージェント並列との違いと使い分け
Claude Code で「並列」と言うと、worktree のほかにもう1つの軸——サブエージェント並列(1つのセッション内で複数のサブエージェントに作業を分担させる)がある。この2つは混同されやすいが、解決している問題が違う。
- サブエージェント並列(in-session):1つの Claude Code セッションの中で、
.claude/agents/に定義した複数のエージェントに役割を分けて作業を分担させる。「調査班」「実装班」のように仕事そのものを分割するのが目的。詳しくはClaude Codeサブエージェント並列開発入門で解説している。 - git worktree(プロセス分離):複数の Claude Code プロセスを、別々の作業コピー(別ディレクトリ・別ブランチ)で走らせる。ファイル編集を物理的に隔離するのが目的。タスクAとタスクBが互いのファイルに触れない状態を作る。
公式ドキュメントの整理を借りれば、「worktree はファイル編集を隔離する/サブエージェント・エージェントチームは作業そのものを調整する」という役割分担になる。重要なのは、この2つは排他ではなく組み合わせられること。サブエージェントに isolation: worktree を frontmatter で設定すると、各サブエージェントが一時 worktree の中で動き、並列編集が衝突しなくなる。セッション中に「エージェントに worktree を使わせて」と頼むだけでも有効化できる。
どちらを使うか——判断の目安
- 「全く別の2タスクを同時に進めたい」→ worktree。機能開発とホットフィックスのように、文脈もブランチも分かれているなら
--worktreeでプロセスごと分ける。 - 「1つのタスクを手分けして速くしたい」→ サブエージェント並列。「テストを書く班」「実装する班」のように1つのゴールを分担するなら in-session で十分。
- 「手分けしたいが編集がぶつかるのが怖い」→ サブエージェント × worktree 隔離。並列度を上げつつ衝突も防ぎたいなら、サブエージェントに worktree 隔離を付ける。
worktree の運用に慣れたら、CLAUDE.md でプロジェクトの前提(worktree の置き場所・命名規約・.worktreeinclude の方針)を共有しておくと、チーム全体で同じ並列ワークフローを再現できる。CLAUDE.md の設計はCLAUDE.md設計・運用ガイドに詳しい。さらに大きな変更を並列で安全に進めるなら、Plan Mode実践ガイドと組み合わせると、各ツリーで「計画→実装」の流れを崩さずに回せる。
よくある質問(FAQ)
Q. worktree を作るとディスクが2倍になりますか?
作業ファイルは複製されますが、git の履歴オブジェクト(.git の本体)は1か所に集約され、各 worktree は .git ファイル経由でそれを共有します。履歴が巨大なリポジトリでも、増えるのは作業ツリー分のファイルだけです。
Q. 同じブランチを2つの worktree で開けますか?
既定ではできません。git が二重チェックアウトを拒否します(--force で上書きは可能ですが非推奨)。タスクが分かれているならブランチも分けてください。
Q. --worktree はどの git でも使えますか?
native worktree 機能は git リポジトリ前提です。SVN・Perforce・Mercurial などでは、WorktreeCreate/WorktreeRemove フックでカスタムの作成・後片付けロジックを定義します。ただしフックが既定の git 挙動を置き換えるため、その場合 .worktreeinclude は処理されず、ローカル設定のコピーはフック内で自分で行う必要があります。
Q. worktree とサブエージェント並列、どちらが速いですか?
「速さ」の軸が違います。worktree は別プロセス・別ファイルで完全に並走するので独立タスクの同時進行に強く、サブエージェント並列は1つのタスクを分担して仕上げを速くします。前述の判断目安に沿って選んでください。
まとめ——今日から始める3つのアクション
git worktree は「ブランチを切り替える」発想を「作業ディレクトリを増やす」発想に変えることで、ブランチ切替コスト・作業の取り違え・並行作業の衝突を構造的に消す。Claude Code の --worktree フラグは、その環境構築を一発で自動化してくれる。最後に、今日試せる3アクションを置いておく。
- 素の git で1本作ってみる:
git worktree add ../myrepo-test -b wt-test→ そのディレクトリでclaudeを起動し、メインと干渉しないことを体感する。 - native フラグを使う:対象リポジトリで一度
claudeを起動して trust を承認したあと、claude --worktree feature-xで隔離セッションを立ち上げる。.gitignoreに.claude/worktrees/を追加するのを忘れずに。 - 共有設定を整える:
.worktreeincludeに.envなどを書き、チームで--worktreeを叩いても設定不足で詰まらない状態を作る。慣れてきたらサブエージェントにisolation: worktreeを付けて、並列度と安全性を両取りする。
より体系的に Claude Code の実践スキルを積み上げたい場合は、Claude Code 実践テクニック完全ガイドを学習順の地図として使うとよい。worktree は、その中でも「並列開発」の土台になるテクニックだ。
著者プロフィール
佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載を7回執筆。Claude Code を中核にした開発ワークフローの設計・社内導入支援を専門とする。
参考・出典
- git-worktree Documentation — Git 公式リファレンス(2026年6月確認)
- Run parallel sessions with worktrees — Claude Code 公式ドキュメント(2026年6月確認)
- Subagents — Claude Code 公式ドキュメント(2026年6月確認)
- Settings(worktree.baseRef / cleanupPeriodDays)— Claude Code 公式ドキュメント(2026年6月確認)
- Hooks(WorktreeCreate / WorktreeRemove)— Claude Code 公式ドキュメント(2026年6月確認)