Azure AI Foundryでモデルやエージェントを本番運用する場合、AI Gatewayは「あとから足す便利機能」ではなく、トークン使用量・クォータ・監視・ガバナンスを一元管理するための入口になります。2026年5月16日時点で確認できる公式情報では、FoundryリソースにAI Gatewayを追加すると、背後でAzure API Management（APIM）が使われ、モデルデプロイへのアクセスをプロジェクト単位で制御できるようになります。(Microsoft Learn)
特に重要なのは、新規プロジェクトはAI Gatewayが既定で有効になる一方、既存プロジェクトは手動で追加が必要な点です。すでにAzure AI Foundryを使っている組織では、設定を有効化しただけで全プロジェクトに適用されたと思い込むと、リクエストがゲートウェイを通らず、トークン制限や監査の対象外になる可能性があります。(Microsoft Learn)
Azure AI FoundryのAI Gatewayで何が変わるのか
AI Gatewayは、クライアントアプリとFoundry内のモデル・ツールなどの間に置かれる制御ポイントです。関連付け後は、対象プロジェクトのリクエストがAPIMインスタンスを経由し、プロジェクトごとにTPM（Tokens Per Minute）やクォータを管理できます。(Microsoft Learn)
従来、開発チームごとにモデルデプロイへ直接アクセスしていた環境では、あるチームの大量利用が他チームの処理を圧迫したり、コスト増の原因が特定しにくくなったりします。AI Gatewayを使うと、プロジェクト単位で上限を設けられるため、PoC、本番アプリ、社内エージェント、部門別利用を分けて管理しやすくなります。
| 変更点 | 実務上の意味 |
|---|---|
| FoundryポータルからAI Gatewayを追加できる | APIMを個別に細かく構成しなくても、Foundryリソース単位でゲートウェイを関連付けやすくなる |
| 背後でAzure API Managementを使用する | 既存のAPIM運用、監視、ネットワーク、RBAC設計の影響を受ける |
| 新規プロジェクトは既定で有効 | 今後作るプロジェクトは統制対象にしやすい |
| 既存プロジェクトは手動で有効化 | 移行時の見落としポイント。既存アプリの棚卸しが必要 |
| トークン制限・クォータをプロジェクト単位で設定可能 | チーム別、アプリ別、環境別に利用上限を分けられる |
| APIMのメトリックやログで確認できる | 監査、障害調査、利用状況の可視化に使える |
管理者が最初に確認すべき前提条件
AI Gatewayの設定で最もつまずきやすいのは、ポータル操作そのものではなく、権限・APIMインスタンス・ネットワーク条件の不足です。
公式情報では、新しくAPIMインスタンスを作る場合は対象リソースグループまたはサブスクリプションの共同作成者または所有者が必要です。既存APIMを使う場合は、そのAPIMインスタンスに対してAPI Management Service Contributorまたは所有者の権限が必要です。(Microsoft Learn)
設定前チェックリスト
| 確認項目 | 見るべきポイント | 不備があると起きること |
|---|---|---|
| Azureサブスクリプション | FoundryリソースとAPIMを配置・参照できるか | APIM作成や選択ができない |
| Foundry側の権限 | Foundryリソースの管理コンソールにアクセスできるか | AI Gatewayタブで設定できない |
| APIM側の権限 | 既存APIMにAPI Management Service Contributor以上があるか | 既存APIMが候補に出ない、関連付けできない |
| テナント・サブスクリプション | FoundryリソースとAPIMが同じMicrosoft Entraテナント、同じサブスクリプションか | 既存APIMが一覧に表示されない |
| APIMのSKU | v2レベルのAPIMか | 既存APIMをAI Gatewayに使えない |
| 既存の関連付け | APIMが別のAI Gatewayに関連付いていないか | 候補に表示されない |
| ネットワーク | Foundryがプライベート構成の場合、APIMもプライベートアクセス可能か | ゲートウェイ経由の通信に失敗する可能性がある |
既存APIMを使う場合、同じテナント・同じサブスクリプション・v2レベル・未関連付け・必要権限の条件をすべて満たす必要があります。いずれかが欠けると、Foundryポータルで「Use existing APIM」を選んでも対象インスタンスが表示されません。(Microsoft Learn)
APIMは新規作成と既存利用のどちらを選ぶべきか
AI Gateway追加時には、APIMを新規作成するか、既存APIMを使うかを選びます。公式手順では、新規作成を選ぶとBasic v2 SKUのAPIMインスタンスが作成されます。Basic v2はSLAサポート付きの開発・テスト向けと説明されています。(Microsoft Learn)
本番利用や高スループットが必要な場合は、既存のStandard v2またはPremium v2のAPIMインスタンスを検討するのが安全です。特に、部門横断で複数のAIアプリやエージェントを集約する場合、将来的なスケール、監視、ネットワーク分離、運用権限を先に設計しておく必要があります。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 新規作成 | 検証環境、PoC、小規模な開発チーム | 既定ではBasic v2が作成されるため、本番要件を満たすか確認が必要 |
| 既存APIMを利用 | 本番環境、複数チーム利用、既存のAPI基盤に統合したい場合 | 条件を満たさないAPIMは候補に出ない |
| Standard v2 / Premium v2の既存APIM | 高スループット、プライベート接続、厳格なガバナンスが必要な場合 | APIM側の運用設計とFoundry側のプロジェクト設計を合わせる必要がある |
AI GatewayにはAPIMのFreeレベルが含まれるとされていますが、コストや適用条件は時期や契約条件で変わる可能性があります。監視ログ、関連リソース、スケール要件を含めて、必ずAzureの料金ページと社内の課金管理ルールで確認してください。(Microsoft Learn)
FoundryポータルでAI Gatewayを構成する手順
設定作業は、Foundryポータルの管理コンソールから行います。実際のUIは頻繁に更新されるため、画面上の文言や手順番号が公式スクリーンショットと少し違う場合があります。その場合は、「AI Gateway」「Admin console」「Add AI Gateway」に相当する項目を探してください。(Microsoft Learn)
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Foundryにサインイン | New Foundryのトグルがオンか確認 |
| 2 | Operate から Admin console を開く | 対象リソースを管理できる権限で入っているか |
| 3 | AI Gateway タブを開く | タブが見えない場合は権限を確認 |
| 4 | Add AI Gateway を選択 | 対象のFoundryリソースを選ぶ |
| 5 | Create new または Use existing APIM を選択 | 本番用途ならSKUとネットワーク要件を確認 |
| 6 | ゲートウェイ名を入力して追加 | 命名規則を決めておくと運用しやすい |
| 7 | 状態が Enabled になるまで確認 | Provisioning の間は待機して更新 |
| 8 | 既存プロジェクトをゲートウェイに追加 | 新規プロジェクトと違い、既存プロジェクトは手動追加が必要 |
| 9 | テスト呼び出しを実行 | APIMのメトリックとログで経由を確認 |
ここでの重要ポイントは、リソースレベルでAI Gatewayが有効でも、既存プロジェクトが自動的に保護されるわけではないことです。移行時は、既存プロジェクト一覧を作り、どのプロジェクトをいつゲートウェイへ追加したかを記録しておくと、抜け漏れを防げます。
ゲートウェイが正しく動いているか確認する方法
AI Gatewayを作成した後は、設定画面で有効化されたことを見るだけでは不十分です。実際のモデル呼び出しがAPIMを経由しているか、必ずAzureポータル側で確認します。
公式手順では、Foundryリソースに接続されたAPIMインスタンスをAzureポータルで開き、Monitoring > Metrics から Requests を確認します。対象プロジェクトのモデルデプロイにテスト呼び出しを行い、要求数が増えるかを見ます。詳細ログでは GatewayLogs テーブルを確認し、AI Gatewayに対応するAPI名と 200 応答のエントリを探します。(Microsoft Learn)
確認すべき観点
| 確認対象 | 正常な状態 | 異常時に疑うこと |
|---|---|---|
| AI Gatewayの状態 | リソース側で Enabled | プロビジョニング未完了 |
| プロジェクトのGateway status | 対象プロジェクトが Enabled | 既存プロジェクトを追加していない |
| APIMメトリック | テスト呼び出し後にRequestsが増える | リクエストがゲートウェイを通っていない |
| APIMログ | GatewayLogs に該当APIのログが出る | APIM関連付け、プロジェクト有効化、ログ設定を確認 |
| トークン制限 | 上限超過時に制限レスポンスが返る | 制限未設定、またはプロジェクトがゲートウェイ未使用 |
トークン制限を設定している場合は、意図的に上限を超えるテストを行い、制限が適用されるか確認します。FoundryのAI Gateway手順では、制限超過時にAPIMが 429 Too Many Requests を返すと説明されています。(Microsoft Learn)
一方、APIMの llm-token-limit ポリシー一般では、トークンのレート制限超過時は 429 Too Many Requests、クォータ超過時は 403 Forbidden が返るとされています。アプリ側では429だけでなく、403も運用上の制限応答として扱えるようにしておくと安全です。(Microsoft Learn)
開発者への影響：API呼び出しとエラーハンドリングを見直す
AI Gatewayを導入すると、開発者にとって最も大きな変化は「モデルを呼ぶだけ」では済まなくなることです。利用量の上限、制限時の応答、ログ監査、プロジェクト単位のガバナンスを前提に、アプリケーション側の設計を見直す必要があります。
特に確認すべきなのは、次の4点です。
| 観点 | 開発者が確認すべきこと |
|---|---|
| 制限時の挙動 | 429や403を受けたときに、再試行、待機、ユーザー通知を適切に行う |
| タイムアウト | APIM経由になってもアプリ側のタイムアウト設定が適切か確認する |
| ログ | プロンプトや応答内容をログに残す場合、機密情報や個人情報の扱いを確認する |
| 環境差分 | 開発・検証・本番で異なるクォータやTPMを設定する場合、設定値を文書化する |
例えば、社内チャットボットでAI GatewayのTPM上限を超えた場合、ユーザーに単に「エラー」と表示するのではなく、「現在利用が集中しています。数分後に再試行してください」のように返す方が実用的です。バックエンドでは Retry-After ヘッダーがある場合にそれを参照し、無制限の即時リトライを避けます。
管理者への影響：ガバナンス設計をプロジェクト単位で作る
AI Gatewayは、単にAPIの前段に置くルーティング機能ではありません。Azure API ManagementのAI Gateway機能は、AIモデル、エージェント、ツールを保護、スケーリング、監視、管理するための機能群として位置付けられています。(Microsoft Learn)
管理者は、どのプロジェクトにどの程度のトークンを割り当てるかを、利用目的に応じて決める必要があります。全プロジェクトに同じ上限を設定すると、PoCには過剰、本番アプリには不足という状態になりがちです。
プロジェクト別の設定例
| プロジェクト種別 | 推奨される考え方 | 設定例 |
|---|---|---|
| 個人検証・PoC | コスト暴走を防ぐため低めに設定 | 小さめのTPM、日次または月次クォータ |
| 社内業務アプリ | 利用時間帯と利用人数に合わせる | 業務ピークに耐えるTPM、部門別クォータ |
| 顧客向け本番アプリ | 可用性と公平性を優先 | 高めのTPM、監視アラート、段階的な引き上げ |
| エージェント・ツール連携 | ループや連続呼び出しを想定 | 厳しめの上限、ログ監査、異常検知 |
AI Gatewayでは、複数チームのトークン消費を抑制し、1つのプロジェクトが容量を独占するのを防ぎ、コスト管理や規制対象ワークロードの利用上限にも役立つと説明されています。(Microsoft Learn)
移行時に失敗しやすいポイント
既存のAzure AI Foundry環境にAI Gatewayを追加する場合、次のような失敗が起きやすくなります。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 既存プロジェクトに制限が効かない | プロジェクトをゲートウェイに追加していない | 既存プロジェクトを一覧化し、Gateway statusを確認する |
| 既存APIMが選択肢に出ない | テナント、サブスクリプション、SKU、権限、関連付け条件のいずれかを満たしていない | APIMの条件を1つずつ確認する |
| ゲートウェイ作成後にすぐ見えない | プロビジョニング中 | 数分待って更新する。Basic v2では通常5〜10分程度かかる場合がある |
| リクエストがゲートウェイを通らない | リソースだけ有効で、プロジェクトが未有効 | リソースとプロジェクトの両方でEnabledを確認する |
| モデル呼び出しで500エラーが出る | APIMエンドポイントの準備未完了、またはモデルデプロイのマッピング不備 | まずゲートウェイなしでモデルにアクセスできるか確認し、APIMログを確認する |
| 削除後に別ワークロードへ影響する | 共有APIMを誤って削除 | 専用APIMか共有APIMかを確認してから削除する |
公式トラブルシューティングでも、既存プロジェクトの手動追加漏れ、権限不足、既存APIMの条件不一致、プロビジョニング未完了、500エラー時のAPIMログ確認が挙げられています。(Microsoft Learn)
プライベートネットワーク構成ではAPIM側も合わせて設計する
Foundryリソースでパブリックネットワークアクセスを無効にしている場合は、APIMインスタンス側もプライベートにアクセスできる構成にする必要があります。公式情報では、この場合、プライベートエンドポイントを持つStandard v2またはPremium v2、または仮想ネットワークに挿入されたPremium v2の利用が示されています。(Microsoft Learn)
これはセキュリティ部門との調整が必要になりやすいポイントです。AI Gatewayだけを有効にしても、ネットワーク経路、DNS、プライベートエンドポイント、VNet、ログ出力先が整っていなければ、本番通信は安定しません。
本番展開前には、少なくとも次の点を確認してください。
| 確認項目 | 実務上の確認内容 |
|---|---|
| 通信経路 | クライアントからAPIM、APIMからFoundry関連リソースへ到達できるか |
| DNS | プライベートエンドポイント利用時に名前解決が正しく行われるか |
| 監視 | APIMメトリック、ログ、アラートが運用チームに届くか |
| 障害時対応 | APIM障害、モデル障害、制限超過を切り分けられるか |
| セキュリティ | プロンプトや応答ログの保存範囲が社内ルールに合っているか |
ロール名変更にも注意する
Microsoft FoundryのRBACロールは名称変更が進んでおり、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前はAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerという名称でした。ロールIDと主要な権限は変わらないものの、移行期間中は旧名称が一部に残る可能性があります。(Microsoft Learn)
管理者は、手順書や社内申請フォームのロール名を更新しておくと混乱を避けられます。特に「Azure AI Ownerが必要」と書かれた古い運用文書と、ポータル上の「Foundry Owner」表記が混在すると、権限申請で差し戻しが起きやすくなります。
本番展開前の最終チェック
AI Gatewayを本番に展開する前に、単に「作成できたか」ではなく、「統制したいリクエストが確実に通っているか」を確認します。
| チェック項目 | 合格基準 |
|---|---|
| 対象プロジェクトの棚卸し | 既存プロジェクトを含め、適用対象と対象外が明確になっている |
| APIMの選定 | 開発・検証・本番の要件に合うSKUを選んでいる |
| 権限 | Foundry側、APIM側、リソースグループ側の必要権限が整理されている |
| ネットワーク | パブリックまたはプライベート構成に合わせて通信確認済み |
| トークン制限 | TPMとクォータの設定値に根拠がある |
| アプリ側の例外処理 | 429、403、500を区別して処理できる |
| ログと監視 | APIMメトリック、GatewayLogs、アラートが確認済み |
| ロール名 | Foundry系の新旧ロール名を社内文書に反映済み |
| クリーンアップ | 専用APIMか共有APIMかを識別し、削除手順を誤らない |
まず取るべき行動
Azure AI FoundryでAI Gatewayを使う場合、最初にやるべきことはポータルでボタンを押すことではありません。既存プロジェクト、利用チーム、モデルデプロイ、トークン消費、APIMの候補、ネットワーク条件を棚卸しすることです。
そのうえで、検証環境では新規APIMで動作確認し、本番では既存のStandard v2またはPremium v2のAPIMを使うべきかを判断します。設定後は、対象プロジェクトのGateway status、APIMのRequestsメトリック、GatewayLogs、制限超過時の429または403の扱いまで確認してください。
AI Gatewayは、Azure AI FoundryのAI/Copilotアプリを「作れる状態」から「安全に運用できる状態」へ移すための重要な管理ポイントです。特に既存プロジェクトの手動追加、APIMのSKUと権限、プライベートネットワーク構成、アプリ側のエラーハンドリングは、展開前に必ず確認しておきましょう。
コメント