Azure Localの2026年4月更新では、運用担当者がまず見るべきポイントは明確です。2604リリース自体の新規の既知の問題は公式リリースノート上では「なし」とされています。一方で、Windows Admin Center、Azure Arc登録、更新ステータス表示、Defender設定、Mochostagentなど、過去リリースから継続する既知の問題は残っています。つまり今回の更新は「安心して何もしなくてよい更新」ではなく、修正点を確認しつつ、既存環境のリスクを事前点検する更新と捉えるべきです。Microsoft Learnの該当ページは2026年4月23日に更新され、Azure Local 2604のソリューションバージョンは12.2604.1003.209、OSビルドは26100.32690です。(Microsoft Learn)
Azure Local 2026年4月更新の要点
Azure Local 2604は、派手な新機能だけを見るよりも、VM管理、更新処理、デプロイ、修復操作の信頼性改善に注目すべきリリースです。Microsoftのリリースノートでは、このリリースに含まれる修正済みの問題、今回リリースの既知の問題、過去リリースから引き継がれる既知の問題が整理されています。(Microsoft Learn)
特にIT adminsやプロダクトオーナーにとって重要なのは、次の3点です。
- Azure Local 2604単体では、新規の既知の問題は公式上「なし」とされている
- ただし、過去リリースから継続する既知の問題は運用上の確認が必要
- VM、更新、デプロイ、Add-server／Repair-serverまわりの不具合修正により、日常運用の安定性向上が期待できる
Azure Localは、従来Azure Stack HCIとして知られていたオンプレミス／エッジ向けのハイパーコンバージド基盤です。Microsoftの最新説明でも、クラウドベースのデプロイ、更新、監視、Azure Local VM管理、セキュリティなどが重視されています。(Microsoft Learn)
2604リリースの基本情報
Azure Local 2604の基本情報は次のとおりです。
| 項目 | 内容 |
|---|---|
| リリース | Azure Local 2604 |
| ソリューションバージョン | 12.2604.1003.209 |
| OSビルド | 26100.32690 |
| Microsoft Learn更新日 | 2026年4月23日 |
| 新規デプロイで使われるビルド | 12.2604.1003.209 |
| 2604リリース自体の既知の問題 | 公式リリースノート上ではなし |
Microsoftのリリース情報では、12.2604.1003.209の提供開始日は2026年4月22日とされています。また、新規デプロイではこのビルドが使用されます。(Microsoft Learn)
ここで注意したいのは、「提供開始日」と「自社環境で更新できる日」が必ずしも一致しない点です。Azure Localの機能リリースは、サーバーモデルやSKU、Solution Builder Extensionの検証状況によって利用可能になる時期が変わる場合があります。ハードウェアベンダーの検証後に配信されるケースもあるため、更新計画ではOEMやハードウェアベンダーの情報も確認してください。(Microsoft Learn)
今回の更新で修正された主な問題
2604では、Azure Local VM、更新処理、デプロイ、サーバー修復に関する複数の問題が修正されています。運用影響の大きいものから見ると、次のように整理できます。(Microsoft Learn)
| 領域 | 修正内容 | 運用上の意味 |
|---|---|---|
| Azure Local VMs | ストレージパス未指定時の事前チェックが、誤ってインフラストラクチャボリュームを対象にする問題を修正 | VM作成時に意図しない保存先が使われるリスクを下げられる |
| Azure Local VMs | 大きなギャラリーイメージの作成・更新が遅延またはタイムアウトする問題を改善 | イメージ運用の待ち時間や失敗リスクを減らせる |
| Azure Local VMs | Azure Localインスタンスと異なるリソースグループにあるVMへVM Connectできない問題を修正 | リソースグループを分けて管理している環境で接続性が改善する |
| Update | サブスクリプションがアクティブでない場合のCloud Managementサービス失敗に対し、更新ヘルスチェックを追加 | 更新前の検出精度が上がり、更新途中の失敗を減らしやすい |
| Update | SBE更新が検出されない問題に対し、検出URLとハードウェアモデル／SKUの一致確認を追加 | ハードウェア依存の更新確認で原因を切り分けやすい |
| Deployment | DNSタイムアウトによってデプロイが失敗する問題を修正 | 新規展開や再展開時の失敗要因を減らせる |
| Update | SBE更新の再開、サイドロード更新、過去のヘルスチェック失敗後の更新などに関する問題を修正 | 更新運用の復旧性が改善する |
| Repair server | Add-serverとRepair-serverでCluster Build ID matches node to add's Build IDエラーが発生する問題を修正 | ノード追加・修復作業の停止リスクを下げられる |
VM管理まわりは実務影響が大きい
今回の修正で特に現場に効くのは、Azure Local VM関連です。
たとえば、ストレージパスを明示しないVM作成シナリオで、事前チェックがインフラストラクチャボリュームを対象にしてしまう問題は、単なる表示上の不具合ではありません。保存先の設計や運用ルールに影響し、環境によっては後から調査・移動・再作成が必要になる可能性があります。
また、大きなギャラリーイメージの作成や更新がタイムアウトしにくくなる改善は、標準イメージを使って複数VMを展開する組織にとって重要です。テンプレート化されたWindows Serverイメージ、業務アプリ入りイメージ、検証用イメージを運用している場合、イメージ操作の安定性は展開スピードに直結します。
異なるリソースグループのVM Connect対応は管理設計に効く
VM Connectが、Azure Localインスタンスとは別のリソースグループにあるAzure Local VMへ接続できるようになった点も見逃せません。(Microsoft Learn)
多くの環境では、次のようにリソースグループを分けます。
| 分け方 | 例 |
|---|---|
| 環境別 | rg-prod-local、rg-dev-local |
| 部門別 | rg-finance-vm、rg-sales-vm |
| 用途別 | rg-management、rg-workload |
| 権限別 | 管理基盤用RGとアプリ担当者用RGを分離 |
これまでは、こうした構成で接続面の制約が運用負担になる可能性がありました。2604の修正により、リソースグループ設計の自由度を保ちながら、VM接続の実務性が改善されます。
「既知の問題なし」はどう読むべきか
Azure Local 2604のリリースノートでは、今回リリースのKnown issuesについて「There are no known issues for this release」とされています。(Microsoft Learn)
ただし、これは「Azure Localで注意すべき問題が一切ない」という意味ではありません。Microsoftの同じページには、previous releasesから継続するKnown issuesが掲載されています。運用判断では、次のように分けて考える必要があります。
| 見るべき項目 | 意味 | 判断 |
|---|---|---|
| Known issues for version 2604 | 2604リリースで新たに明示された既知の問題 | 公式上はなし |
| Known issues from previous releases | 過去リリースから継続して注意が必要な問題 | 更新前後に確認が必要 |
| Known and expected behaviors | バグではなく、仕様または想定動作として扱うべき挙動 | 回避ではなく運用ルール化が必要 |
つまり、2604の評価では「新規の既知の問題がない」ことを前向きに捉えつつ、過去から残る問題をチェックリスト化して潰すことが重要です。
継続して注意すべき既知の問題
2604でも、過去リリースから引き継がれる既知の問題があります。特に運用影響が大きいものを、実務目線で整理します。(Microsoft Learn)
| 領域 | 既知の問題 | 実務での対応 |
|---|---|---|
| Windows Admin Center | Cluster Manager拡張が古い場合、ボリューム削除操作で問題が起きる可能性 | Cluster Manager 5.2.6以上、またはWindows Admin Center 2511 build 2.6.6.18以上を使う。更新前にボリューム削除をしない |
| Update | 更新中にSBE manifest endpoint not reported by Get-SolutionDiscoveryDiagnosticInfoが表示される場合がある | 警告レベルのため、更新中は無視可能 |
| Azure Verification | Windows Server Azure Edition、Windows 10、Windows 11 multi-sessionのVMでライセンス認証表示が正しくない場合がある | VMは動作するが、ウォーターマークが残る可能性がある。現時点で公式上の回避策なし |
| Deployment | Azure Arc登録時にAZCMAgentのexitcode: 42で失敗する場合がある | Microsoftのトラブルシューティング手順に従う |
| Azure Local VM management | Mochostagentサービスが動作中に見えても、ログ更新が止まる場合がある | C:\programdata\mochostagent\logsを確認し、必要に応じてrestart-service mochostagentを実行 |
| Update | Azure Update Managerの準備チェックで同名のチェックが複数表示される場合がある | View detailsで個別内容を確認 |
| Update | Azure portal上の更新状態が、完了後もFailed to updateやIn progressに見える場合がある | PowerShellで実際の状態を確認し、必要に応じてCloud Managementクラスタグループを再起動 |
| Security | Defender for EndpointのRestrict App Execution設定により、更新や修復で問題が起きる可能性 | Defenderポータルで設定を無効化し、再起動。解消しない場合はサポートへ |
| Security | PSExec／WMI由来のプロセス作成をブロックする攻撃面縮小ルールにより、Solution Updateが失敗する可能性 | 更新前にセキュリティポリシーを確認 |
| Add server / Repair server | リコールされた特定イメージでノード追加・修復が失敗する場合がある | 対象バージョンを確認し、必要に応じてサポートへ |
| Update | Secret rotationのアクションプラン状態取得が失敗する場合がある | Secret rotation自体は完了しているため、失敗メッセージは無視可能 |
Windows Admin Centerは更新前に必ず確認する
Windows Admin CenterのCluster Manager拡張が古い場合、ボリューム削除操作に問題が起きる可能性があります。Microsoftは、データ損失を防ぐためにCluster Manager拡張を5.2.6以上に更新するか、Windows Admin Center 2511 build 2.6.6.18以上を使うよう案内しています。(Microsoft Learn)
この問題は、更新作業そのものよりも「更新前後のついで作業」で踏みやすいポイントです。たとえば、更新前に不要ボリュームを整理しようとして古いWindows Admin Centerから削除操作を行うと、余計なリスクを抱えます。
実務では、次の順番が安全です。
- Windows Admin Centerのバージョンを確認する
- Cluster Manager拡張のバージョンを確認する
- 古い場合は先に更新する
- 更新できない場合は、Windows Admin Centerからのボリューム削除を避ける
- 変更作業の証跡を残す
Azure portalの表示だけで更新完了を判断しない
Azure portalでは、更新が完了していてもステータスがFailed to updateまたはIn progressのまま表示される場合があります。Microsoftは、PowerShellで実際の更新状態を確認し、Installedであれば追加対応は不要と説明しています。ポータル表示は24時間以内に正しく更新されるとされています。(Microsoft Learn)
確認には、リモートPowerShellでAzure Localインスタンスに接続し、次のようなコマンドを使います。
$Update = get-solutionupdate | ? version -eq "<version string>"
$Update.state<version string>には、実際に実行しているバージョンを入れます。2604であれば、環境に表示される対象バージョンを正確に指定してください。
ポータル表示を早く更新したい場合は、Cloud Managementクラスタグループを再起動する手順も案内されています。
Stop-ClusterGroup "Cloud Management"
Start-ClusterGroup "Cloud Management"ただし、この操作は管理系コンポーネントに影響します。運用中の本番環境では、変更時間帯、影響範囲、作業者、ロールバック方針を決めてから実行してください。
更新前に確認すべきチェックリスト
Azure Local 2604へ更新する前に、最低限確認したい項目を整理します。
| 確認項目 | 確認する理由 | 判断基準 |
|---|---|---|
| 現在のソリューションバージョン | 更新パスとサポート状態を判断するため | Azure Localのリリース情報でサポート対象か確認 |
| OSビルド | 2604の対象ビルドとドライバー互換性を確認するため | 26100.32690に対応するドライバーを確認 |
| ハードウェアモデル／SKU | SBE更新やOEM検証の影響を受けるため | ベンダーの更新提供状況を確認 |
| サブスクリプション状態 | 更新ヘルスチェックで問題になり得るため | Azureサブスクリプションがアクティブであること |
| Windows Admin Center | ボリューム削除リスクを避けるため | Cluster Manager 5.2.6以上、またはWAC 2511 build 2.6.6.18以上 |
| Defender for Endpoint設定 | 更新・修復が失敗する可能性を避けるため | Restrict App ExecutionやASRルールを確認 |
| Azure Arc登録状態 | Azure Local管理の前提になるため | Arc登録エラーや接続状態の異常がないか確認 |
| Mochostagentログ | VM管理の異常を早期に検出するため | ログが継続的に更新されていること |
| AKS enabled by Azure Arc | Kubernetesバージョン非対応を避けるため | サポート対象バージョンであること |
| 監視・バックアップ | 更新失敗時に復旧できるようにするため | 監視アラート、作業ログ、復旧手順を準備 |
Microsoftのリリース情報では、Azure Localをサポートされた状態に保つため、原則として6か月以内に更新を適用する必要があると説明されています。また、Azure Arc resource bridgeについては証明書とAzure Local VM機能を維持するため、1年以内のソリューション更新が重要とされています。(Microsoft Learn)
AKS enabled by Azure Arcを使っている環境の注意点
Azure Local上でAKS enabled by Azure Arcを利用している場合は、Azure Local本体だけでなく、Kubernetesバージョンも確認が必要です。
2604では、AKS enabled by Azure Arcのサポート対象としてKubernetes 1.31.12、1.31.13、1.32.8、1.32.9、1.33.4、1.33.5が示されています。一方で、Kubernetes 1.30はサポート対象外とされています。(Microsoft Learn)
この点を見落とすと、Azure Local本体の更新は進められても、AKSクラスタ側で互換性やサポートの問題が出る可能性があります。特に、アプリケーションチームとインフラチームが分かれている組織では、更新前に次の確認を行ってください。
- AKSクラスタのKubernetesバージョン
- アプリケーションのKubernetes対応バージョン
- マニフェスト、Helmチャート、Ingress、ストレージクラスの互換性
- 更新後の検証観点
- 本番反映前のステージング環境での動作確認
KMS v1についても、将来的な非推奨が示され、2604ではKMS v2が含まれると説明されています。AKSクラスタの再デプロイ計画が必要になる可能性があるため、単なる月次更新ではなく、中期的なクラスタ更新計画として扱うべきです。(Microsoft Learn)
SAN対応と分離型デプロイはロードマップ観点で確認する
2604の「What’s new」では、SANストレージのみを使ったAzure Localのデプロイが可能になり、ストレージとコンピュートを独立して拡張できる分離型デプロイが示されています。また、Azure LocalのSANサポートは一般提供とされています。(Microsoft Learn)
これは、すべての既存環境がすぐ構成変更すべきという意味ではありません。むしろ、次のようなケースで検討価値があります。
| 検討シーン | SAN／分離型デプロイが効きやすい理由 |
|---|---|
| コンピュートだけ増やしたい | ストレージ拡張と切り離してノード設計しやすい |
| ストレージ投資を既存SANに寄せたい | 既存のストレージ運用スキルを活かせる可能性がある |
| 大規模クラスタを検討している | 独立したスケール設計により、拡張計画を立てやすい |
| 部門別・拠点別にリソース設計したい | ストレージとワークロードの責任分界を整理しやすい |
ただし、SAN対応は設計・調達・運用体制に関わるテーマです。2604適用のついでに構成を変えるのではなく、PoC、性能検証、障害時の切り分け、監視設計まで含めて判断するのが現実的です。
更新後にやるべき確認作業
Azure Local 2604の適用後は、Azure portalの見た目だけで完了判断をしないことが重要です。次の順で確認すると、トラブルを早期に検出できます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | ソリューションバージョンを確認 | 期待するバージョンが表示されているか |
| 2 | PowerShellで更新状態を確認 | Installedになっているか |
| 3 | Azure portalの表示を確認 | In progressやFailed表示が残っていないか |
| 4 | VM操作を確認 | 起動、停止、削除、VM Connectが正常か |
| 5 | ギャラリーイメージ操作を確認 | 大きなイメージの作成・更新が安定しているか |
| 6 | Mochostagentログを確認 | ログ更新が止まっていないか |
| 7 | Azure Arc接続を確認 | 登録状態、接続状態、拡張機能に異常がないか |
| 8 | セキュリティ設定を戻す | 更新のため一時変更したDefender設定を戻す |
| 9 | 証跡を残す | バージョン、作業者、実施時刻、確認結果を記録 |
特に、ポータル上の更新状態が実際の状態とずれる可能性がある点は、運用報告で誤解を生みやすいポイントです。作業完了報告では、Azure portalのスクリーンショットだけでなく、PowerShellで確認した状態も残すと安心です。
失敗しやすいポイント
Azure Localの更新で失敗しやすいのは、技術的な不具合そのものよりも、事前確認の抜けです。
「既知の問題なし」だけを見て変更審査を通す
2604単体の新規既知の問題がないとしても、過去から継続する既知の問題は残っています。変更審査では、「Known issues for version 2604はなし。ただしprevious releases由来の注意点として、Windows Admin Center、Azure portal表示、Defender設定、Mochostagentを確認する」と説明すると、リスクを正しく伝えられます。
セキュリティ設定を更新直前に確認しない
Defender for Endpointや攻撃面縮小ルールは、セキュリティチームが一括管理していることがあります。インフラ担当者が更新ウィンドウに入ってから気づくと、設定変更の承認が間に合いません。
更新計画には、次の担当を明記してください。
- Azure Local更新担当
- セキュリティポリシー確認担当
- Azure Arc／Azure portal確認担当
- アプリケーション影響確認担当
- 障害時のエスカレーション先
OEMやハードウェアベンダーの検証状況を見落とす
Azure Localは、サーバーモデルやSKUによって機能リリースの利用可能タイミングが変わる場合があります。Microsoftのリリースが出たからといって、すべての環境で同時に適用できるとは限りません。(Microsoft Learn)
特に、Integrated SystemやPremier solution hardwareを利用している場合は、OEMから互換OSイメージや互換ドライバーを入手する必要があります。2604ではOSビルド26100.32690に対応するドライバーが必要とされています。(Microsoft Learn)
RegBackによるレジストリ復元を復旧策に入れる
Azure Localでは、RegBackを使ったレジストリ復元はサポートされていません。この操作により、Lifecycle ManagerやMicrosoft On-premises Cloudの設定が削除され、Azure Localインスタンスが破損する可能性があると説明されています。(Microsoft Learn)
障害復旧手順を作る場合は、一般的なWindows Serverの復旧手順をそのまま流用しないでください。Azure Local固有の管理コンポーネントを前提に、Microsoft公式のサポート手順を確認する必要があります。
IT管理者向けの実践的な進め方
Azure Local 2604の更新は、次の流れで進めると現場で判断しやすくなります。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 事前調査 | 現在のバージョン、OSビルド、ハードウェア、Arc登録、WAC、Defender設定を確認 | 更新前チェックシート |
| 影響確認 | VM、AKS、SAN、監視、セキュリティポリシーへの影響を確認 | 影響範囲一覧 |
| 変更計画 | 作業時間、担当者、手順、確認コマンド、ロールバック方針を決定 | 変更申請書 |
| 検証 | 可能であれば検証環境で2604更新を試す | 検証結果 |
| 本番適用 | 更新を実行し、PowerShellとポータルで状態確認 | 作業ログ |
| 事後確認 | VM操作、Mochostagent、Arc接続、監視アラートを確認 | 完了報告 |
| ナレッジ化 | 発生した警告、回避策、所要時間を記録 | 次回更新用メモ |
この流れにすると、単に「更新を当てた」で終わらず、次回のAzure Local更新にも使える運用資産が残ります。
プロダクトオーナーが見るべき判断ポイント
プロダクトオーナーやサービス責任者は、細かいコマンドよりも、今回の更新が事業やサービス運用にどう効くかを把握する必要があります。
2604で見るべき観点は次の3つです。
| 判断軸 | 見るべきポイント |
|---|---|
| 安定性 | VM作成、イメージ更新、VM Connect、更新再開などの修正により、運用停止リスクを下げられるか |
| サポート継続 | Azure Localをサポート対象バージョンに維持できるか |
| 将来設計 | SAN対応、分離型デプロイ、AKSバージョン対応を今後の基盤計画に反映すべきか |
特にサポート継続は重要です。Azure Localでは、更新を怠るとサポート対象外になる可能性があります。Microsoftは、更新されていないバージョンはセキュリティ脆弱性やコンプライアンス上のリスクにさらされる可能性があり、サポート対象バージョンを維持する必要があると説明しています。(Microsoft Learn)
2604更新で次に取るべき行動
Azure Local 2026年4月更新では、2604リリース自体に新規の既知の問題は示されていません。一方で、過去リリース由来の既知の問題は引き続き確認が必要です。
まず実施すべきことは、次の3つです。
- 自社のAzure Localバージョン、OSビルド、ハードウェアモデル、SKUを確認する
- Windows Admin Center、Defender設定、Azure Arc登録、Mochostagent、Azure portal表示の既知の問題に該当しないか確認する
- 2604更新後は、Azure portalだけでなくPowerShellでも更新状態を確認する
今回の更新は、VM管理や更新処理の安定性を高める実務寄りのリリースです。特に、Azure Local VMを本番運用している環境、ギャラリーイメージを使ってVM展開している環境、複数リソースグループで管理している環境では、2604の修正内容を確認する価値があります。
「既知の問題なし」という表現だけで判断せず、過去から残る注意点をチェックリストに落とし込み、更新前・更新後の確認まで含めて計画することが、Azure Localを安定して運用する近道です。
コメント