Claude Codeでgit worktreeを使う手順｜複数作業のファイル衝突を防ぐ

Claude Codeの作業をgit worktreeで分離し、複数セッションの編集衝突を防ぐ手順を、作成・起動・統合・片付けまで順番に解説します。

Claude Codeで複数の作業を同時に進めるなら、同じフォルダで複数セッションを開くのではなく、作業ごとにgit worktreeを分けます。worktreeは、一つのGitリポジトリから別々の作業フォルダとブランチを用意する機能です。たとえるなら「同じ本棚を共有する、別々の作業机」です。履歴は共有しながら、編集中のファイルは分離できます。

この記事では、Claude Codeの--worktreeを中心に、作成、起動、環境の準備、統合、後片付けまでを順番に説明します。Gitの基本操作に不安がある場合は、先にClaude Codeにファイルを触らせる基本も確認してください。

git worktreeで防げる衝突と防げない衝突

同じフォルダで二つのセッションを動かすと、片方が読んだファイルを他方が先に書き換え、古い内容で上書きする恐れがあります。

worktreeでは、作業Aと作業Bを別フォルダ・別ブランチで編集します。Claude Code公式のworktree解説では、各worktreeが独自のファイル状態とブランチを持ちながら、リポジトリの.gitディレクトリ(=Gitの管理情報)は元のフォルダと共有する、と説明されています。つまり履歴は一つのまま、作業場所だけが増えます。完全に独立した複製を作る機能ではありません。

一方で、防げない衝突もあります。GitHub公式のmerge conflict解説にあるとおり、同じ行を別々に変更した場合や、一方が編集したファイルを他方が削除した場合は、統合時に競合(=どちらを採用するかGitが決められない状態)が起こります。worktreeは「同じ実ファイルを同時に触る事故」を減らす仕組みであり、設計の食い違いまで自動で解決する機能ではありません。この区別を最初に押さえておくと、後の判断が楽になります。

worktreeへ分ける作業を先に決める

片方の結果を待たず、変更範囲も分離できる作業だけをworktreeへ分けます。たとえば「記事表示の修正」と「通知メールのテスト追加」です。

開始前に、各作業へ次の4項目を割り当てます。

目的と完了条件
変更してよいファイル
変更しないファイル
実行する検証コマンド

同じ設定ファイル、データベース定義、依存関係のlockfile(=ライブラリの版を固定するファイル)を変えるなら、同時進行を避けます。分割の判断はAIを同時に何人も動かすときの分け方でも説明しています。

分け方の判断表

状況	worktreeの判断	理由
変更ファイルが重ならず、個別にテストできる	分けやすい	編集と検証を独立させられる
同じファイルでも、変更箇所と目的が明確に離れている	慎重に分ける	統合時に競合や仕様の食い違いが起こり得る
同じlockfileやデータベース定義を変更する	原則、順番に進める	個別には成功しても、統合後に不整合が出やすい
作業Bが作業Aの結果を必要とする	分けない	並列ではなく依存関係のある直列作業
調査だけでファイルを編集しない	worktreeは必須ではない	読み取り専用ならファイル衝突が起きない

Claude Codeをworktreeで起動する手順

手を動かす順番は次のとおりです。

リポジトリのルートでgit status --shortを実行し、作業中の変更が散らかっていないか確認します。
そのフォルダでClaude Codeを初めて使う場合は、先に通常のclaudeを一度起動して、フォルダの信頼確認(workspace trust)を済ませます。公式のworktree解説によると、-pを付けた非対話実行(=質問に答えず一括で走らせる形)ではこの確認が省略されるため、対話実行と同じ前提では動きません。
.claude/worktrees/を.gitignoreへ追加します。公式ページもこの追加を案内しています。
名前を付けて起動します。

claude --worktree feature-login

短縮形の-wも使えます。

claude -w fix-header

既定では.claude/worktrees/<名前>/へ作業場所が作られ、worktree-<名前>という新しいブランチで始まります。名前を省略すると自動生成されます。

二つ目の作業は、別のターミナルで別の名前を付けて起動します。

# ターミナル1
claude --worktree feature-login

# ターミナル2
claude --worktree fix-header

各セッションの最初に、現在地と担当を確認させます。

現在の作業フォルダとブランチを確認してください。
担当はログイン画面だけです。
変更予定のファイルを示し、まだ編集しないでください。

場所やブランチを自分で指定したい場合は、Git公式のgit-worktreeドキュメントにあるとおり、Gitから直接作成します。

git worktree add ../project-feature-login -b feature-login
cd ../project-feature-login
claude

git worktree listを実行すると、作業場所、コミット、ブランチを一覧できます。担当名とブランチ名を一致させると取り違えを減らせます。

起点のブランチと開発環境をそろえる

worktreeを作ったのに「さっきのローカル変更が入っていない」と戸惑う人が多いので、起点の仕組みを整理します。

既定のfreshは、リモートのデフォルトブランチを起点にします。未プッシュのローカルコミットは入りません。
設定worktree.baseRefをheadにすると、現在のローカルHEAD(=いま自分がいるコミット)を起点にできます。
公式のsettings解説のとおり、worktree.baseRefに受け付ける値はfreshとheadだけです。任意のブランチ名は指定できません。特定のブランチから始めたい場合は、上で示したgit worktree addを使います。

なお2026-07-26時点の公式案内では、freshのときリポジトリが24時間以内にfetchされていなければ、5秒を上限にデフォルトブランチの取得を試みる、といった細かい既定も記載されています。この種の数値は変わりやすいので、挙動が気になる場合は公開時点の公式案内で確認してください。

環境の準備も自動ではそろいません。新しいworktreeは新規チェックアウトなので、次の3つを分けて考えます。

依存関係: Node.jsプロジェクトなら各worktreeでnpm installを実行します。npm公式ドキュメントにあるとおり、引数なしのnpm installはpackage.jsonとpackage-lock.jsonを比較して依存関係を導入します。
.envなどGitで無視しているファイル: .worktreeincludeに.gitignoreと同じ形式で書くとコピーされます。ただしコピーされるのは、パターンに一致し、かつGitで無視されているファイルだけです。追跡済みファイルは複製されません。秘密情報は無条件で複製せず、worktreeごとに必要性と保管方法を確認します。詳しくはAIコーディングで秘密情報を守る方法を参照してください。
node_modulesなどの大きなフォルダ: 既定では共有されません。設定worktree.symlinkDirectoriesに指定したフォルダだけ、元のリポジトリからリンクで共有できます。これは任意設定で、既定では何もリンクされません。

変更を統合し、worktreeを片付ける

各worktreeで担当範囲を検証し、差分を確認してコミットします。

git status --short
git diff
# プロジェクト固有のテストを実行
git add <確認済みのファイル>
git commit -m "ログイン画面の入力検証を追加"

統合側に作業中の変更がないことを確認し、ブランチを一つずつ取り込みます。GitHub公式の解説でも、mergeは「別の作業をローカルの変更へ統合する操作」と説明されています。

git status --short
git switch main
git merge feature-login
# 統合後のテストを実行

統合先がmainでなければ読み替えてください。GitHubを使っているなら、pull request(=変更の取り込み提案)経由の統合も選べます。説明、コミット、自動検査(Checks)、変更ファイルを一か所で確認してからマージできます。これはGitHub利用時の選択肢であり、worktree自体に必須の手順ではありません。

競合が出たら、機械的に片方を採用せず、両方の作業の目的を読み直します。統合後は、個別テストだけでなく組み合わせた状態のテストも行います。AI生成コードの検品チェックリストも利用できます。

片付けは次の順です。

Claude Codeの対話セッションを終了すると、公式の案内どおり、名前なしで変更もないworktreeは自動削除されます。名前付きや、未コミット変更・新しいコミットがある場合は、保持か削除かを確認されます。削除を選ぶ前に、必要な変更が統合済みか確かめてください。
-p付きの非対話実行には終了確認がないため、作ったworktreeは自動では片付きません。自分でgit worktree removeを実行します。
手動で片付けるときは、空であることを確認してから削除します。

git worktree list
git -C ../project-feature-login status --short
git worktree remove ../project-feature-login
git branch -d feature-login

git worktree removeは、既定では変更のない(clean)worktreeだけを削除できます。--forceは通常手順にしません。git branch -dも、統合済みかをGitが確認してから削除します。フォルダを手で消してしまった後に残る管理情報は、git worktree pruneで整理できます。pruneは作業フォルダを消す通常手段ではなく、残骸の掃除用です。

現在地が分からなくなったら編集を止め、AIコーディングの引継ぎメモへ記録してください。

よくある質問

git worktreeとgit cloneの違いは何ですか

git cloneはリポジトリ一式を別フォルダへ複製し、リモート設定やコミットも新しく取得します。git worktreeは一つのリポジトリの管理情報を共有しながら、作業フォルダとブランチを追加します。同じプロジェクト内で複数ブランチを並行編集する用途では、worktreeの方が作業場所とブランチの対応を管理しやすい場合があります。

同じブランチを複数のworktreeで同時に開けますか

Gitは既定で、すでに別のworktreeでチェックアウトされているブランチを、新しいworktreeへ追加することを拒否します。作業ごとに別ブランチを用意し、最後に統合してください。

.envやnode_modulesは新しいworktreeにも入りますか

既定ではどちらも入りません。新しいworktreeは追跡対象ファイルの新規チェックアウトだからです。依存関係は各worktreeで導入します。.envなどGitで無視しているファイルは.worktreeincludeでコピーできますが、秘密情報を含む場合はコピー範囲を絞ります。大きなフォルダの共有にはworktree.symlinkDirectoriesという任意設定もあります。

worktreeに最新のローカルコミットが見えないのはなぜですか

Claude Codeの既定のfreshは、リモートのデフォルトブランチを起点にするためです。未プッシュのコミットや作業ブランチの状態を引き継ぎたい場合は、worktree.baseRefのheadを検討します。未コミット変更は先に整理し、引き継ぐ内容を明確にしてください。

worktreeを削除すると変更やコミットも消えますか

git worktree removeは作業フォルダを取り除くコマンドで、ブランチの削除は別操作です。ただしClaude Codeの終了時確認で「削除」を選ぶと、そのworktreeの未コミット変更、未追跡ファイル、新しいコミットも削除対象になります。先に統合済みか、必要なコミットが別の参照からたどれるかを確認します。

まとめ

git worktreeは、複数のClaude Code用の「別の作業机」です。作成、担当固定、環境準備、個別検証、一つずつ統合、cleanを確認して削除、の順を守れば、同じファイルを奪い合う事故を減らせます。ただし同じ行や同じ設計を別々に変えれば競合は残ります。仕組みの限界を知ったうえで使うのが上達の近道です。

次にやることは3つです。

手元のリポジトリでgit status --shortを実行し、散らかった変更がない状態を作る
独立した小さい作業を2つ選び、claude --worktreeで1回ずつ試す(いきなり本番の大きい作業で試さない)
終わったらgit worktree listで残りを確認し、統合済みのworktreeをgit worktree removeで片付ける

公式一次情報

確認日: 2026-07-26

Claude Code公式「Run parallel sessions with worktrees」: --worktree/-wの使い方、既定の保存先とブランチ名、fresh/headの起点、.worktreeinclude、終了時の片付けの違いが説明されています。
Claude Code公式「Settings」: worktree.baseRef(fresh/head)やworktree.symlinkDirectoriesなど、worktree関連の設定項目が記載されています。
Git公式「git-worktree」: add・list・remove・pruneの各コマンドと、同一ブランチの重複チェックアウトやcleanでないworktreeへの安全措置が説明されています。
GitHub公式「Merge conflicts」: 同じ行への別変更などで競合が起こる条件と、解消するまでマージできないことが説明されています。
GitHub公式「Pull requests」: 変更の取り込み提案で、会話・コミット・自動検査・差分を一か所で確認できることが説明されています。
GitHub公式「Getting changes from a remote repository」: clone・fetch・merge・pullの役割の違いが整理されています。
npm公式「npm-install」: npm installがpackage.jsonとpackage-lock.jsonを比較して依存関係を導入することが説明されています。