はじめに
最近CodexやClaude CodeなどのAIエージェントを使って開発することが増えてきました。
AIエージェント単体でもかなり便利ですが、最近は、
- Codexに機能Aを作らせる
- Claude Codeに機能Bを作らせる
- 別のAIエージェントにテストを書かせる
といった形で、複数のAIエージェントを同時に動かして開発することもできます。
そこでふと思いました。
同じリポジトリに対して複数のAIエージェントを動かして、コンフリクトしないのか？
同じファイルを同時に触れば、普通に壊れそうです。
さらに片方がブランチを切り替えたら、もう片方はどうなるのかも気になります。
AIエージェントが実際にどう動いているのか見てみると、git worktreeを使って作業場所を分けていました。
git worktree自体は普段から使っていました。
例えば、今の作業を残したまま別ブランチを確認したいときに、
git worktree add ../my-app-check feature/check
のように使います。
一覧を見るなら、
git worktree list
です。
ただ、自分一人で開発していると、worktreeをいくつ作っても自分は一人です。
自分 → worktree A
自分 → worktree B
自分 → worktree C
当然、本当の意味で同時に3つの開発を進められるわけではありません。
そのため自分の中では、
「ブランチを切り替えずに別の作業場所を持てる便利機能」
くらいの認識でした。
でもAIエージェントなら違います。
自分
│
├── Codex → worktree A
├── Claude Code → worktree B
└── Codex → worktree C
これなら本当に同時に作業できます。
ここで初めて、
worktreeはAIエージェントの並列開発とかなり相性がいい
と気づきました。
知っていたGitの機能なのに、AIエージェントによって別の使い方に気づかされたのが今回の学びでした。
今回は、複数のAIエージェントが同じリポジトリに対してどうやって並列で開発しているのかを、git worktreeを使った例で簡単に見ていきます。
同じディレクトリで複数のAIエージェントを動かすと危ない
まず普通のGitリポジトリを考えます。
my-app/
├── .git/
├── src/
├── package.json
└── README.md
現在mainブランチにいるとして、ログイン機能を実装するためにブランチを作ります。
git switch -c feature/login
ここでCodexを起動します。
codex
例えば、
ログイン画面を実装してください
とお願いする。
ここまでは普通です。
ではCodexが作っている間に、Claude Codeにもプロフィール画面を作ってもらう場合はどうでしょう。
my-app/
↑
Codex
Claude Code
同じディレクトリで2つのAIエージェントが動くことになります。
さらにClaude Code用に別ブランチを作ろうとして、
git switch -c feature/profile
とすると、この作業ディレクトリ自体がfeature/profileに切り替わります。
Codexからすると、
feature/login
で作業していたはずなのに、突然、
feature/profile
に変わります。
これでは安全に並列作業できません。
AIエージェントごとにworktreeを分ける
例えば、
Codex
→ ログイン機能
Claude Code
→ プロフィール機能
を同時に作らせたいとします。
手動でやるなら、次のようにworktreeを分けます。
git worktree add ../work-login -b feature/login
git worktree add ../work-profile -b feature/profile
すると、
my-app/
└── main
work-login/
└── feature/login
work-profile/
└── feature/profile
という状態になります。
Codexは、
cd ../work-login
codex
Claude Codeは、
cd ../work-profile
claude
で動かします。
すると、
Codex
↓
work-login/src/app.ts
Claude Code
↓
work-profile/src/app.ts
となります。
同じリポジトリに対して作業していても、実際に触っている作業ディレクトリは別です。
そのため、Codexがファイルを保存してもClaude Code側のファイルが直接書き換わることはありません。
AI同士で同じファイルをうまく調整しているというより、
最初から別々の作業場所を与えている
という方が実態に近いです。
じゃあコンフリクトしないのか？
worktreeを分けていても、最後に同じ箇所を変更していれば普通にコンフリクトします。
例えば、
work-login/src/app.ts
work-profile/src/app.ts
をそれぞれ変更してcommitしたあと、
git merge feature/login
git merge feature/profile
と統合したとします。
同じ行を変更していれば、
<<<<<<< HEAD
Codexの変更
=======
Claude Codeの変更
>>>>>>> feature/profile
となります。
なのでworktreeは、
コンフリクトをなくす仕組み
ではありません。
どちらかというと、
AIエージェントが作業中にお互いの変更を直接踏まないようにする仕組み
です。
作業中
↓
worktreeで分離
↓
直接ぶつからない
統合時
↓
同じ箇所を変更していれば
↓
コンフリクトする
ここは人間のチーム開発と同じです。
タスクの分け方も重要
AIエージェントを複数起動すれば何でも速くなるわけではありません。
例えば、
Codex
→ Userモデルを全面変更
Claude Code
→ Userモデルを使うAPIを全面変更
のような依存の強い作業は、最後の統合が大変になりやすいです。
一方で、
Codex
→ ログイン画面
Claude Code
→ プロフィール画面
別のAI
→ テスト追加
くらい分かれていれば、並列化しやすくなります。
結局ここも人間のチーム開発と同じで、
仕事の切り分け方が大事
というところに戻ってきます。
AIの動きを見ていると意外と学びがある
今回面白かったのは、git worktree自体を初めて知ったわけではないところです。
普段から使っていました。
ただ、一人で開発していると、
worktree A
worktree B
worktree C
といくら作っても、実際にコードを書く自分は一人です。
なので複数のworktreeを、
本当に同時並行で動かす
という使い方をあまり意識していませんでした。
それがAIエージェントだと、
worktree A → Codexが作業中
worktree B → Claude Codeが作業中
worktree C → 別のAIが作業中
という状態を普通に作れます。
知っていたはずの機能なのに、
使う主体が人間からAIに変わっただけで用途が広がった
というのが今回一番の学びでした。
AIエージェントを使っていると、
依頼する
↓
完成する
だけで終わらせることもできます。
それでも十分便利です。
ただ、たまに、
「今何をやっているんだろう？」
と実行しているコマンドやGit操作を見てみると、
「その使い方は思いつかなかった」
という発見があります。
今回のworktreeもまさにそれでした。
AIに新しい技術を教えてもらったというより、
AIが作業しているところを見て、知っていた技術の新しい使い方に気づいた
という感覚です。
まとめ
最初は、
同じリポジトリに対してCodexやClaude Codeを同時に動かして、本当に大丈夫なのか？
と思っていました。
実際に見てみると、
同じGit Repository
│
├── worktree A → Codex
├── worktree B → Claude Code
└── worktree C → AIエージェント
という形で作業場所を分けていました。
リポジトリは同じ。
でも実際に編集しているディレクトリは別。
なので作業中にお互いのファイルを直接上書きしません。
最後にGitで統合するとき、同じ箇所を変更していれば普通にコンフリクトします。
git worktree自体は昔からある機能ですが、AIエージェントによって使い方の意味が少し変わったように感じました。
自分一人では本当の意味で並列に動かせなかった複数のworktreeを、AIエージェントなら実際に同時並行で動かせます。
昔から知っている技術でも、AIによって使い方が変わる。
AIに全部任せるのも便利ですが、たまにはAIが何をしているのか見てみると、ひょんなところから新しい発見があって面白いです。