git worktree を使いこなして、AI コーディングエージェントの同時並行開発を実現する

OpenAI Codex に GPT-5-Codex が登場してから、ローカル環境で動かせる AI コーディングエージェントが、業務でも普通に使えるレベルに到達したと感じている。最近では、実装は自分で一から書くのではなく、コーディングエージェントに任せて、最後の手直しだけを自分でやることが多い。

ローカル環境でのコーディングエージェントの活用が業務の中心になってくると、ひとつ気になる制約が見えてくる。「ある Git リポジトリをコーディングエージェントが編集しているあいだに、そのリポジトリを同時に編集しづらい」という問題だ。

具体的には、次のようなことをやりたくなる。

  • 同じ Git リポジトリに対して、複数のコーディングエージェントを同時に動かしたい
    • チケット A とチケット B の開発を同時に進める
    • Codex と Claude Code に同じチケットの開発を依頼して、アウトプットの品質が良い方を採用する
  • 同じリモートブランチに対して、コーディングエージェントと人間で同時に開発したい

しかし Git では、ひとつの作業ディレクトリにつき同時にチェックアウトできるブランチは 1 つだけだ。普通に開発ブランチを切って作業している場合、そのリポジトリをコーディングエージェントが編集しているあいだに、同時に編集しようとすると、差分が混ざってしまい、訳のわからない状態になってしまう。

こういった問題を解決する存在として、2015 年にリリースされた Git 2.5 で導入された git worktree の機能が、コーディングエージェントを用いた複数同時開発の文脈で、改めて注目されている。

git worktree は、ひとつのリポジトリに対して複数の作業ディレクトリ(worktree)を作成できる機能だ。作業ディレクトリごとに別々のブランチをチェックアウトしておけば、それぞれの作業ディレクトリで、他の作業ディレクトリの編集内容に影響されることなく開発を進めることができる。

Claude Code のドキュメントでも、git worktree を使った並行開発の手法が紹介されている。

仕組みだけを見ると、「作業ディレクトリを増やして、それぞれでコーディングエージェントを動かすだけ」の簡単な話に見える。手元の開発環境で早速やってみようとなったのだが、実際に試してみると、いくつかハマりどころがあった。

試行錯誤の結果、快適に複数同時開発を回せる開発環境が整ったので、git worktree の使い方の一例として紹介したい。

この記事では、git worktree で作成されるディレクトリのことを「作業ディレクトリ」(worktreeに相当)と呼ぶ。

git worktree を初めて使ったときに困ったポイント

初めて git worktree の機能を試したときに、次のような部分が期待通りに動かなくて困った。

  • 作業ディレクトリの新規作成からコーディングエージェントに依頼すると、コーディングエージェントは作成した作業ディレクトリに移動して作業できない
    • コーディングエージェントに「起動時のカレントディレクトリ配下だけ編集可能」という制約がある場合に、それ以外のディレクトリに移動して編集することができない
  • .gitignore で指定された .env など、開発環境の動作に必要なファイルが、作成した作業ディレクトリ側には存在しない

今振り返ると、これらの問題は作業ディレクトリの新規作成からコーディングエージェントに任せようとしたことが原因だったと思う。作業ディレクトリの作成や .env の準備といった環境づくりは、自分の手で整えるのが良さそうだ。

とはいえ、開発チケットごとに毎回手作業が発生するのは面倒だ。そこで、私は「複数のチケット開発に使い回せる作業ディレクトリ」を作っておき、そこでコーディングエージェントに開発を依頼する運用にしている。以下、その作成手順を紹介したい。

コーディングエージェントを動かすための作業ディレクトリの作成手順

前提情報

Git リポジトリのデフォルトの作業ディレクトリを「人間が開発するための作業ディレクトリ」として扱い、コーディングエージェント用に新しい作業ディレクトリを追加で作成する、という想定での手順を紹介する。

以下はサンプルとして使う名称なので、実際の環境での名称に適宜置き換えてほしい。

作業ディレクトリの作成

まず、コーディングエージェント用の作業ディレクトリを git worktree で作成する。

git worktree add ../myapp-ai -b main-ai origin/main

このコマンドは、次の 2 つを同時に行っている。

  • ../myapp-ai という作業ディレクトリ(worktree)を新規に作成する
  • リモートのデフォルトブランチ(origin/main)をトラッキングする main-ai というローカルブランチを作成し、その作業ディレクトリでチェックアウトする

Git では、同じブランチを複数の作業ディレクトリで同時にチェックアウトすることはできない。そのため、デフォルトブランチと同じ名前のブランチ(main)をそのまま複数の作業ディレクトリで共有することはできないので、main-ai のように、「デフォルトブランチをトラッキングするブランチ」を作業ディレクトリごとに用意する構成にしている。

作業ディレクトリごとに「デフォルトブランチをトラッキングするブランチ」を用意しておくと、どの作業ディレクトリでも同じように、

  • デフォルトブランチ相当のブランチで git pull して最新の実装内容を同期する
  • そこから新しく開発ブランチを切って作業を始める

という開発サイクルを回せるようになる。

.gitignore されている開発環境用のファイルを整える

次に、作成した作業ディレクトリ側に、開発環境で必要なファイルを用意する。

具体的には、.env のように .gitignore で ignore されていて、かつ開発環境の動作に必要なファイルは、コーディングエージェント用の作業ディレクトリにも配置しておく必要がある。

作成した作業ディレクトリでコーディングエージェントに開発依頼する

ここまで準備できたら、myapp-ai 側をコーディングエージェント用の作業ディレクトリとして使えるようになる。

  • 人間は従来どおり myapp 側で開発する
  • コーディングエージェントは myapp-ai 側で動かす

という分担にしておくと、お互いの作業が干渉しにくくなる。

同じ手順で作業ディレクトリを増やしていけば、コーディングエージェントを 2 つ 3 つと同時に動かせるようになる。

人間とコーディングエージェントで同じリモートブランチを参照する方法

コーディングエージェントが feature/example-function というリモートブランチを作成して push したとする。このブランチを、エージェントに編集してもらいつつ、人間もローカルで編集したい、という場面がある。

その場合は、次のようにして「同じリモートブランチをトラッキングする別名のローカルブランチ」を作成すると、運用がやりやすい。

git switch -c feature/example-function-human origin/feature/example-function

このように、リモートブランチをトラッキングするローカルブランチを人間用に別名で作成しておくと、

  • リモート側では 1 本のブランチ( feature/example-function
  • 手元では、エージェント用と人間用で別々のローカルブランチ

という構成にできる。これによって、人間とコーディングエージェントで同時に同じリモートブランチに対して編集することが可能になる。

Docker Composeによる開発環境構築で困ったポイントと解決策

Docker Compose を使って開発環境を構築している場合に、worktree ごとに別プロジェクト扱いになる、という問題にもぶつかった。

Docker Compose は、デフォルトでは「ディレクトリ名」をもとにプロジェクト名を決める。そのため、 myappmyapp-ai のようにディレクトリ名が異なると、

  • コンテナ名
  • ネットワーク名
  • ボリューム名

などがそれぞれ別々に作成されてしまう。

この仕様によって、

  • 複数の作業ディレクトリで同じポートを使おうとしてエラーになる
  • 作業ディレクトリごとに Docker リソースがどんどん増えていって整理しづらくなる

といった問題が発生した。

この問題については、COMPOSE_PROJECT_NAME環境変数.env に追加することで解決できた。

COMPOSE_PROJECT_NAME=myapp

また、コマンド実行時に -p--project-name ) オプションで明示的にプロジェクト名を指定することもできる。

docker compose -p myapp run --rm app bin/rspec

こうしてプロジェクト名を固定しておくと、複数の作業ディレクトリから、同じ Docker コンテナを共有できるようになり、Docker Composeによるコマンド実行が複数同時開発時にも支障なく動作するようになった。

VSCode での git worktree のサポート

VSCode では、git worktree の機能が公式にサポートされている。独立したリポジトリを扱うような感覚で、それぞれの作業ディレクトリを別々の VSCode ウィンドウで開くことができて便利だ。

おわりに

この記事に書いた手順で、ローカル環境でのコーディングエージェントによる同時並行開発を、快適に回せるようになった。git worktree は慣れるまでに挙動が非直感的に感じられる部分もあるが、一度コツを掴んでしまえば、AI 時代の開発に必須のテクニックという印象がある。

最近はモニターを 1 枚新たに買い足して、複数のコーディングエージェントがそれぞれの作業ディレクトリで頑張って開発している様子を小脇に眺められるようにしている。仕事の風景は、ほんの半年前と比べてもすっかり様変わりしていて、時代の急速な変化を日々感じているところだ。