Windows Server 2016（Version 1607 / OS build 10.0.14393.1770）をWSUSで管理しているのに、最新の累積更新プログラム（CU）が「不要（Not needed）」と判定されて適用できない――さらに手動インストールでも「互換性がない」で失敗する。多くの場合、原因はServicing Stack Update（SSU）の未適用/古さです。SSU→CUの順で入れる手順と、WSUS表示が追随しないときの現場向け切り分けをまとめます。
症状：WSUSでは「不要（Not needed）」、手動では「互換性がない」
対象は Windows Server 2016（Version 1607）、かつ OS build が 10.0.14393.1770 など比較的古い状態で止まっているケースです。WSUS（社内の更新サーバー）配下で運用しているにもかかわらず、最新のCUが配信されなかったり、配信されていても「不要」と判定されてインストールされないことがあります。
| 見えている現象 | 起きる場所 | よくある表示・メッセージ | 意味（推測） |
|---|---|---|---|
| 最新CUが当たらない | WSUSコンソール | 対象サーバーが Not needed / 不要 | クライアント側の適用判定が「適用対象外」と評価している可能性 |
| 手動インストールに失敗 | スタンドアロン（.msu / .cab） | 「この更新プログラムはこのコンピューターには適用できません」 「not compatible / 互換性がない」 | 前提条件不足（SSU不足など）や、パッケージ選択ミス（バージョン違い/アーキ違い） |
| 更新確認しても変化なし | サーバー側のWindows Update | 「最新です」なのに脆弱性スキャンでは未適用扱い | WSUSの検出・評価が止まっている、またはSSU不足で適用判定が誤る |
ポイントは、「WSUSが悪い」というより、クライアント（Windows Updateの適用判定）が古いSSUのままで、最新CUを“対象外”と評価してしまうことが多い点です。
原因：Servicing Stack Update（SSU）が古いとCUが適用対象外になる
SSU（Servicing Stack Update）は、Windowsの更新処理そのもの（コンポーネントの追加・置換・整合性チェックなど）を担当する「サービススタック」を更新するパッチです。Windows Server 2016 では時期によって、CUの適用にSSUが前提になることがあり、SSUが古い（または未適用）だと、次のような不整合が起きます。
- WSUSで CU が「不要」に見える（＝適用判定が偽になる）
- 手動インストールでも「この更新は適用できない」と弾かれる
- 更新チェーンが途切れて「どこから手を付けても進めない」状態になりやすい
| 項目 | SSU（サービス スタック更新） | CU（累積更新プログラム / LCU） |
|---|---|---|
| 役割 | 更新処理の土台（更新の適用エンジン）を更新 | OSの不具合修正・機能修正・セキュリティ修正をまとめて提供 |
| 適用順 | 先に適用（CUの前提になることがある） | SSUの後に適用 |
| WSUSでの扱い | 「更新（Updates）」分類に入ることが多く、 自動承認ルールから漏れやすい | 「セキュリティ更新」「重要な更新」に含まれ、 承認されやすい |
| 失敗時の症状 | 後続のCUが「不要」「互換性がない」扱いになる | 適用対象外・ロールバック・再起動ループなど |
つまり、今回のように OS build 14393.1770 で更新が止まっている場合、最初に疑うべきは SSUの更新不足です。最新CUを入れようとして失敗するのは結果であり、根本原因は「更新の土台」が古いことにあります。
事前確認：OSバージョンと更新状況を把握する
作業を始める前に、対象が本当に Windows Server 2016（1607）であること、そして現在どのKBが入っているかを確認します。誤って別バージョンのパッケージを入れようとすると、同じように「互換性がない」になります。
| 確認したいこと | GUIでの確認 | コマンド例 | 見るポイント |
|---|---|---|---|
| OSのバージョン/ビルド | winver / 設定 > システム > バージョン情報 | winver systeminfo | findstr /B /C:"OS Name" /C:"OS Version" | Version 1607、build 14393.x であること |
| インストール済みKB | 更新履歴 / インストールされた更新 | wmic qfe list brief /format:table PowerShell: Get-HotFix | Sort-Object InstalledOn -Descending | Select -First 20 | SSUのKBが入っているか、最終更新日が極端に古くないか |
| 再起動保留の有無 | 更新画面の表示 | PowerShell: Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired" | 保留があると適用判定がズレることがある |
「SSUが入っているか分からない」場合でも、次の章の手順どおりに進めればOKです。重要なのは SSU→CU の順序です。
解決の王道：最新SSUを先に入れてから、最新CUを入れる
結論はシンプルです。先に最新のSSU（サービススタック更新）を適用し、その後に最新のCU（累積更新）を適用します。WSUS運用でも、まずはこの順で「土台を整える」と更新が動き出すことが多いです。
| 手順 | やること | 具体例 | 成功の目安 |
|---|---|---|---|
| 準備 | バックアップ/スナップショット、メンテ時間確保 | VMならスナップショット、物理ならシステム状態バックアップなど | ロールバック可能な状態 |
| SSU取得 | Microsoft Update Catalog から対象のSSUをダウンロード | 例：KB4565912（SSUの例） | .msu が入手できる |
| SSU適用 | SSUを先にインストール（必要なら再起動） | wusa.exe "Windows10.0-KB4565912-x64.msu" /quiet /norestart | インストール済みKBにSSUが載る |
| CU取得 | 同様にCatalogから対象のCUをダウンロード | 例：KB4571694（CUの例） | .msu が入手できる |
| CU適用 | CUをインストール（ほぼ再起動が必要） | wusa.exe "Windows10.0-KB4571694-x64.msu" /quiet /norestart | OS build が更新される |
| 再評価 | WSUS/クライアントの再検出を実行 | Windows Updateの「更新プログラムの確認」など | WSUSの状態が更新される |
上のKB番号（KB4565912 / KB4571694）はあくまで例です。重要なのは「その時点での最新SSU」と「その時点での最新CU」を選ぶことです。Catalogで検索するときは、次の観点で“取り違え”を防げます。
- 対象が Windows Server 2016 / Version 1607 / build 14393 系であること
- x64（ほとんどのサーバーはx64）を選ぶ
- 「Windows 10, version 1607 and Windows Server 2016」と記載がある更新は対象になることが多い
- 「Preview（プレビュー）」は原則避け、通常の累積更新（Security/Quality）を選ぶ
SSUを先に入れるとなぜ直るのか
SSUは更新処理の内部部品を更新するため、古いSSUのままだと「新しい形式・新しい前提条件」のCUを正しく処理できず、適用判定が崩れます。SSUを更新すると、
- CUの前提条件チェックが正しく動く
- WSUS/Windows Updateが「適用対象」と評価できる
- 手動インストールでも「互換性がない」が解消しやすい
という流れで復旧します。
実際に起きがち：SSU→CUで手動適用は成功、でもWSUSでは「不要」のまま
現場では、SSUを入れた後にスタンドアロン インストーラーでCUを手動適用できるようになったのに、WSUSコンソール上は引き続き「不要」のまま、ということが起きます。ここで焦って「まだ当たっていない」と二重適用を試みると、逆にメンテ時間を溶かします。
このズレは、ざっくり言うと次のどちらかです。
- サーバー側の検出/報告が追いついていない（スキャン結果がWSUSへ送られていない、または送信待ち）
- WSUS側の表示が更新されていない（コンソールの集計タイミング、同期/承認の状態、クリーンアップ不足など）
まずは「OS buildが上がっている」「インストール済み更新にCUが載っている」ことをサーバー側で確認しましょう。適用済みなら、WSUS表示は遅れてついてくることが多いです。
WSUSが「不要」のままのときの切り分け（サーバー側）
基本：再起動と再検出で“評価をやり直す”
SSUやCUの適用直後は、コンポーネントストアの整合性や保留処理が残っていることがあります。まずは再起動を優先し、そのうえで更新の検出（スキャン）を走らせます。
| やりたいこと | 手段 | コマンド例 | 補足 |
|---|---|---|---|
| Windows Updateの再検出 | GUIで更新確認 | （GUI操作） | WSUS配下でも「確認」はトリガになります |
| 検出・報告のトリガ | コマンドで実行 | wuauclt /detectnow wuauclt /reportnow | 即時反映されないことがあります（内部キュー処理） |
| サービス再起動 | Windows Update関連サービスを再起動 | net stop wuauserv net start wuauserv | 更新中のタスクがある場合は注意 |
GUIが使いづらいサーバー（Server Coreなど）では、Windows Updateの状態を見ながら、メンテナンスウィンドウ内で「再起動→検出→報告」までをセットにすると安定します。
定番：Windows Updateコンポーネントのリセット
「検出しても何も変わらない」「WSUSに報告されない」場合、更新キャッシュや署名カタログが壊れていることがあります。次のリセットは、WSUS運用でも有効な定番手順です。
net stop wuauserv
net stop bits
net stop cryptsvc
ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old
net start cryptsvc
net start bits
net start wuauservリセット後は再起動し、再度「更新プログラムの確認」を実行します。SSU→CUが適用済みでも、報告だけが詰まっているケースはこれで通ることがあります。
WSUSの指定（イントラネット更新サーバー）が正しいか確認
グループポリシーやローカル設定の揺れで、サーバーがWSUSではなくMicrosoft Updateへ向いていたり、逆に古いWSUS URLを参照し続けていることがあります。次のレジストリ値が期待通りか確認します。
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUStatusServer想定外のURLになっている場合、GPOの適用状況（OU・セキュリティフィルタ・WMIフィルタ）も含めて見直します。
WSUSが「不要」のままのときの切り分け（WSUS側）
サーバー側でSSU/CUが入っているのに、WSUSがいつまでも「不要」表示のままなら、WSUS側の同期・承認・メタデータの問題も疑います。特に、SSUが自動承認に含まれていない運用だと、同じ事故が繰り返されます。
| 確認項目 | WSUSでの場所 | 見るポイント | 現場あるある |
|---|---|---|---|
| 製品（Products）の選択 | オプション > 製品と分類 | Windows Server 2016、または 「Windows 10, version 1607 and Windows Server 2016」相当が含まれるか | 製品選択から漏れていて、そもそもCUが同期されていない |
| 分類（Classifications）の選択 | オプション > 製品と分類 | CUだけでなく、SSUが入る分類（更新/重要な更新など）も同期対象か | 「セキュリティ更新」だけ同期してSSUが欠ける |
| 同期状態 | 同期 > 最終同期結果 | 失敗が続いていないか、更新数が異常に少なくないか | プロキシ/証明書/容量不足で同期失敗している |
| 承認（Approve） | 更新プログラム | SSUが未承認のままになっていないか | CUは承認済みでもSSUが未承認で詰む |
| 置き換え（Supersedence）/期限切れ | 更新プログラムの詳細 | SSU/CUが「置き換え済み」や「期限切れ」扱いになっていないか | メンテ不足でメタデータが肥大化し評価が遅い |
「WSUSの画面上で不要のまま」という現象は、サーバー側のスキャンが古いまま残っているだけのこともあります。WSUSコンソールの「最終状態レポート時刻」や、クライアント側の WindowsUpdate.log（取得方法はOSにより異なる） を合わせて見ると、どこで詰まっているか判断しやすくなります。
それでも「互換性がない」が続く場合に疑うこと
SSUを入れてもCUが弾かれる場合、前提条件以外の要因が混ざっていることがあります。次のチェックで “取り違え” と “環境要因” を潰します。
| 疑うポイント | 症状 | 対処 |
|---|---|---|
| 更新パッケージの取り違え | 常に「この更新は適用できません」 | OSが Server 2016（1607） 用か、x64 か、Previewでないか再確認 |
| SSU自体が入っていない/別SSUが必要 | 最新SSUが先に弾かれる | Catalogの詳細で前提条件を確認し、適用可能なSSUから段階的に入れる |
| 再起動保留や更新の途中状態 | 適用に失敗→再起動で変化 | 保留を解消（再起動）、不要なメンテタスク停止、ディスク容量確認 |
| コンポーネントストア破損 | 更新がロールバックする、エラーが揺れる | DISM /Online /Cleanup-Image /RestoreHealth sfc /scannowをメンテ時間で実施 |
「互換性がない」は便利な一言ですが、実際は前提条件不足とパッケージ選択ミスが大半です。SSU→CUの順を守りつつ、OSバージョン（1607）とKBの対象表記を丁寧に合わせるのが近道です。
運用のコツ：SSUを“先に承認・先に展開”するルールを作る
今回のトラブルは、個別に直して終わりにすると再発します。WSUS運用でSSUが抜けるのは珍しくありません。特に次のような環境は要注意です。
- 「セキュリティ更新だけ自動承認」している
- 検証用のリング（テスト→本番）がなく、承認が属人的
- サーバーの再起動を嫌って更新が先送りになりがち
おすすめは、SSUを先行展開する“前段リング”を作ることです。例えば、テストサーバー群にSSUだけ先に適用し、問題がなければ本番へSSU、その後CUという流れにすると、今回のような「CUが不要扱いで詰む」リスクを減らせます。
| タイミング | やること | 対象 | 狙い |
|---|---|---|---|
| パッチ公開後（すぐ） | SSUを同期・承認 | テストグループ | 前提条件を先に整備 |
| 数日〜1週間後 | CUを承認 | テストグループ | 不具合検知 |
| 検証OK後 | SSU→CUの順で本番展開 | 本番グループ | 安全に最新セキュリティへ追随 |
まとめ：更新できないときは“SSUから疑う”のが最短ルート
Windows Server 2016（1607 / build 14393系）で、WSUSが最新CUを「不要」と判定したり、手動インストールが「互換性がない」で失敗する場合、まずはSSU（Servicing Stack Update）を最新にするのが鉄板です。SSU→CUの順で適用し、再起動と再検出で評価をやり直せば、最新のセキュリティ更新まで追いつける可能性が高まります。
それでもWSUS表示が追随しないときは、サーバー側のスキャン/報告の詰まりと、WSUS側の同期・分類・承認漏れを順に切り分けてください。SSUは“地味”ですが、更新運用の土台です。ここを押さえるだけで、更新トラブルの大半はぐっと減ります。
コメント