複数の AI Agent でローカル開発を並列化する
今日の到達点は、2 つの小さい修正を別 worktree で同時に進めること。 並列化するのは差分作成だけに絞る。
AI Agent を 1 つの作業では使っているが、複数 Agent をローカルで並べたことはないエンジニア向けの発表資料。 Git の branch / commit、ローカル起動、unit test または E2E の基本は分かっている前提にする。
2 つの小さい修正を別 branch / 別 worktree で同時に進める。並列化するのは差分作成まで。 共有リソースを触る工程は混ぜず、branch / worktree / URL / 検証結果 / cleanup 対象の対応を確認しながら作業ごとに進める。
1. なぜ AI Agent の並列開発が必要になるか
AI Agent を 1 つだけ使う段階では、人間は Agent の完了を待つ時間が長くなる。 独立した小さい作業が複数あるなら、Agent を並べることで待ち時間を減らせる。
ただし、並列化で難しくなるのはコードを書くことではなく、作業、branch、worktree、URL、検証結果、cleanup 対象の対応関係を失わないこと。 最初は「差分作成だけ」を並列化し、共有リソースを触る工程は直列にする。
2. 並列化のレベル
Level は「高度なツールを使う度合い」ではない。 同時に使うリソースをどこまで分けるかの段階である。
git worktree は、同じ repository に紐づく別の作業ディレクトリを作る機能。 Agent A / B のファイル差分を混ぜずに進めるために使う。詳しい境界は 4. worktree で分かれるもの、分かれないもの で見る。
3. 最初は Level 1: 差分作成だけを並列化する
ここからは Level 1 を具体的に見る。 Agent session を 2 つ開くだけでは不十分。branch / worktree を分ける。
検証、PR、cleanup は作業ごとに対応関係を確認しながら直列で進める。
作業前に人間が pwd、git branch --show-current、git status --short を確認する。
この例では、通常の作業ディレクトリを $HOME/src/myapp、Agent 用 worktree を $HOME/worktrees/myapp/* に置く。
worktree 作成コマンドは、通常の作業ディレクトリ側で実行する。
cd "$HOME/src/myapp"
git fetch origin main
git worktree add "$HOME/worktrees/myapp/issue-101" -b agent/issue-101 origin/main
git worktree add "$HOME/worktrees/myapp/issue-102" -b agent/issue-102 origin/maincd "$HOME/worktrees/myapp/issue-101"
pwd
git branch --show-current
git status --short
worktree を作ったら、worktree ごとに terminal または Agent session を開く。
Agent A は $HOME/worktrees/myapp/issue-101 をカレントディレクトリにして作業 A だけを依頼し、Agent B は $HOME/worktrees/myapp/issue-102 を起点に作業 B だけを依頼する。
どちらの Agent にも、担当 worktree の外を触らせない。
人間は「何を並べるか」「どの作業から検証し、どの PR を先に進めるか」を持つ。 作業前に確認するのは、対象作業、作業ディレクトリ、branch、worktree、共有リソースの対応関係。
test、E2E、PR draft 作成、cleanup 候補の列挙は Agent に任せてもよいが、初回は作業ごとに一件ずつ進める。 複数 Agent に共有 URL / DB / cleanup 対象を同時に触らせない。
4. worktree で分かれるもの、分かれないもの
worktree を分けると、作業ディレクトリ、branch、ファイル差分は分かれる。 ただし、process、port、URL、DB / schema、cache / queue、artifact（検証成果物）、cleanup 対象は、worktree だけでは分かれない。
Level 1 では、worktree で分からないものを同時に使わないことで始める。 同時に使う必要が出たものだけ Level 2 以降で分ける。
5. Level 1 から先へ進む判断
Level 1 を回せるようになったら、待ち時間や衝突が出たところだけ分離を増やす。 migration、大きな refactor、同じファイルを触る修正は、初回 2 並列には向かない。
| 起きていること | 次に分けるもの | 進む Level |
|---|---|---|
| 起動の順番待ちが増えた | process / port / URL | Level 2 |
| test / E2E の順番待ちや状態汚染が出た | DB / schema / cache / queue / artifact | Level 3 |
| cleanup で他作業を壊しそうになった | cleanup 対象と所有者を人間が確認する。自動 cleanup は急がない | 並列数を増やさない |
詳しい判断表は 導入レベルと判断表 で扱う。
6. 最初の 2 並列の成功条件
成功は「2 つを同時に完全自動化できた」ことではない。 初回は、人間が作業の対応関係を失わず、2 つの PR を安全に前へ進められればよい。
- Agent A と Agent B が別 branch / 別 worktree で差分作成した。
- 各 Agent の差分が対象作業の範囲に収まっている。
- 検証した URL / branch / worktree の対応を説明できる。
- 共有リソースを触る工程を混ぜずに進めた。
- 削除してよい process / container / worktree を説明できる。
PR の conflict、required checks、CI は通常の開発と同じように確認する。
7. 停止条件
状態が分からないまま進めない。 次のどれかに当たったら、いったん手を止め、並列数を増やさない。
- Agent が別 worktree を変更しようとした。
- 検証対象 URL が今確認している branch と対応しているか分からない。
- 本番環境、共有 DB、共有 cache へ接続しそうになった。
- seed、migration、更新系 E2E の状態が次の作業へ残るか判断できない。
- cleanup 対象の process、container、volume がどの作業のものか分からない。
task、作業ディレクトリ、branch、URL、DB、cleanup 対象を対応付ける。 対応できないものは、検証環境を既知状態に戻すか、対象作業を止めて人間が確認する。 原因が分からないまま PR、merge、cleanup へ進まない。
8. ツール / ダッシュボードは何を助けるか
複数 Agent をローカルで並べると、人間は複数の session、terminal、worktree、URL、diff、検証結果、cleanup 対象を見る必要がある。 dashboard / workspace 管理ツールは、この状態把握を助ける。
ただし、ツールを入れても、プロジェクト固有の DB / cache / queue / E2E / artifact / cleanup ownership は残ることがある。 ツールは「どの問題を助けるか」で分類して見る。
| 観点 | ツールが助けること | プロジェクト側に残ること |
|---|---|---|
| workspace / worktree 管理 | branch / worktree 作成、session 管理、terminal 管理 | どの作業を並べるか、merge 順序 |
| 起動・URL 管理 | port 表示、URL 管理、setup / teardown hook | DB / cache / queue / E2E の分離設計 |
| Agent / PR workflow | diff、PR draft 作成、通知、状態一覧 | 検証結果の信頼性、cleanup 所有権、停止条件 |
具体的な製品名や代表例は ツールが担う範囲とプロジェクト側に残る範囲 で扱う。
9. 補足ページを選ぶ
本編だけで、最初の 2 並列は始められる。 補足ページは必要なものだけ読む。