,
supateam プロダクト責任者の若月です。
直近、AIレビューを導入する企業が増え、その有用性についても様々な議論が盛り上がっています。
今回はUberにおいて、人間のレビューよりも対応される独自のレビューエージェントを構築し、
週65,000件のAIレビュー及びエンジニアからの75%という高い有用性評価を得ているという事例についてまとめました。
元記事：uReview: Scalable, Trustworthy GenAI for Code Review at Uber
AIレビュー導入のアンチパターン - 対応されない大量のAIレビュー
よくあるチームへのAIレビュー導入のアンチパターンとして、
不十分な設定でAIレビューエージェントを導入し、的外れなAIレビューが増加し、 オオカミ少年効果を引き起こしさらにAIレビューが見られなくなり、メンテナンスされ無くなるといった負のループの発生が挙げられます。
一方でUberではレビュー精度にフォーカスし、
人間のレビューよりも有用なAIレビューを独自に構築した「uReview」という内製システムを構築しており、
AIレビューの対応率（インラインコメントの対象コード行がその後outdatedになった率としてsupateamでも計測可能）や エンジニアからの有用性評価について観測し、その精度を評価しています。
AIのコードレビューコメントは、人間より「対応される」── UberのuReview事例から学ぶ精度優先設計
AIコーディングツールの普及によって開発速度は大きく上がりました。一方で、レビュー側の課題についてはあまり語られていません。
AIが生成したコードは、人間が書いたコードと比べて「論理エラーが1.75倍・XSS脆弱性が2.74倍」含まれるというデータがあります。コーディングを加速するほど、レビューの質がより重要になります。しかしレビュアーのリソースは有限であり、PRの量だけが増え続けるという状況が多くの組織で起きています。
Uberは2025年8月の、この問題への取り組みとして内製AIコードレビューシステム「uReview」の詳細を公開しました。
発表時点で週65,000件以上のコードdiffをAIがレビューし、エンジニアの有用性評価75%以上を維持していると記載されています。
この事例でとくに注目すべきは、AIのコメント対応率が人間レビュアーを上回ったという点です。
uReviewとは
- Uberが内製したAIコードレビューシステム（2025年8月に詳細公開）
- 週65,000件以上のコードdiffをカバー（カバレッジ90%以上）
- Go・Java・Android・iOS・TypeScript・Pythonの6つのモノレポにまたがる
- エンジニアの有用性評価75%以上、コメント対応率65%以上を維持
Uberのエンジニア規模を考えると、週65,000件というのはほぼ全てのコード変更をAIがレビューしている状態に近いといえます。
なぜサードパーティを使わず内製したか
uReviewを構築する前に、Uberは市場のAIコードレビューツールを一通り評価しましたが、結果として全て見送ることになりました。
その理由として以下の3つが挙げられています。
① GitHubが前提のツールが多い UberはPhabricatorをコードレビュー基盤に使用していたが、 GitHub連携が前提のサードパーティツールはそもそも導入できなかった。
② 品質が基準に達しなかった 実際に評価すると偽陽性が多く、低品質な真陽性が目立ちました。 加えてUber固有のコーディング規約や内部ドキュメントとの連携ができず、実用に耐えるものではありませんでした。
③ コストが合わない 週65,000件の規模でサードパーティを動かすと、自前運用より1桁高いコストになることがわかりました。
これらの理由から、内製という選択に至っています。
4段階パイプラインの設計
uReviewは「コードレビュー」という複雑なタスクを4つのサブタスクに分解しています。
パイプラインのDAG構造（出典：Uber Engineering Blog）
① 前処理 設定ファイル・自動生成コード・実験ディレクトリを除外します。
LLMに渡す前にノイズを最初に取り除くことで、レビュー精度を高めています。
② コメント生成 3つの専門アシスタントが並列で起動し、コメントを生成します。
| アシスタント | 担当 |
|---|---|
| Standard | バグ・例外処理の誤り・ロジックの欠陥 |
| Best Practices | Uber固有のコーディング規約（社内共有レジストリ参照） |
| AppSec | アプリケーションレベルのセキュリティ脆弱性 |
3つを独立したアシスタントとして分けた理由としては「それぞれを個別に評価・改善できるから」とUberは説明しています。
1つの巨大プロンプトに全てを詰め込むより、役割ごとに切り分けたほうが品質管理がしやすくなります。
③ 品質のフィルタリング 生成したコメントをそのまま出力するのではなく、
信頼スコアリング・セマンティック重複排除・カテゴリ分類という多層フィルタを通します。
このステップが品質と開発者の信頼を維持するための核になっています。
④ 配信とフィードバック収集 エンジニアの評価データを継続的な改善に反映するループを持ちます。運用を続けるほどシステムの精度が向上していく設計です。
偽陽性との戦い
uReviewの構築において最も難しかったのが、偽陽性の管理だとしています。
Uberはその種類を2つに整理しています。
タイプ1：LLMのハルシネーション 事実として間違っているコメントです。存在しないメソッドを参照したり、コードの動作を誤解釈して生成されます。
タイプ2：コンテキスト不適切 技術的には正しいものの、今のコードには関係ない指摘です。過去のPR・DBスキーマ・フィーチャーフラグ・技術ドキュメントにアクセスできないため、ローカルなコードしか見えないことで生じます。
Uberはこの問題に対して、一貫した原則を持って設計を進めました。
開発者の信頼は稼ぐのは難しく、失うのは簡単。
私も冒頭で記載しましたが、ノイズを出し続けるとツールは使われなくなります。 そのため、uReviewは精度を最優先とする設計になっています。
削ったカテゴリ、残したカテゴリ
開発者フィードバックを分析すると、評価の分かれ目は明確でした。
❌ 低評価のため出さないようにしたもの - 可読性の細かい指摘（nits） - ちょっとしたログの修正提案 - スタイルの好みの問題
✅ 高評価のため残したもの - 正確性のバグ - エラーハンドリングの欠落 - 内部ドキュメントへのリンクつきのベストプラクティス指摘
高評価カテゴリの例：メトリクス計算のロジックエラー指摘（出典：Uber Engineering Blog）
コメントの絶対数は減りましたが、開発者に実際に使われるシステムになりました。
結果：AIのコメント対応率が人間を上回った
精度優先設計の結果として、注目すべき数字が出ています。
| コメント対応率 | |
|---|---|
| 🤖 uReview（AI） | 65% |
| 👤 人間レビュアー | 51% |
51%という数字は、内部監査でUberが初めて計測した「人間レビュアーが自分のコメントを実際に対応する率」です。
AIシステムを設計するために人間のベースラインを数値化したことで、副産物として明らかになりました。
AIのコメント対応率が人間を上回った背景には、モデルの性能よりも「対応される確率が高いコメントだけを出す」という設計の徹底があります。
あわせて、システム全体での節約効果は週1,500開発者時間（年換算で39年相当）に達しています。
モデル構成
最終的に採用したモデルの組み合わせは以下のとおりです。
| 役割 | モデル |
|---|---|
| コメント生成 | Anthropic Claude 4-Sonnet |
| 品質評価（グレーダー） | OpenAI o4-mini-high |
全テスト済みの組み合わせの中でこのペアがF1スコア最高となったとのことです。
※ 2025年8月の事例のため、現在利用されているモデルは変更されている可能性が高いです。
生成と評価では求められる能力が異なるため、タスクの性質に応じてモデルを使い分けるアーキテクチャが選ばれています。
段階的な導入
uReviewは全社に一気に展開したわけではありません。1チーム・1アシスタントずつ展開し、各フェーズで精度・リコール・コメント対応率・偽陽性数を計測しながら進めました。
問題があれば次のフェーズに進む前に修正する、という方針を徹底しています。一気に全社展開してノイズが多い状態になれば「こういうもの」という印象が定着しかねません。開発者の信頼を最優先にした展開順序といえます。
AIコーディング時代のレビュー品質という課題
uReviewの事例は、AIコーディングが活発な組織ほど参考になる内容を含んでいます。
AIが書いたコードには前述のとおり品質リスクが伴います。コーディングの速度が上がるほど、そのリスクが積み重なっていきます。レビューがそれに追いつかなければ、手戻りの頻度が上がり、本番障害が増えることになります。
Uberが示したのは「AIがコードを書く時代のレビューをどう設計するか」という問いへの一つの実践例です。その答えは「AIをもっと使う」ではなく「AIの出力をどう絞り込み、開発者の信頼を維持するか」という方向でした。
こうした施策の効果を継続的に把握するためには、手戻りPR率・レビューサイクル数・AI起点の障害率といった指標を定点観測する仕組みが重要になります。supateamでは、これらの指標をチーム別に可視化し、AIコーディングが活発なチームにおける品質面のリスクを早期に検出できます。
まとめ
- uReviewはサードパーティ製品の課題（GitHub前提・品質・コスト）を背景に内製されたシステムです
- 「量より精度」を徹底した設計の結果、AIのコメント対応率（65%）が人間レビュアー（51%）を上回りました
- AIコーディングが加速する今、レビュー品質の設計とその効果計測は、多くの技術組織にとって重要な課題になっています
supateamについて
supateamは、AI時代の開発組織を支援する開発生産性ツールです。
チーム・メンバー・AI活用（現在注力中）の3軸でデータを可視化し、「今、何が起きているか」を定量的に把握できるようにします。
本記事のテーマに関連する指標として、変更のリードタイム・PRの平均レビュー数・変更障害率といったFour Keys指標や、
AIコーディングツールの活用状況・AI起点の手戻りPR率を計測できます。uReviewのような施策を導入した際の効果を定点観測するためのダッシュボードとしてご活用いただけます。
参考リンク - uReview: Scalable, Trustworthy GenAI for Code Review at Uber
