WSUSを正しく同期しているはずなのに、.NET Frameworkの個別KB（例：KB4565622/KB4565613など）がWSUSコンソールに出てこない、端末でも“未適用”扱いになる――。しかし同月のロールアップ（例：KB4566519）が存在するなら、多くの場合それはWSUSの故障ではなく仕様です。本記事では仕組み、確認方法、ACAS/Tenable系スキャナーの指摘への実務対応まで整理します。
起きている現象を整理する（「WSUSに無い＝配布できない」ではない）
まず、今回の問い合わせパターンは次のようなものです。
- WSUSの製品/分類/同期設定は概ね問題なさそう
- テスト端末で .NET Framework 関連パッチが「未適用（欠落）」として扱われる
- しかしWSUS上には、同月のロールアップ（例：KB4566519）やセキュリティのみ更新（例：KB4566468）が存在する
- Microsoftの案内では「WSUSと自動同期される」旨が書かれているのに、個別KB（例：KB4565622/KB4565585、KB4565613/KB4565580など）がWSUSで見つからない
- 脆弱性スキャナー（ACAS / Tenable.SC）が不足パッチとして検出し、過去に手動インポートを行った経緯がある
結論から言うと、WSUSに個別KBが表示されないこと自体は、設計上起こり得る正常な挙動です。重要なのは、ロールアップ（累積更新）を承認しているなら、クライアント側は必要な“構成要素”だけを選んで適用できるという点です。
.NETの月例更新は「見た目は1つ、内部は複数」で動いている
.NET Frameworkの月例更新は、運用上は「このKBを当てればOK」という形に見えますが、内部的にはもう少し複雑です。Windowsの更新はコンポーネントベース（CBS）で管理され、更新パッケージは複数の部品（サブコンポーネント）として扱われます。
そのため、たとえばロールアップ（例：KB4566519）の内部が、イメージとしては以下のように分解されることがあります。
- KB4566519（ロールアップ＝“親”）
- KB4565613 / KB4565614 / KB4565622 / KB4565635 …（“部品”としての更新要素）
ここで重要なのが、「部品のKB」が常にWSUSコンソールに“個別の更新”として並ぶとは限らないという点です。WSUSが扱うのは主に「配布・承認の単位」として公開された更新であり、内部部品まで毎回コンソールに出すとカタログが肥大化し、運用負荷やDB負荷が跳ね上がります。
用語の整理（ロールアップ／セキュリティのみ／部品KB）
| 種類 | WSUSでの見え方 | 特徴 | 運用上のポイント |
|---|---|---|---|
| ロールアップ（累積更新） | 表示されることが多い | 過去分を含めた“まとめ”として配布される。内部的に複数の部品で構成されることがある。 | 基本はロールアップ承認が最優先。端末は必要な部品だけ選んで適用する。 |
| セキュリティのみ更新 | 表示されることが多い | セキュリティ修正に限定した更新（対象OS/対象.NETの条件がある）。 | ロールアップを使わない方針の環境で使われがち。適用漏れが出やすいのでルール化が必要。 |
| 部品KB（コンポーネントKB） | 表示されないことがある | ロールアップの内部要素として参照される更新。単体で承認・配布する前提ではない場合がある。 | 見えなくても配布不能ではない。端末側はロールアップ経由で整合することがある。 |
なぜWSUSに「個別KB」が出てこないのか（仕様として起こる代表パターン）
ロールアップが“配布の表看板”で、部品は裏側に隠れている
Microsoft Update側で更新が「まとめ（ロールアップ）」として公開されている場合、WSUSはそのまとめを同期します。一方、内部の部品更新は、単体で配布・承認する目的で公開されていないことがあり、その場合はWSUSコンソールに更新として表示されません。
このとき、WSUSに個別KBが見つからなくても、クライアントは次の流れで更新できます。
- クライアントがWSUSに対して「適用可能な更新は何か」を問い合わせる
- WSUSはロールアップ更新を含む“公開された更新”のメタデータを返す
- クライアントは自分の構成（OS、.NETバージョン、既存の更新状況）に基づいて、ロールアップの中から必要な要素を選択して適用する
WSUSは“カタログの全部”を見せる設計ではない
WSUSの設計思想は「組織内配布に必要な更新を、管理可能な粒度で運用する」ことです。更新の内部構造（細かな部品）まで管理者に見せると、承認・期限・グルーピングが破綻しやすくなります。そのため、管理単位として意味のある更新だけを前面に出し、裏側の部品を見せない（または見せにくい）ケースが発生します。
同じKB番号に見えても、対象が異なる（OS / .NET / 前提更新で枝分かれ）
.NET Framework更新は、OSや.NETの世代（例：3.5/4.6/4.7/4.8など）、さらに前提のサービススタックや累積更新の状況で適用可否が変わります。スキャナーが「KB4565622が無い」と言っている場合でも、実際にはその端末にとっては同等の修正が別の束（ロールアップ）で満たされていることがあります。
結論：WSUSで個別KBが表示されないのは故障ではなく、ロールアップ承認で配布できる
ここまでを踏まえると、運用上の結論はシンプルです。
- WSUSに個別KB（例：KB4565622 / KB4565613）が表示されないことは、仕様として起こり得る
- 同月のロールアップ（例：KB4566519）を承認していれば、端末は必要な部品だけを選んで適用する
- 「個別KBが見えない＝WSUSで配布できない」ではない
つまり、WSUS側で「個別KBがない」ことだけを根拠に不具合扱いするのは早計で、端末側でロールアップが適用済みかを基準に判断するのが最も確実です。
端末側での確認が最優先（ロールアップKBを基準に“整合”を取る）
スキャナーやWSUSコンソールの表示よりも信頼できるのは、端末自身が持つ「実際にインストールされた更新情報」です。確認は次の順で行うと迷いが減ります。
確認観点のおすすめ順
| 優先度 | 確認対象 | 何が分かるか | ポイント |
|---|---|---|---|
| 高 | ロールアップKBが入っているか | その月の.NET修正がまとめて満たされている可能性 | スキャナーが部品KBを要求しても、ロールアップで満たされることがある |
| 中 | インストール済み更新一覧（GUI/コマンド） | KB番号レベルの客観証跡 | Get-HotFixに出ない更新もあるため、複数手段で確認する |
| 中 | .NETのリリース値/バージョン | .NETの実体が想定どおりか、前提不足がないか | 端末の.NETが古いと“必要な更新”の前提が崩れる |
| 低 | Windows Update履歴 | 更新経路の傾向 | 履歴はクリアされたり欠けたりするため、最終証跡にはしない |
PowerShell/コマンドでの実用例（監査・報告にも使える）
環境や更新の種類によって“見える/見えない”があるため、証跡取得は複数手段を用意するのが安全です。
| 目的 | コマンド例 | 読み取りのコツ |
|---|---|---|
| 特定のKBが入っているか（簡易） | Get-HotFix -Id KB4566519 | 結果が返ればインストール済み。ただし更新種別によっては出ないこともある。 |
| KBを含む一覧を検索（簡易） | Get-HotFix | Where-Object {$_.HotFixID -match "KB4566519"} | 複数KBを横断して確認したいときに便利。 |
| パッケージ（CBS）として確認（強め） | dism /online /get-packages /format:table | findstr /i 4566519 | Get-HotFixで拾えない更新でも、CBSパッケージとして見つかることがある。 |
| インストール済み更新（GUI） | appwiz.cpl → インストールされた更新プログラムを表示 | 監査対応でスクリーンショットを残す場合に有効。 |
| .NET 4.xのリリース値確認（例） | reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release | .NET 4.xの世代・更新レベルの確認に使う（環境標準の基準値と突合）。 |
スキャナーが部品KB（例：KB4565622）を欠落として出してきた場合でも、端末でロールアップ（例：KB4566519）がインストール済みであれば、実害がない（同等の修正が満たされている）ケースが現実的に多いです。
ACAS / Tenable.SC が「部品KB不足」と言い続ける理由と、現場での落としどころ
脆弱性スキャナーは便利ですが、更新の“束ね方”や“置き換え（supersedence）”の表現が複雑な領域では、次のようなズレが起こり得ます。
よくあるズレのパターン
- KBの置き換え（supersedence）をスキャナーが正しく追従していない
本来はロールアップで包含されているのに、部品KBの未適用として残る。 - プラグイン/フィードが古い
“同等の修正が別KBに統合された”という情報に追従できず、旧KBを欠落扱いする。 - 検出ロジックがKBベースではなくファイル/レジストリ痕跡ベース
ロールアップ適用後も、痕跡の差分で「未対応」と判定されることがある。 - 端末の更新履歴の欠損
履歴だけ消えている、またはコンポーネントストア修復等で見え方が変わり、スキャナーが取り違える。
誤検知（または過剰検知）を疑うときの実務対応
| 対応 | 狙い | 具体例 |
|---|---|---|
| ロールアップ適用の証跡を先に固める | 「修正は満たしている」を説明できる状態にする | Get-HotFix / DISM結果、インストール済み更新のスクショ、適用日を保存 |
| スキャナー側のプラグイン/フィード更新 | 既知の誤検知を潰す | スキャナー運用チームに更新状況確認、再スキャンを依頼 |
| “同等修正”の扱いを運用ルール化 | 毎月同じ議論を繰り返さない | 「部品KB指摘はロールアップ適用で代替可」を基準書に明記 |
| 例外/受容（Risk Acceptance）の判断材料を用意 | 監査・セキュリティ部門との合意形成 | ロールアップKB番号、適用端末一覧、根拠（ベンダー資料の要旨）を添付 |
ポイントは、スキャナーの画面だけで「未適用」と断定せず、端末のロールアップ適用状況を一次情報として扱うことです。運用上は「不足と出ているKBの“代替となるロールアップ”が適用済みである」証跡を固めると、説明コストが下がります。
WSUS側で“本当に”確認すべきチェックポイント（不具合と仕様を切り分ける）
個別KBが見えないこと自体は仕様でも、更新が端末に降りていないなら別問題です。WSUS側では、次の基本項目を押さえると切り分けが早くなります。
| チェック項目 | 見る場所 | よくある落とし穴 | 対処の方向性 |
|---|---|---|---|
| 製品（Products）の選択 | WSUSオプション | OSは選んでいるが、対象のWindows世代が抜けている | 端末のOSと一致する製品を追加し再同期 |
| 分類（Classifications）の選択 | WSUSオプション | Update Rollups / Security Updates などが無効 | 運用方針に応じて必要分類を有効化 |
| 承認（Approve）の状態 | WSUSコンソール | ロールアップが未承認、または誤って拒否/期限設定 | テスト→本番の段階承認に統一 |
| 対象端末の所属グループ | コンピューター/グループ | テスト端末が想定外グループに所属 | クライアント側のターゲット設定（GPO）を確認 |
| 期限切れ/置き換え（Superseded）処理 | WSUS保守 | 清掃で必要更新まで拒否してしまう | 自動拒否ルールの見直し、段階的なクリーンアップ |
| コンテンツ配布（Content）の整合 | IIS/WSUSContent | メタデータはあるがコンテンツ欠損で配布失敗 | WSUSの整合性確認、必要に応じて再ダウンロード |
切り分けのコツ：「WSUSに“更新がある”」と「端末に“入る”」は別
WSUSコンソールにロールアップが表示されていても、端末に入らない場合は以下のような原因があり得ます。
- 端末が別グループで未承認のポリシーに当たっている
- 端末のWindows Update関連サービスやポリシーが崩れている
- 前提更新（OSの累積更新、サービススタック等）が不足していて適用判定から外れている
- WSUSコンテンツの欠損や配布経路（プロキシ、SSL、IIS設定）の問題
この場合は「個別KBが見えない」ことよりも、ロールアップ自体が端末に適用されない理由を優先的に追うべきです。
「MicrosoftはWSUSと自動同期されると言っているのに？」への回答の作り方
ここで誤解が生まれやすいのが、「自動同期される＝個別KBがWSUSに並ぶ」という読み方です。実務的には、次のように整理して説明すると通りやすくなります。
- “自動同期される”の対象は、管理単位として公開されている更新（多くはロールアップ）である
- ロールアップの内部は複数要素で構成され得るが、内部要素（部品KB）はWSUS上で個別に見えない場合がある
- それでも端末側は、ロールアップを受け取ることで必要要素を選択して適用し、結果として修正が満たされる
この説明に加えて、端末でロールアップKBが適用済みである証跡（Get-HotFix/DISM/GUI）を提示できると、「WSUS不具合」という疑いから一気に外れます。
それでもスキャナー指摘を潰したい場合の現実的アプローチ
現場では「実害はないと分かっていても、スキャナーで赤が残ると困る」という状況が起きます。その場合は、技術的に“正しい”だけでなく、運用的に“通る”手を選ぶのが近道です。
アプローチ例
| 状況 | おすすめ対応 | 補足 |
|---|---|---|
| ロールアップ適用済みなのに部品KBで検出 | 誤検知として扱い、根拠（ロールアップ適用証跡）を添付 | 監査/セキュリティ部門向けにテンプレ化すると強い |
| スキャナーのプラグインが古い | フィード更新→再スキャン | 月例更新は置き換えが頻繁なので、更新運用が重要 |
| 端末の更新状態が不安定 | ロールアップ再適用、コンポーネントストア整合の確認 | まずは“ロールアップが入る端末状態”を作るのが先 |
| どうしても個別KB名での証跡が必要 | “個別KBではなくロールアップKBを証跡とする”運用に切替 | 手動インポート常態化は運用負荷・事故リスクが上がる |
過去に手動インポートで対処した経験があると、「今回もWSUSが欠けているのでは」と疑いやすいのですが、ロールアップ前提で設計された更新は、手動インポートで“見た目だけ”合わせるほど運用が歪みやすい点に注意が必要です。
運用を安定させるためのベストプラクティス（WSUS×.NET更新）
最後に、同種の問い合わせを減らすための運用面の工夫をまとめます。
ロールアップ基準で“合否判定”する
- 「部品KBが見えるか」ではなく、毎月のロールアップKBが適用されたかで合否を決める
- 報告書・監査資料・パッチ適用証跡も、ロールアップKBを基準に統一する
テストリング運用（テスト端末→本番）を固定化する
- ロールアップは影響範囲が広い分、段階承認と相性が良い
- 「テストで問題なければ本番承認」という流れをWSUSのコンピューターグループに落とし込む
WSUSのメンテナンスを“やり過ぎない・やらなさ過ぎない”
- 不要な更新・言語・期限切れの整理は重要だが、ルールが荒いと必要更新まで消す事故が起きる
- 「置き換え更新の拒否」は段階的に行い、テストリングの端末で影響がないことを確認する
スキャナー運用チームと“合意できる基準”を作る
- スキャナーの指摘KBと、実際の適用単位（ロールアップKB）がズレる領域があることを前提にする
- 「ロールアップ適用済み＝修正満たす」の扱いを、例外ではなく標準ルールとして文書化する
まとめ（現場で迷わない判断軸）
- WSUSで.NET Frameworkの個別KBが表示されないのは、仕様として起こり得る
- ロールアップ（例：KB4566519）を承認していれば、端末は必要要素を選んで適用する
- スキャナーが部品KB（例：KB4565622）不足と言っても、ロールアップ適用済みなら誤検知/過剰検知の可能性がある
- 切り分けは「WSUS表示」より端末のインストール済み更新（ロールアップKB）を一次情報にする
「個別KBが見えない」ことに引っ張られず、ロールアップを基準に事実確認と証跡化を進めると、WSUS運用もスキャナー対応も安定します。
コメント