自分でコードを書かずに、20台のVMでエージェントを動かすのですか？ 重要なのはエージェント数ではなく、20件の結果が同時に押し寄せても人がボトルネックにならない運用構造です。
20台を起動する前に、人の待ち行列から設計する必要があります
並列エージェントのスループットは、実行中のセッション数ではなく、人が判断できる結果の数で決まります。 5つのエージェントが同時に質問し、テストレポートとPRを提出すると、コーディング時間は短くなっても、要件確認、優先順位の判断、競合の解決は一人に集中します。実際の並列開発の事例でも、3つ以上になると結果を読み分けて分類する作業が新たなボトルネックになり、要件のすり合わせは深い集中を必要とするため並列化しにくいと指摘されています。
そのため、「20台のVM」をすぐに「生産性20倍」と解釈してはいけません。まずタスクを、人の応答なしに完了できる大きさに分割する必要があります。良いタスクチケットは目標だけを書きません。変更を許可する範囲、触れてはいけない領域、完了条件、実行する検証コマンド、結果の提出形式まで含めます。エージェントが途中でプロダクト判断を下す必要があるなら、まだ委任の準備ができていないタスクです。
エージェント数を増やすと先に増えるもの
生成速度とともに、質問、PR、テストログ、競合、コストも増えます。一画面にセッションを増やす前に、「どの結果だけを人に上げるのか」を決めてください。失敗ログの原文、変更要約、リスク度、次のアクションを同じ形式で提出させると、レビュー待ち行列がはるかに明確になります。
運用ボードはセッション一覧よりもタスク状態を示すほうが適しています。最低でも待機・実行中・検証失敗・人の判断が必要・マージ可能を区別してください。人に通知する条件も制限する必要があります。要件の競合、権限拡大、繰り返す失敗、データマイグレーションのように人が決めるべき事象だけを上げ、一般的なテスト失敗はまずエージェントに修正させます。
VMは生産性ツールである前に、影響範囲を分ける境界です
エージェントごとにVMや強力なサンドボックスを与える目的は、速度より隔離です。 コーディングエージェントはファイルを変更し、シェルコマンドを実行し、パッケージをインストールできます。OpenAIも、エージェントは実際のユーザー権限で動作し得るため、ファイル書き込みとネットワークアクセスをOSレベルで制限するサンドボックスが必要だと説明しています。
隔離単位は「エージェント1つにつき独立した作業空間1つ」とすると分かりやすいです。異なるリポジトリなら別のVMやコンテナを使い、同じリポジトリ内の独立したタスクならGit worktreeも実用的です。Git公式ドキュメントによると、1つのリポジトリに複数のworking treeを接続し、異なるブランチを同時にチェックアウトできます。 ただしworktreeはGit状態の競合を減らすだけで、ホストの秘密情報やネットワークまで隔離するものではありません。
| 境界 | 防げる問題 | 残る問題 |
|---|---|---|
| ブランチ | 変更履歴とマージ単位の分離 | 同じディレクトリ内のファイル競合 |
| Git worktree | 作業ディレクトリとブランチの同時実行を分離 | ホストの認証情報・プロセス・ネットワークを共有 |
| コンテナ・サンドボックス | ファイルとプロセスへのアクセスを制限 | 設定によりカーネル・ホスト資源を共有 |
| エージェントごとのVM | OSと作業環境まで強力に分離 | コスト、イメージ管理、認証情報の受け渡し設計 |
重要なのは、VM内に長期認証情報をコピーしないことです。Anthropicのクラウド方式はセッションを隔離し、Git認証情報をサンドボックス内に置かず、別のプロキシがリポジトリとブランチを確認してからGitリクエストに認証を付与します。 同じ原則を自前環境にも適用し、リポジトリ単位の読み取り権限、作業ブランチへの書き込みのみ、短命トークン、デフォルト拒否のネットワークを使ってください。
ファイル境界とネットワーク境界は併用する必要があります。Anthropicは、ファイルだけを隔離すると別経路でネットワーク権限を得られる可能性があり、ネットワークだけを隔離すると機密ファイルを読める可能性があると説明しています。両方の境界を適用した社内利用では、権限確認プロンプトが84%減少したとも明らかにしています。 この数値がすべての環境にそのまま当てはまる保証はありませんが、繰り返しの承認ではなく強制可能な境界を設計すべきだという方向性は明確です。
レビューをなくすのではなく、「コードを読む」から「証拠を確認する」へ変えましょう
エージェントが「テストしました」と言うことと、実際にテストが実行されたことは別です。 WorkOSは、テストを実行するよう指示するだけでは、エージェントが証拠のように見えるファイルを作成できたと説明しています。解決策は、次のステップが実際のテスト出力を入力として要求するよう、ワークフローを変えることでした。
各タスクの提出物はPRだけで終わらせてはいけません。最低でも変更理由、修正ファイル、実行したコマンド、テスト原文またはアーティファクトへのリンク、既知のリスク、ロールバック方法を一緒に提出させてください。実装エージェントと検証エージェントのコンテキストも分けるほうがよいです。同じ誤解を共有した1つのセッションが実装とテストを両方作ると、誤った要件を完璧に通してしまう自己充足型の検証が生じる可能性があります。
最終的なマージ権限は実行エージェントから分離してください。GitHubの保護ブランチは、必須ステータスチェックが成功・スキップ・中立になるまでマージを止められ、特定のGitHub Appが作成したチェック結果だけを認めるよう設定することもできます。 PRが増えたらmerge queueを有効にし、最新のデフォルトブランチ上で再びチェックを通過した変更だけを順番にマージする方法もあります。
人はすべてのコードを同じ深さで読む必要はありませんが、すべてのリスクを同じ方法で自動承認してもいけません。認証・決済・権限・データ削除・マイグレーションはコードとクエリを直接確認し、UI文言や社内ツールのように戻しやすい変更は、テスト結果とプレビューを中心にレビューしてください。WorkOSが社内エージェント1つに対して180件のPR規模の信頼性検証期間を別途設けた事例のように、繰り返し使う自動化そのものもプロダクトとして捉え、信頼性を管理する必要があります。
今週、2つのエージェントで運用ボードを作る
- 競合しないように2つのタスクを分割してください。
異なるリポジトリを選ぶか、同じリポジトリなら主に修正するファイルが重ならない2つのタスクを選びます。各チケットに目標、禁止領域、完了条件、検証コマンド、リスク等級を書いてください。 - 作業空間と権限をそれぞれ分離してください。
低リスクの試行なら、git worktree add ../agent-a -b agent/aのように別のworktreeから始められます。外部ドキュメントを読んだり任意のコマンドを実行したりする必要があるなら、別のVM・サンドボックスを使い、ホームディレクトリとクラウドキーは接続しないでください。 - 提出形式を固定してください。
終了前に、PRリンク、5行の変更要約、実行コマンド、テスト結果、失敗項目、ロールバック手順を残すようにします。「すべて通過」という文ではなく、CIログまたはテストアーティファクトを求めてください。 - マージゲートを強制してください。
GitHubのSettings → Rules → Rulesetsまたはブランチ保護設定で、PR必須、ステータスチェック必須、直接pushの制限を有効にします。高リスクの変更には人の承認を追加し、実行エージェントにはマージ権限を与えないでください。 - 1週間後は数字ではなく介入を数えてください。
完了タスク数とともに、人への質問回数、再実行回数、競合数、レビュー待ち時間、マージ後の差し戻しを記録します。質問と待ち時間が減らないなら、3つ目のエージェントを追加せず、先にチケットと検証手順を直してください。
さらに深掘りしたいなら
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
Beyond permission prompts: making Claude Code more secure and autonomous — ファイル・ネットワーク隔離と限定的なGit認証構造を理解するのに適した公式資料です。 anthropic.com
Git - git-worktree Documentation — 同じリポジトリで複数の独立した作業ディレクトリを作るコマンドと整理方法を確認できます。 git-scm.com
About protected branches — 必須ステータスチェック、承認、merge queueでエージェントの変更を統制する公式設定ドキュメントです。 docs.github.com
