# Running a Software Factory Efficiently at Uber Scale Navigation: [[sources/_index]] | [[index]] ## 概要 [[Uday Kiran Medisetty]] が Uber における「ソフトウェアファクトリー」の運用とコスト最適化を説明した記事である。AI エージェントを個々の開発者が対話的に使う段階から、コード生成・検証・デプロイ・観測・保守を専門の管理エージェントが担う段階へ移行し、その成果をコスト・品質・信頼性で測る考え方を示す。 Uber の報告では、2026年2月から8月にかけて週次アクティブユーザーが7倍、週次エージェントリクエストが9.4倍に増えた。モデルを固定した比較では、1,000リクエスト当たりコストがピーク比で約34%、セッション当たりコストが6月のピーク比で52%低下した。利用量の拡大と単位コストの低下を、不要なトークン消費を削る工学的課題として同時に扱っている。 ![[_attachments/efficient-software-factory-2026-08-27/fig01-adoption.jpg]] （図1。2026年2月から8月にかけて、週次アクティブユーザーが7倍、エージェントリクエストが9.4倍に増えた推移を示す。） ## セッションが存在する4層 Uber は AI 利用を、専門性が高い順に次の4層へ整理する。上位層ほどコスト・品質・モデル選択を制御しやすい。 1. **専門管理エージェント**: Minion は意図からPR、uReview はPRからコードレビュー、Agentic XP は完了したXPから振り返り、Conan AI はアラートから AI 根本原因分析、Fawkes はスケジュール実行から保守を担当する。 2. **汎用エージェント**: Cortana はスキルを指定するだけで、初期設定なしに Uber のクラウド上でタスクを実行する。 3. **スキル付きセッション**: 開発者のローカル環境で、3,600を超えるスキルを利用する。 4. **生のセッション**: Claude Code、Codex、OpenCode に開発者がプロンプト・コンテキスト・指示を与える。 専門管理エージェントでは、狭いタスクを明確な成果単位へ結び付ける。これにより、PRのマージ、レビュー、アラート処理、保守作業といった成果ごとのコストを比較できる。 ![[_attachments/efficient-software-factory-2026-08-27/fig03-agent-layers.jpg]] （図3。専門管理エージェントから生の対話セッションまでの4層と、各層で追跡する成果単位を示す。） ## 支出の分解 エージェントセッションの総支出を次の積として表す。 **ユーザー数 × ユーザー当たりセッション数 × セッション当たりターン数 × ターン当たりリクエスト数 × リクエスト当たりトークン数 × トークン単価** ユーザー数とユーザー当たりセッション数は、拡大させたい導入・関与の項である。残る項は、開発者の依頼に加えてエージェントが自律的に行う作業量と単価であり、最適化対象になる。モデル選択はトークン単価を下げるだけでなく、品質と信頼性を含む成果当たりコストで評価する。 ![[_attachments/efficient-software-factory-2026-08-27/fig04-cost-equation.jpg]] （図4。支出を導入・関与、エージェント軌跡、単位価格の積として分解する考え方を示す。） ## 測定体系 ポートフォリオ全体では、帰属コスト、重複を除いた利用者数、ツール・エージェントごとのコストと支出比率を追跡する。ツール単位では、ユーザー当たりコスト、ユーザー当たりリクエスト、1,000リクエスト当たりコスト、入出力トークン、100万トークン当たりコスト、1,000セッション当たりコスト、アクティブセッション時間当たりコスト、プロンプトキャッシュヒット率を測る。 モデル単位では、コストとリクエストの比率、1,000リクエスト当たりコスト、100万トークン当たりコストを比較する。コスト変化は、導入、ユーザー当たりリクエスト、リクエスト当たり入力トークン、リクエスト当たり出力トークンへ順番に分解し、説明不能な残差を残さない。 管理エージェント単位では、成果当たりコスト、品質指標、処理量を測る。品質指標の例はリバート率、F1、MTTRであり、処理量の例はマージ済みPR、投稿レビュー、処理済みアラートである。 ## モデル選択 Uber は管理エージェントの実作業からベンチマークを作り、同一のハーネスから最先端モデルとオープンウェイトモデルを実行する。コスト、完了タスク当たり品質、モデル信頼性のパレート前線上にあるモデルを採用し、モデル世代の更新に応じて選び直す。 uReview では、既知のバグを含む実際のPRを難易度別にベンチマーク化し、バグに対する適合率・再現率・F1、レビュー当たりコスト、遅延、タイムアウト、ノイズを評価する。さらに [[Uber SWE Benchmark]] で大規模モノレポの実PRを使い、タスク種別ごとに複数モデルを比較する。 ![[_attachments/efficient-software-factory-2026-08-27/fig05-model-frontier.jpg]] （図5。uReview ベンチマークで、レビュー当たりコストとF1のパレート前線を比較する。） 対話インターフェースでは、初期セッションモデルとサブエージェントモデルの既定値によってトークン配分を制御する。サブエージェントは限定された作業を担うため、最先端モデルを必要としない場合は、より安価なモデルを既定にする。主モデルはタスク分解と評価を担い、サブエージェントが実作業を行う。 ## リクエスト当たりトークンの削減 各ターンでは会話履歴、プロジェクトコンテキスト、ツール結果が再送される。Uber は1Mトークンのコンテキストウィンドウを持つモデルでも400Kトークンで自動圧縮し、推論の強度をMediumにする。これは品質とのバランスを保ちつつ、入力・出力トークンを削減する設定である。 プロンプトキャッシュでは、キャッシュ読み出しが通常の入力単価の0.1倍になる一方、書き込みは5分TTLで1.25倍、1時間TTLで2倍になる。開発者の対話セッションは5分を超えて中断することが多いため1時間TTLを使い、短時間で終わるサブエージェントには5分TTLを使う。 ## MCPツールの動的実行とコードモード Uber は1,000を超える内部・SaaS MCPサーバーを単一ゲートウェイの背後に置き、認証とポリシー適用を集約する。すべてのツールスキーマをセッションへ事前ロードすると、初期プロンプトだけで約50K〜70Kトークンを消費する。 そこで、ゲートウェイのツールをCLIコマンドとして公開し、呼び出し時に必要なツールだけを動的解決する。ツール検索も必要な定義だけをオンデマンドで読み込む。コードモードでは、モデルが複数のツール呼び出しとポーリングをスクリプトへまとめ、モデルのコンテキストには最終的な要約だけを返す。 同一セッションで5種類のSQLクエリを比較したところ、コードモードは小さな結果でもトークン数を55%〜71%削減した。広いテーブルへの問い合わせでは、通常の1,431,594トークンに対して900トークンとなった。Uber は頻繁に使うMCPサーバー向けに25以上のコードモードスキルを用意している。 ![[_attachments/efficient-software-factory-2026-08-27/fig08-code-mode.jpg]] （図8。通常のMCPツール利用ではポーリングと生の応答が各ターンに入るが、コードモードではループをモデル外で実行し要約だけを返す。） SaaS MCPは単一製品の機能を広く公開するため、ワークスペース製品の49ツールで約22Kトークン、メッセージング製品とプロジェクト追跡製品の34・46ツールで大きなスキーマ負荷が生じる。ゲートウェイ、CLI、専用スキルを組み合わせることで、この負荷を抑える。 ## コンテキスト接地 [[AI Context Graph]] は、サービス、チーム、インシデントログ、PR、設計文書、デプロイ、データセット、テーブル利用履歴など30超の内部システムを統合する。24Mノード、80Mエッジ、86種類のノード、117種類のエッジを持ち、エージェントが自然言語で照会できる。 Vehicle Lists in Forge の問い合わせでは、グラフ接地したエージェントが過去の利用履歴から53人のアナリストが使うテーブルを特定し、38秒で正しい回答を得た。グラフなしでは、エージェントはサービスコードを20分間調査し、2つのサブエージェントを起動し、3回のエラーを経て、照会不能だと誤判定した。 ![[_attachments/efficient-software-factory-2026-08-27/fig10-context-graph.jpg]] （図10。同じモデルへの同じ質問でも、コンテキストグラフの有無で38秒の正答と20分超の誤答に分かれることを示す。） ## 可視化と教育 ハーネスのステータスラインには、セッション単位とユーザーの全ハーネス合計のライブコストカウンターを表示する。対話ハーネスには共有の支出ティアを設け、管理エージェントには別のティアを用意する。予想支出の50%、80%、100%でSlack通知を送り、ティアの引き上げは管理者承認とする。 セッション分析ダッシュボードは、ローカルとクラウドのセッション痕跡を調べ、16種類のアンチパターンを金銭的影響と修正策に結び付ける。最適でないモデルルーティング、MCP応答によるコンテキスト肥大化、キャッシュ期限切れ、初期プロンプトの過剰なシステム指示・ツール定義が例として挙げられる。 ## 横断的な位置づけ この記事は、[[エージェントシステム運用]] が扱う信頼性・制御可能性に、コストと成果の測定軸を加える事例である。[[Model Context Protocol]] の動的解決とコードモードは、ツールの機能を減らすのではなく、セッションへ持ち込むコンテキスト量とターン数を減らす設計として位置づけられる。[[開発者生産性]] の観点では、単なる利用量ではなく、レビュー・復旧・保守などの成果単位と品質を同時に測る点が重要である。 新しい管理エージェントを追加する際は、成果指標を定め、実作業ベンチマークを作り、パレート最適なモデルを選ぶ。今後はモデルルーティング、コンテキストグラフの適用範囲、リアルタイムの開発者向け助言、スキル実行の痕跡からの自動改善を拡大する。 ## 注意点 - 数値とコスト削減率は Uber の環境、ワークロード、モデル構成に依存する。記事も、手法は一般化できるが、削減幅はコードベース・チーム規模・ワークフローによって変わると明記している。 - モデル比較は、採用したベンチマーク、品質指標、価格体系、信頼性定義に依存する。パレート前線上の選択が他組織の最適解になるとは限らない。 - 記事は Uber 内部の実装を紹介する技術記事であり、AI Engineer 2026 で共有した構想の詳細や全図表データを公開しているわけではない。 ## 出典 - [[.raw/articles/efficient-software-factory-2026-08-27.md]] - Uber, “Running a Software Factory Efficiently at Uber Scale”, Uday Kiran Medisetty, 2026-08-27, https://www.uber.com/cy/en/blog/efficient-software-factory/