Azure AI Foundry の「Import a Microsoft Foundry API – Azure API Management」は、Microsoft Foundry にデプロイした AI モデルのエンドポイントを、Azure API Management に REST API として取り込むための手順です。結論からいうと、管理者が最初に見るべきポイントは、クライアント互換性の選択、マネージド ID によるバックエンド認証、トークン利用量の制御、セマンティックキャッシュ、コンテンツ安全性ポリシーです。公式ドキュメントでは、Foundry の AI モデルエンドポイントを API Management インスタンスに API としてインポートし、AI gateway ポリシーや監視・制御機能を使って管理できると説明されています。(Microsoft Learn)
なお、2026年6月25日の GitHub 履歴では、該当ページに対して「author」「ms.author」などの著者メタデータ削除が行われており、API の呼び出し方法や移行期限を変更するような本文上の破壊的変更は確認できません。Learn ページ上の最終更新日は 2026年3月31日、ソース上の ms.date は 2026年3月30日です。したがって本記事では、2026年6月25日時点で確認できる公式情報をもとに、実務で確認すべき影響範囲と設定ポイントを整理します。(GitHub)
Azure AI Foundry の Microsoft Foundry API インポートで何ができるのか
この機能は、Azure AI Foundry、現在の公式表記では Microsoft Foundry にデプロイされた AI モデルのエンドポイントを、Azure API Management の API として取り込むためのものです。API Management 側に取り込むことで、アプリケーションが Foundry のモデルエンドポイントへ直接接続する構成ではなく、API gateway を経由して呼び出す構成にできます。(Microsoft Learn)
直接接続では、アプリごとに認証情報、呼び出し制限、ログ取得、モデル切り替え、コンテンツ安全性の実装がばらつきやすくなります。API Management を前段に置くと、認証、認可、監視、トークン消費管理、開発者向け公開、ポリシー適用を一元化しやすくなります。Microsoft の AI gateway ドキュメントでも、AI gateway は AI バックエンドを保護、スケール、監視、ガバナンスするための API Management の機能群として説明されています。(Microsoft Learn)
実務上の狙いは、「モデルを使えるようにすること」だけではありません。重要なのは、誰が、どのアプリから、どのモデルを、どれだけ使い、どの程度の安全性チェックを通しているかを管理できる状態にすることです。
2026年6月25日時点の更新ポイント
| 確認項目 | 内容 | 管理者が取るべき対応 |
|---|---|---|
| 2026年6月25日の変更 | GitHub 履歴上は著者メタデータ削除が中心で、本文仕様の変更ではない | 既存構成の緊急変更ではなく、公式ページの内容を設定棚卸しに使う |
| 対象 | Microsoft Foundry の AI モデルエンドポイントを API Management に API としてインポート | Foundry 直結のアプリがある場合、APIM 経由化を検討する |
| 適用範囲 | 公式ページでは API Management のすべての tier に適用と記載 | ただし、利用する AI gateway ポリシーごとの対応 tier は別途確認する |
| 自動構成 | API 操作、システム割り当てマネージド ID、バックエンド、set-backend-service ポリシー、バックエンド認証などを構成 | 作成後に権限、バックエンド URL、ポリシー、Product 紐付けを確認する |
| 移行期限 | 該当ドキュメント内に、既存 API の廃止日や強制移行期限は確認できない | 期限ありの移行ではなく、ガバナンス強化・標準化の観点で計画する |
| 運用上の重要点 | トークン制限、トークンメトリック、セマンティックキャッシュ、コンテンツ安全性を追加できる | 本番適用前に、429・403・ログ出力・キャッシュヒットをテストする |
公式手順では、インポート時に API Management が REST API エンドポイントごとの操作、Foundry tool deployment へアクセスするためのシステム割り当て ID、バックエンドリソース、set-backend-service ポリシー、マネージド ID によるバックエンド認証を自動構成するとされています。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
この更新は、単なるポータル操作の手順追加として見るより、AI API の入口を標準化する機能として捉えるべきです。影響するのは AI 開発者だけではありません。
| 関係者 | 影響するポイント | 確認すべきこと |
|---|---|---|
| Azure 管理者 | API Management、Foundry、マネージド ID、RBAC | APIM のシステム割り当て ID が対象 Foundry リソースへアクセスできるか |
| アプリ開発者 | API の呼び出しパス、ヘッダー、認証方式 | 既存クライアントが選択した互換性オプションに合っているか |
| セキュリティ担当 | API キー排除、認可、コンテンツ安全性 | API キー直書きではなく、マネージド ID と APIM 側の制御に寄せられるか |
| 運用担当 | ログ、メトリック、障害切り分け | Application Insights や Azure Monitor でトークン使用量を追えるか |
| FinOps 担当 | トークン消費、キャッシュ、クォータ | アプリ単位・チーム単位で利用量を制限できるか |
特にグローバル展開では、API Management のゲートウェイと Foundry 側の AI バックエンドをどのリージョンに置くかが重要です。Microsoft の AI gateway ドキュメントでは、マルチリージョン構成で地理的分散を活用する場合、API Management gateway と同じリージョンにバックエンド AI サービスをデプロイする例が示されています。(Microsoft Learn)
クライアント互換性オプションの選び方
Import a Microsoft Foundry API の設定で最も重要なのが、Client compatibility の選択です。ここを誤ると、アプリ側の URL パス、リクエスト本文、モデル指定方法が想定とずれ、404、400、422 などのエラーにつながります。
| オプション | 向いているケース | 呼び出し設計の考え方 |
|---|---|---|
| Azure OpenAI | Foundry tool に Azure OpenAI モデルデプロイだけが含まれる場合 | /openai/deployments/... 系の既存 Azure OpenAI パターンに近い構成にしたい場合 |
| Azure AI | Azure AI Model Inference API 経由のモデルや、複数モデルの切り替えを考える場合 | Azure AI Model Inference API で公開されるモデルを柔軟に扱いたい場合 |
| Azure OpenAI v1 | 新規開発で v1 API に寄せたい場合、OpenAI クライアント互換性を重視する場合 | api-version パラメーター依存を減らし、OpenAI クライアントに近い実装へ寄せたい場合 |
公式ドキュメントでは、Azure OpenAI、Azure AI、Azure OpenAI v1 の 3 つのクライアント互換性オプションが示されています。Azure OpenAI は /openai エンドポイント、Azure AI は /models エンドポイント、Azure OpenAI v1 は Azure OpenAI API version 1 を使う選択肢として説明されています。(Microsoft Learn)
新規アプリケーションで迷う場合は、次の基準で判断すると実務上の失敗を減らせます。
既存アプリが Azure OpenAI の従来パスを前提にしているなら、まず Azure OpenAI 互換を検討します。複数の Foundry モデルや Azure AI Model Inference API 対応モデルを切り替える可能性が高いなら、Azure AI 互換が候補になります。新規開発で OpenAI クライアントに近い形へ寄せたい、または api-version の更新負荷を抑えたい場合は Azure OpenAI v1 が有力です。Azure OpenAI v1 API は、日付付き api-version パラメーターを不要にし、OpenAI クライアント対応やクロスプロバイダーのモデル呼び出しを支援する方向で説明されています。(Microsoft Learn)
ポータルでのインポート手順
Azure Portal での大まかな流れは次のとおりです。
| 手順 | 作業 | 実務上の注意点 |
|---|---|---|
| 事前準備 | API Management インスタンスと、1つ以上のモデルがデプロイされた Foundry tool を用意する | 検証用と本番用の APIM を分けると安全 |
| API 追加 | API Management の「APIs」から「+ Add API」を選ぶ | 既存 API と Base path が衝突しないようにする |
| Microsoft Foundry を選択 | Azure resource から Microsoft Foundry を選ぶ | 対象サブスクリプションが見えない場合は権限を確認する |
| AI Service 選択 | Subscription と Foundry tool を選ぶ | deployments リンクでモデルデプロイ状況を確認する |
| API 構成 | Display name、Description、Base path、Products、Client compatibility を設定する | Base path は後から変えるとクライアント影響が大きい |
| Token 設定 | 必要に応じてトークン消費管理ポリシーを設定する | 最初から厳しすぎる上限を入れると検証が進まない |
| Semantic caching | 必要に応じてセマンティックキャッシュを設定する | Embeddings API や Redis 構成が必要になる |
| Content safety | 必要に応じて Azure AI Content Safety を設定する | しきい値を本番前に実データに近いプロンプトで検証する |
| Review/Create | 検証後に作成する | 作成後、Test タブで成功応答とトークン使用量を確認する |
公式手順では、API Management インスタンスから「APIs > + Add API」を選び、Azure resource から Microsoft Foundry を選択し、Foundry tool、Base path、Product、Client compatibility を設定して作成する流れになっています。作成後は Test タブで操作を選び、必要なパラメーターやヘッダー、リクエスト本文を指定して送信します。成功時にはバックエンドから成功ステータスとデータが返り、レスポンスにはトークン使用量データが含まれると説明されています。(Microsoft Learn)
自動構成される範囲と、管理者が手動で確認する範囲
インポートウィザードは便利ですが、「作成されたから本番投入できる」と判断するのは危険です。自動構成される範囲と、管理者が確認すべき範囲を分けて見てください。
| 項目 | 自動構成されること | 管理者が確認すること |
|---|---|---|
| API 操作 | REST API エンドポイントごとの Operations | 不要な操作が公開されていないか |
| ID | システム割り当てマネージド ID | Foundry 側で必要な権限が付与されているか |
| バックエンド | backend リソース | 宛先 URL、リージョン、認証方式が正しいか |
| ポリシー | set-backend-service など | 環境ごとの差し替え、ログ、例外処理を追加するか |
| 認証 | マネージド ID によるバックエンド認証 | API キー運用が残っていないか |
| Product | 任意で関連付け | 利用チーム単位の Product と Subscription を設計する |
本番では、Foundry 側の API キーをアプリやポリシーに埋め込むより、API Management のマネージド ID でバックエンド認証する方が管理しやすくなります。キー漏えい対策、ローテーション負荷、環境差分の管理を考えると、ID ベースの接続を標準にするのが現実的です。
トークン制限とメトリックは必ず設計する
AI API の運用では、リクエスト数だけでなくトークン消費量を管理する必要があります。単純なレート制限だけでは、短いプロンプトを大量に投げるアプリと、長いプロンプトを少数投げるアプリのコスト差を適切に制御できません。
API Management の llm-token-limit ポリシーは、LLM API のトークン使用量をキー単位で制限するためのポリシーです。トークンのレート上限、一定期間のクォータ、またはその両方を指定できます。レート制限超過時は 429、クォータ超過時は 403 が返ると説明されています。(Microsoft Learn)
実務では、最初から全社一律の上限を入れるより、次のように段階を分けると安全です。
| フェーズ | 設定例 | 目的 |
|---|---|---|
| 検証 | 緩めの TPM 制限、ログ中心 | 通常利用時のトークン量を把握する |
| パイロット | Product または Subscription 単位で上限設定 | チームごとの利用量を制御する |
| 本番 | アプリ重要度別にレートと月次クォータを設定 | コスト暴走と特定アプリによる枯渇を防ぐ |
トークン消費の可視化には llm-emit-token-metric ポリシーも重要です。このポリシーは LLM API のトークン消費に関するカスタムメトリックを Application Insights に送信します。ただし、Azure Monitor のカスタムメトリックにはディメンション数や時系列数の制限があり、API Management 側では 1 ポリシーあたり構成できるカスタムディメンション数に実質的な制約があるため、ユーザー ID やプロンプト本文のような高カーディナリティ項目を安易に入れない方が安全です。(Microsoft Learn)
セマンティックキャッシュはコスト削減に効くが、前提条件を見落としやすい
セマンティックキャッシュは、同一または意味的に近いプロンプトに対してキャッシュ済みレスポンスを返し、バックエンド API の処理負荷やレイテンシを下げるための仕組みです。API Management の公式ドキュメントでは、LLM API リクエストへのレスポンスをセマンティックにキャッシュすることで、バックエンド API にかかる帯域・処理要件を減らし、利用者が感じる遅延を下げられると説明されています。(Microsoft Learn)
ただし、セマンティックキャッシュは「チェックを入れれば終わり」ではありません。公式手順では、API 利用者向けの Chat Completion API デプロイに加えて、セマンティックキャッシュ用の Embeddings API デプロイ、マネージド ID 認証、RediSearch モジュールを有効にした Azure Managed Redis、API Management の外部キャッシュ構成が前提として示されています。また、RediSearch モジュールは新しい Azure Managed Redis キャッシュ作成時にのみ有効化でき、既存キャッシュへ後から追加できない点に注意が必要です。(Microsoft Learn)
セマンティックキャッシュを導入しやすいのは、社内 FAQ、定型問い合わせ、ドキュメント要約、ナレッジ検索のように似た質問が繰り返される用途です。一方、ユーザー固有情報や直近データに強く依存する応答では、キャッシュの安全性、鮮度、パーソナライズの扱いを慎重に設計する必要があります。
コンテンツ安全性は「ブロックするか」だけでなく「どこで検査するか」を決める
AI API を社内外に公開する場合、コンテンツ安全性の設計も重要です。API Management の llm-content-safety ポリシーは、LLM のリクエストやレスポンスを Azure AI Content Safety に送って安全性チェックを行うためのポリシーです。悪意あるコンテンツが検出された場合、API Management はリクエストまたはレスポンスをブロックし、403 を返すと説明されています。(Microsoft Learn)
このポリシーでは、Hate、SelfHarm、Sexual、Violence といったカテゴリ、しきい値、ブロックリスト、プロンプト攻撃への防御などを設定できます。前提として、Azure AI Content Safety リソース、Content Safety API 呼び出し用の API Management backend、API Management のマネージド ID に対する Cognitive Services User ロールなどが必要です。(Microsoft Learn)
実務で失敗しやすいのは、検証なしにしきい値を厳しくしすぎることです。たとえば、医療、教育、自治体、防災、法務のようにセンシティブな語が通常業務で出る領域では、単純にブロックを強くすると正常な問い合わせまで止まる可能性があります。本番前に、業務上よく使うプロンプト、想定される危険プロンプト、境界線上のプロンプトを用意し、403 の発生条件を確認してください。
移行期限はあるのか
2026年6月25日時点で確認できる該当公式ページには、既存の Azure OpenAI API、Azure AI Model Inference API、または既存の API Management 構成に対して、特定日までに「Import a Microsoft Foundry API」へ移行しなければならないという期限は記載されていません。今回の GitHub 履歴上の 2026年6月25日更新も、該当ファイルでは著者メタデータ削除にとどまります。(GitHub)
そのため、対応方針は「期限に追われて移行する」ではなく、次のように考えるのが現実的です。
| 既存状況 | 推奨アクション |
|---|---|
| アプリが Foundry / Azure OpenAI に直接接続している | APIM 経由化して、認証・ログ・トークン制御を標準化する |
| すでに API Management 経由で Azure OpenAI を公開している | Client compatibility とポリシー設計を見直し、Foundry API インポートとの差分を確認する |
| 新規 AI アプリを作る | 最初から APIM 経由にし、Product、Subscription、Token policy、Content Safety を設計する |
| 複数モデル・複数チームで利用する | Azure AI 互換または Azure OpenAI v1 を候補に、モデル切り替えとクライアント標準化を検討する |
既存アプリを APIM 経由へ移す手順
既存アプリを一気に切り替えると、認証、URL、レスポンス形式、レート制限、コンテンツ安全性のどこで問題が起きたのか切り分けにくくなります。移行する場合は、次の順序が安全です。
| ステップ | 作業 | 確認ポイント |
|---|---|---|
| 現状把握 | 現在のモデルデプロイ名、API パス、認証方式、利用アプリを一覧化する | どのクライアント互換性が最も変更少なく済むか |
| 検証用 APIM へインポート | Microsoft Foundry API を検証環境に取り込む | Base path、Product、Subscription を本番想定で作る |
| 認証確認 | マネージド ID でバックエンドへ接続する | API キーなしでバックエンド応答が返るか |
| 最小ポリシーでテスト | まずは制限を緩め、正常応答を確認する | 200、400、401、403、404、429 の発生条件 |
| 監視を有効化 | Application Insights、トークンメトリック、ログを設定する | アプリ別・チーム別に追跡できるか |
| 安全性・制限を追加 | トークン制限、Content Safety、必要に応じてキャッシュを追加 | 正常プロンプトが過剰にブロックされないか |
| 段階移行 | 一部アプリだけ APIM の URL に切り替える | レイテンシ、エラー率、トークン量 |
| 本番切替 | 既存直結ルートを停止または制限する | 直結ルートが残ってコスト管理が崩れないか |
特に注意したいのは、Client compatibility の変更はクライアント契約の変更になりやすい点です。既存アプリの URL パスやリクエスト形式を維持したいなら、互換性オプションを慎重に選ぶ必要があります。後から変更する場合は、API revision や別 Base path を使って段階的に移行する方が安全です。
管理者向けチェックリスト
| 項目 | チェック内容 |
|---|---|
| サブスクリプション | API Management と Foundry tool が見える権限を持っているか |
| マネージド ID | APIM のシステム割り当て ID が有効か |
| バックエンド権限 | Foundry / Azure AI Services 側で必要なロールが付与されているか |
| Base path | 既存 API と衝突せず、将来のバージョン管理に耐える命名か |
| Product 設計 | 部門、アプリ、環境ごとに Subscription を分けられるか |
| Client compatibility | 既存クライアントの呼び出し形式と一致しているか |
| トークン制限 | 429 と 403 の発生条件を利用者へ説明できるか |
| メトリック | Application Insights でトークン量を追えるか |
| セマンティックキャッシュ | Embeddings API、Redis、RediSearch、外部キャッシュ設定がそろっているか |
| Content Safety | しきい値、カテゴリ、ブロックリストを業務データで検証したか |
| グローバル構成 | APIM gateway と AI バックエンドのリージョン配置を決めたか |
| 障害時対応 | バックエンド障害、認証失敗、制限超過時の利用者向けメッセージを決めたか |
よくある失敗と回避策
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| Foundry tool が選択画面に出ない | サブスクリプション、ディレクトリ、権限が違う | Azure Portal のディレクトリ、RBAC、対象サブスクリプションを確認する |
| 401 または 403 が返る | マネージド ID の権限不足、バックエンド認証設定ミス | APIM の ID と Foundry 側ロールを確認する |
| 404 が返る | Base path または Client compatibility とクライアント実装が不一致 | 実際の呼び出し URL とインポート時の互換性設定を見直す |
| 想定外に 429 が出る | トークンレート制限が厳しすぎる | 検証時は緩めに設定し、実測値から上限を決める |
| 想定外に 403 が出る | トークンクォータ超過、Content Safety ブロック | 403 の原因が quota か safety かをログで分ける |
| メトリックが扱いにくい | カスタムディメンションを増やしすぎている | アプリ ID、Product、環境など低カーディナリティ項目に絞る |
| キャッシュ効果が出ない | 類似プロンプトが少ない、Embeddings / Redis 構成不足 | キャッシュ対象ユースケースを FAQ や定型応答に限定して検証する |
まず何から始めるべきか
Azure AI Foundry の Microsoft Foundry API インポートは、AI モデルを単に公開するための機能ではなく、AI API の入口を Azure API Management に集約し、認証、制限、監視、安全性、コスト管理を標準化するための仕組みです。
最初に行うべきことは、既存の Foundry / Azure OpenAI 利用状況を棚卸しし、どのアプリがどのモデルをどのパスで呼んでいるかを整理することです。そのうえで、検証用 API Management にインポートし、Client compatibility、Base path、Product、Subscription、トークン制限、ログ、Content Safety を小さく試してください。
2026年6月25日時点の該当更新は、確認できる範囲では強制移行を伴うものではありません。だからこそ、急いで設定を変えるよりも、API Management を AI gateway として使う設計に寄せ、今後のモデル追加、利用部門拡大、コスト管理、監査対応に耐えられる形へ整えることが重要です。
コメント