Windows 10のサポート終了後も、AVD上のWindows 10をWindows 11移行まで安全に使いたい——そんなときに鍵になるのがESUです。本記事では、MECM（SCCM）＋WSUSで配信する場合の“ライセンス判定”と、更新の空白を作らないための確認ポイントをまとめます。
先に結論：AVDのWindows 10はESUが自動で効き、MECM配信でも運用できる
まず押さえるべきポイントは次のとおりです。
- Azure Virtual Desktop（AVD）上のWindows 10（22H2）のセッションホストは、ESUが追加費用なしで自動的に適用対象になります（ESUの購入やキー投入は不要）。
- 更新の配布経路はMECM（Software Update Point＝WSUS連携）でもOKで、既存の月例パッチ運用の延長で回せます。
- ただし「ESUの前提KBが入っていない」「WSUS/SUPに必要な更新が同期されていない」などがあると、更新が“見えない/降りない”状態になり得ます。
前提整理：Windows 10は2025年10月14日にサポート終了、ESUは延命のための“セキュリティ更新のみ”
Windows 10は2025年10月14日にサポートが終了し、以後は通常の品質更新プログラム（セキュリティ更新を含む）が提供されません。したがって、Windows 11への移行が間に合わない場合は、ESU（Extended Security Updates）で“最低限のセキュリティ更新だけ”を受け取りつつ移行期間を稼ぐ、という設計になります。
ESUは機能追加や非セキュリティ修正が目的ではなく、MSRCが定義する重大度に基づくCritical/Importantのセキュリティ更新を中心に提供される位置づけです。
なぜ「AVDならESUが追加費用なし」なのか（対象条件と注意点）
Microsoft Learnでは、Windows 10 ESUは原則有償（年単位）としつつも、Azure Virtual DesktopやAzure VMなどの特定のAzure環境で稼働するWindows 10 VMには追加費用なしでESUが提供される、と明記されています。AVD上のWindows 10（シングル/マルチセッション）は追加ライセンス購入や手動アクティベーションなしで自動的に対象という扱いです。
| 稼働場所/形態 | ESUの扱い | 管理者がやること（要点） |
|---|---|---|
| AVD セッションホスト（Windows 10 22H2） | 追加費用なし・自動対象 | キー投入は不要。パッチ運用（MECM/WSUS等）を継続し、前提KBと同期状態を担保 |
| Azure VM（AVD以外の一般VM含む） | 追加費用なし（条件により） | 同上。更新経路の設計（WSUS/WUfB/Azure Update Manager等）を統一 |
| Azure上の他社VDI/仮想化（例：Citrix等） | 手動のESUキーが必要になる場合あり | 要件確認（アカウント担当/契約形態）。VDI複製時のキー運用に注意 |
また、AVDに関してMicrosoftは「既存のWindows 10（22H2）セッションホストはESUの対象で、Windows Updateのスキャン（またはAutopatch）時に管理者アクションなしで提供される」と説明しています。重要なのは、“AVD上で正しく動いているWindows 10 22H2”であることです。
「ライセンス判定」はMECMではなく、Windowsの更新判定（スキャン）側で決まる
質問で一番不安になりやすいのが「MECM配信だとESUの権利判定ができず、更新が欠落するのでは？」という点です。ここは整理するとシンプルで、MECMは“更新の配布と適用管理”を担う一方で、その更新がその端末に“適用可能かどうか”はWindows Updateエージェント（更新スキャン/適用判定）側が決めます。
- MECM：更新メタデータの同期（SUP/WSUS）、配布（DP）、適用スケジュール、再起動制御、レポート
- 端末（AVDセッションホスト）：更新のスキャン結果に基づき「必要/不要」「インストール可否」を判定し、必要な更新を適用
AVDのWindows 10はESUが自動対象なので、端末側のスキャン時点で“ESU対象”として認識されれば、ESU用の月例セキュリティ更新（累積更新）が通常どおり適用可能になります。逆に言うと、更新の空白が発生する典型は「MECMが悪い」というより、端末がESU適用可能な状態になっていない（前提KB不足など）、またはWSUS/SUPに更新が来ていない、のどちらかです。
MECMでESUパッチを配信できる？→ できる（ただし“同期と前提”が命）
Microsoftのドキュメントでは、AVD/Azure環境のESU運用においても、WSUSやIntune/SCCM（MECM）を含む既存の更新管理で継続できることが示されています。つまり「AVDをWindows Updateへ直向けにしないと受け取れない」という必須要件はありません。
ただし、MECM配信を成功させる条件が2つあります。
- WSUS/SUPが“ESU期間のWindows 10向け更新”を正しく同期できていること
- セッションホストが“ESU更新をインストールできる前提”を満たしていること
前提：Windows 10 ESUに必要な最低条件（ここが欠けると更新が見えない）
Windows 10 ESUは、端末がWindows 10 version 22H2であることが前提です。加えて、Microsoft Learnでは、ESUを有効にするための前提としてKB5066791（またはそれ以降）と、ESU Licensing Preparation Package（KB5072653）のインストールが必要であることが示されています（KB5072653はKB5066791の後に入れる）。AVDで“キー不要”であっても、この前提パッケージが未適用だと更新の判定が崩れてギャップが出やすくなります。
| チェック項目 | どこで確認 | 期待値（例） | NGだと起きること |
|---|---|---|---|
| OSがWindows 10 22H2か | winver / システム情報 | Windows 10, version 22H2 | ESU対象外として扱われ更新が適用不可 |
| KB5066791（または以降）が入っているか | 更新履歴 / Get-HotFix | 該当KBが存在 | ESU前提不足で更新が不適用/失敗 |
| KB5072653が入っているか | 更新履歴 / Get-HotFix | 該当KBが存在 | ESU判定に必要な準備不足 |
| AVDセッションホストとして正常稼働か | Azure Portal（ホストプール）、エージェント状態 | Available/Healthy | 環境条件が崩れて想定外の判定になり得る |
実務で困らないための「おすすめ構成」：MECM配信を維持しつつ、ギャップ検知を仕組み化
構成パターン：AVDをMECM/WSUS配信のままESU期間を乗り切る
現行がMECM配信で安定しているなら、ESUのために運用を変えるメリットは小さいです。基本は次の構成で十分です。
- SUP（WSUS）でWindows 10向け更新を同期
- ADR（自動展開ルール）で月例の累積更新（LCU）を配布
- AVDセッションホスト用のコレクションを分け、リング（検証→本番）運用
- メンテナンスウィンドウ・再起動制御・ユーザー影響（ドレイン）を設計
ギャップ検知のチェックリスト（更新の空白を“起きる前に”見つける）
「ESUだから怖い」の正体は“更新の空白”です。空白は、月例更新が出たのに環境へ流れてこない状態を指します。次の3点を定例チェックに入れると、空白を早期に炙り出せます。
| チェック観点 | 見る場所 | 合格ライン | NG時の一次対応 |
|---|---|---|---|
| WSUS/SUPの同期が成功しているか | MECMコンソール / wsyncmgr.log | 最新の同期が成功、エラーなし | プロキシ/証明書/同期分類を確認し再同期 |
| 対象KB（当月LCU）がWSUSに存在するか | WSUSコンソール / MECM「すべての更新」 | 当月のWindows 10 LCUが見える | 製品/分類の見直し、必要ならカタログから取り込み |
| セッションホストが前提KBを満たすか | 更新履歴 / Get-HotFix | KB5066791以降 & KB5072653がある | 先に前提KBを配布（イメージ更新も含む） |
| コンプライアンスが落ちていないか | MECMレポート | 目標達成率を維持（例：検証リング>90%） | 失敗端末のログ採取、再評価/再インストール |
AVD特有の落とし穴：セッションホストは“作り方”で更新の当たり方が変わる
既存ホストと新規ホストで差が出るポイント
AVDは「今動いているホスト」と「これから展開するホスト」で、更新状態の作り込みに差が出やすいです。Microsoftは、既存のセッションホスト（Windows 10 22H2）はESUが自動で提供される一方、新規に作成するセッションホストはベースイメージ次第で“最初から古い”ことがあり得る点に触れています。特にAzure MarketplaceのWindows 10イメージは、Microsoft 365 Apps同梱/非同梱でライフサイクルの扱いが異なります。
| シナリオ | 起きがちな問題 | おすすめ対策 |
|---|---|---|
| 既存ホスト（すでに運用中） | 当月から突然更新が“見えない” | 前提KB/WSUS同期/適用判定ログを順に確認 |
| 新規ホスト（スケールアウト/入替） | 展開直後に大量の未適用が発生、またはESU前提不足 | ゴールデンイメージに前提KB＋最新LCUを焼き込み、入替を標準化 |
| 非永続（再イメージ前提） | 更新しても“戻る”ためコンプライアンスが安定しない | 更新はホスト個体ではなくイメージ更新で担保（MECMは検証・例外対応に寄せる） |
「Windows Updateへ直向け」しなくてもいい？→ 原則不要、ただし“非常時の逃げ道”は用意する
結論から言うと、ESUのためだけにAVDをWindows Updateへ直向けにする必要は原則ありません。MicrosoftはAVD/Azure環境では追加設定やキーなしでESUが提供され、更新管理もWSUSやIntune/SCCMを含む既存手段で継続できるとしています。
ただし、現場では「WSUS同期が詰まった」「当月の更新だけ取り込めない」などの事故はゼロにはできません。そこでおすすめは、直向け運用に切り替えるのではなく、“緊急時だけの手順（ブレイクグラス）”を決めておくことです。
- 緊急時にだけ、特定の検証ホスト（または一時コレクション）で更新ソースを切り替えられる手順をドキュメント化
- 切り替えの前後で、グループポリシー/ローカルポリシー（WSUS指定）を元に戻すチェックもセットにする
- 「直向けにした結果、意図せずドライバ/プレビューが入る」リスクもあるため、適用範囲は最小化
トラブルシューティング：ESU更新がMECMに“来ない/見えない/入らない”ときの切り分け
症状別の当たりを付ける（最短ルート）
| 症状 | まず疑う場所 | 一次切り分け | よくある原因 |
|---|---|---|---|
| WSUS/SUPに当月の更新が存在しない | サーバ側 | 同期ログ/製品・分類を確認 | 製品/分類の設定漏れ、同期エラー、プロキシ |
| WSUSにはあるが、端末が「必要なし」になる | 端末側 | OSバージョン/前提KB/スキャンログ | 22H2でない、KB5072653未適用 |
| 必要と判定されるがインストール失敗 | 端末側 | CBS/WindowsUpdateログを確認 | 依存関係不足、コンポーネント破損、空き容量 |
| 一部ホストだけ更新が降りない | 端末/運用 | コレクション/境界/メンテナンス | 配布範囲の漏れ、再起動抑止、ドレイン設計不備 |
端末側コマンド例：前提KBの有無を素早く確認
まずは「前提KBが入っているか」を機械的に確認すると、切り分けが速くなります。
powershell -NoProfile -ExecutionPolicy Bypass -Command ^
"Get-HotFix | Where-Object {$_.HotFixID -in 'KB5066791','KB5072653'} | Sort-Object InstalledOn | Format-Table -AutoSize"運用のコツ：AVDの“ユーザー影響を増やさない”パッチ手順（MECM前提）
プール（Pooled）セッションホストの場合
- リング運用：検証ホストプール（少数）→本番ホストプール（多数）へ段階展開
- ドレイン（新規セッション停止）：更新適用前に対象ホストへ新規ログオンを止め、既存セッションの自然終了を待つ
- 再起動制御：MECMの再起動を“ホストの空き状況”に合わせ、強制再起動がユーザーに刺さらないようにする
個人割当（Personal）セッションホストの場合
- ユーザーごとの利用時間が固定化しやすいので、メンテナンスウィンドウの設計が効きます
- 「パッチ→再起動→健康状態確認→解放」の定型を作り、失敗時のロールバック（別ホストへ退避等）も用意
ゴールデンイメージ運用（推奨）
AVDで台数が多い場合、最終的に強いのはイメージを最新化してから入れ替える運用です。特にESU期間は「前提KB」「毎月のLCU」が安定して入ることが最優先なので、次のような流れが現実的です。
- ゴールデンイメージに対して月例更新を適用（前提KBを含む）
- アプリ動作検証（サインイン、Teams/Office相当、業務アプリ）
- 本番ホストを段階的に入替（スケールプランと連携）
- 旧ホストは計画的に廃棄（ドリフトを減らす）
よくある質問（現場目線）
数か月だけESUが欲しい。年単位購入が必要？
AVDのWindows 10セッションホストは追加費用なしでESU対象なので、“使う期間が数か月”でも購入手続きは不要です。一方、AVD以外の一般的な有償ESUは年単位で、途中月だけ買うことはできません（年2から入る場合でも年1相当が必要などの考え方）。
ESUキーを入れていないのに、本当に更新される？
AVDのWindows 10は、Microsoftの説明ではキーや手動アクティベーションなしで対象として認識され、スキャン時にESU更新が提供されるという扱いです。したがって「キー投入していない＝不安」という感覚は自然ですが、AVDに限っては“入れないのが正常”です。
MECM配信のままでも、Windows Updateに向けたスキャンが必要？
運用としてはMECM/WSUS配信のままで問題ありません。ポイントは「端末がESU更新を適用できる前提を満たす」ことと「WSUS/SUPが更新を取り込めている」ことです。ここが成立していれば、ESU期間の月例更新も従来の運用フローで回せます。
まとめ：ESUは“仕組み”より“前提と同期”を押さえると安心して回る
AVD上のWindows 10をESUでパッチ運用する場合、悩みどころは「ライセンス判定」ですが、実際にはAVDセッションホストは自動対象であり、MECM（WSUS連携）で従来どおり配信できます。怖いのは“更新の空白”なので、次の3点を守るだけで事故率が大きく下がります。
- Windows 10 22H2であることを担保する（古いバージョンを残さない）
- 前提KB（KB5066791以降＋KB5072653）をイメージ/ホストへ確実に入れる
- WSUS/SUPに当月の更新が入っているかを定例でチェックし、リング運用で早期検知する
コメント