プロダクト
複数のAIコーディングエージェントを並列で動かす方法｜ADE入門
複数のAIコーディングエージェントを並列で動かす方法を解説します。エージェント開発環境（ADE）とは何か、git worktreeによる分離、タスクの分け方、コンフリクトの防ぎ方、進捗を可視化するオブザーバビリティ、そして人間によるコードレビューまで、実践的な手順をわかりやすくまとめました。
この記事の内容
エージェント開発環境（ADE：Agent Development Environment）とは、複数のAIコーディングエージェントを並列で動かすためのワークスペースです。各エージェントには個別のタスク、コードの分離されたコピー、ひと目でわかるステータスが割り当てられ、人間は作業の分割、進捗の監視、そしてマージ前のすべての変更のレビューを担います。
この記事のポイント
- AIエージェントの並列実行が成果につながるのは、タスクが互いに独立していて、範囲が狭く、検証できる場合に限られます。
- まずは分離から。エージェントごとに専用のgit worktreeとブランチを用意します。
- オブザーバビリティ（可観測性）はADEの中核機能です。どのエージェントが作業中か、待機中か、行き詰まっているか、完了したかをひと目で把握できるようにします。
- ボトルネックになるのはコード生成ではなくレビューです。動かすエージェントの数は、レビューしきれる範囲にとどめましょう。
- すべてのマージの責任は人間にあります。差分（diff）を自分で読み、チェックも自分で実行してください。
AIコーディングエージェントとは？
AIコーディングエージェントとは、入力中にコードを提案するだけでなく、指示されたタスクを完了するためにリポジトリを読み、ファイルを編集し、コマンドやテストを実行できる、AIモデル駆動のツールです。代表的なものに、Claude Code、Codex CLI、Gemini CLIといったターミナル型のエージェント、コードエディタに搭載されたエージェントモード、クラウドのサンドボックスで作業してプルリクエストを返すホスト型のエージェントがあります。
エージェント開発環境（ADE）とは？
従来のIDEは、1人の開発者が1つの作業コピーを編集することを前提につくられており、最近では独自のエージェント機能を追加するエディタも増えています。しかし複数のエージェントが動き始めると、1日の仕事の中心は編集ではなく調整（コーディネーション）に移ります。この用語は「agentic development environment」と表記されることもあり、AIエージェントを開発するためのツールではなく、AIコーディングエージェントと一緒にソフトウェアを開発する場所を指します。
ADEはエディタやエージェントを置き換えるものではありません。それらの上に位置するオーケストレーション層として、エージェントが1つ増えるごとに膨らんでいく次のような作業を引き受けます。
- ワークスペースの分離：エージェントごとに作業ディレクトリとブランチを分け、手作業でのgit管理を不要にします。
- タスク管理：各エージェントに渡した指示（ブリーフ）をいつでも確認できます。
- ライブステータス：どのエージェントが実行中か、入力待ちか、完了したか、失敗したかがわかります。
- レビュー画面：各エージェントの差分、実行したコマンド、テスト結果を1か所で確認できます。
- 統合：各エージェントのブランチをメインラインへ戻すための、管理された経路を用意します。
なぜ複数のAIコーディングエージェントを並列で動かすのか？
ある程度複雑なタスクに取り組むエージェントは、読み込み、編集、テスト、修正を繰り返しながら、一度に数分間動き続けることがよくあります。1つずつ見守っていると、その時間のほとんどは待ち時間になります。エージェントを並列で動かせば、待ち時間がそのままスループットに変わります。1つ目のエージェントがリファクタリングをしている間に、2つ目が別のモジュールのテストを書き、3つ目がバグ報告を調査する、といった具合です。
実際には、並列作業のほとんどは次の3つのパターンに当てはまります。
- ファンアウト：同じバックログから独立したタスクをいくつか取り出し、1タスクにつき1つのエージェントを割り当てて、それぞれ個別にマージします。
- コンペ方式：正解がはっきりしない問題では、同じタスクを2つのエージェントに渡すか、指示を変えて2回実行し、良いほうの結果を採用します。
- パイプライン：1つのエージェントが実装し、2つ目がその結果をレビューするかテストを書き、最終判断は人間が下します。
AIコーディングエージェントを並列実行する構成にはどんなものがある？
多くのチームは次の4つの構成のいずれかを使っており、組み合わせているケースも少なくありません。
- ターミナルのタブやtmuxのペインで、エージェントごとに1つのgit worktreeを使う：新しいツールは不要ですが、各エージェントの状態はすべて自分で追う必要があります。
- エディタに組み込まれたマルチエージェント機能：チーム全員がすでに同じエディタで作業しているなら便利です。
- ホスト型のサンドボックスで動き、プルリクエストを返すクラウド／バックグラウンドエージェント：ローカルでは何も動かさず、届いたPRをレビューします。
- 専用のエージェント開発環境：すべてのエージェントのステータス、差分、レビューを1か所で扱えます。
並列のAIコーディングエージェントに向いているタスクは？
候補となるタスクは、次の4つの問いで見極めましょう。実行中のほかのタスクから独立しているか。短いブリーフで説明できるか。テスト、型チェック、ビルド、あるいは受け入れ基準で検証できるか。コードベースのほかとは別の部分を触るものか。
向いているタスク
- テストカバレッジが不足しているモジュールへのテスト追加。
- 再現手順が明確で、影響範囲が閉じたバグ修正。
- 新しいAPIエンドポイントやUIコンポーネントのように、明確に定義されたインターフェースの内側で完結する機能。
- ディレクトリやパッケージ単位できれいに分割できる機械的な移行作業。
- ほかに誰も編集していない領域での、ドキュメント整備、型の改善、Lintエラーの修正。
向いていないタスク
- 共有の型やデータモデルに波及するアーキテクチャ変更。
- 完了の定義が好みの問題になってしまうタスク。
- ルーター、スキーマ、依存関係のマニフェストなど、同じ中心的なファイルをどちらも変更する必要がある2つのタスク。
- まだ終わっていない別のタスクの成果物に依存する作業。
複数のAIコーディングエージェントを動かす手順（ステップバイステップ）
- 作業を独立したタスクに分解する。
- エージェントごとに専用のgit worktreeとブランチで分離する。
- 各エージェントが実行できるブリーフを書く。
- 監視し、詰まりを解消し、必要に応じて介入する。
- ブランチを1つずつレビューしてマージする。
ステップ1：作業を独立したタスクに分解する
エージェントからではなく、目指す成果から考え始めます。目標を、それぞれ単独で完了・検証・マージできるタスクに分解しましょう。2つのタスクが同じファイルを編集するなら、1つにまとめるか、順番に実行します。「タスク2の新しいスキーマが必要」といった短い依存関係メモを添えておくだけで、統合時の想定外のトラブルはほとんど防げます。
ステップ2：git worktreeで各エージェントを分離する
同じ作業ディレクトリで2つのエージェントが動くと、互いの変更を上書きしたり、互いのテスト実行を混乱させたりすることがあります。最もシンプルで確実な分離方法がgit worktreeです。これは同じリポジトリに紐づいた追加の作業ディレクトリで、それぞれが独自のブランチを持ちます。
# One worktree and one branch per agent
git worktree add -b agent/auth-refactor ../app-agent-auth
git worktree add -b agent/billing-tests ../app-agent-tests
# See what is checked out where
git worktree list
# Clean up once the branch has been merged locally (use -D after a squash merge)
git worktree remove ../app-agent-auth
git branch -d agent/auth-refactorgitはデフォルトで、同じブランチを2つのworktreeで同時にチェックアウトすることを許可しません。これこそが求めている安全装置です。後片付けの際、git worktree removeは変更済みまたは未追跡のファイルを含むworktreeの削除を拒否します。先にコミットするか破棄し、問題ないと確信できた場合にだけ--forceを付けてください。なお、worktreeが分離するのはファイルだけで、すべてではありません。共有されるものについても計画しておきましょう。
- 依存関係とビルド成果物：各worktreeには通常、それぞれ専用のインストール済みパッケージ（node_modulesや仮想環境）とビルド成果物が必要です。
- ポート：2つの開発サーバーが同じポートにバインドすることはできないため、エージェントごとにポートを割り当てます。
- データベース：ローカルのデータベースやスキーマを分けて使い、共有のステージング環境は決して使わないでください。
- 環境ファイル：各エージェントが必要とする、機密情報を含まない設定だけをコピーします。
ステップ3：エージェントが実行できるブリーフを書く
エージェントは、ブリーフ（作業指示）の抜けをすべて推測で埋めてしまいます。良いブリーフは短く、それでいて漏れがありません。
- ゴール：実装方法ではなく、目指す成果を1文で書きます。
- コンテキスト：関係するファイル、モジュール、ドキュメントと、従うべき規約。
- 境界：公開インターフェース、マイグレーション、依存関係など、エージェントが変更してはいけないもの。
- 完了の定義：パスしなければならないテスト、型チェック、振る舞い。
- 引き継ぎ：変更内容の要約や未解決の疑問点など、報告してほしい内容。
エージェントに応じてAGENTS.mdやCLAUDE.mdなど、起動時に読み込まれるファイルにプロジェクト共通の指示を書いておけば、ブリーフのたびに規約を繰り返し書く必要がなくなります。
ステップ4：監視し、詰まりを解消し、介入する
エージェントが動き出したら、開発者の役割は書き手から監督者へと変わります。1つのエージェントの出力が流れていくのを眺め続けるのではなく、一定のリズムで様子を確認しましょう。権限のリクエストにはすばやく応答してください。止まっているエージェントは、その分だけ時間を失っています。方向がずれ始めたエージェントは早めに止めましょう。誤った方向に長く進んでしまった実行を立て直すより、より明確なブリーフで再スタートするほうが、たいていは早く済みます。
ステップ5：ブランチを1つずつレビューしてマージする
依存関係の順に、1ブランチずつマージします。マージのたびに、残りのブランチを更新後のメインラインにリベースし、チェックを再実行します。この段階で起きるコンフリクトは有益な情報です。見た目ほど独立していなかったタスクを教えてくれるからです。
AIエージェント同士のコンフリクトを防ぐには
並列エージェント間のコンフリクトの多くは、いくつかの共有ホットスポットから生じます。
- ロックファイルと依存関係のマニフェスト：依存関係の追加やアップグレードは、1ラウンドにつき1つのエージェントだけに許可します。
- データベースのマイグレーション：順番に実行します。並列で生成されたマイグレーションは、適用順序やスキーマの状態をめぐって衝突することがあるためです。
- ルーターや設定ファイルなどの共有レジストリ：ファイルごとに担当を1つに決めるか、先に自分で変更しておきます。
- 自動生成コード：複数のブランチから生成ファイルをマージするのではなく、マージ後に再生成します。
- フォーマットによる無用な差分：ほかに変更していないファイルは再フォーマットしないよう、エージェントに指示します。
もう半分の答えは、ブランチを短命に保つことです。数時間以内にマージされる小さなタスクは、何日もメインラインから離れたままのブランチに比べて、コンフリクトがはるかに起きにくくなります。
各AIコーディングエージェントの作業状況はどう監視する？
エージェントが1つならターミナルを見ていれば済みますが、5つになるとそうはいきません。すべてのエージェントについて、次の問いにひと目で答えられるようにしておくべきです。
- 何に取り組んでいて、どんなブリーフを渡されたのか？
- 今どんな状態か：実行中、入力や権限の待機中、エラーで停止中、それとも完了？
- ここまでに何を変更したか（ベースブランチとの差分）？
- どのコマンドを実行し、テストやチェックはパスしたか？
- どれくらいの時間動いていて、どれだけ使用量を消費したか？
ダッシュボードと同じくらい重要なのが通知です。一言の承認を10分間待ち続けるエージェントは、並列作業によくある隠れたコストです。優れたエージェント開発環境は、そうした瞬間をすぐに知らせてくれます。
複数のAIコーディングエージェントを動かすコストは？
コストには、モデルの使用量と人間の時間という2つの側面があります。モデルの使用量は、エージェントの数、実行時間の長さ、読み込むコンテキストの量に応じて増えます。トークン単位で支払う場合でも、サブスクリプションの利用上限の範囲内で使う場合でも、並列エージェントはその予算を速く消費します。さらにコンペ方式では、最終的に捨てることになる作業にあえて予算を使います。
最も過小評価されがちなのは人間の時間です。すべてのエージェントの出力は、読み、テストし、統合しなければならないからです。便利な目安は、同僚のプルリクエストと同じ丁寧さでレビューできる数だけエージェントを動かすことです。両方のコストを抑えるためのポイントは次のとおりです。
- タスクを小さく保ち、実行時間を短く、差分をレビューしやすくする。
- リポジトリ全体ではなく、関連するファイルをエージェントに示す。
- 方向がずれた実行は、最後まで走らせずに止める。
- タスクごとに使用量を記録し、どんな作業なら任せる価値があるのかを見極める。
AIが生成したコードに人間のレビューが欠かせない理由
AIコーディングエージェントは有能ですが、責任を負うことはできません。要件を読み違えたり、誤った振る舞いを正しいとみなすテストを書いたり、エラーを修正する代わりに握りつぶしたり、一度も実行されていないチェックをパスしたと報告したりすることがあります。人間が書いたコードをレビューするのも同じ理由からです。並列エージェントは、単により多くの変更をより速く生み出すだけです。
実践的なレビューのループは3層構造です。まずエージェントが、完了の定義に照らして自分の作業をチェックします。必要に応じて、2つ目のエージェントがまっさらなコンテキストで差分をレビューします。そして最後に、人間が差分を読んでマージするかどうかを決めます。自動化された層はノイズを減らしますが、その判断の代わりにはなりません。
エージェントが書いた変更のレビューチェックリスト
- エージェントによる要約だけでなく、差分そのものを読む。
- テストとチェックを自分で実行するか、CIで実行されたことを確認する。
- スコープの肥大化に注意する：ブリーフで一度も触れていないファイルが変更されていないか。
- 新しい依存関係、ネットワーク通信、そして認証・決済・個人データに関わる箇所をすべて確認する。
- シークレット、トークン、マシン固有のパスがコミットされていないことを確かめる。
- 新しいテストが単にパスするだけでなく、新しい振る舞いを実際に検証していることを確認する。
複数のAIエージェントを動かすときによくある失敗
- 2つのエージェントを同じ作業ディレクトリで動かし、ファイルの上書きで作業を失う。
- エージェントのブランチを何日も開いたままにし、きれいにマージできなくなる。
- 本番環境の認証情報や、必要のない権限をエージェントに与える。
- マージされて正しく動く変更の数ではなく、動いているエージェントの数で成果を測る。
よくある質問
IDEとエージェント開発環境の違いは？
従来のIDEは、1人が1つの作業コピーでコードを編集することを中心に設計されています（ただし最近は、多くのエディタにエージェント機能も備わっています）。一方、エージェント開発環境は複数のAIコーディングエージェントを監督することを中心に設計されており、ワークスペースの分離、タスク管理、ライブステータス、そして管理されたレビューとマージの経路を備えています。多くの開発者は両方を使い分けています。エージェントの調整にはADEを、作業内容の確認や仕上げにはIDEを使う、という形です。
AIコーディングエージェントは同時にいくつ動かすべき？
きちんとレビューできる数だけにしましょう。目安としては、明らかに独立したタスクに対して2〜3つのエージェントから始めます。数を増やすのは、レビューとマージのプロセスが追いついている場合だけにしてください。差分が何日もレビュー待ちのまま放置されていたり、読まずにマージしている自分に気づいたりしたら、動かしすぎです。
エージェントを並列で動かすのにgit worktreeは必要？
何らかの分離は必要で、その中で最も軽量な選択肢がgit worktreeです。各エージェントが、共有された1つのリポジトリの中で専用のディレクトリとブランチを持てます。別々のクローンやコンテナを使えばより強力に分離できますが、ディスク容量とセットアップの手間が増えます。プルリクエストを返すホスト型のサンドボックスなら分離を手元のマシンの外に移せますが、レビューまでは移せません。2つのエージェントに同じ作業ディレクトリを同時に編集させることだけは、絶対に避けてください。
AIコーディングエージェント同士でコードをレビューさせられる？
はい、できます。しかも有効な追加の層になります。レビュアーとしてのブリーフとまっさらなコンテキストを与えた2つ目のエージェントは、テストの不足、処理されていないエッジケース、スコープの肥大化をよく見つけてくれます。ただし、最終関門にするべきではありません。エージェント同士は同じ盲点を共有していることがあるため、本番環境に届くものについては、やはり人間が差分を読み、マージを判断するべきです。
AIコーディングエージェントに自分のマシンでコマンドを実行させても安全？
ガードレールを設ければ、安全に運用できます。エージェントには必要最小限の権限だけを与え、本番環境の認証情報はエージェントの環境に置かず、破壊的なコマンドやネットワークを使うコマンドには承認を必須にしましょう。issue、Webページ、サードパーティのファイルなど、コードベースの外からエージェントが読み込むものはすべて信頼できないものとして扱ってください。そこにはエージェントを誤誘導するよう仕組まれた指示が含まれている可能性があり、これはプロンプトインジェクションと呼ばれるリスクです。コンテナを使えば、さらに保護を強化できます。
Neptayのエージェント開発への取り組み
Neptayは、クライアント向けサービスの一環としてAIエージェントや自動化の設計を行っており、自社のテクノロジー製品はAnlatoブランドで開発しています。Anlatoファミリーのフラッグシップ製品であるAnlato Spaceは、私たちのエージェント開発環境です。多数のAIコーディングエージェントを1つのネイティブウィンドウに並べ、それぞれにタスクとステータスを持たせ、すべての変更がレビュー待ちとして並ぶ仕組みです。Anlato Spaceは近日公開予定です。チームのためにエージェントのワークフローを設計している方や、Anlato Spaceの最新情報を受け取りたい方は、hello@neptay.com までお気軽にご連絡ください。