10月15日、The Pragmatic Engineerが「Uber's AI infra, from the inside」と題した記事を公開した。UberのDistinguished EngineerであるUday Kiran Medisettyが、同社のAIエージェント基盤を支える内部開発ツール群の実態について詳しく語っている。

「1年で作った」ように見えるAI基盤の正体

記事の核心はここだ。Uberの2025年製AIツール群は、一見すると生成AI登場後に急ごしらえしたように映る。しかし実際は、2010年代から10年かけて積み上げた開発者向けインフラの上に構築されている。

例えば、AIエージェントを動かすための実行環境「Minion」（2025年構築）は、2017年に開発されたクラウドベース開発環境「DevPods」の上で動作する。MCP（Model Context Protocol）ゲートウェイ——AIエージェントが内部サービスを呼び出すためのインターフェース規格——の構築が速かったのも、既存のThriftおよびProtobufレジストリ——いずれもサービス間の型付きAPIを定義するIDL/シリアライゼーションフォーマット——が整備されていたからだ。分散トレーシングツールJaeger——マイクロサービス間の処理の流れを可視化するオブザーバビリティツール——があったため、エージェントのルーティング機構「Slate」やコンテキストグラフの構築も容易だった。

さらに、Uberが外部ベンダーでは要件を満たせず自社開発したシステムも、この「10年の積み上げ」の一部をなしている。毎秒5億メトリクスという負荷に対応できるベンダーが存在しなかったため自社開発した時系列DB「M3DB」はオープンソース化後、オブザーバビリティ企業のChronosphereがこの上に構築された。ドライバーのオンボーディングのような数日にわたるフローを扱うワークフローエンジン「Cadence」はオープンソース化後にTemporalが誕生した。フィーチャーフラグと実験基盤を統合した「Morpheus」は、Uberが運営するような両面・三面市場向けのスイッチバックテスト——需要側と供給側が相互に影響し合う市場で、通常のA/Bテストでは制御群が汚染されるため、時間帯や地域を交互に切り替えながら実験する手法——をサポートする。これらのツールはAI基盤の直接の構成要素ではないものの、大規模サービスを長年運営してきたUberが「AIエージェントにとっても機能する基盤」を持てた背景として記事で紹介されている。

Udayはこう語る。

「エンジニアの生産性を高めるために作ったものすべてが、エージェントにとっても同様に機能する」

これはUber固有の話でもあるが、「AIネイティブな開発基盤をゼロから作ろうとしている組織」への示唆でもある。

モデル非依存のゲートウェイ設計が鍵だった

2023年時点でUberのプラットフォームチームが下した決断が、その後の展開を大きく左右した。「AIを使って構築するものはすべてモデル非依存かつハーネス非依存にする」という方針だ。

この方針のもとで開発された「Model Gateway」は、Anthropic・OpenAI・オープンソースモデルを統一的に扱うインターフェースを提供する。このゲートウェイには以下の機能が追加されている：

• AI Guard：セキュリティチームが管理するミドルウェア。全リクエスト・レスポンスを検査し、応答が遅すぎるモデルやクエリをフラグ立て
• Spend Tracking：ユーザー単位でトークンコストを追跡
• Visibility：監査ログとセッショントレース

また、エンジニアが使うAIコーディングハーネス（Claude Code、Codex、OpenCode）を切り替えても設定・スキル・プラグインが引き継がれる「AIFX（AI Foundations）」というラッパーも整備されている。ツールを乗り換えるたびに設定をやり直す手間がなくなる。

トークンコストを50%削減した「使いすぎない」設計

AIツールの社内展開で頭を悩ませるのが、青天井になりがちなAPIコストだ。Uberのアプローチはシンプルで現実的だ。

エンジニアにはSpend Tier（消費枠）が割り当てられ、上限に達したらマネージャーの承認で追加できるという仕組みにしている。「正当な業務なら上限なし、しかし無駄遣いは抑制する」という設計思想だ。さらに「CostCheck」というプラグインがセッション横断でコスト状況を監視し、改善アドバイスを提供する。

この取り組みの結果、直近数カ月でトークンコストを約50%削減することに成功している。

CIが「コードレッド」に陥った話

2025年初頭、UberのCI（継続的インテグレーション）システムは社内で「コードレッド」が宣言される事態に陥った。AIエージェントによるPR生成が急増した結果、CIジョブが12カ月で2倍以上に膨れ上がり、システムが過負荷状態になったためだ。

対応策として、リント・ビルド・テンプレートルールといった軽量なCIジョブを「インナーループ」に移動した。具体的には、エージェントがPRを開く前にafx validateコマンドでこれらを実行するよう変更している。AIが大量のPRを生成できる環境では、CI設計の見直しが必須になるという事例だ。

PRの「種類」で生産性を測り直す

Uberはこれまで「PR Velocity（PRが本番環境に到達するまでの時間）」を生産性指標の一つとして使ってきた。しかしエージェントが数十・数百のPRを生成できる環境では、この指標は意味をなさなくなった。

そこでUberは全PRを以下の5種類でタグ付けするようにした：

• Feature（機能追加）
• Bugfix（バグ修正）
• Maintenance（保守）
• Testing（テスト）
• Docs（ドキュメント）

現在、「Feature PR」の割合が増加し、「Maintenance PR」の割合が減少する傾向が見えているという。AIを導入してもビジネス価値につながる変化が起きているかどうかを、こうした分類で追跡している。

エンジニアに求められるスキルの変化

Udayはエンジニアの役割変化についてこう語る。

「エンジニアリングの仕事は、ある意味『エージェントが信頼できる出力を生成するための正しいコンテキストをどう作るか』になっている。コンテキストエンジニアリングが非常に重要になった。また、マルチタスク能力も必要になった。以前はPRを一つ作るのに多大な時間がかかったので、そこに集中できた。今は常に多くのことを並行して進め、エージェントの出力を検証し、リグレッションを本番に送り込まないためにコードの問題を嗅ぎ取る必要がある」

コンテキスト構築・マルチタスク・出力の検証と品質確認。この3つがAI時代のエンジニアに求められるスキルとして挙げられている。

詳細はUber's AI infra, from the insideを参照していただきたい。