Azure Red Hat OpenShift（ARO）でAI基盤を運用している、あるいはOpenShiftの運用モデルを維持したまま生成AI対応を強化したい――そんなチームにとって、2026年4月7日の更新はかなり実務的な意味があります。Microsoftは、AROでNVIDIA H100およびH200 GPUベースのAzure VM SKUのサポートを一般提供開始しました。要点を先に言うと、AROの管理・運用の枠組みを崩さずに、H100/H200クラスの高性能GPUをAI学習・推論・HPCへ持ち込めるようになった、ということです。 (Microsoft)
ただし、「発表されたので新規クラスタ作成時にそのまま選べる」と理解すると危険です。現時点のAROサポートポリシーでは、H100/H200はDay-2 only対応で、ARO 4.19以降のクラスタに後から追加するGPUワーカーノードとして扱われています。さらに、GPUクォータは既定で0、リージョンによってはGPU収容性がボトルネックになります。この記事では、ニュースの要約ではなく、H100/H200サポートがARO上のAIワークロードにとって何を意味するのか、どんな案件に向くのか、導入前に何を確認すべきかまで整理します。 (Microsoft Learn)
2026年4月7日に何が発表されたのか
今回の公式発表では、AROがNVIDIA H100およびH200 GPUベースのAzure VM SKUをサポートし、大規模AI、機械学習、HPCワークロードをフルマネージドなOpenShift上で実行できるようになったと説明されています。発表文では、組み込みのセキュリティ、ライフサイクル管理、Azure統合、さらにオンプレミスとクラウドで一貫したOpenShift体験を維持できる点が強調されています。 (Microsoft)
この更新はAzure Updates上で Launched / General Availability として扱われています。Azure UpdatesではLaunchedを「すべてのAzure顧客が利用できる本番向けの正式リリース」と説明しており、単なるプレビューではありません。AROのサポートポリシーでも、OpenShift Container PlatformのTechnology Preview機能はサポート対象外と明記されているため、今回のようにARO側で正式サポートに入ったこと自体が、運用面では大きな意味を持ちます。 (Microsoft Azure)
ARO上のAIワークロードにとって何が変わるのか
単にGPUが増えたのではなく、サポート境界内で使えるGPUの格が上がった
今回の本質は、「AROで使えるGPUが1種類増えた」ことではありません。現時点のサポートポリシーを見ると、AROのGPUワーカーは従来のT4系やA100系に加えて、Standard_ND96isr_H100_v5 と Standard_ND96isr_H200_v5 が並ぶ構成になっています。つまり、AROがカバーできるAIワークロードの守備範囲が、従来のGPU活用から、より本格的な生成AI・大規模学習・HPC寄りまで広がったと見るのが実務的です。 (Microsoft Learn)
今回の主役は「軽量GPU」ではなく、8GPUクラスのND v5系
現在のAROサポートポリシーに載っているH100/H200対応SKUは、どちらも96 vCPUのND v5系です。ND H100 v5は1VMあたり8基のH100、ND H200 v5は1VMあたり8基のH200を搭載し、いずれもVM内外の高帯域接続を前提とした設計です。つまり今回の追加は、「小さく試せるGPUが増えた」というより、分散学習やスケールアウトHPCをOpenShift上で回したい企業向けの選択肢がAROに入ったと捉えるほうが実態に近いです。 (Microsoft Learn)
OpenShiftの運用モデルを崩さずにAI基盤を伸ばしやすくなる
AROはフルマネージドなOpenShiftサービスで、Red HatとMicrosoftが共同で設計・運用・サポートし、利用者がVM運用やパッチ適用を直接持たなくてよいのが強みです。その上でH100/H200ワーカーノードを追加できるようになったため、AI向けだけ別のKubernetes基盤やIaaS設計を持つ必要が薄れます。たとえば、オンプレミスでもOpenShiftを使っている企業なら、RBAC、Operator、監視、ネットワーク設計の考え方を大きく変えずに、学習基盤や大規模バッチ推論をAzure側へ伸ばしやすくなります。 (Microsoft Learn)
H100とH200はどう見分けるべきか
H100が向く場面
ND H100 v5は、ハイエンドのディープラーニング学習と、密結合のスケールアップ・スケールアウト型の生成AI/HPCワークロード向けに設計されています。1VMあたり8基のNVIDIA H100 GPU、3.2 Tbpsの相互接続帯域幅、GPU Direct RDMAを備えるため、まず「分散学習をしっかり回したい」「HPC寄りの並列計算をOpenShift上で扱いたい」という要件に合います。 (Microsoft Learn)
H200が向く場面
ND H200 v5は、AIおよびHPC向けに設計されており、H100比で高帯域幅メモリが76%増、GPUあたり141GBの高速メモリと4.8 TB/sのメモリ帯域幅を持つ点が大きな違いです。Microsoft Learnでも、より大きなデータセットやより複雑なモデルを処理しやすく、生成AIや科学技術計算に適すると説明されています。GPUメモリ不足で分割・オフロード・バッチ縮小が頻発しているなら、H200の価値は非常に分かりやすいと言えます。 (Microsoft Learn)
AzureのAIコンピューティングガイダンスでは、トレーニングではRDMAやGPU間相互接続を持つ最新SKUを選び、推論ではInfiniBandは通常不要とされています。今回AROに追加されたH100/H200がND v5系であることを踏まえると、恩恵が最も大きいのは、常時の軽量オンライン推論よりも、分散トレーニング、大規模バッチ推論、HPC寄りの案件です。 (Microsoft Learn)
導入前に確認したい3つの条件
ARO 4.19以降で、導入方法はDay-2 onlyか
現時点のAROサポートポリシーでは、H100/H200対応として掲載されているのは Standard_ND96isr_H100_v5 と Standard_ND96isr_H200_v5 で、どちらも Day-2 only, 4.19+ と明記されています。つまり、新規クラスタ作成時の初期ノードとして選ぶ前提ではなく、既存クラスタにGPUワーカーノードを追加する設計で考える必要があります。ここを読み違えると、設計の最初からやり直しになりがちです。 (Microsoft Learn)
GPUクォータとリージョン収容性を先に押さえる
AROのGPUワークロード手順では、AzureのGPUクォータは既定で0であり、まずクォータ申請が必要だと明記されています。さらに、GPUワーカーの競争が激しいため、実際に確保できるリージョンでクラスタを用意する必要があるとも説明されています。加えて、AzureのGPUクォータはコア単位で管理されます。今回のH100/H200対応SKUはいずれも96 vCPUクラスなので、「GPUを1台追加するだけ」の感覚で進めると、クォータ不足で止まりやすい点は覚えておきたいところです。 (Microsoft Learn)
実装はMachineSet、GPU Operator、NFDが基本線
公式手順の基本は、既存のMachineSetをテンプレートにしてGPU用MachineSetを作り、vmSize を対象GPUに合わせて変更する方法です。その後、NVIDIA GPU Operatorを導入し、Node Feature Discovery（NFD）でGPUノードを自動検出・ラベル付けし、必要に応じてClusterPolicyを適用していきます。つまり、実務の論点は「対応発表されたかどうか」ではなく、Day-2の追加運用を自社のOpenShift運用フローにどう組み込むかです。 (Microsoft Learn)
GPUワーカー追加後の最小確認としては、NFDがGPUを見えているか、GPU Operator経由で nvidia-smi が通るか、最後にサンプルのCUDA Podが正常終了するかを押さえるのが近道です。公式手順でも、GPUラベルの確認、nvidia-smi の実行、cuda-vector-add サンプルPodによる検証まで案内されています。 (Microsoft Learn)
oc describe node | egrep 'Roles|pci-10de' | grep -v master
oc project nvidia-gpu-operator
for i in $(oc get pod -lopenshift.driver-toolkit=true --no-headers | awk '{print $1}'); do
oc exec -it $i -- nvidia-smi
done詰まりやすいポイント
- 「正式対応 = 初期構築から選べる」と思い込むこと。 現時点ではH100/H200はDay-2 onlyで、ARO 4.19以降の既存クラスタに追加する前提です。 (Microsoft Learn)
- クォータ申請を最後に回すこと。 GPUクォータは既定で0、しかもコア単位です。リージョンの収容性まで含めて最初に確認しないと、PoC開始日がそのまま遅れます。 (Microsoft Learn)
- MachineSetの
vmSizeだけ変えて満足すること。 公式手順では、イメージのskuとversionの整合性も確認するよう案内されており、条件が合わないとVM生成時に失敗します。新しいGPU系SKUほど、この確認を飛ばさないほうが安全です。 (Microsoft Learn) - Red Hat pull secretを整えておらず、GPU Operatorが見つからないこと。 ドキュメントでは、pull secretが不十分だと
gpu-operator-certifiedが見つからないエラーになると説明されています。 (Microsoft Learn) - GPUノードを明示的に載せ分けないこと。 NFDはGPUノードをラベル付けし、公式サンプルでも
nvidia.com/gpu.present: trueをnodeSelectorに指定しています。高価なGPUノードに一般ワークロードが流れ込まないよう、ラベルやスケジューリング方針は最初から決めておくべきです。 (Microsoft Learn)
このアップデートが向くケース
このアップデートが特に効くのは、すでにOpenShiftを標準基盤として使っている企業です。オンプレミスのOpenShiftとAzure上のAROで運用感を揃えたい、Red HatとMicrosoftのサポート境界内でAI基盤を持ちたい、学習・大規模推論・HPCを同じOpenShiftの管理モデルで扱いたい――こうした要件にはかなり相性がよいはずです。発表内容でも、オンプレミスとクラウドで一貫したOpenShift体験を維持しつつ、実験から本番へ移行しやすくなる点が強調されています。 (Microsoft)
逆に、小規模PoCや軽い推論だけが目的なら、少し慎重に見たほうがよいでしょう。AROは最小構成として3つのワーカーノードと3つのマスターノードが必要で、今回のH100/H200対応SKUはいずれも96 vCPUクラスです。しかもAzureのAIガイダンスでは、推論ではInfiniBandは通常不要とされています。つまり、「まずは小さく安く試したい」案件では、今回のH100/H200対応がそのまま最適解になるとは限りません。 (Microsoft Learn)
まず何をすべきか
H100/H200対応の価値は、ARO上でAIを回せるようになったこと自体よりも、AROのサポート境界内で本格GPUを扱えるようになったことにあります。特に、分散学習や大規模HPCをOpenShiftで統制したい企業には、かなり大きな前進です。 (Microsoft)
次に取るべき行動は、次の3つで十分です。
- 自社のAROクラスタが4.19以降か、H100/H200をDay-2で追加する設計にできるかを確認する。 (Microsoft Learn)
- 対象リージョンでGPUクォータと収容性を先に押さえる。特に96 vCPUクラスのノードを何台必要かを具体化する。 (Microsoft Learn)
- MachineSet、GPU Operator、NFD、検証手順まで含めた導入フローを先に1本通して、PoCの前に「作れるか」ではなく「運用できるか」を確認する。 (Microsoft Learn)
コメント