Azure の学習コンテンツどおりに Azure CLI を叩いたのに、VM 作成で SkuNotAvailable エラーが出て先に進めない──そんな「ハマりポイント」は、初学者だけでなく実務でも頻出するトラブルです。本記事では、実際のコマンド例（Standard_D2s_v5／eastus）を題材に、エラーの正体と具体的な対処手順、再発を防ぐためのチェック方法まで、まとめて解説します。
Azure CLI で VM 作成時に発生する SkuNotAvailable エラーとは
まずは、今回のケースの前提となるコマンドを整理します。学習コンテンツでよく出てくる典型的な例は次のようなものです。
az vm create \
--resource-group "IntroAzureRG" \
--name my-vm \
--size Standard_D2s_v5 \
--public-ip-sku Standard \
--image Ubuntu2204 \
--admin-username azureuser \
--generate-ssh-keys
このコマンド自体は文法的にもパラメーター的にも問題ありません。それにもかかわらず、デプロイ時に InvalidTemplateDeployment の内側で SkuNotAvailable が発生し、さらにエラーメッセージの末尾には The content for this response was already consumed のような見慣れない文言が出ることがあります。
ここで重要なのは、次のポイントです。
- 根本原因は「リージョン内の容量不足」による
SkuNotAvailableである The content for this response was already consumedは CLI 側の例外処理に伴う副次的なエラーであり、原因ではない- 対象リージョンは
eastus、サイズはStandard_D2s_v5である
つまり、「コマンドが間違っている」のではなく、「そのとき、そのリージョンで、その SKU を新規割り当てできなかった」だけです。クラウドらしく聞こえますが、実際にはデータセンターのリソースは有限なので、人気のあるサイズやリージョンではこうしたエラーが起こり得ます。
エラーメッセージの読み解き方
実際のエラーメッセージ（抜粋）は、概ね次のような構造になっています。
"code": "InvalidTemplateDeployment",
"message": "The template deployment 'vm_deploy_xxxxx' is not valid...",
"details": [
{
"code": "SkuNotAvailable",
"message": "The requested size for resource 'my-vm' is currently not available in location 'eastus' for subscription 'xxxx-xxxx-xxxx'. Please try another size or deploy to a different location."
}
]
ポイントは、外側の InvalidTemplateDeployment は「デプロイ全体が失敗した」ことを示すラッパーであり、本当の原因は details の中にあるということです。
| 項目 | 意味・役割 |
|---|---|
InvalidTemplateDeployment | ARM テンプレート（内部的なデプロイ定義）の実行が失敗したことを示す汎用的なエラーコード。 |
SkuNotAvailable | 指定した VM サイズ（SKU）が、そのリージョンで現在割り当て不可能であることを示す詳細エラー。 |
The content for this response was already consumed | Azure CLI の内部処理で結果を二重に読み込んでしまった際に出る副次的メッセージ。根本原因ではない。 |
この構造を理解しておくと、同種のエラーに遭遇したときでも「何を見ればよいか」が明確になります。
原因：eastus で Standard_D2s_v5 を新規割り当てできない状態
SkuNotAvailable が示している根本原因は、次のいずれか、あるいは複数の組み合わせです。
- 対象リージョン（ここでは
eastus）で、該当 SKU（Standard_D2s_v5）の空きが無い - サブスクリプションのクォータや予約の状況などにより、システム的に割り当てできない状態になっている
Azure の物理ホストには「このホストには Dv5 系を何台まで」というような内部制約があります。そのため、特定のサイズだけが一時的に枯渇することや、ゾーン単位で混み具合が異なることがよくあります。
学習環境や検証環境でありがちなパターンとしては、「教材が指定している人気サイズを、混雑しやすいリージョン（eastus や southeastasia など）でそのまま実行している」ケースです。この場合、教材どおりのコマンドでも再現できないことは珍しくありません。
最優先の対処：サイズ（SKU）を変更する
もっともシンプルで成功率が高いのは、VM サイズ（SKU）を変更して再実行する方法です。特に学習用途・検証用途であれば、必ずしも Standard_D2s_v5 にこだわる必要はありません。
おすすめは、低コストかつ通りやすい B シリーズです。代表的なものは次の通りです。
| SKU | 用途イメージ | 特徴 |
|---|---|---|
Standard_B1s | Linux の基礎学習、Azure CLI / ポータル操作の練習 | 最小構成に近いサイズ。料金が安く、失敗してもダメージが小さい。 |
Standard_B2s | Web サーバーの軽い検証、小規模アプリの動作確認 | B1s より少し余裕があり、ミドルウェアを複数入れても扱いやすい。 |
Standard_B2ms | メモリを少し多めに使う検証環境 | メモリが比較的多い。DB を動かす軽い検証などに向く。 |
今回のコマンドを B シリーズに書き換える例は以下の通りです。
az vm create \
--resource-group "IntroAzureRG" \
--name my-vm \
--size Standard_B1s \
--public-ip-sku Standard \
--image Ubuntu2204 \
--admin-username azureuser \
--generate-ssh-keys
学習コンテンツに「Standard_D2s_v5 を使う」と書かれていても、ハンズオンの目的が「VM 操作の流れを理解すること」であれば、サイズを変更しても学習効果は変わりません。むしろ B シリーズを選んでおくことで、コストを抑えながら失敗確率も減らせます。
サイズ選定のちょっとしたコツ
どのサイズを選ぶべきか迷ったときは、次のように考えると決めやすくなります。
- Linux の基礎操作や CLI の練習 →
Standard_B1s - Web サーバーやアプリを軽く触ってみたい →
Standard_B2s - DB やメモリを使うコンポーネントを試したい →
Standard_B2ms以上
実務では性能要件やコスト要件に応じてサイズ選定を行いますが、学習段階では「とりあえず起動する・触れること」を優先する方が得られる経験値は大きいです。
同じサイズを使いたいときの対処：リージョンを変更する
一方で、「教材の説明どおり Standard_D2s_v5 で試したい」「既存システムと同じサイズで検証したい」といった事情で、どうしても SKU を変えたくない場合もあるでしょう。その場合は、リージョンを変更するという選択肢があります。
Azure では、リソース グループの場所と VM の場所は一致している必要はありません。たとえば、リソース グループを eastus に作成していても、その中に eastus2 や westus の VM を含めることが可能です。
同じ SKU を別リージョンで試す例は次の通りです。
az vm create \
--resource-group "IntroAzureRG" \
--name my-vm \
--location eastus2 \
--size Standard_D2s_v5 \
--public-ip-sku Standard \
--image Ubuntu2204 \
--admin-username azureuser \
--generate-ssh-keys
ここで重要なのは、--location を明示的に指定している点です。これにより、IntroAzureRG が eastus にあっても、VM 自体は eastus2 に配置されます。
| 対処方法 | メリット | デメリット・注意点 |
|---|---|---|
| サイズ変更（B シリーズなど） | もっとも成功しやすく、学習用には十分な性能。コストも安い。 | 教材の画面例とサイズ名が変わることがある。 |
| リージョン変更（eastus2 など） | 同じサイズを維持できるため、検証結果を本番構成に近づけられる。 | リージョンが増えると、ネットワークやストレージ構成が複雑になる場合がある。 |
シンプルな学習環境であれば、まずは「サイズ変更」、どうしても同じサイズを使いたい場合には「リージョン変更」という優先度で検討するのが現実的です。
可用性ゾーン（Availability Zone）を明示してみる
リージョンによっては、可用性ゾーンごとに混み具合が異なる場合があります。そのため、ゾーンを明示すると通るケースもあります。
eastus にゾーンが存在する前提で、--zones を付与した例は次の通りです。
az vm create \
--resource-group "IntroAzureRG" \
--name my-vm \
--location eastus \
--zones 2 \
--size Standard_D2s_v5 \
--public-ip-sku Standard \
--image Ubuntu2204 \
--admin-username azureuser \
--generate-ssh-keys
ただし、次の点には注意が必要です。
- ゾーン全体が逼迫している場合は、ゾーンを指定しても失敗する
- 既存のネットワーク設計（ゾーン冗長 LB など）と整合するゾーン選択が必要な場合がある
- 学習環境では「ゾーンの仕組み」を学ぶ目的がない限り、無理に使う必要はない
実務でゾーン冗長構成をとる場合には重要なパラメーターですが、単なるハンズオンであれば「サイズ変更」や「リージョン変更」で解決する方がシンプルです。
事前確認に使える Azure CLI コマンド
同じエラーを繰り返さないためには、「作成前に、そのリージョンで利用可能な SKU を確認する」ことが有効です。よく使うのは次の 3 コマンドです。
リージョンごとの利用可能な VM SKU 一覧を確認する
# eastus で利用可能な Standard_D 系 SKU を一覧表示
az vm list-skus \
--location eastus \
--size Standard_D \
--all \
--output table
このコマンドにより、eastus で利用可能な D 系 VM サイズを一覧できます。--size を Standard_B に変えれば B シリーズの可用性も確認できます。
単一 SKU の可用性をピンポイントで確認する
az vm list-skus \
--location eastus \
--size Standard_D2s_v5 \
--output table
これは「この SKU はそもそもこのリージョンで提供されているのか」「提供されているが一時的な容量不足なのか」を切り分けるのに役立ちます。もし一覧に出てこない場合は、そのリージョンではそもそも提供されていない SKUである可能性が高く、リージョン変更が必要です。
vCPU クォータや使用状況を確認する
似たようなエラーでよくあるのが、「容量不足ではなくクォータ不足（上限超過）」が原因となるケースです。その場合は SkuNotAvailable ではなく、別のメッセージで「クォータ上限に達しています」といった内容が出ることが多いですが、念のため次のコマンドでサブスクリプションの使用状況を確認しておくと安心です。
az vm list-usage \
--location eastus \
--output table
ここで、vCPU の使用数と制限値（Limit）がほぼ同じになっている場合は、本当にクォータが足りない可能性があります。その場合は、不要な VM を削除するか、Azure ポータルからサポートリクエストを作成してクォータ引き上げを申請します。
「容量不足」と「クォータ不足」を見分けるポイント
どちらも「新しく VM が作れない」という現象こそ同じですが、対処方法は大きく異なります。整理すると次のようになります。
| 種類 | 典型的なエラーコード | 主な原因 | 主な対処 |
|---|---|---|---|
| 容量不足（Capacity Constraint） | SkuNotAvailable など | リージョン／ゾーン内の物理リソースが一時的に枯渇。 | サイズ変更、リージョン変更、ゾーン指定で回避。 |
| クォータ不足（上限超過） | OperationNotAllowed など | サブスクリプションの vCPU クォータを超えている。 | 不要 VM 削除、クォータ引き上げ申請。 |
今回のパターンでは、メッセージに明示的に SkuNotAvailable と出ており、「別サイズに変えたら作成できた」という結果も含めて考えると、容量不足タイプであることが分かります。
学習・検証環境でのおすすめ構成と実践的 Tips
せっかくなので、今回のようなハンズオンや検証環境を組む際に意識しておくと、トラブルを避けやすくなるポイントも整理しておきます。
1. リージョンを「人気リージョン一択」にしない
教材やドキュメントでは、よく eastus や westus などが例として登場します。しかし、これらのリージョンは世界中から利用されるため、時間帯やタイミングによってはリソースが逼迫していることがあります。
学習用途であれば、eastus2 や、居住地域に近い他のリージョンも候補に入れておくと、容量不足にぶつかる可能性を減らせます。
2. 手始めは B シリーズで作ってみる
最初から D シリーズや E シリーズのような「やや大きめのサイズ」を指定すると、料金も高くなるうえ、容量不足の影響も受けやすくなります。まずは B シリーズの小さめサイズで作成に成功することを確認し、その後必要に応じてサイズアップする方が安全です。
3. 失敗したコマンドはすぐに見直せるように残しておく
Azure CLI を使っていると、「ちょっとオプションを変えて再実行」という操作を何度も行うことになります。ターミナルの履歴機能に頼るだけでなく、az vm create のコマンドをテキストファイルやスクリプトとして保存しておくと、エラーが出てから見直すのが非常に楽になります。
4. エラーが出たら「一度ログをじっくり読む」習慣をつける
つい「よくわからないけど失敗した」と流してしまいがちですが、エラーメッセージの中には必ずと言ってよいほどヒントが含まれています。特に Azure の場合、details の中に有用な情報が隠れていることが多いので、JSON 形式をよく読み解く練習も兼ねて、一度ゆっくり眺めてみると理解が深まります。
実際のトラブルシューティング手順（チェックリスト形式）
最後に、今回のケースのように az vm create でエラーになったときに取るべきステップを、チェックリスト形式でまとめておきます。
| ステップ | 内容 | 目的 |
|---|---|---|
| 1 | エラーメッセージ内の code と details を確認 | SkuNotAvailable なのか、クォータ関連なのかを切り分ける。 |
| 2 | az vm list-skus --location <region> --size <sku> を実行 | そのリージョンでその SKU が提供されているかを確認する。 |
| 3 | az vm list-usage --location <region> を実行 | クォータ上限に達していないかを確認する。 |
| 4 | B シリーズなど、別サイズで再実行 | 容量不足が一時的なものである場合はこれで解消することが多い。 |
| 5 | --location を eastus2 などに変更して再実行 | 同じ SKU を別リージョンで試す。 |
| 6 | それでもダメなら Azure サポートに問い合わせ | 内部要因の可能性も含めて確認してもらう。 |
一度この流れでトラブルシュートしておくと、別のエラーに遭遇したときにも応用が利くようになります。
今回のケースの「落としどころ」
最初の質問のケースでは、最終的に VM サイズを Standard_B 系に変更することで作成に成功しています。この事実からも、「コマンドの書き方が誤っていたわけではなく、タイミング的な容量不足に当たっただけ」と解釈できます。
クラウドの世界では、オンプレミスのように「ハードウェアを買い足してから構築する」という感覚ではなく、「使えるリソースの中で柔軟にサイズや場所を変えながら環境を用意する」ことが求められます。今回の SkuNotAvailable は、その考え方に慣れるための良い教材とも言えます。
まとめ：SkuNotAvailable エラーに遭遇したら
最後に、本記事の要点を改めて整理します。
SkuNotAvailableは、指定した VM サイズ（SKU）が、その時点のそのリージョンで割り当てできないことを意味するInvalidTemplateDeploymentやThe content for this response was already consumedといったメッセージは、あくまでラッパーや副次的な情報であり、根本原因はSkuNotAvailableにある- 学習・検証用途であれば、B シリーズ（
Standard_B1s/B2sなど）に変えるのがもっとも手早く、コスト的にも安全 - 同じサイズを使いたい場合は、
--locationオプションで別リージョン（例：eastus2）を指定する - 事前に
az vm list-skusやaz vm list-usageを活用しておくと、エラーに遭遇する確率を減らせる
Azure では、同じコマンドでもタイミングやリージョンの混み具合によって結果が変わることがあります。そのたびに「なぜだろう？」と原因をたどり、今回のように解決までの筋道をストックしておくことで、インフラエンジニアとしての引き出しが少しずつ増えていきます。
今回の SkuNotAvailable も、ぜひ「Azure らしい振る舞いを理解するための一歩」として、自分のナレッジに加えておいてください。
コメント