# AIゲートウェイ ## 定義 AIゲートウェイとは、LLM 推論トラフィック・[[Model Context Protocol|MCP]] ツールサーバ間通信・A2A(Agent2Agent)エージェント間通信を、通常の HTTP/gRPC API トラフィックと**同一のプロキシ**で扱うゲートウェイである。従来の API ゲートウェイがステートレスな request/response(1リクエスト→バックエンド選択→1レスポンス)を前提に設計されているのに対し、MCP・A2A は長命の JSON-RPC セッション・複数バックエンドへのファンアウト・サーバ起点の SSE プッシュ・クライアント単位の動的ツール可視性を要求するため、既存ゲートウェイをそのまま転用できない。AIゲートウェイはこの不一致を埋めるために、プロトコル認識ルーティング・セッションファンアウト・双方向イベント配送・動的ツール仮想化を第一級機能として実装する。(Source: [[@2026__AgentgatewayDocs__agentgateway Standalone ドキュメント概要]]) ## 横断的知見 - **フィールド観測の一次論文が、AIゲートウェイ製品が実装すべき機能を「本番障害から逆算した6段パイプライン」として独立に裏付けた**: agentgateway はドキュメント上で MCP 認証仕様準拠・ツールフェデレーションを製品機能として列挙するが、[[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]] は同種の機能を、大手クラウドプロバイダ統合の実運用障害(ユーザー識別情報の欠落によるクロステナントデータ露出リスク)から導出される**必須責務**として提示する: JWT 抽出・検証、コンテキスト注入、ツールレベル ACL 強制、レスポンスサニタイズ、認証情報保管庫、監査証跡の 6 つ(Context-Aware Broker Protocol, CABP)。製品ドキュメント(agentgateway)と独立系フィールド論文が同じ機能セットに収束したことは、これらが単一ベンダーの設計選択ではなく MCP エージェント運用に**構造的に必要な最小機能集合**であることを示唆する。(Source: [[@2026__AgentgatewayDocs__agentgateway Standalone ドキュメント概要]], [[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]]) - **「ゲートウェイはワークアラウンドか恒久コンポーネントか」という問いに、フィールド論文は明確な立場を取る**: 本論文は「MCP 仕様がユーザーコンテキストをネイティブサポートするようになった後も、ブローカー/ゲートウェイは ACL 強制・監査ログ・レスポンスサニタイズ・認証情報管理のために恒久的なアーキテクチャコンポーネントであり続ける」と明言する。これは agentgateway が「AI 用ゲートウェイと通常用ゲートウェイを分離せず統合する」設計判断の妥当性を、プロトコル仕様の将来変化に対して頑健な根拠として補強する。(Source: [[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]]) - **「AIゲートウェイ」という同一カテゴリに、出自の異なる2つの実装アプローチが実在する**: [[agentgateway]] は Rust で新規実装した統合プロキシとして「AI 用/通常用を分離しない」設計へ到達したのに対し、[[Envoy AI Gateway]] は既存の [[Envoy]]/Envoy Gateway エコシステムを拡張することで同じ「AIトラフィックと通常トラフィックを同一プロキシで扱う」問題設定に到達した。Envoy AI Gateway 側は「LLM/MCPトラフィックも最終的にはHTTPに依存する」という主張を根拠に、新規実装ではなく既存のクラウドネイティブHTTPプロキシの十年の実績を転用する戦略を明示的に取る。AIゲートウェイという製品カテゴリが、単一の実装パターンではなく「新規統合実装」対「既存プロキシ拡張」という異なる出自から独立に収束しつつある構造が見える。(Source: [[@2024__EnvoyAIGatewayBlog__Introducing Envoy AI Gateway]], [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]]) - **MCPのステートフルなセッションをゲートウェイでどう配置するかに、具体的な設計軸が存在する**: [[Envoy AI Gateway]] は MCP セッション管理を「アップストリームセッション情報をクライアントセッションIDへ自己完結的にエンコードし、ゲートウェイ自体をステートレスに保つ」設計(トークンエンコーディング)で解決する。代替案として検討・却下されたのは「Redis等の集約ステートストアへ `UUID → 複数アップストリームセッション` マッピングを保存する」集約化ステート管理であり、却下理由は管理対象コンポーネントの追加・高可用性アーキテクチャの複雑化・単一障害点リスクである。エンコードステート方式は運用簡素化と引き換えに、鍵導出関数(KDF)によるセッション暗号化の計算オーバーヘッド(調整可能、デフォルトで数十ミリ秒)を受け入れる。これは CABP(前項)の「ステートレスな per-request JWT 注入」型ブローカーとも同型の設計選好であり、AIゲートウェイのステート配置には「エンコードして無ステート化」対「集約ストアで一元管理」という一貫した設計軸があることを示唆する。(Source: [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]]) - **自ホスト型LLMサービング層との統合方針も実装ごとに異なる**: agentgateway は独自の Kubernetes Inference Gateway 拡張(GPU/KVキャッシュ利用率・LoRAアダプタ・キュー長ベースのルーティング)を自前で実装するのに対し、Envoy AI Gateway は自ホスト型モデルサービング基盤を [[KFServing|KServe]] に委譲し、ゲートウェイ自体はルーティング・レート制限・可観測性に責務を絞る。AIゲートウェイという製品カテゴリの境界(どこまでを自前実装し、どこから既存のモデルサービング基盤に委ねるか)にも実装間で差がある。(Source: [[@2025__EnvoyAIGatewayBlog__Envoy AI Gateway Reference Architecture]]) ## 未解決の問い - 「AI 用ゲートウェイ」と「通常用ゲートウェイ」を分離せず統合するという agentgateway の設計判断は、実運用でどの程度のオペレーション上の利点(単一ポリシー面・単一可観測性面)を生むか。分離運用している他社事例と比較する余地がある。 - [[Gateway API Inference Extension]] は Kubernetes SIG が定める「LLM 推論ルーティング」寄りの薄い拡張であるのに対し、agentgateway の LLM Gateway 機能はマルチプロバイダ変換・レート制限・ツールポイズニング対策まで含む「AIゲートウェイ」というより広い製品カテゴリを構成する。両者の関係(agentgateway が GAIE を実装レイヤーとして取り込む形なのか、独立した機能なのか)は本ソースだけでは確定できず、GAIE を扱う他ソースとの突き合わせが必要。 - ツールポイズニング対策(直接改竄・シャドーイング・rug-pull 攻撃への防御)は agentgateway が課題として明示する一方、具体的な防御機構の詳細は本ページ(概要)には含まれない。下位ページ(mcp/等)のingestで補う必要がある。 - CABP の仮説 H2(JWT検証+コンテキスト注入+レスポンスフィルタリングによる追加レイテンシ中央値が 15ms 未満)は本論文自体では未検証(検証可能な仮説として提示されるのみ)。agentgateway のような実装がこの目標値を達成しているかは、ベンチマーク結果を扱う他ソースとの突き合わせが必要。 ## 関連 - [[Model Context Protocol]] — AIゲートウェイが前段配置する対象プロトコルの一つ - [[Gateway API Inference Extension]] — Kubernetes上のLLM推論ルーティング拡張。AIゲートウェイの一部機能と重なる - [[エージェント運用安全性]] — ツールレベル ACL 強制・least-privilege アクセスという安全機構の一形態としてのゲートウェイ - 実体: [[agentgateway]] / [[Envoy AI Gateway]] ## 出典 - [[@2026__AgentgatewayDocs__agentgateway Standalone ドキュメント概要]] - [[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]](Context-Aware Broker Protocol の6段責務、ブローカー恒久性の主張) - [[@2024__EnvoyAIGatewayBlog__Introducing Envoy AI Gateway]](プロジェクト発足、トークンベース使用量制御という問題設定) - [[@2025__EnvoyAIGatewayBlog__Envoy AI Gateway Reference Architecture]](二層ゲートウェイアーキテクチャ、KServeとの統合方針) - [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]](MCPステートフルセッションのトークンエンコーディング設計)