Azure Migrate でオンプレミス VM の「テスト移行」を実行した際に表示される 「Not enough resource available（リソース不足）」。これは多くの場合、指定リージョンやゾーンで希望の VM サイズ（SKU）を一時的に割り当てられないことが原因です。本記事は、現場で即使える原因の見極め方と最短で通すための手順を、コマンド例・チェックリスト・表を交えて体系的にまとめました。
この記事で得られること
- 「Not enough resource available」エラーの正体（割り当て失敗のメカニズム）
- 最短で通す優先順位付きの解決手順（サイズ変更・リージョン変更・再試行・クォータ増）
- Azure Migrate 画面での具体操作と、CLI/PowerShell による事前確認
- 計画段階で詰まらないための設計チェックリストと代替サイズマトリクス
- エラー文言別の対処早見表、FAQ、実例
エラーの正体：Azure の割り当て（Allocation）とキャパシティ
Azure の仮想マシンは、「SKU（サイズ）」「リージョン／ゾーン」「ディスク種別」「機能（Trusted Launch、GPU、PPG 等）」など複数条件を満たした空きリソースに配置されます。テスト移行時は、これら条件に適合する空きスロットを探して割り当て（Allocation）しますが、いずれかが満たせないと割り当てに失敗し、典型的に本エラーが返ります。
クォータ（上限）と実キャパシティは別物
- クォータ：サブスクリプションに許可された vCPU 上限（シリーズ別）。上限に達すると「上限不足」で失敗。
- 実キャパシティ：その瞬間に対象リージョン／ゾーンで割り当て可能な物理余力。上限内でも空きがないと「リソース不足」で失敗。
両者は独立なので、上限を増やしても直ちに空きが出るとは限りません。逆に、上限内でもタイミングや条件次第で失敗します。
よくある不足要因と症状
| 要因 | 典型症状 | 主な対処 |
|---|---|---|
| 人気サイズの一時枯渇（例：Dsv5/Esv5） | 特定サイズ指定のみ失敗 | 同系列の別サイズや他シリーズへ切替 |
| ゾーン指定が厳しすぎる（PPG/可用性要件） | ゾーン A は失敗、ゾーン B なら通る | ゾーン/PPG 条件緩和または別ゾーン |
| ディスク機能の制約（Ultra、Premium SSD v2） | 同サイズでも特定ディスク種で失敗 | ディスク種変更、対応ゾーンへ配置 |
| GPU 系（N 系）のキャパシティ稀少 | GPU SKU のみ継続的に失敗 | 別リージョン／サイズ変更＋事前確保 |
| Spot/低優先 VM | テストは成功しても本番で失敗 | 通常優先へ切替、上限リトライを許容 |
| Trusted Launch、暗号化、Gen2 必須など | 機能有効時のみ失敗 | 要件緩和または対応ホストへ条件変更 |
いますぐ試せる解決策（優先順）
ターゲット VM サイズ（SKU）を変更する
最も成功率が高いのはサイズの即時切替です。Azure Migrate の評価または移行設定画面で、同系列または近縁系列へ変えて再実行します。
| 元サイズ | 第一候補 | 第二候補 | ねらい |
|---|---|---|---|
| Dsv5 系 | 同系の上下サイズ（例：D8s v5 → D16s v5 / D4s v5） | Esv5 系（メモリ多め） | 近いコア/メモリで空きを狙う |
| Esv5 系 | 同系上下サイズ | Dsv5 系 or Dasv5（AMD 系） | メモリ要件が許せば D 系へ |
| Fsv2 系（高周波数） | 同系上下サイズ | Dsv5 系 | CPU 性能要件に注意 |
| N 系（GPU） | 同系別サイズ（vCPU/GPU 数違い） | 別リージョンの N 系 | GPU はリージョン移動も検討 |
ポイント：評価レポートの「推奨サイズ」と「可用性状態」を必ず参照し、複数候補を事前に用意しておくと切替が迅速です。
別リージョンを選択する
特定リージョンの逼迫が疑われる場合、隣接リージョン（例：東日本 → 西日本）の同等サイズでテスト移行を実施します。ネットワーク遅延・コスト・ガバナンスを勘案しつつ、まずテスト移行で割り当て可否を見極めるのが効率的です。
時間を空けて再試行する
キャパシティは動的に変動します。緊急でなければ数時間〜翌日の再試行で通るケースも少なくありません。自動化できる場合は、リトライをスケジュール化し、成功した時点で通知する運用が有効です。
リージョン単位のクォータ（上限）を引き上げる
継続的にそのシリーズを使う見込みがあるなら、対象リージョンの vCPU 上限増加を申請します。承認後は当該シリーズを割り当て可能にするための前提が整います（＝ただし、即キャパシティ確保とは限らない）。
- Azure Portal で「サポート + トラブルシューティング > 新しいサポート リクエスト > クォータの増加」を開く
- 対象サブスクリプション／リージョン／シリーズ（例：Dsv5）と希望 vCPU 値を指定
- 承認後、再度テスト移行やサイズ変更で割り当てを確認
申請前に「サブスクリプション > 使用量 + クォータ」で現状の使用量と上限を把握しておくとスムーズです。
容量確認ツールの活用（補足）
CLI/PowerShell で事前に「利用可否」や「上限」を機械的に確認できます。
Azure CLI（SKU/可用性の下見）
# 指定リージョンで利用可能な VM サイズ（部分一致）を一覧表示
az vm list-skus --location japaneast --size Standard_D* --output table
# 制限付き SKU を抽出（利用不可の理由やスコープを確認）
az vm list-skus --location japaneast --all --output json
| jq '.[] | select(.restrictions != null) | {name: .name, restrictions: .restrictions}' Azure CLI（使用量/上限の確認）
# コンピュート使用量と上限（リージョン別）
az vm list-usage --location japaneast --output table
PowerShell（使用量/制限の確認）
# 事前に Az モジュールをインストールしてログイン
# Install-Module Az -Scope CurrentUser
# Connect-AzAccount
# 使用量（リージョン別）
Get-AzVMUsage -Location "Japan East" | Sort-Object Name | Format-Table
# SKU 制限（NotAvailableForSubscription など）
Get-AzComputeResourceSku -Location "Japan East" ` | Where-Object { $_.ResourceType -eq "virtualMachines" -and $_.Restrictions }`
| Select-Object Name,Locations,Restrictions Azure Migrate での具体操作（テスト移行を「通す」実務手順）
サイズ切替の手順（評価から）
- 「Azure Migrate > サーバーの評価」で対象マシンの評価結果を開く
- 「推奨サイズ」を確認し、同系列の上下サイズまたは代替シリーズをメモ
- 「移行」プロジェクトで「テスト移行」実行前にターゲットサイズを指定し直す
- 失敗したら次候補へ切り替え、3 回程度リトライ（別ゾーン/別リージョンも検討）
ゾーン/配置の見直し
- 可用性ゾーン固定が原因の場合、ゾーン未指定（ゾーンレス）で試験的に配備して可否を確認
- Proximity Placement Group（PPG）利用時は、PPG の縛りが強く枯渇しやすい。PPG を一旦外すか構成を分割
- 可用性セットはフォールト/アップグレードドメインの観点で配置制約が増える場合があるため、一時的に外して検証
ディスク/機能の見直し
- Ultra Disk／Premium SSD v2 はゾーン/リージョン対応が限定されることがあるため、まずは Standard/Premium SSD v1 で通す
- Trusted Launch、vTPM、Encryption at host などの機能有効化が割り当て先を狭めることがある。テストで無効化し、通ったら本番で再評価
- Ephemeral OS Disk は一部サイズでのみ利用可能。失敗時は一旦マネージド OS ディスクに変更
サイズ自動フェイルオーバー（擬似コード例）
# 疑似コード：サイズ候補リストを順に試し、最初に成功したサイズでテスト移行
candidates = ["Standard_D8s_v5", "Standard_D16s_v5", "Standard_E8s_v5"]
for size in candidates:
try:
start_test_migration(target_size=size)
wait_until_completed()
if success:
notify("Test migration succeeded with " + size)
break
except AllocationFailed:
continue
実装は環境に合わせて、Azure Migrate の REST/PowerShell/CLI などで置き換えてください。
事前設計で「詰まない」ためのチェックリスト
- 候補 SKU を最低 3 つ用意（同系列上下 + 近縁系列）
- ゾーン要件は「必須/任意」を明確化。任意ならゾーンレスで初期割り当てを許容
- PPG/可用性セットは本番切替時に適用し、テスト移行では一旦外す運用も選択肢
- ディスク要件（IOPS/スループット/レイテンシ）と対応ゾーンを設計段階でマッピング
- シリーズ別 vCPU クォータを事前申請（D/E/N 系は特に早め）
- GPU/高性能 I/O（Ultra）のワークロードはリージョン冗長候補を設ける
- 移行ウィンドウが短い場合はサイズ自動切替スクリプトを準備
代替サイズマトリクス（例）
| ワークロード | 第一候補 | 第二候補 | 第三候補 | 注意点 |
|---|---|---|---|---|
| 汎用アプリ | Dsv5 | Esv5 | Dasv5（AMD） | メモリ/コア比と価格のバランス |
| メモリ多用 | Esv5 | Edsv5（ローカル SSD） | Dsv5 | ページファイル/キャッシュの配置 |
| 高周波数 CPU | Fsv2 | Dsv5 | Dasv5 | 単一スレッド性能要件に注意 |
| GPU 推論/学習 | N 系（vGPU/単体 GPU） | 別リージョンの N 系 | ND/NC 系の混在 | ドライバ/イメージ整合性 |
| 高 I/O | Premium SSD v2 | Premium SSD | Standard SSD | ゾーン/SKU の対応範囲 |
ケーススタディ：サイズ変更で即解消
実際の解決例：テスト移行時に「Not enough resource available」エラーが発生。対象は Dsv5 系の中サイズ。評価レポートで「可用性が高い」と表示されていた代替候補に切り替え（同系列の上位サイズ）、直ちにテスト移行が成功しました。性能とコストを比較したうえで、のちに Esv5 の下位サイズに最適化するフローで落ち着いています。
別例：ゾーン縛りが原因
ゾーン A に固定していたため失敗。ゾーン未指定でテスト移行すると成功。最終的にはゾーン B を本番配置に選び、要件を満たしつつ割り当て失敗を回避しました。
別例：Ultra Disk の可用性
Ultra Disk を前提にしていたため、対応ゾーンが限定されて失敗。Premium SSD v2 に切り替えてテスト移行を通し、最終的に本番で Ultra Disk 対応ゾーンにスイッチしました。
エラー文言別トラブルシュート早見表
| エラーの断片 | 想定原因 | 対処の第一手 | 次の一手 |
|---|---|---|---|
| Not enough resource available | 実キャパシティ不足 | サイズ変更（同系列/近縁系列） | 別リージョン／再試行／ゾーン未指定 |
| Allocation failed | ゾーン/PPG/機能で割当先が狭い | ゾーン/PPG/機能を一時緩和 | サイズ再選定／別リージョン |
| QuotaExceeded | シリーズ別 vCPU 上限 | クォータ増加申請 | 別シリーズで代替／サイズ縮小 |
| Requested operation is not supported in the specified region | SKU/機能がリージョン未対応 | 対応リージョンへ変更 | 機能要件の見直し |
FAQ（よくある質問）
クォータを増やしたのに「リソース不足」で失敗します
クォータは「許可枠」であり、物理的な空き（実キャパシティ）とは別です。サイズ変更・ゾーン/リージョン変更・時間を置くの 3 点で回避を図りつつ、本番期日までに代替案を確実に用意してください。
ゾーン指定は必須ですか？
強い可用性要件がなければ、テスト移行はゾーン未指定で通し、本番切替時にゾーンを確定する運用が実務的です。ゾーン固定は枯渇の影響を強く受けます。
Reserved Instances / Savings Plan は関係しますか？
コスト割引の仕組みであり割り当て可否には直接影響しません。ただし最終サイズが確定している場合、コスト最適化の観点で検討価値があります。
Spot VM でのテストは意味がありますか？
Spot は価格/可用性が変動し、割り当て失敗も起こりやすいです。テスト移行は通常優先で実施することを推奨します。
Trusted Launch や vTPM を有効化すると失敗します
該当機能に対応するホストが限定されるため、割り当て先が狭まります。テストでは一時的に無効化し、通ったのちに本番で再評価するのが現実解です。
Ephemeral OS Disk が原因になることは？
はい。サポートされるサイズ/ストレージが限られるため、エフェメラル条件で割り当てできない場合があります。まずはマネージド OS ディスクで通し、要件が満たせると判断できてからエフェメラルに切替えます。
現場で役立つ運用 Tips
- テスト移行の段階で「候補サイズの順番」を決めておく（例：D8s v5 → D16s v5 → E8s v5）
- VM 作成をパラメータ化し、サイズだけ差し替えて即リトライできるようにする
- 移行ウィンドウ直前はキャパシティ変動が大きい時間帯を避ける（業務時間外の大規模展開が重なる傾向）
- ディスクは最初は保守的に（Premium/Standard）で通し、本番で最適化する
- GPU/Ultra/PPG は最初から代替リージョンを設計に含める
コマンド・スクリプト集（コピーして使える）
サイズ候補の可用性をざっと確認（Azure CLI）
# Dsv5 系の可用性をリージョン別に確認（例：Japan East）
az vm list-skus --location japaneast --size Standard_D*s_v5 --output table
# Esv5 系も確認
az vm list-skus --location japaneast --size Standard_E*s_v5 --output table 使用量と上限（クォータ）を確認（Azure CLI）
# Compute の使用量/上限（Japan East）
az vm list-usage --location japaneast --output table
PowerShell での同等確認
# 使用量（上限に近い項目を把握）
Get-AzVMUsage -Location "Japan East" | Sort-Object Name | Format-Table
# 制限のある SKU を抽出
Get-AzComputeResourceSku -Location "Japan East" ` | Where-Object { $_.ResourceType -eq "virtualMachines" -and $_.Restrictions }`
| Select-Object Name,Locations,Restrictions サイズ自動切替の雛形（PowerShell 擬似）
$candidates = @("Standard_D8s_v5","Standard_D16s_v5","Standard_E8s_v5")
foreach ($s in $candidates) {
try {
# Invoke-AzMigrateTestMigration -TargetSize $s ... （概念例）
# 完了待ちのロジックを挿入
Write-Host "Succeeded with $s"; break
} catch {
Write-Warning "Allocation failed with $s. Trying next..."
}
}
まとめ（要点の再確認）
- 本エラーの根本はリージョン/ゾーンの実キャパシティ不足。環境設定を変えれば大半は解消します。
- 最短策は「サイズ変更」または「リージョン変更」。それでも不可なら「時間を空ける」か「クォータ増加申請」。
- 計画段階で利用可能サイズの確認と複数候補の準備を行い、代替案を運用に組み込むと移行が滞りません。
- ゾーン/PPG/ディスク/機能の条件は割り当て先を狭めるため、テスト移行では緩め、本番で締めるのが現実的です。
実際の解決例：質問者は VM サイズをより利用可能な SKU に変更したところ、直ちに移行テストが成功。
コメント