11月2日、InfoQがLeela Kumili寄稿による「Uber Builds MCP Gateway to Govern Access to 800+ Servers and 5,000+ AI Agent Tools」と題した記事を公開した。この記事では、Uberが社内の800以上のMCPサーバーと5,000以上のAIエージェントツールを統括するMCPゲートウェイを構築した経緯と設計について詳しく紹介されている。
800サーバー・5,000ツールを束ねるゲートウェイ
AIエージェントの社内導入が拡大するにつれ、Uberが直面したのは「統合の断片化」「インフラの重複」「セキュリティポリシーの不統一」という三つの問題だった。これを解消するために構築されたのが、MCPゲートウェイである。
MCP（Model Context Protocol）は、AIエージェントが外部ツールやAPIを呼び出す際の共通プロトコルとして、Anthropicが主導して策定した仕様だ。各社がバラバラに独自連携を実装する代わりに、MCPを使えばエージェントとツール間のインターフェースを標準化できる。
Uberのアーキテクチャは二層構造になっている。MCPレジストリがコントロールプレーンとして機能し、ツール定義・スキーマ・オーナーシップ・有効化設定を管理する。一方、プロキシゲートウェイがランタイム実行を担当し、MCPリクエストをHTTP・gRPC・TChannelの呼び出しに変換して既存APIと橋渡しする。既存サービス側の変更は不要で、APIをMCPツールとして公開できる設計になっている。
/filters:no_upscale()/news/2026/11/uber-mcp-gateway-ai-agents/en/resources/1ubermcpgateway-1791756099777.jpeg)
Uber MCPゲートウェイ — APIをツールとして公開する構造（出典: Uber Blog）
ツール自動発見：AutoCrawlerの仕組み
5,000を超えるツールを手動で登録するのは現実的ではない。そこでUberが開発したのがAutoCrawlerだ。ワークフローエンジンCadence上で動作し、社内のIDL（インターフェース定義言語）レジストリをスキャン。Protocol BuffersやThriftのスキーマからAPI定義を抽出し、MCPに適合したスキーマを自動生成する。ツールの説明文はLLMが生成する。
新たに発見されたツールは、担当チームがレビューして明示的に有効化するまで無効状態のまま保たれる。設定変更はサービスの再起動やデプロイなしにデータプレーンへ伝播する。
/news/2026/11/uber-mcp-gateway-ai-agents/en/resources/1Screenshot 2026-10-11 at 3.00.15 PM-1791756099777.png)
AutoCrawlerによるツール自動発見フロー（出典: Uber Blog）
セキュリティとPII対応
ゲートウェイはサーバーレベルとツールレベルの両方で認可を実施する。ツールのレスポンスに含まれる個人情報（PII）や機密データのリダクション（マスキング）もサポートしている。JiraやGoogleなどのサードパーティ連携では、内部ユーザートークンを対応するサードパーティ認証トークンに交換する専用サービスが用意されている。
5,000ツールをコンテキストに詰め込む問題
ツールカタログが膨大になると、全定義をエージェントのコンテキストに一括ロードするのは非効率になる。Uberはこの問題に対してOmni MCPを開発した。
Omni MCPは「検索 → 発見 → スキーマ取得 → 呼び出し」という段階的なフローを提供する。エージェントはまずサーバー一覧を検索し、関連するツールを絞り込んだうえで個別スキーマを取得し、最後に必要なツールだけを呼び出す。この設計により、コンテキストウィンドウを全ツール定義で埋め尽くすことなく、大規模なツールカタログを扱えるようになる。LLMのコンテキスト長制約が実用上のボトルネックになりやすい現場において、段階的発見は重要な設計原則といえる。
Response Projection機能も同様の問題意識から生まれている。エージェントがレスポンスペイロード全体を受け取る代わりに、必要なフィールドのみを明示的に指定して取得できる仕組みだ。不要なデータをコンテキストに含めないことで、トークン消費の抑制と推論精度の向上を両立する。また、aifx CLIを使えばコーディングエージェントがツールを発見・呼び出し、結果をファイルに書き出して選択的に参照できる（aifx CLIの正確なリポジトリURLは元記事のUber Blogを参照のこと）。
「APIゲートウェイと同じ問題を解いている」
業界からの反応は概ね好意的だが、設計思想自体は既存のゲートウェイパターンの延長だという見方も多い。
MicrosoftのPrincipal Software EngineerであるAjay SharmaはLinkedInでこう述べている。
Azure API Gatewaysはしばらく前からこれをやっている。LLMがもたらすカオスに秩序をもたらすレシピだ。
Pipe17のPresident、Kelly GoetschもLinkedInの投稿でこう指摘している。
UberのMCPゲートウェイは、私たちが何十年もかけてAPI向け、そしてのちにGraphQL向けに構築してきたゲートウェイとまったく同じに見える。
Tamir DresherはLinkedInの投稿で、セキュリティ・ディスカバリー・オブザーバビリティ・ガバナンスといった分散システムの古典的な課題が引き続き中心にあることを指摘した。
「MCPゲートウェイ」という呼び名は新しくても、解いている問題はAPIゲートウェイが長年向き合ってきたものと本質的に同じだ。裏を返せば、既存のAPIゲートウェイ設計の知見がAIエージェント基盤にそのまま活きるということでもある。
詳細はUber Builds MCP Gateway to Govern Access to 800+ Servers and 5,000+ AI Agent Toolsを参照していただきたい。
