5つのコーディングエージェントを並列に走らせる2つのやり方 — 一方は4つを捨て、もう一方は41.7%の確率で衝突する
By Surya Pratap
2026年9月22日
12 min read
AI & Technology
2026年9月22日
12 min read
冗長型と分割型のファンアウトHover to explore今年、誰も大声で名付けないままに一つのツールのカテゴリが生まれた。そして面白いのは、それが何をうまくやるかではない。それが静かにこちら側へ残していくもののほうだ。
本記事は、Stably AI による MIT ライセンスの並列エージェント環境 Orca と、2026年9月20日公開の ArshTechPro による解説記事、Daniel Ogenrwot と John Businge による AgenticFlict データセット、Xu・Subramanian・Karthik によるエージェントの同時プルリクエストの研究、そして Daniel Vaughan によるその研究の分析 に基づく。どの数字をどこまで信用するかは第8節で述べる。2種類のファンアウトの区別、継ぎ目の議論、そしてすべての提言は筆者のものだ。
エージェント開発環境 — ADE、そう、IDE と1文字違いなのはわざとだ — とは、モデルを内蔵しないデスクトップアプリケーションである。内蔵しているのは艦隊のほうだ。
抜け出したのは Orca だった。MIT ライセンスで、macOS・Windows・Linux で動き、モバイル用のコンパニオンアプリもある。自らの売り文句はあけすけだ。「Codex、ClaudeCode、OpenCode、Pi を横に並べて走らせる。それぞれ自分の worktree の中で、一か所にまとめて追跡できる」。名前の挙がっている CLI エージェントは30ほどで、実際にはそのいずれでも動く。9月22日にリポジトリを見たときはおよそ7万5000スターだった。夏に書かれたレビューは6万に近い数字を挙げているので、曲線は十分に急で、あなたが読む数字はすでに古い。
仕組みは2015年からそこにあった git のプリミティブで、それが突然キラーアプリケーションを手にした。
1タスクに1 worktree。 各エージェントは同じオブジェクトストアを共有する自分専用のチェックアウトディレクトリを持つ。本物のファイルシステム、本物のブランチ、stash は不要だ。
1 worktree に1ターミナル。 エージェントのセッション、テスト実行、プレビューサーバーのすべてがそのディレクトリに閉じる。
.git/index.lock の奪い合いがない。 2つのエージェントが同じ作業ディレクトリに書き込んで互いを壊すという失敗は、原理的に起こり得なくなる。
注釈を付けられる差分。 差分の特定の行に markdown でコメントを残し、まとめてエージェントにフィードバックとして返せる。
これは良い工学であり、本物の苛立ちを解消している。エージェントが1つ目のタスクで難儀している間に2つ目を始めたいと思ったことがあるなら、ここで何が解かれているかは正確にわかるはずだ。
worktree は書く作業を隔離する。ツールの中に、マージを隔離するものは何もない。
これを書きたくなった理由がここにある。ツールが差し出す操作は一つ — これを5つのエージェントに振り分けろ — なのに、その一つの操作がまったく異なる2つの作業を覆っている。
冗長型ファンアウトはデモのほうだ。プロンプト1つ、エージェント5つ、worktree 5つ、そして同じタスクへの5回の挑戦。5つの差分を読み、最良の1つを残し、4本のブランチを消す。Orca 自身の説明もそうなっている。1つのプロンプトを5つのエージェントに振り分け、結果を比べ、勝者をマージする。
分割型ファンアウトは、そのうち移行してしまうほうだ。異なる5つのタスク、5つの worktree、5つのエージェント、そして最後には5つとも欲しい。何も捨てない。捨てることが目的だったことなど一度もないからだ。目的は、1つ分の時間で5つのことを片づけることだった。
インターフェース上では同じに見える。正反対である。
| 冗長型ファンアウト | 分割型ファンアウト | |
|---|---|---|
| 変わるもの | エージェントまたはシード | タスク |
| 残すブランチ | 1本 | 全部 |
| マージが必要なブランチ | 1本 | 全部 |
| 上乗せされる統合リスク | なし | 本記事の主題 |
| 支払うもの | 成果1に対して支出N倍 | 成果N倍に対して支出N倍、ただし衝突の分だけ目減り |
冗長型ファンアウトは値札の正直な宝くじだ。5回分を使って1つの結果を得る。支出の5分の4が捨てられることは最初からわかっている。報道で引かれているレビュアーの言い方は率直だ。Claude Code を3並列で走らせれば、クォータは3倍消費する。隠れたコストはない。無駄こそが見えている部分だからだ。
隠れたコストが住んでいるのは分割型ファンアウトのほうだ。こちらはより倹約的に見える — 何も捨てないのだから。まさにそれゆえに人は移行する。たいていはツールを入れて1週間以内に。
この点に関わる2026年の実証研究が3本あり、合わせて読むと筋の通った話になる。
エージェントの同時作業はすでにどれくらい当たり前なのか
Xu・Subramanian・Karthik は、2807リポジトリにわたる3万3596件のエージェント作成プルリクエストを精査した。時間帯が厳密に重なる条件で、エージェントの PR の79.4%が別のエージェントの PR と同時に動いていた。対象は全リポジトリの40.2%にあたる。窓を1週間に広げれば、53.4%のリポジトリで**PR の95%**になる。
分割型ファンアウトは、誰かが試すかもしれない先進的な実践などではない。エージェントが入っているリポジトリの既定の状態である。
その成果物はどれくらいの頻度で衝突するのか
Daniel Ogenrwot と John Businge による AgenticFlict データセットは規模の広いほうだ。5万9000を超えるリポジトリから集めた14万2000件を超えるエージェントのプルリクエストのうち、10万7000件以上を決定的なマージシミュレーションで再現している。結果は27.67% — 2万9000件以上の PR — がテキスト上のマージコンフリクトを生み、33万6000を超える個別の衝突領域にまたがっていた。
この数字に牙を与える比較がある。人間が書いたプルリクエストを扱った先行研究は、おおむね**10〜20%**の範囲に収まる。エージェントの貢献は、人間の1.5倍から2.5倍ほどの割合で衝突していることになる。
どのエージェントかは問題になるのか
製品の位置づけを変えてしまうのがこの発見だ。Xu らは747組の PR ペアでマージシミュレーションを走らせ、内訳を分けた。
看板機能こそが最悪のケース
異なるエージェント同士のペアは、同一エージェント同士のおよそ2倍の割合で衝突した。どの ADE も先頭に掲げる能力 — Claude Code も Codex も Cursor も横に並べて走らせよう、一つに義理立てする理由などない — は、分割型モードにおいては、データが最も好まない構成だということになる。異なる訓練を受け、異なるシステムファイルから起動され、命名・ファイル配置・ヘルパーの置き場所について異なる意見を持つ2つのエージェントは、同一エージェントの2回の実行ならたいてい避けられる形で構造的に食い違う。
正直に付け加えておく。現実の世界では、異なるエージェント同士の重なりはまだ稀だ。同時進行のペアのうち異なるエージェントを含むものは0.5%にすぎず、2807リポジトリ中122件にとどまる。41.7%という数字は、やった場合に起きることを小さな標本で測ったものだ。そして ADE の価値提案とは、その稀だったことを容易にする、まさにそれである。
これらの衝突が実際には何なのかを分解すると、話はバージョン管理のものではなくなる。Vaughan による当該研究の分析では、衝突したペアは3つに分かれる。
| 衝突の種類 | 割合 | 実際に意味しているもの |
|---|---|---|
| テキストの重なり | 57.6% | 2つのエージェントが同じ行を編集した。分割の失敗であり、2人に1つの机をあてがったということ |
| 変更／削除 | 26.8% | 一方が変更したものを他方が削除した。誰も下していないアーキテクチャ上の判断が、二度、別々に下された |
| 追加／追加 | 15.1% | 両方が同じファイルを作った。仕様の失敗であり、相手がそれを必要とすると誰も伝えなかった |
マージの問題なのは最初の1つだけだ。残りの2つ — 合わせておよそ42% — は構造的で、機械的には解消できず、そもそもブランチ間の衝突ですらない。これは2つの計画の衝突であり、しかも考え得る最悪の時点、両方の計画が完全に実装され終わったあとに発見される。
追加／追加の衝突はとりわけ雄弁だ。2つのエージェントが別々にあるファイルが必要だと結論し、それを考案し、どちらも相手を知らなかった。どれだけマージツールを積み上げても直らない。直すべき場所は上流、こちらが何を伝えたかにある。
そしてこれらの衝突がどこに落ちるかにも注目したい。衝突したファイルの84.4%はソースコードであって、ロックファイルや依存関係のマニフェストではない。相手の版を採れば済む、退屈だが機械的な衝突ではないということだ。両側を理解しなければならない種類のものである。
1段落しか残せないとしたら、下線を引くのはここだ。
これらの比率はいずれもテキスト上の衝突だけを対象としている。 著者たちもはっきりそう述べている。ビルド失敗と意味的な衝突を除いた、保守的な下限だと。つまり、git が止まって教えてくれたケースを測っているということだ。
危険なのはもう一方である。
きれいにマージされてしまう衝突
2つの worktree に2つのエージェント。一方が関数名を変え、見えている呼び出し箇所をすべて更新する。もう一方が、最初のエージェントが一度も開かなかったファイルの中で、古い名前のまま新しい呼び出しを追加する。ファイルは別々。重なる行もない。git は何も言わずにマージする。そしてコンパイルの通らないブランチが、あるいはもっと悪いことに、通ってしまうブランチができあがる。片方のブランチで検証ルールを変え、もう片方で古いルールに依存していれば、CI は緑のまま、2週間後に本番でバグが顔を出す。「この2つの変更は何が真であるかについて意見が食い違っている」ことを示すコンフリクトマーカーは存在しない。
worktree が隔離するのはファイルシステムの層だ。意味の層では協調しない。2本のブランチはまったく重ならないファイルに触れながら、なお矛盾し得る。ルートテーブル、まとめ役のエクスポート、共有された型定義、設定、データベーススキーマ、あるいは何かの振る舞いについての素朴な前提を通して。
だから27.67%の正直な読み方はこうなる。それは問題が自分から名乗り出た割合である。 名乗り出なかった割合は誰も測っておらず、そしてそれはゼロではない。
私が実際に土台にする捉え直しはこれで、これはツールの話ではまったくない。
どの ADE も、エージェントを何個走らせるべきかという問いに、予算やマシンから引いた数字で答えるよう誘ってくる。5つがしっくりくる。5つはマーケティングが見せている数だ。だが本当の制約はクォータとは何の関係もない。
並列に走らせられるエージェントの数は、コードベースが持つ継ぎ目の数までだ。継ぎ目とは、その両側で2つの変更が互いを見ずに書ける境界のことをいう。
継ぎ目とは、安定したインターフェースを持つモジュール、API 契約の裏にあるサービス、追加しかしないマイグレーション、他の誰も import していないコンポーネントのことだ。コードベースに本物の継ぎ目が4つあるなら、エージェント4つが上限になる。8つ走らせるということは、そのうち4つが、残る4つが同時に変更しつつある前提に対して書いているということであり、どれがそうだったかはマージの時点で、上に挙げた比率で判明する。
これは、そうでなければ逆説に見えることを説明してくれる。よく分解されたコードベースを持つチームは並列エージェントが見事に働くと報告し、絡まったコードベースのチームは混乱を報告する。しかも両者はまったく同じソフトウェアを走らせている。変数はツールではない。継ぎ目の数のほうだ。
これは導入すべきかという問いへの正直な答えにもなる。継ぎ目が3つしかないなら、12エージェント分の艦隊管理を買うのは、使えない容量を買うことだ。並列性を解錠する作業は、昔から変わらない地味なモジュール化の作業である。締まらない結論だが、私はこれが正しいと思っている。
5つ、順番に。どれも、気に入っているツールを手放せとは言っていない。
研究は要らない。要るのは git merge-tree だ。この1か月にエージェントが生んだブランチを取り、各ペアをマージベースに対して再生し、いくつ衝突するかを数える。その数字はあなたのものだ。業界平均ではなく、あなたのコードベースの継ぎ目の構造を映している。19.8%をかなり下回るなら、分割は標準より上手で、ファンアウトはもっと広げてよい。40%を超えるなら、エージェントを足すことは手戻りを足すことになる。
マージシミュレーションは、エージェントがファイルを書くたびにフックで走らせても十分に安い。2つのエージェントが同じ行に向かっているという情報は、3分目には非常に価値があり、2時間目にはほとんど価値がない。その頃には両方がすでに衝突の上に積み上げてしまっている。
ファンアウトの前に、各タスクが触ってよいパスを指定する。そして自分の集合の外に手を伸ばしたエージェントは、見逃してよい些事ではなく、タスクの切り方が間違っていた合図として扱う。タスクをまたいで成り立つ境界の置き場所としては AGENTS.md が適切だ。上位のリポジトリが実際に何を書いているかも見てほしい。
1本を着地させ、次を新しいベースにリベースし、衝突したらリベース後のベースをエージェントに渡して変更をやり直させる。自分が書いてもいない2つのものの間の衝突を手で解決するのではなく。エージェントが現在の現実に対して自分の仕事を合わせ直すほうが、関与していない2つの計画の間をあなたが裁定するよりも良い結末になる。
19.8%対41.7%は、この記事全体で最も安い意思決定だ。複数エージェントの比較は冗長型ファンアウトのために取っておく。勝者を選んで残りを捨てるあの場面でなら、作風の食い違いはまさに狙いそのものであり、着地するブランチが1本だけである以上、何のコストにもならない。
5つすべての下にある経験則
結果を1つだけ残すつもりなら多数のエージェントを、結果を多数残すつもりなら1つのエージェントを使う。ADE はどちらも1クリックにしてしまう。だからこそ、この区別は自分の頭の中に置いておかねばならない。
747組は小さな標本であり、異なるエージェント間の区間は広い。 41.7%という数字は33.1〜50.9%という95%信頼区間を背負っている。私が行動の根拠にするのは方向 — 異なるエージェント間のほうが同一エージェント内よりかなり悪い — であって、小数第2位ではない。
AgenticFlict の27.67%は、あなたのリポジトリについての予測ではない。 構造も、レビュー文化も、エージェントの使い方もまるで異なる5万9000のリポジトリにまたがる母集団の比率だ。よく分解されたコードベースでタスクの切り方が厳密なら、これをはるかに下回る。測るべき理由ではあっても、計画に使う数字ではない。
人間側の10〜20%という基準値は、手法の異なる別の研究から来ている。 それらを横に並べるのは方向として有用だが、統制された実験ではない。エージェントの PR は概して大きく、速く生産されるので、差の一部は確実にそちらの事情であって、エージェントに内在する何かではない。
ADE が悪いツールだとは言っていない。 worktree による隔離は率直に正しく、注釈を付けてエージェントに返すレビューの流れはこのカテゴリで最良のものだ。私の議論は、それが解決するものと創業者がそれが解決すると思い込むものとのあいだの隙間についてであって、やっていることの質についてではない。
スター数は採用ではないし、まして継続利用ではない。 動きの速いカテゴリでの7万5000スターは、注目が集まったことを教えてくれる。そのうち何件が3月にもまだ使っているかは何も教えてくれない。
ここまでのどれも意味的な衝突については測られていない。 私自身も測っていない。それらが存在し、したがって公表された比率は問題を過小評価している、と論じたにすぎない。どれだけかは言えないし、今のところ誰にも言えない。
コーディングエージェントを並列に走らせることは、今年、難しい問題ではなくなった。隔離された worktree、クリック1回、対応エージェント30種、MIT ライセンス、スマートフォンからも動く。この部分は終わっている。
その成果物を着地させるほうは終わっていない。人間の仕事を着地させるより測定可能なかたちで難しく、そしてどの ADE も解決するとは言っていない半分だ。ツールの中では解決できないからである。それはコードがどう分解されているか、タスクをどれだけ正確に切ったかの下流にあり、そのどちらも、これらが存在する前からあなたの仕事だった。
この型は、エージェント時代のエンジニアリングで繰り返され続けているものだ。ボトルネックは消えない、移動する。そして、いまだ判断を要するもののほうへ移動する。生成は並列になった。統合はならなかった。そして判断があるのは統合のほうだ。
ファンアウトを広げる前に、継ぎ目を数えること。その数が走らせようとしていたエージェントの数より小さいなら、買っているのはスループットではない。文書化された比率のマージコンフリクトを、エージェント1つあたり定価を払って買っているのだ。
出典: GitHub 上の Orca — MIT ライセンス、対応エージェントの一覧、worktree ごとの隔離モデル、1つのプロンプトを5つのエージェントに振り分けるという記述、および2026年9月22日時点のスター数。ArshTechPro「Orca Explained」、2026年9月20日 — ADE という枠組み、worktree とターミナルとプレビューからなる構造、差分に注釈を付ける流れ、そして並列エージェントが消費を倍加させるという指摘。Ogenrwot と Businge「AgenticFlict」 — 14万2000件のプルリクエスト、5万9000のリポジトリ、10万7000件のマージシミュレーション、27.67%というテキスト衝突率、33万6000の衝突領域、および先行研究による人間側の10〜20%という基準値。Xu・Subramanian・Karthik「AI Agent Pull Requests on GitHub」 — 2807リポジトリにわたる3万3596件の PR、79.4%と95%という同時実行の数値、747組のマージシミュレーション、信頼区間付きの19.8%と41.7%という比率、異なるエージェント間ペアの0.5%という割合、およびソースコードファイルの84.4%という数値。Daniel Vaughan「When Agents Collide」、2026年7月28日 — 57.6%／26.8%／15.1%という衝突の分類と、worktree による隔離はディレクトリの衝突を防ぐがマージコンフリクトは防がないという観察。冗長型と分割型のファンアウトの区別、git のコンフリクト分類を分割・アーキテクチャ・仕様の失敗に対応づけた整理、継ぎ目の議論、そして第7節のすべての提言は筆者のものだ。ボトルネックが移動するという議論についてはAnthropic の CI の数字を、この成果物を誰がレビューすべきかについてはコードを書く人より先にレビューする人を採用せよを参照してほしい。
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
