AI Gatewayとは何か
LLM や AI エージェントを本番運用し始めると、アプリケーションコードの中に直接モデル呼び出しを書くだけではすぐに限界が来ます。理由は単純で、AI API は通常の REST API よりも コスト・可用性・安全性・観測性の変動幅が大きい からです。
- 同じ 1 リクエストでも消費トークンが大きく変わる
- ストリーミングや長文コンテキストなど、通信特性が不均一
- モデルやプロバイダを切り替えたくなる頻度が高い
- プロンプトや応答そのものがガバナンス対象になる
- エージェント化が進むと、LLM だけでなくツールや MCP サーバー、さらに A2A でつながる他エージェントまで統制対象に入ってくる
この「AI 特有の運用課題」を、アプリケーションの外側でまとめて扱うための制御レイヤーが AI Gateway です。
この記事では、特定ベンダーの製品紹介に寄せすぎず、まずは AI Gateway という概念そのもの を整理します。そのうえで、実装の厚みが分かりやすい Azure / AWS を題材に、どこまでが「単なる中継」で、どこからが「組織運用のための制御レイヤー」なのかを見ていきます。
関連記事
AI Gateway をひとことで言うと
AI Gateway は、アプリケーションと AI モデルの間に立ち、AI トラフィックを統制するためのミドルレイヤーです。
通常の API Gateway が「認証・認可」「レート制限」「ルーティング」「監視」といった横断機能を API の前段で担うのに対し、AI Gateway はそこに次のような AI 向けの関心事を追加します。
- トークン単位での利用制御
- モデル／プロバイダの切り替えとフォールバック
- プロンプト／レスポンスに対する安全性チェック
- AI 利用コストの集計と可視化
- 類似問い合わせの再利用（セマンティックキャッシュ）
- エージェントや MCP / A2A まで含めたガバナンス
構造としては新しいものに見えますが、発想はそこまで奇抜ではありません。API Gateway の進化系を AI ワークロードに最適化したものと捉えると理解しやすいです。
ただし、実務では「モデル API だけ守れば終わり」ではなくなっています。最近の焦点は、モデル・ツール・エージェントを横断して統制できるかどうかです。Azure が MCP サーバー や A2A agent API を AI Gateway の守備範囲に入れ始めているのは、その流れを象徴しています。
従来の API Gateway ではなぜ足りないのか
AI Gateway が必要とされる背景は、LLM API が「HTTP で呼べる」という表面的な共通性に反して、運用上は普通の API とかなり違うからです。
| 観点 | 従来の API Gateway | AI Gateway で強く問われること |
|---|---|---|
| 課金と制御の単位 | リクエスト数中心 | トークン数、モデル単価、チーム別コスト |
| ルーティング | サービス単位の振り分け | モデル特性・遅延・単価・障害時フォールバック |
| キャッシュ | 完全一致キャッシュ | 類似質問も再利用したい |
| セキュリティ | API 認証、WAF、JWT | PII マスキング、プロンプト注入、応答フィルタ |
| 可観測性 | レイテンシ、エラー率 | トークン消費、プロンプト、モデル別品質・失敗率 |
| 通信パターン | REST 中心 | SSE、WebSocket、マルチモーダル、長文入力 |
| バックエンド差異 | HTTP API の差分 | SDK・認証方式・レスポンス形式がかなり違う |
たとえば、通常の API であれば「1 分あたり 100 リクエスト」の制限でも一定の意味があります。しかし LLM では、100 リクエストの中身が短文 100 件なのか、巨大コンテキスト付きの 100 件なのかでコストも負荷もまるで違います。ここで必要になるのが、リクエスト数ではなくトークンやモデル特性を理解した制御です。
また、複数プロバイダを併用し始めると、認証方式やレスポンス形式の違いを各アプリケーションに埋め込むのはつらくなります。AI Gateway はこの差分を吸収し、アプリ側の結合を緩める役割も担います。
AI Gateway のコア機能
製品ごとの差はあっても、AI Gateway と呼ばれるものはおおむね次の能力を持っています。
統一エントリポイント
アプリケーションは個々のモデル API を直接呼ぶのではなく、ゲートウェイに向かって呼びます。これにより、バックエンドが OpenAI なのか Gemini なのか、自前ホストのモデルなのかをアプリから切り離しやすくなります。
認証と資格情報の集約
各チームや各アプリが個別にプロバイダ API キーを持つのではなく、ゲートウェイ側で管理します。アプリケーションはゲートウェイに対してだけ認証し、上流のプロバイダ資格情報は中央管理できます。
トークン制御とコスト可視化
AI Gateway の価値が最も分かりやすいのがここです。
- チーム単位・アプリ単位のトークンクォータ
- モデル別の利用量・レイテンシ・失敗率の集計
- コストの異常値検知
- 高価なモデルの利用を特定ユーザーだけに限定
「どのチームが、どの用途で、どのモデルにいくら使っているのか」を見える化できると、AI 利用は一気に運用品質が上がります。
ルーティング、フェイルオーバー、負荷分散
AI ワークロードでは、単に複数サーバーに均等分散すればよいとは限りません。
- 普段は安いモデルを使い、難問だけ高性能モデルへ送る
- 優先プロバイダが障害中なら代替モデルへフォールバックする
- 応答速度重視の経路と品質重視の経路を分ける
- 特定リージョンやデータ境界をまたがないように振り分ける
この「モデル選択のポリシー」をアプリごとに実装するのではなく、ゲートウェイ層で持つのが AI Gateway の考え方です。
ガードレールとコンテンツ統制
AI Gateway は、単に入口を守るだけではなく、プロンプトと応答の中身に踏み込むことがあります。
- PII や機密情報のマスキング
- 禁止トピックや不適切入力のブロック
- 応答のモデレーション
- プロンプトテンプレートや共通システムメッセージの注入
従来の API Gateway が「ヘッダーとパスの世界」に強いとすれば、AI Gateway はそこから一歩進んで「意味のある本文」まで対象にするイメージです。
観測性と監査
AI の運用では、「失敗したか」だけでなく「何を投げて、何が返ってきて、いくらかかったか」が重要です。
そのため AI Gateway では、以下のような監査情報が重視されます。
- リクエスト単位のトレース
- モデル、トークン数、応答時間の記録
- ユーザー／アプリ／部門別の利用実績
- プロンプトと出力の保存またはサニタイズログ
エージェント／ツール接続の統制
最近は AI Gateway の対象が「モデル呼び出し」だけではなくなってきています。エージェントが外部ツールや MCP サーバーにアクセスする場合、その接続先や認可をまとめて管理したい、という要求が出てきます。
このため、AI Gateway は LLM Gateway から Agent Gateway へ拡張される方向にも進んでいます。特にここで重要なのが、MCP と A2A は似ているようで役割が違うことです。
言い換えると、MCP は「エージェント → ツール」、A2A は「エージェント → エージェント」です。A2A の仕様でも、A2A と MCP は競合ではなく補完関係だと整理されています。実際、A2A で受けたタスクを、裏側で MCP ツールを使って処理するという構成はかなり自然です。ここまで含めて考えると、AI Gateway は単なる LLM プロキシではなく、エージェント実行基盤の境界面になっていきます。
典型ユースケース
AI Gateway の価値は、PoC よりも「本番で複数の要求が衝突し始めた瞬間」に見えてきます。
1. 社内向け AI プラットフォーム
最も典型的です。部門ごとに別々の AI アプリが増えてくると、個別に API キーを配布し、個別にコスト管理し、個別にガードレールを実装する運用はすぐ破綻します。
AI Gateway を入れると、
- 利用者認証を統一できる
- チーム別クォータを配れる
- ログと監査を一元化できる
- モデル追加や入れ替えをアプリ改修なしで進めやすい
という形で、AI を組織運用可能なインフラに寄せていくことができます。
2. 複数プロバイダを使う SaaS
たとえば、
- 通常のチャットは低コストモデル
- 長文解析は高性能モデル
- 画像理解は別プロバイダ
のように使い分ける SaaS では、AI Gateway があるとマルチプロバイダ構成をアプリから分離できます。障害時の自動切り替えにも向いています。
3. 規制や内部統制が厳しい業界
金融・公共・医療のように、
- データの出し先
- リクエスト内容の監査
- モデル利用の承認経路
- 出力内容の安全性
を重く見る環境では、AI Gateway は単なる便利ツールではなく、統制上の要件を満たすための中核部品になりやすいです。
4. エージェント基盤
エージェントが MCP サーバーや業務 API を呼び始めると、モデルの呼び出しだけでなく「どのツールにアクセスしたか」「誰の権限で実行したか」まで追跡したくなります。
AI Gateway はこのとき、モデル・ツール・エージェント通信を横断的に統制するハブとして機能します。たとえば、エージェント間のタスク委任は A2A、外部システム呼び出しは MCP に分け、それぞれに認証・監査・レート制限をかける設計が見えてきます。
LLM Proxy との違い
実務では「LLM Proxy」と「AI Gateway」がしばしば混同されます。
ざっくり言うと、LLM Proxy は 接続を簡単にする薄い中継層、AI Gateway は 運用と統制まで背負う制御層です。
| 観点 | LLM Proxy | AI Gateway |
|---|---|---|
| 主目的 | ルーティングの簡略化 | 組織全体の統制と運用 |
| ログ | 基本的な記録 | 構造化監査ログ、分析、アラート |
| ガードレール | 限定的 | 本格的なポリシー適用 |
| コスト管理 | 簡易 | 予算・クォータ・利用配賦 |
| 権限制御 | 弱い | チーム／用途別に制御しやすい |
| 向く場面 | 試作・小規模運用 | 本番・複数チーム・複数プロバイダ |
小規模では Proxy で十分なこともあります。ただし、利用者・チーム・モデルの数が増えると、だいたい「それを誰がどう使っているのか追えない」問題に突入します。そこから先が AI Gateway の守備範囲です。
どんなときに効くのか、逆にいつはまだ早いのか
AI Gateway は便利ですが、万能薬ではありません。
導入価値が高いケース
- 複数チームが同じ AI 基盤を使う
- 複数プロバイダや複数モデルを併用する
- 監査、コスト、データ保護を中央集権的に管理したい
- 障害時フォールバックやルーティングをアプリから外したい
- エージェントや MCP サーバーまで管理対象にしたい
まだ過剰なケース
- 単一アプリが単一モデルを小規模利用しているだけ
- 利用量が少なく、コストや監査の要求も薄い
- モデル切り替えやマルチクラウドを当面考えていない
この段階では、AI Gateway を入れること自体が新しい運用対象を増やすだけになる可能性があります。AI Gateway の価値は、複雑さを整理することにあります。複雑さがまだ存在しないなら、急いで入れる必要はありません。
MCP / A2A を含めると、AI Gateway は何を管理するのか
モデル管理だけを前提にすると、AI Gateway は「LLM 呼び出しの前段」に見えます。しかしエージェント基盤まで視野に入れると、見るべき面はもう少し増えます。
以下では概念を具体化しやすくするため、Azure API Management を例に MCP / A2A の管理面を説明します。ただし、ここで取り上げる論点自体は Azure 固有ではなく、ツール公開・資格情報管理・エージェント間委任の統制という意味で、AI Gateway 全般に共通する観点です。
MCP は「ツールをどう公開・統制するか」の問題
MCP サーバーのアーキテクチャでは、MCP host / client / server が分かれ、remote MCP server は HTTP ベースで外部公開されます。ここで企業が気にするのは、ツールの存在そのものよりも、むしろ次の論点です。
- どの REST API / Function / Logic App をツールとして公開するか
- エージェントや IDE からのアクセスをどう認証するか
- バックエンドへのトークンを誰が持つか
- ツール呼び出しをどう監査するか
Azure APIM が面白いのは、既存 REST API を MCP サーバーとして公開する経路と、既存の remote MCP server をそのままガバナンス下に置く経路の両方を持っていることです。つまり「ツールを APIM 内から生やす」ことも、「外の MCP サーバーを APIM 配下に入れる」こともできます。
なお、現時点では制約もあります。APIM が管理する MCP は、シナリオによって tools 中心です。managed REST API を MCP 化する場合は tools のみで、resources / prompts は未対応です。既存 MCP server の前段に立つ場合は tools と resources は扱えるが prompts は未対応です。ここは「MCP 対応」と聞いて全部できると思うと少しズレます。プロトコル名の響きに負けず、仕様差分はちゃんと確認したいところです。
A2A は「エージェント同士をどう協調させるか」の問題
A2A 仕様は、エージェント同士が相互に能力を発見し、タスクを委任し、進捗や成果物を受け渡すための標準です。中心にあるのは Agent Card と Task です。
- Agent Card: エージェントの能力・入出力モード・認証要件・利用可能スキルを記述する公開メタデータ
- Task: 非同期処理の単位。
working/input_required/auth_required/completedなどの状態を持つ - Update delivery: polling / streaming / push notification の 3 系統を標準で持つ
この構造が重要なのは、A2A が単なる RPC ではなく、長時間タスク・人間承認・再入力要求まで含めた協調を前提にしているからです。たとえば仕様上、エージェントは AUTH_REQUIRED 状態で一時停止し、クライアント側に追加認可を要求できます。これは「AI エージェントが業務ワークフローに入る」ときにかなり効いてきます。
つまり A2A は、単に「他のエージェントを HTTP で呼ぶ」ことを標準化しているのではなく、複数エージェントが状態を持った仕事を引き継ぐための土台です。
Azure: APIM を中心にモデル・ツール・エージェントを一枚で扱う
Azure の AI Gateway は、Azure API Management の既存 API Gateway を AI 向けに拡張した機能群として整理されています。ここがまず大事です。AI Gateway が別製品として増えるのではなく、既存の API 管理基盤が AI ワークロードを吸収するという見せ方になっています。
この方針は、機能一覧を見るだけでもかなりはっきりしています。
- モデル API のオンボーディング
- トークンベースの制御
- セマンティックキャッシュ
- バックエンドプールとサーキットブレーカー
- LLM ログとトークンメトリクス
- Content Safety
- MCP サーバー管理
- A2A agent API 管理
- Microsoft Foundry との統合
「モデル」「ツール」「エージェント」が同じ APIM の操作面に寄ってくるので、Azure は AI Gateway を AI トラフィック統制の汎用面として育てようとしている、と見るのが自然です。
Azure で本当に強いのは、接続方式の違いまで吸収しにいくこと
Azure 側の実装を深掘りすると、APIM は「モデルを前に置けます」で終わっていません。バックエンドの種類ごとに統合パターンを用意し、認証と API 形状の差をかなり吸収しようとしています。
1. Foundry / Azure OpenAI はかなりネイティブ
Microsoft Foundry API のインポートでは、APIM が以下を自動構成します。
- API オペレーション定義
- backend リソース
set-backend-service- system-assigned managed identity によるバックエンド認証
- 必要な権限設定
しかもクライアント互換性として、/openai 互換、/models ベースの Azure AI Model Inference API、Azure OpenAI v1 の選択肢まであります。ここはかなり「製品化されている」部分で、Azure ネイティブなモデルほどシークレットレスかつ宣言的に運用しやすいです。
2. OpenAI 互換 API はかなり素直に載る
Language Model API のインポートでは、OpenAI 互換エンドポイントを APIM に取り込み、必要なら API キーを named value として保持できます。要するに、OpenAI 互換であれば APIM 側がかなり親切です。
この意味は大きくて、アプリケーション側から見れば「Azure OpenAI」「外部 OpenAI 互換 API」「セルフホスト互換 API」の差を、かなり同じ呼び出し面に寄せられます。マルチプロバイダ化したいとき、アプリコードに差分を埋め込まなくてよいのは相当ありがたい。ええ、地味ですが本番ではこういう地味さが最後に勝ちます。
3. Bedrock のような非 OpenAI 互換は載るが、急に手仕事が増える
一方で、Amazon Bedrock passthrough API のインポートまで行くと景色が変わります。APIM には Bedrock を passthrough API として取り込む導線がありますが、認証は AWS Signature Version 4 を policy で組み立てる必要があります。
- AWS の access key / secret key を named value に保存
-
X-Amz-DateやX-Amz-Content-Sha256を構成 - canonical request を組み立てる
- HMAC-SHA256 連鎖で署名を計算
-
Authorizationヘッダーを生成
つまり Azure は Bedrock まで「接続対象」にはできますが、Azure ネイティブのような自動化レベルではない。ここは重要な設計判断点で、Azure の AI Gateway は「マルチモデル対応」ではあるものの、どの程度までネイティブに管理できるかはバックエンド依存です。
Azure は AI 固有の運用制御を APIM の政策として持ち込んでいる
Azure が AI Gateway らしいのは、単に接続できることではなく、AI 固有の運用制御が APIM の policy と observability に落ちていることです。
トークンベースの制御
llm-token-limit policyでは、counter-key ごとに TPM 制限や期間クォータを設定できます。ここで面白いのは、単なる request count ではなく token usage が制御単位になっていることです。
- subscription 単位に月次クォータを切る
- IP やユーザー ID で TPM を切る
-
estimate-prompt-tokensにより、送信前見積もりで早めにブロックする
完全に正確な同時実行制御ではないものの、少なくとも「LLM の運用で見るべき単位」が API Gateway 側に持ち込まれています。これは従来 API Gateway との差としてかなり本質的です。
セマンティックキャッシュ
Semantic cachingも、Azure の AI Gateway らしさが出る機能です。APIM は Azure Managed Redis などの外部キャッシュと embeddings を組み合わせ、完全一致ではなく類似問い合わせで再利用できます。
これは普通の HTTP キャッシュとは発想が違います。AI Gateway では「同じ URL か」よりも「意味的に同じ質問か」が重要だからです。
バックエンドプール、優先度、サーキットブレーカー
Backends では、APIM が backend pool と circuit breaker を持ちます。ロードバランシングは round-robin / weighted / priority-based / session awareness をサポートし、サーキットブレーカーは Retry-After を見て復帰タイミングを制御できます。
ここで Azure の設計意図がよく出ています。AI Gateway の役割は「複数モデルに均等分散」ではなく、たとえば次のような 品質・コスト・回復性の設計です。
- 通常は PTU 付きの優先バックエンドを使う
- 枯渇時だけ PAYG 側にスピルオーバーする
- 429 や 5xx を契機に一時的にバックエンドを切り離す
- 会話セッション中は同一バックエンドに寄せる
単なる L7 LB ではなく、AI エンドポイント運用を意識した配線盤になっています。
ログ、トークンメトリクス、監査
Azure では LLM ログ と llm-emit-token-metric により、prompt / completion / token usage / model 名を Azure Monitor や Application Insights に送れます。
ここが重要なのは、コスト可視化と監査が最初から AI 向けの粒度になっていることです。しかも大きな request / response は分割ログ化され、CorrelationId で再構成できます。AI 運用で本当に欲しいのは「5xx 率」だけでなく、誰が何を投げ、どれだけ token を使い、何が返ったかなので、この差は大きいです。
Azure は MCP と A2A を「同じ面」で扱おうとしている
ここが Azure の実装でいちばん面白いポイントです。APIM はもはやモデル API だけの製品説明ではなく、MCP サーバーと A2A agent API を同じ AI Gateway の中で扱うようになっています。
MCP: 既存 API をツール化する / 既存 MCP を前段に置く
MCP server overview を見ると、APIM の MCP 管理は大きく 2 パターンあります。
前者では API operation が MCP tools になります。後者では LangServe など外部 MCP server を前段で守れます。さらに secure-mcp-servers にあるように、inbound は subscription key / Entra ID、outbound は credential manager で OAuth トークン注入という分離も可能です。
ここでの本質は、「エージェントに直接ツール資格情報を持たせる」のではなく、ツール接続も gateway が仲介して資格情報を中央管理することです。
A2A: agent card を書き換え、JSON-RPC 実行面を仲介する
A2A agent API のインポートは現時点で preview ですが、かなり示唆的です。APIM は A2A バックエンドに対して以下を行います。
- JSON-RPC runtime の仲介
- policy によるトラフィック制御
- Application Insights に
genai.agent.id/genai.agent.nameを付与 - Agent Card のホスト名を書き換え
-
additionalInterfacesを整理 - subscription key 要件を含むよう security 要件を書き換え
要するに APIM は、A2A の 実行面 だけでなく 発見面（Agent Card） にも介入します。これにより、クライアントエージェントは APIM 経由の統一された Agent Card を見て接続できる。ここは単なる HTTP リバースプロキシより一段深いです。
なお制約として、A2A は現時点で v2 tier 限定かつ preview で、JSON-RPC ベースの A2A API のみ対応、outgoing response body のデシリアライズ非対応といった制限もあります。したがって「今すぐ全面採用」というよりは、Azure が agent governance をどこまで APIM に寄せたいか を示す方向性として見つつ、実導入では GA 時期と制約解消の見通しもセットで確認するのがよさそうです。
Azure を一言でまとめると
Azure の AI Gateway は、API 管理の延長線上に AI 固有制御を持ち込み、さらに MCP / A2A まで同じ管理面に寄せようとしている実装です。
- Azure ネイティブ資産には強く、managed identity も使いやすい
- OpenAI 互換 API も比較的素直に吸収できる
- 非互換 API も取り込めるが、そこは手作業が増える
- モデルだけでなく tools / agents まで統合管理の対象にしている
「AI Gateway をプロダクトとしてかなり前に出している」のが Azure の特徴です。
AWS: API Gateway を入口にして Bedrock 向け統制レイヤーを組み上げる
今回 AWS パートで中心に置いている公式資料は、AWS Architecture Blog の Amazon API Gateway の前段に AI gateway を構成し、Bedrock に中継する参照アーキテクチャ です。
Azure のように「AI Gateway」という機能群を API 管理製品の中に明確に畳み込むというより、AWS は 既存サービスを組み合わせて AI Gateway パターンを組み立てる見せ方が強いです。
AWS の中核は「sign-and-forward」構成
この参照アーキテクチャの基本構成は次の通りです。
- Route 53（任意）で独自ドメイン
- API Gateway を入口に配置
- Lambda authorizer で JWT などを検証
- Lambda integration でリクエストを受け、SigV4 署名して Bedrock に転送
- Bedrock が実際のモデル実行を担当
ポイントは、クライアントは Bedrock を直接知らなくてよいことです。認証、利用制御、ルーティング、署名付与を gateway 側に寄せられるので、アプリ側はかなり薄くできます。
さらに AWS の記事では、クライアントが Boto3 などの AWS SDK インターフェースをほぼそのまま使い、ゲートウェイ側で署名と中継を吸収できるようにしています。これは Bedrock 固有の API 進化に追随しやすい設計です。
AWS の良さは、既存のエンタープライズ制御をそのまま持ち込めること
このパターンで AWS が強いのは、AI 専用の新しいコントロールプレーンを増やすというより、API Gateway まわりの既存エンタープライズ機能を Bedrock 前段に持ち込めることです。
- authorization mechanisms
- usage plans と API keys
- request throttling
- canary release
- AWS WAF integration
- API Gateway response streaming
記事でも、企業が AI Gateway に求める要件として authorization、quota management、tenant isolation、cost control を前面に置いています。つまり AWS の見せ方は、「AI Gateway は新奇な AI 製品」というより、Bedrock の前段に企業向け API 制御をちゃんと置く設計パターンです。
Bedrock 固有の安全性や応答制御は周辺サービスと組み合わせる
AWS のブログは、AI 固有制御を API Gateway 単体に閉じ込めてはいません。たとえば、
- Bedrock 側の Guardrails
- API Gateway / Lambda 側での独自コンテンツフィルタ
- API Gateway cache を使った応答再利用
といった形で、Gateway・Bedrock・Lambda の責務分担で組み上げます。
この構成はかなり AWS らしいです。柔軟で、サーバーレス寄りで、既存サービスとの統合も自然です。一方で、Azure の APIM のように「トークン制御」「セマンティックキャッシュ」「MCP/A2A 統合」が API 管理面に濃く表現されているわけではありません。便利な部品はあるが、AI Gateway としての全体像は自分で設計する色が強いです。
AWS の実装は「専用製品」より「参照アーキテクチャ」に近い
ここが Azure との大きな違いです。Azure では AI gateway capabilities というページがあり、「APIM はモデル・ツール・エージェントをどう管理するか」がひとまとまりで見えます。
AWS では、少なくとも今回参照している AWS Architecture Blog と API Gateway / Bedrock の公式ドキュメント群を見る限り、Amazon API Gateway + Lambda + Bedrock + WAF + 認証系をどう組み合わせるか、という参照アーキテクチャとして語られています。これは悪い意味ではなく、AWS では AI Gateway が アーキテクチャパターンとして現れるということです。
その結果として、AWS の AI Gateway は次のような特徴になります。
- Bedrock 中心の統制レイヤーとしては作りやすい
- 既存の API Gateway 運用ノウハウを流用しやすい
- サーバーレス構成で伸ばしやすい
- ただし AI 固有の制御項目は、自分で組み合わせる面が大きい
Azure と AWS を並べると、何が違って見えるか
両者とも「アプリから AI バックエンドを直接触らせず、前段で統制する」という発想は同じです。ただし、どこまでを製品が肩代わりするかはかなり違います。
| 観点 | Azure | AWS |
|---|---|---|
| 中心となる考え方 | APIM の AI Gateway 機能群 | API Gateway を中心にした参照アーキテクチャ |
| モデル接続 | Foundry / OpenAI 互換 / passthrough を UI と policy で吸収 | Bedrock 前段に API Gateway + Lambda を配置 |
| 認証の見え方 | managed identity を強く活用、OpenAI 互換は named value、非互換は policy で吸収 | authorizer + Lambda で認証・署名・転送を組み立てる |
| AI 固有制御 | token limit、semantic cache、LLM logs などが前面に出る | throttling、usage plans、WAF、streaming など既存機能の組み合わせが中心 |
| ツール / エージェント統制 | MCP / A2A を同じ管理面に載せようとしている | 今回参照した AWS 公式資料では Bedrock 前段の管理が中心 |
| 使い心地 | 製品化が進んでいる | 設計自由度が高いぶん自前判断が多い |
ざっくり言うと、Azure は AI Gateway を製品として見せる、AWS は AI Gateway を設計パターンとして見せる、という差があります。
ベンダー差よりも先に見るべき設計論点
製品の見え方が違っても、設計上の論点はだいたい共通です。
1. 何を統制対象にするのか
- モデル API だけか
- ベクトル検索や RAG も含むのか
- MCP サーバーや業務ツール接続も含むのか
- A2A によるエージェント間通信まで扱うのか
ここが曖昧だと、後から「想定外のトラフィック」が増えて破綻します。
2. 利用者単位で何を見たいのか
- 誰が使ったか
- どのモデルを使ったか
- 何トークン消費したか
- いくらかかったか
- どのツール・エージェント連携が実行されたか
- どの出力が危険だったか
これを答えられないと、本番運用では困りがちです。
3. 障害時の期待値をどこまで持つか
- 代替モデルに自動切替したいのか
- エラーを返してよいのか
- 品質低下を許してでも止めたくないのか
- エージェント連携が途中停止したとき、task 単位で再開したいのか
AI Gateway のルーティング設計は、単なる冗長化ではなく 品質・コスト・可用性のトレードオフ設計です。
4. どこまで中央集権にするか
全部を中央集権化すると統制はしやすいですが、プロダクトチームの自由度が下がることもあります。逆にチームに任せすぎると、コストとセキュリティが散らばります。
AI Gateway は「中央集権か分散か」の二択ではなく、どこまで共通化し、どこからは各チームに委ねるかの境界設計が重要です。
まとめ
AI Gateway は、流行語として見ると少し霧がかっています。しかし、やっていることを分解すると本質はかなり実務的です。
- AI API を直接べた書きすると運用が破綻しやすい
- その破綻ポイントは、認証、コスト、可用性、ガードレール、監査に集中する
- エージェント化が進むと、そこに MCP と A2A の統制も加わる
- それらをアプリから切り離して中央で制御するのが AI Gateway
そして重要なのは、AI Gateway が「特定ベンダー専用の機能名」ではなく、AI を組織運用可能にするための設計パターンだということです。
Azure は APIM を中心に、モデル・ツール・エージェントを同じ管理面へ寄せようとしています。AWS は API Gateway を中心に、Bedrock 前段の企業統制を参照アーキテクチャとして組み上げます。見え方は違いますが、どちらも目指しているのは AI トラフィックをアプリコードの外で統制することです。
もし今後、
- モデルが増える
- チームが増える
- ガバナンス要件が増える
- ツール接続やエージェント間連携が増える
のであれば、AI Gateway は「あると便利」ではなく、AI 基盤を運用品質に引き上げるための前提部品になっていくはずです。
参考リンク（主に公式Docs）
Azure API Management / AI Gateway
- Microsoft Learn, AI gateway in Azure API Management
- Microsoft Learn, Import a Microsoft Foundry API
- Microsoft Learn, Import a language model API
- Microsoft Learn, Import an Amazon Bedrock passthrough language model API
- Microsoft Learn, Limit large language model API token usage
- Microsoft Learn, Backends in API Management
- Microsoft Learn, Log token usage, prompts, and completions for LLM APIs
- Microsoft Learn, GenAI gateway reference architecture using APIM
MCP / A2A
- Microsoft Learn, About MCP servers in Azure API Management
- Microsoft Learn, Expose REST API in API Management as an MCP server
- Microsoft Learn, Expose and govern an existing MCP server
- Microsoft Learn, Secure access to MCP servers in API Management
- Microsoft Learn, Import an A2A agent API (preview)
- A2A Protocol, Agent2Agent (A2A) Protocol Specification
AWS
- AWS Architecture Blog, Building an AI gateway to Amazon Bedrock with Amazon API Gateway
- AWS Docs, Control access to a REST API with API Gateway
- AWS Docs, Usage plans and API keys for REST APIs in API Gateway
- AWS Docs, Throttle API requests for better throughput in API Gateway
- AWS Docs, Stream responses from API Gateway APIs
- AWS Docs, Protect REST APIs in API Gateway with AWS WAF
- AWS Docs, Amazon Bedrock Guardrails
Discussion