Azure for Studentsでリージョン制限エラー(RequestDisallowedByAzure)を解決する方法｜Allowed locations確認手順

Azure for Students（学生向けサブスクリプション）でストレージアカウントやApp Serviceなどをデプロイしようとしたとき、RequestDisallowedByAzure や InvalidTemplateDeployment が出て先に進めないことがあります。これは多くの場合、サブスクリプションに割り当てられた Azure Policy（Allowed locations / 許可されている場所） が原因です。この記事では、自分のサブスクリプションで使えるリージョンの確認方法と、確実にデプロイを通す手順をまとめます。

Azure for Studentsで起きる「リージョンエラー」の典型例

以下のような状況に心当たりがあれば、今回の話にほぼ当てはまります。

状況	よくある操作	結果
ストレージアカウントを作成したい	East US / West Europe / India など複数リージョンを試す	どこを選んでも同じエラーで失敗
ARMテンプレート / Bicep でデプロイしたい	location に eastus や westeurope を指定	InvalidTemplateDeployment で落ちる
ポータルで作ると「推奨リージョンのみ」っぽいメッセージが出る	別リージョンに変えてリトライ	結局すべてNG

エラー画面では次のようなキーワードが見えることが多いです。

RequestDisallowedByAzure
InvalidTemplateDeployment
Policy: Allowed locations / 許可されている場所
このサブスクリプションでは推奨リージョンのみ利用可能
ポリシーにより要求が拒否された

結論：Azure for Studentsは「利用可能リージョンがサブスクリプション単位で制限」される

Azure for Studentsでは、デプロイ可能なリージョンが最初から一部に絞られていることがあります。ここが重要で、許可されているリージョンはすべての学生サブスクリプションで共通ではありません。

• 「Aさんの環境で使えたリージョン」をそのまま真似しても、あなたのサブスクリプションでは拒否されることがあります。
• 許可リージョンは Azure Policy の Allowed locations（許可されている場所） で指定されていることが多いです。
• このポリシーは通常、受講者側で勝手に無効化・変更できません（権限がありません）。

したがって解決の最短ルートは、「自分のサブスクリプションで許可されているリージョン一覧」を特定して、その中から location を選ぶことです。

なぜ全リージョンを試してもダメになるのか（エラーの仕組み）

RequestDisallowedByAzure は、Azureが「そのリクエストは受け付けられない」と判断してブロックしたときに出やすいエラーです。学生サブスクリプションでは、その判断理由がAzure Policy（組織・教育プログラム側で設定されたルール）になっているケースがよくあります。

エラー	意味	このケースで多い原因
RequestDisallowedByAzure	要求がAzure側で拒否された	Allowed locations ポリシー違反（許可外リージョン）
InvalidTemplateDeployment	テンプレートデプロイが失敗した（包括的エラー）	内部の詳細に Policy 違反が含まれている

つまり「East USがダメならWest US」ではなく、許可リストにない限り全部ダメという状態になり得ます。

最短で解決する流れ

やることはシンプルで、次の順番が一番早いです。

手順	やること	ゴール
確認	Azure Policy「Allowed locations（許可されている場所）」の割り当てを探す	許可リージョン一覧を把握
選択	許可一覧に含まれるリージョンだけでリソース作成する	デプロイ成功
再発防止	テンプレートやスクリプトで location の指定ミスを防ぐ	次回からハマらない

Azure ポータルで「Allowed locations」ポリシーから許可リージョンを確認する

まずはポータルで確認するのが確実です。画面表示は日本語/英語で多少異なりますが、見るポイントは同じです。

1. Azure ポータルにサインインします。
2. 左上の検索（またはメニュー）から 「ポリシー」（Azure Policy）を開きます。
3. 左側メニューの 「作成（Authoring）」 を開き、「割り当て（Assignments）」 を選びます。
4. 一覧から、名前に Allowed locations または 許可されている場所 / ロケーション / 場所 が含まれる割り当てを探してクリックします。
5. 割り当ての詳細画面で 「パラメーター（Parameters）」 を確認します。
6. listOfAllowedLocations（または「許可されている場所」）の値として、利用可能なリージョン（location code）の一覧が表示されます。

ポータルの項目名が分かりづらい場合は、次の対応表が参考になります。

日本語UI	英語UI	見る目的
ポリシー	Policy	ポリシー管理画面に入る
作成	Authoring	割り当てや定義を確認する
割り当て	Assignments	サブスクリプションに適用されているルール一覧
パラメーター	Parameters	許可リージョン（Allowed locations）の中身
スコープ	Scope	どの範囲（サブスクリプション等）に適用されているか

「Allowed locations」が見つからない・候補が多すぎるときの探し方

割り当てが大量に出る環境や、名称が少し違う環境もあります。次の観点で絞り込むと見つけやすくなります。

• スコープが自分のサブスクリプションになっているか（管理グループ配下の割り当ても混ざることがあります）。
• 「Allowed locations」単体ではなく、イニシアチブ（Initiative）としてまとめられている場合があります。その場合もパラメーターに許可リージョンが入っていることがあります。
• 名前に「推奨」「学生」「Education」「限定」などが含まれることもあります。

よくある状態	見え方	対処
イニシアチブ配下で制限	Allowed locations が単体で出ない	割り当ての種類や詳細を開き、Parametersを探す
名称がカスタム	Allowed locations という名前ではない	「場所/ロケーション/Location」系の文言で当たりを付ける
複数の割り当てが存在	似た名前が複数出る	スコープとパラメーターを見比べ、実際に listOfAllowedLocations があるものを特定

ポータルで許可リージョン一覧が確認しづらい場合の代替手段

ポリシー画面で一覧が見えない、あるいは「どの値が許可リージョンか分からない」場合は、次の方法も有効です。

デプロイ失敗画面の「詳細（Raw error）」から許可リージョン情報を拾う

ARMテンプレートやポータル作成で失敗したとき、エラー詳細にポリシー違反の情報がJSONで含まれることがあります。環境によっては、その中に許可リージョンが見える場合があります。

{
  "error": {
    "code": "RequestDisallowedByAzurePolicy",
    "message": "Resource 'xxx' was disallowed by policy.",
    "details": [
      {
        "policyDefinitionDisplayName": "Allowed locations",
        "policyAssignmentDisplayName": "Allowed locations",
        "parameters": {
          "listOfAllowedLocations": {
            "value": ["norwayeast", "polandcentral"]
          }
        }
      }
    ]
  }
}

ポイントは、policyDefinitionDisplayName や policyAssignmentDisplayName に Allowed locations（許可されている場所）が出ているか、そして parameters の中に listOfAllowedLocations があるかです。

Azure CLIで「Allowed locations」の許可リージョン一覧を取得する

CLIが使える場合、ポリシー割り当てから許可リージョンをテキストで抜き出せます。以下は、listOfAllowedLocations を持つ割り当てを対象に、許可リージョンだけを出力する例です。

az policy assignment list \
  --subscription <YourSubscriptionId> \
  --query "[?parameters.listOfAllowedLocations.value!=null].parameters.listOfAllowedLocations.value[]" \
  -o tsv

• <YourSubscriptionId> は自分のサブスクリプションIDに置き換えます。
• 出力される norwayeast のような値（location code）が、そのサブスクリプションで選べる候補になります。

割り当てが複数あって混乱する場合は、まず「どの割り当てが許可リージョンを持っているか」を見える化すると分かりやすいです。

az policy assignment list \
  --subscription <YourSubscriptionId> \
  --query "[?parameters.listOfAllowedLocations.value!=null].{name:name, displayName:displayName, allowed:parameters.listOfAllowedLocations.value}" \
  -o table

「使えるリージョン一覧」を整理する考え方（全リージョンとの違い）

質問でよくあるのが「使えるリージョン一覧を取得したい」というものですが、ここには2種類あります。

一覧の種類	何が分かるか	コマンド例	注意点
Azureが提供する全リージョン	一般的に存在するlocation一覧	az account list-locations -o table	学生サブスクリプションで「使える」とは限らない
自分のサブスクリプションで許可されたリージョン	Allowed locationsポリシーで許可されている場所	az policy assignment list ...	これが「実際にデプロイに使える候補」

実務的には、Allowed locationsで許可された一覧を正として扱うのが安全です。

「リージョン名」の落とし穴：表示名とlocation codeの違い

もう一つハマりやすいのが、同じリージョンでも表記が複数ある点です。ポータルでは「East US」のような表示名、テンプレートやCLIでは eastus のようなlocation codeを使います。

見える場所	例	使う場面
ポータルの表示名	East US / West Europe	GUIでリージョンを選ぶ
location code（内部名）	eastus / westeurope	ARMテンプレート、Bicep、CLI、PowerShell

Allowed locations のパラメーターに出てくるのは、基本的に location code です。テンプレート側も同じ表記に揃える必要があります。

ARMテンプレート / Bicepで「許可リージョン外」を防ぐ実装例

授業や演習でテンプレートを使い回す場合、locationの指定を固定していると、別サブスクリプションでは即死します。そこで、locationをパラメーター化し、さらに（分かっている範囲で）候補を絞るのが有効です。

Bicepの例（locationをパラメーター化）

下記は考え方のサンプルです。Allowed locations で許可された値に合わせて、@allowed の中身はあなたの環境に合わせて更新してください。

@description('デプロイ先リージョン（Allowed locations に含まれるものを指定）')
@allowed([
  'norwayeast'
  'polandcentral'
  'spaincentral'
  'switzerlandnorth'
])
param location string

@description('ストレージアカウント名（英小文字と数字のみ、3-24文字）')
param storageAccountName string

resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Allowed locations の値がまだ確定していない場合は、@allowed を使わず「まずは通す」ことを優先し、運用で“許可リスト内しか使わない”ルールにするのも現実的です。

テンプレートでlocationを固定してはいけないパターン

テンプレートの書き方	何が起きるか	改善案
location: 'eastus' のように固定	eastus が許可されていないサブスクリプションでは必ず失敗	location をパラメーターにして、環境ごとに選べるようにする
リソースグループのlocationに合わせずバラバラ	ポリシーだけでなく運用上も管理が難しくなる	基本は resourceGroup().location を採用しつつ、ポリシーに合わせてRGを作る

それでも失敗するときに見るチェックポイント

Allowed locations を確認してもなお失敗する場合、原因が「リージョン」以外にあることもあります。以下のチェックリストで切り分けると早いです。

チェック項目	よくあるミス	確認方法	対処
指定したlocationが許可リストにあるか	表示名（East US）をテンプレートに書いてしまう	Allowed locationsの値と完全一致しているか	テンプレート/CLIは location code（例：eastus）で統一
別のポリシーにも引っかかっていないか	場所以外の制限（SKU、種類、タグ必須など）	Raw error の policyDefinitionDisplayName を確認	該当ポリシーに合わせてテンプレートを修正
リソースの種類が“リージョン対応”か	サービス自体がそのリージョンに未対応	エラー詳細で「サービス利用不可」系がないか	許可リージョンの中で対応しているリージョンに切り替える
複数リソースでlocationが混在していないか	テンプレート内で一部だけ別リージョン	テンプレート内の location を検索	locationパラメーターに一本化
サブスクリプションを取り違えていないか	別のサブスクリプションにデプロイしている	ポータル上部やCLIの current subscription を確認	正しいサブスクリプションに切り替える

実務的なおすすめ運用（学生環境でハマらないための型）

演習・学習では「とりあえず作って動かす」が優先になりがちですが、学生サブスクリプション特有の制限がある以上、最初に“型”を作っておくと後が楽です。

タイミング	やること	狙い
初回（環境を触り始める日）	Allowed locations を確認してメモする	無駄な試行錯誤をゼロにする
リソースグループ作成時	許可リージョンのいずれかでRGを作る	以降のデプロイの基準点を揃える
テンプレート化するとき	locationは必ずパラメーター化	環境差分を吸収する
エラーが出たとき	Raw error を先に見る	原因（ポリシー名）を最短で特定する

どうしても別リージョンを使いたい場合の現実的な選択肢

Allowed locations が厳しく、演習内容によっては「そのリージョンだとサービスが使えない」「先生の指定リージョンが選べない」ということも起こります。その場合は、次のいずれかを検討することになります。

• 通常の有料サブスクリプション（従量課金）を用意して、リージョン制限のない環境で実行する（ただし課金に注意）。
• 授業・組織側で提供している別の学習用サブスクリプション（ラボ環境など）がないか確認する。
• 制限は自分で外せないため、必要であれば管理者・サポート窓口に相談する（ただし学生向け環境では変更不可の場合もあります）。

いずれにしても、まずは「自分のサブスクリプションで許可されているリージョン」を把握するのがスタート地点です。

よくある質問

Azure for Studentsだと、どのリージョンが使えますか？

サブスクリプションごとに異なるため、一般論として「このリージョンなら必ず使える」と断言できません。Azure Policy の Allowed locations（許可されている場所） に並んでいる location code が、そのサブスクリプションの“使えるリージョン”です。

Allowed locations（許可されている場所）ポリシーの制限内容はどこで確認できますか？

Azure ポータルの ポリシー → 割り当て → Allowed locations（またはそれに相当する割り当て） を開き、Parameters の listOfAllowedLocations を確認します。

使えるリージョン一覧を取得する方法は？

一番正確なのはポリシー割り当てから取得する方法です。CLIが使えるなら、az policy assignment list で listOfAllowedLocations を抽出するのが簡単です。Azure全体のリージョン一覧（az account list-locations）は“存在するリージョン”であって“許可されているリージョン”ではない点に注意してください。

まとめ：解決の要点

• Azure for Studentsでリージョンが通らないときは、Azure Policy（Allowed locations）が原因になっていることが多いです。
• 許可されるリージョンはサブスクリプションごとに異なるため、他人の例をそのまま当てにしないのが安全です。
• ポータル（Policy AssignmentsのParameters）またはAzure CLI（az policy assignment list）で許可リージョン一覧を確認し、その中から location を選べば解決に近づきます。