Azure Static Web Apps作成で「Subscription could not be found or is invalid for CreateOrUpdateStaticSite」発生時の原因と対処(Microsoft.Web登録で解決)

Azure Static Web Apps を新規作成しようとした際に「Subscription <subscription_id> could not be found or is invalid for CreateOrUpdateStaticSite」という不可解なエラーに遭遇するケースが散見されます。実は多くの場合、サブスクリプションや権限の問題ではなく、特定のリソースプロバイダー登録が原因です。本稿では、最短で直す具体手順から恒久対策、深掘りの技術背景までを一気通貫で解説します。

目次

エラーの概要と前提条件

Portal/CLI いずれの経路でも次のようなエラーメッセージでデプロイが失敗します。

Subscription <subscription_id> could not be found or is invalid for CreateOrUpdateStaticSite
観測状況詳細
状況Azure ポータルで Static Web App 作成ウィザードを実行するとデプロイが失敗。
前提サブスクリプション ID は正しい 自身のロールは Owner 直近で 無料版 → 従量課金 (Pay‑As‑You‑Go) にアップグレード 他のリソースは作成できるが、Static Web Apps だけ失敗する

最短解決の結論(先に答え)

この症状の 最頻原因 は、サブスクリプションに Microsoft.Web リソースプロバイダーが「未登録」または「不安定登録」の状態であることです。無料トライアルやアップグレード直後は、一部のプロバイダーが自動で登録されない/伝播が遅延することがあり、Static Web Apps のように Microsoft.Web/staticSites リソースタイプを使うサービスだけが失敗します。

手順内容
原因特定多くの場合、Microsoft.Web リソースプロバイダーがサブスクリプションに登録されていない/登録が不安定。
1. プロバイダーを登録/再登録ポータル:「サブスクリプション」→ 対象サブスクリプション →「リソースプロバイダー」→ Microsoft.Web → [登録] Azure CLI: az provider register --namespace Microsoft.Web PowerShell: Register-AzResourceProvider -ProviderNamespace "Microsoft.Web"
2. 登録状態を確認az provider show --namespace Microsoft.Web --query "registrationState" Registered が返れば OK。
3. 反映待ち登録完了後、5〜10 分程度待ってから再度作成を試行。
4. CLI 経由での作成ポータルが依然失敗する場合は CLI で作成: az staticwebapp create --name <アプリ名> --resource-group <RG名> --location "Central US"
5. 追加チェックサブスクリプションあたりの Static Web App 上限(Free: 10、Standard: 100)を超えていないか 別リージョンで試す(例: East US, West Europe など) ブラウザのキャッシュ削除やシークレットウィンドウの使用

結果(実例): Microsoft.Web を「再登録」したところ、Static Web App を問題なく作成できた、という報告が多数あります。

なぜ起こるのか ― 技術的背景

Azure の各サービスは「リソースプロバイダー」として公開され、サブスクリプション単位で登録(Register)することで初めてそのリソースタイプを作成できます。Static Web Apps は Microsoft.Web/staticSites を使用するため、Microsoft.Web の登録が必須です。

無料トライアルから従量課金へ切り替えた直後は、課金種別やディレクトリの変更が裏側のスタンプに伝播するまでラグが生じることがあります。さらに、登録済みでも状態が Registering のまま固着、あるいは Unregistered に戻ってしまう稀なケースがあり、その際に本エラーが発生します。結果として「他のリソースは作れるのに Static Web Apps だけ作れない」という現象になります。

想定要因説明典型的な兆候
Microsoft.Web 未登録Static Web Apps のリソースタイプが許可されていない。登録状態が NotRegistered または Unregistered。
登録の伝播遅延ディレクトリ/課金変更の伝播が遅れている。登録後に 5〜10 分の待機で解消。
サブスクリプション・ポリシー「許可リソースタイプ」や「Deny 未登録プロバイダー」などのポリシーで遮断。Policy 名が含まれる Deny エラーが付随する/Portal 上で警告。
リージョン制約選択リージョンで Static Web Apps がサポート外、または SKU 制限。リージョンを変えると成功。
上限超過サブスクリプションの Static Web Apps 上限に達している。Free/Standard の上限を超えた時に失敗。

確実に直すための詳細手順

0. スコープの確認(ヒューマンエラー排除)

本題の前に、念のため現在の操作対象が正しいサブスクリプション/ディレクトリであるかを確認しておきます。

# 現在のアカウント/サブスクリプション
az account show --output table

# (必要なら)対象サブスクリプションを明示

az account set --subscription 

1. Microsoft.Web を登録/再登録する

ポータルでの動作は次の通りです:

  1. 「サブスクリプション」→ 対象サブスクリプションを開く
  2. 左メニュー「リソースプロバイダー」→ 検索欄に Microsoft.Web と入力
  3. 状態が 未登録 または 登録解除 になっていれば [登録] または [再登録] をクリック

CLI の場合:

az provider register --namespace Microsoft.Web

PowerShell の場合:

Register-AzResourceProvider -ProviderNamespace "Microsoft.Web"

2. 登録状態の確認

az provider show --namespace Microsoft.Web --query "registrationState"

Registered であれば準備完了です。Registering の間は、少し待ってから再確認します。

3. 反映待ちの目安と再トライ

登録完了後でも、コントロールプレーンの伝播にタイムラグがあるため 5〜10 分ほど間を置いてから作成を再試行してください。ポータルがキャッシュを保持している場合があるため、シークレットウィンドウで再実行するのも有効です。

4. それでもダメなら CLI で作成してみる

ポータル固有のバリデーション/キャッシュに起因する失敗を切り分けるため、CLI で直接作成します。

# 例:Central US に Free SKU でプレーンなリソースを作成
az staticwebapp create \
  --name <アプリ名> \
  --resource-group <RG名> \
  --location "Central US"

作成後の確認:

az staticwebapp show -n <アプリ名> -g <RG名>
az staticwebapp list -g <RG名>

5. オプションとバリエーション

ワークフローまで一気通貫で構成する場合(リポジトリとブランチを指定):

az staticwebapp create \
  --name <アプリ名> \
  --resource-group <RG名> \
  --location "Central US" \
  --source https://github.com/<owner>/<repo> \
  --branch main

注:認証連携やビルド構成は別途必要になる場合があります。まずはリソース作成だけが成功するかを確認し、徐々に周辺設定を加えると切り分けが容易です。

登録状態の読み方(ステータス一覧)

registrationState意味対応
NotRegistered未登録。register を実行。
Registering登録中(伝播待ち)。数分待ってから再確認。
Registered登録済み。作成を再試行。
Unregistered登録解除状態。再登録(Re-register)。

うまくいかない時のチェックリスト(深掘り)

現象確認コマンド/確認箇所対処
Owner だが作成できないaz role assignment list \ --assignee <UPN または ObjectId> \ --scope /subscriptions/<subscription_id> \ --query "[?roleDefinitionName=='Owner']" スコープが サブスクリプション になっているか要確認(RG スコープのみだと失敗することがあります)。必要に応じてサブスクリプション直下に Owner/Contributor を付与。
Policy による拒否az policy assignment list --scope /subscriptions/<subscription_id> --output table 「許可されたリソースタイプ」や「未登録プロバイダー拒否」などがあると作成不可。一時的に例外スコープを設定/ポリシーを緩和、または Microsoft.Web を事前登録。
リージョン制約ポータル作成画面でリージョンを変更して試行。East US / West Europe 等の一般的リージョンで再試行。
上限(クォータ)超過既存の Static Web Apps 数を確認。不要なリソースの削除、または SKU の見直し。
ディレクトリ(テナント)違いポータル右上のディレクトリを確認。CLI は az account show で確認。正しいディレクトリへ切り替え。
支払い・制限無料枠の「支出の上限」からの切り替え直後は反映待ちが必要な場合があります。時間を置く/課金情報が正しく紐付いているかを確認。
ブラウザキャッシュポータルの長期セッションで状態が古いまま。シークレットウィンドウ/別ブラウザで再試行。

ケーススタディ(再登録で解決)

質問者の環境では、無料版から従量課金へ切り替えた直後に本エラーが発生。サブスクリプション ID とロールは正しく、他のサービスは作成できる状態でしたが、Static Web Apps に限って失敗していました。サブスクリプションのリソースプロバイダー一覧を確認したところ、Microsoft.Web が未登録(または不安定)であることを確認。再登録 後に 5〜10 分待ってから再試行したところ、問題なく作成が完了しました。

なぜ「再登録」で直るのか(仕組みの理解)

リソースプロバイダーの登録は、Azure のコントロールプレーンに対するサブスクリプションの「許可設定」です。登録操作自体は即時応答しますが、裏側では複数のリージョン/スタンプに設定が伝播します。課金プランの変更やディレクトリ切替とタイミングが重なると、特定サービスの権限だけが遅延する場合があります。再登録はこの伝播を再トリガーし、未整合な状態を解消するのに有効です。

予防策(同種のトラブルを未然に防ぐ)

  • 事前登録の徹底:新しい Azure サービスを初めて使う前に、主要なプロバイダーを登録しておく。 az provider register --namespace Microsoft.Web
  • IaC に組み込む:Bicep/Terraform/スクリプトに「プロバイダー登録の確認→未登録なら登録」を入れておく。
  • CLI/PowerShell での検証:ポータルより詳細なエラーが得られるため、デプロイ前に az / Az PowerShell での疎通確認を行う。
  • ポリシー整備:「未登録プロバイダー拒否」系のポリシーを使う場合は、Microsoft.Web を必ず登録済みにしておくか例外を適用する。
  • リージョン標準化:チーム内で利用リージョンを標準化し、サポート有無の揺らぎを避ける。

運用を強くする自動化スニペット

Bash(Azure CLI)

#!/usr/bin/env bash
set -euo pipefail

SUBSCRIPTION_ID="<subscription_id>"
PROVIDER="Microsoft.Web"

az account set --subscription "${SUBSCRIPTION_ID}"

STATE=$(az provider show --namespace "${PROVIDER}" --query "registrationState" -o tsv || echo "NotRegistered")
if [ "${STATE}" != "Registered" ]; then
echo "Registering ${PROVIDER} (current: ${STATE})..."
az provider register --namespace "${PROVIDER}" 1>/dev/null

# 伝播待ち(最大 10 分を目安にループ)

for i in {1..20}; do
sleep 30
STATE=$(az provider show --namespace "${PROVIDER}" --query "registrationState" -o tsv || true)
echo "State: ${STATE}"
[ "${STATE}" = "Registered" ] && break
done
fi

if [ "${STATE}" != "Registered" ]; then
echo "ERROR: ${PROVIDER} registration not completed." >&2
exit 1
fi

echo "OK: ${PROVIDER} is Registered."

# ここで az staticwebapp create を実行

PowerShell(Az モジュール)

param(
  [Parameter(Mandatory=$true)][string]$SubscriptionId
)

$ErrorActionPreference = "Stop"
Select-AzSubscription -SubscriptionId $SubscriptionId | Out-Null

$ns = "Microsoft.Web"
$rp = Get-AzResourceProvider -ProviderNamespace $ns -ErrorAction SilentlyContinue
if (-not $rp -or $rp.RegistrationState -ne "Registered") {
Write-Host "Registering $ns (current: $($rp.RegistrationState))..."
Register-AzResourceProvider -ProviderNamespace $ns | Out-Null

for ($i=0; $i -lt 20; $i++) {
Start-Sleep -Seconds 30
$rp = Get-AzResourceProvider -ProviderNamespace $ns
Write-Host "State: $($rp.RegistrationState)"
if ($rp.RegistrationState -eq "Registered") { break }
}
}

if ($rp.RegistrationState -ne "Registered") {
throw "ERROR: $ns registration not completed."
}

Write-Host "OK: $ns is Registered."

# ここで New-AzResource などの自動化を続行

よくある質問(FAQ)

Q. 自分は Owner なのに、なぜ作成できないのですか?

RBAC 権限とリソースプロバイダー登録は別物です。Owner であっても、サブスクリプションに対象プロバイダーが未登録だと新規作成は拒否されます。

Q. 無料→従量課金へ切り替えた直後に失敗します。

課金・ディレクトリ情報の伝播とプロバイダー登録が同期しない場合があります。再登録後に数分待って再試行してください。

Q. どのリージョンを選ぶべきですか?

まずは一般的なメジャーリージョン(例: East US / West Europe など)で成功を確認し、必要に応じて近傍リージョンへ移すのが確実です。

Q. 既存の IaC(Bicep/Terraform)を変えずに直せますか?

はい。デプロイ前に Microsoft.Web の登録確認と不足時の登録処理を追加するだけで、多くの環境で安定します。

エラーメッセージのバリエーション(参考)

  • Subscription 'xxxx' could not be found
  • Subscription is invalid for CreateOrUpdateStaticSite
  • Resource type 'staticSites' could not be found in namespace 'Microsoft.Web'
  • RequestDisallowedByPolicy(ポリシーにより拒否)

いずれも本質的には「そのサブスクリプションで Microsoft.Web/staticSites を 今 使える状態にない」ことを示唆します。まずはプロバイダー登録を疑い、次にポリシー/リージョン/上限を切り分けるのが定石です。

まとめ

Azure Static Web Apps 作成時の「Subscription が見つからない/無効」エラーは、サブスクリプションやロール設定の問題に見えて、実は Microsoft.Web リソースプロバイダー未登録(または不整合) が原因の王道パターンです。ポータル/CLI いずれでも 登録→状態確認→数分待機→再作成 の流れで大半は解決します。運用としては、プロバイダー登録の事前確認を自動化に組み込み、ポリシーやリージョンの標準を整備することで、同種のトラブルを未然に防止できます。

補足:再掲(素早く直すチェックリスト)

  1. スコープ確認:az account show で対象サブスクリプションか確認。
  2. 登録/再登録:az provider register --namespace Microsoft.Web。
  3. 状態確認:az provider show --namespace Microsoft.Web --query "registrationState" が Registered。
  4. 5〜10 分待つ:伝播を待つ。
  5. CLI で作成:az staticwebapp create --name ... --resource-group ... --location "Central US"。
  6. 追加チェック:上限/リージョン/ポリシー/ブラウザキャッシュ。

経験則:この順で対応すれば、ほとんどのケースを短時間で収束できます。

補足・予防策(再掲)

  • 新しい Azure サービスを初めて使う前に、az provider register --namespace <プロバイダー名> で主要プロバイダーを先に登録しておくと同種のエラーを防ぎやすい。
  • CLI/PowerShell は、ポータルより詳細なエラーが得られるためトラブルシューティングに有効。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次