WSUS 2016 を最新まで更新して同期も成功しているのに、必要なはずの KB が更新一覧にも SUSDB（SQL）検索にも出てこない――この現象は「設定ミス」だけでなく、置き換え（Superseded）や配信経路の仕様が原因で起きることがあります。現場で困りがちな切り分けと、個別 KB を確実に入手して検証する手順をまとめます。
よくある症状：同期成功でも特定の KB が見つからない
WSUS（Windows Server Update Services）は、Microsoft Update から「更新のメタデータ」と「更新ファイル（コンテンツ）」を取得し、社内の端末へ配布する仕組みです。ところが運用していると、次のような状況に遭遇します。
- WSUS サーバー（Windows Server 2016、SUSDB は SQL Server）を最新に更新済み
- 同期は成功（エラーなし）
- それでも KB4580390 / KB4577069 / KB4570333 / KB4571748 / KB4559003 / KB4567513 / KB4561608 / KB4464330 / KB4464455 / KB4580364 / KB4579311 などが、WSUS コンソールで検索しても出てこない
- 念のため SUSDB を SQL で検索してもヒットしない
「その KB を個別にダウンロードしてテスト環境で検証したい」「承認・配布したい」のに見つからないと、運用が止まります。ここで重要なのは、“WSUS に存在しない（自動同期されない）更新” が実在する点と、“置き換え済みで不要になった KB” が大量に混ざる点です。
まず結論：原因は大きく 3 パターンに分かれる
| パターン | WSUS での見え方 | 典型例 | 現実的な対処 |
|---|---|---|---|
| 置き換え（Superseded）で統合済み | 古い KB が非表示になりやすい／期限切れ扱い／クリーンアップで削除される | 古い累積更新、過去月の品質更新 | 最新の累積更新（LCU）を適用して検証する。古い KB が必要なら Update Catalog で入手。 |
| そもそも WSUS へ自動配信されない | 同期しても WSUS の DB に来ない（検索しても出ない） | プレビュー（Preview）/ オプション（Optional）/ 一部の OOB | Windows Update / Microsoft Update で取得、または Microsoft Update Catalog から入手。必要なら手動インポート。 |
| WSUS 側の設定・範囲が合っていない | 特定 OS/バージョンの更新だけ欠ける | Products/Classifications 未選択、言語制限、同期フィルタ | 対象 OS に合わせて製品・分類を見直し、同期→再検索。必要に応じてメンテ（再インデックス等）。 |
原因パターン：置き換え（Superseded）で “KB が消えたように見える”
まず多くの KB は、時間が経つと Superseded（置き換え） になります。Windows 10 / Windows Server の「累積更新（LCU）」はその名の通り累積で、基本的に過去の修正を内包します。よって、古い KB を 1 つずつ揃えなくても、最新の LCU を入れれば過去分を含めて適用できます。
なぜ WSUS から “見えなくなる” のか
WSUS には「置き換えられた更新をどう扱うか」という運用要素があり、環境によっては次の理由で古い KB が見えにくくなります。
- 既定のビューやフィルタ（例：未承認のみ、必要な更新のみ）では、置き換え済み更新が表示されにくい
- Superseded を自動で期限切れ（Decline/Expire）にするルールを運用している
- サーバークリーンアップで「不要な更新」扱いになり、メタデータやコンテンツが削除される
運用の要点：本当に必要なのは “その KB” か、それとも “最新 LCU” か
「個別 KB を検証したい」気持ちはよく分かりますが、実務上は次のように考えるとトラブルが減ります。
| 検証したい目的 | おすすめのアプローチ | 理由 |
|---|---|---|
| 本番へ入れる前に不具合が出ないか確認したい | 本番で入れる予定の “最新 LCU（+必要な SSU）” をそのまま検証 | 古い KB 単体の検証は再現性が低く、実際の本番適用（最新 LCU）と条件がずれる |
| 特定の不具合修正が入った月だけを試したい | Update Catalog でその月の LCU を入手して検証（必要なら前提 SSU も） | 「その KB の修正」は通常 LCU に含まれる。単独 KB に固執するより月次 LCU の方が現実的 |
| ベンダーやアプリ要件で “この KB を入れろ” と指定されている | まず Superseded を確認し、代替となる後継 LCUを提示できないか検討 | 指定 KB が置き換え済みなら、後継 LCU を適用すれば要件を満たせることが多い |
Superseded / Expired / Declined の違いを整理する
| 状態 | 意味 | WSUS で起きがちなこと | 対処の方向性 |
|---|---|---|---|
| Superseded | 後継更新に置き換えられた | ビューによっては表示されない／承認対象から外される | 基本は後継（最新 LCU）を適用 |
| Expired | 提供側が期限切れ扱いにした | 一覧に出にくい／クリーンアップ対象になりやすい | 原則は後継へ。どうしても必要なら Catalog を探す |
| Declined | 管理者が拒否した | 既定ビューでは非表示になる | 必要なら再承認。ただし Superseded/Expired なら再考 |
置き換えの連鎖が長い例：累積更新は “傘” になりやすい
累積更新（LCU）は「その時点までの修正をまとめて持つ」ため、後発の LCU が過去月の LCU を一気に置き換えることがあります。結果として、WSUS では古い KB が非表示・期限切れ・クリーンアップ対象になり、“探しても見つからない” ように見えることがあります。
例として、Windows 10 バージョン 1809 / Windows Server 2019（ビルド 17763 系）の更新では、後発の累積更新が過去の累積更新やプレビュー更新を置き換える形になりやすいです。
| KB の例 | 種別の例 | 現場での扱い |
|---|---|---|
| KB4464330 / KB4464455 | 累積更新（LCU） | 後継 LCU に吸収されやすく、単体で追いかける価値が下がる |
| KB4561608 / KB4567513 | 累積更新（LCU） | 後発の LCU を適用すれば包含されるのが基本 |
| KB4559003 / KB4571748 / KB4577069 | プレビュー（Preview） | 検証用途。WSUS に自動同期されないことがあり、必要なら Catalog から入手する |
| KB4570333 | 累積更新（LCU） | 原則は最新 LCU を採用し、指定がある場合のみピンポイント検証 |
SQL で “本当に SUSDB に無いか” を確認する（PUBLIC_VIEWS の例）
WSUS が SQL Server を使っている場合、SUSDB には PUBLIC_VIEWS が用意されています。KB で探すなら KnowledgebaseArticle 列やタイトルを LIKE で検索すると早いです（KB の表記揺れに備えて両方を見るのがコツです）。
USE SUSDB;
SELECT TOP 50
CreationDate,
DefaultTitle,
KnowledgebaseArticle
FROM [PUBLIC_VIEWS].[vUpdate]
WHERE KnowledgebaseArticle LIKE '%4580390%'
OR DefaultTitle LIKE '%KB4580390%'; ここで行が返らない場合、「WSUS に同期されていない（WSUS: No）」か、クリーンアップなどでメタデータが削除された可能性が高いです。
原因パターン：KB が “WSUS へ自動同期されない” という仕様
ここが今回の本題です。KB の中には、公式のサポート情報に 「WSUS：No」 と明記されているものがあります。つまり、WSUS をどれだけ最新にして同期しても、その KB のメタデータ自体が入ってきません。代表例として、KB4580390 や KB4577069 は「Preview（非セキュリティ、オプション）」の累積更新で、WSUS には自動同期されない扱いになっています。
見分け方：まず “公式ページの配信チャネル” を確認する
最短で切り分けるコツはシンプルで、KB の公式ページで「How to get this update（入手方法）」を確認します。ここに次のような情報が載っています。
- Windows Update / Microsoft Update：入手できるか
- Microsoft Update Catalog：入手できるか
- WSUS：同期されるか（Yes/No）
ここで WSUS が「No」なら、WSUS で検索しても DB に無いのは正常です。逆に WSUS が「Yes」なら、Products/Classifications の不足や同期範囲の問題を疑います。
“Preview / Optional” 更新はなぜ扱いが違うのか
Preview（プレビュー）や Optional（任意）と呼ばれる更新は、一般に「次回の月例（B リリース）に含まれる予定の品質修正を先出し」する位置づけです。企業の WSUS 運用では、通常は月例のセキュリティ更新（B リリース）を中心に配布し、Preview は検証用途に限定することが多いため、配信経路が分かれている（WSUS 自動同期対象外になる）ケースがあります。
原因パターン：WSUS の設定不足で “WSUS:Yes の KB” が落ちている
一部の KB は WSUS へ同期されます。ただし、WSUS の「製品（Products）」と「分類（Classifications）」が適切でないと、同期が成功していても目的の更新が入ってきません。特に Windows 10/11 は “バージョン別の製品項目” が増えたため、チェック漏れが起きやすいポイントです。
Products / Classifications の考え方（よくある落とし穴）
| 目的 | WSUS で意識すべき設定 | ありがちなミス |
|---|---|---|
| Windows Server 2016 の月例更新を配布 | 製品：Windows Server 2016 分類：Security Updates / Updates（運用方針による） | 製品に “Windows Server 2016” を入れ忘れる |
| Windows Server 2019（1809）へ配布 | 製品：Windows Server 2019 分類：Security Updates ほか | Windows 10 側だけ選んでいて Server 2019 を外している |
| Windows 10（1903 以降）の累積更新を配布 | 製品：“Windows 10, version 1903 and later” 分類：Security Updates | 製品を “Windows 10” のみ選択し、バージョン別項目を選んでいない |
| Feature Update（機能更新）を配布 | 分類：Upgrades | 分類 “Upgrades” を選ばず、機能更新が来ない |
“同期は成功しているのに更新が少ない” ときに見るべき場所
- WSUS コンソール：Options → Products and Classifications
- WSUS コンソール：Options → Update Files and Languages（言語制限が厳しすぎないか）
- WSUS コンソール：Synchronization → Synchronizations（最終同期日時、エラーの有無）
- 上流 WSUS がある場合：上流側の承認や同期範囲（下流は上流以上には取得できない）
実務で使える：KB が WSUS に無いときの “切り分け手順”
「今すぐその KB を検証したい」場面を想定し、迷わないための手順をテンプレ化します。
対象 OS と KB の “所属” を確定する
KB 番号だけ見ても、対象が Windows Server 2016 なのか、Windows Server 2019 なのか、Windows 10 なのかで取りうる手段が変わります。まずは次を確定します。
- 対象端末の OS（例：Windows Server 2019 / Windows 10 2004 など）
- OS ビルド番号（例：17763.xxxx、14393.xxxx、19041.xxxx など）
- その KB が “セキュリティ月例（B）” か “Preview/Optional” か
公式ページで WSUS が Yes/No かを見る
公式ページで WSUS が No なら、WSUS 側の設定をいくらいじっても出てきません。運用としては次のどちらかになります。
- 検証端末だけ一時的に Microsoft Update（オンライン）へ切り替えて取得する
- Microsoft Update Catalog から KB を直接ダウンロードして適用する
WSUS が Yes の場合は、製品・分類の不足を疑う
WSUS が Yes の KB なのに見えない場合、まず Products/Classifications を見直し、同期を手動実行してから再検索します。検索は “All Updates” で、Approval/Status を広めにしてから KB 文字列で検索すると見落としが減ります。
個別 KB を入手してテストする方法
WSUS に無い KB（または古くて WSUS から消えた KB）を検証するなら、Microsoft Update Catalog からの入手が最も確実です。ここでは「配布」ではなく「検証」を主目的として、手順を具体化します。
Update Catalog からダウンロードするときのチェック項目
| チェック項目 | 見るポイント | ミスすると |
|---|---|---|
| 対象製品 | Windows Server 2016 / 2019、Windows 10 バージョンなど | 別 OS 用を落として「適用できない」 |
| アーキテクチャ | x64 / x86 / ARM64 | インストール失敗 |
| 種類 | Cumulative Update / SSU / .NET など | 前提不足で失敗、または期待した修正が入らない |
| 更新日 | 同じ KB でも複数行ある場合は更新日で見分ける | 古い方を検証してしまう |
| 前提（SSU など） | 公式ページの “Before installing this update” | LCU が入らない／謎エラー |
検証環境でのインストール例（wusa / DISM）
ダウンロードしたファイルが .msu の場合、単体インストールは wusa.exe で行えます。静かに入れて再起動を制御したい場合は次のようにします。
wusa.exe C:\\Temp\\windows10.0-kb4579311-x64.msu /quiet /norestart
shutdown /r /t 0
イメージ適用や詳細確認をしたい場合は、.msu を展開して .cab を DISM で扱う方法もあります。
mkdir C:\\Temp\\KB4579311
expand -f:* C:\\Temp\\windows10.0-kb4579311-x64.msu C:\\Temp\\KB4579311
dism /online /add-package /packagepath:C:\\Temp\\KB4579311\\*.cab
適用できたか確認するコマンド
LCU は表示名が変わることもあるため、複数の観点で確認すると安全です。
# 代表的（HotFix として出ない場合もあります）
Get-HotFix -Id KB4579311
# パッケージとして確認（LCU はこちらが確実なことが多い）
dism /online /get-packages | findstr 4579311 どうしても WSUS 配布したい：Catalog から “手動インポート” する現実解
「検証だけでなく、WSUS から承認して配布したい」場合もあります。ただし、注意点があります。Update Catalog から単純に .msu をダウンロードしても、WSUS は .msu を “ファイルとしてアップロード” する形では取り込めません。現在の WSUS では、カタログの更新 ID を使ってインポートする手順が基本になります。
インポートの流れ（概要）
- Microsoft Update Catalog で対象 KB を検索し、詳細画面で “UpdateID（GUID）” を取得する
- WSUS 管理コンソールが入った端末で、PowerShell からインポート用スクリプトを実行する
- WSUS に更新が追加されたら、通常どおり承認して配布する
スクリプト実行のイメージ
インポートは 1 件でも複数でも行えます。ここでは “WSUS サーバー名・ポート・UpdateID” を指定して取り込む形を例示します（ポートは環境により 8530/8531 など）。
.\ImportUpdateToWSUS.ps1 -WsusServer WSUS01.contoso.local -PortNumber 8530 -UpdateId 12345678-90ab-cdef-1234-567890abcdef
インポート後、更新ファイルがいつダウンロードされるかは WSUS の「更新ファイルの取得設定」（承認時に取得する／事前に取得する）に依存します。うまくいかない場合は、WSUS のログ（例：SoftwareDistribution.log）にエラーが残るため、まずそこを確認すると切り分けが早くなります。
“どこに行った？今後直る？” への現実的な答え
この手の「WSUS に無い KB」は、必ずしも障害や一時的な不具合ではなく、配信設計として WSUS 同期対象外になっている場合があります。したがって、「待っていれば WSUS に出る」前提で運用を組むと、検証や緊急対応が詰まります。
実運用としては、次の設計にしておくと強いです。
- 本番配布は WSUS（B リリース中心）：承認フローとリング運用で安全に回す
- 検証・スポット適用は Update Catalog / Microsoft Update：WSUS に無い KB も確実に入手できるルートを確保する
- 置き換え済み KB は “最新 LCU で満たす” 方針：ベンダー要件にも「後継 LCU で包含」を説明できるよう整理する
運用を安定させるための実務ポイント
SSU → LCU の順序を意識する
更新が入らない・途中で失敗する原因として多いのが、サービススタック更新（SSU）不足です。OS や時期によっては統合されているケースもありますが、特にサーバー系は「まず SSU を最新にしてから LCU」を基本動作として覚えておくと事故が減ります。オフラインで適用する場合は、前提 SSU を同時に確保しておくのが安全です。
“プレビュー更新を自動承認しない” ルールを明文化する
Preview/Optional は便利ですが、本番配布に混ざるとリスクが増えます。分類が Updates に入ることもあるため、次のようなルールで統制すると扱いやすくなります。
- 自動承認は “Security Updates（必要な製品のみ）” に限定
- Preview を検証したい場合は、専用コンピュータグループ（検証リング）へ手動承認
- 検証結果と採否を記録し、次月の B リリースへ備える
WSUS クリーンアップは “消えて困る KB” がある前提で慎重に
サーバークリーンアップは WSUS の健康維持に重要ですが、古い KB を個別に検証したい運用では、「クリーンアップしたら二度と WSUS で見つからない」ケースが出ます。古い KB の検証が必要な組織では、Update Catalog を併用して “入手ルート” を別に持つ、または検証用のオフライン保管庫を作る、といった設計が現実的です。
まとめ：WSUS で KB が見つからないときの最短ルート
- まずはその KB が Superseded（後継に統合）なのか、WSUS 自動同期対象外なのかを切り分ける
- 公式ページで WSUS が “No” の KB は、WSUS に出てこないのが仕様。Microsoft Update / Update Catalog を使う
- WSUS が “Yes” の KB なら、Products/Classifications を再点検して同期→検索
- 個別検証の要件があるなら、最初から Update Catalog を運用手順に組み込むと詰まらない
コメント