AI Gatewayティアでの資産のガバナンスと保護(プレビュー)

対象:AIゲートウェイティア(プレビュー)

AI Gateway tier(プレビュー版)を使って、AIモデル、Microsoft Foundryリソース、Azure OpenAIデプロイメント、MCPサーバーの前に共通コントロールを配置しましょう。 プラットフォームチームは、必要な資産を使い続ける間、ガバナンス、セキュリティ、監視設定を一か所で適用できます。 ゲートウェイをプライベートバックエンドやクライアントに接続するには、「 プライベートネットワーキングの設定」を参照してください。

AI Gateway ティアはプレビュー版です。 パイロットや本番環境の検証に活用しましょう。 特徴、領域、制限、テレメトリーフィールド、セットアップフローは一般公開前に変更されることがあります。 プレビューはクイックプロビジョニングをサポートしていますが、信頼性は最善の努力です。 エラーを監視し、重要なアプリケーションに対してロールバックパスを維持しましょう。

前提条件

• AIゲートウェイ層のインスタンスです。
• AIゲートウェイ層インスタンスの管理権限。
• あなたが管理するプロバイダーモデルやバックエンドへのアクセス。
• マネージデンティティ・バックエンド認証の場合、バックエンドリソースに必要な役割を割り当てる権限を付与します。
• Application Insightsや他のOpenTelemetry(OTLP)互換エンドポイントなどのテレメトリ宛先へのアクセス。

ガバナンス ポリシー

ガバナンスポリシーは、リクエストがバックエンドモデルやツールに届く前にAIトラフィックを保護します。 プレビューでは、ポータル内でポリシーをビジュアルカードとして設定します。コントロールプレーンAPIでは、各ポリシーは構造化されたJSONオブジェクトです。 ポリシータイプを選択し、適用するモデルやツールを選び、検証済みのフィールドを埋めて「 作成」を選択します。 XMLを書いたり、ポリシーの断片を貼り付けたり、ポリシー式を使う必要はありません。 ポリシーは構造化されたオブジェクトであるため、Azure Policyを使えば複数のゲートウェイ全体で監査や強制が可能です。

各ポリシーを選択したモデルやツールに適用します。 コンテンツ安全性などの基準管理を設定するには、すべての該当する資産を選択してください。 あるモデルまたはツールで、リスク、能力、またはネットワーク要件が異なる場合は、より限定的なポリシーを適用してください。

複数のポリシーがリクエストに適用される場合、ゲートウェイはリクエストをバックエンドに転送する前にそれらすべてを評価します。 もし何らかのポリシーがリクエストをブロックした場合、ゲートウェイは停止し、バックエンドを呼び出すことなくエラーを返します:

トークン制限とリクエスト制限の両方が適用される場合、リクエストは両方を満たさなければなりません。

すべての方針がすべての資産タイプに適用されるわけではありません。 コンテンツセキュリティ、IPフィルター、リクエストレート制限はモデルとMCPツールの両方に適用されます。 トークンレートの制限はモデルに適用されます。

以下の図は、リクエストフローでガバナンスポリシーが適用される場所を示しています。

ポリシーを構成するには、次の手順を実行します。

1. AIゲートウェイのティアポータルで 、「ポリシー>ポリシーを追加」を選択します。
2. タイプで、コンテンツセーフティ、IPフィルター、トークンレート制限、リクエストレート制限など追加したいポリシー(ガードレール)を選択します。
3. アセットでは、ポリシーが適用されるモデルやツールを選択します。 ゲートウェイ全体のベースラインでは、すべての該当する資産を選択します。
4. 「Configure」で、検証済みフィールドの値を入力または選択し、「Create」を選択します。

まずは以下の保険タイプから始めましょう:

• コンテンツセキュリティ:バックエンドに届く前に、Azure AI Content Safetyで受信したプロンプトやツール入力を検査しましょう。 カテゴリーごとの重症度閾値(憎悪、性的、暴力、自傷行為)を設定し、4つ または8つの重症度レベル を選択してより細かくコントロールします。 Prompt Shieldを有効にして脱獄やプロンプト注入の試みを検出し、特定のキーワードやフレーズ(競合他社名や禁止用語など)を拒否するブロックリストを追加してください。 ブロックするか、ログを取るか、あるいは両方かを選べます。ブロックされた通話はクライアントにエラーを返します。 コンテンツセキュリティにはAzure AI Content Safetyリソースが必要で、構成ステップでポリシーバックエンドとして選択します。 正当なトラフィックを拒否せずにキャリブレーションするには、ログオンリーモードで始め、実際のトラフィックに対して閾値を調整し、その後ブロッキングに切り替えます。 モデルやMCPツールに適用されます。
• IPフィルター:IPv4またはIPv6のCIDR(許可または拒否リスト)によって、ランタイム通話を承認されたクライアントネットワーク範囲に制限します。 プライベートアプリケーションや、より厳しい境界を必要とする特定のモデルやツールにグローバルに適用してください。 ランタイムアクセスキーと組み合わせて防御を深めます。鍵は発信者を認証し、IP範囲はネットワーク境界を強制します。 モデルやMCPツールに適用されます。
• トークンレート制限:トークンスループット(プロンプト加完了分)を 1分、1時間、または1日あたりに制限します。 構成ステップでトークン許容枠を設定し、制限が対象となる次元(発信者識別か発信者IPアドレスか)を選択します。 ゲートウェイは、remaining-tokens および consumed-tokens の応答ヘッダー（1 時間以上の期間の場合は remaining-quota-tokens も）を返すため、クライアント アプリケーションはブロックされる前に自律的にスロットリングできます。 トークン制限を使ってモデルの容量を保護し、スムーズなバーストを行ってください。 モデルに適用されます。
• リクエストレート制限:通話量を設定可能なウィンドウ(例:30秒、1分、2分、または5分)で制限し、発 信者ID または 発信者のIPアドレスごとにカウントします。 SaaS APIを呼び出すツールや、厳格なノルマ付きの内部システムに使うのが良いでしょう。 モデルやMCPツールに適用されます。

ベースラインおよびターゲットオーバーライドのレイヤーポリシー

広い基準と狭いオーバーライドを組み合わせることで、ガバナンスを最大限に活用しましょう:

• ゲートウェイ全体の基準を設定しましょう。 すべての該当する資産にコンテンツセキュリティとIPフィルターを適用し、すべてのモデルとツールが同じ保護を受け継承できるようにします。
• ターゲットを絞ったオーバーライドを追加しましょう。 高コストまたは容量制約のあるモデルにはトークンレート制限を適用し、レート制限のある下流APIを呼び出す特定のツールにはより厳しいリクエストレート制限を適用します。
• 多層的なコスト管理策 モデル容量 と 下流システムを保護する必要がある場合、同じモデルに対してトークン制限とリクエスト制限の両方を適用してください。リクエストは両方を満たさなければなりません。
• ID による範囲指定。 アプリケーションごとに別々のランタイムアクセスキーを発行し、呼び出し元ごとにレート制限をカウントして、各アプリケーションに独自の予算を与え、使用量を属性付けできるようにしましょう。

ガバナンスポリシーは運用上の統制です。 トークンの上限は急増を抑え、使用シグナルを提供するのに役立ちます。 財務報告には、プロバイダーの請求やAzure Cost Managementをご利用ください。

セキュリティと ID

AIゲートウェイ層のセキュリティ機能を活用してアクセスを制御し、リソースを保護しましょう。

ランタイムアクセスキー

ランタイムアクセスキーは、クライアントアプリケーションがAI Gateway Tierで公開した資産をバックエンド認証を受け取らずに呼び出すことができます。 クライアントアプリケーションはランタイムアクセスキーでゲートウェイに認証します。 クライアントは api-key ヘッダー内のランタイムアクセスキーをゲートウェイに送信します。 ゲートウェイはキーを検証し、ガバナンスポリシーを適用し、設定されたAPIキー、ツール用のOAuth設定、またはマネージドIDを使ってバックエンドに認証します。 エージェントアプリケーション、評価ハーネス、開発者ツール、自動化のためにランタイムアクセスキーを使用し、MCPサーバー、OpenAPI生成のMCPツール、モデルリソース、その他のゲートウェイ資産を呼び出します。

ゲートウェイはランタイムアクセスキーを生成し、所有者に割り当て、必要に応じてローテーションや取り消しを行います。 プレビューでは、すべてのキーがゲートウェイスコープ化されており、ゲートウェイ内の公開されているすべてのモデルやツールへのアクセスが許可され、アセットごとのスコーピングはまだ利用できません。 アプリケーションや環境ごとに別々のキーを作成し、それらをローテーションして個別に監査できるようにしましょう。

ランタイムアクセスキーを作成するには:

1. AIゲートウェイのティアポータルで「 キー」を選択します。
2. [API キーの作成] を選択します。
3. 厩舎名を入力し、所有者を特定します。
4. を選択してを作成します。
5. その値をコピーして申請に使ってください。 キーは後ほどキー のページで再度 ご覧いただけます。

クライアントアプリケーションは api-key ヘッダーにランタイムアクセスキーを含みます。 ランタイムアクセスキーをソースコードに貼り付けたり、ログやノートブック、共有チャットを作成したりしないでください。 デプロイプラットフォームのシークレットストアか、他の承認されたシークレットマネージャーに保存してください。 アプリケーションと環境ごとに1つのキーを使いましょう。 鍵は定期的に、そして所有権が変わるたびにローテーションしましょう。 鍵が露出している可能性がある場合は、すぐに切り替えまたは取り消し、ゲートウェイログを確認しましょう。

バックエンド認証にはマネージデンティティを使います

管理IDを設定し、AIゲートウェイ層がAPIキーを保存せずにサポートモデルやMCPサーバーのバックエンドに認証できるようにします。 マネージドIDを使ってモデルやMCPサーバーにアクセスすることはパブリックプレビューで利用可能です。 サポートされている場合は、バックエンドの鍵管理を減らすためにマネージドIDを優先してください。 ゲートウェイ設定からキーローテーションをなくし、Azure RBACでアクセス管理が可能になります。 AIゲートウェイ層はシステム割り当ておよびユーザー割り当てのマネージドアイデンティティをサポートします。 AIゲートウェイのティアポータルにある 管理されたアイデンティティ ページで管理してください。

システム割り当てまたはユーザー割り当てのアイデンティティを、あなたのニーズに応じて選択してください。 システム割り当てのアイデンティティはゲートウェイのライフサイクルに紐づいており、単一のゲートウェイがバックエンドアクセスを必要とする場合には簡単です。 ユーザー割り当てのアイデンティティはより厳密なコントロールを可能にします。ゲートウェイ間で1つのアイデンティティを共有したり、すべてのバックエンドに単一のアイデンティティを使う代わりに、異なるバックエンドごとに別々のアイデンティティを割り当てることができます。 管理者IDをサポートしていないプロバイダーはAPIキーを使いましょう。

バックエンド認証を設定する前に、以下の項目を必ず備えてください:

• AIゲートウェイ層のインスタンスです。
• モデル展開をホストするMicrosoft FoundryまたはAzure OpenAIリソースです。
• ゲートウェイのアイデンティティ設定を更新する許可をいただけます。
• バックエンド リソースに Azure RBAC ロールを割り当てるためのアクセス許可。
• Azure CLI 2.57.0 或更後版本。

システム割り当てのアイデンティティを有効にするには、AIゲートウェイティアポータルの 管理されたアイデンティティ ページを開きます。 「 アイデンティティを構成」では、 システムに割り当てられたアイデンティティをオンにし、その オブジェクト(プリンシパル)IDをコピーします。

ユーザー割り当てIDを有効にするには、ゲートウェイおよびバックエンドリソースと同じテナント内でアイデンティティを作成します。 マネージド ID ページで、ユーザー割り当て済み>ID の追加 を選択し、それを選択します。 管理型アイデンティティの クライアントID と オブジェクト(プリンシパル)IDをコピーします。 ゲートウェイはクライアントIDを使ってトークンを要求します。 Azure RBACはプリンシパルIDを使用します。

ゲートウェイのアイデンティティに、可能な限り狭い範囲で各バックエンドリソースへのアクセス権を付与します。 ほとんどの場合、個別のFoundryまたはAzure OpenAIリソースを活用してください。

以下のAzure CLI snippetを使用してください。 プレースホルダーを実際の値に置き換えます。 役割は名前ではなくIDで言及してください。

以下の価値を集めましょう:

• GATEWAY_PRINCIPAL_ID: ゲートウェイの管理IDのオブジェクト(プリンシパル)ID。
• BACKEND_RESOURCE_ID: Microsoft Foundry または Azure OpenAI リソースの完全な Azure リソース ID。形式は /subscriptions/... です。

GATEWAY_PRINCIPAL_ID="<gateway-managed-identity-principal-id>"
BACKEND_RESOURCE_ID="/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-or-aoai-resource-name>"

az role assignment create \
  --assignee-object-id "$GATEWAY_PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
  --scope "$BACKEND_RESOURCE_ID"

役割割り当ては伝播に数分かかることがあります。 割り当てを確認する:

az role assignment list \
  --assignee-object-id "$GATEWAY_PRINCIPAL_ID" \
  --scope "$BACKEND_RESOURCE_ID" \
  --output table

モデルをインポートする際は、バックエンド認証方法としてマネージドアイデンティティを選択してください。 モデル 追加 ウィザードで 「Foundryからインポート」を選択し、サブスクリプション、リソース、モデル展開を選択します。 プロバイダー詳細で「管理されるアイデンティティ」を選択し、システム割り当てのアイデンティティかゲートウェイに紐づくユーザー割り当てのアイデンティティを選択します。 ゲートウェイを呼び出すクライアントはバックエンドキーを必要としません。

もし401エラーで通話が失敗した場合は、インポートがマネージドIDを使用していること、バックエンドがEntra ID認証を受け入れているかを確認してください。 403エラーで呼び出しが失敗した場合は、アイデンティティのプリンシパルIDがバックエンドリソーススコープで Foundry User 役割を持っているか確認し、ロール割り当ての伝播を待ちます。

Monitoring

AIゲートウェイ層はモデルトラフィックに対してOpenTelemetryトークン使用指標を出力します。 メトリクスをどこに送るかは選びます。Azure アプリケーション Insightsか、Datadog、Splunk、Grafana Cloudなど他のOpenTelemetry(OTLP)互換先に送るかです。 Application Insightsを利用すると、ポータルにはトークン消費ダッシュボードが内蔵されています。

MCPツールのトラフィック監視(リクエストボリューム、レイテンシ、エラー)は、Application Insightsを接続したポータルの監視ビューで利用可能です。 OpenTelemetry(OTLP)エクスポートは現在、モデルトークン使用指標のみを対象としており、MCPツールのトラフィックは含まれていません。

トークン使用指標はカスタムのOpenTelemetry指標で、OpenTelemetry生成AIやクラウドセマンティックな慣習属性の一部(例えばモデル名)を含んでいます。 すべてのバックエンドがトークン数を報告しているわけではありません。一部のプロバイダーはストリーミングやパススルー応答でそれらを省略しています。 欠損したトークンデータはゼロではなく、利用不可と扱いましょう。

トークン使用指標には以下のような属性が含まれます:

ゲートウェイの監視設定でテレメトリの宛先を設定してください。 Application Insightsについては、サブスクリプション内のリソースを選択してください。 汎用OpenTelemetry(OTLP)エンドポイントの場合、コレクタURLと必要なアクセストークンやヘッダーを提供します。 Datadog、Splunk、Grafana Cloud、または一般的なOTLPコレクタを標準的な運用プラットフォームとして使うのが良いでしょう。 宛先の認証情報を秘密として保護し、テレメトリのエクスポート失敗を監視します。

トークン使用指標をApplication Insightsに送信すると、ポータルは内蔵のトークン消費ダッシュボードを提供します。 PromQLでトークンメトリックを照会します。Application Insightsや他のOTLPメトリックの目的地に到達するかどうかに関わらず。 例えば、このPromQLクエリはモデルごとのトークン使用状況をまとめています:

sum by (gen_ai_request_model) (gen_ai_client_token_usage)

メトリクスはセマンティックコンベンション属性を持つため、追加の設定なしで消費をセグメント化できます。 例えば、 gen_ai_operation_name ごとにグループ化して chat トラフィックと responses トラフィックを比較したり、 gen_ai_token_type ごとにプロンプトトークンと完了トークンを分けたりします。

sum by (gen_ai_request_model, gen_ai_token_type) (gen_ai_client_token_usage)

消費推定にはモデルとトークンの使用を使い、財務報告にはプロバイダー請求やAzure Cost Managementのエクスポートと照合します。

アプリケーションレベルの調査用に x-correlation-id ヘッダーを送信します。 個人データ、秘密情報、プロンプト、規制された識別子を相関ヘッダーに入れないでください。

トークン使用の急増、バックエンド認証の失敗、テレメトリのエクスポート失敗など、対応できるアラートから始めましょう。 すべてのアラートを所有者にルーティングし、ゲートウェイ、バックエンド、ポリシー、または宛先の設定を調査できるようにします。

関連するコンテンツ

• AIゲートウェイの階層概要
• クイックスタート:AIゲートウェイ層インスタンスを作成する
• モデルとツールの管理
• プライベート ネットワークを構成する