# Envoy AI Gateway [[Tetrate]] と [[Bloomberg L.P.]] が2024年10月に協業開始したオープンソースプロジェクト。[[Envoy Gateway]] コントロールプレーンを拡張し [[Envoy]](Envoy Proxy)のデータプレーン拡張機能を活用することで、LLM 推論トラフィックと [[Model Context Protocol|MCP]] トラフィックを既存の CNCF Envoy エコシステム上で扱う。独立の新規プロキシを作るのではなく**既存のクラウドネイティブ HTTP プロキシ実績(約10年の本番運用実績)へ AI トラフィック対応を継ぎ足す**という設計方針が一貫しており、対抗する [[agentgateway]] の「新規統合プロキシを作る」方針と対照的である。(Source: [[@2024__EnvoyAIGatewayBlog__Introducing Envoy AI Gateway]], [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]]) ## MVP の3機能(2024-10 発足時点) 1. **使用量制限**: トークンベースのLLM使用量制御。従来のリクエスト数ベースのレート制限では、LLMの計算複雑性・コストを捉えられないという課題に対応する。 2. **統一API**: 複数LLMプロバイダ統合の簡素化。 3. **アップストリーム認可**: 複数プロバイダの認証情報・認可設定の一元管理。 (Source: [[@2024__EnvoyAIGatewayBlog__Introducing Envoy AI Gateway]]) ## リファレンスアーキテクチャ: 二層ゲートウェイ設計(2025-07時点) - **Tier One Gateway**(第一層): 集約されたゲートウェイクラスタにデプロイ。外部LLMプロバイダ(OpenAI・Anthropic・Bedrock・Vertex)または内部モデルサービスクラスタへのトラフィックルーティング、認証、トップレベルルーティング、グローバルレート制限を担う。 - **Tier Two Gateway**(第二層): 自ホスト型モデルサービングクラスタ内にデプロイ。内部トラフィックルーティング・ロードバランシング・自ホスト型モデル特有のポリシーを実装する。プラットフォームチームは外部ゲートウェイへ変更を加えずにモデルバージョン管理や内部セキュリティルールを適用できる。 自ホスト型モデルサービングには [[KFServing|KServe]](KFServing の後継プロジェクト名)を組み合わせ、トークンベース自動スケーリング・GPUのゼロスケーリング・マルチノード推論(vLLM経由)・OpenAI互換API・モデル/プロンプトキャッシングを利用する。可観測性は OpenTelemetry(GenAI Semantic Conventions準拠)、制御はガードレール設定によるコスト超過防止、最適化はKServeのモデルキャッシングと分散型推論(計算集約・メモリ集約処理の分離)で実現する。(Source: [[@2025__EnvoyAIGatewayBlog__Envoy AI Gateway Reference Architecture]]) ## MCP対応の設計(2025-12時点) MCPはステートフルプロトコルであり、セッションIDを複数呼び出し間で再利用し、複数のアップストリームMCPサーバ(GitHub・Jira等)との独立セッションを保持する必要がある。Envoy AI Gateway はこれを**トークンエンコーディング設計**で解決する: 1. エージェントがMCPセッションを初期化すると、ゲートウェイがバックエンドサーバとのアップストリームセッションを確立する。 2. ゲートウェイがアップストリームセッションのコンパクトな説明を構築し、安全で自己完結的なクライアントセッションIDへエンコードする。 3. クライアントがこのIDを返却すると、任意のゲートウェイレプリカがデコードでき、正確なアップストリームへルーティングできる。 代替案として検討された「UUIDをクライアントへ返却し Redis 等の共有ストアに `UUID → [Upstream_Session_1, Upstream_Session_2]` マッピングを保存する」集約化ステート管理は、管理対象コンポーネントの追加・高可用性アーキテクチャの複雑化・単一障害点リスクを理由に採用されなかった。エンコードステート方式は水平スケーリングの簡素化・専用ステートコンポーネント不要という運用簡素化を得る代わりに、鍵導出関数(KDF)によるセッション暗号化の計算オーバーヘッドを受け入れる。デフォルト設定(KDF 100,000回反復)は数十ミリ秒のオーバーヘッドを生むが、約100回反復への調整で1〜2ミリ秒まで削減できる。(Source: [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]]) ## agentgateway との設計思想の対比 | | [[Envoy AI Gateway]] | [[agentgateway]] | |---|---|---| | 出自 | 既存の[[Envoy]]/[[Envoy Gateway]]エコシステムを拡張 | Rustで新規実装した統合プロキシ | | MCPセッション状態 | トークンエンコーディング(ゲートウェイはステートレス、セッション情報はトークン内に自己完結) | (ドキュメント概要ページの範囲では)明記されず、ツールフェデレーション・トランスポート対応が中心 | | 主張する優位性 | 約10年のHTTPプロキシ本番実績、可観測性・セキュリティへの既存投資の再利用 | 「AI用」と「通常用」でゲートウェイを分けない一枚岩の統合、Rustによる性能・メモリ安全性 | | 自ホスト型モデル対応 | [[KFServing|KServe]]と連携(モデルサービング層は外部委譲) | 独自のKubernetes Inference Gateway拡張でGPU/KVキャッシュ利用率等に基づくルーティング | 両者とも「LLM/MCP/A2Aトラフィックを通常のAPIトラフィックと同一の面で扱う」という同じ問題設定に対し、「既存資産の拡張」対「新規統合実装」という異なる出自から接近している。Envoy AI Gateway の記事は明示的に他のMCPゲートウェイと比較していないが、Envoyのプロキシとしての実績を暗に対比軸として使っている。(Source: [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]], [[@2026__AgentgatewayDocs__agentgateway Standalone ドキュメント概要]]) ## コミュニティ・ガバナンス 毎週月曜日の定例会議、Slackコミュニティ、GitHubディスカッションで運営される。(Source: [[@2024__EnvoyAIGatewayBlog__Introducing Envoy AI Gateway]]) ## 関連 - [[Envoy Gateway]] / [[Envoy]] — 拡張元のコントロールプレーン・データプレーン - [[Tetrate]] / [[Bloomberg L.P.]] — 共同創設組織 - [[KFServing]](KServe) — 自ホスト型モデルサービングの組み合わせ先 - [[Model Context Protocol]] — 対応するステートフルプロトコル - [[agentgateway]] — 設計思想が対照的な競合/隣接プロダクト - [[AIゲートウェイ]] — 本プロダクトが属する概念カテゴリ - [[Kubernetes Gateway API]] — 準拠する標準API仕様