AI駆動開発で並列化しすぎると遅くなる理由｜worktree・AIエージェント開発の落とし穴

AI駆動開発では、1人でも複数のタスクを同時に進められるようになりました。

私自身もGitのworktreeを使い、複数のAIエージェントに別々のタスクを担当させながら並列開発を行っています。

最初はかなり速いです。

3本、4本と同時に実装が進み、「このまま並列数を増やせば、さらに速くなるのでは」と思います。

ところが、ある地点から急に遅くなります。

• PR同士が競合する
• mainを取り込むたびに修正が発生する
• 一方を直すと別のテストが落ちる
• CIを何度も回す
• AIが同じ共通部分を別々に変更する

結果として、最後は並列開発を止めて、1本ずつ処理する。

私はこの状態を何度か経験しています。

AIで速くなるのは「実装」だけ

原因を整理すると、AIによって急激に高速化するのは主にコードを書く部分です。

しかし開発には、その後があります。

仕様
↓
実装
↓
レビュー
↓
テスト
↓
PR
↓
マージ
↓
回帰確認
↓
リリース

AIによって実装速度が5倍になっても、レビューや統合能力まで5倍になるわけではありません。

その結果、

コードを書く能力より、変更を統合する能力がボトルネックになる

という現象が起きます。

海外でも、似た問題が見え始めています。

GitHubでも「AIが作るPR」をどうレビューするかが課題に

GitHubは2026年、AIエージェントによってPull Requestが大量に作られる時代を前提に、AI生成PRのレビュー方法について解説しています。

GitHubによると、Copilot Code Reviewはすでに6,000万件以上のレビューを処理しており、コードレビューへのAIエージェントの関与も急速に増えています。

ポイントは、

AIがコードを作る速度に、人間のレビュー能力が追いつかなくなる

ということです。

AIに10個のタスクを渡して10個のPRを作らせることはできます。

しかし、その10個を人間が安全に確認するには時間がかかります。

つまり、

AIによる生成能力
↑↑↑↑↑

レビュー・統合能力
↑

というアンバランスが生まれます。

StripeではAIが週1,000件以上のPRを本番へ

一方、AI駆動開発をかなり大規模に運用している企業もあります。

Stripeでは社内AIコーディングエージェント「minion」を活用しており、2026年には週1,000件を超えるPRを本番環境へ届けていることが紹介されています。

ただし重要なのは、

「AIを大量に動かしている」

ことではありません。

それだけのPRを、

レビューし、テストし、安全に統合できる仕組みまで作られている

ことです。

AIエージェントの数だけ増やしても、同じ速度にはなりません。

GitHubも巨大PRより「小さく分ける」方向へ

AIに大きな機能を丸ごと実装させると、数千行規模のPRになることもあります。

しかし大きなPRほど、

• レビューしにくい
• 競合しやすい
• 問題発生時の原因特定が難しい

という問題があります。

GitHubもAI生成コードを巨大な1本のPRにするのではなく、小さなPRへ分割して積み重ねる「Stacked Pull Requests」という考え方を紹介しています。

例えば案件管理機能なら、

PR1 DB
↓
PR2 API
↓
PR3 UI
↓
PR4 テスト

と小さく分けます。

AI時代は、

大量に作らせる技術より、小さく作らせる技術

の方が重要になってきています。

worktree並列開発でも同じことが起きる

worktreeを使うと、

A：画面
B：API
C：DB
D：テスト

のような並列開発ができます。

それぞれ独立している間は非常に高速です。

ところが途中から、

DB変更
↓
API変更
↓
画面修正
↓
テスト失敗

という依存関係が発生します。

さらに別のworktreeが共通コンポーネントを変更すると、

Aをマージ
↓
Bが競合
↓
Bを修正
↓
Cが失敗
↓
その間にmain更新
↓
再度修正

という状態になります。

これでは並列開発ではなく、

「並列手戻り」

です。

並列数を最大にすることが最速ではない

以前は、

「AIエージェントを5体使えるなら5並列」

と考えていました。

しかし今は、状況によって並列数を変える方が速いと考えています。

状況	並列数の目安
通常	2〜3
独立性が高い機能	4〜5
共通基盤変更	1〜2
大規模リファクタ	1
リリース直前	1

重要なのは最大並列数ではなく、

安全にmainへ統合できる数

です。

AI駆動開発で重要なのは「統合速度」

最近は、開発速度を見るときに、

「何個Issueを開始したか」

ではなく、

何個の変更を安全にmainへ入れられたか

を見るようにしています。

例えば、

• PR作成からMergeまでの時間
• Review待ち時間
• CI失敗率
• Merge Conflict発生率
• 修正のやり直し回数

です。

特にPRがどんどん溜まり始めたら危険です。

その場合は新しいAIエージェントを増やすのではなく、一度新規開発を止めて、PRやCIを片付けた方が結果的には速くなります。

AIを使い込むほど「AIを働かせすぎない」ことが重要になる

AI駆動開発を始めた頃は、

「もっとAIを動かせば速くなる」

と思っていました。

しかし使い込むほど、少し考え方が変わりました。

AI駆動開発で重要なのは、AIエージェントの数ではありません。

小さく設計
↓
小さく実装
↓
小さくテスト
↓
小さくレビュー
↓
小さくマージ

この流れを止めずに回すことです。

AIによってコードを書くコストは大きく下がりました。

その一方で、

AIが作った大量の変更を、安全に統合する能力

の重要性は以前より高まっています。

AI駆動開発の次のテーマは、単純な「コード生成速度」ではなく、

人間とAIを含めた開発ライン全体を、どこまで滑らかに設計できるか

なのだと思います。