Select a result to preview

Claude CodeとGit Worktreeによる並列開発

#ClaudeCode #Git #並列開発 #ワークフロー #自動化

Claude CodeとGit Worktreeを組み合わせると、複数のタスクを並列で進められる。本記事では、なぜこの組み合わせが強力なのか、どのようなユースケースで活用できるか、そして実践的な自動化レシピを紹介する。

なぜGit WorktreeとClaude Codeの組み合わせが強力なのか

コンテキスト切り替えのコスト

人間にとってもAIエージェントにとっても、コンテキスト切り替えは高コストな操作である。

人間の場合、別のタスクに切り替えると「いまどこまで考えていたか」を思い出すのに時間がかかる。これは認知負荷の問題であり、ワーキングメモリの限界に起因する。

Claude Codeにとっても同様の問題がある。ブランチを切り替えると、それまでの会話で築いた「このコードベースの構造」「いま取り組んでいるタスクの背景」といった文脈が薄れていく。コンテキストウィンドウは有限であり、新しい情報が入るたびに古い情報は押し出されていく。

AIエージェントにとっての「記憶」

Claude Codeの強みは、対話を通じてコードベースへの理解を深めていく点にある。

セッション開始時:
  「このプロジェクトは何？」から始まる

30分後:
  「src/auth/の認証フローはOAuth2ベースで、
   トークン管理はredis-sessionを使っている」
  という理解が蓄積されている

この蓄積された理解は、そのセッションの「記憶」である。ブランチを切り替えて別の作業をすると、この記憶は上書きされていく。

Git Worktreeを使えば、各タスクに専用のClaude Codeセッションを割り当てられる。認証システムのリファクタリングを担当するClaude Aは認証コードに詳しくなり、ダッシュボード機能を担当するClaude Bはフロントエンドに詳しくなる。それぞれが専門性を持った状態で作業を続けられる。

タスク独立性の評価

ただし、すべてのタスクを並列化できるわけではない。並列化に適したタスクには条件がある。

並列化に適したタスク：

並列化に向かないタスク：

並列化の判断に迷ったら、Claude Code自身に聞いてみるのも手である。「この2つのタスクを並列で進めたいのだが、コンフリクトのリスクはどの程度か？」と質問すれば、コードベースを踏まえた評価を返してくれる。

ユースケース別パターン

パターン1：機能開発の並列化

最も基本的なパターン。3〜5つの独立した機能を同時に開発する。

# 3つの独立機能を並列開発
git worktree add ../project-auth -b feature/auth-refactor
git worktree add ../project-dashboard -b feature/new-dashboard
git worktree add ../project-api -b feature/api-v2

# それぞれ別ターミナルでClaude Codeを起動
# Terminal 1
cd ../project-auth && claude

# Terminal 2
cd ../project-dashboard && claude

# Terminal 3
cd ../project-api && claude

各セッションには「あなたは認証システムのリファクタリングを担当している」のように、明確な役割を最初に伝えておくとよい。Plan Modeを使えば、勝手にコードを変更される心配なく、複数のセッションを放置できる。

パターン2：本線開発 + ホットフィックス

開発中に緊急のバグ修正が入ったケース。従来なら git stash して緊急対応し、戻ってきたら git stash pop して「どこまでやったっけ...」となる。

# 通常開発中に緊急バグ報告
git worktree add ../project-hotfix -b hotfix/urgent-bug

# 別ターミナルでホットフィックス対応
cd ../project-hotfix && claude
# → 「本番で決済エラーが発生している。原因を調査して修正してほしい」

# 元のターミナルでは開発を継続できる

ホットフィックスが完了してマージされたら、元の開発ブランチで git merge main すればよい。

パターン3：PRレビュー待ち + 次タスク

PRを出して、レビュー待ちの間に次のタスクに着手するパターン。

# feature-a のPRを出した
# レビュー待ちの間に次のタスクへ

git worktree add ../project-feature-b -b feature/next-feature
cd ../project-feature-b && claude

レビューでコメントが来たら、元のworktreeに戻って対応する。各worktreeのClaude Codeセッションはそれぞれのタスクの文脈を保持しているので、切り替えてもスムーズに再開できる。

パターン4：探索的リファクタリング

「このアーキテクチャを変えたらどうなるか試してみたい」という実験的な作業。本番ブランチに影響を与えずに試行錯誤できる。

git worktree add ../project-experiment -b experiment/new-architecture
cd ../project-experiment && claude
# → 「このモジュールをClean Architectureに書き換えてみたい。
#    まず影響範囲を調査して、段階的に進めてほしい」

実験がうまくいけばマージし、ダメならworktreeごと削除する。メインの開発を止めずに「試してみる」ことができるのは心理的にも楽である。

自動化のレシピ

基本のシェル関数

毎回 git worktree add を打つのは面倒なので、シェル関数を用意しておくと便利である。

# ~/.zshrc または ~/.bashrc に追加

# worktreeを作成してClaude Codeを起動
function ccw() {
    local branch=$1
    local worktree_dir="../$(basename $(pwd))-${branch}"

    # ブランチが存在しなければ作成
    if ! git rev-parse --verify "$branch" &>/dev/null; then
        git worktree add "$worktree_dir" -b "$branch"
    else
        git worktree add "$worktree_dir" "$branch"
    fi

    # .envがあればコピー
    if [ -f ".env" ]; then
        cp .env "$worktree_dir/.env"
    fi

    # 移動してClaude Code起動
    cd "$worktree_dir" && claude
}

# worktree一覧を見やすく表示
function wtls() {
    git worktree list --porcelain | grep '^worktree' | sed 's/worktree //'
}

# worktreeを削除（ブランチも削除）
function wtrm() {
    local worktree_path=$1
    git worktree remove "$worktree_path"
    # ブランチ名を推測して削除（オプション）
    local branch=$(basename "$worktree_path" | sed "s/^$(basename $(pwd))-//")
    git branch -d "$branch" 2>/dev/null
}

使い方：

# feature/new-loginブランチでworktreeを作成し、Claude Codeを起動
ccw feature/new-login

# 作成済みのworktree一覧
wtls

# worktreeとブランチを削除
wtrm ../project-feature/new-login

git-worktree-runner (gtr) の活用

より本格的な自動化には、git-worktree-runnerが便利である。CodeRabbitが開発したツールで、エディタやAIツールとの連携が組み込まれている。

# インストール
git clone https://github.com/coderabbitai/git-worktree-runner.git
cd git-worktree-runner && ./install.sh

# Claude Codeをデフォルトに設定
git gtr config set gtr.ai.default claude

# 基本的な使い方
git gtr new my-feature           # worktree作成
git gtr ai my-feature            # Claude Code起動
git gtr editor my-feature        # エディタで開く
git gtr rm my-feature            # 削除

gtrの便利な点：

tmux/iTerm2との連携

複数のworktreeセッションを管理するには、ターミナルマルチプレクサが役立つ。

iTerm2の場合：

tmuxの場合：

# tmuxセッション作成スクリプト
function tmux-worktrees() {
    local session_name="dev"

    tmux new-session -d -s $session_name -c ../project-main
    tmux send-keys -t $session_name "claude" Enter

    tmux new-window -t $session_name -c ../project-feature-a
    tmux send-keys -t $session_name "claude" Enter

    tmux new-window -t $session_name -c ../project-feature-b
    tmux send-keys -t $session_name "claude" Enter

    tmux attach -t $session_name
}

tmuxの利点は、SSHで作業している場合でも接続が切れてもセッションが維持される点である。長時間実行されるタスクを放置しておける。

クリーンアップの自動化

worktreeは放っておくと増えていく。定期的なクリーンアップが必要である。

# 週次でworktreeをクリーンアップするスクリプト
function wt-cleanup() {
    echo "=== Current worktrees ==="
    git worktree list

    echo ""
    echo "=== Pruning stale worktrees ==="
    git worktree prune -v

    echo ""
    echo "=== Merged branches that can be deleted ==="
    git branch --merged main | grep -v '^\*\|main\|master'
}

注意点とトレードオフ

リソース消費

複数のClaude Codeセッションを同時に実行すると、それなりのリソースを消費する。

私の感覚では、3〜4セッションが実用的な上限だと思う。それ以上増やしても、人間側の監視が追いつかなくなる。

設計判断はAIに任せられない

incident.ioのブログで「大規模な建築的決定には依存できない」と述べられていたが、これは重要な指摘である。

Claude Codeが得意なのは、方向性が決まった後の実装作業である。「認証をJWTからセッションベースに変える」と決めたら、その実装は任せられる。しかし「認証方式をどうすべきか」という設計判断は、人間が行うべきである。

並列開発を行う際も、タスクの分割と各タスクの方向性は人間が決め、実装をClaude Codeに委譲するという分担が有効だと考えている。

マージコンフリクトのリスク

独立したタスクを選んでいても、思わぬところでコンフリクトが発生することはある。

リスクを減らすプラクティス：

コンフリクトが発生した場合、Claude Codeに解決を依頼することもできる。「mainブランチとのコンフリクトを解消して。我々の変更を優先で」のように指示すればよい。

まとめ

Git WorktreeとClaude Codeの組み合わせは、並列開発を実現するための強力なパターンである。

基本的な考え方：

実践のポイント：

この手法は、要件が明確で方向性が決まったタスクに特に有効である。探索的な作業や設計フェーズには向かない。適切な場面で使えば、開発速度を大きく向上させることができる。

参考

関連ノート

抽出された概念

この記事の主要概念は既存のnotes/ノートに収録済み：