Azureで仮想マシン（VM）を作成しようとしたら「capacity」「AllocationFailed」などのエラーで止まることがあります。多くの場合、指定したリージョン／ゾーンにそのVMサイズ（SKU）の空きがない状態です。本記事では原因の切り分けから、すぐ試せる回避策、本番での再発防止まで実務目線でまとめます。
Azure VM の「capacity エラー（キャパシティ不足）」とは
Azure で VM を作成・再デプロイ・スケールアウトするときに、「今その場所に、指定した VM サイズ（SKU）を置ける空きがない」ために失敗することがあります。ポータルでは「Critical error」「Azure VM capacity」などと見える場合もありますが、要するに リージョン／可用性ゾーンごとに用意されている計算資源プールが満杯という状態です。
キャパシティはリージョン単位だけでなく、ゾーン（Zone 1/2/3）やハードウェア世代ごとに分かれています。そのため、ゾーン変更や SKU 変更だけで解決するケースが多いのが特徴です。
よくあるエラー表示例と意味
| 表示例 | 代表的なエラーコード（例） | 意味 | よくある状況 |
|---|---|---|---|
| We do not have sufficient capacity… | AllocationFailed | 指定条件のままでは割り当て先が見つからない | 人気リージョン、スケールアウト、特定 SKU 固定 |
| The requested size is currently not available… | SkuNotAvailable | そのリージョン／ゾーンで該当 SKU が不足、または提供対象外 | GPU/大容量系、リージョン限定 SKU |
| Zonal allocation failed | ZonalAllocationFailed | ゾーン固定が原因で配置できない | 単一ゾーン固定、ゾーン固定リソース併用 |
| Overconstrained allocation request | OverconstrainedAllocationRequest | 制約の組み合わせが厳しすぎて置けない | 近接配置、専用ホスト、Ultra Disk など |
枯渇しやすい VM の傾向
- GPU 搭載 VM（ホスト台数が限られ需要が集中）
- 汎用の D 系・メモリ最適化の E 系（利用者が多い）
- 大きいサイズ（1台あたりの占有が大きい）
- ゾーン固定・近接配置など制約が多い（置ける場所が狭まる）
最初に切り分けたい：クォータ超過との違い
VM 作成失敗は「キャパシティ不足」だけでなく、vCPU クォータ（上限）でも起きます。クォータはサブスクリプション側の制限、キャパシティは Azure 側の空き状況です。ここを誤判定すると「ゾーンを変えても直らない」「サポートに出したのにたらい回し」になりがちなので、最初に確認します。
| 項目 | キャパシティ不足 | クォータ超過 |
|---|---|---|
| 足りないもの | Azure 側の空き（その場所/その SKU の台数） | サブスクリプション側の上限（vCPU など） |
| エラーの雰囲気 | capacity / allocation failed | quota / core limit / exceed |
| 主な対処 | ゾーン変更・SKU 変更・リージョン変更 | クォータ増枠申請、不要リソース削除 |
CLI でリージョンごとの使用量を確認できます。
az vm list-usage -l japaneast -o table
az vm list-usage -l japanwest -o tableキャパシティ不足と勘違いしやすい失敗例
「作れない」＝キャパシティ不足とは限りません。次のような原因も、見た目は似ています。並行して潰しておくと遠回りを防げます。
| 原因 | 兆候 | 確認ポイント | 代表的な対処 |
|---|---|---|---|
| サブネットの IP 枯渇 | NIC 作成や IP 割り当てで失敗する | サブネットのアドレス範囲、使用中 IP 数 | サブネット拡張、別サブネット作成 |
| Azure Policy による拒否 | 「disallowed」「policy」などの文言 | エラー詳細、ポリシー割り当て | 例外設定、ポリシー要件に合わせる |
| リージョンで未提供の構成 | 特定機能やサイズが選べない | サイズ一覧、対応機能（ディスク/ネットワーク） | 対応 SKU へ変更、リージョン変更 |
代表的な対処方法
キャパシティ不足は「今置けない」状態です。Azure が配置先を見つけやすいように、条件を1つずつ緩めるのが基本戦略になります。
同じリージョン内で別ゾーンを試す
ゾーン指定がある場合、まずは 別ゾーンで再試行します。ゾーン 1 が満杯でもゾーン 2/3 は空いている、ということは珍しくありません。要件的に可能なら、ゾーン指定を外して「ゾーンなし」で作成するのも有効です。
| 選択肢 | メリット | 注意点 |
|---|---|---|
| 別ゾーンで作成 | 構成をほぼ変えずに成功率を上げられる | 関連リソース（PIP/ディスク等）がゾーン固定だと作り直しが必要な場合がある |
| ゾーン指定を外す | Azure 側が空きを探しやすい | ゾーン冗長が必要なら別手段で冗長化する |
| 可用性セットを使う | 更新ドメイン/障害ドメインで分散でき、配置の自由度も高い | ゾーン冗長ではない |
# 例：ゾーン 2 に作成
az vm create -g rg-example -n vm-example \
--image Ubuntu2204 --size Standard_D4s_v5 --zone 2 \
--admin-username azureuser --generate-ssh-keys別の VM サイズ（SKU）を選ぶ
キャパシティは SKU ごとに偏りが出ます。近いスペックの別 SKUに切り替えるだけで、別のハードウェアプールに割り当てられて成功することがあります。特に「v3 が枯れているが v5 は空いている」といった世代差は現場でよく起きます。
| 目的 | 例 | 代替候補の方向性 | 確認ポイント |
|---|---|---|---|
| 汎用 | Dsv3 | Dsv5 / Dasv5、必要なら F 系も検討 | CPU 世代差、NIC 帯域、ディスク性能 |
| メモリ多め | Esv3 | Esv5 / Easv5、台数分散も検討 | メモリ比率だけでなく IOPS も確認 |
| GPU | NC/ND/NV の特定 SKU 固定 | 世代違い・GPU 種別違い・リージョン違いを候補化 | GPU ファミリークォータ、ドライバ要件 |
候補を広げる目的で、リージョン内のサイズ一覧を取っておくと判断が速くなります（一覧に出ても必ず作れるわけではありません）。
az vm list-sizes -l japaneast -o table別リージョンで VM を作成する
同じ SKU でもリージョンが変わればキャパシティ状況が変わります。日本なら Japan East と Japan West を行き来するだけで解決することもあります。遅延・データ所在地・社内規定を確認しつつ、切替手順（DNS 切替など）まで含めて準備しておくと本番で詰まりにくくなります。
制約条件を緩めて「過剰拘束」を解除する
近接配置（Proximity Placement Group）、専用ホスト、Ultra Disk、エフェメラル OS ディスクなどは、配置先を狭めて失敗しやすくします。エラーが続く場合は、本当に必須の制約かを再確認し、一時的に外して作成できるか試すのが近道です。
| 制約 | 緩め方（例） | 注意点 |
|---|---|---|
| 近接配置（PPG） | PPG を外す／別ゾーンへ逃がす | レイテンシ最適化が弱まる |
| Ultra Disk | Premium SSD へ一時退避 | 性能要件を再確認する |
| エフェメラル OS ディスク | マネージドディスクへ変更 | 起動速度・コストが変わる |
リトライを仕組み化する
キャパシティ不足は一時的な場合もあるため、検証用途なら 指数バックオフで数回リトライするだけで安定します。本番で「必ず起動できる」ことが必要なら、次の章の恒久対策も併用します。
# PowerShell イメージ（概念）
$try = 0
while ($try -lt 6) {
$try++
az vm create ... 2> error.log
if ($LASTEXITCODE -eq 0) { break }
Start-Sleep -Seconds ([Math]::Pow(2, $try) * 30)
}本番で詰まらないための恒久対策
障害復旧や急な増設で困らないように、設計で「逃げ道」を作ります。ポイントは ゾーン・SKU・リージョンの固定を最小化することです。
- ゾーン：単一ゾーン固定にせず、複数ゾーンで動ける構成にする
- SKU：同等クラスを複数候補にして IaC（Bicep/Terraform 等）で切替可能にする
- リージョン：DR 先を用意し、切替手順（DNS/Front Door 等）を整備する
「その SKU じゃないと困る」「そのゾーン固定が必須」など制約が強い本番は、Azure Capacity Reservation（容量予約）や専用ホストで確保する選択肢もあります。なお、予約インスタンス（RI）は主にコスト削減で、キャパシティ確保を保証するものではありません。
| 手段 | 目的 | 覚えておくこと |
|---|---|---|
| 予約インスタンス（RI） | コスト削減 | 割引は受けられるが、作成成功を保証しない |
| 容量予約 | キャパシティ確保 | 確保が目的。未使用でも費用が発生する場合がある |
| 専用ホスト | 隔離・確保 | ホスト確保ができれば、その上で VM を柔軟に配置 |
実務で迷わないおすすめ手順
| 順番 | やること | 狙い |
|---|---|---|
| 最初 | エラーコード/メッセージ、リージョン/ゾーン、SKU、台数を控える（必要ならアクティビティログも保存） | 切り分けとサポート依頼の材料にする |
| 次 | クォータを確認（使用量 + クォータ、az vm list-usage） | 原因がクォータなら最短で潰す |
| 優先 | 同一リージョンで別ゾーンへ変更（またはゾーン指定を外す） | 最小変更で成功率を上げる |
| 続けて | 同一リージョンで SKU を変更（世代違い/ファミリー違い） | 別のハードウェアプールへ逃がす |
| 最後 | 別リージョンで作成（日本なら East/West を優先） | キャパシティ状況を丸ごと変える |
サポートに依頼するときのチェックリスト
Azure ポータルの「ヘルプ + サポート」からサポートリクエストを作成し、Compute/VM の割り当て失敗（キャパシティ）に関する相談として起票します。伝える情報が揃っているほど、調査と提案が早くなります。
- サブスクリプション、対象リージョン/ゾーン、SKU、必要台数
- 発生日時、エラー全文、Activity ID / Correlation ID（表示されている場合）
- 試した回避策（別ゾーン、別 SKU、別リージョン）と結果
- 本番/検証の別、いつまでに必要か（緊急度）
よくある質問
昨日は作れたのに今日は作れないのはなぜ？
キャパシティはリアルタイムに変動します。人気リージョンでは特に、他の利用者の作成状況や Azure 側の都合で空きが動きます。恒久的には、ゾーン/SKU/リージョンの逃げ道を用意するのが安全です。
どうしても同じゾーン・同じ SKU で作り続けたい
要件上「固定が必須」なら、容量予約や専用ホストなど「確保」を目的とした手段を検討します。そのうえで、障害時の再デプロイも含めた運用手順（予約への紐づけ、増設時の台数計画）までセットで整備すると、トラブル時に止まりにくくなります。
コメント