配達とモビリティ / 配車と配達
Uber：ソフトウェアのコードレビュー
- 企業
- Uber
- 国
- 米国
- 導入状況
- 運用中
- 資料公開
- 日付の基準
- 資料が公開された時点。導入を開始した日とは異なる場合がある。
- 根拠の確認方法
- 原文の本文を閲覧
業務課題
AIがコードの作成を助けるようになり、レビューすべきコードの量が増えた。レビューする側は、微妙なバグとセキュリティの問題を見つけ、社内の規則を守る時間が足りなかった。Uberはこの限界が、見落とした誤りと運用の障害、遅れた配布につながると見た。
使った技術とデータ
uReviewの中心は、いくつもの段階に分かれた生成AIのレビューシステムCommenterである。変わったコードに、周りの関数、クラスの定義、import文を一緒に入れたプロンプトを作る。レビューは三つの流れに分かれる。Standard Assistantはバグと誤った例外処理、論理の欠陥を探す。Best Practices Assistantは共用のスタイル規則の保管庫を参照して社内のコーディング規則を確かめる。AppSec Assistantはアプリケーションの水準のセキュリティ脆弱性を見る。作られた意見は別のプロンプトが品質を評価して信頼度の点数を付け、重なる意見は合わせる。モデルは、Anthropic Claude-4-Sonnetが意見を作り、OpenAI o4-mini-highが採点するときが最も良かった。開発者は意見ごとにUsefulまたはNot Usefulを選び、メモを残す。
成果
Uberは、uReviewが週におよそ65,000件のdiffのうち90%を超えて分析すると述べた。毎週10,000件を超えるコミットを処理する。道具を使ってみたエンジニアは意見の75%を有用だと表示し、掲示された意見の65%を超えて反映された。Uberはこれを週あたり約1,500時間の節約と計算し、年間で39 developer yearsに近いと説明した。社内の監査では、人が書いた意見は51%だけを作成者がバグと認め、同じ変更で直した。
限界と残る課題
uReviewはコードだけを見ることができ、過去のPR、feature flagの設定、データベースのスキーマ、技術文書にはアクセスできない。全体の設計が正しいかどうかは判断できない。
出典
公開資料をまとめた事例です。ATF Works導入企業の成果ではありません。