Microsoft AzureのAzure Local 最新リリースでは、ハイパーコンバージド展開向けに、SANストレージ対応、分離型デプロイ、GPUアクセラレーションの一般提供、更新設定の制御、Key Vaultを使ったローカルID、展開前のドメイン参加などが追加・強化されています。特に管理者が最初に確認すべきなのは、OSバージョン26100.32690に対応したドライバー、AKSのKubernetes対応バージョン、更新経路、既知の問題、VM停止・再起動時の挙動変更です。新機能を使う前に、ハードウェア、ネットワーク、ID、更新運用の前提を棚卸ししておかないと、展開やアップグレード時に詰まりやすくなります。
Azure Local最新リリースの位置づけ
Microsoft Learnの「What’s new in Hyperconverged Deployments of Azure Local latest release – Azure Local」は、Azure Localのハイパーコンバージド展開で利用できる新機能と改善点をまとめた公式情報です。今回の中心は、2026年4月リリースのAzure Local 2604で、ソリューションバージョンは12.2604.1003.1005、OSビルドは26100.32690です。新規展開では、このビルドが使用されます。(Microsoft Learn)
Azure Localは、オンプレミスやエッジ環境にAzureの管理・監視・セキュリティ機能を広げるための基盤です。今回の更新は、単なる不具合修正ではなく、ストレージ設計、VM運用、AKS、GPU、ID管理、セキュリティベースラインに関わる変更を含みます。既存環境を運用している管理者も、新規にAzure Localを導入するインフラ担当者も、展開前に確認すべき範囲が広がっています。
まず押さえるべき変更点
Azure Local 2604の変更点を、運用への影響が大きい順に整理すると次のようになります。
| 変更領域 | 主な内容 | 確認すべき担当者 |
|---|---|---|
| OS・ドライバー | OSバージョン26100.32690を使用。対応ドライバーが必要 | インフラ管理者、ハードウェア担当 |
| AKS enabled by Azure Arc | Kubernetes 1.31.12以降の複数バージョンをサポート。1.30は非サポート | Kubernetes管理者、アプリ基盤担当 |
| ストレージ | SANストレージの一般提供、分離型デプロイに対応 | ストレージ管理者、設計担当 |
| VM管理 | GPUアクセラレーションGA、データディスク管理改善、正常停止・再起動が既定に | 仮想化管理者 |
| 更新運用 | 更新設定を制御可能。検証時間・展開時間の短縮 | 運用管理者 |
| ID・セキュリティ | Key VaultでのローカルID、展開前ドメイン参加、セキュリティベースライン改善 | ID管理者、セキュリティ担当 |
今回のポイントは、「使える機能が増えた」だけではありません。既定の動作が変わる箇所と、事前に準備しないと更新・展開に失敗しやすい箇所があります。
OSとドライバーは最優先で確認する
Azure Local 2604では、新規・既存の展開でOSバージョン26100.32690が使用されます。また、OSバージョン26100.32690またはWindows Server 2025と互換性のあるドライバーが必要です。統合システムやPremierソリューションハードウェアの場合は、OEMと連携して互換性のあるOSイメージとドライバーを入手する必要があります。(Microsoft Learn)
ここで失敗しやすいのは、「Azure portalからOSイメージを入手できるから、そのまま展開できる」と考えてしまうことです。Azure Localはハードウェア、ファームウェア、ドライバー、SBE（Solution Builder Extension）の整合性が重要です。特に既存クラスターの更新、ノード追加、修復では、実行中のソリューションバージョンとOSイメージの組み合わせを誤ると、検証で止まる可能性があります。
展開前の確認リスト
| 確認項目 | 判断基準 |
|---|---|
| OSイメージ | Azure Local 2604に対応したイメージか |
| NIC・ストレージ・GPUドライバー | OS 26100.32690またはWindows Server 2025対応か |
| OEM提供手順 | ベンダーが2604対応を案内しているか |
| SBE | 対象モデル・SKUに合う更新が提供されているか |
| 更新経路 | 現在のバージョンから直接更新できるか |
特にハードウェアベンダーが検証済みリリースを提供する環境では、Microsoftのリリース直後にすべてのクラスターへ同時適用できるとは限りません。公式情報では、機能リリースの利用可能時期はサーバーモデルやSKU、ハードウェアベンダーの検証完了状況によって変わると説明されています。(Microsoft Learn)
AKS利用環境ではKubernetes 1.30の扱いに注意
AKS enabled by Azure ArcをAzure Local上で使っている場合、今回の更新で最も注意したいのはKubernetesバージョンです。Azure Local 2604では、Kubernetes 1.31.12、1.31.13、1.32.8、1.32.9、1.33.4、1.33.5がサポートされ、Kubernetes 1.30はサポートされなくなりました。また、KMS v1は近く非推奨となり、KMS v2を使ったクラスター再デプロイを計画する必要があります。(Microsoft Learn)
実務では、Azure Local本体の更新だけを見て作業計画を立てると危険です。AKSクラスターのバージョン、ノードプール、KMS設定、アプリケーションの互換性を先に確認してください。
AKS環境での作業順序
| 順序 | 作業 | 目的 |
|---|---|---|
| 1 | 現在のKubernetesバージョンを確認 | 1.30利用有無を把握 |
| 2 | アプリの対応バージョンを確認 | Kubernetes更新による影響を避ける |
| 3 | KMS v2への移行方針を決める | 将来の非推奨リスクを下げる |
| 4 | Azure Localの更新計画に反映 | 基盤とAKSの更新順序を整理 |
| 5 | ステージング環境で検証 | 本番障害を避ける |
「Azure Localを更新すればAKSも問題なく動く」とは考えず、AKS側のサポートバージョンを満たしてからAzure Localを更新するのが安全です。
SANストレージと分離型デプロイで設計の選択肢が広がる
Azure Local 2604では、SANストレージが一般提供されました。公式情報では、SANストレージをAzure Localにアタッチし、Storage Spaces Directと併用できると説明されています。また、SANストレージのみを使った分離型デプロイにも対応し、ストレージとコンピュートを独立してスケールできるようになりました。(Microsoft Learn)
これは、既存のSAN投資を持つ企業や、ストレージ容量とコンピュートリソースを別々に増強したい環境にとって大きな変更です。分離型デプロイの公式概要では、SANを使用する構成で1台から最大64台のマシンまでの規模に対応し、Azure portalやPowerShellなどで管理できるとされています。(Microsoft Learn)
SAN活用が向いているケース
SANストレージ対応は、次のような環境で特に有効です。
- 既存のFC SANを活用したい
- ストレージ容量だけを先に増やしたい
- コンピュートノードとストレージを別々の更新サイクルで管理したい
- エンタープライズ向けのストレージ運用手順を継続したい
- 16ノードを超える拡張を見据えて設計したい
一方で、SANを使えば簡単になるわけではありません。外部ストレージ接続の前提には、2604以降で展開されたAzure Localクラスター、各ノードにインストールされFCファブリックにゾーニングされたファイバーチャネルHBA、管理アクセス可能なSANアレイなどがあります。また、公式手順では、Azure Local展開後までFC HBAのWWNをゾーニングしないよう注意されています。(Microsoft Learn)
Key VaultでのローカルIDが一般提供に
Azure Local 2604では、Azure Key Vaultを使ったローカルIDが一般提供されました。これは、従来のActive Directoryベースの展開に加え、ADに依存しない環境でローカル管理者アカウントと証明書ベースの認証を使い、Azure Key VaultにBitLockerキーや重要な構成データを安全にバックアップする仕組みです。(Microsoft Learn)
エッジ拠点やOTネットワークなど、Active Directoryを置きにくい場所では有力な選択肢です。ただし、ローカルIDを使う場合も、認証情報の管理が不要になるわけではありません。公式ドキュメントでは、組み込みの管理者アカウントではなくローカルユーザーアカウントを作成し、ローカルAdministratorsグループへ追加すること、クラスター内のすべてのノードで同じ資格情報を使うことなどが前提に挙げられています。(Microsoft Learn)
AD参加とローカルIDの使い分け
| 選択肢 | 向いている環境 | 注意点 |
|---|---|---|
| ADベースの展開 | 既存のドメイン管理が整っている本社・データセンター | DNS、時刻同期、権限設計を事前に確認 |
| Key VaultでのローカルID | ADを置きにくいエッジ、工場、隔離ネットワーク | ローカル管理者資格情報、Key Vault、DNS設定を厳格に管理 |
| 展開前ドメイン参加 | 事前にAD参加を済ませて標準化したい環境 | 展開ユーザーをローカルAdministratorsに追加する必要 |
展開前のドメイン参加に対応
Azure Local 2604以降では、展開前にマシンをドメインに参加させることができます。SConfigでドメイン参加を行い、各マシンのローカルAdministratorsグループに展開ユーザーを追加する手順が示されています。事前にドメイン参加しない場合は、Azure portalを使用した展開中に自動的にドメイン参加します。(Microsoft Learn)
この変更は、セキュリティ部門が「サーバーは展開前に必ずドメイン参加させる」という標準を持っている企業にとって扱いやすい改善です。ただし、DNSや時刻同期が不安定な状態で先にドメイン参加すると、展開時の検証で問題が出やすくなります。
ドメイン参加前に確認すること
- DNSサーバーが正しく名前解決できる
- 各ノードの時刻同期が正常
- コンピューター名の命名規則が決まっている
- 展開ユーザーに必要な権限がある
- ローカルAdministratorsグループへの追加漏れがない
特にDNSは後から直せばよいと考えないほうが安全です。Azure LocalのOS構成手順では、展開後のDNSサーバー変更はサポートされない旨が示されています。(Microsoft Learn)
更新設定を制御できるようになった
Azure Local 2604では、更新プログラムの適用方法を制御できるようになりました。公式ドキュメントでは、既定の設定は更新実行時間とワークロード影響のバランスを取る設計であり、利用可能なコントロールで更新動作をサービス要件に合わせて調整できると説明されています。(Microsoft Learn)
重要なのは、ライブマイグレーションが失敗したときの挙動です。既定では、ライブマイグレーションが失敗した場合でも更新完了を優先する設定になっています。一方、ワークロードの稼働を優先したい場合は、SkipForceDrainを有効化して、ライブマイグレーション失敗時に更新プロセスを中止するよう変更できます。(Microsoft Learn)
# ワークロードの稼働を優先する
Enable-UpdateSetting -Name SkipForceDrain
# 設定状態を確認する
Get-UpdateSetting -Name SkipForceDrain
# 既定の動作に戻す
Disable-UpdateSetting -Name SkipForceDrain本番環境では、どちらが正解とは一概に言えません。24時間稼働の業務システムではワークロード稼働優先、保守時間内に確実に更新を終えたい基盤では更新完了優先、というように、SLAと保守体制に合わせて決めるべきです。
VM管理ではGPU、ディスク、停止・再起動の挙動に注目
Azure Local 2604では、Azure Local VMのGPUアクセラレーションが一般提供されました。VM作成時またはDay-2操作として、Azure CLIやAzure portalから、完全なGPUであるDDAやGPUパーティションであるGPU-PをAzure Local VMへアタッチ・デタッチできます。(Microsoft Learn)
DDAでは、物理GPUをワークロード専用に割り当てられます。公式ドキュメントでは、仮想化されたワークロードがネイティブドライバー上で実行され、通常はGPU機能へフルアクセスできるため、高いアプリ互換性と潜在的なパフォーマンスを提供すると説明されています。(Microsoft Learn)
GPU利用前に確認すること
| 確認項目 | 理由 |
|---|---|
| GPUがAzure Local対応か | 物理搭載だけでは利用条件を満たさない場合がある |
| ドライバーとファームウェア | OS更新後の互換性が必要 |
| VM停止を許容できるか | 既存VMへのGPUアタッチ時にVM停止・再起動が発生する場合がある |
| DDAかGPU-Pか | 専有性能重視か、分割利用重視かで設計が変わる |
| AKSでもGPUを使うか | VM用途とAKS用途でリソース設計が競合しやすい |
また、Azure portalでのデータディスク管理も改善され、クラスター単位で新しいデータディスクを作成できるようになり、Azure Local VMビューから既存ディスクをVMに接続できるようになりました。Marketplaceイメージの選択画面もフルページ表示になり、VMイメージ選択がしやすくなっています。(Microsoft Learn)
VMの停止・再起動は既定で正常シャットダウンになる
Azure Local 2604では、Azure Local VMの停止・再起動操作が、既定で正常シャットダウンを行うようになりました。Azure CLIで利用する場合は、stack-hci-vm拡張機能の更新が必要です。強制的にシャットダウンをバイパスする場合は、再起動時に--skip-shutdownフラグを使用します。(Microsoft Learn)
az extension update --name "stack-hci-vm"この変更は、運用手順書に影響します。従来の「停止」が即時電源断に近い意味で使われていた環境では、処理時間やアプリケーション側のシャットダウン動作が変わる可能性があります。夜間バッチ、DBサーバー、状態を持つアプリケーションVMでは、停止・再起動の所要時間を事前に測っておくべきです。
SDN管理をネットワークインターフェイス単位で制御可能に
Azure Localでは、個々のネットワークインターフェイスごとにSDN管理を有効化または無効化できるようになりました。CLIでは--bypass-sdn-policiesフラグを使います。この機能を使う場合も、stack-hci-vm拡張機能の更新が必要です。(Microsoft Learn)
この変更は、複数NICを持つVMや、業務ネットワーク、管理ネットワーク、バックアップネットワークを分けている環境で役立ちます。ただし、SDNポリシーをバイパスする設定は、セキュリティ境界や監査にも影響します。例外設定として使う場合は、対象NIC、目的、期間、承認者を記録しておくことをおすすめします。
セキュリティベースラインとドリフト制御の扱いに注意
Azure Local 2604では、セキュリティベースラインも改善されています。ユーザーログオン時のテキストとバナーが、DISA STIGやCIS要件への準拠に役立つものとして追加されています。また、新しい設定はドリフト制御で保護され、値をカスタマイズするには先にドリフト制御を無効化する必要があります。(Microsoft Learn)
Azure Localのセキュリティ既定値では、システムのセキュリティ、ドリフト制御、セキュアコア設定などを管理できます。ドリフト制御を無効にすると保護された設定を変更できますが、再度有効にすると保護された設定に対して行った変更が上書きされる可能性があります。(Microsoft Learn)
セキュリティ設定変更時の失敗例
| 失敗例 | 起きやすい問題 |
|---|---|
| ドリフト制御を理解せずにローカル設定を変更 | 後で設定が戻り、原因調査に時間がかかる |
| ログオンバナーをGPOとAzure Local側の両方で管理 | 設定の競合が起きる |
| セキュリティ基準を満たす前に本番展開 | 監査時に追加対応が必要になる |
| DefenderやASRルールを強くしすぎる | 更新や修復処理が失敗することがある |
セキュリティ担当とインフラ担当が別組織の場合は、Azure Local独自のドリフト制御を前提に、どの設定をGPOで管理し、どの設定をAzure Local側で管理するかを決めておくと運用が安定します。
既知の問題と更新ブロックは必ず確認する
Azure Local 2604の既知の問題では、2601以降のAzure Localインスタンスで、プラットフォームコンポーネントが通常運用中にVMを誤分類し、意図しないVM削除が発生する可能性がある問題が示されています。対策として、Microsoft On-Premises Cloud（MOC）コンポーネントを修復サポートツールで更新することが案内されています。(Microsoft Learn)
さらに、2601以降のAzure Localでは、ソリューション更新とSBE更新が一時的にブロックされている既知の問題も記載されています。このブロックは、意図しないVM削除のリスクから環境を保護するためのもので、2512以前から2601への更新は影響を受けないと説明されています。(Microsoft Learn)
この点は非常に重要です。管理者は「新しいバージョンがあるから即適用」ではなく、次の順序で確認してください。
| 確認 | 内容 |
|---|---|
| 現在のバージョン | 2601以降か、2512以前か |
| 更新可否 | Azure portalやAzure Update Managerで更新が表示されるか |
| 既知の問題 | 2604のKnown issuesと前リリースから継承された問題を確認 |
| MOC更新 | 修復サポートツール適用が必要か |
| バックアップ | VM、構成、運用手順の復旧準備があるか |
既知の問題は継続的に更新されるため、展開直前に再確認するのが実務上のポイントです。数日前に確認した情報だけで作業に入ると、更新ブロックや回避策の変更を見落とす可能性があります。
既存環境からの移行・更新で注意すべきこと
Azure Localは、リリースモデルやバージョン体系が変化しています。公式リリース情報では、Azure Localは以前の23H2、22H2のような年次リリースから、2507や2506のような月次リリーストレインに合わせたモデルへ変わったと説明されています。また、Azure Localの各リリースは原則として6か月間サポートされ、Azure Arc resource bridgeは証明書有効性とAzure Local VM機能維持のため、1年以内にソリューション更新を適用する必要があります。(Microsoft Learn)
OSバージョン23H2、つまり25398.xxxx系については、2026年4月にサポート終了となる情報も示されています。2026年4月以降は、23H2に対する月次セキュリティ・品質更新が提供されず、サポート要求もサポート対象リリースへのパッチ適用に限定されます。(Microsoft Learn)
既存環境での判断基準
| 現在の状態 | 推奨される確認 |
|---|---|
| 23H2系を運用中 | 24H2/2604系への移行計画を具体化 |
| 2504以降を運用中 | OSビルド26100.xxxx系の更新経路を確認 |
| AKSを利用中 | Kubernetes 1.30が残っていないか確認 |
| GPU VMを運用中 | GPUドライバー、DDA/GPU-P、VM停止手順を確認 |
| SAN導入を検討中 | FC HBA、MPIO、ゾーニング、SANベンダー手順を確認 |
| 更新が表示されない | 既知の更新ブロックやSBE検証状況を確認 |
管理者が展開前にやるべき実務チェック
Azure Local 2604を検討する場合、次の順番で確認すると抜け漏れを減らせます。
現状把握
まず、現在のソリューションバージョン、OSビルド、ノード数、ハードウェアモデル、SBEバージョン、VM数、AKSクラスターの有無を一覧化します。管理対象が複数拠点に分かれている場合は、拠点ごとに更新可否が異なることがあります。
互換性確認
次に、ドライバー、ファームウェア、GPU、SAN、NIC、HBAなどの互換性を確認します。特にSANを使う場合は、MPIO設定、FCファブリック、ゾーニング、WWN登録の順序を運用手順として明文化してください。
更新方針の決定
更新時にワークロード稼働を優先するのか、更新完了を優先するのかを決めます。SkipForceDrainのような更新設定は、技術担当だけでなく、業務部門や運用責任者と合意しておくべき項目です。
検証環境での確認
本番と同じハードウェアを完全に用意できない場合でも、少なくともVM停止・再起動、ディスク操作、Azure CLI拡張機能、AKSバージョン、Key Vault連携、権限設定は検証しておきたいところです。
作業当日の確認
作業当日は、公式のKnown issues、Release information、What’s newを再確認します。Azure Localの既知の問題は継続的に更新されるため、作業計画作成時点の情報だけでは不十分です。
開発者・アプリ担当者が確認すべき影響
Azure Localの更新はインフラ作業に見えますが、アプリ担当者にも影響があります。
特に確認すべきなのは、AKSのKubernetesバージョン、VMの停止・再起動挙動、GPU割り当て、ディスク接続、ネットワークポリシーです。コンテナアプリケーションをAKS enabled by Azure Arc上で動かしている場合、Kubernetes 1.30の非サポート化はアプリのマニフェスト、Ingress、CSI、監視エージェント、バックアップツールに影響する可能性があります。
また、VM停止・再起動が既定で正常シャットダウンになることで、短時間の再起動を前提にした保守手順は見直しが必要です。DB、キュー、ジョブ実行サーバーなどは、シャットダウン時のフックやタイムアウト設定を確認してください。
Azure Local 2604を導入すべき環境、待つべき環境
Azure Local 2604は機能面で魅力的ですが、すべての環境で即時導入が最適とは限りません。
| 判断 | 向いているケース |
|---|---|
| 早めに検証すべき | SAN活用、GPU VM、分離型デプロイ、Key VaultローカルIDを使いたい |
| 慎重に進めるべき | 大規模な本番AKS、24時間稼働VM、複数拠点同時更新 |
| 事前準備が必須 | 23H2系からの移行、Kubernetes 1.30利用、OEM検証待ち |
| すぐ本番適用しない方がよい | 既知の問題を確認できていない、バックアップや復旧手順が未整備 |
特に、2601以降の更新ブロックやVM削除リスクに関する既知の問題は、運用判断に直結します。機能追加だけで判断せず、Known issuesまで含めて導入可否を決めてください。
まとめ：Azure Local最新リリースは「新機能」より「事前確認」が重要
Azure Local最新リリースである2604は、SANストレージ、分離型デプロイ、GPUアクセラレーション、Key VaultでのローカルID、更新設定の制御、展開前ドメイン参加など、ハイブリッド基盤の設計自由度を広げる更新です。一方で、OS 26100.32690対応ドライバー、AKSのKubernetes対応バージョン、VM停止・再起動の挙動変更、SDN管理、セキュリティベースライン、既知の問題を確認せずに進めると、展開や更新でつまずく可能性があります。
次に取るべき行動は明確です。まず、自社環境のAzure Localバージョン、OSビルド、ハードウェア、AKS、VM、SAN、GPUの利用状況を棚卸ししてください。そのうえで、公式のWhat’s new、Release information、Known issuesを展開直前に確認し、ステージング環境で更新・停止・復旧手順を検証することが、Azure Local 2604を安全に活用する近道です。
コメント