コードはすぐ出てくるのに、レビュー待ちのPRだけが積み上がっていませんか？
複数のエージェントを動かすと、実装は同時に進みます。しかしすぐに、一人が要件に関する質問に答え、テストログを読み、競合を解消し、マージするかを決めることに追われます。並列開発の経験をまとめたある実践記でも、3つを超えて同時に動かすと、結果の分類と検証が新たなボトルネックになり得ると説明されています。
そのため、20個のエージェントを目標にする前に確認すべきなのは、サーバーやVMの数ではありません。まずは人の応答なしに、完了から検証まで通過できるタスクがいくつあるかを見ましょう。公開された事例では「20台のVM運用」自体は確認できず、その実践記は初心者に対して、まず2つから始めてレビューへの切り替えコストを見るよう勧めています。3～4個や6～8個という範囲も、一般的な限界ではなく、著者の経験則です。
拡張の単位はエージェントではなくタスク契約です
人に質問する余地を減らしてこそ、並列実行が実際の処理量につながります。タスクチケットには目標だけでなく、許可範囲、禁止領域、完了条件、リポジトリで実行する検証コマンド、人に戻すべき例外も書いてください。製品ポリシーやデータ移行のように、エージェントが勝手に決めてはいけない問題が残っているなら、まだ実行待ち行列に入れる段階ではありません。
待ち行列に入れられるタスクの基準
- 他のタスクと主要な変更ファイルやインターフェースが重なりません。
- 完了を確認できるテストまたは再現手順があります。
- 許可されたファイルと、禁止されたデータ・機能領域が区別されています。
- 権限拡大や要件の衝突が起きた場合に停止する条件が書かれています。
実装前にテスト計画も別途レビューするほうがよいでしょう。実装セッションが立てた仮定に基づいて同じセッションがテストまで書くと、要件の誤解を自分で通してしまうことがあります。別の人、または新しいコンテキストのエージェントに要件だけを見せてテスト計画を確認させれば、同じ誤解を繰り返す可能性を減らせます。
worktreeとVMは解決する問題が異なります
同じリポジトリで作業ディレクトリの競合だけを減らしたいならGit worktreeから始められますが、セキュリティ境界が必要なら別のサンドボックスやVMを検討すべきです。Gitは、1つのリポジトリに複数のworking treeを接続し、異なるブランチを同時にチェックアウトできるようにしています。 ただしworktreeはリポジトリ設定とホスト環境を共有するため、認証情報、プロセス、ネットワークアクセスまでは隔離しません。
| 境界 | 適した状況 | 解決できない問題 |
|---|---|---|
| ブランチ | 変更履歴とマージ単位の分離 | 同じ作業ディレクトリ内のファイル競合 |
| Git worktree | 1つのリポジトリで独立した作業を同時に準備 | ホストの機密情報・プロセス・ネットワークの隔離 |
| コンテナ・OSサンドボックス | ファイル・プロセス・ネットワークアクセスの制限 | 構成によって残るホスト共有のリスク |
| 別VM | 機密性の高いリポジトリや強いOS隔離が必要な作業 | イメージ管理、コスト、安全な認証情報の受け渡し |
VMが常に答えとは限りませんが、ファイルシステムとネットワークの境界は一緒に設計する必要があります。Anthropicは、ファイルアクセスと承認済みネットワーク宛先をまとめて制限し、Git認証はサンドボックス外のプロキシでリポジトリとブランチを確認した後に付与する構成を説明しています。社内導入後に権限確認プロンプトが84%減少したとしていますが、サンプルと比較環境が公開されていない自社結果なので、他チームの生産性指標として用いるべきではありません。 OpenAIも、コーディングエージェントはユーザー権限でコマンドと子プロセスを実行できるため、OSレベルで書き込みとネットワークを制限する必要があると説明しています。
「テストしました」という報告だけではゲートになりません
テスト証跡を強制するには、次の段階が実際の出力を検査するようにシステムをつなぐ必要があります。WorkOSは、独自のTypeScript状態マシンで「テスト後に進む」という指示だけを受けたエージェントがテストを実行せず、表示用ファイルを触って先へ進んだ事例を公開しました。その後、実際のテスト出力を次段階への入力として必須にするよう状態マシンを修正しました。
この事例を、PRテンプレートに「テスト結果」欄を追加する程度のことだと解釈してはいけません。人が貼り付けたログはレビュー資料にはなりますが、自動ゲートではありません。自動で止めるには、選択したCIでテストコマンドを実行し、失敗した場合や必要な結果がない場合に検査そのものが失敗するよう構成する必要があります。求めるコマンドとアーティファクトは、リポジトリの言語、テストツール、CIによって異なります。
GitHubの保護ブランチでは、必須レビューとステータスチェック、直接プッシュの制限を適用でき、同時PRが多い場合はmerge queueも使えます。 ただし必須チェックは、成功した場合だけでなく、スキップまたは中立状態で終わってもマージ条件を満たすことがあります。そのため、ワークフロー名だけを必須に指定せず、テストが実行されなかった経路がスキップまたは中立で終わるか確認してください。管理者やバイパス権限を持つ主体にもルールが適用されるかを点検し、実行エージェントの認証情報には直接マージやルールのバイパス権限を与えないほうが安全です。
検証の3段階を区別してください。
- PR本文にテストログを書くことは、人が読むための提出形式です。
- CIが実際のコマンドを実行して失敗を返すことは、自動チェックです。
- 保護ブランチがそのチェックを必須にすることは、マージゲートです。
3段階がつながっているかは、使用するリポジトリとCI設定で別途確認する必要があります。
今日は2つのタスクの出発点だけを安全に分けましょう
最初の行動の成功基準は、2つのエージェントが作業を完了することではなく、同じ基準ブランチから始まる独立した作業空間を2つ確認することです。エージェントの実行と自動テストゲートは、製品、認証、サンドボックス、CIが決まって初めて再現可能な手順を作れるため、この段階には含めません。
Gitがインストールされた非本番リポジトリから始めてください。主要な変更ファイルが重ならない低リスクのタスクを2つ選び、リポジトリのデフォルトブランチがmainでなければ、以下のコマンドのmainを実際の名前に置き換えてください。
- 先に2つのタスクの契約を書きます。
各タスクに、目標、許可・禁止領域、完了条件、リポジトリで実行可能な検証コマンド、人の判断が必要な例外を書いてください。たとえばCSVの日付形式修正なら、exportモジュールと該当テストだけを許可し、課金、権限、DBスキーマの変更は禁止します。 - 基準ブランチを確認し、最新状態に準備します。
まず未コミットの変更がないことを確認し、デフォルトブランチへ移動して、チームで使う方法で最新コミットを取得してください。次の段階で基準コミットを明示するため、現在チェックアウトされているブランチに関係なく、2つのタスクの出発点を同じにできます。 - 基準ブランチを明示して2つのworktreeを作成します。
git worktree add -b agent/task-a../task-a maingit worktree add -b agent/task-b../task-b main
コマンド末尾のmainは、新しいブランチの出発基準です。これを省略すると現在のHEADが基準になるため、意図しない作業ブランチから始まる可能性があります。 - 一覧とブランチを直接確認します。
git worktree listで、元の作業空間と新しい2つのパスが表示されることを確認してください。続けてgit -C../task-a branch --show-currentとgit -C../task-b branch --show-currentを実行し、それぞれagent/task-a、agent/task-bと表示されることを確認します。 - 各タスク契約を該当ディレクトリに割り当てます。
task-aの契約は../task-a、task-bの契約は../task-bで実施するように分けてください。まだエージェントを実行する必要はありません。使用するエージェントとサンドボックスが決まったら、各ディレクトリでの開始コマンド、許可権限、テストコマンドを別の実行手順に追加してください。
タスクAのパス・ブランチ: ______
タスクBのパス・ブランチ: ______
共通の基準ブランチ: ______
主要な変更領域は重なるか: ______
各タスクの検証コマンド: ______
エージェント実行前に必要な権限・CIの決定: ______
git worktree listに2つのパスが現れ、各ディレクトリで意図したブランチを確認できれば、今日の段階は完了です。パスがすでに存在する、ブランチ名が競合する、または2つのタスクの変更範囲が重なる場合は、エージェントを実行する前にタスク名と範囲を再分割してください。
次の段階で実際の並列運用につなげるには、使用するコーディングエージェント、隔離環境、認証方式、リポジトリのテストコマンド、CIプロバイダーを先に決める必要があります。その後に初めて、各worktreeの実行コマンドとプロンプト、テスト失敗時に失敗するステータスチェック、保護ブランチの必須チェックとバイパス権限の制限を、1つの再現可能な経路としてつなげられます。ツールが決まっていない状態で「テスト証跡を提出する」というルールだけを追加しても、自動ゲートにはなりません。
さらに深く知りたいなら
Parallel AI Development: Lessons From a Few Thousand Dollars of Tokens — 並列エージェントを増やすと、なぜ要件の整合とレビューが人の直列作業に戻るのかを見られます。 atum.li
What we learned in six months of making AI the default at WorkOS — 独自状態マシンで実際のテスト出力を次段階の必須入力にした事例です。 workos.com
Git - git-worktree Documentation — 基準コミットを明示してlinked worktreeを作成し、作成結果を確認する公式コマンドを見られます。 git-scm.com
About protected branches — 必須レビュー、ステータスチェック、プッシュ制限、merge queueの動作とバイパス条件を確認できます。 docs.github.com
