9月16日、The Stackが「1,000 MCP servers, no schema bloat? Uber's assault on AI costs」と題した記事を公開した。Uberが1,000個以上のMCPサーバーをスキーマ肥大化なしに運用し、生成AIコストをピーク比34%削減したアーキテクチャの詳細だ。LLMエージェントのコスト爆増に悩む開発組織にとって、見落とされがちなオーバーヘッドの構造を解剖した実例として参照価値が高い。

AIコストが「年間予算を数ヶ月で使い切る」問題からどう脱したか

Uberは今年初め、CTOのPraveen Nagaが「AIの年間予算を数ヶ月で使い切った」と発言し注目を集めた。その後、同社はコスト削減の取り組みを段階的に公開している。今回はDistinguished EngineerのUday Medisettyがエンジニアリングブログでその詳細を共有した。

数字を先に示す。2026年2月〜8月の間に、AIコーディングツールの週間アクティブユーザーは7倍、週間エージェントリクエストは9.4倍に増加した。にもかかわらず、4月以降の総支出はほぼ横ばいを維持。コスト最適化の効果を単独で見ると、リクエスト1,000件あたりのコストをピーク比で約34%削減、セッションあたりのコストを約52%削減している。

本題：スキーマ肥大化がコストを静かに爆増させていた

エンジニアにとって最も参考になるのが、MCP（Model Context Protocol）サーバーのスキーマ管理に関する知見だ。

MCPはAnthropicが2024年11月に提唱したオープン規格で、LLMエージェントが外部ツールやデータソースを標準化されたインターフェースで呼び出せるようにする仕組みだ（公式仕様）。GitHubやSlackなどSaaS各社が対応サーバーを提供しており、エージェントが利用可能なツールの定義（スキーマ）をコンテキストに読み込むことで、ツール呼び出しを実現する。Uberはコードレビュー、CI障害の自己修復、E2Eプルリクエストの完成、オンコールアラートのトリアージ、バグ調査、コードメンテナンスなど多数のエージェントをこの仕組みの上で動かしている。

問題は、サードパーティのMCPサーバーの設計思想だ。

「サードパーティのソフトウェア管理は、内製サーバーと比べて格段に難しかった。ベンダーはどの機能が使われるか予測できないため、製品の全機能を公開する設計にしている」

具体的には、あるワークスペース系SaaSが49個のツールを1つのサーバーにバンドルし、スキーマだけで約2万2,000トークンを消費する。メッセージング系とプロジェクト管理系のベンダーも、それぞれ34ツール・46ツールを搭載して出荷してくる。

100個強のツールをインストールした状態では、プロンプトを1文字も入力する前の初期プロンプト時点で、スキーマのオーバーヘッドだけで5万〜7万トークンが発生していた。さらに、LLMとの会話は各ターンで全履歴を再送するため、このオーバーヘッドは1回だけでなく毎ターン支払い続けるコストになる。「ユーザーがプロンプトを入力する前から、編集対象のファイルよりも多くのスキーマをエージェントが抱えている」という状況だ。

Uberの3つの対策

Uberはこの問題に対し、3つのアプローチで対処した。

1. CLIツール解決（CLI Tool Resolution）
ツール定義をモデルのコンテキストに事前ロードするのではなく、モデルにシェルコマンドの実行能力を与える。必要なタイミングでコマンドがゲートウェイに対して正しいツールを解決・呼び出すため、スキーマはコンテキストに一切載らない。1,000以上のゲートウェイツール全てがこの方式で公開されている。

2. ツール検索（Tool Search）
CLIが適さないケースでは、モデルが利用可能なツールのカタログを検索し、そのタスクに必要な定義だけをオンデマンドで取得する。ツールライブラリ全体の規模が増えても、オーバーヘッドは増加しない。

3. コードモード（Code-mode / バッチ実行）
通常のMCPでは1つのツール操作が1回のラウンドトリップになる。コードモードでは、モデルが一連の操作を小さなスクリプトとして書き、サブプロセスでまとめて実行し、最終的なサマリーだけをモデルに返す。

この3つを組み合わせることで、セッションあたりのツールスキーマオーバーヘッドを5万〜7万トークンのベースラインからほぼゼロに削減したとされる。内製ツールもサードパーティSaaSも、同一のゲートウェイを通じて同じ仕組みで処理される。

また、最もよく使うツールに対して約25個の「コードモードスキル」を事前パッケージ化し、このパターンをエンジニアがオプトインしなくてもデフォルトで使えるようにしている点も実装上の工夫として面白い。

モデル選定コストの最適化

スキーマ削減と並行して、Uberはモデル選定にもコスト意識を組み込んでいる。「ヘルパー」的なタスクはデフォルトで小型モデルに振り、高度な推論が必要なタスクだけ高コストのモデルを使う設計だ。フロンティアモデルとオープンウェイトモデルをタスク別にベンチマークし、その結果をSDLCマネージドエージェント全体のモデル選定に反映している。

このタスク難易度に応じたモデルの使い分けという考え方は、業界全体で広がりつつあるコスト最適化の定石でもある。Databricksや、オランダのネオバンクbunqでも類似のアプローチが取られているとUberのブログは言及している。

この知見は他社に転用できるか

Uberは明示的に「コスト削減の数字は自社のコードベース・チーム規模・ワークフローに固有のものであり、そのまま他社には適用できない」と述べている。ただし、「実際の業務でベンチマークし、コストを要素分解し、継続的に再最適化する」という方法論は汎用的に設計されていると強調している。

MCPを本番運用しているチームや、LLMエージェントのコストが想定外に膨らんでいるチームにとって、スキーマオーバーヘッドという見落とされがちなコスト要因に光を当てた実例として参照価値が高い。

詳細は1,000 MCP servers, no schema bloat? Uber's assault on AI costsを参照していただきたい。