Azure Local 2026年4月更新で最初に押さえるべき結論は、2604リリースが単なる月例修正ではなく、SAN対応、分離型デプロイ、Key Vaultを使ったローカルID、GPU活用、更新制御、AKS対応バージョンの見直しまで含む実務寄りのアップデートになっている点です。特に、オンプレミス基盤をAzureの管理面で運用しているIT管理者は、「すぐ更新してよいか」より先に、OSビルド、OEMドライバー、AKSのKubernetesバージョン、SAN設計、更新時のVM退避方針を確認する必要があります。
Microsoft Learnの「What’s new in hyperconverged deployments of Azure Local?」は2026年4月23日に更新され、Azure Local 2604の新機能と改善点をまとめています。Azure Localは旧Azure Stack HCIであり、今回の更新はハイパーコンバージド環境をクラウドから展開・更新・監視し、Azure Local VM管理やセキュリティを簡素化する方向性をさらに進める内容です。(Microsoft Learn)
Azure Local 2026年4月更新の要点
Azure Local 2604のハイパーコンバージドデプロイは、ソリューションバージョン 12.2604.1003.209、OSビルド 26100.32690 として案内されています。Microsoftのリリース情報では、このビルドの提供開始日は2026年4月22日とされています。(Microsoft Learn)
今回の更新を実務視点で整理すると、主な影響は次の5つです。
| 領域 | 変更点 | 管理者が確認すべきこと |
|---|---|---|
| 基盤OS・ドライバー | 2604では新規・既存のAzure LocalデプロイがOSバージョン26100.32690を使用 | ハードウェアがOS 26100.32690またはWindows Server 2025互換ドライバーを利用できるか確認 |
| ストレージ | SAN対応が一般提供され、SANのみを使う分離型デプロイも可能に | 既存SANを再利用するか、Storage Spaces Direct中心で運用するかを設計し直す |
| ID・セキュリティ | Key Vaultを使ったローカルIDが一般提供 | AD前提でない拠点、OT環境、エッジ環境での導入方式を検討 |
| AKS on Azure Local | 対応Kubernetesバージョンが更新され、1.30はサポート対象外 | Azure Local更新前にAKSクラスタのバージョンを棚卸し |
| VM運用 | GPUアクセラレーション、ディスク管理、Marketplaceイメージ表示、VM再起動、NIC単位のSDN制御が改善 | VM作成・更新の運用手順とAzure CLI拡張機能を見直す |
まず確認すべき対象環境
Azure Local 2604は、Azure Localをすでに運用している組織だけでなく、これからハイブリッドクラウド基盤を構築する企業にも関係します。特に影響が大きいのは、次のような環境です。
既存のAzure Stack HCI／Azure Localを運用しており、月例更新を定期適用している環境では、OSビルドとOEMドライバーの整合性が重要です。Integrated SystemまたはPremier Solutionのハードウェアを使っている場合、MicrosoftはOEMと連携して互換OSイメージと互換ドライバーを取得するよう案内しています。(Microsoft Learn)
AKS enabled by Azure ArcをAzure Local上で利用している場合は、Azure Local本体の更新だけでなく、Kubernetesのサポートバージョンも確認が必要です。2604では Kubernetes 1.31.12、1.31.13、1.32.8、1.32.9、1.33.4、1.33.5がサポート対象として示され、Kubernetes 1.30はサポート対象外になっています。(Microsoft Learn)
また、GPUを使うAI推論、CAD、VDI、高負荷分析ワークロードをオンプレミス側で動かす組織にとっては、Azure Local VM向けGPUアクセラレーションの一般提供が大きな変更です。2604では、VM作成時またはDay-2運用で、フルGPUのDDAやGPUパーティションをAzure CLIまたはAzure portalからアタッチ／デタッチできるとされています。(Microsoft Learn)
OSとドライバー更新は「互換性確認」が最優先
Azure Local 2604では、すべての新規および既存デプロイがOSバージョン26100.32690を使用すると説明されています。ここで重要なのは、OSだけを見て更新可否を判断しないことです。Microsoftは、OS 26100.32690またはWindows Server 2025と互換性のあるドライバーが必要だと明記しています。(Microsoft Learn)
実務では、次の順番で確認すると失敗を減らせます。
| 確認項目 | 具体的な確認内容 | 見落とした場合のリスク |
|---|---|---|
| 現在のAzure Localバージョン | 既存環境がサポートされる更新経路上にあるか | 更新パス不一致、サポート外状態 |
| OEMドライバー | NIC、HBA、ストレージ、GPU、ファームウェアが2604対応か | 更新後の通信断、ストレージ認識不良、GPU利用不可 |
| SBE更新 | ハードウェアベンダーのSolution Builder Extensionが利用可能か | 更新検出や適用の失敗 |
| メンテナンス時間 | VMのライブマイグレーション、再起動、検証時間を見込めるか | 業務影響の過小評価 |
| 既知の問題 | 2604固有だけでなく、過去リリースから引き継がれた問題を確認 | 既知の回避策を適用せず障害対応が長期化 |
Microsoftの既知の問題ページでは、2604リリース自体には「既知の問題なし」とされています。一方で、以前のリリースから継続する既知の問題は掲載されているため、更新前には2604だけでなく「Known issues from previous releases」も確認するのが安全です。(Microsoft Learn)
SAN対応と分離型デプロイで設計の選択肢が広がる
Azure Local 2604で特に注目したいのが、SANを使った構成の強化です。Microsoftは2604から、Azure LocalをSANストレージのみでデプロイできるようになり、ストレージとコンピュートを独立して拡張できるため、16ノードを超えるクラスタ拡張が可能になると説明しています。また、SANストレージのAzure Local対応は一般提供となり、Storage Spaces Directと併用できるとも案内されています。(Microsoft Learn)
分離型デプロイの公式概要では、SANストレージを使うAzure Localインスタンスは1台から最大64台の物理マシンまで対応し、Azure portal、Azure CLI、ARM/Bicep/Terraform、Windows Admin Center、PowerShellなどで管理できるとされています。(Microsoft Learn)
どちらを選ぶべきか
Storage Spaces Direct中心の従来型構成が不要になるわけではありません。むしろ、どちらが適しているかは、既存資産、拡張計画、運用チームのスキルで判断すべきです。
| 構成 | 向いているケース | 注意点 |
|---|---|---|
| Storage Spaces Direct中心 | サーバー内蔵ディスクでシンプルにHCI基盤を構築したい | コンピュートとストレージの拡張が結びつきやすい |
| SAN併用 | 既存SAN投資を活かしつつAzure Local VMを運用したい | FC HBA、ゾーニング、LUNマスキング、MPIOの設計が必要 |
| SANのみの分離型デプロイ | 大規模環境でコンピュートとストレージを別々に拡張したい | 対応ハードウェア、SANベンダー手順、運用分担を明確にする必要がある |
SAN接続の手順では、Azure Local 2604以降、Windows Server 2025認定のFibre Channel HBAとドライバー、FCファブリック上のゾーニング、SANアレイへの管理アクセスが前提とされています。さらに、Microsoftはデプロイ時の混乱を避けるため、Azure Localデプロイ後までFC HBAのWWNをゾーンインしないよう注意しています。(Microsoft Learn)
この点は現場で失敗しやすいポイントです。SAN管理チームが先にLUNを見せてしまうと、デプロイ時のディスク認識や検証で想定外の結果になる可能性があります。Azure Local、SAN、ネットワーク、セキュリティの担当者が別チームの場合は、更新・構築手順書に「WWN登録のタイミング」を明記しておくべきです。
Key Vaultを使ったローカルIDが一般提供に
2604では、Key Vaultを使ったローカルIDが一般提供になりました。これは、従来ADベースで進めていたAzure Localデプロイに加え、ADに依存しない構成を取りやすくする変更です。Microsoftの説明では、ローカル管理者アカウントを使うローカルID方式により、証明書ベース認証でクラスタレベルの統合を構成し、Azure Key VaultがBitLockerキーなどの重要なシークレットの安全なバックアップ先として使われます。(Microsoft Learn)
この機能が向いているのは、次のような環境です。
- 工場、店舗、物流拠点など、Active Directory基盤を最小化したいエッジ環境
- OTネットワークなど、ファイアウォール構成をできるだけ単純にしたい環境
- 海外拠点や小規模拠点で、AD運用を各拠点に広げたくない組織
- シークレット管理をAzure Key Vaultに集約したいMicrosoftエコシステム中心の企業
ただし、ローカルID方式は「ADが不要だから簡単」というだけではありません。公式手順では、ローカル管理者アカウントを作成し、全ノードで同じ資格情報を使うこと、静的IPアドレスを使いDHCPをサポートしないこと、DNSサーバーとゾーンを適切に構成することなどが前提として示されています。(Microsoft Learn)
デプロイ前のドメイン参加に対応
2604では、Azure Localのデプロイ前にマシンをドメイン参加させる構成もサポートされました。SConfigの「Domain/workgroup」からドメイン参加し、各マシンのローカルAdministratorsグループにデプロイ用ユーザーを追加する流れが案内されています。事前にドメイン参加しない場合は、Azure portalでのデプロイ中に自動的にドメイン参加されます。(Microsoft Learn)
この変更は、Active Directoryチームとインフラチームの分業が明確な企業で役立ちます。たとえば、事前にコンピューター名、OU、GPO、DNS、時刻同期を確認してからAzure Localデプロイに進めるため、デプロイ中に認証・名前解決・権限まわりの問題で止まるリスクを下げられます。
一方で、DNS設計は慎重に扱う必要があります。MicrosoftはSConfigでDNSをドメイン参加先のDNSに設定するよう案内し、デプロイ後にDNSサーバーを変更することはサポートされないと注意しています。(Microsoft Learn)
更新設定の制御で「更新完了優先」か「ワークロード稼働優先」かを選べる
2604では、Azure Localの更新適用方法を制御できる更新設定が案内されています。公式ドキュメントでは、デフォルト設定は更新時間とワークロード影響のバランスを取るものとされ、VMのライブマイグレーションに失敗した場合の動作を変更できると説明されています。(Microsoft Learn)
実務上のポイントは、更新ポリシーを「システムを最新化すること」だけで決めないことです。基幹業務VM、24時間稼働の製造系システム、VDI、GPUワークロードなどが同居している場合、ライブマイグレーション失敗時に更新を継続するか、中断してワークロード稼働を優先するかは事前に決めておくべきです。
ワークロード稼働を優先し、ライブマイグレーション失敗時に更新プロセスを中断させたい場合は、公式手順で次の設定が示されています。(Microsoft Learn)
Enable-UpdateSetting -Name SkipForceDrain設定状態は次のコマンドで確認できます。
Get-UpdateSetting -Name SkipForceDrainデフォルト動作に戻す場合は、次のコマンドを使います。
Disable-UpdateSetting -Name SkipForceDrainこの設定は、すべての環境で有効にすればよいものではありません。更新完了を優先したい検証環境や短時間停止が許容される環境では、デフォルトのままのほうが運用しやすい場合があります。逆に、本番VMの停止回避を最優先する環境では、更新前レビューのチェック項目に入れておく価値があります。
デプロイと検証の時間短縮は現場への効果が大きい
Azure Local 2604では、デプロイおよび更新時の検証時間が最大50%短縮され、失敗時には3時間以内であれば失敗地点から再開できるようになったと説明されています。また、最大8ノードまでのクラスタではデプロイ時間がより一貫し、全体として最大40%短縮されるとされています。(Microsoft Learn)
この改善は、単に「速くなる」というより、作業計画を立てやすくなる点が重要です。従来、検証エラーが出るたびに最初からやり直していた環境では、メンテナンス時間の見積もりが保守的になりがちでした。2604では再開性が改善されるため、検証エラーの原因を潰しながら進める運用がしやすくなります。
ただし、最大値として示される短縮率をそのまま自社環境に当てはめるのは危険です。ノード数、OEMハードウェア、ネットワーク、SBE、Azure接続品質、既存構成のドリフトによって所要時間は変わります。初回更新では、検証環境または非ピーク時間帯で実測値を取り、次回以降の標準作業時間に反映するのが現実的です。
AKS on Azure LocalはKubernetes 1.30終了に注意
Azure Local上でAKS enabled by Azure Arcを利用している場合、2604更新前にKubernetesバージョンの確認が必須です。2604では、サポート対象として Kubernetes 1.31.12、1.31.13、1.32.8、1.32.9、1.33.4、1.33.5 が示され、Kubernetes 1.30はサポートされなくなりました。(Microsoft Learn)
さらに、KMS v1は近く非推奨になる予定で、2604にはKMS v2が含まれるため、KMS v2を使ってクラスタを再デプロイする計画を立てるよう案内されています。KMSはKubernetesのシークレット暗号化に関わるため、単なるバージョン番号の問題ではなく、セキュリティ運用とクラスタライフサイクルの問題として扱うべきです。(Microsoft Learn)
更新前には、次の観点でAKSクラスタを棚卸ししてください。
| 確認対象 | 確認内容 | 推奨アクション |
|---|---|---|
| Kubernetesバージョン | 1.30以前のクラスタが残っていないか | サポート対象バージョンへのアップグレード計画を作る |
| シークレット暗号化 | KMS v1利用クラスタがあるか | KMS v2前提の再デプロイ計画を検討 |
| ノードプール | Windows/Linux、GPU利用、OSディスク容量 | 更新後のノード再作成や容量計画を確認 |
| ネットワーク | Pod CIDR、Service CIDR、既存ネットワークとの重複 | Azure Local更新前にIP設計を再確認 |
| 運用手順 | クラスタ更新とAzure Local更新の順序 | 変更手順書に依存関係を明記 |
Azure Local VM運用はポータル中心に使いやすくなる
2604では、Azure Local VMまわりの運用改善も多く含まれています。たとえば、Azure portalでクラスタレベルの新しいデータディスク作成ができるようになり、ディスク概要の表示や管理ワークフローの視認性が改善されています。また、Azure Local VMの画面から既存ディスクをVMへアタッチできるようになりました。(Microsoft Learn)
Azure Marketplaceイメージのナビゲーションも改善され、新しいVMイメージ作成時にダウンロード可能なMarketplaceイメージ一覧をフルページで表示できるようになっています。これにより、複数OSや複数イメージを使い分ける運用で、選択ミスを減らしやすくなります。(Microsoft Learn)
また、Azure Local VMの再起動操作はデフォルトでグレースフルシャットダウンを行うようになりました。Azure CLIから利用する場合は、stack-hci-vm拡張機能を更新する必要があります。シャットダウンをバイパスしたい場合は、--skip-shutdownフラグを使います。(Microsoft Learn)
az extension update --name "stack-hci-vm"この変更は小さく見えますが、運用上は重要です。従来の手順書で「再起動＝即時再起動」の前提になっている場合、所要時間やアプリケーション側の停止検知が変わる可能性があります。本番VMでは、再起動手順、監視アラート、メンテナンス通知の文面まで見直しておくと安全です。
NIC単位のSDN管理でネットワーク制御が細かくなる
2604では、個別のネットワークインターフェイスごとにSDN管理を有効化または無効化できるようになりました。Azure CLIで利用する場合は、こちらもstack-hci-vm拡張機能の更新が必要で、--bypass-sdn-policiesフラグを使って動作を構成します。(Microsoft Learn)
この機能は、すべてのNICを同じポリシーで扱いにくい環境で役立ちます。たとえば、管理用NIC、業務アプリ用NIC、バックアップ用NIC、閉域接続用NICを分けているVMでは、どのNICをSDNポリシー配下に置くかを明確にできます。
ただし、便利だからといって安易にバイパス設定を使うのは避けるべきです。ネットワークセキュリティグループ、監査、セグメンテーションの設計と矛盾しないよう、変更理由、対象NIC、承認者、戻し手順を運用台帳に残すことをおすすめします。
GPUアクセラレーション一般提供でオンプレAI・VDIの現実味が増す
2604では、Azure Local VM向けGPUアクセラレーションが一般提供として案内されています。Azure Localは、VM作成時または作成後の運用で、フルGPUのDDAやGPUパーティションをAzure CLIまたはAzure portalからVMにアタッチ／デタッチできると説明されています。(Microsoft Learn)
DDAは物理GPUをワークロードに専有させる方式で、公式ドキュメントではネイティブドライバー上で仮想化ワークロードを動かし、高いアプリ互換性とパフォーマンスが期待できる方式として説明されています。(Microsoft Learn)
実務での活用候補は次のとおりです。
| 活用シーン | 期待できる効果 | 注意点 |
|---|---|---|
| AI推論 | データをオンプレミスに置いたまま低遅延で処理 | GPU対応サーバー、ドライバー、モデル実行環境の検証が必要 |
| CAD／CAE | 拠点内で高負荷グラフィックス処理を実行 | GPU割り当て方式とライセンス条件を確認 |
| VDI | グラフィックス性能が必要な仮想デスクトップを提供 | ユーザー密度、GPU分割、監視設計が重要 |
| 映像解析 | エッジ側で映像データを処理しクラウド転送量を削減 | ストレージ容量、ネットワーク帯域、ログ保存を設計 |
GPU機能は導入効果が分かりやすい一方、サーバー調達、冷却、電力、ドライバー、VMサイズ、アプリ互換性まで影響します。PoCでは「GPUが認識できるか」だけでなく、実ワークロードの処理時間、再起動時の挙動、障害時の切り戻しまで確認すべきです。
更新前チェックリスト
Azure Local 2604へ進む前に、次のチェックリストを使って準備状況を確認してください。
| チェック | 確認内容 |
|---|---|
| 現行バージョン | Azure Localの現在のソリューションバージョンとOSビルドを確認 |
| 更新経路 | サポートされる更新パス上にあるか確認 |
| ハードウェア | OEMの2604対応状況、SBE、ファームウェア、ドライバーを確認 |
| AKS | Kubernetes 1.30以前のクラスタがないか確認 |
| SAN | FC HBA、MPIO、ゾーニング、LUNマスキング、CSV化手順を確認 |
| ID | ADベース、事前ドメイン参加、ローカルID＋Key Vaultのどれを使うか決定 |
| DNS | デプロイ後にDNS変更できない前提で設計を確定 |
| VM退避 | ライブマイグレーション失敗時に更新完了を優先するか、稼働維持を優先するか決定 |
| Azure CLI | stack-hci-vm拡張機能を更新 |
| 既知の問題 | 2604固有と過去リリースから継続する既知の問題を確認 |
特に本番環境では、Azure Local更新、AKSクラスタ更新、SAN設定変更、GPU割り当て変更を同じメンテナンス枠に詰め込みすぎないほうが安全です。影響範囲が異なる変更は分けて実施し、各段階でヘルスチェックとロールバック判断を入れると、障害時の切り分けがしやすくなります。
まとめ：2604は「更新」ではなく運用設計を見直すタイミング
Azure Local 2026年4月更新は、OSや品質修正だけを適用するリリースではありません。SAN対応と分離型デプロイによりストレージ設計の幅が広がり、Key Vaultを使ったローカルIDでADに依存しない拠点展開がしやすくなり、GPUアクセラレーションの一般提供でオンプレミス側のAI・VDI活用も進めやすくなりました。
一方で、AKSのKubernetes 1.30終了、OS 26100.32690対応ドライバー、SANの接続順序、DNS設計、更新時のライブマイグレーション方針など、事前に決めるべき項目も増えています。
次に取るべき行動はシンプルです。まず、自社のAzure Local環境について「現在のバージョン」「OEM対応状況」「AKSバージョン」「SAN／GPU利用有無」「更新時のVM退避方針」を棚卸ししてください。そのうえで、2604を単なる月例更新として扱うのではなく、ハイブリッドクラウド基盤の拡張計画、セキュリティ設計、運用自動化を見直す機会として計画するのが最も実務的です。
コメント