はじめに
Uber における AI エージェントの急速な普及は、チームがコード、データ、運用システムとやり取りする方法を根本から変えました。MCP（Model Context Protocol）との初期のアドホックな統合は、明確な価値を示しました。エージェントがライブのビジネスコンテキストにアクセスし、内部サービスをクエリし、ユーザーに代わって意味のあるアクションを実行できるようになると、その能力は劇的に向上したのです。こうした初期の成功により、MCP が Uber 社内でエージェント型システムを構築するための強力な抽象化レイヤーであることが実証されました。
しかし、導入が進むにつれて、重大な課題も浮上しました。各チームが個別に統合を進めた結果、ツール群の断片化やインフラの重複が発生したのです。MCP ツールは見つけにくく、安定して運用するのが難しく、特定のサービスやエージェントの実装に強く依存していました。小規模な段階ではこのアプローチでも機能しましたが、数百ものチームがエージェント型ワークフローを検索し始めたことで、Uber のニーズを満たせなくなりました。統一されたアーキテクチャがなければ、MCP をスケールさせるほど運用の複雑さ、セキュリティリスク、開発者の負担が増大し、最終的にはその効果を制限してしまうことになります。
Uber の規模で MCP の可能性を最大限に引き出すには、AI エージェントが既存のバックエンドシステムとやり取りする方法を標準化しつつ、各チームの柔軟性も維持できる、一元化されたスケーラブルなソリューションが必要でした。このソリューションには、プロトコルの違い（HTTP、gRPC™、TChannel）を抽象化し、一貫したセキュリティとオブザーバビリティを保証し、社内全体で MCP ツールを簡単に作成・検出・再利用できるようにする役割が求められました。
このニーズに応えるために構築したのが MCP Gateway です。これは Uber におけるすべての MCP インタラクションを支える基盤的なマイクロサービスであり、AI エージェントと既存のバックエンドサービスおよびネイティブ MCP サーバーの間で、オーケストレーションとルーティングのレイヤーとして機能します。MCP ロジックを単一のゲートウェイに集約することで、エージェントからサービスへのインタラクションに一貫した実行モデルを提供し、各チームがコアインフラを再構築する手間をなくしました。既存の API はシームレスに MCP ツールとして公開でき、一箇所で管理・運用され、複数のエージェントが統一された方法で利用できます。MCP Gateway により、Uber 社内で AI エージェントを構築するためのスケーラブルかつ高速で一貫した道筋が開かれ、現在では 800 を超える MCP サーバーと 5,000 を超えるツールをホストしています。
図 1：MCP Gateway（API をツールとして活用）。
本ブログでは、MCP Gateway の設計について解説します。具体的には、Proxy Layer（MCP と既存プロトコル間の相互変換）、Discovery Layer（MCP Registry と API クローリング）、そしてコントロールプレーン（オーサリング）を取り上げます。
ゲートウェイ
MCP Gateway はマイクロサービスベースのアーキテクチャを採用しており、ゲートウェイが AI 対応システムと Uber のバックエンドサービスを結ぶ中心的な統合ポイントとして機能します。プラットフォームは主に 2 つのコンポーネントで構成されています。コントロールプレーンを担う MCP Registry と、データプレーンを形成する Proxy Gateway です。
MCP Registry は、内部サービスに支えられた数百の MCP サーバーと、数千の MCP ツールのカタログを管理しています。これらのツールは、既存の API を MCP ツールとして公開するノーコード定義から、MCP 仕様に準拠して明示的に構築された完全なネイティブ実装まで多岐にわたります。レジストリは、エコシステム全体における検出、所有権、有効化のための唯一の信頼できる情報源（Single Source of Truth）を提供します。
Proxy Gateway は、ランタイムでの MCP リクエストの実行を担当します。MCP プロトコルの呼び出しを HTTP、gRPC、または TChannel リクエストに変換し、適切なバックエンドサービスに転送した後、レスポンスを再び MCP 互換の結果に変換します。この変換レイヤーにより、AI エージェントは基盤となるサービスに変更を加えることなく、一貫した MCP インターフェースを通じて既存のシステムとやり取りできます。
コントロールプレーン
Uber はマイクロサービスアーキテクチャを採用しており、HTTP、gRPC、TChannel で API を公開する数千の内部サービスを運用しています。これらの API は AI システムにとって貴重なコンテキストとなりますが、各チームに MCP サーバーを手動で作成してもらうのは時間がかかり、負担も大きくなります。この問題を解決するために構築したのが AutoCrawler です。AutoCrawler は Uber の IDL レジストリを継続的にスキャンして API を検出し、変換した上でレジストリを更新します。また、ネイティブ MCP サーバーをクエリしてレジストリに追加する機能も備えています。
AutoCrawler：ディスカバリーエンジン
AutoCrawler は Cadence を活用した分散ワークフローシステムで、Uber の IDL レジストリと内部サービスのシグナルをサブスクライブしています。一定のスケジュールに従い、cron ジョブが Cadence ワークフローをトリガーし、新たに追加されたサービス、API、スキーマの変更をスキャンします。
検出された各エンティティに対して、AutoCrawler は以下の処理を行います。
- MCP サーバー表現の作成または更新
- ツール定義とスキーマの生成または取得
- デフォルトで無効化された状態で MCP Registry にツールを登録
この共通基盤により、数千のサービスにわたって MCP の検出をスケールさせつつ、サービスチームをクリティカルパスから外すことができます。
図 2：Auto Crawler。
IDL ベースのサービスの検出
Protobuf や Thrift IDL で定義された従来のバックエンドサービスの場合、AutoCrawler は IDL Registry から直接 MCP サーバーとツールを導き出します。各サービスの API グループに対して、AutoCrawler は次のステップを実行します。
- MCP サーバーのアップサート： 検出されたサービスに対応する仮想 MCP サーバーを作成または更新します。
- IDL 定義のパース： 関連する protobuf または Thrift ファイルをパースし、メソッド名、リクエストおよびレスポンスのスキーマ、ドキュメントコメントを抽出します。
- ツール説明の生成： LLM を使用して、抽出されたスキーマとコメントに基づき、エージェントにとって使いやすい詳細な MCP ツール説明を生成します。
- スキーマ変換： protobuf または Thrift スキーマを、MCP 互換の JSON-RPC 2.0 スキーマに変換します。
- MCP ツールのアップサート： 生成された MCP ツールを、デフォルトで無効化された状態で MCP Registry に登録または更新します。
ネイティブサーバーの検出
IDL ベースのサービスに加え、MCP Gateway はネイティブ MCP サーバー、つまり MCP プロトコルを直接実装し、エージェント向けに最適化されたツールを公開するサービスにも対応しています。
MCPFx は、Uber がネイティブ MCP サーバーを構築するために使用しているフレームワークです。各ネイティブ MCP サーバーは、自身の存在と準備状態を示すハートビートメトリクスを発信します。AutoCrawler はこのハートビートシグナルを継続的に監視し、新しいネイティブ MCP サーバーを自動的に検出します。ネイティブ MCP サーバーが検出されると、AutoCrawler は別の検出パスをたどります。
- ネイティブ MCP サーバーに対して listTools 呼び出しを行い、明示的に公開されているツールとそのスキーマを取得します。
- 検出されたすべてのツールとそのスキーマを含む仮想プロキシ MCP サーバーを、デフォルトで無効化された状態で MCP Registry に作成します。
3P MCP サーバー
MCP Gateway は、Uber 全体のあらゆる MCP インタラクションを統括する集中型オーケストレーションレイヤーとして機能し、Jira や Google といったサードパーティ統合もシームレスにサポートします。
サードパーティ MCP サーバーのプロビジョニングは、次の 2 つの主要コンポーネントの連携によって実現されます。
- MCP Gateway： 認証、レート制限、機密データの秘匿化といった必須のゲートウェイ機能を適用しながら、呼び出し元のユーザートークンを下流に中継します。
- サードパーティ MCP サービス： 外部 MCP サーバーにリクエストを送信する前に、内部ユーザートークンを対応するサードパーティの認証トークンと交換します。
オーサリングと有効化
サービスチームを関与させずに MCP サーバーを作成することは可能ですが、MCP サーバーの所有権と管理権限は必ずサービスチームに帰属する必要があります。MCP Gateway の設計原則の一つは、「検出＝公開」ではないということです。すべての MCP サーバーとツールは無効な状態で開始され、所有するチームによる明示的なレビューと有効化が必要です。サービスオーナーは、生成されたツール定義を有効化する前に確認し、調整できます。
ツールの説明に対する変更はすべて設定変更の差分（diff）をトリガーし、サーバーオーナーの承認が必要になります。オーナーは設定変更を承認してデプロイでき、必要に応じて既知の以前のバージョンにロールバックすることも可能です。
図 3：MCP Registry UI。
図 4：MCP ツール UI。
データプレーン
MCP Gateway のデータプレーンは、MCP リクエストの実行を担当するコアランタイムサービスです。コントロールプレーンからサーバーおよびツールの設定を継続的に取得し、一定の周期でメモリ内の状態を更新します。これにより、ツールの更新や有効化の変更といった設定変更が、サービスの再起動や再デプロイなしにリアルタイムで反映されます。
この設定に基づき、データプレーンは仮想 MCP サーバーを動的に具体化します。Gateway は各仮想サーバーに対して単一の /<service-name>/mcp エンドポイントを公開し、これが AI エージェント実行のエントリーポイントとなります。受信したリクエストは、組み込みのプロキシサーバーを通じて対応するサーバーハンドラーに解決されます。
図 5：MCP Gateway データプレーン。
プロトコル変換と実行
MCP Gateway におけるプロトコル変換は、Proxy Gateway 内のサーバーハンドラーによって処理されます。各サーバーハンドラーはツールと下流サービスの双方を認識しているため、ランタイムで MCP リクエストを正しくルーティングし、実行できます。
セキュリティ
MCP Gateway は、すべてのサーバーに対してツールレベルの粒度で組み込みの認証と秘匿化機能を提供します。MCP Gateway は Uber 内部の Access Control System を使用し、検出された呼び出し元アクター（人間、サービス、エージェント）に設定された異なる Charter ポリシーを適用します。Charter ポリシーはサーバーレベルで作成され、必要に応じてツールレベルでオーバーライドすることも可能です。
さらに MCP Gateway は、ツールレスポンスに含まれる PII（個人識別情報）や機密データを、すぐに使える形で自動的に秘匿化します。
IDL ベースの下流サービス
既存のバックエンドサービスを利用するツールの場合、サーバーハンドラーは HTTP エンドポイント設定や gRPC/TChannel プロシージャなど、下流の宛先を示すマッピングをメモリ内に保持します。
MCP リクエストを受信すると、ハンドラーは以下の処理を行います。
- 受信した JSON ペイロードを適切なワイヤフォーマットに変換します。
- リクエストを Protobuf または Thrift バイトにシリアライズします。
- リクエストを下流サービスに転送します。
- Protobuf または Thrift バイトのレスポンスを MCP 互換の JSON に再変換し、呼び出し元のエージェントに返します。
実際の下流リクエストは、すべてのバックエンドサービスと並行して稼働する Uber のサービスメッシュサイドカーである Muttley を介して実行されます。リクエスト実行を Muttley に委譲することで、MCP Gateway は既存のサービス間ルーティング機能を自動的に活用できます。
ネイティブ MCP サーバー
ネイティブ MCP サーバーも MCP Registry に仮想サーバーとして登録され、レジストリが元のサーバーへのプロキシとして機能します。ランタイムでは、ネイティブ MCP リクエストは透過的に下流サーバーへプロキシされ、レスポンスも同様に呼び出し元へプロキシされます。
ゲートウェイのメリット
MCP-Gateway の構築により、Uber はエージェント型システムを構築するためのスケーラブルかつ統一されたアプローチを実現しました。特に大きな効果をもたらしたのは以下の点です。
- 容易な検出とインストール
- 既存 API に対するノーコードアプローチ
- 組み込みのオブザーバビリティとセキュリティ
- 一元化された所有権とガバナンス
ゲートウェイの拡張
MCP Gateway を数百のサーバーと数千のツールへとスケールさせる過程で、小規模では発生しない問題が明らかになりました。それが「コンテキストの肥大化」と「コストの増大」です。
ランタイムディスカバリー
MCP には、サーバー横断検索というネイティブな概念がありません。エージェントは、どのツールが利用可能かを尋ねる前に、どのサーバーと通信すべきかをすでに把握している必要があります。エージェントが MCP サーバーを使用するように設定するには、サーバー URL、認証情報、ツールリストを明示的に紐付ける必要があり、これを数百のサーバーに対して行うのは現実的ではありません。そうしたコンテキストがモデルのコンテキスト上限を圧迫してしまうからです。私たちは以下の仕組みでこの問題を解決しました。
- Omni MCP — MCP クライアントが段階的な検出パターンで MCP Gateway の任意のサーバーにアクセスできる単一のプロキシサーバーです。インクリメンタルな検出により、コンテキスト／トークンの最適化も可能になります。Omni MCP は以下のツールを公開します。
- discover_server - クエリの意図に基づいて MCP サーバーを検出する
- discover_tools - サーバーのツールを検索する
- get_tool_schema - ツールの JSON スキーマを取得する
- invoke_tool - ツールを呼び出す
これらのツールを組み合わせることで、組み込みのアクセス制御やその他のゲートウェイ機能を活用しながら、すべての MCP サーバーへの段階的な検出とアクセスが可能になります。
- Response Projection - MCP Gateway は、MCP ツール向けの GraphQL ライクな呼び出しパターンである Response Projection も提供します。これは、ツールリクエストスキーマに新しいフィールドを追加し、全フィールドではなく必要なフィールドのみを要求するようゲートウェイに指示することで機能します。LLM がこれを読み取り、必要なフィールドのみのネストされたパス配列を注入します。その後、Gateway はランタイムで投影されたフィールドのみを残してレスポンスをトリミングします。これにより、エンタープライズレベルで MCP の API スキーマ互換性をスケールさせることができました。
- Code Mode - コーディングエージェントはシェル環境で動作することが多く、ツール出力をファイルに直接書き込む方が、レスポンス全体をモデルコンテキストに読み込むよりも効率的です。Code Mode は、エージェント操作向け CLI である aifx を通じてこのパターンに対応し、MCP サーバーを一切インストールすることなく、ゲートウェイ経由で MCP 呼び出しをルーティングします。コンテキストに MCP 定義が存在しなくても、エージェントが作業に適した MCP ツールを見つけられるようになります。aifx は 3 つのコマンドを公開します。
- aifx mcp list - 利用可能な MCP サーバーを一覧表示する
- aifx mcp search - すべての MCP サーバーからツールを検索する
- aifx mcp call - MCP Gateway を介して MCP ツールを呼び出す
エージェントはこれらを単一のコマンドで連鎖させ、出力をファイルに書き込めます。ファイルシステムエージェントはそれを選択的に grep し、必要な部分だけをコンテキストに読み込みます。Code Mode は現在、コーディングエージェントにおける MCP ツール使用の社内デフォルトとなっています。
まとめ
MCP Gateway の構築は、Uber における AI エージェントの運用方法を根本から変えました。数十のチームがバラバラに MCP 統合を進め、ツールの一貫性がなく、共通のセキュリティ保証もなく、インフラが重複していた断片化の問題は、今やどのチームでも数分で接続できる統一されたスケーラブルなプラットフォームへと進化しました。
私たちの設計を推進した核心的な洞察はシンプルです。「既存の API こそが、エージェントにツールを提供する最も迅速な方法である」ということです。チームにエージェント時代に向けてサービスを書き直してもらうのではなく、MCP Gateway は現状のまま寄り添います。HTTP、gRPC、TChannel の呼び出しを、Muttley を介して透過的かつ MCP 互換のインタラクションに変換し、下流サービスの変更は一切不要です。
大規模なエージェント型システムを構築しようとしているなら、最も難しい部分は AI ではありません。検出、セキュリティ、信頼性といった「結合組織」を構築し、エージェントが本番環境で実際のユーザーに代わって行動できるだけの信頼を得ることこそが真の難題です。MCP Gateway は、その課題に対する私たちの答えです。ここに記した設計上の意思決定が、同じ問題に直面している方々の参考になれば幸いです。
謝辞
カバー写真の帰属：OpenAI の ChatGPT で生成。外部画像、ロゴ、サードパーティアセットは使用していません。
gRPC は The Linux Foundation の商標です。
Uber Engineering の最新情報をお届けします。最新のブログ記事やインサイトについては LinkedIn でフォローしてください。
