Windows Server 2022（21H2）でWSUS承認済みのセキュリティ更新が降ってこず、WSUS上では「適用対象外（Not Applicable）」になる場合の原因と切り分け手順を、現場で再現しやすい順に整理します。
起きていること：WSUSは承認済みなのに、端末は「最新の状態」
この現象は、WSUS運用でかなり頻繁に遭遇します。ポイントは、WSUSで「承認（Approved）」しただけでは、端末に更新が必ず配布されるわけではないという点です。更新プログラムは、端末側（Windows Update Agent）が「この端末に必要で適用可能」と判定したものだけが候補になります。
つまりWSUSの表示で「Approved to install」でも、端末が条件を満たしていなければWSUSコンソール上の端末状態はNot Applicable（適用対象外）になり得ます。これは「配信エラー」というより、適用判定の不一致であることが多いです。
まずは結論：最短で当たりやすい確認順
| 優先 | 確認ポイント | なぜ効くか | すぐやること |
|---|---|---|---|
| 高 | 端末のOS実体（エディション/ビルド/更新レベル） | 対象OS/ビルドが違うと「Not Applicable」になりやすい | winver と systeminfo でビルドを確定 |
| 高 | WSUSの「製品」と「分類」 | 「それっぽい設定」でもServer 2022だけ漏れることがある | 製品：Windows Server 2022、分類：Security/Critical/Update Rollups |
| 高 | 対象KBが置き換え済み（Superseded）になっていないか | LCUは新しいKBが古いKBを上書きし、古いKBは不要扱いになりやすい | WSUSの更新詳細で「置き換え」関係を確認 |
| 中 | 前提更新（SSU/更新レベル不足） | 更新の土台が古いと後続LCUが「適用対象外」判定になることがある | 最新SSU/LCU（または統合LCU）を手動適用して土台を揃える |
| 中 | 端末側の更新コンポーネント破損・キャッシュ不整合 | 検出結果が壊れると「最新の状態」でも実際は未適用になり得る | SoftwareDistributionリセット→再スキャン→再報告 |
| 低 | WSUSの同期/DB肥大化/メタデータ不整合 | 置換更新の溜まりや同期不整合で判定が崩れることがある | Server Cleanup Wizard、wsusutil reset、必要ならDBメンテ |
「Not Applicable（適用対象外）」の意味を正しく捉える
WSUSで表示される「Not Applicable」は、ざっくり言うと「端末の条件では、その更新は当てる必要がない（または当てられない）」という意味です。代表的には次のような理由があります。
| 代表パターン | 起こり方 | 見分けるコツ | 対処の方向性 |
|---|---|---|---|
| 対象OS/エディションが違う | Server 2022だと思っていたが、実際は別ビルド/別SKU | winver とレジストリで「20348.x」か確認 | 製品カテゴリの見直し、正しい更新系統を承認 |
| 既により新しいLCUが入っている | 古いKBを承認しても、端末側は不要扱い | WSUSで更新が「Superseded」表示、端末の更新履歴に新しいKB | 最新LCUの承認に寄せる、古い承認を整理 |
| 前提（SSU/一定の更新レベル）が不足 | 検出はするが適用対象外扱い（またはインストール失敗） | 更新履歴が極端に古い、DISM/WindowsUpdateログに前提不足 | 土台を手動適用で引き上げ→WSUS配信に戻す |
| コンポーネントストア破損 | 検出自体が歪み、必要な更新が「不要」扱いに見える | DISM /RestoreHealth やCBS.logで破損兆候 | DISM修復→再検出、最終的にインプレース修復も検討 |
| WSUSメタデータ不整合/同期不備 | 承認状態はあるが、クライアントの検出結果が崩れる | 同期エラー、置換更新が大量、WSUSログに警告 | 同期確認、クリーンアップ、必要に応じて再同期/リセット |
手順：原因を潰すための実務的なチェックポイント
端末側のOS実体（21H2/ビルド/エディション）を確定する
最初にやるべきは、「その端末が何者か」を数字で確定することです。運用表記が「Server 2022 21H2」でも、実体がズレていると適用判定は簡単に崩れます。
| 確認方法 | コマンド/操作 | 見るべき値 | メモ |
|---|---|---|---|
| GUI | スタート→「winver」 | OSビルド（例：20348.x） | Server 2022（LTSC）の基準は20348系 |
| コマンド | systeminfo | OS 名/OS バージョン | 出力は環境言語で変わるが数値は共通 |
| PowerShell | Get-ComputerInfo | Select WindowsProductName, WindowsVersion, OsBuildNumber | 製品名/Version/Build | リモートでも取りやすい |
| レジストリ | reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuildNumber | CurrentBuildNumber | 棚卸しやスクリプト化に向く |
参考までに、よく使う目安をまとめます（厳密な更新レベルは「ビルドの小数点以下」で判断します）。
| OS | 代表的なビルド系列 | WSUSでのありがちな勘違い |
|---|---|---|
| Windows Server 2022（LTSC / 21H2） | 20348.x | 「Windows 11 22H2」的な感覚で“22H2”と混同し、製品カテゴリやKBを取り違える |
| Windows Server 2019 | 17763.x | 2019向けLCUを2022に当てようとしてNot Applicableになる |
| Windows Server 2016 | 14393.x | 古いWSUS設定が残り、Server 2022だけ分類漏れする |
WSUSの「製品（Products）」と「分類（Classifications）」のズレを潰す
WSUSで「Server 2022に見える更新」が並んでいても、製品や分類の選択が微妙にズレると、必要な更新だけ欠けることがあります。特にServerは、クライアントOSと一部コンポーネントが共通のため、「それっぽい設定」で漏れが出がちです。
| 項目 | 推奨 | よくある落とし穴 | チェックのしかた |
|---|---|---|---|
| 製品（Products） | Windows Server 2022 を選択 | 「Windows Server（汎用）」や旧版だけを選んでいる、似た名称の項目で止まっている | WSUSの「オプション」→「製品と分類」→製品タブで検索して確認 |
| 分類（Classifications） | Security Updates / Critical Updates / Update Rollups | Security Updatesだけで運用していて、ロールアップや重要更新が漏れる | 分類タブで最低限3つにチェック（運用によりUpdatesも検討） |
| .NET更新 | 運用により「Updates」も検討 | .NET累積更新が分類側で取りこぼされ、OSは最新に見えるのに脆弱性が残る | WSUSで「Microsoft .NET」関連更新が同期されているか確認 |
| 同期 | 手動同期で整合性確認 | 自動同期が失敗していても気づきにくい | WSUSコンソールで「同期」状態/最終同期時刻/エラーを確認 |
なお、WSUSでの製品名は環境やバージョンで揺れることがあります。迷ったら、端末の実ビルド（20348.x）と、WSUSで同期されている更新の対象ビルドが一致しているかを基準に判断してください。
KBの対象不一致・置き換え（Superseded）を見抜く
Windows Server 2022の月例更新は、基本的に累積更新（LCU）です。LCUは「その月のKB」だけ入れれば過去分も含めて更新される反面、1つ新しいLCUが出ると前のLCUは置き換え済みになります。
そのため、WSUSで古いLCUを承認していると、端末側では「もう不要」と判定されてNot Applicableになりやすいです（端末が悪いわけではありません）。
| 状況 | WSUSでの見え方 | 端末での見え方 | 対処 |
|---|---|---|---|
| より新しいLCUが既に入っている | 古いKBを承認しても「Not Applicable」 | Windows Updateは「最新の状態」、更新履歴に新しいKB | 最新LCUを承認し、古いLCU承認を整理 |
| 承認しているKBが別OS向け | 承認済みに見える | Not Applicable（当然） | 製品カテゴリとKB対象（Server 2022 / 20348系）を再確認 |
| 同一月でも別系統（例：プレビュー、Out-of-band） | 更新が複数並ぶ | 適用条件に合わずNot Applicable | 通常は「セキュリティ月例（Bリリース）」に寄せて承認 |
KB番号は毎月変わるため、具体例として「2025/5/13配布のLCU（例：KB5058385、OS Build 20348.3692）」のように社内文書に書かれていても、同じ考え方で“今月のLCU”に読み替えるのがコツです。
前提更新（SSU/更新の土台）を揃える：WSUSで詰まるなら一度手動で引き上げる
「Not Applicable」には、置き換えだけでなく前提更新（Prerequisite）不足も絡みます。更新が長期間止まっているサーバーは、サービススタックやコンポーネントの状態が古く、後続のLCUが素直に当たらないことがあります。
実務では、WSUS経由で直そうとして沼るより、Microsoft Update Catalogから最新のSSU/LCU（または統合LCU）を1回手動適用して土台を揃え、以降はWSUSに戻す方が復旧が早いケースが多いです。
| やりたいこと | 確認/作業 | メリット | 注意点 |
|---|---|---|---|
| 更新履歴の把握 | Get-HotFix / 「設定」→「更新の履歴」 | どこで止まっているか一発で分かる | LCUは「更新プログラム」ではなく「品質更新」と表示されることもある |
| パッケージ視点で確認 | dism /online /get-packages | SSU/LCUのパッケージ状態を追える | 出力が多いのでフィルタ（findstr等）推奨 |
| 土台を引き上げる | Catalogから最新更新を手動適用 | WSUSの判定不整合を一気に解消しやすい | 再起動要否、メンテ窓、適用順（SSU→LCU）を確認 |
手動適用後は、WSUSに戻す前に端末で再検出を行い、WSUSコンソールの状態が「必要（Needed）」や「未インストール（Not Installed）」に変化するかを見てください。変化しない場合は、WSUS側・ポリシー側の問題に寄っている可能性が高いです。
WSUSが最新同期できていない／同期エラーを確認する
端末側が正常に報告していても、WSUSサーバーが更新メタデータを取りこぼしていると、結果的に「承認はあるのに必要な更新が揃わない」状態になります。
- WSUSコンソールで「同期」状態と最終同期時刻を確認する
- 手動同期を実行し、同期エラー（プロキシ、TLS、容量、上位WSUS設定など）がないか確認する
- 同期後、対象更新が本当にWSUSに存在するか（更新一覧でKB検索できるか）を見る
| 見る場所 | 何を見るか | よくある原因 | 対処例 |
|---|---|---|---|
| WSUSコンソール | 同期結果/エラー | 上位サーバー同期失敗、プロキシ、証明書/TLS | ネットワーク/証明書/プロキシ設定を再確認 |
| WSUSログ | 同期やコンテンツ取得の失敗 | コンテンツ破損、容量不足 | ログのエラーコードを手掛かりに復旧（後述） |
| IISログ | クライアント要求と応答 | 認証/アクセス制御、URL誤り | GPOのWSUS URLと突合 |
置き換え更新の山で判定が壊れる：WSUSクリーンアップと整合性チェック
WSUSは運用期間が長いほど、置き換え済み（Superseded）更新や不要リビジョンが溜まり、メタデータ処理が重くなります。結果として「検出結果が不安定」「古い承認が残って混乱」といった形で問題化します。
| 作業 | 目的 | 期待できる効果 | 補足 |
|---|---|---|---|
| Server Cleanup Wizard | 不要更新/置換更新/リビジョン整理 | 判定の軽量化、誤判定の原因を減らす | 定期メンテとして実施したい |
wsusutil checkhealth | WSUSの健康状態チェック | イベントログに診断情報が残る | 原因の当たりを付ける入口に便利 |
wsusutil reset | コンテンツの整合性再チェック | ダウンロード欠け/破損の修復に寄与 | 容量とI/Oに余裕がある時に |
| DBメンテ（インデックス等） | SUSDBのパフォーマンス維持 | コンソール操作や検出処理が安定 | 社内標準の運用手順に沿って実施 |
端末側（Windows Update Agent）のキャッシュ破損・判定不整合をリセットする
端末側の判定が変に固まっている場合は、更新コンポーネントのリセットで改善することがあります。特に「WSUSには定期報告しているのに、必要な更新が1つも出ない」「Windows Update画面は常に最新の状態」などは、キャッシュの不整合を疑います。
注意：以下は管理者権限が必要です。サーバー運用では再起動やサービス停止の影響を考慮し、メンテナンス枠で実施してください。
net stop wuauserv
net stop bits
net stop cryptsvc
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start msiserver
net start cryptsvc
net start bits
net start wuauservリセット後は、再スキャンと再報告を行います。環境によって使えるコマンドが異なるため、複数用意しておくと切り分けが早いです。
| 目的 | コマンド例 | 備考 |
|---|---|---|
| 再スキャン | UsoClient StartScan | 近年のWindowsで基本。反映はログで追う |
| 更新のダウンロード | UsoClient StartDownload | 検出後の取得を促す |
| インストール開始 | UsoClient StartInstall | 自動更新ポリシーと組み合わせて使う |
| （補助）再報告 | wuauclt /reportnow | 古い方式。動作しない環境もあるため補助的に |
GPO（WSUS URL、延期/一時停止、二重スキャン）を点検する
WSUS運用でよくあるのが、GPOに混在するポリシーが原因で、クライアントが「見た目はWSUSに向いているが、実は別の挙動をしている」ケースです。特にWindows Update for Business系（延期・一時停止・機能更新の制御）を後から入れた環境では注意が必要です。
| チェック項目 | 見る場所 | 期待値 | ズレた場合の症状 |
|---|---|---|---|
| WSUS URL | GPO「イントラネットの更新サービスの場所を指定する」 | http(s)://<wsus>:8530 等が正しい | スキャンできているようで別サーバーへ行く、更新が来ない |
| UseWUServer | レジストリ：HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU | UseWUServer=1 | Microsoft Update側に寄ってWSUSと結果が噛み合わない |
| 更新の延期/一時停止 | WUfB系ポリシー、設定アプリの一時停止 | 運用方針通り（過度に長い延期を避ける） | 「最新の状態」表示でも、実際は未適用が残る |
| ターゲットグループ | WSUS側のコンピューターグループとGPOの割当 | 承認対象グループに端末が所属 | 承認はあるのに対象外に見える（実は別グループ） |
確認コマンド例：
gpresult /h C:\Temp\gpresult.html
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /sログで「なぜNot Applicableか」を言語化する
ここまでやっても原因が見えないときは、ログで「何が条件を満たしていないのか」を追うのが最短です。キーワードは0x80240017（WU_E_NOT_APPLICABLE）や NotApplicable、Superseded、Prerequisite などです。
| 対象 | ログ/場所 | 見るポイント | 補足 |
|---|---|---|---|
| クライアント | イベントビューア：Microsoft-Windows-WindowsUpdateClient/Operational | 検出・ダウンロード・インストールの失敗理由 | GUIより情報が具体的 |
| クライアント | Get-WindowsUpdateLogで生成されるWindowsUpdate.log | 適用判定の流れ、エラーコード | 新しいOSはETLを統合して生成 |
| クライアント | C:\Windows\Logs\CBS\CBS.log / C:\Windows\Logs\DISM\dism.log | コンポーネント破損や修復状況 | DISM修復が絡むと必須 |
| WSUSサーバー | 既定：C:\Program Files\Update Services\LogFiles | 同期・配信・コンテンツ関連の警告/エラー | IISログと併せると原因に近づきやすい |
ログの読み方のコツは、「更新が存在しない」のか「存在するが不要扱い」なのか「存在するが条件不足」なのかを切り分けることです。
- 存在しない：WSUS同期/製品分類/上位同期の問題が濃厚
- 不要扱い：置き換え（Superseded）や既に新しいLCUが入っている
- 条件不足：前提更新、コンポーネント破損、GPO不整合
コンポーネント破損が疑わしい場合の修復（DISM/SFC）
「更新を当てたはずなのに検出が変」「他のサーバーと挙動が違う」「CBS.logにエラーが多い」などがある場合は、コンポーネントストアを修復します。
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow修復後は、前述の手順で再スキャン→WSUSへの再報告を行い、WSUS側の状態（Not Applicable → Needed/Not Installedなど）が変わるかを確認してください。
よくある質問と現場でのハマりどころ
WSUSで「承認」したのに、なぜ端末に強制できないの？
承認は「配布してよい」許可であり、適用可否は端末がメタデータに基づいて判断します。前提不足や置き換え済みの場合、端末は正しく「適用対象外」と判断します。
Windows Update画面が「最新の状態」なのに、パッチが足りないことはある？
あります。表示は「いま参照している更新ソース（WSUS/Microsoft Update）で、検出できた更新がない」ことを意味します。WSUS側の同期不足やポリシーのズレがあると、未適用が残っていても「最新」表示になり得ます。
手動でCatalog適用したら、WSUS運用が崩れない？
基本的には崩れません。むしろ、止まっている端末を復旧させるために「土台を引き上げる」目的で手動適用し、以降をWSUSに戻すのは実務的です。ただし、運用としてはなぜWSUSで止まったか（製品分類、同期、GPO、WSUSメンテ）を必ず回収してください。
おすすめの復旧フロー（再現性重視）
最後に、現場で「早く当てる」ことを優先したフローをまとめます。チェック項目を順番に潰すことで、原因の当たりを付けながら復旧できます。
| ステップ | 作業 | 判断基準 | 次に進む条件 |
|---|---|---|---|
| 1 | 端末のOSビルド（20348.x）とエディション確認 | Server 2022として正しいか | 正しければ2へ。違えば製品カテゴリ/KBを見直す |
| 2 | WSUSの製品（Windows Server 2022）と分類（Security/Critical/Rollups）確認 | 必要な更新がWSUSに存在するか | 存在すれば3へ。存在しなければ同期/設定修正 |
| 3 | 対象KBの置き換え（Superseded）確認 | 古いKBを承認していないか | 最新LCUを承認できたら4へ |
| 4 | 前提更新/更新土台を引き上げ（必要ならCatalog手動適用） | 更新履歴が古すぎないか | 土台が揃ったら5へ |
| 5 | 端末の更新コンポーネントリセット→再スキャン→再報告 | WSUSの状態が変化するか | 変化しなければ6へ |
| 6 | WSUSクリーンアップ/整合性チェック（必要に応じてDBメンテ） | WSUS側に不整合や劣化がないか | 改善しない場合はログ解析（7） |
| 7 | ログ解析（WindowsUpdateClient、WindowsUpdate.log、CBS/DISM、WSUS/IIS） | 「存在しない/不要/条件不足」のどれか | 原因が特定できたらピンポイント対処 |
WSUSの「Not Applicable」は、原因が1つとは限りません。OS実体の確定→WSUS設定→置換/前提→端末リセット→WSUSメンテの順で潰すと、遠回りせずに復旧しやすくなります。
コメント