11月9日、テクノロジーメディア startuphub.ai が「Uber let trunk break to ship AI code faster」と題した記事を公開した。AIコード生成によるPR急増でビルドパイプラインが限界を迎えたUberが、mainブランチの破壊を許容しつつも開発者への影響を遮断する設計変更でスループットを回復させた実践的な取り組みを詳しく紹介している。「mainが壊れる」と聞くと重大インシデントを想起しがちだが、後述するStowPipeの仕組みにより開発者が参照するポインタは常に安全な位置に保たれる点が重要だ。
AIコードがSubmitQueueを壊した
Uberの開発者プラットフォームでスタッフエンジニアを務めるPreetam Dwivediは、AI Engineerで次のように語った。2026年1月に毎時90リクエストだったSubmitQueueへの負荷が、3月には毎時130リクエストへと44%増加した。その主因はAIが書いたdiff（差分）の急増だという。
ここで言う「毎時90→130リクエスト」はSubmitQueue（マージ前の検証キュー）に投入されるPR数の増加を指す。後述するスループット指標「lands/h」とは単位が異なり、こちらはキューへの流入量、lands/hは実際にmainへのマージが完了した件数を表す。流入が増えても処理が追いつかなければスループットは下がる、という因果関係を念頭に置いて読むと数字の意味が整理しやすい。
その結果、PRのP95ランドタイム（マージ完了までの時間）は30分から3〜4時間に悪化した。トランクは緑のまま。でも開発者は詰まっていた。
Uberのスケールを念のため整理しておくと、5,000人超の開発者が週36,000コミット・27,000 PRを6つのモノレポに投入している。言語はGoが中心で、並列ビルドのスケールが特に難しいという。
人間時代の3つの工夫が通用しなくなった
Dwivediによれば、AI以前の時代は以下の3つの最適化でSubmitQueueを維持していた。
- ターゲット分析：依存関係が重複しないビルドを並列実行する
- 確率的投機実行：マージ成功確率の高いビルドを先に走らせる
- バイパス：小さな変更が大きな変更の後ろに詰まらないようジャンプさせる
AIが大量の差分を生成するようになると、これらの前提が崩れた。変更の量と多様性が増しすぎて、既存の最適化が効かなくなったのだ。
「入場制限」と「後回しキュー」で130→160 lands/h
シニアエンジニアのManjari AkellaはAIボリュームへの対応として2つの施策を実装した。
アドミッションゲーティングは、変更の「重さ」を判定して高コストな変更をピーク時間帯に受け付けない仕組みだ。これによりビジネスアワーのスループットは毎時130→約160ランドに改善した。
ディファーラル（deferred queue）は、弾かれた変更を別キューに保持し、キャパシティが空いたタイミングで再試行する仕組みだ。リジェクトを捨てずに再利用することで、無駄な再サブミットを減らす。
本命は「コンフリクト緩和」：ピーク250〜300 lands/h、P95を30分に復元
ここが記事の核心だ。
通常のSubmitQueueはコードの重複（コンフリクト）があるPRを直列にキューイングする。AkellaのチームはJaccardSimilarity（ジャッカード類似度） でコンフリクトを0〜1のスコアとして定量化し、スコアが低い（＝実質的に重複が薄い）組み合わせはコンフリクトなしとみなして並列レーンに流す「コンフリクト緩和」を実装した。
Jaccard類似度とは、2つの集合の「共通要素の割合」を測る指標。ここではPR同士が触るファイル・パッケージの重複度合いを0（完全に別物）〜1（完全に同一）で表す。
この緩和によりピーク時で毎時250〜300ランドを達成し、P95ランドタイムも30分まで戻った。
ただし「mainが壊れる」コストを払っている
問題はトレードオフだ。Akellaはこれを率直に認めている。スコアの低い組み合わせでも、実際には干渉が起きることがある。その場合、テストが通っていない状態でmainにコードが入る。
これに対応するのがStowPipeという仕組みだ。ランド後にバリデーションを非同期で走らせ、「検証済みmainポインタ」をビルドが通過するまで前進させない。開発者がビルドやテストの基点として参照するのはこのポインタであるため、mainのHEADが実際に壊れていても、開発者の手元には影響が出ない設計になっている。いわば「壊れたHEADと開発者の間にバッファを挟む」構造だ。
StowPipeはUber内製の仕組みであり、一般的なOSSとしては公開されていない。概念的にはFeature FlagsやContinuous Deliveryにおける「リリースゲート」に近い発想で、コミットの物理的な存在とそれを「有効」とみなすタイミングを切り離す点が特徴だ。
要するに「mainは壊れていいが、開発者に悪影響が出るまでにフォールバックを挟む」という割り切りである。これはトランクベース開発の一般的な哲学（mainは常に緑）から意図的に外れた判断と言える。
AIコード時代のCI設計が問い直すもの
Uberの事例が示すのは、AIコーディングツールの普及がCIパイプラインの設計前提を崩しうるという現実だ。人間のペースに合わせて設計されたSubmitQueueは、AIが毎時数十件の差分を追加生成し始めた瞬間にボトルネックになった。
Uberが取った答えは「mainの完全性を諦めて速度を取り、後から検証で補う」という構成だった。130→300 lands/hという数字と引き換えに得たのが、mainが壊れるリスクを受け入れる設計変更だ。ただしそのリスクはStowPipeによって開発者から遮断されており、「壊れることを放置する」のではなく「壊れることを制御する」という姿勢が貫かれている点は強調しておきたい。
詳細はUber let trunk break to ship AI code fasterを参照していただきたい。
