AIが書いたコードはメインブランチを壊す頻度が半分

Mergifyは最新の『マージキューの状態報告2026』を公開し、過去3か月間の20万件以上のマージを分析しました。このレポートはMergifyの共同創業者兼CEOであるJulien Danjouによって執筆され、477のエンジニアリングチームのマージ行動を調査し、承認されたプルリクエスト（PR）がメインブランチにマージされるまでの間に実際に何が起こるのかという単純な問いに答えようとしています。

主な発見は、AI支援によるPRがメインブランチを壊す確率が非AIのPRに比べて約半分であることです（1.9%対4.4%）。この傾向はPRのサイズやリポジトリを調整した後も変わりません。注目すべきは、AI支援PRの平均変更行数が137行と、非AIの84行よりも多いことで、小さなPRほど安全という説明が否定されます。現在、プライベートマージの約7分の1にAI支援の痕跡が見られますが、これは下限値であり、実際の割合はさらに高いと推定されます。自律エージェントがPR全体を作成するケースはまだ稀で、ごく一部に留まっています。

チームサイズはメインブランチの安定性に大きく影響します。2〜5人の小規模チームでは破損率は0.77%（約130マージに1回）ですが、40人以上では12.5%（8マージに1回）に跳ね上がります。破損率は16〜40人のチーム層から急上昇し（2.49%）、このあたりでチームはマージの苦痛を感じ始めます。プライベートリポジトリの破損率はオープンソースの4.5倍（5.1% vs 1.1%）であり、これはコードの相互依存度の高さに起因します。プライベートリポジトリの失敗バッチは平均約5.8個のPRを含むのに対し、オープンソースでは2.6個です。

レポートはまた、バッチマージ（複数のPRを同時にテスト）の活用が不十分であることを指摘しています。プライベートマージの94%は依然として1PRずつ処理されており、バッチを利用するのはわずか6%です。バッチを使用する場合、平均4つのPRがグループ化されますが、多くのチームはこの最適化を活用できていません。マージキューの中央値滞在時間は約7分ですが、p99テールではプライベートリポジトリで20時間に達することもあります。DependabotやRenovateなどの自動化ツールは平均0.4分で処理されるのに対し、人間のPRは約12分かかります。

エンジニアリングチームへのアドバイスとして、チームサイズが15〜20人を超えたらマージキューの導入を検討すべきであり、キューが混雑してきたらバッチ処理を有効にすることが推奨されています。レポートはまた、GitHubネイティブキューと専用キューの違いを比較し、専用キューがバッチ自動二分、スコープ別並列キュー、優先順位レーンなどの利点を提供することを指摘しています。

全体として、このレポートはAIコーディングがメインブランチを不安定にするという一般的な懸念に挑戦し、チームサイズ管理の重要性を強調する実証的洞察を提供しています。