Azure Machine Learning で GPU 仮想マシンがグレーアウトして選べない、あるいは「Standard NCASv3_T4 Family の vCPU 4」などのクォータ申請が却下されてしまう——この組み合わせは、多くの場合サブスクリプション種別とリージョン／SKU の相性に起因します。本記事は Free／Benefit／Sponsorship などの無料系サブスクリプションを前提に、なぜ起こるのか、どう回避するのかを実運用レベルで整理します。
目次
質問概要（再掲）
- Azure Machine Learning で新しいコンピュートを作成しようとすると、GPU 仮想マシン（例：NCas T4 _v3 シリーズ）がグレーアウトして選択できない。
- 「Standard NCASv3_T4 Family の vCPU 4 コア」を eastus2 リージョンで申請したが却下された。
- サブスクリプションは Free／Benefit／Sponsorship のいずれか。GPU ファミリ（NC／ND／NV など）は一切利用不可なのか？もし可能なら使えるリージョンやファミリを知りたい。
結論の要点
- 無料系サブスクリプションでは GPU クォータの増枠は原則不可。特に Free Trial／Student／Sponsorship／Visual Studio サブスク特典（Benefit）の枠では、N 系（NC／ND／NV 等）や Dv5/Ev5 の大きめ CPU ファミリの増枠が承認されないポリシーが一般的です。
- 解決の最短ルートは「有料サブスクリプション」へ切り替え→必要 GPU ファミリでクォータ再申請。Pay‑As‑You‑Go（従量課金）、Microsoft Customer Agreement（MCA）、Enterprise Agreement（EA）等に切り替えると、承認余地が一気に広がります。
- Azure ML でグレーアウトするのは、クォータ不足・SKU 未提供・ワークスペース／リージョンの不一致・ポリシー制限のいずれかが主因。UI 上の表示だけでは切り分けにくいため、「サブスクリプション → 使用量 + クォータ」で数値を確認し、「VM availability（Products by region）」で候補リージョンをあらかじめ調べるのが鉄則です。
なぜ起こる？——3つの論点で理解する
サブスクリプション種別のポリシー
無料系（Free／Benefit／Sponsorship）サブスクリプションは、リスク管理とコスト保護の観点から、GPU 系ファミリや大規模 vCPU のクォータ増枠申請が原則として承認されません。
特に Azure for Students（学生向け）は「支出上限（Spending Cap）」でクレジット消費が尽きるとリソース起動がブロックされるほか、GPU のような高コスト・高需要 SKU は 最初から対象外 になりがちです。
クォータ（Quota）と実在庫（Capacity）は別物
クォータは「利用上限の許可」で、在庫は「実際に作れるかどうか」。クォータが承認されても、タイミングやリージョンによっては在庫不足で作成に失敗します。逆に、在庫があってもクォータが無ければ UI がグレーアウトする、あるいは作成時に OperationNotAllowed / InsufficientQuota で止まります。
リージョンと SKU の相性
同じ N 系 GPU でも、リージョンごとに提供 SKU が微妙に異なり、需要逼迫で一時的に新規作成ができないこともあります。Azure ML のコンピュートはワークスペースと同一リージョンで作る必要があるため、「ワークスペースをどのリージョンに置くか」が実は作成可否に直結します。
サブスクリプション種別ごとの方針
| サブスクリプション種別 | GPU クォータ増枠 | 想定される制限 | 推奨アクション |
|---|---|---|---|
| Free Trial（無料評価版） | 原則不可 | クレジット上限・高需要 SKU 非許可 | Pay‑As‑You‑Goへアップグレード後、GPU ファミリで再申請 |
| Azure for Students（学生） | 不可 | Spending Cap により高額リソース起動不可 | 新規に PAYG サブスクリプション作成（既存の学生枠はアップグレード不可） |
| Visual Studio サブスク特典（Benefit） | 原則不可 | 開発・検証向け。GPU は対象外になりがち | 別の PAYG/MCA/EA サブスクを用意 |
| Sponsorship（スポンサーシップ） | 原則不可 | 予算・利用規約で GPU 制限 | MCA/EA などの有料枠で再構成 |
| Pay‑As‑You‑Go / MCA / EA | 可（審査あり） | 需要状況により在庫無しの可能性 | 「使用量 + クォータ」で小さく申請→段階拡張 |
解決策ロードマップ（最短で通すための手順）
- 有料サブスクリプションへ切り替え
Free／Benefit／Sponsorship をそのまま使うより、新規の Pay‑As‑You‑Go を作るのが早道です。学生枠はアップグレード不可のため、新規作成が前提です。 - ワークスペースのリージョン設計を見直す
Azure ML のコンピュートはワークスペースと同一リージョンに配置されます。GPU の在庫・SKU が厚いリージョン（例：East US / West US 2 / West Europe / Southeast Asia など）で 最初からワークスペースを作り直すと成功率が上がります。 - 「使用量 + クォータ」で GPU ファミリを小さく申請
いきなり大きく出さないのがコツ。NCASv3_T4 Family vCPU 4 など最小構成で通し、承認後に 8 → 16 → … と段階的に増やすと通りやすい傾向があります。 - Portal の「VM availability（Products by region）」で事前調査
検索バーに VM availability と入れて開くと、リージョン別に選べる GPU SKU が確認できます。候補リージョンを複数用意し、どこで作るか柔軟に切り替えましょう。 - Azure ML での作成手順を最適化
まずは Compute Cluster から着手（Instance より SKU 選択肢が広め）。作成画面で「GPU」を選び、承認済みファミリの最小 SKU を狙います。必要なら Spot（低優先度） を使い、在庫とコストの両面で可用性を高めます。
GPU ファミリと用途の早見表
| シリーズ | 代表的な SKU 例 | 主用途 | 特性・注意点 | 最初に申請する vCPU 目安 |
|---|---|---|---|---|
| NCas T4 v3 | NC4as T4 v3 / NC8as T4 v3 など | 軽〜中規模学習、推論、開発検証 | 1GPU あたりコストが抑えめ、在庫豊富なことが多い | vCPU 4（最小から開始推奨） |
| NV 系（例：NVads A10 v5） | NV A10 系 | 可視化、レンダリング、軽量推論 | グラフィックス最適化。ML でも使えるが帯域に留意 | vCPU 4〜8 |
| NC / ND（A100 等） | NC A100 v4 / ND A100 v4 等 | 大規模学習、分散学習 | 単価・需要ともに高い。クォータと在庫の両面で狭き門 | vCPU 8〜16（必要なら段階拡張） |
Azure ML でグレーアウトする典型原因と対処
| 症状・表示 | 主因 | 対処 |
|---|---|---|
| GPU ラジオボタンや SKU がグレーアウト | クォータ不足／対象ファミリ非許可 | 「使用量 + クォータ」で対象ファミリ（例：Standard_NCASv3_T4 Family）を少量で申請 |
| 作成時に OperationNotAllowed / InsufficientQuota | クォータは承認済みでも SKU の vCPU を満たさない | 必要 vCPU の読み違いに注意。NC8as T4 v3 なら vCPU 8 が目安 |
| 「SKU がこのリージョンでは未提供」エラー | リージョン未提供／一時的在庫切れ | VM availability で代替リージョンを調査し、ワークスペースも含め移す |
| 特定 SKU だけが UI に出ない | Azure Policy／RBAC／リソースプロバイダ未登録 | 所有者ロールで Microsoft.Compute 等のリソースプロバイダを登録、ポリシーを確認 |
Portal 操作の具体手順
クォータ申請（使用量 + クォータ）
- Azure Portal で サブスクリプション → 対象サブスクを選択。
- 使用量 + クォータ を開き、Compute カテゴリに切り替え。
- リージョンを eastus2 などに絞り、Standard_NCASv3_T4 Family の vCPU を 4 など最小で申請。
- 承認後、必要に応じて 8 → 16 → … と段階的に増枠。
VM availability（Products by region）での事前調査
- Portal 左上の検索に VM availability と入力。
- Products by region を開き、候補リージョン（East US／West US 2／West Europe／Southeast Asia 等）で GPU SKU の提供状況を確認。
- 該当 SKU が無い場合は、ワークスペースも含めて別リージョン移行を検討。
Azure ML ワークスペース特有の落とし穴
- 同一リージョン制約：コンピュートクラスター／インスタンスはワークスペースと同じリージョンに配置。ワークスペースのリージョン選びが最重要。
- Instance と Cluster の差：Compute Instance の方が選べる SKU が少ないケースあり。まずは Cluster で最小構成を確保し、Notebook は接続して使う運用が安定。
- ネットワーク制約：VNet 統合や Private Endpoint を有効化していると、Marketplace 取得やイメージ Pull に失敗し、UI 上はグレーアウトに見えることがあります。はじめは Public 構成で通し、後から閉域化を検討。
クォータ申請が通りやすくなる依頼文テンプレート
目的：大学の研究（画像分類）で T4 GPU を用いた軽量学習の検証を実施します。
期間：3 か月程度。夜間・休日にスポット的に利用します。
希望：eastus2 で Standard_NCASv3_T4 Family の vCPU 4 から開始し、
需要に応じて 8→16 に段階拡張予定。コスト最適化のため Spot を併用します。
補足：利用ポリシーと予算管理（アラート・タグ付け）を徹底します。
リージョン選定のコツ（在庫・距離・予算の三拍子）
| 候補リージョン | 選定理由 | 補足 |
|---|---|---|
| East US / East US 2 | 在庫層が厚いことが多い、AML 実績多数 | 需要も多い。ダメなら West US 2 / South Central US も視野に |
| West Europe / North Europe | 欧州圏ユーザーの定番。緯度も近くレイテンシ良好 | 一時期在庫が薄くなることあり。複数候補を持つ |
| Southeast Asia | アジア圏のバランス型。T4 系の入手性が比較的高い場面も | データ所在要件と時差に留意 |
RBAC／ポリシー／リソースプロバイダの前提確認
- ロール：申請者に 所有者（Owner） もしくは十分な権限があるか。サブスクのクォータ申請は管理者系ロールが必要です。
- Azure Policy：組織が Allowed virtual machine SKUs 等のポリシーで N 系を禁止していないか。
- リソースプロバイダ：「サブスクリプション → リソースプロバイダ」で Microsoft.Compute、Microsoft.MachineLearningServices が 登録済みか。
CLI／PowerShell での事前チェック（任意）
Portal が使えない環境や自動化の準備に役立ちます。
# 1) リージョンの使用状況（vCPU）を確認
az vm list-usage --location eastus2 -o table
# 2) 利用可能な SKU を洗い出し（フィルタ例）
az vm list-skus --location eastus2 --size standard_nc --all -o table
# 3) ワークスペースやリソースプロバイダの登録状況も確認
az provider list --query "[?registrationState!='Registered'].{Namespace:namespace,State:registrationState}" -o table 「却下」からのリカバリー戦略
- 申請粒度を小さく：vCPU 4 → 8 → 16 と段階化。テキストでは 期間・用途・コスト管理 を明示。
- リージョン横展開：eastus2 がダメでも East US や West US 2、West Europe 等で通ることがあります。
- ファミリの柔軟性：まずは NCas T4 v3 で最小構成を確保。大規模学習に移る際に ND/A100 系へ拡張を検討。
Azure ML でのおすすめ運用パターン
- 最初は Compute Cluster（最小ノード = 0）
アイドル時のコストを抑えつつ、需要に応じて自動スケール。SKU バリエーションも広い。 - Notebook は Compute Instance ではなく Cluster に接続
Instance の SKU 制約を回避しつつ、トレーニング／推論を同じ環境で回せます。 - Spot でコスト最適化
学習の中断に耐えられるワークロードは 低優先度（Spot） を活用。クォータはオンデマンドと共通枠の場合があるため、最初はオンデマンドを通すのが安定です。
料金・予算管理のベストプラクティス
- タグ運用：プロジェクト／費目／担当者タグでコストを可視化。
- アラート：予算アラートを早めに設定。無料枠からの移行直後は特に厳重に。
- アーキテクチャ：データ前処理や軽い推論は CPU、学習の要所だけ GPU に切り替える「バースト運用」で支出を平準化。
学術・研究・スタートアップ向けの別枠支援
もし組織の方針で有料サブスクリプションが難しい場合は、学術向け助成やスタートアップ支援プログラムなど、別枠のファンディングを検討してください。要件・審査はありますが、GPU ワークロードに適したクレジットを獲得できるケースがあります。
トラブルシューティング・チェックリスト
- サブスクリプションは PAYG/MCA/EA か？（無料系ではないか）
- 「使用量 + クォータ」で目当ての GPU ファミリの vCPU が 0 ではないか？
- ワークスペースとコンピュートの リージョン一致を確認したか？
- Portal の「VM availability」で 別リージョンの SKU を調査したか？
- ポリシー／RBAC／リソースプロバイダの前提は満たしているか？
ケーススタディ：eastus2 で NCas T4 v3 が通らない場合
よくあるのは「Standard NCASv3_T4 Family vCPU 4 を eastus2 で申請 → 却下」。この場合の再現性の高い打ち手は下記です。
- サブスクリプションの切り替え：Free／Benefit／Sponsorship → PAYG。学生枠は新規に PAYG を作成。
- リージョンの分散：East US、West US 2、West Europe、Southeast Asia を候補化。ワークスペースも新設。
- まずは vCPU 4：最小で通したら、学習の実績（ジョブ履歴、アクティビティ）を添えて 8、16 と増枠。
- Cluster 先行：Instance ではなく Cluster の最小ノード 0 で構成し、必要時だけ起動。
よくある質問（FAQ）
- Q. 無料系サブスクリプションでも、たまたま GPU が使えたという話を聞きました。
A. 旧来の例外やキャンペーン由来のケースはありますが、現在は原則として増枠不可と考えるのが安全です。新規プロジェクトは有料枠で計画しましょう。 - Q. 申請テキストに何を書けば良い？
A. 目的・期間・リージョン・最小構成・段階拡張の方針・コスト管理（予算／アラート／Spot 併用）を具体的に。上のテンプレートを参考に簡潔にまとめます。 - Q. 先に AKS（Kubernetes）で GPU ノードを立てるのはあり？
A. 有効ですが、結局は同じ GPU ファミリのクォータが必要です。まずは N 系の vCPU クォータを確保しましょう。 - Q. AML のコンピュートだけ他リージョンに置けますか？
A. 置けません。ワークスペースと同一リージョンの制約があります。はじめからリージョン設計を見直してください。
まとめ：最短ルートの再確認
無料系サブスクリプションでは GPU クォータ増枠そのものが認められないのが最大のボトルネックです。遠回りせず、有料サブスクリプション（PAYG/MCA/EA）へ切り替え、「使用量 + クォータ」から Standard_NCASv3_T4 などの GPU ファミリを 最小値で申請。VM availability で候補リージョンを用意し、Compute Cluster で最小構成から着実に拡張。これが Azure ML で GPU 環境を最短で立ち上げるための現実解です。
付録：実行前チェックのテンプレート（コピー用）
[サブスクリプション]
- 種別：PAYG / MCA / EA（無料系でない）
- 申請者ロール：Owner または相当
- リソースプロバイダ：Microsoft.Compute / Microsoft.MachineLearningServices = Registered
[リージョン]
* 第1候補：East US / East US 2
* 第2候補：West US 2 / South Central US
* 第3候補：West Europe / North Europe / Southeast Asia
[クォータ申請]
* Family：Standard_NCASv3_T4
* vCPU：4（最小で申請 → 承認後に拡張）
* テキスト：目的・期間・段階拡張・コスト管理・Spot 活用
[Azure ML]
* ワークスペース：コンピュートと同一リージョン
* まずは Compute Cluster（最小ノード 0）
* Instance は必要になってから 付録：運用上の小ワザ
- タイムウィンドウ運用：夜間・休日はスケールアウト、営業時間は最小ノードという具合に スケジュールベース自動化でコスト圧縮。
- イメージの使い分け：CUDA バージョンやドライバ整合の取れた AML の curated environment を活用し、起動失敗やドライバ不整合を回避。
- データ近接：トレーニングデータを同リージョンのストレージに置き、リージョン間転送コストと時間を削減。
以上を押さえれば、「GPU インスタンスが作成できない／クォータが却下される」状況でも、原因を定量的に切り分け、最短で実行可能な代替案へリルートできます。まずは有料サブスクリプションと最小クォータの確保から。必要に応じてリージョンを柔軟に切り替え、Azure ML の GPU 基盤を安定的に回していきましょう。
コメント