Uberに見るAIエージェントの運用コストをいかに減らすか？

Uberが、自社のAIエージェント運用のコスト効果について、記事を書いていた。なかなか面白いポイントが多かったのでメモ。

Uberでは、プルリクの70%以上でAIエージェントが使われていて、3,600以上のAgent Skill、1日3万回以上のSkill実行があるらしい。

ここ半年で、エージェントの利用者数は7倍、リクエスト数は9.4倍だが、「「「総AI支出は4月以降おおむね横ばいの模様」」」。

ここが、すごく気になってドキュメントを読んでみた。

というわけで、UberではAI Agentの稼働率が異常に高まったわりに、そこまで負担が増えてない。以下、Uberが何をやっているのかメモ。

Uberの全体方針

前提として、Uberは、個々のエンジニアがAIと対話する「AIコーディング」から、評価基準・モデル選択・実行環境まで企業側が管理する「Managed AgentによるSoftware Factory」へ重心を移行しようとしている。

つまり、個々人のプロンプトテクニックで頑張るというより、ハーネスやワークフロー側で、AIがどう仕事をするかをかなり強く管理する方向。

コードレビュー、CIの修復、保守などは専門Agentに寄せていき、人間はレビューや例外判断に集中するイメージですね。

長期的には、こういう「人が毎回AIを操作しなくても開発プロセスが回る状態」のほうがスケールする、という思想でいくらしい。

Uberのコスト評価式

AIのコストについて、Uberはコスト評価をざっくり以下の掛け算として考えている。

要は、コストを減らしたければ、この中のどこかを下げればいい。　ポイントは、AIコスト削減にユーザー数やセッション数で対処していない点。

むしろAIの利用自体や利用者数はどんどん増やす。その代わり、1回の仕事の中にある無駄なターン、無駄なリクエスト、無駄なトークンを削る。で、トドメにモデル変更でトークンコストを削る…というアプローチをとっている。

そのために、以下みたいなことをやっている。

モデルは“最高性能”ではなく、仕事ごとの最適解で選ぶ

実際のPRやタスクからベンチマークを作り、品質・コスト・信頼性を比較する。全部を最強モデルに投げるのではなく、タスクごとに一番費用対効果のいいモデルを選ぶ。特にsubagentには比較的安価なモデルを使い、メインモデルを計画や評価に集中させる。

特にこのサブエージェントのモデルを適切にダウングレードすることが、最も効果がある施策っぽい。

「コンテキストを大きければよい」という発想を避ける

1Mトークンのコンテキストが使えるモデルでも、400K程度で自動圧縮する。Reasoning EffortもMediumをデフォルトにする。会話履歴はターンごとに再送されるので、1回の入力が少し小さくなるだけでも、セッション全体ではかなり安くできる。

MCPの大量Tool定義をコンテキストに載せない

100以上のToolを普通に読み込むと、開始時点だけで5〜7万トークンくらいのschema overheadが発生する。そこでUberは1,000以上のMCP ToolをGateway経由でCLI化し、必要なToolだけ検索して動的にロードする。

Tool呼び出しをコード化・バッチ化する。

SQL実行 → ポーリング → 結果取得、みたいな決定論的な処理をLLMに毎回考えさせない。Pythonなどのサブプロセス内でまとめて処理して、最終結果だけLLMに返す。単純なSQLでもトークンを50%以上削減し、バルク処理では90%以上削減できたケースもあるらしい。

「良いコンテキストを最初から与える」

巨大なコードベースでは、AIはコードを書くこと以上に、「どこを見ればいいのか」を探すことに大量の時間とトークンを使う。Uberはそのために、2,400万node・8,000万edge規模の「AI Context Graph」を構築している。記事中の例では、同じモデルでもGraphありなら38秒で正答、なしでは20分以上探索した末に誤答している。

プロンプトのキャッシュの有効期限を1時間に

同様にプロンプトのキャッシュを5分から1時間に。5分でLLM側のキャッシュが消えると、ローカルからフル価格でコンテクストを再送信するハメになる。そして、ふつうのエンジニアは5分インターバル内で仕事を連続発行できない。
仕事終わるまでスマホ見てたら、キャッシュが消えちゃったりする。一方でSubagentの履歴は5分使い捨てのまま。

コスト意識を開発者にも見せる

セッション履歴を分析して、「高価なモデルの無駄遣い」「巨大なMCPレスポンス」「cache切れ」「巨大な初期prompt」など、非効率なパターンも検出する。

最終的には、トークン運用効率を、モデル固定の条件で1,000リクエストあたりのコストを34%削減、セッション単価をピーク比で約52%削減している。

個人的にはコンテキスト設計が１番気になる

個人的に特に興味があるのが、この中の「コンテキスト」のパート。

自分の経験でも、結局のところAIエージェントの大きなコストは、事前コンテキスト共有にあると感じる。実際のタスクを遂行する前に、依存関係やドキュメント、既存コード、制約条件などを一通り探索して、「この仕事をするために何を知っておくべきか」を組み立てる部分が重い。

コードを書くことよりも、手前の状況理解のコストが高いイメージ。

マルチエージェントでいきなりコストが肥大化するのも、ここがかなり大きいのではと思っている。

エージェントを5つに分岐させると、それぞれが別々にリポジトリを探索し、同じREADMEを読み、同じ依存関係を調べ、同じような前処理をして、それぞれのコンテキストをゼロから構築し始める。

つまり並列化すると、タスクだけでなく「状況把握」まで並列に重複してしまう。

たとえば統括エージェントが先に共通コンテキストを作り、しっかりと各エージェントに専用コンテキストを発行したり、共通コンテキストを発行できれば、トークン利用料は大きく減るのかもしれない。

というか、メモだけでは書ききれない情報がいっぱいあるので、このまとめに興味もったら、ちゃんとオリジナルのページをじっくりみるのオススメ。

以下、追記雑感

トークン削減というと、HeadroomのようにLLMとの間に入ってコンテキストを圧縮したり、通信量を減らす仕組みも思い浮かぶ。

ただ、Uberの記事を読んでいると、それよりさらに広く、モデルとの通信だけではなく、Toolの読み込み、サブプロセス、モデルルーティング、コンテキスト探索、Agent間の役割分担まで含めて、「LLMに何を考えさせるか」そのものをシステム側で管理する方向に進んでいるように見える。

…と考えると、やっぱり人間のエンジニアの仕事は、どこにいっちゃうんだろうね。