Azure AI FoundryでModel Routerを使っている組織がまず押さえるべきポイントは、Model Routerが選択できる基盤モデルをAzure Policyで一元的に制御できるようになったことです。2026年6月3日に案内された「Public Preview: Azure Policy Coverage for Model Router in Foundry Models」は、モデルルーティングの賢さを変える機能というより、セキュリティ、コンプライアンス、運用標準に沿ったモデル選択を強制しやすくするガバナンス強化です。Azure Policyによる制御はFoundryポータルだけでなく、REST API、Azure CLI、ARMテンプレート経由の展開にも影響します。(Microsoft Azure)
特に確認すべきなのは、既存のAzure Policy割り当て、許可済みモデルのPublisher名とAsset ID、Model Routerのモデルサブセット、IaCテンプレート、既存デプロイのコンプライアンス状態です。プレビュー機能のため、いきなり本番環境にDenyで適用するのではなく、まずAuditで影響範囲を把握し、承認済みモデル一覧と展開手順を整えてから段階的に適用するのが安全です。Azure Updatesでは「In preview」は非本番での利用・テスト向けの状態として説明されています。(Microsoft Azure)
Azure AI FoundryのModel Routerに対するAzure Policy適用で何が変わるのか
今回の変更は、Azure AI FoundryのModel Routerに対して、標準的なモデルデプロイで使われていた組み込みAzure Policyの統制を、Model Routerのモデル選択にも適用できるようにするものです。
Model Routerは、プロンプトの内容に応じて適切な大規模言語モデルへルーティングする仕組みです。これにより、単一のデプロイとして扱いながら、品質、コスト、レイテンシのバランスを取りやすくなります。一方で、組織として利用を許可していないモデルにルーティングされる可能性をどう管理するかが重要になります。Microsoft Learnでは、Model Routerは同じ組み込みFoundryモデルデプロイポリシーを尊重し、モデルサブセットに対して適用されると説明されています。(Microsoft Learn)
| 観点 | 変更内容 | 実務上の意味 |
|---|---|---|
| ガバナンス対象 | Model Routerで選択できるモデルサブセットをAzure Policyで制御 | 開発者が自由にルーティング対象モデルを広げることを防ぎやすくなる |
| 適用タイミング | デプロイ時にポリシー評価 | 非承認モデルを含む新規作成・更新リクエストはブロック対象になる |
| 対象チャネル | Foundryポータル、REST API、Azure CLI、ARMテンプレート | ポータルだけでなくIaCやCI/CDパイプラインも影響を受ける |
| 既存デプロイ | ポリシー変更後にコンプライアンス状態として検出 | 既に作成済みのModel Routerも棚卸しが必要 |
| ポリシー定義 | 既存の組み込みFoundryモデルデプロイポリシーを利用 | Model Router専用に別ポリシーを作る必要は基本的にない |
重要なのは、Azure Policyが実行時のプロンプトごとの推論内容を制御するわけではない点です。制御の中心は、どのモデルをModel Routerのルーティング候補としてデプロイに含められるかです。非承認モデルを含むデプロイは、APIやCLI、ARMテンプレートではポリシー違反として拒否されます。(Microsoft Learn)
Model Routerを使う組織でこの更新が重要な理由
Model Routerの価値は、用途に応じて高性能モデル、低コストモデル、推論向けモデルなどを使い分けられる点にあります。たとえば、FAQ要約のような軽い処理は低コストなモデルに、複雑な推論が必要な処理は高品質なモデルに寄せる、といった運用がしやすくなります。Microsoft Learnでは、Model Routerはプロンプトの複雑さ、推論の必要性、タスク種別などを見てルーティングし、Balanced、Cost、Qualityといったルーティングモードを選べると説明されています。(Microsoft Learn)
ただし、企業利用では「使えるモデルが増える」ことはそのまま「管理対象が増える」ことでもあります。モデルごとにデータ取り扱い、リージョン、価格、性能、契約条件、社内承認状況が異なるためです。特に複数部門がAzure AI Foundryを使っている場合、個別チームごとの判断に任せると、次のような問題が起きやすくなります。
| 起こりやすい問題 | 具体例 |
|---|---|
| 未承認モデルの利用 | セキュリティレビュー前のモデルがPoCから本番相当の環境に広がる |
| コストのばらつき | 高品質モデルに偏り、想定より推論コストが増える |
| 監査対応の負荷 | どのチームがどのモデルを使える状態にしたか追跡しづらい |
| IaCとの不整合 | ポータルでは制限しているのに、テンプレート経由で別モデルが指定される |
| 変更管理の不足 | 新しいモデルが追加された際に、社内承認プロセスを通さず利用される |
今回のプレビューは、こうした問題をAzure Policyで中央管理しやすくするものです。AIガバナンスを「開発者へのお願い」ではなく、Azureのデプロイ制御として実装できる点が大きな意味を持ちます。
影響を受ける対象者
この更新は、Model Routerを直接使う開発者だけでなく、Azure環境全体の統制に関わる担当者にも影響します。
| 対象者 | 確認すべきこと |
|---|---|
| Azure管理者 | Azure Policyの割り当て範囲、Effect、許可済みPublisher、許可済みAsset ID |
| セキュリティ・コンプライアンス担当 | 利用を許可するモデルの基準、例外申請フロー、監査ログの見方 |
| AIアプリ開発者 | Model Routerのモデルサブセット、ブロックされたモデルの確認方法、APIエラー時の対応 |
| DevOps・IaC担当 | ARMテンプレート、Bicep、CLI、REST APIのデプロイ定義に非承認モデルが含まれていないか |
| FinOps・SRE担当 | モデルサブセット変更後のコスト、レイテンシ、品質への影響 |
特に、CI/CDパイプラインでModel Routerを自動デプロイしている環境では注意が必要です。ポリシー適用後は、これまで成功していたテンプレートが、非承認モデルを含むことで失敗する可能性があります。Microsoft Learnでは、REST API、Azure CLI、ARMテンプレート経由のModel RouterデプロイでもAzure Policyが評価されると説明されています。(Microsoft Learn)
管理者が確認すべきAzure Policy設定
使用する組み込みポリシーを確認する
Model Router用にまったく新しいポリシー定義を作る必要があるわけではありません。Microsoft Learnでは、Model Routerは他のFoundryモデルデプロイを統制する組み込みポリシー「Foundry model deployments should only use approved models」を利用すると説明されています。なお、このポリシーは以前「Cognitive Services Deployments should only use approved Registry Models」という名称だったものの、ポリシー定義IDは変更されていないため、既存の割り当てはそのまま機能します。(Microsoft Learn)
まずAzure管理者は、以下を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| ポリシー名 | Foundry model deployments should only use approved models |
| 割り当て範囲 | 管理グループ、サブスクリプション、リソースグループのどこに適用しているか |
| Effect | AuditなのかDenyなのか |
| Allowed Models Publishers | 許可するPublisher名が正確に入っているか |
| Allowed Asset Ids | 許可するモデルAsset IDが正確に入っているか |
| 例外スコープ | PoC用や検証用の除外設定が意図通りか |
Model Routerのモデルサブセットは、Foundryリソースが作成されているスコープでポリシーを評価します。サブスクリプション全体に適用するのか、特定リソースグループだけに適用するのかで、開発者の体験は変わります。(Microsoft Learn)
Model Routerでは「Microsoft」のPublisher指定を忘れない
Model Routerをポリシー配下で使う場合、許可済みPublisherにMicrosoftを含める必要があります。これは、Model Router自体のPublisherがMicrosoftであるためです。さらに、ルーティング対象にする各モデルのPublisherも許可する必要があります。たとえばClaudeモデルをルーティング対象にする場合は、該当モデルのPublisherとしてAnthropicも考慮します。許可済みPublisherに必要な名前が含まれていない場合、Model Routerのデプロイがブロックされる可能性があります。(Microsoft Learn)
実務では、Publisher名だけで広く許可するのではなく、必要に応じてAsset ID単位で絞り込む設計を検討してください。Publisher名で広く許可すると、同じPublisherが提供する別モデルまで許可範囲に入る可能性があります。反対にAsset IDを厳格に指定する場合は、モデル更新や新バージョン追加のたびにポリシー更新が必要になることがあります。
Asset IDとPublisher名は完全一致で管理する
モデルのAsset IDやPublisher名は、ポリシーのパラメーターと完全に一致している必要があります。Microsoft Learnでは、モデルIDが完全一致しない場合はポリシーが期待通りに機能しないこと、Publisher名やAsset IDの大文字小文字にも注意が必要なことが示されています。(Microsoft Learn)
おすすめは、承認済みモデルの台帳を作ることです。最低限、次の情報をまとめておくと運用が安定します。
| 台帳項目 | 記録例 |
|---|---|
| モデル名 | gpt系、Claude系など |
| Publisher | Microsoft、OpenAI、Anthropicなど |
| Asset ID | Foundryポータルのモデル詳細から取得した正確なID |
| 承認理由 | 本番利用可、PoCのみ、特定業務のみなど |
| 利用可能環境 | dev、stg、prod |
| 承認日・更新日 | 変更管理と監査用 |
| 所有部門 | 例外申請や問い合わせ先 |
いきなりDenyにせずAuditで影響を確認する
Azure Policyには、違反を記録するAudit系の運用と、違反リソースの作成・更新を拒否するDeny系の運用があります。Azure Policyの公式ドキュメントでも、既存の自動化や環境への影響を把握するため、強制適用の前にAuditまたはauditIfNotExistsから始める考え方が紹介されています。(Microsoft Learn)
Model Routerに対しても、次の順序で進めると失敗を減らせます。
| フェーズ | Effect | 目的 |
|---|---|---|
| 事前調査 | Audit | 既存デプロイやテンプレートがどの程度影響を受けるか確認 |
| 検証環境 | Deny | 非承認モデルが実際にブロックされるか確認 |
| 一部本番 | Deny | 影響の小さい部門・リソースグループから適用 |
| 全体展開 | Deny | 標準運用として強制 |
ポリシー割り当て後は、反映まで最大15分程度かかる場合があります。また、コンプライアンスダッシュボードへの反映は最大24時間かかる場合があるため、テスト直後に結果が出ないことを異常と判断しないようにしてください。(Microsoft Learn)
開発者・IaC担当が確認すべき展開上の注意点
Foundryポータルでは非承認モデルが見えるが選べない
Azure Policyが有効な環境でModel Routerを展開すると、Foundryポータルのモデルサブセット選択画面では、サポート対象モデルの一覧自体は表示されます。ただし、組織のポリシーで許可されていないモデルはチェックボックスが無効化され、選択できません。Microsoft Learnでは、開発者がブロックされたモデルを確認できるよう、バナーや「View blocked」による確認導線が用意されると説明されています。(Microsoft Learn)
これは開発者体験として重要です。単にモデルが消えるのではなく、存在は分かるが選べないため、「なぜ使えないのか」「誰に申請すべきか」を判断しやすくなります。管理者側は、ブロックされたモデルを使いたい場合の申請フローを社内ドキュメントに明記しておくべきです。
REST API、Azure CLI、ARMテンプレートではポリシー違反として失敗する
ポータル以外の方法でModel Routerを作成する場合も、Azure Policyはコントロールプレーンで評価されます。非承認モデルを含むModel Routerデプロイ要求はポリシー違反として拒否され、Model Routerデプロイ自体は作成されません。(Microsoft Learn)
そのため、IaC担当者は次の確認を行ってください。
| 確認対象 | チェック内容 |
|---|---|
| ARMテンプレート・Bicep | モデルサブセットに非承認モデルが含まれていないか |
| Azure CLIスクリプト | ハードコードされたモデル名やAsset IDが古くないか |
| REST APIリクエスト | リクエストボディに許可外モデルが含まれていないか |
| CI/CDパイプライン | ポリシー違反時に分かりやすいエラーとして検知できるか |
| 環境別設定 | devでは許可、prodでは禁止といった差分が明示されているか |
よくある失敗は、ポータルで選べるモデル一覧を見てテンプレートを作成し、別スコープの本番環境へ展開したらポリシー違反になるケースです。ポリシーはスコープごとに異なるため、テンプレート側では「環境ごとの許可済みモデル一覧」を参照する設計にしておくと安全です。
モデルサブセットは明示的に管理する
Model Routerは、デフォルト設定ではサポート対象のモデルセットを使ってルーティングします。一方、最新のModel Routerではモデルサブセットを選択でき、ルーティング候補に含めるモデルを指定できます。Microsoft Learnでは、新しいベースモデルが追加された場合でも、明示的に選択したモデルサブセットには自動で含まれないと説明されています。(Microsoft Learn)
コンプライアンスを重視する環境では、デフォルトの広いモデルセットに頼るより、承認済みモデルだけをモデルサブセットとして明示する方が運用しやすくなります。これにより、次のような管理がしやすくなります。
| 管理したい観点 | モデルサブセットで得られる効果 |
|---|---|
| コンプライアンス | 承認済みモデルだけをルーティング候補にできる |
| コスト | 高価格帯モデルの利用範囲を絞れる |
| 品質 | 業務要件を満たしたモデルだけに限定できる |
| レイテンシ | 応答時間が安定しやすいモデルに寄せられる |
| 変更管理 | 新モデル追加時に明示的な承認プロセスを挟める |
既存デプロイの移行・棚卸し手順
既にModel Routerを使っている場合、Azure Policyを割り当てた瞬間にすべてが自動修正されるわけではありません。Microsoft Learnでは、新しいポリシー割り当てや既存ポリシーの更新により、既存のModel Routerデプロイが再評価され、非準拠リソースがComplianceダッシュボードに表示されると説明されています。 remediationとしては、非承認モデルをモデルサブセットから外すか、デプロイを削除して承認済みモデルだけで作り直す方法が示されています。(Microsoft Learn)
移行は次の順番で進めると安全です。
| 手順 | 作業内容 | 目的 |
|---|---|---|
| 1 | FoundryリソースとModel Routerデプロイを棚卸しする | 影響範囲を把握する |
| 2 | 現在のモデルサブセットと利用部門を確認する | 非承認モデルの有無を洗い出す |
| 3 | 承認済みPublisherとAsset IDの一覧を作る | ポリシーパラメーターの根拠を明確にする |
| 4 | Auditでポリシーを割り当てる | 既存デプロイやIaCへの影響を確認する |
| 5 | 非準拠のModel Routerを修正する | モデルサブセット更新または再作成で準拠させる |
| 6 | 品質・コスト・レイテンシを再評価する | モデル候補の変更によるアプリ影響を確認する |
| 7 | Denyに切り替える | 非承認モデルを含む新規・更新デプロイを防ぐ |
| 8 | Complianceとコストを継続監視する | 運用上の逸脱を早期に見つける |
ここで見落としやすいのが、モデルサブセット変更によるアプリ挙動の変化です。アプリ側の呼び出し方法が同じでも、ルーティング候補のモデルが変われば、応答品質、コスト、レイテンシが変わる可能性があります。Microsoft Learnでは、Model Routerを本番トラフィックに使う前に、品質、コスト、レイテンシの3軸で評価し、代表的なプロンプトを使って比較することが推奨されています。(Microsoft Learn)
展開時に失敗しやすいポイント
Azure Policy Coverage for Model Router in Foundry Modelsで起きやすいトラブルは、ポリシー設定そのものよりも、スコープやモデルIDの不一致に集中します。
| 症状 | 主な原因 | 対応 |
|---|---|---|
| Model Routerのデプロイがブロックされる | 許可済みPublisherにMicrosoftが含まれていない | Model Router自体のPublisherとしてMicrosoftを追加する |
| 承認済みのはずのモデルがブロックされる | Asset IDまたはPublisher名が完全一致していない | モデルカタログから正確な値をコピーし、大文字小文字も確認する |
| ポータルでは使えるのにCLIでは失敗する | プロジェクトやリソースグループごとにポリシースコープが違う | Policy > Assignmentsで割り当て範囲とパラメーターを比較する |
| モデルサブセットのチェックボックスが無効 | サブスクリプションまたはリソースグループのポリシーで制限されている | バナーとブロック一覧を確認し、必要なら管理者に承認申請する |
| Complianceにすぐ表示されない | 評価サイクルがまだ完了していない | 最大24時間待つか、オンデマンド評価スキャンを検討する |
| ポリシーを設定したのにブロックされない | EffectがAuditのまま、または反映待ち | EffectをDenyにする前提か確認し、15分程度の伝播時間を考慮する |
特に本番環境では、「許可済みPublisherに入っているから安全」と短絡的に判断しないことが重要です。Publisher単位の許可は管理しやすい一方、細かなモデル制御には向きません。厳格な環境では、PublisherとAsset IDの両方を使い、承認済みモデルだけを明確に定義する運用が望まれます。
リージョン、クォータ、プレビュー状態も合わせて確認する
Model RouterをAzure Policyで統制できても、Model Router自体の利用可否はリージョンやデプロイタイプ、クォータの影響を受けます。Microsoft Learnでは、Model Routerのリソース制限として対応リージョンやデプロイタイプが示されており、最新のリージョン可用性を確認するよう案内されています。(Microsoft Learn)
また、Public Previewの機能は仕様や画面、対応範囲が変わる可能性があります。運用設計では、次のように切り分けると判断しやすくなります。
| 環境 | 推奨方針 |
|---|---|
| 個人検証・PoC | 小さなリソースグループでAuditまたは限定的なDenyを試す |
| 開発環境 | 承認済みモデル一覧を使い、CI/CDの失敗パターンを確認する |
| ステージング | 本番同等のポリシーでModel Routerの品質・コスト・レイテンシを評価する |
| 本番環境 | プレビュー利用に関する社内基準、サポート要件、監査要件を確認してから適用する |
プレビューだから使うべきではない、という話ではありません。むしろ、AIガバナンスを早期に整えるには有用です。ただし、本番環境に展開する場合は、社内のプレビュー利用ルール、Microsoftの最新ドキュメント、サポート条件を確認したうえで判断してください。
運用で見るべき監視・コストのポイント
Azure Policyで非承認モデルを防いでも、承認済みモデルの範囲内でどのモデルにルーティングされるかによって、コストやレイテンシは変わります。Microsoft Learnでは、Model RouterのパフォーマンスはAzure Monitorでデプロイ名をフィルターして確認でき、必要に応じて基盤モデル別にメトリックを分割できると説明されています。また、コストはAzureポータルのCost analysisでリソースやデプロイ名をもとに確認する方法が案内されています。(Microsoft Learn)
運用開始後は、少なくとも次の指標を見てください。
| 指標 | 見る理由 |
|---|---|
| p50、p90、p95レイテンシ | 平均値だけでは外れ値や体感遅延を見落としやすい |
| 入力・出力トークン量 | モデル変更によるコスト増を把握する |
| ルーティング先モデルの傾向 | 想定より高価なモデルへ偏っていないか確認する |
| エラー率・レート制限 | Model Router側のTPM/RPMや下位モデルの制限を確認する |
| 品質評価スコア | モデルサブセットを絞った結果、回答品質が下がっていないか確認する |
Model Routerはコスト最適化に役立つ可能性がありますが、ポリシーで候補モデルを絞りすぎると、期待した品質やレイテンシが出ないことがあります。承認済みモデルを最小化するだけでなく、業務要件を満たす組み合わせになっているかを評価することが重要です。
導入判断の基準
今回のPublic Previewは、次のような組織ほど早めに検証する価値があります。
| 状況 | 導入・検証を優先すべき理由 |
|---|---|
| 複数部門がAzure AI Foundryを利用している | モデル利用ルールを中央管理しないと統制が崩れやすい |
| 生成AI利用に社内承認プロセスがある | 承認済みモデルだけを強制しやすくなる |
| IaCでFoundry環境を展開している | ポータル操作だけでなくテンプレート展開も制御できる |
| モデルコストを部門別に管理したい | 高コストモデルの利用範囲を制限しやすい |
| 監査対応が必要 | Complianceダッシュボードで非準拠状態を確認しやすい |
一方で、まだ承認済みモデル一覧がない、Model Routerの評価が終わっていない、リージョンやクォータの確認が済んでいない場合は、まずAuditで実態把握から始めるべきです。ガバナンス機能は強力ですが、準備不足のままDenyを適用すると、開発チームのデプロイを止めるだけになってしまいます。
次に取るべき行動
Azure AI Foundryの「Public Preview: Azure Policy Coverage for Model Router in Foundry Models」は、Model Routerを企業利用するうえで重要なガバナンス強化です。ポイントは、Model Routerのルーティング候補モデルをAzure Policyで統制し、FoundryポータルだけでなくREST API、Azure CLI、ARMテンプレート経由の展開にも同じルールを適用できることです。
まずは、次の順番で確認してください。
- Azure AI FoundryのModel Routerデプロイを棚卸しする
- 承認済みモデルのPublisher名とAsset IDを台帳化する
- 組み込みポリシーの割り当て範囲とEffectを確認する
Microsoftおよび必要なモデルPublisherが許可されているか確認する- Auditで既存デプロイとIaCへの影響を確認する
- モデルサブセットを承認済みモデルに整理する
- 品質、コスト、レイテンシを再評価する
- 問題がなければ段階的にDenyへ切り替える
Model Routerは、モデル選択を柔軟にする機能です。Azure Policy Coverageは、その柔軟性を組織のルール内で安全に使うための仕組みです。開発スピードと統制のどちらかを犠牲にするのではなく、承認済みモデル、ポリシー、IaC、監視をセットで整備することが、Azure AI Foundryを実務で安定運用する近道です。
コメント