MENU

Azure API Management AI GatewayでモデルとMCPサーバーを一元管理する方法

Azure

Azure API ManagementのAI Gatewayを使うと、Microsoft FoundryやAzure OpenAIだけでなく、AWS Bedrock、Google Vertex AI、OpenAI、Anthropicなどのモデルを、共通の管理境界とエンドポイントで扱えます。さらに、既存のMCPサーバー、OpenAPIで定義されたREST API、各種SaaSコネクターをMCPツールとしてまとめて公開できます。

呼び出し元はプロバイダーごとの認証情報を持たず、AI Gatewayのランタイムアクセスキーだけを使用します。ゲートウェイ側で認証、レート制限、コンテンツ安全性、バックエンド認証、OpenTelemetry監視を一元化できることが大きな利点です。

ただし、専用の「AI Gateway tier」は2026年7月に公開プレビューとなった機能です。2026年8月時点では利用リージョン、アクセスキーの権限範囲、OpenTelemetryで出力できるデータなどに制約があります。まずは非本番環境で、モデル1つと読み取り専用のMCPツールから検証するのが安全です。

目次

Azure API Management AI Gatewayとは

Azure API ManagementのAI Gateway tierは、AIモデルとMCPツールへのアクセスを公開、保護、統制、監視するためのマネージドゲートウェイです。

アプリケーションやAIエージェントは、個々のモデルプロバイダーやMCPサーバーを直接呼び出しません。代わりにAI Gatewayの共通エンドポイントへリクエストを送り、ゲートウェイが次の処理を行います。

  1. api-keyヘッダーに設定されたランタイムアクセスキーを検証する
  2. 対象モデルやツールに設定されたポリシーを評価する
  3. モデル名またはツール名を基にバックエンドを選択する
  4. マネージドID、APIキー、OAuth 2.0などでバックエンドへ接続する
  5. 応答を返し、利用状況を監視先へ送信する

構成を簡略化すると、次のようになります。

アプリケーション／AIエージェント
        │
        │ api-key
        ▼
Azure API Management AI Gateway
        ├─ ランタイム認証
        ├─ コンテンツ安全性
        ├─ IPフィルター
        ├─ トークン／リクエスト制限
        ├─ モデル／ツールのルーティング
        └─ OpenTelemetry監視
        │
        │ Managed Identity／API Key／OAuth 2.0
        ▼
AIモデル／MCPサーバー／REST API／SaaSコネクター

これにより、プロバイダーのAPIキーを各アプリケーションへ配布せずに済みます。モデル、MCPサーバー、ポリシー、認証情報、監視設定を、プラットフォーム管理者が一か所で管理できます。(Microsoft Learn)

従来のAPI Managementとの違い

Azure API Managementには以前からAI向けのゲートウェイ機能がありました。新しいAI Gateway tierは、それらを基盤にしつつ、管理画面や管理APIを「API」ではなく「モデル」「MCPサーバー」「ツール」を中心に再構成した専用ティアです。

ポリシーも従来のXMLを直接記述する方式ではなく、専用ポータルのポリシーカードから設定できます。

一方、通常のREST APIやSOAP APIも含めて一つのAPI Managementインスタンスで管理したい場合や、既存ティア固有の機能が必要な場合は、従来のAPI Managementティアを継続する方が適していることがあります。AI Gateway tierは、AIモデルとエージェント用ツールの管理に特化した選択肢です。

AI Gatewayプレビューの構成と対応プロバイダー

公開プレビューでは、次のモデルプロバイダーを接続できます。

モデルの配置先登録方法主な呼び出し形式バックエンド認証
Microsoft FoundryFoundryからインポートOpenAI互換APIマネージドID推奨、またはキー
Azure OpenAIFoundryからインポートOpenAI互換APIマネージドID推奨、またはキー
Azure AI ServicesのモデルデプロイFoundryからインポート対応するOpenAI互換APIマネージドID、またはキー
AWS Bedrockカスタムモデルとして追加対応するOpenAI互換形式プロバイダーの認証情報
Google Vertex AIカスタムモデルとして追加対応するOpenAI互換形式プロバイダーの認証情報
OpenAIカスタムモデルとして追加Chat Completions、Responses APIAPIキー
Anthropicカスタムモデルとして追加Anthropic Messages APIのパススルーx-api-key
その他の互換エンドポイントカスタムモデルとして追加OpenAI Chat、Responses、Anthropic、その他任意の認証ヘッダーとキー

OpenAI互換モデルは、原則として次の配下に公開されます。

https://<gateway-name>.azure-api.net/default/models/openai/v1

Chat Completions APIは次のパスです。

https://<gateway-name>.azure-api.net/default/models/openai/v1/chat/completions

Responses APIは同じベースURLの /responses を使用します。

AnthropicモデルはネイティブのMessages API形式を維持し、次のパスで公開されます。

https://<gateway-name>.azure-api.net/default/models/anthropic/v1/messages

AI Gatewayはリクエスト本文の model に指定された値と、登録済みモデル名を完全一致で照合します。現在は、異なるプロバイダーであっても、同じゲートウェイ内のモデル名を重複させることはできません。(Microsoft Learn)

モデル名はプロバイダー名を含めて設計する

複数プロバイダーを登録する場合、単にモデルの製品名だけを登録すると、名称の衝突や切り替え時の混乱が起きやすくなります。

実務では、次のような命名規則を決めておくと管理しやすくなります。

<provider>-<model-family>-<purpose>-<environment>

例としては、次のような形式です。

foundry-chat-standard-dev
openai-reasoning-evaluation
anthropic-longcontext-prod

アプリケーションがモデル名を直接指定するため、後から名前を変更するとアプリケーション側の設定変更も必要になります。モデルの登録前に、プロバイダー、用途、環境を識別できる命名規則を定めておくことが重要です。

公開プレビューで確認すべき制約

2026年8月時点の主な条件は次のとおりです。

項目公開プレビュー時点の内容
利用リージョンEast US 2、Sweden Central
管理画面Azure Portalとは別のAI Gateway専用ポータル
管理認証Microsoft Entra ID
ランタイム認証ランタイムアクセスキー
キーの権限範囲ゲートウェイ内の全モデル、全ツール
SLAなし。ベストエフォート
管理API2026-05-01-preview
料金正式な料金体系はプレビュー期間中に案内予定
OTLP出力主にモデルのトークン使用量メトリック
プライベート接続受信Private Link、送信VNet統合がプレビュー対応

日本リージョンでは提供されていないため、データ所在地の要件がある組織では注意が必要です。データ所在地はAI Gatewayのリージョンだけで決まるものではありません。モデル、MCPサーバー、REST API、ログ保存先、OpenTelemetry転送先を含むリクエスト経路全体で確認する必要があります。(Microsoft Learn)

AI Gatewayを構築する前に決めておくこと

設定を始める前に、次の4点を決めておくと手戻りを減らせます。

ゲートウェイを分ける単位

公開プレビューでは、ランタイムアクセスキーを特定のモデルやMCPツールだけに限定できません。1つのキーで、そのゲートウェイに公開されたすべてのモデルとツールへアクセスできます。

したがって、少なくとも本番環境と検証環境は別のゲートウェイに分けるのが安全です。さらに、部門間でアクセス権を完全に分離する必要がある場合や、書き込み権限を持つMCPツールを公開する場合も、ゲートウェイの分割を検討します。(Microsoft Learn)

バックエンドの認証方式

Azure内のMicrosoft FoundryやAzure OpenAIには、可能な限りマネージドIDを使用します。

外部プロバイダーではAPIキーが必要になることがあります。MCPバックエンドでは、バックエンドごとに次の方式を選択できます。

  • 認証なし
  • API Key
  • OAuth 2.0
  • Managed identity

認証方式は、クライアントからAI Gatewayへの認証とは別です。クライアントはランタイムアクセスキーを使用し、AI Gatewayがバックエンド用の認証情報を付与します。

MCPで公開する操作

OpenAPIからMCPツールを生成できるからといって、すべてのAPI操作を公開する必要はありません。

最初は検索、一覧取得、詳細取得など、読み取り専用の操作から始めます。削除、送信、承認、支払い、ユーザー登録など、業務への影響が大きい操作は別のMCPサーバーへ分けると管理しやすくなります。

監視先

Application Insightsを使うか、既存のOpenTelemetry対応監視基盤へ送るかを決めます。

後から監視先を追加することもできますが、監視先を接続する前のリクエストについては、必要なテレメトリを取得できません。検証開始前に設定しておく方が確実です。(Microsoft Learn)

Azure API Management AI Gatewayの作成手順

AI Gateway専用ポータルへサインインする

AI Gateway tierは、通常のAzure Portalではなく、専用ポータルから管理します。

ai.gateway.azure.com

Microsoft Entra IDでサインインし、対象サブスクリプションのリソースを管理できるアカウントを使用します。

管理者はEntra IDでポータルにサインインしますが、アプリケーションやエージェントはEntra IDでポータルへサインインするわけではありません。ランタイムアクセスキーを使ってゲートウェイの実行エンドポイントを呼び出します。(Microsoft Learn)

ゲートウェイを作成する

専用ポータルで「Create gateway」を選択し、次の項目を指定します。

  • ゲートウェイ名
  • Azureサブスクリプション
  • リージョン
  • リソースグループ

ゲートウェイ名は、実行エンドポイントの一部になります。

https://<gateway-name>.azure-api.net

公開プレビューでは、East US 2またはSweden Centralを選択します。通常のAPI Managementのように、事前にスケールユニット数を設計する必要はありません。(Microsoft Learn)

マネージドIDを設定する

Microsoft FoundryやAzure OpenAIへ接続する場合は、ゲートウェイにシステム割り当てマネージドID、またはユーザー割り当てマネージドIDを設定します。

使い分けの目安は次のとおりです。

種類向いているケース
システム割り当て1つのゲートウェイ専用のIDとして簡単に管理したい
ユーザー割り当て複数ゲートウェイでIDを共有したい、バックエンドごとにIDを分けたい

Microsoft FoundryまたはAzure OpenAIリソースでは、ゲートウェイのマネージドIDへ必要なRBACロールを付与します。現在のドキュメントでは、対象リソースのスコープで「Foundry User」ロールを付与する構成が案内されています。

インポートウィザードを実行するユーザーに十分な権限があれば、ウィザードがロールを割り当てます。手動で設定する場合は、ゲートウェイのプリンシパルIDとバックエンドのリソースIDを確認して、最小限のスコープでロールを付与します。(Microsoft Learn)

複数のAIモデルを登録する方法

Microsoft Foundryからモデルをインポートする

AI Gatewayの「Models」から「Add models」を選択し、「Import from Foundry」を使用します。

基本的な流れは次のとおりです。

  1. 対象のAzureサブスクリプションを選択する
  2. Microsoft Foundryリソースを選択する
  3. 検出されたモデルデプロイを確認する
  4. プロバイダー名と表示名を設定する
  5. マネージドIDまたはキーベース認証を選択する
  6. インポートを実行する

初期セットアップウィザードでは、選択したFoundryアカウント単位でモデルデプロイが検出されます。不要なモデルをAI Gatewayへ登録したくない場合は、Foundry側でも用途や環境ごとにリソースを分けておくと管理しやすくなります。(Microsoft Learn)

外部プロバイダーをカスタムモデルとして追加する

AWS Bedrock、Google Vertex AI、OpenAI、Anthropicなどは、「Add a custom model」から登録します。

主な設定項目は次のとおりです。

  • プロバイダー名
  • 表示名
  • ベースエンドポイント
  • 認証ヘッダー名
  • APIキー
  • AI Gateway上で使用するモデル名
  • 対応するAPI形式

API形式は、OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、その他から、バックエンドに合ったものを選択します。

外部プロバイダーのAPIキーはアプリケーションへ配布せず、AI Gatewayに登録します。アプリケーションはAI Gatewayのランタイムアクセスキーのみを保持します。(Microsoft Learn)

モデルを呼び出して動作確認する

OpenAI互換モデルを登録した後は、次のように呼び出せます。

curl "https://<gateway-name>.azure-api.net/default/models/openai/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "api-key: <runtime-access-key>" \
  -d '{
    "model": "<registered-model-name>",
    "messages": [
      {
        "role": "user",
        "content": "この文章を3行で要約してください。"
      }
    ]
  }'

modelには、AI Gatewayへ登録したモデル名を正確に指定します。プロバイダー側の製品名やデプロイ名と、AI Gateway上のモデル名が異なる場合があるため注意してください。(Microsoft Learn)

ランタイムアクセスキーを安全に管理する

アプリケーションやAIエージェントがAI Gatewayを呼び出すには、ランタイムアクセスキーを使用します。

ポータルの「Keys」で「Create API key」を選択し、アプリケーションごとにキーを作成します。

推奨する分け方は次のとおりです。

業務アプリA・開発環境
業務アプリA・本番環境
評価ツール・検証環境
エージェント基盤・本番環境

キーを分けておけば、利用元の識別、個別ローテーション、漏えい時の失効が容易になります。

ランタイムアクセスキーはソースコード、Dockerfile、CIログ、Notebook、チャットへ直接貼り付けないでください。Azure Key Vaultや利用中のシークレット管理機能へ保存します。

なお、公開プレビューではランタイムアクセスキーはゲートウェイ単位です。特定のモデルやMCPツールだけを許可するアクセスキーは作成できません。キーを受け取ったアプリケーションは、同じゲートウェイ内のすべての公開アセットへ到達できる前提で設計します。(Microsoft Learn)

MCPサーバーをAI Gatewayから一元公開する方法

AI Gatewayでは、複数のツールバックエンドを1つの管理されたMCPエンドポイントへまとめられます。

対応するソースは次の3種類です。

ソース使用する場面AI Gatewayへの入力公開されるもの
既存MCPサーバーすでにリモートMCPサーバーを運用しているSSEまたはStreamable HTTPのMCP URL既存MCPサーバーのツール
OpenAPI定義REST APIはあるがMCPサーバーがないOpenAPIファイル、URL、インライン定義選択したAPI操作から生成されたMCPツール
組み込みコネクターSaaSへ接続したいがサーバーは運用したくないコネクターと接続設定コネクターの操作をMCPツールとして公開

組み込みコネクターでは、Office 365、SharePoint、GitHub、SalesforceなどのSaaSを接続できます。公開プレビュー時点の公式ドキュメントでは、1,000を超える事前構築済み統合が案内されています。(Microsoft Learn)

MCPサーバーを作成する

専用ポータルで次の操作を行います。

  1. 「MCP servers」を開く
  2. 「Add MCP server」を選択する
  3. MCP server、OpenAPI spec、Built-in connectorのいずれかを選ぶ
  4. バックエンドに一意の名前を付ける
  5. バックエンド認証を設定する
  6. 必要に応じて別のバックエンドを追加する
  7. 内容を確認して作成する

1つのMCPサーバーに、複数種類のバックエンドを追加できます。

例えば、次の構成を1つのMCPエンドポイントへまとめることが可能です。

github       ：GitHubコネクター
inventory    ：社内在庫APIのOpenAPI定義
knowledge    ：既存のリモートMCPサーバー

ツール名の衝突を避けるため、AI Gatewayはバックエンド名を名前空間として使用します。同じ create_issue というツールが複数バックエンドに存在しても、バックエンド名によって区別できます。(Microsoft Learn)

OpenAPIからMCPツールを生成する場合の注意点

OpenAPIからMCPツールを作る場合は、公開するAPI操作を選択できます。エージェントから不要な操作まで公開しないことが重要です。

また、OpenAPIの summary や description は、MCPツールの説明として利用されます。説明が曖昧だと、AIエージェントが適切なツールを選びにくくなります。

例えば、「データを取得する」だけではなく、次のように具体的に記述します。

指定した商品コードの現在庫数と最終更新日時を取得する。
データの変更は行わない。

書き込み操作の場合は、実行結果や副作用も明記します。

指定した案件IDへコメントを追加する。
この操作は元に戻せない場合がある。

AI Gatewayのポリシーは呼び出し回数やネットワークを制御できますが、業務上の認可をすべて代替するものではありません。更新や削除を行うAPIでは、バックエンド側でもユーザー、テナント、対象データに対する認可を維持します。

MCPツールの一覧を確認する

作成されたMCPサーバーは、次の形式で公開されます。

https://<gateway-name>.azure-api.net/default/toolservers/<server-name>/mcp

tools/listを送信して、公開されたツールを確認できます。

curl "https://<gateway-name>.azure-api.net/default/toolservers/<server-name>/mcp" \
  -H "Content-Type: application/json" \
  -H "api-key: <runtime-access-key>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list"
  }'

MCP互換クライアントやエージェントフレームワークでは、このURLとランタイムアクセスキーを設定します。クライアント側に、個々のMCPバックエンドやSaaSの認証情報を登録する必要はありません。(Microsoft Learn)

OAuth 2.0コネクターはツール一覧まで確認する

OAuth 2.0を使用するバックエンドでは、対話型サインインによる同意操作が必要です。

公開プレビューでは、バックエンドの認証完了状態がポータル上で完全には検証されず、表示される状態が自己申告扱いになる制限があります。認証画面で完了しただけで判断せず、tools/listで実際にツールが取得できることまで確認してください。

ツールが表示されない場合は、コネクターを再接続してサインインをやり直します。(Microsoft Learn)

ポリシーでモデルとMCPツールを統制する

AI Gateway tierでは、専用ポータルのポリシーカードからガードレールを設定できます。従来のAPI ManagementポリシーのようにXMLやポリシー式を直接記述する必要はありません。

公開プレビューで利用できる主なポリシーは次のとおりです。

ポリシー対象用途ブロック時の主な状態コード
Content safetyモデル、MCPツール有害コンテンツ、プロンプト攻撃、禁止語などの検査400
IP filterモデル、MCPツール許可または拒否するIPv4・IPv6範囲の指定403
Token rate limitモデルプロンプトと生成結果のトークン使用量制限429
Request rate limitモデル、MCPツール一定時間内のリクエスト回数制限429

複数ポリシーが適用されている場合は、すべての条件を満たしたリクエストだけがバックエンドへ転送されます。いずれかのポリシーがブロックすると、バックエンドモデルやツールは呼び出されません。(Microsoft Learn)

最初に設定したい基本ポリシー

実務では、次の順序で設定すると調整しやすくなります。

Content Safetyをログのみで開始する

最初から厳しいしきい値でブロックすると、正常な業務リクエストまで拒否する可能性があります。

まずはログのみで動作させ、実際のプロンプトやツール入力がどのカテゴリに判定されるか確認します。その後、業務要件に合わせてしきい値を調整し、ブロックへ切り替えます。

アクセス元が固定できる場合はIPフィルターを併用する

社内ネットワーク、Azure上のアプリケーション、固定されたNAT Gatewayなどからのみ呼び出す場合は、IP許可リストを設定します。

ランタイムアクセスキーだけに依存せず、キーとネットワークの両方で制御できます。

モデルにはトークン制限を設定する

同じ1回のリクエストでも、短い質問と長文生成では消費トークンが大きく異なります。リクエスト回数だけでなく、トークン使用量にも上限を設定します。

トークン制限は、分、時間、日などの単位で設定でき、呼び出し元IDまたはIPアドレスを集計軸として使用できます。

MCPツールにはリクエスト回数制限を設定する

SaaS APIや社内業務システムには、独自のAPI制限や処理能力の上限があります。

特に、メール送信、課題作成、データ更新などのツールには、モデルより厳しいリクエスト制限を設定します。429が返った場合に、クライアントが Retry-After を尊重して再試行する実装も必要です。(Microsoft Learn)

OpenTelemetryでモデル利用量を監視する

AI Gateway tierは、モデルのトークン使用量をOpenTelemetryメトリックとして出力できます。

送信先には、次のいずれかを設定できます。

  • Azure Application Insights
  • OpenTelemetry OTLP互換エンドポイント
  • 組織で利用しているOTLP対応監視プラットフォーム

Application Insightsを使用すると、AI Gatewayポータル内でトークン消費ダッシュボードを確認できます。(Microsoft Learn)

取得できる主な属性

トークン使用量メトリックには、OpenTelemetryの生成AI向けセマンティック規約に沿った属性が含まれます。

属性内容
gen_ai.request.modelリクエストで指定されたモデル名
gen_ai.response.model実際に応答したモデル
gen_ai.operation.namechat、responsesなどの操作
gen_ai.token.typeプロンプト、生成結果、推論トークンなどの種類

モデル別のトークン使用量は、例えば次のPromQLで集計できます。

sum by (gen_ai_request_model) (gen_ai_client_token_usage)

モデルとトークン種別の両方で分類する場合は、次のようにします。

sum by (
  gen_ai_request_model,
  gen_ai_token_type
) (
  gen_ai_client_token_usage
)

この値は利用傾向や異常な増加を把握するために使えます。ただし、請求額を確定する用途では、モデルプロバイダーの請求データやAzure Cost Managementと照合する必要があります。(Microsoft Learn)

公開プレビューではOTLP出力に制限がある

公開プレビュー時点で、汎用OTLPエンドポイントへ出力できる主なメトリックは、モデルのトークン使用量です。追加のログ、トレース、メトリックは今後拡張予定とされています。

MCPツールのリクエスト数、待ち時間、エラーは、Application Insightsを接続した場合にAI Gatewayポータルの監視画面で確認できます。一方、MCPツールのテレメトリを汎用OTLPエンドポイントへ出力する機能は、現在の公開プレビューでは提供されていません。(Microsoft Learn)

また、ストリーミング応答やパススルー応答では、バックエンドがトークン数を返さない場合があります。メトリックがない場合は「0トークン」ではなく、「取得できなかった」と判断してください。

相関IDへ機密情報を入れない

アプリケーションから x-correlation-id を送ると、障害調査時にリクエストを追跡しやすくなります。

ただし、相関IDには次の情報を含めないでください。

  • プロンプト本文
  • APIキー
  • メールアドレス
  • 氏名
  • 顧客番号
  • 医療、金融などの規制対象識別子

相関IDには、ランダムなUUIDや内部の処理IDを使用します。(Microsoft Learn)

よくあるエラーと確認ポイント

状態・症状主な原因確認する場所
400リクエスト形式不正、Content Safetyによる拒否JSON本文、ポリシーのログ
401ランタイムアクセスキーがない、無効、失効済みapi-keyヘッダー、Keys画面
403IPフィルター、バックエンドRBAC不足IPポリシー、マネージドIDのロール
404modelの値が登録名と一致しないModels画面、モデル名の大文字小文字
429トークン制限、リクエスト制限、プロバイダー側制限ポリシー、Retry-Afterヘッダー
5xxバックエンド障害、認証情報不正、タイムアウトプロバイダー状態、保存済み認証情報
MCPツールが表示されないOAuth接続未完了、OpenAPI操作未選択tools/list、コネクター再接続
トークンメトリックがない監視先未設定、バックエンドが使用量を返していないMonitoring設定、応答形式

マネージドIDのロール割り当ては、反映まで時間がかかる場合があります。設定直後に403が返った場合は、プリンシパルID、ロール、スコープを確認したうえで、ロール割り当ての反映を待ってから再試行します。(Microsoft Learn)

AI Gatewayを選ぶべきケース

AI Gateway tierが特に適しているのは、次のような構成です。

  • 複数のモデルプロバイダーを併用している
  • 複数アプリケーションへ共通のモデル基盤を提供したい
  • プロバイダーのAPIキーを各開発チームへ渡したくない
  • モデルとMCPツールへ共通ポリシーを適用したい
  • 利用モデルやトークン消費量を一元監視したい
  • 承認済みのMCPツールだけをエージェントへ公開したい
  • OpenAPIで管理している既存APIをMCP化したい

一方、単一アプリケーションから単一モデルを呼び出すだけで、共通ポリシー、認証情報の集中管理、統合監視が不要なら、モデルプロバイダーを直接呼び出す方が構成は単純です。(Microsoft Learn)

本番導入前に確認するチェックリスト

公開プレビューでの検証は、次の順番で進めると安全です。

  • 非本番用のAI Gatewayを作成する
  • Microsoft Foundryまたは外部プロバイダーからモデルを1つ登録する
  • アプリケーション専用のランタイムアクセスキーを作成する
  • Content Safetyをログモードで設定する
  • トークン制限とリクエスト制限を設定する
  • Application InsightsまたはOTLP監視先を接続する
  • 読み取り専用のOpenAPI操作をMCPツールとして公開する
  • tools/listで公開範囲を確認する
  • 400、401、403、429、5xx時のアプリケーション動作を確認する
  • キー漏えい時の失効手順と、障害時の直接接続または旧構成への切り戻し手順を用意する

AI Gateway tierは、モデルとMCPサーバーを「登録する場所」だけではありません。認証、ポリシー、バックエンド認証、監視を含む運用境界として設計することが重要です。

特に公開プレビュー中は、ゲートウェイ単位のアクセスキー、限定されたリージョン、OTLP出力の制約を前提にしてください。まずは環境と信頼境界ごとにゲートウェイを分け、モデル1つ、アプリケーション1つ、読み取り専用ツール1つの小さな構成から始めると、正式提供へ向けた設計判断をしやすくなります。(Microsoft Learn)

Azure
MCP Azure API Management OpenTelemetry Microsoft Foundry AI gateway

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次