Windows Server 2019 で累積更新プログラムを適用しようとした際、「この更新プログラムはお使いのコンピューターには適用できません（Not applicable）」と表示されて先に進めない――特に 2025 年 6 月の累積更新（KB5060531）が当たらない、という相談が増えています。本記事では、この現象が起こる代表的な原因と、サーバーを最新の準拠状態まで戻すための具体的な手順を、コマンド付きで分かりやすく解説します。
現象の概要と前提環境の整理
今回取り上げるケースは、次のような状況を想定しています。
- OS：Windows Server 2019 Datacenter（LTSC）
- OS ビルド：17763.xxx 系（Windows 10 Version 1809 と同一系列）
- 2025 年 6 月の累積更新（例：KB5060531）をインストールしようとすると「適用対象外（Not applicable）」になる
- 直近 2～3 か月分の累積更新も同様に適用できていない
質問文に「Windows Server 2019 21H2」と書かれていることがありますが、21H2 というバージョン表記があるのは主に Windows Server 2022 であり、Windows Server 2019 は バージョン 1809（ビルド 17763）固定 です。
そのため、まずは OS のビルド情報を必ず確認し、「本当に Windows Server 2019（ビルド 17763 系）」なのかをはっきりさせることが重要です。
OS バージョンの確認方法
GUI から確認する場合：
- Win + R →
winverと入力 → 表示されるバージョンと OS ビルドを確認
コマンドから確認する場合（管理者権限の PowerShell またはコマンドプロンプト）：
systeminfo | findstr /C:"OS 名" /C:"OS バージョン"
よくある混乱を整理するために、簡単な対応表を用意しておきます。
| 製品名 | マーケティング バージョン | OS ビルドの例 | 備考 |
|---|---|---|---|
| Windows Server 2019 | Version 1809 | 17763.xxxx | LTSC。この記事の対象 |
| Windows Server 2022 | 21H2 / 23H2 など | 20348.xxxx | ビルド番号が 20348 系 |
ここで OS ビルドが 17763 系であること を確認できたら、以降の手順に進みます。
なぜ Windows Server 2019 の累積更新が「適用不可」になるのか
「適用対象外（Not applicable）」には、単純な「最新だから当たらない」以外にもいくつか典型的なパターンがあります。特に Windows Server 2019 では、以下の原因が多くの環境で繰り返し問題になっています。
サービス スタック更新プログラム（SSU）の未適用
Windows の累積更新（LCU）は、内部で更新を適用するための土台となる「サービス スタック更新プログラム（Servicing Stack Update：SSU）」を前提としています。
- Windows Server 2019 の場合、KB5005112（2021 年 8 月 10 日公開 SSU）が重要なベース要件として扱われるケースが多い
- この SSU が入っていないサーバーでは、新しい累積更新が「適用対象外」と判定されることがあります
2021 年以降、Microsoft は「SSU と LCU を一つのパッケージに統合」する方式へ移行しましたが、最低限の SSU（例：KB5005112）すら欠けていると、その統合 LCU 自体が検出されなかったり、Not applicable と扱われてしまうことがある点に注意が必要です。
更新コンポーネントの不整合・キャッシュ破損
Windows Update のコンポーネントやキャッシュが壊れている場合も、「この更新は適用できません」と誤判定されることがあります。
C:\Windows\SoftwareDistribution内のキャッシュ破損C:\Windows\System32\catroot2の未整合- 途中まで適用された更新が失敗したまま「保留」状態になっている
この状態では、本来適用可能な累積更新であっても検出に失敗し、「適用不可」と表示されることがあります。
その他、よくある要因
上記 2 つ以外にも、実務でよく遭遇する原因を挙げておきます。
| 要因 | 概要 | 現象の出方 |
|---|---|---|
| より新しい CU が既に適用済み | 累積更新は 包含（supersede）関係 を持ち、新しい CU が古い CU を丸ごと含む | 古い CU を手動インストールしようとすると Not applicable |
| OS / エディション / アーキテクチャの不一致 | 例：Server 2019 ではなく Server 2022 用のパッケージ、x86 用パッケージなど | ダウンロードはできるがインストール段階で適用不可 |
| 再起動保留（Pending restart） | 過去の更新やロールアップが保留状態のまま | 新しい更新がブロックされたり、インストール中にロールバック |
| 言語パックの後入れ | OS インストール後に言語パックを追加し、更新との依存関係が崩れる | 一部の更新だけ適用に失敗 / 適用不可 |
| WSUS / SCCM の承認・配布設定 | 承認状態やターゲット グループが誤っている、または更新が上書きされている | クライアント側からは「更新はありません」に見える |
このように、Not applicable は単なる「最新だから不要」という意味に限らず、前提 SSU 不足やコンポーネント障害のサイン になっていることが多い点を押さえておきましょう。
実際の復旧フロー：優先順位順に対応する
ここからは、実運用でおすすめできる「段階的な復旧フロー」を紹介します。トラブル時に上から順に試していけば、ほとんどのケースで最新状態まで戻せます。
ステップ 1：現在の状態を棚卸しする
いきなり更新を当て始める前に、まずは現在の状態を簡単に棚卸しします。
systeminfo | findstr /C:"OS 名" /C:"OS バージョン"
wmic os get buildnumber,caption,osarchitecture
さらに、最近適用された更新を確認します（管理者 PowerShell）。
Get-HotFix | Sort-Object InstalledOn
ここで、2025 年 6 月の累積更新 KB5060531（OS ビルド 17763.7434）や、それ以降の更新が入っていないことを確認しておきます。
ステップ 2：前提 SSU（KB5005112）の有無を確認する
SSU は Get-HotFix に出ないことが多いため、DISM でパッケージ一覧を確認 するのが確実です。
DISM /Online /Get-Packages | findstr /I "Servicing Stack 17763"
出力の中に、以下のようなパッケージ名が含まれているか確認します。
Package_for_KB5005112~31bf3856ad364e35~amd64~~17763.XXXX.xxxxのような表記
もし KB5005112 が見当たらない 場合は、まずこの SSU を適用します。
KB5005112 の入手と適用手順
- 別 PC から Microsoft Update カタログ で
KB5005112を検索し、「Windows Server 2019 for x64-based Systems」向けのパッケージをダウンロード - 対象サーバーに .msu をコピー
- 管理者権限で次のように実行：
wusa.exe Windows10.0-KB5005112-x64-2019.msu /quiet /norestart
その後、必要なら再起動を行い、再度 DISM で SSU が入っていることを確認します。
この時点で、Windows Update からあらためて更新のチェックを行い、2025 年 6 月の累積更新 KB5060531 や、それ以降の更新が検出されるか確認してください。
ステップ 3：Windows Update コンポーネントをリセットする
SSU を適用しても現象が変わらない場合は、Windows Update 関連コンポーネントのリセットを行います。これはトラブルシューティングでは定番の手順です。
サービス停止とキャッシュのリネーム
管理者権限のコマンド プロンプトで次を実行します。
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver
実行のポイント：
SoftwareDistributionとcatroot2はリネームして退避するだけで、再起動やサービス起動時に自動で再生成されます。- WSUS 管理環境であっても、クライアント側キャッシュの破損はこの手順でよく解決します。
手順完了後、GUI から「更新プログラムのチェック」 を再実行し、KB5060531 を含む更新が検出・適用できるかを確認します。
ステップ 4：MSU を展開して SSU → CU の順で手動適用する
「自動更新だとどうしても通らない」「WSUS のルールの影響を切り離して検証したい」といった場合は、MSU を展開して DISM で直接パッケージを当てる 方法が有効です。
1. 累積更新（CU）の .msu をダウンロード
Microsoft Update カタログで KB5060531 を検索し、Windows Server 2019 for x64-based Systems 向けの「2025-06 Cumulative Update」をダウンロードします。
2. 作業用フォルダーを作成
mkdir C:\Temp\KB5060531
3. .msu を展開する
以下は例です（実際のファイル名に合わせて変更してください）。
expand -F:* C:\Temp\Windows10.0-KB5060531-x64.msu C:\Temp\KB5060531
展開後、フォルダー内には次のようなファイルが生成されます。
SSU-17763.XXXX-x64.cab（サービス スタック更新）Windows10.0-KB5060531-x64.cab（累積更新本体）- その他メタデータ ファイル
4. SSU → CU の順に DISM /Add-Package で適用
管理者権限のコマンド プロンプトまたは PowerShell で、次のように実行します。
dism /online /add-package /packagepath:C:\Temp\KB5060531\SSU-17763.XXXX-x64.cab
dism /online /add-package /packagepath:C:\Temp\KB5060531\Windows10.0-KB5060531-x64.cab
SSU と CU を分けて適用することで、「SSU 不足による適用不可」と「CU 自体の問題」を切り分けやすくなります。
適用完了後は、必要に応じて再起動を行い、ビルド番号が 17763.7434 以降 に上がっていることを確認します。
ステップ 5：DISM と SFC でシステムの健全性を確認する
更新に失敗しているサーバーでは、コンポーネント ストアや OS ファイルが一部壊れているケースも少なくありません。更新作業の前後、どちらかのタイミングで次のコマンドを実行することをおすすめします。
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
DISM /RestoreHealth はコンポーネント ストアを修復し、sfc /scannow はシステム ファイルの整合性チェックと修復を行います。特に、以前の更新途中で電源断があったり、ストレージの問題が疑われる場合は必ず実行しておきたいコマンドです。
詳細なログは次の場所に出力されます。
C:\Windows\Logs\CBS\CBS.logC:\Windows\Logs\DISM\dism.log
WSUS / SCCM 環境での追加チェックポイント
企業環境では、多くの場合 Windows Update ではなく WSUS や Configuration Manager（SCCM）で更新を配布 しています。この場合、「クライアント側をいくらさわっても更新が出てこない」という事態が起こりがちです。
よくある WSUS 側の落とし穴
- 該当 KB が承認されていない
- KB5060531 が「未承認」のまま、あるいはテスト用グループのみに承認されている
- より新しい累積更新に置き換えられている
- 累積更新は毎月「置換関係」があり、新しい KB が古い KB を包含します
- 「最新のみ承認」ポリシーにしている場合、古い月の CU はそもそも配布されない
- ターゲット グループの誤り
- 対象サーバーが想定外のコンピューター グループに属している
- あるいはグループを作成しただけで更新を承認していない
- クライアント側ポリシーとの齟齬
- グループ ポリシーで「社内 WSUS を使用」としながら、手動でインターネット更新を試みている
- 結果として「更新はありません」と見えてしまう
特に、2025 年以降は Windows Server 2019 に対する更新もセキュリティ上の重要度が増しており、SMB や WSUS 自体の脆弱性が実際に悪用された事例も報告されています。こうしたセキュリティ更新を取りこぼさないためにも、配布ルールと承認状態の見直しは必須です。
事後確認：サーバーが「準拠状態」に戻ったかどうかを検証する
更新が一通り適用できたら、以下の観点で「準拠状態」かどうかを確認しましょう。
確認 1：OS ビルド番号
winver または systeminfo で OS ビルドを確認し、2025 年 6 月の累積更新 KB5060531（OS ビルド 17763.7434）以降になっていることを確認します。
確認 2：インストール済み更新の一覧
PowerShell で次を実行します。
Get-HotFix | Sort-Object InstalledOn
DISM /Online /Get-Packages | findstr /I "Package Identity Servicing Stack"
出力のポイント：
- KB5060531 など直近の累積更新が
Get-HotFixに表示されている - DISM の結果に KB5005112 を含む SSU パッケージが表示されている
確認 3：WSUS / 管理コンソール上のステータス
WSUS または Configuration Manager を使用している場合、管理コンソール側でも対象サーバーの状態を確認します。
- 該当サーバーが「インストール済み」または「準拠」と表示されていること
- 保留中の重要なセキュリティ更新が残っていないこと
Microsoft の公式「Windows 10 / Windows Server 2019 更新履歴」ページと照らし合わせて、最新のビルドと KB 番号を確認しておくとより確実です。
確認チェック表（サマリー）
| 確認項目 | コマンド / 画面 | 正常状態の例 |
|---|---|---|
| OS ビルド | winver / systeminfo | OS ビルド 17763.7434 以上 |
| 最新 CU | Get-HotFix | KB5060531 など最新 CU が表示される |
| SSU | DISM /Online /Get-Packages | KB5005112 を含む Servicing Stack パッケージが存在 |
| WSUS 準拠状況 | WSUS / SCCM コンソール | 「準拠」「インストール済み」と表示 |
| システム健全性 | DISM /RestoreHealth, sfc /scannow | エラーなし（要再起動の警告がない） |
よくある見落としポイント（チェックリスト）
最後に、Windows Server 2019 で累積更新が「適用不可」と表示されたとき、必ず確認したいポイントをチェックリスト形式でまとめます。
- □ OS が Windows Server 2019（ビルド 17763 系） であることを再確認したか
- □ KB5005112（SSU） が DISM のパッケージ一覧に存在するか
- □ 保留中の再起動（Pending restart）が残っていないか
- □ 適用しようとしているパッケージが OS / エディション / アーキテクチャ（x64）に一致しているか
- □ 言語パックの後入れがないか（ある場合は、言語関連の更新も含めて再適用が必要な場合あり）
- □ WSUS / SCCM の承認状態・置換関係・配布グループが正しいか
- □ 上記を確認してもダメな場合、Windows Update コンポーネントのリセット と MSU 展開 → SSU → CU の DISM 手動適用 を実施したか
運用上のベストプラクティスと再発防止のヒント
一度「適用不可」問題にハマると、毎月のパッチ適用作業が一気に重くなってしまいます。ここからは、同じトラブルを繰り返さないための運用上のコツをいくつか紹介します。
ステージング環境で毎月の CU を先行検証する
2025 年 6 月の KB5060531 についても、一部の管理者から「適用後に SFTP 接続や cd コマンドの挙動に問題が出た」との報告があり、ロールバックしたケースも見られました。
このような「更新そのものが不具合を持っている」ケースもあり得るため、本番環境に適用する前に、次のような運用を推奨します。
- 本番と同一構成のテストサーバー（仮想マシンでも可）を用意
- 毎月 Patch Tuesday 直後にステージングへ CU を適用し、アプリケーション動作やログイン周りを確認
- 必要に応じてスナップショットやバックアップからのロールバック手順もリハーサルしておく
SSU と CU の関係を運用ドキュメントに明記する
運用チーム内で担当者が変わると、SSU の存在自体が忘れられてしまい、「なぜか一部のサーバーだけ毎月更新がこける」という状態になりがちです。
手順書の中に、最低限次のような情報を明記しておくと、トラブル時の切り分けが格段に早くなります。
- 「Windows Server 2019 は、2021 年 8 月の KB5005112 以降の SSU が前提になっている」
- 「CU が Not applicable の場合は、まず SSU の有無を確認する」
- 「SSU → CU の順で DISM /Add-Package すれば多くの問題は解決する」
ログ収集とナレッジ蓄積を仕組み化する
毎回手作業で CBS.log や DISM.log を見に行くのは手間ですが、更新トラブルのパターンは意外なほど繰り返されます。社内 Wiki やナレッジベースに、以下のようなテンプレートを作っておくと便利です。
- 障害発生日・対象サーバー名
- 適用しようとした KB 番号（例：KB5060531）
- エラーコード（0x800f0818 など）
- 最後に成功した累積更新 KB
- 対応手順（SSU 適用・コンポーネント リセット・DISM / SFC の結果など）
- 最終的な OS ビルド番号
こうした記録を残しておくと、次に似た障害が発生した際、「あ、あのときと同じパターンだ」とすぐ気付けるようになります。
まとめ：まずは SSU（KB5005112）を疑い、それでもダメならコンポーネントと手動適用を試す
Windows Server 2019 の累積更新が「適用不可（Not applicable）」になる原因の中で、もっとも頻度が高いのは サービス スタック更新プログラム（SSU）の未適用 です。特に 2021 年 8 月公開の KB5005112 は、多くの新しい累積更新が前提としている重要な SSU であり、これが欠けていると 2025 年 6 月の KB5060531 を含む最新 CU が適用できないケースが少なくありません。
本記事の内容を簡単にまとめると、次のような流れになります。
- OS ビルドが Windows Server 2019（17763 系） であることを確認する
- DISM /Online /Get-Packages で KB5005112（SSU）の有無を確認し、未適用なら先に入れる
- Windows Update コンポーネント（SoftwareDistribution / catroot2）をリセットする
- それでもダメなら、MSU を展開 → SSU → CU の順で DISM /Add-Package で手動適用する
- 最後に DISM /RestoreHealth と sfc /scannow を実行し、OS の健全性を確認する
- WSUS / SCCM 環境では、承認状態・置換関係・ターゲット グループの設定も再確認する
この一連の手順を踏めば、ほとんどの Windows Server 2019 環境で「適用不可」状態から脱出し、サーバーを最新のセキュリティ更新を適用した「準拠状態」に戻すことができます。パッチ適用はセキュリティ事故から組織を守る最後の砦でもあるため、ぜひ自社環境向けに本記事の手順をカスタマイズし、「トラブルシューティング用の標準手順書」として整備しておくことをおすすめします。
コメント