AIエージェントのリクエストが9.4倍に、Uberがコストを抑えた方法

導入

企業がAIコーディングを本格導入すると、課題は「コードを生成できるか」から「多数のエージェントを安定したコストで運用できるか」へ移る。Uberが公開したソフトウェアファクトリーの取り組みは、この変化をよく示している。2026年2月から8月中旬までに、全AIエージェント製品の週次アクティブユーザーは7倍、週次リクエストは9.4倍に増えた。それでもAI総支出は4月以降、おおむね安定していた。モデルを固定した比較では、1000リクエスト当たりのコストがピークから約34%、1セッション当たりのコストが6月のピークから52%下がったという。

ポイントは、節約を安価なモデルへの単純な置き換えに求めなかったことだ。エージェントの実行ループに含まれる重複入力、不要な推論、過剰なツール情報、無駄な検索を一つずつ削減している。

主要な施策

実際のタスクでモデルを選ぶ。 Uberは一般的なベンチマークだけでなく、コードレビューやソフトウェア開発の実データで評価する。タスク完了コスト、品質、信頼性、遅延、タイムアウト、ノイズ、適合率・再現率・F1などを比較し、コストと性能のパレート最適な構成を選ぶ。主エージェントには分解と評価を担わせ、範囲が明確な子エージェントには、より費用対効果の高いモデルを割り当てる。

1回のリクエストを小さくする。 会話型エージェントは、過去の対話、プロジェクトの文脈、ツールの結果を各ターンで再送する。Uberは40万トークンで自動圧縮し、推論強度を標準で中程度に設定して、高価な出力・推論トークンを抑える。プロンプトキャッシュのTTLも使い方に合わせ、長く続く対話には長いTTL、短命な子エージェントには短いTTLを適用する。

ツール定義を必要な時だけ読み込む。 MCPのSchemaを全セッションへ事前ロードすると、実際には使わないツールにもトークンを支払うことになる。UberはMCPゲートウェイを設け、CLI経由でツールを呼び出し、検索によって必要な定義だけを読み込む。さらにコードモードでは、ポーリングや繰り返し処理をサブプロセスへ移し、モデルには要約結果だけを返す。同じSQL処理の比較では、トークン消費が半分以上減り、バッチ処理では効果が拡大した。

事実に基づく探索を可能にする。 大規模なコードとデータ環境では、生成よりも情報の所在確認に多くのターンを使いがちだ。Uberのコンテキストグラフは、サービス、チーム、障害、PR、設計文書、データセット、利用履歴などを結び付け、エージェントが推測で検索を繰り返すのを防ぐ。

コストを見える化する。 実行中のコスト表示、支出階層、通知、承認フロー、セッション分析ダッシュボードを用意し、過剰なモデル選択、膨張したコンテキスト、キャッシュ失効、巨大なツール定義などを検出する。

意義

Uberの事例は、AIコスト管理をソフトウェアエンジニアリングの問題として扱う必要性を示している。品質、信頼性、遅延、コストを同時に測り、実際のタスクでモデルと実行経路を継続的に更新することが重要だ。

ただし、提示された削減率はUberのコードベース、チーム、インフラ、ワークロードに基づくもので、一般化できる固定値ではない。移植しやすいのは数値ではなく、ホスト型エージェントを本番システムとして捉え、無駄な入力と処理を計測可能な形で削るという考え方である。

出典：InfoQ 中文