Azure Machine Learning の管理対象オンライン エンドポイントを作成しようとした際に、HttpResponseError: (SubscriptionNotRegistered) Resource provider [N/A] isn't registered with Subscription [N/A] というメッセージだけが表示されて詰まっていませんか？この記事では、この分かりにくいエラーの正体と、実務で再現性高く解消できた手順を、Azure ポータル／CLI の具体的な操作例とともに整理します。
Azure ML 管理対象オンライン エンドポイントとエラーの位置づけ
まずは、問題がどのレイヤーで起きているのかを整理します。
Azure Machine Learning の「管理対象オンライン エンドポイント（Managed Online Endpoint）」は、学習済みモデルをリアルタイム推論用の HTTPS エンドポイントとして、Azure が管理するインフラ上にホストしてくれる機能です。
ユーザーはコンテナー基盤やロードバランサーを意識せず、エンドポイントとデプロイ（deployment）を定義するだけで利用できます。
このエンドポイントを新規作成／更新するとき、内部では次のような処理が走ります。
- Azure Resource Manager（ARM）経由で、エンドポイントや関連リソースのデプロイ テンプレートを実行
- Azure Policy によるコンプライアンス／ポリシー評価
- 必要に応じてネットワーク、ID、ストレージなどの関連リソースへアクセス
- エンドポイントを外部公開するためのフロント（CDN / Front Door 系サービス）との連携
今回の SubscriptionNotRegistered エラーは、このうち「サブスクリプションに必要なリソース プロバイダーが登録されていない」段階で落ちているパターンです。ARM テンプレートなどで別サービスを作成するときにも同様のエラーが発生しますが、通常は「どのプロバイダーが未登録か」がメッセージに表示されます。
発生するエラー メッセージと典型的な状況
問題となるエラーは、Python SDK や CLI、スタジオ（ポータル）など、どの経路からデプロイしてもほぼ同じメッセージで現れます。
HttpResponseError: (SubscriptionNotRegistered)
Resource provider [N/A] isn't registered with Subscription [N/A].
典型的な状況を整理すると次のようになります。
| 項目 | 内容 |
|---|---|
| 発生タイミング | 管理対象オンライン エンドポイントの作成／更新／デプロイ作成時 |
| 利用クライアント | Azure ポータル（スタジオ）、Azure CLI、Python SDK いずれでも再現 |
| 対象リージョン | East US / East US 2 / West Europe など複数リージョンで報告あり |
| 環境の状態 | 以前は同じ環境・コードで問題なくデプロイできていたのに、ある日突然失敗し始めるケースが多い |
| メッセージの問題点 | 本来表示されるはずのプロバイダー名が [N/A] のままで、どのリソース プロバイダーを登録すればよいのか判断できない |
Microsoft Q&A や Stack Overflow でも、まったく同じエラー メッセージで管理対象オンライン エンドポイントの作成に失敗する事例が多数報告されています。
原因の全体像：間接依存しているリソース プロバイダーの未登録
この現象のポイントは、Azure ML そのものではなく、「Azure ML が間接的に利用している別サービスのリソース プロバイダーが未登録」 なことです。
リソース プロバイダーとは？（おさらい）
Azure では、「どの種類のリソースをそのサブスクリプションで使えるか」を、名前空間単位の「リソース プロバイダー」で管理しています。
Microsoft.MachineLearningServices：Azure Machine Learning ワークスペースやコンピューティングなどMicrosoft.Storage：ストレージ アカウントMicrosoft.Network：仮想ネットワーク、パブリック IP などMicrosoft.PolicyInsights：Azure Policy の評価／ポリシー状態の記録Microsoft.Cdn：Azure CDN / Front Door 系サービス
これらはサブスクリプションごとに登録状態が管理されており、「登録（Registered）」状態でないプロバイダーは、そのサブスクリプションでは利用できません。多くのプロバイダーは、初めて関連リソースを作成したときに自動登録されますが、そうならないケースもあります。
なぜプロバイダー名が [N/A] になるのか
本来、未登録のプロバイダーが原因であれば、次のように名前空間がメッセージに出ることが多いです。
SubscriptionNotRegistered: The subscription is not registered to use namespace 'Microsoft.XXX'.
しかし、今回のケースでは次のように [N/A] が入ってしまいます。
Resource provider [N/A] isn't registered with Subscription [N/A].
これは、エンドポイント作成フローの奥で利用されているサービス（ポリシー評価やフロント エンド基盤など）が、未登録のプロバイダーに依存している結果、「どのプロバイダーが原因なのかを Azure ML 側が特定しきれない」 状態でエラーを返していると考えられます。
実際に、Microsoft Q&A の回答やブログ記事では、Microsoft.PolicyInsights や Microsoft.Cdn をサブスクリプションに登録することで、この [N/A] 付きのエラーが解消することが繰り返し報告されています。
実務で有効だった解決策：Microsoft.PolicyInsights と Microsoft.Cdn を登録する
結論から言うと、次のリソース プロバイダーをサブスクリプションに登録することで、多くの環境でエラーが解消されています。
Microsoft.PolicyInsightsMicrosoft.Cdn（「Microsoft.Cnd」ではなく綴りに注意）- （一部環境で必要）
Microsoft.ApiManagement
まずは Microsoft.PolicyInsights と Microsoft.Cdn の 2 つを登録し、まだだめな場合に Microsoft.ApiManagement の登録も試す、という順番がおすすめです。
Microsoft の公式ドキュメントや Q&A でも、オンライン エンドポイントやフローをデプロイする前提条件として Microsoft.PolicyInsights の登録が明記されており、同様のエラーに対して Microsoft.Cdn も合わせて登録するよう案内されています。
権限の確認：誰がリソース プロバイダーを登録できるか
リソース プロバイダーの登録は、サブスクリプション レベル の操作です。そのため、次のいずれかのロールが付与されている必要があります。
- 所有者（Owner）
- 共同作成者（Contributor）
- それと同等以上の権限を持つカスタム ロール
リソース グループ単位の権限や、ワークスペース単位のロールだけでは足りない点に注意してください。権限が不足していると、「登録」ボタンがグレーアウトしていたり、CLI 実行がサイレントに失敗したりします。
Azure ポータルからの登録手順
GUI での操作に慣れている場合は、Azure ポータルから次の手順で登録できます。
- Azure ポータルにサインインし、左メニューから「サブスクリプション」を開く。
- 対象となるサブスクリプションをクリック。
- 左ペインの「設定」セクションから「リソース プロバイダー」を選択。
- 検索ボックスで
Microsoft.PolicyInsightsを検索。 - ステータスが「登録解除（NotRegistered）」になっていたら、行を選択して「登録」ボタンを押す。
- 同様に
Microsoft.Cdnを検索し、未登録であれば登録する。 - 必要に応じて
Microsoft.ApiManagementも検索し、未登録なら登録する。
登録が完了するまで数十秒〜数分かかる場合があります。ステータスが「登録済み（Registered）」になったことを確認してから、再度エンドポイントの作成／デプロイを試してください。
Azure CLI からの登録・確認手順
スクリプトで環境を自動構成している場合は、Azure CLI でまとめて登録しておくと便利です。
個別に登録する場合
# リソース プロバイダーの登録
az provider register --namespace Microsoft.PolicyInsights
az provider register --namespace Microsoft.Cdn
# 必要に応じて追加
az provider register --namespace Microsoft.ApiManagement
# 登録状態の確認
az provider show -n Microsoft.PolicyInsights --query "registrationState"
az provider show -n Microsoft.Cdn --query "registrationState"
az provider show -n Microsoft.ApiManagement --query "registrationState"
よく使うプロバイダーをまとめて確認するワンライナー
Azure ML でよく利用するリソース プロバイダーを一括で確認したい場合は、次のようなスクリプトが便利です。
providers=(
Microsoft.MachineLearningServices
Microsoft.PolicyInsights
Microsoft.Cdn
Microsoft.ApiManagement
Microsoft.KeyVault
Microsoft.ContainerRegistry
Microsoft.ManagedIdentity
Microsoft.Storage
Microsoft.Network
Microsoft.Authorization
)
for p in "${providers[@]}"; do
echo "==== $p ===="
az provider show -n "$p" --query "{namespace:namespace, state:registrationState}" -o tsv
done
ここで state が Registered になっていないものは、必要に応じて az provider register で登録します。
主なリソース プロバイダーと役割の整理
管理対象オンライン エンドポイント周りで頻出するリソース プロバイダーを、用途とともに整理しておきます。
| 名前空間 | 主な役割 | エンドポイント作成との関係 |
|---|---|---|
Microsoft.MachineLearningServices | Azure Machine Learning ワークスペース、コンピュート、エンドポイント本体 | ワークスペースやエンドポイントのリソース定義そのものに利用 |
Microsoft.PolicyInsights | Azure Policy の評価・コンプライアンス データ | エンドポイント作成時のポリシー評価に利用。未登録だと今回のようなエラーが発生し得る |
Microsoft.Cdn | Azure CDN / Front Door によるコンテンツ配信・エッジ経由のトラフィック制御 | エンドポイント公開時のフロント エンド基盤で利用。公式回答で登録を推奨 |
Microsoft.ApiManagement | Azure API Management | APIM 経由でエンドポイントを公開する構成で利用。未登録だと関連構成で別のエラーの原因に |
Microsoft.KeyVault | シークレット／証明書の保管 | エンドポイントから他リソースへアクセスする際の資格情報などで利用 |
Microsoft.ContainerRegistry | コンテナー イメージのホスティング | カスタム コンテナーでのデプロイ時に必須 |
Microsoft.ManagedIdentity | マネージド ID | エンドポイントから Key Vault や Storage にアクセスする際の ID として利用 |
Microsoft.Storage | BLOB・ファイル・キューなどのストレージ | モデルやログの格納先として利用 |
Microsoft.Network | 仮想ネットワーク・プライベート エンドポイント | VNet 統合やネットワーク分離構成で必須 |
Microsoft.Authorization | ロール ベースのアクセス制御（RBAC）など | 権限付与やデプロイ時のアクセス検証に利用 |
今回のエラーに直接効くのは主に Microsoft.PolicyInsights と Microsoft.Cdn ですが、Azure ML を本番で使う前に、上記の一覧は一度すべて Registered にしておくことをおすすめします。
登録後の確認：エラー メッセージの変化をチェック
リソース プロバイダーを登録したあと、再度エンドポイントを作成すると、次のような振る舞いがよく見られます。
- もともとの
SubscriptionNotRegisteredエラーが出なくなり、別のエラー（例：クォータ不足、イメージ取得失敗）に変わる - あるいは、そのまま問題なくデプロイが完了する
特に、SKU を大きめに設定している場合は、クォータ不足（QuotaExceeded） に移行することがあります。その場合は、
- 一時的に SKU を小さくする
- 必要に応じて、Azure ポータルからクォータ増枠申請を行う
といった対策に切り替えます。
それでも解決しない場合の追加トラブルシュート
Microsoft.PolicyInsights と Microsoft.Cdn を登録しても状況が改善しない場合は、次の観点を順に確認してみてください。
1. サブスクリプションが本当に正しいか確認
- Azure ML ワークスペースを作成したサブスクリプションと、現在ログインしているサブスクリプションが一致しているか
- 複数サブスクリプションを切り替えながら作業している場合、CLI や Python SDK のコンテキストが想定外のサブスクリプションを指していないか
# 現在のサブスクリプション
az account show --query "{name:name, id:id}"
# サブスクリプションの切り替え
az account set --subscription <サブスクリプションID or 名前>
2. すべての関連プロバイダーが Registered になっているか
先ほどの一覧に挙げたプロバイダーのうち、特に次のものは Azure ML のエンドポイント作成で頻出です。
Microsoft.MachineLearningServicesMicrosoft.PolicyInsightsMicrosoft.CdnMicrosoft.KeyVaultMicrosoft.ContainerRegistryMicrosoft.ManagedIdentityMicrosoft.StorageMicrosoft.NetworkMicrosoft.Authorization
これらがすべて Registered になっているか、ポータル／CLI の両方で確認してください。
3. 別リージョンでも再現するか
Azure ML のエンドポイントはリージョンごとにデプロイされますが、今回のエラーはサブスクリプション単位の設定（リソース プロバイダー）が原因です。そのため、別リージョンで同じワークスペースを作っても再現することが多いものの、以下のような切り分けには意味があります。
- そもそもリージョン固有の障害や制限ではないかを確認
- 新規に作った最小構成のワークスペース＆エンドポイントでも再現するかを見る
4. デプロイ ログを確認する
スタジオ（Azure ML ポータル）からエンドポイントを作成している場合は、「デプロイ」画面のログや、Azure ポータルの「リソース グループ > デプロイ履歴」から詳細を確認します。そこに追加のヒント（例：クォータ不足／ネットワーク到達性の問題）が出ていることがあります。
5. 組織ポリシー（Azure Policy / Blueprint）の影響
企業環境では、サブスクリプションに Azure Policy や Blueprint が適用されていて、特定の種類のリソース作成が拒否されるケースがあります。その場合、
- セキュリティ／クラウド運用チームに「Azure ML 管理対象オンライン エンドポイント作成時のポリシー拒否がないか」を確認する
- 一時的に制限の緩いテスト用サブスクリプションで同じ操作を試す
といった切り分けも有効です。
なぜ「以前は動いていた環境」で急に再現するのか
現場でよく聞くのが、「同じワークスペース／同じコードで半年以上問題なくデプロイできていたのに、ある日突然このエラーが出るようになった」というパターンです。
考えられる背景としては、
- Azure ML の内部実装や依存サービスが更新され、新たに
Microsoft.PolicyInsightsなどへの依存が追加された - Azure Policy やサブスクリプション レベルの設定が組織都合で変更され、より厳しい評価フローが入った
といった、利用者のコードとは無関係な変更 が影響している可能性があります。実際に Microsoft Q&A でも、2024〜2025 年にかけて同様の事象が複数報告されており、そのたびに Microsoft.PolicyInsights と Microsoft.Cdn の登録がワークアラウンドとして案内されています。
そのため、「コードの変更がないから Azure 側の問題に違いない」と思考停止するのではなく、まずは静かにリソース プロバイダーの登録状況を確認するのがおすすめです。
運用のベストプラクティス：新規サブスクリプションでの初期設定に組み込む
今回のようなエラーは、一度プロバイダーを登録してしまえば基本的には再発しません。そこで、次のような運用にしておくと、後からハマる確率を大きく下げられます。
1. サブスクリプション作成時の「標準セット」を決める
Azure ML を利用するサブスクリプションでは、最初に下記のプロバイダーを必ず登録する、という標準ルールを決めておきます。
Microsoft.MachineLearningServicesMicrosoft.PolicyInsightsMicrosoft.CdnMicrosoft.ApiManagement（APIM を使う組織なら）Microsoft.KeyVaultMicrosoft.ContainerRegistryMicrosoft.ManagedIdentityMicrosoft.StorageMicrosoft.NetworkMicrosoft.Authorization
2. IaC（Bicep/ARM/Terraform）やスクリプトに組み込む
Azure 環境をコードで管理している場合は、az provider register を含んだ初期化スクリプトを用意し、新しいサブスクリプションでは必ずそれを実行する、という形にすると再現性が高まります。
3. トラブルシュート チェックリスト化する
チームとして Azure ML を運用している場合、「エンドポイントが作成できないときにまず見る項目」をチェックリストとして Wiki などにまとめておくと便利です。
| チェック項目 | 内容 | 確認済み |
|---|---|---|
| サブスクリプションの確認 | ワークスペースとデプロイ対象が同じサブスクリプションか | □ |
| 権限の確認 | Owner / Contributor 相当の権限があるか | □ |
| Microsoft.PolicyInsights | リソース プロバイダーが Registered になっているか | □ |
| Microsoft.Cdn | リソース プロバイダーが Registered になっているか | □ |
| その他プロバイダー | ML 関連のプロバイダーが一通り Registered か | □ |
| エラー メッセージの変化 | SubscriptionNotRegistered から別エラーに変わっていないか | □ |
| クォータ | SKU・リージョンのクォータを超過していないか | □ |
よくある質問（FAQ）
Q. Microsoft.Cnd と書かれている記事を見ました。どちらが正しいですか？
A. 正しい名前空間は Microsoft.Cdn です。公式回答でも一部で Microsoft.Cnd と誤記されており、そのままコピーされている記事もありますが、ポータルや CLI で検索するときは Microsoft.Cdn と入力してください。
Q. リソース プロバイダーを登録すると料金は発生しますか？
A. いいえ。リソース プロバイダーを登録しただけでは課金は発生しません。「その種類のリソースを作成できるようにする許可」を与えるだけです。実際に CDN プロファイルや API Management インスタンスなどを作成・利用した場合に料金が発生します。
Q. 全サブスクリプションで登録しないといけませんか？
A. リソース プロバイダーの登録状態はサブスクリプションごとに管理されるため、Azure ML を利用する可能性のあるサブスクリプションでは、いずれも登録しておくのが安全です。リージョン単位ではなく、サブスクリプション単位での設定です。
Q. なぜエラー メッセージにサブスクリプションも [N/A] と出るのですか？
A. 内部的には複数のサービスが連携して処理しているため、未登録のプロバイダー検出が Azure ML の外側で行われ、その結果だけが伝搬している可能性があります。このとき、メッセージの成形に必要な情報（どのサブスクリプション／どのプロバイダーか）が揃わず、[N/A] というプレースホルダーのまま表示されてしまうと考えられます。
まとめ
HttpResponseError: (SubscriptionNotRegistered) Resource provider [N/A] isn't registered with Subscription [N/A]は、Azure ML 本体ではなく、間接依存するリソース プロバイダーの未登録 が原因で起きることが多い。- 特に
Microsoft.PolicyInsightsとMicrosoft.Cdnの 2 つをサブスクリプションに登録することで、多くの環境で問題が解消している。 - 場合によっては
Microsoft.ApiManagementの登録も役立つほか、Azure ML で頻出する関連プロバイダーも合わせて登録しておくとよい。 - 一度登録してしまえば基本的には再発しないため、新規サブスクリプションの初期設定タスク として組み込んでおくのがおすすめ。
- エラー解消後に別のエラーが出る場合（クォータ不足など）は、その内容に応じて SKU 調整やクォータ増枠申請に進む。
同じエラーで悩んでいる場合は、まずは一度、サブスクリプションのリソース プロバイダーを落ち着いて見直してみてください。それだけで、驚くほどあっさり解決するケースが少なくありません。
コメント