Azure Arc-enabled serversでHotpatchを有効化する「Enable Hotpatch for Azure Arc-enabled servers」のポイントは、Windows Server 2025 Standard / Datacenterでも、Azure Arcに接続すればホットパッチを追加料金なしで利用できるようになったことです。オンプレミスや他社クラウド上のWindows Server 2025でも、再起動を伴う月例パッチ適用の負担を減らせる可能性があります。
ただし、すべての更新で再起動が不要になるわけではありません。対象OS、VBS/VSM、UEFI・セキュアブート、Azure Arc接続、更新管理の設計を事前に確認しないと、有効化に失敗したり、従来どおり再起動が必要な更新として扱われたりします。この記事では、Windowsの「Enable Hotpatch for Azure Arc-enabled servers」について、変更点、影響範囲、管理者が確認すべき設定、展開時の注意点を実務目線で整理します。Microsoft Learnでは、Windows Server 2025のAzure Arc対応ホットパッチが追加料金なしで利用可能になったこと、利用にはConnected MachineエージェントのデプロイとWindows Server Hotpatchの有効化が必要であることが説明されています。(Microsoft Learn)
Windowsの「Enable Hotpatch for Azure Arc-enabled servers」で何が変わるのか
今回の変更で重要なのは、Azure上の特定VMだけでなく、Azure Arcに接続したWindows Server 2025 Standard / DatacenterでもHotpatchを使いやすくなった点です。
Hotpatchは、Windows ServerにOSセキュリティ更新プログラムを適用する際、通常より再起動を減らすための仕組みです。Microsoft Learnでは、ホットパッチにより実行中プロセスのメモリ内コードへパッチを適用し、マシン再起動を不要にする更新方式として説明されています。(Microsoft Learn)
従来のWindows Server運用では、セキュリティ更新のたびに再起動計画、メンテナンスウィンドウ、フェイルオーバー確認、業務部門への周知が必要になることが少なくありません。Hotpatchを使うと、少なくとも対象となる月のセキュリティ更新については、再起動なしで適用できるため、次のような環境で特に効果があります。
| 利用シーン | Hotpatchの効果 |
|---|---|
| 基幹システムのアプリケーションサーバー | 業務停止時間を短縮しやすい |
| 24時間稼働の社内サービス | 月例更新時の調整負荷を減らせる |
| 拠点サーバー・工場・店舗サーバー | 現地作業や夜間対応を減らせる |
| 複数クラウド・オンプレ混在環境 | Azure Arc経由で更新管理を統一しやすい |
| Server Core中心の運用 | Azure Update Managerや自動化と組み合わせやすい |
ただし、「Hotpatch＝再起動が完全になくなる」と理解すると危険です。3か月ごとのベースライン更新や、Hotpatch対象外の更新では再起動が必要になる場合があります。Microsoft Learnでは、ホットパッチはまず累積更新プログラムでベースラインを確立し、3か月ごとにベースラインを更新、その後2か月間にHotpatchリリースを受け取る仕組みと説明されています。(Microsoft Learn)
追加料金なしになったことで影響を受ける対象者
Microsoft Community Hubの公式発表では、Windows Server 2025向けにAzure Arcで有効化するHotpatchが追加料金なしで利用可能になったこと、対象はオンプレミスまたはマルチクラウド環境のWindows Server 2025 Standard / Datacenterで、Azure Arcへの接続が必要であることが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
特に影響が大きいのは、次のような管理者です。
| 対象者 | 確認すべきこと |
|---|---|
| Windows Server管理者 | 対象サーバーがWindows Server 2025か、VBS/VSM要件を満たすか |
| インフラ管理者 | 物理サーバー・仮想基盤・他社クラウドVMでAzure Arc接続が可能か |
| セキュリティ担当者 | 更新適用の遅延を減らしつつ、再起動計画をどう維持するか |
| 運用設計担当者 | Azure Update Manager、グループポリシー、既存パッチ管理ツールとの役割分担 |
| 開発・アプリ担当者 | ベースライン更新時の再起動でアプリが問題なく復旧するか |
特にオンプレミスのWindows Serverを多く抱える組織では、「Azureに移行しないとHotpatchを使えない」という認識を見直す必要があります。Azure Arcに接続できる運用体制があれば、既存のデータセンターや他社クラウド上のサーバーも、Azureの管理プレーンで扱える可能性があります。
対象となるWindows Serverと前提条件
「Enable Hotpatch for Azure Arc-enabled servers」を検討する際は、まず対象条件を満たしているか確認します。Microsoft Learnでは、Windows Server 2025 ビルド26100.1742以降、Windows Server 2025 Standard / Datacenter、Azure Arc接続、VBS/VSM要件などが前提条件として示されています。(Microsoft Learn)
| 確認項目 | 必要な条件 |
|---|---|
| OS | Windows Server 2025 |
| ビルド | 26100.1742以降 |
| エディション | Standard、Datacenter |
| インストール形態 | Desktop Experience、Server Coreの両方をサポート |
| Azure Arc | 対象マシンがAzure Arcに接続済みであること |
| エージェント | Azure Connected Machine agentが必要 |
| セキュリティ要件 | VBS/VSM要件を満たすこと |
| 起動方式 | UEFI、セキュアブート有効 |
| Hyper-V VM | 第2世代仮想マシンが必要 |
| Azureサブスクリプション | 必要 |
Windows Server 2025 Datacenter: Azure Editionは扱いが異なります。このエディションではHotpatchが既定で有効で、Azure Arc対応である必要はないとされています。ただし、技術的な前提条件は引き続き適用されます。(Microsoft Learn)
対象外になりやすい環境
次のような環境では、有効化前に設計の見直しが必要です。
| 環境 | 注意点 |
|---|---|
| Windows Server 2022 Standard / Datacenter | Azure Arc対応Hotpatchの主対象ではない |
| Windows Server Insiderビルド | プレリリースOS向けHotpatchは作成されない |
| BIOS起動の古い物理サーバー | UEFI・セキュアブート要件を満たさない可能性がある |
| Hyper-V 第1世代VM | VBS/VSM要件を満たせない可能性が高い |
| カスタム更新運用が強い環境 | 既存のWSUS、MECM、サードパーティ製品との整理が必要 |
| インターネット接続が制限された環境 | Azure Arcエージェントの通信要件を確認する必要がある |
特に注意したいのは、古い仮想マシンです。OSだけWindows Server 2025へアップグレードしても、VM世代、セキュアブート、仮想TPM、VBS関連設定が不足していると、Hotpatchの有効化に失敗する可能性があります。
Hotpatchの仕組みを誤解しないための基本
Hotpatchは便利ですが、通常のWindows Updateを完全に置き換えるものではありません。実務上は、次のように理解すると安全です。
| 種類 | 内容 | 再起動 |
|---|---|---|
| ベースライン更新 | 最新の累積更新プログラムを基準点として適用 | 必要 |
| Hotpatch更新 | ベースライン後の対象セキュリティ更新を適用 | 原則不要 |
| 計画外ベースライン | ゼロデイ対応など、Hotpatch化できない重要更新 | 必要 |
| 対象外更新 | .NET、ドライバー、ファームウェア、セキュリティ以外の更新など | 必要になる場合あり |
Microsoft Learnでは、計画された1年間のリリース期間には、4つの計画ベースラインと8つのHotpatchリリースが含まれる場合があると説明されています。つまり、Hotpatchを導入しても、年4回程度の再起動計画は残る前提で運用設計を組むべきです。(Microsoft Learn)
実務での考え方
Hotpatchの価値は「再起動をゼロにすること」ではなく、毎月の再起動を前提にした運用から、再起動が必要な月を絞り込めることにあります。
たとえば、毎月第3日曜日の深夜に全サーバーを再起動していた環境なら、Hotpatch導入後は次のような運用に変えられます。
| 変更前 | 変更後 |
|---|---|
| 毎月、全サーバーで再起動を計画 | Hotpatch月は再起動なしで適用 |
| アプリ担当者が毎月待機 | ベースライン月を中心に待機計画を集約 |
| 再起動後の監視を毎月実施 | 重点監視を再起動が必要な月へ集中 |
| 更新遅延が起きやすい | セキュリティ更新を早く適用しやすい |
結果として、運用負荷を減らしながら、セキュリティ更新の適用スピードを上げやすくなります。
管理者が最初に確認すべき設定
Hotpatchの有効化で失敗しやすいのは、Azureポータルの操作そのものではなく、事前条件の不足です。特にVSMが動作しているかは先に確認しておくべきです。
Microsoft Learnでは、AzureポータルでHotpatchを有効化する際にVSMが実行されているか確認され、VSMが実行されていない場合は有効化が失敗すると説明されています。(Microsoft Learn)
VSMの状態をPowerShellで確認する
対象サーバーで、管理者権限のPowerShellを開き、次のコマンドを実行します。
Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' -ClassName 'win32_deviceGuard' |
Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus'出力が 2 であれば、VSMが構成され実行されています。2 ではない場合は、VSMを有効化してからHotpatchの設定に進みます。Microsoft Learnでも、コマンド出力が 2 の場合にVSMが構成・実行されていると説明されています。(Microsoft Learn)
VSMを有効化する場合の例
VSMを有効にするには、次のようなレジストリ設定を行います。
New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\DeviceGuard' `
-Name 'EnableVirtualizationBasedSecurity' `
-PropertyType 'Dword' `
-Value 1 `
-Force設定後はサーバーの再起動が必要です。再起動後、もう一度VSMの状態を確認し、出力が 2 になっているか確認します。Microsoft Learnでも、VSMを有効化した後はサーバーの再起動が必要とされています。(Microsoft Learn)
VSMが有効にならないときの見方
VSMが有効にならない場合、OS側の設定だけでなく、ハードウェアまたは仮想化基盤の要件を確認します。
| 確認箇所 | 見るべきポイント |
|---|---|
| 物理サーバー | UEFI、セキュアブート、仮想化支援機能 |
| Hyper-V | 第2世代VM、セキュアブート、仮想化ベースのセキュリティ設定 |
| VMwareなど | VBS対応設定、仮想ハードウェアバージョン、セキュアブート |
| セキュリティ機能 | Credential Guard、HVCI、Secured-core serverとの関係 |
| 既存ポリシー | GPOやセキュリティベースラインで無効化されていないか |
ここでつまずくと、Azure Arc側の設定を何度見直しても解決しません。まずローカルOSと仮想基盤の要件を満たしているかを確認するのが近道です。
Azure Arc対応サーバーでHotpatchを有効にする手順
事前条件を満たしていれば、有効化の流れは複雑ではありません。Microsoft Learnでは、Azure Arcに接続した後、Azure ArcポータルのMachinesから対象マシンを選択し、Hotpatchを選んで確認する手順が示されています。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 対象サーバーを棚卸しする | OS、エディション、ビルド、VM世代を確認 |
| 2 | VBS/VSM要件を確認する | PowerShellで状態確認 |
| 3 | Azure Connected Machine agentを導入する | Azure Arcにマシンを接続 |
| 4 | AzureポータルでAzure Arc → Machinesへ移動 | 対象マシンが表示されるか確認 |
| 5 | 対象マシンを選択しHotpatchを有効化 | Hotpatch → Confirm |
| 6 | 反映を待つ | Microsoft Learnでは約10分待つ手順が示されている |
| 7 | 更新管理ツールで適用計画を作る | Azure Update Managerなどと組み合わせる |
有効化後、状態がPendingのまま進まない場合は、Azure Arcエージェントの通信、プロキシ、権限、マシン登録状態を確認します。単に時間を置くのではなく、「Arcエージェントが正常にAzureと通信できているか」を先に見るべきです。
Azure Update Managerとの組み合わせ方
Hotpatchは、1台ずつ手動で適用するより、Azure Update Managerと組み合わせて管理するほうが実務向きです。Microsoft Learnでは、Azure Arcに接続されたマシンではAzure Update Manager、グループポリシー、SConfig、Microsoft以外のパッチ管理ソリューションを使用してHotpatch更新を管理できると説明されています。(Microsoft Learn)
特にサーバー台数が多い場合は、次のような整理をしておくと運用が安定します。
| 管理方法 | 向いている環境 |
|---|---|
| Azure Update Manager | Azure Arc接続サーバーをまとめて可視化・スケジュール管理したい |
| グループポリシー | Active Directory参加サーバーでWindows Update設定を統制したい |
| SConfig | Server Coreでシンプルに更新設定を管理したい |
| 既存のパッチ管理製品 | すでにMECMやサードパーティ製品で統制している |
| API / CLI / PowerShell | IaCや自動化パイプラインに組み込みたい |
おすすめは、適用の判断とスケジュール管理はAzure Update Manager、OS側の基本ポリシーはGPOや既存構成管理で統制する形です。すべてを一つのツールに寄せようとすると、既存の承認フローや監査証跡と衝突しやすくなります。
展開前に決めておくべき運用ルール
Hotpatchの導入は、ボタンを押して終わりではありません。更新運用のルールを変える作業です。最低限、次の項目は導入前に決めておきます。
| 決めること | 具体例 |
|---|---|
| 対象サーバーの範囲 | 本番DBを除くアプリサーバーから開始する |
| パイロット対象 | 開発環境、検証環境、影響の小さい本番サーバー |
| ベースライン月の再起動計画 | 四半期ごとに業務影響の少ない時間帯を確保 |
| Hotpatch月の確認手順 | 更新履歴、監視、アプリ疎通確認 |
| 失敗時の切り戻し | 更新アンインストール、ベースライン更新、再起動手順 |
| 監査・証跡 | どのサーバーにいつ更新を適用したかを記録 |
| 例外管理 | 再起動できないサーバー、VBS非対応サーバーの扱い |
導入順序としては、いきなり全台展開するのではなく、次の順で進めるのが現実的です。
| フェーズ | 作業 |
|---|---|
| 準備 | 対象サーバーのOS、ビルド、仮想基盤、Azure Arc接続可否を棚卸し |
| 検証 | 数台の検証サーバーでVSM、Arc接続、Hotpatch有効化を確認 |
| 小規模展開 | 影響の小さい本番サーバーに適用 |
| 運用設計 | Azure Update Managerでスケジュール、通知、失敗時対応を整備 |
| 本格展開 | サービス単位、拠点単位、環境単位で段階的に拡大 |
| 継続改善 | ベースライン月の再起動実績と失敗原因を見直す |
開発者・アプリ担当者が確認すべきこと
Hotpatchはインフラ機能ですが、開発者やアプリ担当者にも関係します。再起動回数が減ることで運用負荷は下がりますが、アプリケーションの更新確認が不要になるわけではありません。
特に確認すべきなのは、次の3点です。
| 確認項目 | 理由 |
|---|---|
| ベースライン更新後のアプリ起動 | 四半期ごとの再起動時にサービスが正常復旧するか |
| .NETやミドルウェア更新 | Hotpatch対象外の更新で再起動が必要になる可能性がある |
| 監視・ヘルスチェック | 再起動なし更新でもアプリの疎通確認は必要 |
Microsoft Learnでは、Hotpatchプログラムに含まれない更新として、Windowsのセキュリティ以外の更新、.NET更新、Windows以外の更新、ドライバーやファームウェア更新などが挙げられています。(Microsoft Learn)
つまり、アプリ担当者は「毎月の再起動立ち会いが減る」可能性はあるものの、四半期ごとのベースライン更新やミドルウェア更新の確認は引き続き必要です。
失敗しやすいポイントと回避策
Hotpatch導入でよくある失敗は、技術要件、更新サイクル、既存運用との整合性を軽く見てしまうことです。
| 失敗しやすいポイント | 回避策 |
|---|---|
| Windows Server 2025なら全台使えると思い込む | エディション、ビルド、VBS/VSM、Azure Arc接続を確認 |
| 再起動が完全になくなると説明する | ベースライン月や対象外更新では再起動が必要と周知 |
| Azure Arc接続だけ先に進める | プロキシ、通信要件、権限、タグ設計も同時に整理 |
| VSM未対応のVMで有効化する | VM世代、セキュアブート、仮想化基盤の対応を先に確認 |
| 本番全台へ一括展開する | 検証環境、小規模本番、重要システムの順に段階展開 |
| 既存パッチ管理と競合する | WSUS、MECM、GPO、Azure Update Managerの役割を明確化 |
| 更新失敗時の対応を決めていない | 切り戻し、再起動、アプリ確認の手順を事前に文書化 |
特に「更新適用の高速化」と「変更管理の省略」を混同しないことが重要です。Hotpatchを導入しても、セキュリティ更新は本番環境への変更です。承認、適用範囲、監視、障害時対応は従来どおり必要です。
2025年10月更新に関する既知の注意点
Microsoft Learnの該当ページでは、2025年10月にリリースされた複数の更新プログラムや機能ライセンスの問題についても説明されています。内容としては、特定の更新レベルでない場合、2025年11月・12月のHotpatch更新に影響し、通常の非Hotpatch更新として扱われる可能性があるというものです。(Microsoft Learn)
また、2025年10月のセキュリティ更新に関連して、新しいマシンでAzure Arc経由のWindows Server Hotpatch有効化が失敗または完了しない可能性、既存のHotpatch有効化済みマシンで機能ライセンスが期限切れとなり次のHotpatchがインストールされない可能性も記載されています。(Microsoft Learn)
この種の既知の問題は時期によって状況が変わります。実際に導入する前には、Microsoft Learnの該当ページとWindowsリリースヘルス、サポート情報を確認し、自社サーバーの更新履歴と照合してください。
導入判断の基準
Hotpatchは強力な機能ですが、すべての環境で最優先に導入すべきとは限りません。判断基準は「再起動を減らしたいか」だけでなく、「Azure Arcを運用基盤として受け入れられるか」です。
| 導入を優先しやすい環境 | 理由 |
|---|---|
| Windows Server 2025への移行が進んでいる | 対象条件を満たしやすい |
| 月例再起動の調整コストが高い | Hotpatchの効果が出やすい |
| オンプレ・他社クラウドが混在している | Azure Arcで管理を統一しやすい |
| Azure Update Managerを使いたい | 更新状況の可視化・スケジュール管理に向く |
| セキュリティ更新を早く適用したい | 再起動調整待ちによる遅延を減らせる |
一方で、次のような環境では慎重に検討すべきです。
| 慎重に検討すべき環境 | 理由 |
|---|---|
| Windows Server 2019/2022が中心 | 対象OSの整理が先 |
| 古い物理サーバーや第1世代VMが多い | VBS/VSM要件を満たせない可能性 |
| Azure Arc接続が認められていない | ネットワーク・セキュリティ審査が必要 |
| 既存の更新管理が厳格に固定されている | 運用変更の影響が大きい |
| 再起動の業務影響が小さい | 導入効果が限定的な可能性 |
実務では、すべてのサーバーを一気に対象にするより、停止影響が大きく、Windows Server 2025化しやすいシステムから優先するのが現実的です。
管理者向けチェックリスト
導入前には、次のチェックリストを使って確認すると抜け漏れを減らせます。
| チェック | 確認内容 |
|---|---|
| OS | Windows Server 2025か |
| ビルド | 26100.1742以降か |
| エディション | StandardまたはDatacenterか |
| インストール形態 | Desktop ExperienceまたはServer Coreか |
| Azure Arc | 対象マシンがArc対応になっているか |
| エージェント | Connected Machine agentが正常に動作しているか |
| VSM | VirtualizationBasedSecurityStatus が 2 か |
| 起動方式 | UEFI・セキュアブートが有効か |
| 仮想基盤 | Hyper-Vなら第2世代VMか |
| 更新管理 | Azure Update Managerや既存ツールとの役割が明確か |
| 再起動計画 | ベースライン月のメンテナンス枠を確保しているか |
| 監視 | 更新後の正常性確認手順があるか |
| 例外対応 | 非対応サーバーの扱いを決めているか |
| 既知の問題 | Microsoft Learnの最新情報を確認したか |
このチェックを通過したサーバーから段階的に有効化すれば、導入時のトラブルをかなり減らせます。
まず何から始めるべきか
Windowsの「Enable Hotpatch for Azure Arc-enabled servers」は、Windows Server 2025の運用負荷を下げるうえで大きな意味があります。特に、オンプレミスやマルチクラウド環境でもAzure Arcを通じてHotpatchを利用しやすくなったことで、再起動を前提とした月例更新運用を見直すきっかけになります。
最初にやるべきことは、Azureポータルで有効化ボタンを押すことではありません。まず、対象サーバーを棚卸しし、Windows Server 2025、ビルド、エディション、VSM、UEFI・セキュアブート、Azure Arc接続の可否を確認してください。そのうえで、検証環境からHotpatchを有効化し、Azure Update Managerなどで更新適用と監視の流れを確認します。
Hotpatchを正しく導入できれば、再起動が必要な月を減らし、セキュリティ更新の適用スピードを上げながら、Windows Server運用の負荷を現実的に下げられます。
コメント