AIエージェントの費用増加は、利用を制限したり安いモデルへ一律に置き換えたりする前に、実行環境から無駄を除くことで抑えられる。 Uberはこの考え方を、AIエージェントによる開発を費用と品質の両面から運営する「ソフトウェア工場」として実践している。
総費用は、利用者数、利用者当たりのセッション数、セッション当たりのターン数、ターン当たりのリクエスト数、リクエスト当たりのトークン数、トークン単価の積に分解できる。 普及と活用を表す最初の二項は増やしながら、エージェントが利用者の依頼以外に費やすターン数、リクエスト数、トークン数を減らすのがUberの方針である。
リクエスト当たりのトークン数は、長い会話を早めに圧縮し、利用形態に合う保持時間でプロンプトをキャッシュすることで減らせる。 必要になるか分からないMCP道具の定義をすべて読み込まず、カタログから必要な道具だけを検索することも効く。 道具の状態確認をモデルが一回ずつ指示する代わりに、子プロセス内のプログラムで一括実行して最終結果だけを返せば、中間応答が後続の会話へ繰り返し入ることもない。
ターン当たりのリクエスト数は、仕事に必要な情報を先に与えることで減らせる。 情報が足りないエージェントは、対象を探すたびに増えた会話履歴を再送し、時間と費用を使った末に誤答することがある。 Uberはサービス、担当チーム、障害、PR、設計文書、配備、データ利用履歴を知識グラフで結び、社内情報の探索を短縮している。
トークン単価は、実際の仕事から作った評価集合を複数のモデルに解かせ、品質、信頼性、完了した仕事当たりの費用がパレート最適になるモデルを選ぶことで抑える。 主エージェントには仕事の分解と評価を担えるモデルを使い、入力と完了条件が明確な下位エージェントには比較的安価なモデルを割り当てる。
この最適化は、「トークン量が少なければ品質も高い」と推定するものではない。 品質は既知の不具合に対する適合率、再現率、F1や運用後の差し戻し率などで独立に測り、改善の運用周期へ組み込む。 その品質を保ったうえで、マージされたPR、完了したレビュー、処理した警報など、成果一件当たりの費用を下げる。
特定の仕事を担う管理型エージェントなら、入力、評価集合、モデル、実行手順、権限、費用を運営側で揃えられる。 そのためUberは、個々の開発者の対話型セッションだけを改善するより、評価方法を持つ管理型エージェントへ開発工程を移すほうが規模を拡大しやすいと考えている。
Uberは、週間利用者が7倍、週間のエージェント要求数が9.4倍へ増えた期間にもかかわらず、総費用は途中からおおむね安定し、同じモデルで比較したセッション当たりの費用は最大時から52%下がったと報告している。 ただし、これらはUber固有のコードベース、社内基盤、利用構成で得た値であり、記事は評価集合、絶対的な費用、各施策の因果を再現できる生データまでは公開していない。