Claude Code時代の新常識！git worktreeで実現する、ストレスフリーな並列開発ワークフロー

はじめに

「メイン機能の開発中に、急ぎのバグ修正を頼まれた…」
「複数のプルリクエストをレビューしたいけど、いちいちブランチを切り替えるのが面倒…」

開発者であれば、誰もが一度は経験するこんな状況。これまでの私は、git stashを駆使して変更を一時退避させたり、git checkoutを繰り返してブランチ間を行き来したりすることで、なんとか対応してきました。しかし、この方法は手間がかかるだけでなく、コンフリクトやstashの管理ミスといったリスクも伴います。

もし、現在の作業を一切中断することなく、完全に独立した別の作業環境を瞬時に用意できるとしたら、どうでしょうか？

そんな方法があることを知りました、それが今回ご紹介する git worktree です。

さらに、この記事では git worktree の基本的な使い方に留まらず、Anthropic社のClaude CodeのようなAIコーディングアシスタントと組み合わせることで、開発体験がどのように革命的に向上するのか、「並列AI駆動開発」ワークフローまで踏み込んで解説します。

この記事を読み終える頃には、あなたの開発ワークフローはよりスマートで、ストレスフリーなものになっているはずです。

2025-11-02 更新: コメント欄で @raynux 様より重要なご指摘をいただき、記事を修正しました。

この記事の元となったAnthropic公式ドキュメントを含め、いくつかのgit worktreeの解説でベースブランチ（<commit-ish>）の指定が省略されていますが、これは意図しないブランチから派生するリスクがあります。

# ⚠️ 非推奨：ベースブランチを省略した例
git worktree add ../project-feature -b feature-branch

# ✅ 推奨：ベースブランチを明示的に指定
git worktree add ../project-feature -b feature-branch origin/main

ベースブランチを省略すると、現在のHEAD（作業中のブランチ）から新しいブランチが作成されてしまいます。常にmainブランチを確保しており、そこを起点にするなら問題ありませんが、フィーチャーブランチで作業中の場合、意図せず未完成の変更が含まれてしまいます。

特にホットフィックスのシナリオでは要注意です。 緊急修正のつもりが、未リリースの機能まで本番環境に混入してしまう事故に繋がる可能性があります。

常にベースブランチを明示的に指定することで、コンテキスト依存のミスを防ぎ、誰が実行しても同じ結果になる堅牢なワークフローを維持できます。

前提・環境

この記事は、以下の環境を前提としています。

• Git: バージョン 2.5.0 以上 (git worktreeが導入されたバージョンです)
• AIアシスタント: Claude Code などの対話型AIコーディングアシスタントが利用できると、より本記事の内容を実感できます。

git worktreeとは？

git worktree は、1つのGitリポジトリから、複数のワーキングツリー（作業ディレクトリ）を同時に、かつ安全に作成・管理できる機能です。

「え、git cloneを複数回やるのと何が違うの？」と思うかもしれませんが、git worktreeは全く異なります。cloneがリポジトリ全体を複製するのに対し、 worktreeは.gitディレクトリ（リポジトリの本体）は一つだけ共有し、作業用のディレクトリだけを複数作成します。

これにより、ディスク容量を節約できるだけでなく、すべての作業が単一のリポジトリに紐づくため、管理が非常にシンプルになります。

基本的なコマンド

使い方はとても簡単です。主に使うコマンドは3つだけです。

1. add: 新しいワークツリーを作成します。
2. list: 現在のワークツリーの一覧を表示します。
3. remove: 不要になったワークツリーを削除します。

例: 新しいワークツリーを作成する

mainブランチで作業中に、hotfix/critical-bugという名前で緊急のバグ修正用ブランチを切り、hotfix-worktreeというディレクトリで作業したい場合、以下のコマンドを実行します。

# mainブランチを基点に新しいブランチを作成し、それをチェックアウトした状態でワークツリーを追加
# git fetch origin を実行して、リモートの最新状態を取得しておくとより安全です
git worktree add ../hotfix-worktree -b hotfix/critical-bug origin/main

これだけで、元のディレクトリの隣に hotfix-worktree という新しい作業ディレクトリが作成されます。あとはcd ../hotfix-worktreeで移動し、お好きなエディタで開くだけです。

重要: ホットフィックスのような本番環境への緊急修正では、必ず安定したブランチ（通常はorigin/mainやorigin/master）を基点として指定してください。省略すると現在作業中のブランチから新しいブランチが作成され、未完成の機能が含まれてしまう危険性があります。

git worktreeの制約

同じブランチを複数のワークツリーで同時にチェックアウトすることはできません。例えば、メインリポジトリでmainブランチをチェックアウトしている場合、別のワークツリーでもmainブランチを直接チェックアウトしようとするとエラーになります。

# メインリポジトリで main ブランチにいる状態
git worktree add ../another-main main
# エラー: fatal: 'main' is already used by worktree at '...'

この制約により、同じブランチで誤って競合する変更を加えてしまうことを防げます。別のワークツリーで同じ基点から作業したい場合は、必ず新しいブランチを作成してください（-bオプション）。

実践！git worktreeワークフロー

言葉だけでは分かりにくいので、具体的なシナリオを見ていきましょう。

シナリオ1: 機能開発中の緊急ホットフィックス

あなたは今、feature/awesome-funcブランチで新機能の開発に集中しています。

# 現在の状況
/path/to/my-project (feature/awesome-func) $

そこへ、本番環境で発生した緊急バグの修正依頼が舞い込んできました。ここでgit worktreeの出番です。

# 1. origin/mainを基点に'hotfix/fix-login-bug'ブランチを作成し、../hotfix-dir にワークツリーを作成
/path/to/my-project $ git worktree add ../hotfix-dir -b hotfix/fix-login-bug origin/main

# 2. 作成されたディレクトリに移動
/path/to/my-project $ cd ../hotfix-dir

# 3. ホットフィックス用のディレクトリにいることを確認
/path/to/hotfix-dir (hotfix/fix-login-bug) $

# 4. ここでバグ修正作業に集中...
# ...修正が完了し、コミット、プッシュ、PR作成
/path/to/hotfix-dir $ git commit -am "Fix: login bug"
/path/to/hotfix-dir $ git push origin hotfix/fix-login-bug

# 5. 元の作業ディレクトリに戻る
/path/to/hotfix-dir $ cd ../my-project

# 6. 何事もなかったかのように新機能開発を再開
/path/to/my-project (feature/awesome-func) $

どうでしょうか？ stashもcheckoutも一切使わずに、安全かつスムーズにコンテキストを切り替えられました。修正が終わったら、不要になったワークツリーは簡単に削除できます。

# 後片付け
# 1. 不要になったワークツリーを削除
/path/to/my-project $ git worktree remove ../hotfix-dir

# 2. PRがマージされた後、不要になったブランチを削除
/path/to/my-project $ git branch -d hotfix/fix-login-bug

シナリオ2: 複数ブランチの並行レビュー

チームメンバーから2つのプルリクエストのレビュー依頼が来ました。worktreeを使えば、これも簡単です。

# リモートのブランチ情報を最新化
git fetch origin

# PR-1用のワークツリーを作成（リモートブランチを直接指定）
git worktree add ../review/pr-1 origin/pr-branch-1

# PR-2用のワークツリーを作成
git worktree add ../review/pr-2 origin/pr-branch-2

これで、それぞれのPRを別のエディタウィンドウで開き、じっくり比較しながらレビューを進めることができます。

補足: リモートブランチを直接指定する方法（origin/pr-branch-1）では、各ワークツリーは「detached HEAD」状態になります。これは、特定のブランチ名の上ではなく、特定のコミット（この場合はorigin/pr-branch-1が指す最新コミット）を直接チェックアウトしている状態を指します。コードを読んで動作確認をするだけのレビュー用途では十分ですが、変更を加えてコミットしたい場合は、-bオプションで新しいブランチを作成することもできます。

# レビュー専用（detached HEAD、読み取り専用での確認）
git worktree add ../review/pr-1 origin/pr-branch-1

# 変更も加えたい場合（新しいブランチを作成）
git worktree add ../review/pr-1 -b review-pr-1 origin/pr-branch-1

git worktree x Claude Code = 開発体験の革命

さて、ここからが本題です。なぜgit worktreeが、ClaudeのようなAIアシスタントと驚くほど相性が良いのでしょうか？

その答えは 「コンテキストの物理的な分離」 にあります。

Claudeを使った開発は、特定のタスクについてAIと対話を続けるスタイルが基本です。しかし、複数のタスクを並行して進めようとすると、一つのチャット画面で話題が混ざってしまい、AIも自分も混乱してしまいます。

git worktreeは、この問題を完璧に解決します。

「並列AI駆動開発」の具体的なワークフロー

想像してみてください。あなたは今、2つのタスクを抱えています。

• タスクA: 新しいAPIエンドポイントの実装 (feature/new-api)
• タスクB: 既存モジュールのリファクタリング (feature/refactor-module)

git worktreeを使えば、以下のような未来的な開発フローが実現します。

1. ワークツリーの準備:

   # タスクA用のワークツリー（mainブランチから新しいブランチを作成）
   git worktree add ../task-A-api -b feature/new-api origin/main
   
   # タスクB用のワークツリー（mainブランチから新しいブランチを作成）
   git worktree add ../task-B-refactor -b feature/refactor-module origin/main
   

2. IDEとターミナルを分離:

   • VSCodeのウィンドウを2つ開きます。一つはtask-A-apiを、もう一つはtask-B-refactorを開きます。
   • それぞれのウィンドウで、統合ターミナルを開きます。

3. 並列AIセッションの開始:

   • ターミナルA (task-A-api):

     claude
     > 新しいAPIエンドポイントを設計してください。仕様は...
     

   • ターミナルB (task-B-refactor):

     claude
     > legacy-module.js をリファクタリングしたい。まずは現状のコードの問題点を洗い出して。
     

   注: claudeコマンドは、AIとの対話を模式的に表現した例です。実際のClaude Codeの起動方法は公式ドキュメントをご参照ください。

4. 待ち時間をゼロにする:

   • ターミナルAでClaudeがAPIのコードを生成している間、あなたはその応答を待つ必要はありません。
   • すぐにターミナルBのウィンドウに切り替え、リファクタリングに関する対話を進めます。
   • ターミナルBでAIの思考中に、ターミナルAでコード生成が終わっていれば、そちらに戻って実装の続きを行う...

このように、git worktreeによって物理的に分離された環境が、複数の独立したAIコンテキストを同時に維持することを可能にします。これにより、AIの応答待ちというデッドタイムを限りなくゼロに近づけ、開発者の思考の流れを止めることなく、複数のタスクをスムーズに並行処理できるのです。

まとめ

git worktreeは、単なる便利なGitコマンドではありません。それは、現代の複雑な開発要求と、AIアシスタントの登場によって変化する新しい開発スタイルに対応するための、必須のツールです。

• コンテキストスイッチのコストを劇的に削減
• 安全でクリーンな並列作業環境を提供
• ClaudeのようなAIアシスタントとの組み合わせで、生産性を飛躍的に向上させる

もしあなたがまだgit stashやcheckoutで消耗しているなら、ぜひこの記事をきっかけにgit worktreeを試してみてください。きっと、あなたの開発ライフはもっと快適で創造的なものになるはずです。

参考リンク

• Git公式ドキュメント: git-worktree
• git worktree が便利だし Claude Code と相性が良い話 (Zenn)
• 徹底解説：git worktree の使い方 (Qiita)
• Run parallel Claude Code sessions with Git worktrees

---

更新履歴

• 2025-11-02: 潜在的に危険なコマンド例を修正。コメントでの指摘（ @raynux 氏）を反映し、git worktree addコマンドでベースブランチ（origin/main）を明示的に指定するように全例を修正。