Azure AI Foundry と Azure AI Search を使った RAG 基盤で、「モデル呼び出しの認証・負荷分散・スロットリング・監視をどこで管理するか」に悩んでいる企業には重要な更新です。
2026年6月5日に公開・更新された Azure Updates では、Azure AI Search から Foundry Models を利用する構成で Azure API Management（APIM）を前段に置ける機能が Public Preview になったことが案内されています。これにより、Azure AI Search の埋め込み生成、ベクトル化、GenAI プロンプト処理で、Foundry Models や Azure OpenAI in Foundry Models への呼び出しを APIM 経由に集約しやすくなります。(マイクロソフト アジュール)
ただし、現時点では In preview です。Azure の更新情報では、In preview は「運用環境以外の使用とテストのために、すべての Azure のお客様が利用できる」段階と説明されています。すぐに本番へ全面投入するのではなく、既存の RAG パイプライン、認証方式、ネットワーク経路、監視設計への影響を検証することが先です。(マイクロソフト アジュール)
Azure AI FoundryのAPIM対応で何が変わるのか
今回のポイントは、Azure AI Search が Foundry Models を呼び出す際に、Azure API Management をゲートウェイとして挟めるようになったことです。
これまでもアプリケーション側から Azure OpenAI や Foundry Models を呼び出す場面で APIM を使う設計はありました。今回の更新では、Azure AI Search のスキルやベクターライザーからのモデル呼び出しにも APIM を組み込みやすくなった点が実務上の変化です。
Microsoft Learn では、APIM を Foundry Models を使う Azure AI Search ワークロードの前段に配置することで、ルーティング、負荷分散、スロットリング、可観測性を一元化できると説明されています。(Microsoft Learn)
変更前と変更後の考え方
| 観点 | 従来の設計で起きやすい課題 | APIM対応後に整理しやすくなる点 |
|---|---|---|
| モデル呼び出し先 | スキルやアプリごとにエンドポイント管理が分散しやすい | APIMゲートウェイURLに集約しやすい |
| 認証 | 検索サービス、アプリ、モデル側の権限設計が複雑化しやすい | APIMで呼び出し元を認証し、APIMのマネージドIDでFoundryへ接続する設計を取りやすい |
| 負荷制御 | 大量インデックス作成時やRAG処理でモデル側の制限に当たりやすい | APIMのポリシーでスロットリング、再試行、バックエンド制御を検討しやすい |
| 監視 | どのワークロードがどれだけモデルを呼んでいるか把握しづらい | APIMを通すことでAPI単位の観測点を作りやすい |
| ネットワーク | パブリック経路とプライベート経路の設計が分散しやすい | SearchからAPIM、APIMからFoundryの経路を分けて設計できる |
特に大規模な RAG パイプラインでは、Azure AI Search のインデクサー、埋め込みスキル、ベクトル検索、回答生成用モデルが複数チームで利用されることがあります。その場合、モデルエンドポイントを各チームが直接参照するより、APIM を共通ゲートウェイにしておく方が、変更管理や監査の観点で扱いやすくなります。
対象になるAzure AI Searchの機能
今回の APIM 対応で対象になる Azure AI Search 側の主な機能は、以下の3つです。Microsoft Learn では、これらの機能から API Management 経由で Microsoft Foundry model deployment を呼び出せると説明されています。(Microsoft Learn)
| Azure AI Searchの機能 | 用途 | APIMで設定する主なプロパティ |
|---|---|---|
| Azure OpenAI 埋め込みスキル | インデックス作成時にテキストをベクトル化する | resourceUri |
| Azure OpenAI ベクトライザー | クエリ時などにテキストをベクトル化する | resourceUri |
| GenAI プロンプトスキル | インデックス作成パイプライン内で生成AI処理を行う | uri |
設定値には、https://<apim-name>.azure-api.net のような APIM ゲートウェイURL、または API Management のカスタムドメインを指定します。(Microsoft Learn)
埋め込みスキルで影響が大きい理由
Azure OpenAI Embedding スキルは、Azure OpenAI in Foundry Models リソースや Microsoft Foundry プロジェクトに展開された埋め込みモデルへ接続し、インデックス作成時に埋め込みを生成します。(Microsoft Learn)
そのため、社内文書、FAQ、SharePoint、データベースなどを大量に取り込む RAG 構成では、埋め込み生成の呼び出しが集中しやすくなります。APIM を前段に置くことで、モデル呼び出しの入り口を集約し、呼び出し量や失敗率を観測しやすくなる点は大きなメリットです。
ただし、APIM を挟むことで経路が1つ増えるため、遅延、タイムアウト、ポリシー設定ミスの影響も受けます。検証時は「機能するか」だけでなく、「大量データを流したときに安定するか」まで確認する必要があります。
サポートされないシナリオに注意する
今回の更新は、Azure AI Search のすべての生成AI連携に APIM を使えるという意味ではありません。
Microsoft Learn では、APIM がゲートウェイとしてサポートされないシナリオとして、Azure Content Understanding スキルで使用されるLLM、および エージェント型検索におけるナレッジベースで使用されるLLM が挙げられています。(Microsoft Learn)
| シナリオ | APIMゲートウェイ対応 |
|---|---|
| Azure OpenAI 埋め込みスキル | 対応 |
| Azure OpenAI ベクトライザー | 対応 |
| GenAI プロンプトスキル | 対応 |
| Azure Content Understanding スキルで使うLLM | 非対応 |
| エージェント型検索のナレッジベースで使うLLM | 非対応 |
ここを誤解すると、設計レビューで手戻りが発生します。特に「Azure AI Search 関連だから全部 APIM に集約できる」と判断するのは危険です。対象機能ごとに、スキルセット、ベクターライザー、ナレッジベース、エージェント検索のどこでモデルを呼んでいるかを分解して確認してください。
管理者が確認すべき設定ポイント
管理者が最初に見るべきポイントは、認証、RBAC、ネットワーク、監視、コスト影響です。APIM を追加することで統制しやすくなる一方、設定すべき場所も増えます。
APIMゲートウェイURLをどこに設定するか
Azure AI Search 側では、対象機能のエンドポイントを APIM のゲートウェイURLに向けます。
| 機能 | 確認する場所 | 設定例 |
|---|---|---|
| Azure OpenAI 埋め込みスキル | スキルセット定義の resourceUri | https://<apim-name>.azure-api.net |
| Azure OpenAI ベクトライザー | ベクトライザー定義の resourceUri | https://<apim-name>.azure-api.net |
| GenAI プロンプトスキル | スキル定義の uri | https://<apim-name>.azure-api.net |
既存環境では、Foundry や Azure OpenAI の直接エンドポイントが設定されている可能性があります。移行時は、いきなり既存の本番スキルセットを書き換えるのではなく、検証用インデックス、検証用スキルセット、検証用データソースで動作を確認してから段階的に反映するのが安全です。
マネージドIDとRBACを整理する
今回の構成では、主に2つのIDを意識します。
| ID | 役割 | 確認ポイント |
|---|---|---|
| Azure AI Search のマネージドID | APIMゲートウェイに対する呼び出し元 | APIM側のポリシーで認証・承認できるか |
| API Management のマネージドID | Foundry Models / Azure OpenAI in Foundry Models への呼び出し元 | Foundryリソース側で適切なロールがあるか |
Microsoft Learn では、推奨パターンとして「呼び出し元は APIM に対して認証し、APIM は自身のマネージドIDで Microsoft Foundry リソースに対して認証する」方式が説明されています。また、APIM のマネージドIDには Microsoft Foundry リソースで Cognitive Services OpenAI User ロールを割り当てるとされています。(Microsoft Learn)
この設計にすると、Azure AI Search が Foundry リソースへ直接アクセスする権限を持たなくても、APIM 側で資格情報を終端し、バックエンド接続を再確立できます。組織としては、権限の境界が分かりやすくなります。
サブスクリプションキー方式は検証向き、Entra ID方式は統制向き
APIM ゲートウェイで Azure AI Search を認証する方法には、サブスクリプションキーを使う方法と、Microsoft Entra ID トークンを検証する方法があります。
Microsoft Learn では、サブスクリプションキー方式は構成が簡単で、APIM の named value に Foundry リソースAPIキーを格納し、set-header ポリシーでバックエンド要求に渡す例が示されています。一方で、多層防御には validate-azure-ad-token ポリシーで検索サービスのマネージドIDによるトークンを検証する方法が紹介されています。(Microsoft Learn)
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| APIMサブスクリプションキー | PoC、短期検証、最小構成での動作確認 | キー管理、漏えい時の影響、ローテーション手順を決める必要がある |
| Entra IDトークン検証 | 本番を見据えた統制、ゼロトラスト寄りの設計 | APIMポリシー、アプリ登録、ロール、トークン検証設定の理解が必要 |
| APIMのマネージドIDでFoundryへ接続 | キーを減らし、権限管理をAzure RBACに寄せたい場合 | Foundryリソース側のロール割り当て漏れに注意 |
検証初期はサブスクリプションキーで疎通確認し、その後に Entra ID とマネージドID中心の設計へ寄せる進め方が現実的です。ただし、セキュリティ要件が高い組織では、最初から本番想定の認証方式で検証した方が手戻りを減らせます。
ネットワーク設計で確認すべきこと
APIM を挟む構成では、通信経路を2つに分けて考えると整理しやすくなります。
1つ目は Azure AI Search から APIM への経路、2つ目は APIM から Microsoft Foundry リソースへの経路です。
パブリック経路でよい場合
Azure AI Search が APIM のパブリックエンドポイントを呼び出す構成では、APIM が Foundry リソースに対して認証し、要求を転送します。Microsoft Learn では、公開パスの構成として、Azure AI Search のスキルまたはベクターライザーが APIM ゲートウェイを呼び出し、APIM のポリシーで呼び出し元を認証し、APIM のマネージドIDで Foundry に認証する流れが示されています。(Microsoft Learn)
この構成は比較的始めやすい一方、企業のネットワークポリシーによっては、検索サービスからの送信や APIM の公開範囲を制限する必要があります。
プライベート経路が必要な場合
検索サービスが APIM にプライベートに到達する必要がある場合、Azure AI Search から API Management インスタンスへの共有プライベートリンクを作成し、インデクサーをプライベート実行環境で実行します。Microsoft Learn では、共有プライベートリンクで Microsoft.ApiManagement/service リソースタイプと Gateway グループIDを使う手順が説明されています。(Microsoft Learn)
| 確認項目 | 見るべきポイント |
|---|---|
| Search → APIM | パブリックでよいか、共有プライベートリンクが必要か |
| APIM → Foundry | Foundry側をパブリックで使うか、Private Endpointなどを使うか |
| インデクサー | プライベート実行環境で動かす必要があるか |
| DNS | APIMカスタムドメインやプライベートエンドポイントの名前解決が正しいか |
| 制限 | 共有プライベートリンクの上限に影響しないか |
重要なのは、Search から APIM へのプライベート接続と、APIM から Foundry へのプライベート接続は別物として設計することです。片方をプライベート化しても、もう片方が自動的にプライベートになるわけではありません。
開発者が確認すべき実装ポイント
開発者が見るべきポイントは、スキルセット定義、ベクターライザー定義、APIM のAPI定義、ポリシー、テスト方法です。
既存のスキルセットを洗い出す
まず、Azure AI Search でモデル呼び出しをしている箇所を洗い出します。
確認すべき代表例は次の通りです。
- インデックス作成時に Azure OpenAI Embedding スキルを使っているか
- クエリ時のベクトル化に Azure OpenAI ベクトライザーを使っているか
- スキルセット内で GenAI プロンプトスキルを使っているか
- それぞれの
resourceUriやuriがどのエンドポイントを向いているか - APIキー認証か、マネージドID認証か
- リトライやタイムアウト時の挙動をアプリ側でどう扱っているか
この棚卸しをしないまま APIM を導入すると、ある処理だけ直接 Foundry を呼び続け、別の処理だけ APIM 経由になるなど、運用上分かりにくい構成になります。
APIMにFoundry APIを取り込む
API Management では、Azure OpenAI in Foundry Models にデプロイされたAIモデルエンドポイントを REST API として取り込めます。Microsoft Learn では、Microsoft Foundry から直接 Azure OpenAI API をインポートする方法が推奨されており、手動で OpenAPI 仕様を追加する方法も示されています。(Microsoft Learn)
Foundry から直接インポートした場合、APIM インスタンスのマネージドIDによる認証が自動構成されると説明されています。(Microsoft Learn)
開発者は、APIM のテストコンソールで以下を確認してから Azure AI Search 側のエンドポイントを切り替えると安全です。
| テスト項目 | 確認内容 |
|---|---|
| APIM単体の疎通 | APIMからFoundryモデルへ正常に到達できるか |
| 認証 | サブスクリプションキー、Entra ID、マネージドIDのいずれで通すか |
| APIパス | /openai など、Azure OpenAI互換のパスが想定通りか |
| デプロイID | モデルの deployment ID が正しいか |
| APIバージョン | 呼び出しに使うAPIバージョンがモデル・クライアントと合うか |
| エラー応答 | 401、403、429、5xx の応答が想定通り返るか |
移行時に失敗しやすいポイント
APIM を追加するだけなら簡単に見えますが、実際の移行では細かい設定差分で失敗しやすいです。
エンドポイントだけ変えて認証を変えていない
よくある失敗は、Azure AI Search の resourceUri や uri を APIM に向けたものの、APIM 側の認証ポリシーやサブスクリプションキー設定が合っていないケースです。
Foundry の直接エンドポイントでは通っていた認証が、APIM 経由では通らないことがあります。APIM で呼び出し元をどう認証し、バックエンドへ何を渡すのかを明確にしてください。
APIMのポリシーで429やタイムアウトが増える
RAG のインデックス作成では、短時間に大量の埋め込み生成リクエストが発生することがあります。APIM でスロットリングやリトライを設定する場合、厳しすぎる制限を入れると、インデクサー側で失敗が増える可能性があります。
一方で、制限を緩くしすぎると、バックエンドの Foundry モデル側のレート制限に当たりやすくなります。APIM の制御は「入れれば安全」ではなく、モデルの制限、インデクサーの並列度、データ量、再試行回数とセットで調整する必要があります。
監視ログの見方が変わる
APIM を通すと、モデル呼び出しの観測点が増えます。これはメリットですが、障害時の切り分け対象も増えます。
たとえば、埋め込み生成が失敗した場合、原因は次のどこかにあります。
- Azure AI Search のスキルセット設定
- APIM の認証ポリシー
- APIM のバックエンド設定
- APIM から Foundry への認証
- Foundry モデルのデプロイ状態
- ネットワークやDNS
- レート制限やクォータ
- リクエスト本文やAPIバージョンの不一致
移行前に、Search 側のログ、APIM 側のログ、Foundry 側のメトリックをどう突き合わせるかを決めておくと、トラブル対応が速くなります。
本番導入前のチェックリスト
Public Preview 段階では、いきなり全ワークロードを切り替えるのではなく、限定的な検証から始めるのが現実的です。
| チェック項目 | 管理者・開発者が確認すること |
|---|---|
| プレビュー利用の可否 | 組織のポリシー上、非運用環境での検証に使えるか |
| 対象機能 | 埋め込みスキル、ベクトライザー、GenAIプロンプトスキルのどれを対象にするか |
| 非対応機能 | Content Understandingスキルやエージェント型検索のナレッジベースLLMを混同していないか |
| APIM構成 | API定義、バックエンド、ポリシー、カスタムドメインを確認したか |
| 認証 | サブスクリプションキー、Entra ID、マネージドIDの役割分担が明確か |
| RBAC | APIMのマネージドIDに必要なロールを付与しているか |
| ネットワーク | パブリック経路か、共有プライベートリンクを使うか決めたか |
| 性能 | 大量インデックス作成時の遅延、429、タイムアウトを測ったか |
| 監視 | Search、APIM、Foundryのログを突き合わせられるか |
| ロールバック | 直接エンドポイントへ戻す手順を用意しているか |
特にロールバック手順は軽視されがちです。スキルセットやベクターライザーの定義を変更する前に、変更前のJSONを保存し、検証用インデックスで再現できるようにしておきましょう。
どのような組織で効果が大きいか
今回の APIM 対応は、すべての Azure AI Search 利用者に必須というより、複数チーム・複数モデル・大規模RAGを運用する組織ほど効果が出やすい更新です。
効果が大きいケース
- 部門ごとに複数の RAG アプリを構築している
- Azure AI Search のインデックス作成で埋め込み生成が大量に発生する
- モデル呼び出しの監査ログや利用状況を一元化したい
- Foundry Models や Azure OpenAI のエンドポイントを直接公開したくない
- 将来的に複数リージョン、複数デプロイ、負荷分散を検討している
- APIキーよりもマネージドID中心の設計に寄せたい
- 生成AI基盤をプラットフォームチームが共通管理している
急いで導入しなくてもよいケース
- 単一の検証アプリだけで利用している
- Azure AI Search からのモデル呼び出しが少ない
- APIM をまだ組織で運用していない
- プレビュー機能を利用できない本番ポリシーがある
- 現状の直接接続で監視・認証・制限に困っていない
小規模な構成では、APIM を追加することでかえって運用対象が増える場合もあります。APIM 導入の目的が「統制」「監視」「負荷制御」「ネットワーク分離」のどれなのかを明確にしてから検証しましょう。
まず取るべき行動
今回の Azure AI Foundry 関連の更新は、RAG 基盤を本格運用している組織にとって、モデル呼び出しの管理方法を見直すきっかけになります。
最初にやるべきことは、既存の Azure AI Search ワークロードで、どのスキルやベクターライザーが Foundry Models を直接呼んでいるかを棚卸しすることです。そのうえで、検証環境に APIM を作成し、埋め込みスキルまたはベクトライザーの1つを APIM 経由に切り替えて、認証、性能、ログ、ロールバックを確認します。
Public Preview の段階では、結論を急ぐ必要はありません。重要なのは、今後本番採用できる状態になったときに、認証設計、ネットワーク設計、監視設計をすぐ判断できるよう、早めに検証結果を残しておくことです。
コメント