結論から言うと、Azure API ManagementのAI gatewayは、生成AIアプリが利用するモデル、エージェント、MCPツールなどを、既存のAPI Management上で安全に公開・制御・監視するための機能群です。単にAI APIを中継するだけではなく、認証、トークン制限、負荷分散、セマンティックキャッシュ、ログ、ガバナンスまでまとめて管理できる点が重要です。Microsoft公式情報では、AI gatewayはAPI Managementの既存APIゲートウェイを拡張する機能であり、別製品として切り離されたものではありません。(Microsoft Learn)
特に2026年5月時点で注目すべきなのは、Microsoft Foundryとの直接統合、LLM API向けのトークン制御、MCPサーバーやA2AエージェントAPIへの対応、そしてAI利用状況をAzure MonitorやApplication Insightsで追跡しやすくなった点です。管理者は「どのAIバックエンドを、誰が、どれだけ、どの経路で使うのか」を棚卸しし、開発者はAPIM経由の認証・エラー処理・トークン消費を前提に実装を見直す必要があります。(Microsoft Learn)
Azure API ManagementのAI gatewayとは
Azure API ManagementのAI gatewayは、AIバックエンドを企業システムで運用しやすくするためのゲートウェイ機能です。対象になるのは、OpenAI Chat Completions API、Responses API、Anthropic Messages API、Microsoft Foundry上のモデル、Amazon Bedrockなど外部プロバイダーのモデル、リモートMCPサーバー、A2AエージェントAPI、セルフホストされたAIエンドポイントなどです。Anthropic Messages APIについては、現時点でAPI Management v2 tiersでのサポートと説明されています。(Microsoft Learn)
従来のAPI ManagementはREST APIやバックエンドサービスの公開、認証、流量制御に使われてきました。AI gatewayでは、その考え方を生成AI向けに拡張し、トークン単位の制限、プロンプトや応答のログ、AI Content Safetyとの連携、セマンティックキャッシュ、複数AIエンドポイントへの負荷分散などを扱えるようにしています。(Microsoft Learn)
重要なのは、AI gatewayが「AI API専用の入口」を増やすだけの機能ではないことです。企業内でAI利用が増えると、部門ごとの利用量、モデルごとのコスト、APIキーの管理、監査ログ、障害時の切り替えが問題になります。AI gatewayは、これらをAPI Managementのポリシーと監視機能で統制するための仕組みです。
2026年5月時点で押さえる主な変更点
| 変更点・強化点 | 実務上の意味 | 確認すべきポイント |
|---|---|---|
| Microsoft Foundryとの直接統合 | Foundry環境内からモデル、エージェント、ツールのAIトラフィックを管理しやすくなる | Foundry側でAI gatewayを作成するか、既存のAPI Managementを関連付けるかを決める |
| LLM API、MCP、A2Aへの対応範囲拡大 | モデルAPIだけでなく、エージェントやツール呼び出しもガバナンス対象にできる | 公開するAPI、MCPツール、A2Aエージェントの範囲を棚卸しする |
| トークン単位のレート制限・クォータ | リクエスト数ではなく、生成AIの実コストに近い単位で利用量を制御できる | 部門、アプリ、ユーザー単位のcounter-key設計を決める |
| セマンティックキャッシュ | 意味が近いプロンプトに対して過去の応答を再利用し、レイテンシとバックエンド呼び出しを減らせる | キャッシュしてよい応答か、ユーザーごとに分離すべきかを判断する |
| 負荷分散とサーキットブレーカー | 複数のAIバックエンドを使い分け、障害時に不安定なバックエンドへの転送を止められる | PTU、従量課金、リージョン、優先度の設計を行う |
| AI利用ログとメトリック | トークン消費、プロンプト、応答、モデル名などを分析しやすくなる | 監査・課金・品質改善のどこまでログを取得するか決める |
Microsoft Foundryとの統合では、AI gatewayをFoundryリソースに関連付けることで、モデルのトークンクォータやレート制限をFoundry側の画面から構成できるようになります。エージェントやMCPツールについても、Foundryの管理面でインベントリ化やガバナンスを行えると説明されています。(Microsoft Learn)
一方で、高度なカスタムポリシー、エンタープライズネットワーク、フェデレーションされたゲートウェイ構成などが必要な場合は、Azure API Managementのフル機能を使う構成が前提になります。Foundry統合だけで完結させるか、API Management側で詳細に設計するかは、運用要件で判断する必要があります。(Microsoft Learn)
影響範囲：見直しが必要なシステム
AI gatewayの影響が大きいのは、複数のアプリや部門が同じAIモデルを利用している環境です。Microsoft公式ドキュメントでも、AIサービスの主要リソースであるトークンは、アプリ、開発チーム、部門など複数の利用者に配分する必要があり、1つのアプリがTPM枠を使い切って他のアプリをブロックしないようにする必要があると説明されています。(Microsoft Learn)
| 対象 | 影響 | 優先して確認すること |
|---|---|---|
| Azure OpenAIやMicrosoft Foundryのモデルを複数アプリから使っている環境 | トークン消費、クォータ、認証、ログ設計の見直しが必要 | アプリ単位・部門単位の利用上限 |
| 外部LLMプロバイダーも併用している環境 | APIごとに認証・流量制御・監視が分散しやすい | API Management上でのバックエンド定義とポリシー統一 |
| REST APIをMCPツールとして公開したい環境 | 既存APIがAIエージェントから呼び出される可能性がある | 公開する操作、Products、サブスクリプション制御 |
| A2AエージェントAPIを扱う環境 | エージェント間通信もAPI管理の対象になる | Agent card、JSON-RPC、監視属性、セキュリティ要件 |
| 単一アプリが単一モデルだけを使う小規模環境 | すぐに大きな移行は不要な場合もある | 将来の利用増に備えたログと上限設定 |
特にMCPは、既存のREST APIをAIエージェントが利用する「ツール」として公開できるため、便利な一方で、公開範囲を誤ると本来AIから呼ばせるべきでない操作まで利用可能になります。API ManagementでMCPサーバーとして公開する場合は、対象操作を選択し、Productやサブスクリプションを通じてアクセス管理する設計が重要です。(Microsoft Learn)
管理者が確認すべき設定
認証と認可：APIキー、Managed Identity、OAuthを使い分ける
AI gatewayを導入する際は、まずAIバックエンドへの認証方式を確認します。API Managementでは、AI APIへの認証方法としてAPIキーまたはMicrosoft Entra IDのManaged Identityを使う方法が示されています。また、ユーザーやクライアントごとに細かく制御したい場合は、OAuth 2.0トークンによる事前認可も選択肢になります。(Microsoft Learn)
Azure OpenAIやMicrosoft Foundry上のモデルを使う場合、可能であればManaged Identityの利用を優先すると、APIキーの配布やローテーション負荷を減らせます。APIキーを使う場合でも、API ManagementのNamed valuesにシークレットとして保存し、必要に応じてKey Vault参照を使う設計が現実的です。(Microsoft Learn)
確認すべきポイントは次の通りです。
- APIキーをアプリに直接持たせていないか
- API ManagementのManaged Identityに適切なロールが付与されているか
- チーム、アプリ、ユーザー単位でサブスクリプションやProductを分けているか
- OAuthを使う場合、トークンの発行元、スコープ、クレームをポリシーで検証しているか
- MCPサーバーやA2AエージェントAPIにも同じ認可方針を適用しているか
トークン制限：リクエスト数ではなく消費トークンで制御する
生成AIでは、1リクエストあたりのコストや負荷が大きく変わります。短い質問と長文要約では、同じ1回のAPI呼び出しでも消費トークンが大きく異なります。そのため、通常のAPIレート制限だけでなく、LLM向けのllm-token-limitポリシーでTPMや期間別クォータを設定することが重要です。
llm-token-limitポリシーでは、指定したトークンレートを超えると429 Too Many Requests、指定したクォータを超えると403 Forbiddenが返されます。また、サブスクリプションID、送信元IP、ポリシー式で定義した任意のキーをcounter-keyとして使えます。(Microsoft Learn)
例として、サブスクリプション単位で1分あたり500トークンに制限する場合は、次のような考え方になります。
<llm-token-limit
counter-key="@(context.Subscription.Id)"
tokens-per-minute="500"
estimate-prompt-tokens="false"
remaining-tokens-variable-name="remainingTokens" />ただし、トークン制限には注意点があります。プロンプトトークンを事前推定すると、上限超過時に不要なバックエンド呼び出しを減らせますが、性能への影響があります。ストリーミング時は推定が使われ、並行リクエストでは応答が返るまで正確な消費量が分からないため、一時的に上限を超える可能性があります。また、トークン使用量は適用されたゲートウェイごとに追跡され、インスタンス全体で自動集約されるわけではありません。(Microsoft Learn)
実務では、次のように設計すると管理しやすくなります。
| 制御単位 | 向いているケース | 注意点 |
|---|---|---|
| サブスクリプションID | 部門、アプリ、チーム単位で上限を分けたい | 1つのサブスクリプションを複数アプリで共有しない |
| ユーザーID | SaaSや社内ポータルで個人単位の利用量を見たい | ヘッダー値を信用せず、認証済みトークンから取得する |
| IPアドレス | 簡易的な検証環境や一時的な制限 | NAT配下では複数利用者が同じIPになる |
| カスタムキー | テナント、プロジェクト、契約プラン単位で制御したい | 命名規則とスコープをドキュメント化する |
セマンティックキャッシュ：コスト削減に効くが用途を選ぶ
セマンティックキャッシュは、完全一致だけでなく、意味が近いプロンプトに対して過去の応答を再利用する仕組みです。API Managementでは、Azure Managed RedisまたはRediSearch互換の外部キャッシュ、Embeddings API、llm-semantic-cache-lookup、llm-semantic-cache-storeポリシーを使って構成します。(Microsoft Learn)
向いているのは、社内FAQ、製品仕様の説明、定型的な問い合わせ、ドキュメント要約など、同じような質問が繰り返される用途です。逆に、ユーザーごとに回答が変わる問い合わせ、機密情報を含む応答、最新状態が重要な回答、法務・医療・金融のように誤った再利用が問題になりやすい用途では慎重に設計する必要があります。
セマンティックキャッシュを有効化する手順では、チャット用のモデルデプロイに加えて、キャッシュ判定に使うEmbeddings APIのデプロイ、Managed Identity認証、RediSearchモジュールが有効なAzure Managed Redisが前提として示されています。RediSearchモジュールは既存キャッシュに後から追加できないため、Redisを新規作成する段階で確認が必要です。(Microsoft Learn)
スケールと可用性：APIMだけを増強してもAIバックエンド不足は解決しない
API Managementにはゲートウェイのスケールユニット追加やマルチリージョン配置といったスケール機能があります。ただし、Microsoft公式ドキュメントでは、API Managementのゲートウェイ容量を増やしても、AIバックエンド側のスケールとトラフィック分散も必要だと説明されています。マルチリージョン構成では、API Managementゲートウェイと同じリージョンにAIバックエンドを配置することが例として示されています。(Microsoft Learn)
また、API Managementのバックエンド負荷分散では、ラウンドロビン、重み付け、優先度ベース、セッション認識の方式を選べます。PTUを購入したMicrosoft Foundryエンドポイントを優先し、従量課金エンドポイントをバックアップにする、といった設計も考えられます。サーキットブレーカーでは、応答しないバックエンドへの転送を止め、Retry-Afterヘッダーに基づく動的な復旧時間も扱えます。(Microsoft Learn)
本番展開前には、通常時の負荷試験だけでなく、次のテストも行うべきです。
- 主要バックエンドが429を返したときの振る舞い
- 1つのリージョンのAIバックエンドを停止したときの切り替え
- PTU枠を使い切ったときのフォールバック
- ストリーミング応答中に障害が起きた場合のクライアント処理
- サーキットブレーカー復旧後に優先バックエンドへ戻るか
ログと監視：取得範囲を決めてから有効化する
AI gatewayでは、トークン使用量、モデル名、プロンプト、応答などをAzure Monitorに記録できます。診断設定では「generative AI gateway」に関連するログをLog Analyticsワークスペースへ送信できます。また、API単位でプロンプトと補完結果のログを有効化する設定も用意されています。(Microsoft Learn)
ただし、プロンプトや応答には個人情報、社内情報、顧客データが含まれる可能性があります。ログを「取れるから取る」のではなく、目的別に取得範囲を決めることが重要です。
| 目的 | 取得する主なデータ | 注意点 |
|---|---|---|
| コスト管理 | prompt tokens、completion tokens、total tokens、モデル名 | アプリ・部門別に集計できるキーを設計する |
| 障害調査 | ステータスコード、バックエンド、CorrelationId | プロンプト本文が不要なら本文ログは避ける |
| 品質改善 | プロンプト、応答、モデル名 | サンプリング、マスキング、保存期間を決める |
| 監査 | 呼び出し元、時刻、対象API、利用量 | アクセス権限とログ保持ポリシーを明確にする |
言語モデルAPI向けのAnalyticsでは、Log Analyticsに集約されたデータをもとに、トークン消費やリクエスト状況を確認できます。ApiManagementGatewayLlmLogでは、言語モデルのリクエストと応答、トークン消費、モデルデプロイなどの詳細を確認できます。(Microsoft Learn)
開発者が実装前に確認すべきこと
AI gatewayを導入すると、クライアントアプリはAIバックエンドを直接呼ぶのではなく、API Managementのエンドポイントを呼び出す構成になります。そのため、開発者は単にURLを差し替えるだけでなく、エラー処理、認証ヘッダー、リトライ、ストリーミング、ログ用ヘッダーを見直す必要があります。
特に重要なのは、429 Too Many Requestsと403 Forbiddenの扱いです。429は一時的なレート超過を示すため、Retry-Afterを考慮した待機や指数バックオフが必要です。一方、403は期間クォータ超過の可能性があるため、単純にリトライしても解決しません。利用者への通知、上限引き上げ申請、別プランへの切り替えなど、業務フロー側の対応が必要になります。(Microsoft Learn)
開発チームで確認すべき項目は次の通りです。
- API Management経由のベースURLに切り替えているか
- バックエンドのAPIキーをアプリ側に残していないか
- 429、403、5xx、タイムアウトを区別して処理しているか
- ストリーミング応答時の途中切断を考慮しているか
- ユーザーIDやテナントIDをログ・メトリック用に安全に渡しているか
- セマンティックキャッシュの結果を利用者に返してよい画面か
- プロンプトや応答がログに残る可能性を利用規約や社内ルールと照合しているか
MCPサーバーやA2AエージェントAPIを使う場合は、AIエージェントが「どの操作を実行できるか」を開発者だけで判断しないことも大切です。API Managementでは、REST APIの一部操作だけをMCPツールとして公開でき、A2AエージェントAPIも他のAPI種別と並べて管理できます。公開対象は、セキュリティ管理者、業務責任者、APIオーナーを含めて決めるべきです。(Microsoft Learn)
移行・展開の進め方
AI gatewayは、いきなり全AIアプリに適用するより、段階的に展開する方が安全です。既存のAIアプリが本番稼働している場合は、まず利用状況を見える化し、小さな範囲でポリシーを検証してから本番トラフィックを切り替えます。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 1 | AIバックエンドの棚卸し | モデル、プロバイダー、リージョン、利用アプリ、APIキー保管場所が一覧化されている |
| 2 | 利用者単位の整理 | 部門、アプリ、テナント、ユーザー単位の上限設計が決まっている |
| 3 | Foundry統合かAPIM中心かを選択 | Foundryの簡易管理で十分か、カスタムポリシーが必要か判断できている |
| 4 | 認証方式を設定 | Managed Identity、Named values、OAuthの使い分けが決まっている |
| 5 | トークン制限を小さく試す | 429、403、残トークン通知、超過時の画面表示を確認済み |
| 6 | 可用性設計を入れる | 負荷分散、優先度、サーキットブレーカー、リージョン構成をテスト済み |
| 7 | ログとダッシュボードを整備 | トークン消費、モデル別利用、異常な増加を確認できる |
| 8 | カナリア展開 | 一部アプリやテスト用APIMインスタンスで先行検証する |
| 9 | 本番切り替え | 旧エンドポイントを段階的に停止し、APIM経由に統一する |
Microsoft FoundryでAI gatewayを有効化する場合、既存のAPI Managementインスタンスを使うには、同じMicrosoft Entraテナントと同じサブスクリプションにあること、必要な権限があること、v2 tiersで作成されていること、他のAI Gatewayに関連付けられていないことなどの条件があります。既存プロジェクトは自動では有効化されず、手動でGatewayに追加する必要があります。(Microsoft Learn)
また、API Managementのサービス更新には更新グループの考え方があります。AI Gateway EarlyはAI gateway関連機能を早期に受け取るためのリリースチャネルですが、本番環境では安定性と検証体制を考慮する必要があります。検証用インスタンスで先に試し、本番はDefaultまたは要件に応じてLateを選ぶ、といったカナリア戦略が現実的です。(Microsoft Learn)
Foundry統合とAPI Management中心構成の使い分け
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Microsoft FoundryからAI gatewayを有効化 | Foundry上のモデルやプロジェクト単位で、トークン制限やガバナンスをすばやく始めたい | 既存APIMの関連付け条件、既存プロジェクトの手動有効化を確認する |
| Azure API Management側で詳細設計 | カスタムポリシー、複数プロバイダー、企業ネットワーク、複雑な認可が必要 | ポリシー設計、監視、運用手順を明文化する必要がある |
| 両方を併用 | Foundry管理の利便性を使いつつ、APIMで高度な制御も行いたい | どちらが設定の主導権を持つか、運用責任を決める |
小規模な検証ではFoundry側から始めると導入しやすいでしょう。一方、複数部門でAIを利用し、外部プロバイダーやオンプレミスのツールも含めて統制したい場合は、Azure API Managementを中心に設計した方が後から拡張しやすくなります。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| すべてのアプリで同じサブスクリプションキーを使う | どのアプリがトークンを消費したか分からず、上限も分離できない | アプリ、部門、テナント単位でサブスクリプションやcounter-keyを分ける |
| API Managementだけをスケールする | ゲートウェイは処理できてもAIバックエンドのTPM不足で詰まる | バックエンド側のTPM、PTU、リージョン配置も同時に設計する |
| セマンティックキャッシュを全用途に適用する | ユーザー固有情報や古い回答が再利用される恐れがある | FAQや定型回答から始め、vary-byで利用者単位の分離を検討する |
| プロンプトと応答を無条件にログ出力する | 機密情報や個人情報がログに残る | 目的別にログ項目を絞り、保存期間とアクセス権限を設定する |
v2 tiersのllm-token-limitで同じcounter-keyを複数スコープに使い、値を不一致にする | 予測しにくい挙動につながる可能性がある | スコープごとにキーを分けるか、同じキーではTPM値を一貫させる |
| マルチリージョンでトークン集計を全体集約と誤解する | リージョンやゲートウェイごとの消費量を見誤る | ゲートウェイごとの集計前提でダッシュボードを設計する |
| Foundryの既存プロジェクトを有効化し忘れる | リクエストがgatewayを経由しない | Gateway statusを確認し、既存プロジェクトを手動で追加する |
llm-token-limitポリシーでは、v2 tiersで同じcounter-keyを複数スコープに使う場合、tokens-per-minuteの値を一貫させる必要があると説明されています。また、トークン追跡は適用された各ゲートウェイで独立して行われ、マルチリージョン全体で自動集約されるわけではありません。(Microsoft Learn)
管理者・開発者向けチェックリスト
本番展開前に、最低限次の項目を確認してください。
- 利用中のAIモデル、エージェント、MCPツール、外部LLMプロバイダーを一覧化した
- API Managementのサービス階層と、使いたい機能の対応状況を確認した
- Foundry統合を使う場合、既存APIMの関連付け条件を満たしている
- APIキーをアプリに直接持たせず、Managed Identityまたは安全なNamed valuesで管理している
- アプリ、部門、ユーザー単位のトークン上限を設計した
- 429、403、5xxのエラー処理をクライアント側で分けている
- セマンティックキャッシュを適用するAPIと適用しないAPIを分けた
- プロンプトと応答ログの取得範囲、保存期間、閲覧権限を決めた
- 負荷分散、サーキットブレーカー、バックエンド障害時の挙動をテストした
- カナリア環境または検証用APIMインスタンスで先行確認した
- 本番切り替え後のトークン消費、レイテンシ、エラー率を監視するダッシュボードを用意した
まずはAIバックエンドの棚卸しから始める
Azure API ManagementのAI gatewayは、生成AIの導入が「試作」から「全社利用」へ進む段階で特に効果を発揮します。モデルAPIを直接呼ぶ構成のまま利用者が増えると、APIキー管理、トークン枯渇、ログ不足、バックエンド障害、ツール公開範囲の管理が難しくなります。
最初に行うべきことは、新機能をすべて有効化することではありません。まず、どのアプリがどのAIバックエンドを使っているか、誰が利用量の責任を持つか、どのデータをログに残してよいかを整理します。そのうえで、Managed Identity、トークン制限、ログ、負荷分散、セマンティックキャッシュを段階的に適用すると、運用リスクを抑えながらAI gatewayを展開できます。
管理者はガバナンスと監視の設計から、開発者はAPIM経由の呼び出しとエラー処理の見直しから着手してください。AI gatewayは、AI APIを便利に使うための入口であると同時に、企業として安全に使い続けるための統制ポイントになります。
コメント