Azure の NCv3（V100）を East US 2（UE2）で使い続けていると、廃止（リタイア）の通知や、A100/H100 のクォータ制限・キャパシティ不足が同時に降ってきて一気に難易度が上がります。この記事では「短期の延命」と「本命の移行」を両立させるための現実的な手順を、判断ポイントとチェックリスト付きで整理します。
最初に押さえる結論：短期はV100延命、移行先の本命はH100
NCv3（V100）の廃止が見えている状況では、理想は新世代 GPU に一気に乗り換えることです。しかし East US 2 で H100 が「クォータがない／キャパシティがない」状態だと、移行作業が進んでも最後に詰まるリスクが高くなります。
そこで現実解としては、次の二段構えが安全です。
- 短期（数週間〜）：今動いている NCv3（V100）を「期限付きの延命措置」として守る（必要なら一時的にクォータ増加）。
- 中長期（数ヶ月〜）：Microsoft 側の推奨移行先として案内される NCads_H100_v5（H100 NVL） を本命に、クォータ申請とキャパシティ確保を並走して進める。
重要なのは、クォータ＝必ずVMが作れる保証ではないことです。クォータとキャパシティは別物なので、どちらも同時に抑えにいきます。
「A100/H100が使えない」の正体：クォータとキャパシティが別レイヤー
East US 2 で A100/H100 を選べない、あるいは作成が失敗するケースは、大きく分けて次の3パターンです。
- クォータが0：サブスクリプションにその GPU ファミリのクォータが付与されていない（上限がゼロ）。
- クォータはあるがキャパシティ不足：上限はあるのに、リージョン内に空きがなく割り当てエラーになる。
- 利用制限（SKU制限・ポリシー等）：サブスクリプション種別、Azure Policy、利用中の構成要件などで作成がブロックされる。
| 項目 | クォータ（上限） | キャパシティ（在庫） |
|---|---|---|
| 意味 | サブスクリプションが使ってよい最大量（vCPU など） | そのリージョンに今、物理的に空きがあるか |
| 増やし方 | Azure ポータルの「クォータ」から申請 | サポート（Capacity / PG）に割当・確保を依頼 |
| 落とし穴 | 通っても VM 作成を保証しない | 空き待ちだと「いつ作れるか」が読みにくい |
今回のように「H100 はキャパシティ チームで再評価中・空き待ち」という回答が返っているなら、クォータの話だけでなく、実キャパシティの割当をどこまで進められるかが勝負になります。
V100（NCv3）と完全一致する後継はない：移行先は“同等”ではなく“目的別”に決める
V100 と同じ GPU を East US 2 で保証する「完全な置き換え」は基本的にありません。そこで発想を切り替えて、用途（学習／推論／前処理／分散）に合わせて候補を絞ります。
候補の位置づけ（よくある整理）
| 候補 | 向いている用途 | メリット | 注意点 |
|---|---|---|---|
| NCads_H100_v5（H100 NVL） | 大規模学習／高性能推論 | 現行世代で長期運用を見据えやすい。V100 からの世代更新として筋が良い。 | クォータとキャパシティの両方が詰まりやすい。ドライバ/CUDA など環境要件も新しくなる。 |
| A100 系（ND/NC の A100 世代） | 学習／推論（バランス型） | V100 からの移行が比較的イメージしやすい。H100 より確保できる可能性がある。 | リージョン提供やクォータが前提。サイズによりネットワーク/ディスク特性が大きく違う。 |
| NCv3（V100）の一時延命 | 移行までのブリッジ | 今動いている本番を崩さずに時間を稼げる。4〜5週間でリージョン移設が難しい状況に強い。 | あくまで“有効期限付き”。最終退役日までのギャップを埋める手段として使う。 |
今回の前提では、Microsoft 側の推奨後継＝NCads_H100_v5 と案内されていることが大きな判断材料になります。社内の説明や監査対応でも「推奨移行先に沿っている」ことは説得力になります。
East US 2 で現実的に取り得るアクション：優先順位はこの順
「4〜5週間で他リージョン移設が難しい」という制約があるなら、優先順位は次の並びが合理的です。
- NCv3（V100）を短期延命：一時的なクォータ増加＋必要ならキャパシティ確認。
- NCads_H100_v5（H100）を本命としてクォータ申請：上限を先に確保し、並行してサポートでキャパシティ割当を依頼。
- H100 が長期で詰まるなら A100 も検討：同じ East US 2 内で確保可能な GPU ファミリがないかを“最新の提供状況”で確認。
- 最終手段としてリージョン移行：中長期計画として、GPU が潤沢なリージョンを候補に入れ、アーキテクチャ含めて再設計。
クォータ増加の申請手順：ポータルで迷わない実務フロー
クォータ増加は、基本的に Azure ポータルから申請します。手順は以下です。
- Azure ポータル → 「クォータ」 を開く
- 「コンピュート」 を選択
- リージョンを East US 2 にフィルタ
- 対象の GPU ファミリ（例：NCads_H100_v5 ファミリ）を選択
- 必要な上限（多くの場合 vCPU 数 で指定）を入力して送信
ここでつまずきやすいポイントを先に潰します。
- “GPUの枚数”ではなく vCPU で申請することが多い（画面の単位を必ず確認）。
- 同じ H100 でも「ファミリ」が分かれる場合があるので、VM サイズ名とファミリ名の対応を先にメモする。
- 本番影響があるなら、申請理由に 退役対応（retirement） と 期限（いつまでに必要か） を明記する。
申請前に準備しておくと通りやすい情報
| 準備項目 | 具体例 | 目的 |
|---|---|---|
| リージョン | East US 2 | キャパシティ確認と一体で話を進める |
| VM サイズ/ファミリ | NCads_H100_v5 / 既存：NC6s_v3 | 申請の取り違え防止 |
| 必要台数・必要期間 | 例：2台を常時、まず3か月 | “いつどれだけ必要か”を明確化 |
| 用途 | 学習/推論、SLA、本番/検証 | 緊急度・重要度の根拠 |
| 移行の背景 | NCv3（V100）廃止に伴う移行 | 正当性を示して審査を通しやすくする |
サポートチケットで“キャパシティ確保”まで動かすコツ
すでに Sev A（重要度A）で起票しているなら、そのスレッドを軸にして次の2点を明確に依頼します。
- H100（NCads_H100_v5）のキャパシティ割当を Capacity チーム/PG にエスカレーションしてほしい
- 並行して、NCv3（V100）の一時的なクォータ増加と、退役までの利用継続可否（リージョン/SKU別）を確認してほしい
チケットに書く内容を「お願い」ではなく「判断材料の提示」に寄せると、進みが速くなりやすいです。
そのまま貼れる依頼テンプレ（例）
依頼内容：East US 2 で NCads_H100_v5（H100）を ○台、○日 までに本番で必要。NCv3（V100）退役対応のため、クォータ増加と実キャパシティの割当（確保可能台数と見込み時期）を確認したい。移行完了までのブリッジとして NCv3 の一時増枠も同時に検討したい。
ポイントは、「いつまでに」「何台」「どのSKUを」「本番で」を短い文章で確定させることです。これが曖昧だと、キャパシティ側は判断できず“空き待ち”のまま停滞しがちです。
なぜ“廃止予定のV100”で一時クォータ増加を勧めるのか
「どうせ廃止されるのに、V100 のクォータ増加は無駄では？」という疑問はもっともです。ですが、移行が詰まっている状況では、V100 の増枠は最もリスクが小さいブリッジ策になり得ます。
- すでに V100 ベースで本番が動作している（互換性検証が最小限）
- H100 は クォータ＋キャパシティの両方が必要で、いつ確保できるかが読みにくい
- 4〜5週間でリージョン移設が難しいなら、短期の安定稼働を守る価値が高い
つまり V100 増枠は、“移行完了までの時間を買う”ための有効期限付きの延命です。最終ゴール（H100や別リージョン）を見失わない限り、合理的な手段になります。
NCv3 / NC6s_v3 の廃止日が資料で違うときの整理方法
「2025/9/30 と 2026/2/28 のように、廃止日が資料で違って見える」という混乱はよく起きます。整理のコツは、“全体のリタイア日”と“SKU/リージョン別の延長”が混在していると捉えることです。
| 見え方 | 例 | 解釈 |
|---|---|---|
| シリーズ全体のリタイア日 | 2025/9/30 | NCv3 という“世代”としての標準的な終了目安 |
| 特定 SKU / 特定リージョンの延長 | 2026/2/28（例：East US 2 の一部） | 移行猶予として、例外的に期限が延びているケース |
実務では、自分のサブスクリプションに紐づく退役通知が最優先です。一般公開の資料よりも、Azure ポータルの通知（Service Health のヘルスアドバイザリ等）や、サポートチケットでの回答が“当事者情報”として強い根拠になります。
判断で迷ったときのルール
- まずは 最も早い日付を“リスク基準”として扱い、計画を前倒しにする
- ただし、サブスクリプション/リージョン/SKU で 延長が明記されているなら、その期限までのブリッジ策（V100増枠等）を現実解として採用
- 「延長あり」と「今後も増やせる」は別なので、増枠の可否は必ずサポートで確認
移行を失敗させない“4〜5週間”の実行プラン（チェックリスト付き）
短期間でやることが多いほど、意思決定がブレて時間を失います。ここでは、最小限の分岐で前に進めるための実行プランを提示します。
| 期間 | やること | 成果物 | 失敗しがちな点 |
|---|---|---|---|
| 今すぐ（当日〜） | 現行 VM サイズと台数、依存関係（ドライバ/CUDA/フレームワーク）を棚卸し | 現状構成メモ、必要GPU条件 | 「GPUだけ」見てネットワーク/ディスク要件を落とす |
| 1〜3日 | East US 2 での H100（NCads_H100_v5）クォータ申請／V100一時増枠申請 | 申請番号、必要 vCPU の根拠 | ファミリ名の取り違え、単位ミス（GPU枚数ではなくvCPU） |
| 同時並行 | Sev A チケットで Capacity/PG への割当依頼、見込み時期の確認 | 確保可否、想定開始日 | 「いつまでに何台」を書かず、空き待ちで停止 |
| 1〜2週間 | H100/A100 用の検証環境を最小構成で用意（作れたら即検証） | 性能比較、互換性チェック結果 | 本番同等の巨大環境から作ろうとして確保に失敗 |
| 〜退役期限まで | 本番移行（段階移行）、監視・コスト最適化、社内ドキュメント整備 | 移行手順、運用Runbook | “いつかやる”で先延ばし→期限直前で詰む |
影響範囲の洗い出し：今どのVMがNCv3を使っているかを即確認する
退役対応で最初に詰まりやすいのが「どこで NCv3（V100）を使っているか分からない」状態です。台数が少なくても、VM 以外（VMSS、AKS のノードプール、ML 基盤など）に散らばっていると見落とします。
最短で把握したい場合は、次のいずれかで“サイズ名”ベースに棚卸しします。
Azure ポータルでの簡易棚卸し
- リソース検索で「Virtual machine」を絞り、一覧で サイズ（VM size） を確認
- VMSS を使っている場合は、スケール セット側の SKU を確認
- 複数サブスクリプションがあるなら、対象を横断して同じ作業を行う
Azure CLI での確認（例）
az vm list --query "[].{name:name, resourceGroup:resourceGroup, size:hardwareProfile.vmSize, location:location}" -o table出力から NC6s_v3 など NCv3 系のサイズを抽出し、移行対象リストを作ります。VMSS も使っている場合は、スケール セットの SKU を別途確認します。
MLワークロードで「T4/A10が合わない」ケースに多い理由と確認ポイント
「T4/A10 が現構成では非対応」という結論は珍しくありません。スペック差というより、要件の取り違えや周辺構成が原因で“使えない”と判断されることも多いです。H100/A100 の検証に入る前に、以下だけは確認しておくと手戻りが減ります。
互換性のチェック観点
- GPUメモリ量：モデル/バッチサイズがメモリに収まるか（学習は特に影響大）
- 精度と演算モード：FP32/FP16/BF16、Tensor Core 前提の最適化があるか
- ドライバ/CUDA：ベースイメージ、NVIDIA ドライバ、CUDA ランタイムの対応関係
- 分散・通信：複数GPU/複数ノードで NVLink や RDMA を前提にしていないか
- 周辺I/O：データローダがディスク/ネットワークに依存してボトルネックにならないか
この観点を押さえると、「T4/A10 は無理だが A100/H100 ならいける」の理由が言語化でき、サポートや社内稟議でも説明しやすくなります。
VMサイズ名の読み方：NC6s_v3 の “s” と “v3” を誤解しない
移行検討では、VM サイズ名の読み方を間違えるとクォータ申請や比較表が破綻します。代表例として NC6s_v3 を分解すると、次のように考えると迷いにくくなります。
- NC：GPU コンピュート系のファミリ（機械学習や HPC の計算用途で使われることが多い）
- 6：サイズの規模（vCPU/メモリ等の段階）
- s：ストレージ特性のサフィックス（例：Premium Storage など）
- v3：世代（第3世代）
新世代では「ads」「ams」「v5」など別のサフィックスが増えます。命名規則のページを“必ず1つ参照元に固定”し、社内で表記ゆれ（NCシリーズ／NCファミリ／NCv3 等）を抑えるだけでも、議論がかなり早くなります。
将来の混乱を防ぐ：社内で“単一の信頼ソース”を決める
GPU の提供状況や退役情報は、古い共有リンクや個人ブログだけを見ていると簡単に迷子になります。今後は、社内の判断基準として次の4つ（＋補助）を“参照元”として固定するのがおすすめです。
| 情報源（一次情報） | 何を確認するか | 実務での使い方 |
|---|---|---|
| NCv3 リタイア（retirement）情報ページ | 廃止タイムライン、SKU/リージョン別の例外（延長） | 日付が食い違ったら“ここ”を起点に整理する |
| NC ファミリ（GPU VM）概要ページ | 世代の違い、用途、各シリーズの位置づけ | 「なぜこの後継を選ぶのか」を社内説明に使う |
| Products by region（リージョン別の提供SKUカタログ） | East US 2 に何があるか／別リージョンに何があるか | 移行先候補を“在庫があるリージョン”から逆算する |
| Azure VM 命名規則（naming conventions） | v3/v4/v5、ads、s、r 等の意味 | SKU名から世代と特性を読み解き、取り違えを防ぐ |
| （補助）Azure ポータルの Service Health / 退役通知 | 自サブスクリプションに対する公式通知 | “当事者情報”として最優先で扱う |
特に Products by region は「East US 2 に A100/H100 があるか」の確認に直結します。逆に、共有資料や古いメモは参照順位を下げ、必ず一次情報で裏を取りましょう。
社内向けに残すと便利な“GPU移行マトリクス”テンプレ
退役対応が長引くほど、担当者が変わったり、別チームが同じ調査を繰り返したりしてコストが増えます。そこで、社内 Wiki などに次のような簡易マトリクスを1枚だけ置いておくと、判断が速くなります。
| リージョン | 現行GPU（例） | 移行候補（例） | クォータ状況 | キャパシティ状況 | 退役期限の扱い | メモ |
|---|---|---|---|---|---|---|
| East US 2 | NC6s_v3（V100） | NCads_H100_v5（H100）, A100系 | 申請中/付与済み/0 | 空きあり/空き待ち/要確認 | 2025/9/30 と 2026/2/28 の整合（サポート回答を採用） | Sev A チケット番号、見込み時期 |
ポイントは、「クォータ」「キャパシティ」「期限」の3つを同じ表に置くことです。これだけで「申請は通ったのに作れない」問題や、「いつまで延命できるか」の認識ズレが減ります。
最後に：判断基準を“固定”すると移行は前に進む
NCv3（V100）の廃止対応は、技術課題というより不確実性（クォータとキャパシティ）をどう管理するかが核心です。短期は V100 を延命しつつ、本命の H100（NCads_H100_v5）を取りにいく二段構えで、稼働を止めずに移行計画を進めてください。
そして、日付や SKU 情報で迷ったら、社内で決めた“単一の信頼ソース”と、サポートチケットの当事者回答を軸に意思決定を揃えるのが最短ルートです。
コメント