2026年4月の「Windows Server 2022 known issues and notifications」で最優先に確認すべき点は、4月のセキュリティ更新プログラム適用後に一部のドメインコントローラーで再起動ループが発生する問題が、定例外更新プログラムで解決されたことです。特に、複数ドメインのフォレストやPrivileged Access Management（PAM）を使うActive Directory環境では、KB5082142だけが適用された状態を放置しないことが重要です。
あわせて、BitLocker回復キーの入力を求められる可能性、RDPファイルを開く際の警告表示の不具合、Windows Server 2025への意図しないアップグレード問題、Secure Boot証明書更新の準備も確認しておきたいポイントです。Microsoft LearnのWindows Server 2022 release healthページでは、DC再起動ループ問題が「解決済み」として掲載され、OOB更新プログラムKB5091575による対応が案内されています。(Microsoft Learn)
Windowsの最新動向: Windows Server 2022 known issues and notificationsで何が変わったか
「Windows Server 2022 known issues and notifications」は、Windows Server 2022の既知の問題、更新プログラムの影響、解決状況を確認するためのMicrosoft公式ページです。2026年4月更新で管理者が見るべきポイントは、単に「不具合があるか」ではなく、どの更新プログラムを、どのサーバーに、どの順序で適用すべきかです。
今回の主な確認項目は次のとおりです。
| 更新ポイント | 影響を受ける可能性がある環境 | 管理者が取るべき対応 |
|---|---|---|
| DC再起動ループ問題の解決 | Windows Server 2022のドメインコントローラー、特に複数ドメインフォレストとPAM利用環境 | KB5082142適用後、KB5091575またはホットパッチKB5091576の適用状況を確認 |
| BitLocker回復キー要求の可能性 | BitLockerと特定のTPM/PCR7関連グループポリシーを使うサーバー | 回復キーの保管状況、PCR7 Binding、BitLocker GPOを事前確認 |
| RDP警告表示の不具合 | 複数モニターで表示倍率が異なる管理端末 | 表示倍率を統一し、RDP警告を読み飛ばさない運用に変更 |
| Windows Server 2025への意図しないアップグレード問題 | サードパーティ製パッチ管理ツールを使う環境 | 機能更新プログラムを「任意」として扱う設定を確認 |
| Secure Boot証明書更新の準備 | Secure Bootを使う物理サーバー、仮想化基盤、クラウドVM | 2026年6月以降の証明書期限に備え、検証計画を開始 |
「解決済み」と表示されていても、すべての環境で自動的に安全な状態になったとは限りません。WSUS、Microsoft Configuration Manager、Intune、サードパーティ製パッチ管理ツールを使っている場合は、管理ツール側でKBの承認・配布・適用完了を確認する必要があります。
最重要はドメインコントローラーの再起動ループ対策
2026年4月のWindows Server 2022更新で最も影響が大きいのは、ドメインコントローラーが起動時にLSASSクラッシュを起こし、再起動を繰り返す可能性がある問題です。
Microsoftの説明では、2026年4月のWindowsセキュリティ更新プログラムKB5082142をインストールして再起動した後、フォレスト内に複数ドメインがあり、PAMを使用している環境のドメインコントローラーでLSASSクラッシュが発生する可能性があります。その結果、認証やディレクトリサービスが機能せず、ドメインが利用できなくなる恐れがあります。対象はWindows Server側であり、クライアントPCは対象外とされています。(Microsoft Learn)
KB5082142だけが入っているDCを優先的に確認する
今回の問題で最も避けたいのは、重要なドメインコントローラーにKB5082142だけが入り、OOB更新プログラムが未適用のまま残ることです。
まず、Windows Server 2022のDCで次の状態を確認します。
| 確認項目 | 見る場所・コマンド例 | 判断の目安 |
|---|---|---|
| OSビルド | winver またはPowerShellでCurrentBuild/UBRを確認 | KB5082142適用後の20348.5020だけで止まっていないか確認 |
| KB5091575の適用有無 | Get-HotFix -Id KB5091575 | 標準のOOB更新が適用済みか確認 |
| ホットパッチ対象か | Azure Edition、Hotpatch登録状況 | 対象ならKB5091576を確認 |
| DCの状態 | dcdiag、repadmin /replsummary | 認証、レプリケーション、DNS、SYSVOLの異常を確認 |
| イベントログ | Directory Service、System、LSASS関連イベント | 再起動、認証失敗、LSASS停止の痕跡を確認 |
PowerShellでビルド情報を確認する場合は、次のように実行できます。
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object ProductName, CurrentBuild, UBRKBの適用状況は、次のコマンドで確認できます。
Get-HotFix -Id KB5091575ただし、環境によってはGet-HotFixだけでは更新履歴を十分に確認できない場合があります。WSUS、Configuration Manager、Intune、サードパーティ製パッチ管理ツールのレポートと、OSビルドの両方で確認するのが安全です。
KB5091575とKB5091576の違いを整理する
Windows Server 2022向けの標準OOB更新プログラムはKB5091575です。Microsoft SupportのKB5091575ページでは、2026年4月19日リリース、OS Build 20348.5024の定例外更新として掲載され、KB5082142適用後のDC起動問題を修正する内容が説明されています。(マイクロソフトサポート)
一方、Windows Server 2022 Datacenter: Azure Editionでホットパッチに登録されている環境では、KB5091576が対象です。KB5091576はOS Build 20348.5029のOOB Hotpatch更新で、KB5082142をすでに適用したデバイスに提供され、再起動なしでインストール・有効化されると説明されています。(マイクロソフトサポート)
| 更新プログラム | 対象 | ビルド | 実務上のポイント |
|---|---|---|---|
| KB5082142 | 2026年4月の通常セキュリティ更新 | 20348.5020 | DC再起動ループ問題の発生元として確認が必要 |
| KB5091575 | Windows Server 2022標準環境 | 20348.5024 | DC再起動ループ問題を修正するOOB更新 |
| KB5091576 | Windows Server 2022 Datacenter: Azure EditionのHotpatch対象 | 20348.5029 | 再起動不要のホットパッチとして提供 |
注意したいのは、KB5091575が通常のWindows Updateで自動配布される前提で運用しないことです。KB5091575の案内では、スタンドアロンパッケージはMicrosoft Update Catalogから取得する形で説明されています。パッチ管理ツールを使う組織では、カタログからの取り込み、承認、配布リングへの割り当てを明示的に確認してください。(マイクロソフトサポート)
本番DCへ適用する前に確認したい手順
ドメインコントローラーは、通常のメンバーサーバーよりも更新失敗時の影響が大きいサーバーです。KB5091575の適用は急ぐべきですが、無計画に全DCへ一斉展開するのは避けます。
おすすめの流れは次のとおりです。
| 順序 | 作業 | 目的 |
| -: | —————————— | ——————– |
| 1 | DC一覧、OSバージョン、KB5082142適用状況を棚卸し | 対象サーバーを絞り込む |
| 2 | FSMOロール、認証負荷、拠点別DCを確認 | 影響の大きいDCを把握する |
| 3 | システム状態バックアップ、スナップショット運用ルールを確認 | 復旧手段を事前に確保する |
| 4 | 1台または低リスクな拠点DCからKB5091575を適用 | 更新後の挙動を検証する |
| 5 | dcdiagとrepadminでAD正常性を確認 | 認証・レプリケーション異常を早期発見する |
| 6 | 残りのDCへ段階展開 | 障害範囲を限定しながら更新する |
| 7 | パッチ管理レポートとOSビルドを照合 | 未適用サーバーを残さない |
更新後は、少なくとも次の確認を行います。
dcdiag /e /c
repadmin /replsummary
repadmin /showreplさらに、以下の観点で監視を強めます。
- 管理者ログオンや一般ユーザーログオンが失敗していないか
- Kerberos認証やLDAP認証に遅延がないか
- SYSVOL、NETLOGON共有が見えるか
- DNS応答や動的登録に異常がないか
- 再起動後にLSASS関連のエラーが増えていないか
「OOB更新を入れたので完了」ではなく、更新後にADとして正常に機能しているかまで確認することが重要です。
BitLocker回復キー要求の既知の問題も事前に見る
KB5091575には、DC再起動ループ修正だけでなく、既知の問題としてBitLocker回復キーを求められる可能性も掲載されています。
Microsoftの説明では、OSドライブでBitLockerが有効、TPMプラットフォーム検証プロファイルに関するグループポリシーでPCR7が含まれている、msinfo32.exeでPCR7 Bindingが「Not Possible」と表示される、Windows UEFI CA 2023証明書が存在する、2023署名のWindows Boot Managerをまだ使用していない、といった条件がそろう一部環境で、初回再起動時にBitLocker回復キーが必要になる可能性があります。(マイクロソフトサポート)
実務では、次のようなサーバーを優先的に確認してください。
| 確認対象 | 確認内容 |
|---|---|
| BitLocker有効サーバー | OSドライブが暗号化されているか |
| グループポリシー | TPMプラットフォーム検証プロファイルを明示設定していないか |
| PCR7 Binding | msinfo32.exeで「Not Possible」になっていないか |
| 回復キー保管 | AD DS、Microsoft Entra ID、管理台帳などに回復キーが保管されているか |
| リモート拠点サーバー | 回復キー入力が必要になった場合に現地対応できるか |
特にリモート拠点や無人運用のサーバーでは、BitLocker回復画面で止まると遠隔復旧が難しくなります。更新前に回復キーの保管場所を確認し、必要に応じて保守時間帯や現地対応手段を用意してください。
Microsoftは回避策として、該当するグループポリシーを「未構成」にし、gpupdate /forceを実行したうえで、BitLocker保護機能を一度無効化・再有効化する手順を示しています。(マイクロソフトサポート)
例として、CドライブでBitLockerを使っている場合は、以下のような確認が有効です。
manage-bde -status C:
manage-bde -protectors -get C:ポリシー変更後にMicrosoftが示す流れに沿う場合は、環境の手順書に従ってBitLockerの保護機能を一時停止・再開します。本番サーバーでは、必ず回復キーの保管確認を済ませてから操作してください。
RDP警告表示の不具合は「小さな表示問題」と見なさない
2026年4月23日の変更履歴では、Remote Desktopに関する警告表示の既知の問題が追加されています。その後、4月27日に同項目の修正が行われています。(マイクロソフトサポート)
この問題は、RDPファイルを開く際に表示されるセキュリティ警告が、特定の表示条件で正しく表示されない可能性があるものです。Microsoftの説明では、複数モニターを使い、それぞれの表示倍率が異なる場合、警告ウィンドウの文字が重なったり、ボタンが一部隠れたりして、内容の確認や操作が難しくなる可能性があります。回避策として、すべてのモニターで同じ表示倍率を設定する方法が案内されています。(マイクロソフトサポート)
一見すると軽微なUI不具合に見えますが、管理者端末では注意が必要です。RDP警告は、接続先や要求される接続設定を確認するための重要な表示です。警告が読みづらい状態だと、管理者が内容を十分に確認せずに接続してしまう可能性があります。
実務上は、次の対応をおすすめします。
- 踏み台端末や管理者用VDIでは、複数モニターの表示倍率を統一する
- RDPファイルを配布している場合は、接続先と設定内容の確認ルールを明文化する
- 警告画面でボタンが押しづらい場合は、TabキーとSpaceキーで操作できることを周知する
- ヘルプデスクには「RDP接続できない」ではなく「警告表示が崩れる」事象として切り分けるよう共有する
RDPの警告表示は、フィッシング的な接続誘導や誤接続を避けるための防波堤です。表示不具合であっても、管理者操作の安全性に関わる問題として扱うべきです。
Windows Server 2025への意図しないアップグレード問題は運用設計を見直す材料になる
Windows Server 2022 known issues and notificationsでは、Windows Server 2022およびWindows Server 2019が予期せずWindows Server 2025へアップグレードされた問題も「解決済み」として掲載されています。
Microsoftの説明では、Windows Server 2025はWindows Server 2019およびWindows Server 2022に対して「任意」のアップグレードとして提供される想定でしたが、一部の環境ではサードパーティ製品を通じた更新管理により、自動的にアップグレードされたシナリオが観察されたとされています。また、機能更新プログラムのメタデータは、パッチ管理ツール側で「推奨」ではなく「任意」として解釈すべきと説明されています。(Microsoft Learn)
この問題から学ぶべき点は、Windows Server 2025へのアップグレードそのものの是非ではありません。重要なのは、サーバーOSの機能更新プログラムを、通常の月例更新と同じ自動承認ルールで扱わないことです。
確認すべき設定は次のとおりです。
| 確認項目 | 望ましい状態 |
|---|---|
| 機能更新プログラムの分類 | 自動承認ではなく、明示的な承認制にする |
| サードパーティ製パッチ管理ツール | Optional/Recommendedの解釈を確認する |
| サーバーOSアップグレード | OS更新とは別の変更管理プロセスに乗せる |
| 除外グループ | 本番サーバー、DC、基幹システムを不用意な機能更新から除外する |
| 検証環境 | Windows Server 2025移行テスト用の別リングを用意する |
Windows Server 2025は最新LTSCとして重要な選択肢ですが、移行は計画的に行うべきです。更新管理ツール側で「新しい更新があるから配る」という単純なルールにしている場合は、今回を機にサーバーOSの機能更新ポリシーを見直しましょう。
Secure Boot証明書更新も2026年の重要テーマ
今回のWindows Server 2022関連更新では、Secure Boot証明書の期限にも注意が必要です。KB5091575の通知では、多くのWindowsデバイスで使われるSecure Boot証明書が2026年6月以降に期限を迎え始めること、混乱を避けるために事前の確認と対応を推奨することが案内されています。(マイクロソフトサポート)
これは、2026年4月のDC再起動ループほど即時性の高い障害対応ではありません。しかし、物理サーバー、仮想化ホスト、クラウドVM、セキュアブートを有効にしたテンプレートイメージを管理している組織では、早めに棚卸しすべきテーマです。
確認の観点は次のとおりです。
- Secure Bootを有効にしているサーバーの一覧を作る
- 物理サーバー、Hyper-V、VMware、クラウドVMで検証対象を分ける
- ファームウェア、ブートローダー、セキュリティ製品の依存関係を確認する
- 月例更新の適用だけで十分か、追加手順が必要かを検証環境で確認する
- BitLocker、TPM、Secure Boot関連の変更を同じ変更管理で追跡する
Secure Boot関連の変更は、失敗すると「OSが起動しない」という重大事象につながる可能性があります。月例パッチの一部として軽く扱うのではなく、ブートチェーン全体の変更として管理するのが安全です。
パッチ管理担当者が今すぐ実施すべきチェックリスト
今回のWindows Server 2022 known issues and notificationsを踏まえると、管理者は次の順序で確認すると効率的です。
| 優先度 | チェック内容 | 完了条件 |
|---|---|---|
| 最優先 | Windows Server 2022のDCにKB5082142だけが適用されていないか | KB5091575またはKB5091576の適用状況を確認済み |
| 高 | 複数ドメインフォレスト、PAM利用環境の有無 | 該当環境のDCを優先展開対象に設定済み |
| 高 | OOB更新の配布経路 | Microsoft Update Catalog、WSUS、管理ツールへの取り込み方針を確認済み |
| 中 | BitLocker回復キーの保管 | 対象サーバーの回復キーを確認済み |
| 中 | RDP警告表示 | 管理端末の表示倍率とRDP運用を確認済み |
| 中 | Windows Server 2025機能更新の承認ルール | 任意アップグレードを自動展開しない設定を確認済み |
| 計画対応 | Secure Boot証明書更新 | 検証対象とスケジュールを決定済み |
特にグローバル環境では、Microsoftの公開時刻がPT表記である点にも注意してください。変更管理の記録では、PT、UTC、JSTを混在させず、社内標準のタイムゾーンに変換して記録すると、後から障害時系列を追いやすくなります。
よくある疑問
「解決済み」と表示されていれば何もしなくてよい？
いいえ。Microsoftのページで「解決済み」と表示されているのは、修正策が提供されたことを意味します。対象サーバーに修正プログラムが実際に適用されたかどうかは、各組織の更新管理状況に依存します。
特にKB5091575は、Microsoft Update Catalogからの取得が案内されています。WSUSやサードパーティ製ツールを使っている場合は、自動的に全サーバーへ行き渡ったと考えず、配布・承認・適用完了のレポートを確認してください。
KB5082142をアンインストールすべき？
基本的には、修正用のOOB更新プログラムを適用する方向で検討します。セキュリティ更新プログラムのアンインストールは、脆弱性対策を巻き戻すことになり、別のリスクを生みます。
すでにDCが再起動ループに入っている、認証基盤が停止しているなどの緊急時は、Microsoftサポートや組織の障害対応手順に従って判断してください。平常時の対応としては、KB5091575またはKB5091576の適用状況を確認するのが優先です。
すべてのWindows Server 2022が影響を受ける？
DC再起動ループ問題については、条件が限定されています。Microsoftは、複数ドメインフォレストでPAMを使用している環境のDCにおいてLSASSクラッシュが発生する可能性を説明しています。クライアントPCは対象外です。(Microsoft Learn)
ただし、条件に完全一致しないからといって、更新確認を省略するべきではありません。Windows Server 2022を広く運用している組織では、DC、認証基盤、BitLocker有効サーバー、RDP管理端末を優先的に確認するのが現実的です。
ホットパッチ環境なら再起動は不要？
Windows Server 2022 Datacenter: Azure EditionでHotpatch対象のKB5091576を使う場合、Microsoftは再起動なしでインストール・有効化されると説明しています。ただし、対象はHotpatchに登録され、条件を満たすデバイスです。標準のWindows Server 2022環境ではKB5091575の扱いを確認してください。(マイクロソフトサポート)
Windows Server 2025へのアップグレードは避けるべき？
避けるべきなのは、計画なしに本番サーバーがアップグレードされることです。Windows Server 2025自体は最新のLTSCリリースとして検討対象になりますが、DC、ファイルサーバー、基幹システム、アプリケーションサーバーでは互換性検証が必要です。
パッチ管理上は、機能更新プログラムを通常の累積更新と同じ自動承認ルールに含めないことが重要です。
まとめ: まずDC、次にBitLockerと更新管理ルールを確認する
2026年4月更新のWindows Server 2022 known issues and notificationsで最も重要なのは、KB5082142適用後のドメインコントローラー再起動ループ問題がOOB更新で解決された点です。Windows Server 2022のDCを運用している組織は、KB5091575またはKB5091576の適用状況を最優先で確認してください。
次に、BitLocker回復キー要求の可能性、RDP警告表示の不具合、Windows Server 2025への意図しないアップグレードを防ぐための承認ルール、Secure Boot証明書更新の準備を進めます。
実務では、次の3つを今日の作業として始めるのが現実的です。
- Windows Server 2022のDC一覧を出し、KB5082142とKB5091575/KB5091576の適用状況を照合する
- BitLocker有効サーバーの回復キー保管状況とPCR7関連ポリシーを確認する
- パッチ管理ツールで、Windows Serverの機能更新プログラムが自動展開されない設定になっているか確認する
今回の更新は、単なる月例パッチ確認ではなく、認証基盤、暗号化、リモート管理、OSアップグレード管理をまとめて見直すきっかけになります。Windows Server 2022を安定運用するために、既知の問題の「状態」だけでなく、自社環境での「適用完了」と「運用上の影響」まで確認しましょう。
コメント