Uber のマルチエージェントコードレビューエンジン「uReview」を構築

Uber のコードレビュー革命：9 時間の待ち時間を 60% コスト削減で解決した「uReview」の全貌

Uber は、ソフトウェア開発組織における PR（プルリクエスト）数の急増により、コードレビューに最大 9 時間もの待ち時間が発生する深刻なボトルネックに直面していました。この課題を解決するため、同社は Fabricator や GitHub に対応し、数百のチームが持つ独自ルールも反映可能な社内独自のマルチエージェントシステム「uReview」を構築しました。

本記事では、Uber がどのようにしてコストを 60% 削減しつつ精度を 70% 向上させたのか、その技術的アプローチと開発パラダイムの転換点について解説します。

コードレビューのボトルネックと独自システムの必要性

Uber のソフトウェアエンジニア組織は、12 カ所にまたがる数千名のエンジニアが数百チームで構成されています。彼らは主に 6 つの言語別モノレポで開発を進めていますが、過去 24 ヶ月間で PR の数と規模が急増しました。

その結果、レビュー待ち時間（First time to review）は 2024 年の平均 3 時間から、2026 年には 9 時間にまで延びてしまいました。これによりコードレビューが開発速度の足かせとなっている状況です。

業界には既存の自動化ソリューションが存在しますが、Uber は以下の理由から独自システム「uReview」の開発を選択しました。

「数百ものチームに共通のルールを中央管理で押し付けることは不可能だ。各チームの所有権システムに組み込み、セキュリティとコンプライアンスの一貫性を保ちつつ、柔軟なカスタマイズを実現する必要がある。」

特に重要な制約として、長年使用してきた Fabricator への対応（現在は GitHub 移行中）があり、既存のサードパーティ製ツールでは対応しきれない部分が多かったことが挙げられます。また、エージェント開発ライフサイクル（Agentic SDLC）において、人間が行うレビューと AI エージェントが適用するルールを同一化し、「内側ループ」での一貫性を確保する必要がありました。

分散型カスタマイズ：数百のチームが持つ「独自ルール」をどう扱うか

uReview の最大の特徴は、単一のモデルで全てのレビューを行うのではなく、各チームの特性に合わせた分散型カスタマイズを実現している点です。

Uber には数百ものチームがあり、それぞれ独自のスタイルガイドやコーディングパターンを持っています。これを一元管理することは非現実的であるため、uReview は以下のような仕組みを導入しました。

1. コード隣接での設定管理

開発者がコードを書く場所（リポジトリ内）に、そのチーム固有の設定ファイルを配置できるようにしています。これにより、ルールの変更が即座に反映され、管理コストを大幅に削減しています。

2. カスタムエージェントの定義

各チームは、過去の PR やナレッジベースを参照して独自の「カスタムエージェント」を定義できます。具体的には以下の 4 つのレイヤーで構成されています。

• シングルファイルレビュアー: ファイル単位のロジックバグを検出する汎用的なレビュー。
• マルチファイルレビュアー: モノレポ特有のアンチパターンやスタイルガイドを深く理解するための広範なレビュー。
• AI リンター: 少数の例（few-shot）を用いて、体系的で機械的な問題を検出するルールベースの機能。
• カスタムエージェント: チームがナレッジベースや過去の PR をリンクさせ、独自のスキルを持つエージェントを構築できる最も強力な機能。

「スキルを書くこと自体は簡単だ。チームは Claude などの AI に過去レビューを見てルールを書いてもらうだけで済む。問題は、それを大規模に、かつ低コスト・高品質で実行する仕組みを作ることだった。」

観測性と評価による最適化：モデルの「自信過剰」をどう補正するか

uReview の初期段階では、単一のプロンプトと簡単なディスパッチャーしか存在せず、収集できるデータもコストや NPS（ネットプロモータースコア）調査といった表面的なものに限られていました。その結果、品質対コストの比率は不安定な状態でした。

これを改善するために、Uber は観測性（Observability）と評価（Evaluation）データを徹底的に収集・分析する体制を整えました。

収集した重要なデータポイント

1. 開発者の感情分析: uReview のコメントに対する返信のトーンを「ポジティブ」「ネガティブ」などに分類し、開発者がどのフィードバックを価値あると感じているかを可視化しました。
2. 対応率（Address Rate）: コメントが提出された後、実際に開発者がその指摘に対応した割合を追跡しました。全体の対応率は約 67% に達し、重大な問題の 3 分の 2 が修正されるなど、実質的な価値があることが証明されました。
3. エージェントの思考プロセス（トランジトリ）: エージェントがどのようなツールを呼び出し、どの思考ステップを経て結論に至ったかを記録しました。

モデルのバイアス補正とガードレール

データ分析から得られた重要な知見は、「モデルは自分が間違っていることに気づいていない」という事実です。AI は常に 100% の自信を持ってコメントを出しますが、実際には各チーム固有のスタイルガイドやパターンを無視しているケースが多発していました。

この課題に対し、以下の対策を講じました。

• ガードレールの導入: エージェントが時間のかかる無意味な作業に時間を費やさないよう、行動範囲を制限するルールを設定しました。
• ランタイムのチューニング: エージェントの思考プロセスデータを元に、より迅速かつ高品質な結果を低コストで出力するように調整を行いました。

これらの取り組みにより、ナイーブ（素朴）な実装と比較してコストは 60% 削減され、精度と品質は約 70% 向上しました。現在、uReview は週に約 25,000 件のコメントを生成し、そのうち 10% がフィードバックを受け、ネガティブなフィードバックを受ける PR はわずか 4% に抑えられています。

AI エージェント時代への移行：人間の役割は「外側ループ」へ

コードレビューの自動化が進む中、Uber は開発者の役割の変化についても明確なビジョンを示しています。

従来の「人間による詳細な実装レビュー」から、「アーキテクチャやドメイン知識に注力する外側ループ」へのシフトが加速します。AI エージェントはコードの生成と細かい修正（100 件のニットの修正など）を自動で行うようになりますが、人間のエンジニアはそれらの詳細な実装から解放され、より高次元の設計判断やドメイン固有の知識に集中できるようになります。

「人間がループから外れることで、ソフトウェア開発体験全体が向上する。ただし、そのためには AI の精度を高めることが不可欠だ。精度が低いと、AI が直した後にまたレビューが必要になり、逆方向への修正を迫られる『キャビテーション』現象が発生してしまう。」

まとめ

Uber の uReview は、単なるコードレビューの自動化ツールではなく、大規模組織における AI エージェント導入の成功事例です。分散型のカスタマイズと、開発者フィードバックやエージェントの思考プロセスを活用した観測性データの最適化が、コスト削減と品質向上に直結することを示しました。

今後は、人間が実装の詳細から離れ、アーキテクチャやドメイン知識という「外側ループ」へ役割をシフトさせる開発パラダイムへの転換が、業界全体で加速していくでしょう。