AI Gatewayティアでのモデルとツールの管理(プレビュー)

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

アプリケーションやエージェントが呼び出すモデルやツールを管理するために、AIゲートウェイ層(プレビュー)を活用してください。 モデルをインポートして、モデルリクエストのための1つのガバネートされたエンドポイントを提供します。 管理者管理されたモデルコンテキストプロトコル(MCP)エンドポイントを通じて承認されたツールを公開するためにMCPサーバーを追加してください。 アプリケーションやエージェントはランタイムアクセスキーでゲートウェイに認証します。 ゲートウェイは、各モデルプロバイダーやツールバックエンドごとに設定したバックエンド認証を利用します。

前提条件

• AIゲートウェイ層のインスタンスです。
• AIゲートウェイ層インスタンスの管理権限。
• 追加予定のプロバイダーモデルやバックエンドへのアクセス。
• マネージデンティティ・バックエンド認証の場合、バックエンドリソースに必要な役割を割り当てる権限を付与します。

モデルのインポート

モデルを追加ウィザードを使って、AI Gateway TierをMicrosoft Foundry、Azure OpenAI、AWS Bedrock、Google Vertex、OpenAI、Anthropic、またはカスタムエンドポイントに接続してください。 ゲートウェイは、そのバックエンドがサポートするエンドポイント上で各モデルにサービスを提供し、プレフィックス https://<gateway>.azure-api.net/default/modelsのもとで対応します。 次のパスセグメントはプロバイダーAPI形式です。 例えば、OpenAI互換モデルは.../default/models/openai/v1(/chat/completionsや/responsesなど)で提供され、Anthropicモデルは.../default/models/anthropic/v1/messagesで提供されます。 ウィザードが要求する接続フィールドはプロバイダーによって異なります。

モデルがMicrosoft Foundryリソース(Azure OpenAIやAzure AI Servicesのデプロイメントを含む)で実行されている場合、Foundryからインポートを選択します。ウィザードはリソースのデプロイを自動で発見します。 AWS Bedrock、Google Vertex、OpenAI、Anthropic、その他対応エンドポイント用のカスタムモデルを追加を選択し、エンドポイント名とモデル名を自分で入力してください。

プロバイダーがMicrosoft FoundryなどのMicrosoft Entra IDバックエンド認証をサポートしている場合は、マネージドIDを使用してください。 インポート前にバックエンドリソースでゲートウェイIDに必要な役割を付与してください。 それ以外の場合は、インポート時にプロバイダーのAPIキーやシークレットを提供してください。 ゲートウェイは認証情報を保存・保護します。

発信者は model フィールドでモデル名でモデルを参照します。

{
  "model": "gpt-5.6-sol",
  "messages": [
    {
      "role": "user",
      "content": "Summarize the incident report."
    }
  ]
}

model値はインポートされたモデル名です。

モデルを追加するには、 モデル ページを開き、「 モデルを追加」を選択してください。 どのように繋がりたいかを選びましょう。

Microsoft Foundryからのインポート

1. Foundryからインポートを選択します。
2. SelectリソースでサブスクリプションとFoundryリソースを選択してください。 ウィザードはそのリソース内のモデル展開を一覧にします。
3. プロバイダー詳細にプロバイダー名と表示名を入力し、オプションの説明を追加し、認証方法を選択します - 管理型識別(利用可能な場合推奨)またはキーベース。
4. を選択してを作成します。 ゲートウェイはリソースのデプロイメントをモデルとしてインポートし、呼び出し元が名前で要求します。

カスタム モデルを追加する

1. [ カスタム モデルの追加] を選択します。
2. プロバイダーに表示名とプロバイダー名、オプションの説明を入力します。
3. エンドポイントでは、ベースエンドポイントURL、認証ヘッダー名(例:Authorization)、APIキーを入力します。
4. モデルでは、各モデル名を入力し、対応しているエンドポイント(OpenAIチャット完了、OpenAI応答、Anthropicメッセージ、その他)を選択します。 定義した各モデルごとに「 モデルを追加 」を選択します。
5. を選択してを作成します。

別途検証のステップはありません。 ゲートウェイはプロバイダーを作成するときに接続を設定します。 モデルを追加した後は、認証やポリシーを更新したり、不要になったら削除したりできます。

モデルが追加された後、ゲートウェイエンドポイントを通じてテストリクエストを送信します:

curl "https://<gateway>.azure-api.net/default/models/openai/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "api-key: <runtime-access-key>" \
  -d '{
    "model": "gpt-5.6-sol",
    "messages": [
      { "role": "user", "content": "Write a one-sentence status update." }
    ]
  }'

まだランタイムアクセスキーを作成していない場合は、 キー ページから作成してください。 アプリケーションは直接のプロバイダー認証情報を必要としません。 モデル名でリクエスト量、遅延、トークン使用状況、エラーをレビューするためにモニタリングビューを活用してください。

Anthropic Messages API のパススルー

プロバイダーごとに異なる API 形式が提供されており、ゲートウェイはそれぞれを /default/models 配下の固有のパスで提供します。 AnthropicモデルはパススルーモードでAnthropic Messages APIを使用します。ゲートウェイはネイティブのAnthropicメッセージの要求および応答形式を保持し、/default/models/anthropic/v1/messagesAnthropicへの呼び出しを転送します。 アプリケーションがすでにAnthropic SDKや/v1/messagesを使っている場合は使ってください。

Anthropic のモデルを追加するには、モデルを追加>カスタム モデルを追加を使用します:

1. プロバイダーで、Anthropicの表示名とプロバイダー名を入力します。
2. エンドポイント上で、ベースエンドポイントのURLをhttps://api.anthropic.comに設定し、認証ヘッダー名をx-api-keyに設定し、Anthropic APIキーを入力します。 ゲートウェイはキーを保存し、バックエンドコール時に注入します。
3. モデルでは、呼び出し元が送るAnthropicモデル名(例:claude-fable-5)を入力し、Anthropicメッセージのエンドポイントを選択します。
4. を選択してを作成します。 ゲートウェイは/default/models/anthropic/v1/messagesでAnthropicメッセージのパススルーを担当します。

クライアントはゲートウェイパスを呼び出します。 ゲートウェイは認証情報を保存し、バックエンドx-api-keyを注入し、呼び出し元のanthropic-versionヘッダーをAnthropicに転送します。

curl -X POST "https://<gateway>.azure-api.net/default/models/anthropic/v1/messages" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -H "api-key: <runtime-access-key>" \
  -d '{"model":"claude-fable-5","max_tokens":256,"messages":[{"role":"user","content":"Write a product description for a trail running backpack."}]}'

Anthropic Python SDKは、base_url をゲートウェイパスに向けると動作します。 デフォルトでは、標準SDKは認証情報をx-api-keyヘッダーに送信するため、api-keyを使ってdefault_headersヘッダーにゲートウェイランタイムアクセスキーを渡します。 api_key="unused"値はSDKの必要な引数のみを満たします。ゲートウェイはそれを無視し、保存されたバックエンドAnthropicキーを注入します。 modelをAnthropicモデル名に設定してください。

from anthropic import Anthropic

client = Anthropic(api_key="unused", base_url="https://<gateway>.azure-api.net/default/models/anthropic", default_headers={"api-key": "<runtime-access-key>"})
message = client.messages.create(model="claude-fable-5", max_tokens=256, messages=[{"role":"user","content":"Hello"}])
print(message.content[0].text)

特にポリシーがボディを検査する場合は、タイムアウトやレスポンス処理を本番前に検証してください。

MCP サーバーの追加

AIゲートウェイ層により、プラットフォームチームは1つの管理されたMCPエンドポイントの背後にMCPサーバーを公開できます。 設定ワークフローは以下の通りです:MCPサーバーを作成し、1つ以上のバックエンドを接続し、選ばれたバックエンド機能をツールとして公開します。 単一のMCPサーバーは、3種類のバックエンドを組み合わせることができます:URLによるリモート MCPサーバー 、 OpenAPI仕様から生成されたツール、そして一般的なSaaSアプリ用の 組み込みコネクタ (1,000以上のプリビルド統合で、ホストサーバーは不要)。

エージェントがビジネスシステム、開発者ツール、ナレッジストア、社内APIを呼び出す必要がある場合にMCPサーバーを活用しましょう。 エージェントはゲートウェイに一度認証し、バックエンドごとに別々の認証情報は必要ありません。 各バックエンドごとに、ゲートウェイがどのように認証するかを選択します: None、 API Key、 OAuth 2.0、 またはManaged idid。

単一のMCPサーバーが1つ以上のバックエンドをフェデレートします。 各バックエンドはツールを提供し、ゲートウェイは各バックエンドのツールをバックエンド名で割り当てるため、異なるバックエンドの同じ名前のツールが衝突しないようにしています。 例えば、バックエンドのcreate_issueツールがgithubgithubという名前でエージェントに公開され、別のバックエンドのcreate_issueツールとは異なります。

各情報源は異なる方法でツールを提供しています:

• MCPサーバー — すでにホストしているリモートMCPエンドポイントからツールをフェデレートします。
• OpenAPI仕様 — 選択したAPI操作をツールに変換します。操作の概要や説明がツール記述となります。
• 組み込みコネクタ — Office 365、SharePoint、GitHub、SalesforceなどのSaaSアプリへの管理された接続を使用します。 OAuthコネクタは接続設定時に同意を求めるプロンプトを出します。

MCPサーバーを作成するには:

1. AIゲートウェイのティアポータルで MCPサーバーを選択します。
2. 「 MCPサーバーを追加」を選択します。
3. Sourceでは、MCPサーバー、OpenAPI仕様、または組み込みコネクターのいずれかのバックエンドタイプを選んでスタートします。 後からバックエンドを追加することもできます。
4. バックエンドにユニークな名前を付けましょう。 ゲートウェイは、結合されたMCPサーバー内で、そのバックエンドのツール名の先頭にその名前を付けます。
5. バックエンドを設定し、ゲートウェイの認証方法を選択します: Noone、 API Key、 OAuth 2.0、 またはManaged idid。 APIキーの場合はヘッダー名と値を入力します。値は静止時に暗号化されます。
6. 同じエンドポイントの上でより多くのサービスをフェデレーションするには、別のバックエンドを追加してこれを繰り返します。
7. 「確認」を選択し、その後「作成」を選びます。

接続テストの別途ステップはありません。 ゲートウェイはサーバー作成時に各バックエンドを設定し、チェックします。

ゲートウェイはすべての選択されたバックエンドをフェデレーションする1つのMCPエンドポイントを作成します。 クライアントはガバナントされたエンドポイントを呼び出し、ランタイムアクセスキーで認証します。

エージェントは以下の場所でMCPサーバーに呼び出します。

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

api-keyヘッダーにランタイムアクセスキーを送信します。 任意のMCP互換クライアントまたはエージェントフレームワークをこのURLに向けてください。 例えば、JSON-RPC tools/list リクエストで利用可能なツールを挙げてみましょう。

curl "https://<gateway>.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" }'

import requests

url = "https://<gateway>.azure-api.net/default/toolservers/<server-name>/mcp"
response = requests.post(
    url,
    headers={"api-key": "<runtime-access-key>", "Content-Type": "application/json"},
    json={"jsonrpc": "2.0", "id": 1, "method": "tools/list"},
)
print(response.json())

システムにREST APIはあるがMCPサーバーがない場合は、そのOpenAPI記述をインポートしてください。 ツールとして公開する操作を選択し、ツール名や説明を編集し、サポートするバックエンド認証方法を設定し、MCPアセットを作成します。 ゲートウェイツールはREST操作への呼び出しをマッピングします。

MCPサーバーのゲートウェイを使って集中管理:

• ディスカバリー — 開発者とエージェント向けに承認されたMCPサーバーのカタログを1つ提供すること。
• 認証 — クライアントがゲートウェイに認証します。 ゲートウェイはバックエンドの認証情報を保存しているため、クライアントの設定には上流の秘密は含まれません。
• ツール露出 — 各サーバーがツールとして公開するバックエンド操作を選択します。 プレビューでは、すべてのランタイムアクセスキーがゲートウェイ内の公開されたすべての資産を呼び出すことができます。
• オブザーバビリティ — ゲートウェイはモデルトラフィックに対してOpenTelemetry(OTLP)トークン使用指標を出力し、それをApplication Insightsや他のOTLP宛先に送信できます。 Application Insightsを使うと、MCPツールのトラフィック監視(リクエストボリューム、レイテンシ、エラー)がポータルで利用可能です。OpenTelemetry(OTLP)によるMCPツールトラフィックのエクスポートはまだ利用できません。
• ガバナンス — MCPトラフィックに対して、レート制限やコンテンツ安全性などのモデルで使うポリシーを適用してください。

サーバーを作成した後は、共有前にランタイムアクセスを設定してください。 コンテンツセキュリティ、IPフィルター、トークンおよびリクエストレート制限などのポリシーを追加し、ゲートウェイや特定の公開資産に限定します。

関連するコンテンツ

• AIゲートウェイの階層概要
• クイックスタート:AIゲートウェイ層インスタンスを作成する
• AIゲートウェイ層をガバナンス、安全に管理、運用する
• プライベート ネットワークを構成する