UberがMCPゲートウェイを構築

Uberのゲートウェイは社内でエージェント導入が広がる中で登場した。挙げられている課題は大規模組織ではよくあるものだ。統合の分断、インフラの重複、セキュリティ慣行の不統一である。このアーキテクチャはMCPを新しいプロトコルというより、統制すべき新たな窓口として扱う。制御と実行を分離し、ツール定義、スキーマ、所有権、有効化設定はレジストリに置き、実行時のHTTP・gRPC・TChannel呼び出しへの変換はプロキシが担う。

運用の詳細の多くは検出層にある。AutoCrawlerは社内のインターフェース定義言語レジストリをスキャンし、Protocol BuffersやThriftのスキーマからAPI定義を抽出する。そしてMCP互換スキーマを生成し、大規模言語モデルでツールの説明文を作る。新たに見つかったツールは所有チームがレビューして有効化するまで無効のままで、設定変更はサービスの再起動や再デプロイなしにデータプレーンへ反映される。

カタログが増えると、数千のツール定義をエージェントのコンテキストに読み込むのは非効率になる。UberのOmni MCPは段階的な検出に対応し、Response Projectionを使えばエージェントは完全なペイロードではなく必要な応答フィールドだけを要求できる。報道で引用された外部の識別者、Microsoft CoreAIのAjay Sharma氏やPipe17のKelly Goetsch氏は、この設計を既存のAPIゲートウェイのパターンになぞらえ、エージェントツールをめぐる統制の課題はAPIやGraphQLで既に知られているものと似る可能性を示唆した。