マガジン

git worktreeでClaude Codeを並行して動かす:作業の衝突を避ける手順

AIを使いこなす

Claudeで執筆し、GPTで自動校閲・修正しています。

二つの紙フォルダーに分けられた並行作業を表す机上の静物
記事の内容をもとに制作したAI生成イメージです。実際の製品画面や検証結果の写真ではありません。

結論から言うと、Claude Codeには --worktree(短縮形 -w)オプションがあり、名前を付けて起動するだけで、専用のgit worktreeを作ってその中でセッションを始められます。別のターミナルで別の名前を指定すれば、2つ目のセッションは別のフォルダ・別のブランチで動くため、編集中のファイルが混ざりません。 claude --worktree feature-auth 公式ドキュメントでは、worktreeを「同じリポジトリの履歴を共有しつつ、ファイルとブランチを独立して持つ作業ディレクトリ」と説明しています(Run parallel sessions with worktrees)。この記事では、作成、セッション起動、片付けまでの流れと、つまずきやすい点を表にまとめます。なお、コマンドや依頼文の例は公式ドキュメントの記述をもとにした説明用の例で、私が実際に動かして確かめたものではありません。ご自身のリポジトリでは、まず捨てても困らないブランチで試してください。確認した資料は2026年10月28日時点のものです。

この記事の目次
  1. 全体の流れ(最小手順)
  2. 作成前に整える3つのこと
  3. 2つのセッションを並行して動かす
  4. 片付け:終了時のプロンプトと手動削除
  5. 見落としやすい注意点の表
  6. Claude Codeに任せる範囲と人の確認

全体の流れ(最小手順)

  • 1、やること:リポジトリに最低1コミットあることを確認、コマンドや操作:git log --oneline -1
  • 2、やること:初回だけ、通常の claude を起動して信頼ダイアログを承認、コマンドや操作:claude
  • 3、やること:.claude/worktrees/ を .gitignore に追加、コマンドや操作:下記参照
  • 4、やること:1つ目のターミナルで起動、コマンドや操作:claude --worktree feature-auth
  • 5、やること:2つ目のターミナルで別名を指定して起動、コマンドや操作:claude --worktree fix-login-bug
  • 6、やること:作業が済んだら各セッションを終了し、残すか消すかを選ぶ、コマンドや操作:終了時のプロンプト
  • 7、やること:手動で消す場合、コマンドや操作:git worktree list → git worktree remove <パス>

作成前に整える3つのこと

公式ドキュメントによると、worktreeは既存のコミットから作られるため、コミットが1つもないリポジトリでは Failed to resolve base branch "HEAD" というエラーで失敗します(Common workflows)。また、そのディレクトリで一度もClaude Codeを起動していない場合、対話モードの --worktree はワークスペースの信頼確認が済んでいないとしてエラー終了します。先に claude を一度起動して承認してください。

次に、既定ではworktreeがリポジトリ直下の .claude/worktrees/<名前>/ に、worktree-<名前> という新しいブランチで作られます。メインの作業場にこのフォルダが未追跡ファイルとして出ないよう、公式は .gitignore への追加を勧めています。

text
.claude/worktrees/

最後に、worktreeは新しいチェックアウトなので、.env のようなgit管理外のファイルや、インストール済みの依存関係は入っていません。依存関係は、Claudeに「このworktreeで依存をインストールして」と頼むか、自分でセットアップコマンドを実行します。.env 類は、プロジェクトのルートに .worktreeinclude を置くと新しいworktreeへ自動でコピーされます。書式は .gitignore と同じで、パターンに一致し、かつgitで無視されているファイルだけが対象です。

text
.env
.env.local

秘密情報を含むファイルをコピーする設定になるため、何を列挙するかは最小限にしてください。

2つのセッションを並行して動かす

ターミナルAとBを開き、それぞれ別の名前で起動します。名前を省略すると bright-running-fox のような名前が自動で付きます。

bash
# ターミナルA
claude --worktree feature-auth

# ターミナルB
claude --worktree fix-login-bug

起動後に渡す依頼文の例

並行作業では、各セッションに「どこまでが自分の担当か」を伝えると、範囲外のファイルに手を出しにくくなります。以下は説明用の依頼文です。括弧内はご自身の内容に置き換えてください。

text
このworktreeでは「(ログイン画面にパスワード再設定リンクを追加する)」だけを担当します。
- 触ってよい範囲:(src/auth/ と tests/auth/)
- 範囲外のファイルを直す必要が出たら、編集せずに理由を教えてください
- 最初に依存関係をインストールし、既存のテストが通ることを確認してください
- 終わったら、変更したファイルの一覧とテスト結果を報告してください

人が確認する点は、報告された変更ファイルが担当範囲に収まっているか、テストを実際に実行した出力が付いているか、の2つです。

現在地の確認

どのセッションがどこにいるか迷ったら、別のターミナルで次を実行します。

bash
git worktree list

メインの作業場と各worktreeのパス、ブランチが一覧で出ます。

片付け:終了時のプロンプトと手動削除

対話セッションを終了すると、Claude Codeはworktreeに削除で失われる作業(変更・未追跡ファイル・新しいコミット)がないか調べます。公式の挙動は次のとおりです。

  • 変更がなく、名前なしで起動したセッション:worktreeとブランチが自動で削除されます。
  • 変更がなく、名前付きのセッション:残すかどうかを確認するプロンプトが出ます。
  • 作業が残っている場合:残すか消すかを聞かれます。消すとディレクトリとworktree用のブランチが、中の作業ごと削除されます。残した場合は、終了時に表示される claude --worktree <名前> --resume で戻れます。

つまり、名前を付けて作業した成果も、確認時に「消す」を選ぶと失われます。残したい変更は、プッシュやPRなどで別途保存してから終了するか、プロンプトでworktreeを残してください。

手動で片付けるときは次の順に進めます。

bash
git worktree list                       # 対象を確認
git worktree remove .claude/worktrees/feature-auth
git branch -d worktree-feature-auth     # 不要になったブランチ(任意)

未コミットの変更が残っていると remove は拒否します。中身を捨てると確認できた場合だけ --force を付けてください。非対話の -p で作ったworktreeは自動では片付かず、作成時のロックが残るため、git worktree remove が拒否されたら先に git worktree unlock を実行します。手作業で rm -rf した後にgit側の記録だけが残った場合は、git worktree prune で整理できます(Gitの仕様)。

見落としやすい注意点の表

  • 分岐元が最新のリモート既定ブランチ、何が起きるか:既定では worktree.baseRef が "fresh" で、リモートの既定ブランチ(通常 main)から分岐します。手元の未プッシュのコミットは入りません、対処:手元の作業を引き継ぎたいなら設定で "head" にする。特定の既存ブランチから始めたいなら git worktree add を使う
  • 同じブランチは2か所で使えない、何が起きるか:既存ブランチを手動で追加するとき、すでに別の場所でチェックアウト中だとGitが拒否します(Gitの仕様)、対処:作業ごとにブランチを分ける
  • .env や依存関係がない、何が起きるか:新しいチェックアウトなので動かない、対処:.worktreeinclude と、worktree内でのセットアップ
  • Git LFSがポインタファイルのまま、何が起きるか:git lfs install --local の場合、Claude Codeが作るworktreeは実ファイルでなくポインタになります、対処:worktree内で git lfs pull
  • 許可設定が共有される、何が起きるか:Bashコマンドで「今後確認しない」を選ぶと、メイン側の .claude/settings.local.json に保存され、他のworktreeにも効きます、対処:並行セッションでは許可の範囲を狭く選ぶ
  • cp やリダイレクトは検知されない、何が起きるか:編集ツールやgitの向き先のチェックはあるものの、シェルの cp やリダイレクトでメイン側に書く操作は、これらのチェックでは止まりません、対処:通常の権限設定とサンドボックスで管理し、コマンドの出力先を確認する
  • 手動作成分は自動掃除されない、何が起きるか:git worktree add で自作したworktreeは、公式の定期掃除の対象外です、対処:自分で git worktree remove する

worktreeが分けるのはファイルとブランチです。2つのセッションが同じ関数を別々に書き換えれば、統合時のマージ衝突は起こりえます。また、開発サーバーのポートなど、フォルダ以外の共有資源は分かれません(後者は一般的な注意で、公式の記述ではありません)。そのため、担当範囲を先に分け、マージは1つずつ順に行うのが現実的です。

Claude Codeに任せる範囲と人の確認

  • 任せられること:worktree内での実装、依存のインストール、テスト実行、変更内容の報告。「worktreeで作業して」と頼むと、セッション中にClaudeが作成することもできます。
  • 人が決めること:どの作業を並行させるか、担当ファイルの境界、.worktreeinclude に載せるファイル、終了時に「消す」を選んでよいか。
  • 人が確認すること:git worktree list の結果、各ブランチの差分、マージ前のテスト結果。

手動でブランチ名や置き場所を決めたい場合は、公式にも次の例があります。

bash
git worktree add ../project-feature-a -b feature-a
cd ../project-feature-a
claude

この方法ならリポジトリの外に置けますが、前述のとおり自動掃除の対象外なので、片付けは自分で行います。

出典・参考資料