WSUS（Windows Server 2012 R2）を初めて同期すると、Windows 10 の旧バージョン向け更新まで混在して「未承認更新が数百件」になり、承認作業が止まりがちです。本記事では、社内が Windows 10 1809 のみの場合に、不要更新を安全に整理する考え方と、置き換え済み更新の掃除、運用を楽にするフィルター/スクリプト例をまとめます。
結論：運用対象が Windows 10 1809 のみなら、不要更新は「拒否」で整理して問題ない
WSUS の初回同期で未承認更新が大量に出るのは珍しくありません。製品に Windows 10 を選ぶと、WSUS は Windows 10 の複数リリース（例：1511〜1809 など）向けの「品質更新プログラム（累積更新）」「コンポーネント」「Definition 更新」などを一緒に取得するため、未承認が数百件という状態になりがちです。
社内が Windows 10 バージョン 1809 のみで、ほかのバージョンへ展開しない運用であれば、次の方針で整理するのが現実的です。
- 旧バージョン向け・不要な更新は Decline（拒否）して一覧を絞る
- 置き換え済み（Superseded）更新は定期的に拒否し、クリーンアップで“掃除”する
- 「見やすさ」は 更新ビュー（Update View）とフィルター運用で作る
実務では、旧バージョン向け更新を一括拒否し、さらに置き換え済み更新を拒否してクリーンアップを実行することで、未承認更新が 779 件 → 20 件のように大幅に減らせるケースもあります（環境や選択した分類により数は変わります）。
「タイトルに 1809 と書かれていない更新」は全部拒否してよい？
ここが一番つまずきやすいポイントです。結論から言うと、タイトルだけで機械的に判断するのは危険です。
理由は単純で、1809 端末でも必要な更新の中には、タイトルに「1809」と明示されないものが混ざるからです。代表例は次のとおりです。
| 種類 | タイトルに 1809 が出にくい理由 | 1809 運用での扱い |
|---|---|---|
| Definition Updates（例：Microsoft Defender 定義ファイル） | OS バージョン固定ではなく、エンジン/定義データとして配布されるため | 原則残す（セキュリティ上重要） |
| .NET Framework 関連更新 | OS バージョンではなく、搭載される .NET のバージョン/製品名で表記されることが多い | 利用状況により 必要（OS だけ見て拒否しない） |
| Servicing Stack Update（SSU） | 表記が「Windows 10」止まり、KB 番号中心のことがある | LCU の前提になることがあるため 慎重に扱う |
| Windows Defender/セキュリティプラットフォーム更新 | Windows 10 共通コンポーネントとして配布されることがある | 原則残す |
一方で、タイトルに「version 1511」「version 1607」「version 1703」など、明確に別リリースを示す文言が入っている更新は、1809 端末には通常不要です。そうした“明らかに対象外”を優先して拒否していくと、安全性と作業効率のバランスが取りやすくなります。
WSUS に旧バージョン向け更新が混ざる仕組み
WSUS の製品選択で「Windows 10」を有効にすると、WSUS は Windows 10 の各リリースに対して公開されている更新をまとめて取得します。端末側は自分のビルドに適用可能な更新だけを評価してインストールしますが、WSUS コンソール上の“一覧”は全部見えるため、初回同期後はどうしてもごちゃつきます。
さらに、初回同期直後は次の要素が重なり、件数が増えやすいです。
- 同じ KB が複数アーキテクチャ（x64 / x86 / ARM64）で並ぶ
- 同じ分類（Security / Critical）でも対象製品が多いと積み上がる
- 置き換え（Superseded）の関係で古い更新も残り続ける
- Definition 更新は頻繁に追加される
整理の基本：Decline（拒否）は「運用対象から外す」操作
WSUS の 拒否（Decline）は、ざっくり言うと「この WSUS からは配布しない」と意思表示する操作です。端末に既に入っている更新を勝手にアンインストールするものではありませんし、Windows Update 本体（インターネット側）からも消えるわけではありません。
ただし、拒否は“二度と戻せない”操作ではないにせよ、GUI だけだと元に戻すのが面倒な場合があります。大量に一括拒否する前に、次の安全策を入れてください。
- WSUS のコンピューターグループに テスト（パイロット）を作り、まずテストだけ承認・適用して挙動を確認する
- 「拒否する条件」を 文字列（例：1511 / 1607 / 1703 / 1709 / 1803）などで明確化し、ログとして残す
- 月次運用中（パッチ適用直前〜直後）は、大量拒否/クリーンアップを避ける
最初にやるべき設定見直し：製品・分類・言語を絞って“増え方”を止める
すでに同期してしまった更新は拒否で整理できますが、次に同じ状況を繰り返さないために、WSUS 側の選択を最小限にしておくのが重要です。特に初期構築直後は、以下の3点が効きます。
製品（Products）の選択例
社内が Windows 10 1809 のみで、ほかに配布するものがない前提の例です。実際には Office や .NET、Visual Studio なども WSUS で配るなら追加します。
| 項目 | 推奨 | 理由 |
|---|---|---|
| Windows 10 | 必要 | OS 更新の母体 |
| Windows Defender（または Microsoft Defender 関連） | 必要（Defender を使うなら） | Definition 更新を受け取るため |
| Drivers | 原則不要 | 件数と運用負荷が急増しやすい（別管理の方が安定） |
| Language Packs / Feature on Demand | 必要時のみ | 言語や機能追加を WSUS で管理する場合だけに限定 |
分類（Classifications）の選択例
質問の環境では Critical / Definition / Security を選んでいますが、運用設計としては次の考え方が分かりやすいです。
| 分類 | 1809 運用での位置づけ | ポイント |
|---|---|---|
| Security Updates | 基本的に有効 | 月次の中心。自動承認するなら最優先 |
| Critical Updates | 基本的に有効 | 緊急度が高いものが入りやすい |
| Definition Updates | Defender 利用時は有効 | 件数は多いが“捨てると危険”な代表格 |
| Updates / Update Rollups | 方針で決める | 機能改善系が混ざる。必要最低限にしたいなら抑える |
| Upgrades | 1809 固定なら原則無効 | 機能更新（Feature Update）を WSUS で配る場合だけ有効 |
言語（Languages）と同期対象の見直し
- 使わない言語を同期すると、その分だけ更新バイナリが増えます。日本語環境なら 日本語 + 英語程度に絞ると管理しやすくなります。
- 「Express インストール ファイル」を有効にするとネットワーク負荷が下がる一方、WSUS のコンテンツ容量が増えることがあります。ディスクに余裕がないなら慎重に。
旧バージョン向け更新を安全に減らす手順（GUI 編）
ここからは、コンソール操作で「未承認更新が大量」を現実的な件数まで落とす流れを、なるべく迷わない形でまとめます。
作業前の準備：テスト用コンピューターグループを作る
本番クライアント全台へいきなり適用せず、まずテストで確認します。
- WSUS コンソールで コンピューターを開き、グループ（例：Pilot）を作成
- テスト端末を Pilot に割り当て（手動でも GPO でも可）
- 最初は Pilot のみに承認し、問題がないことを確認してから全社へ広げる
まずは「明確に対象外」の更新を拒否する
“タイトルに OS バージョンが明示されている更新”は、最初の整理対象として扱いやすいです。例えば次のようなキーワードです。
- version 1511 / 1607 / 1703 / 1709 / 1803（社内が 1809 のみなら対象外になりやすい）
- LTSB / LTSC（社内エディションと違う場合）
- ARM64（社内が x64 のみの場合）
- Itanium / ia64 など（そもそも該当しないもの）
WSUS の更新一覧で検索・絞り込みし、該当する更新をまとめて拒否します。
- 更新 > すべての更新を開く
- フィルターを 承認：未承認、状態：任意、種類：ソフトウェアに設定
- 右上の検索（タイトル検索）で version 1511 などを入力して抽出
- 対象を複数選択し、右クリックで 拒否（Decline）
- 同様に version 1607、1703…と繰り返す
この時点で、未承認の総数が大きく減ることが多いです。
クライアントが状態を報告すると「必要な更新だけ」にさらに絞り込める
初回同期直後は、WSUS が「どの更新が社内端末に必要か」をまだ把握できていないため、多くの更新が 状態：なし（No Status） で並びます。クライアント（1809 端末）が WSUS に接続してスキャン結果を報告し始めると、更新ごとに「必要（Needed）」「インストール済み（Installed）」などの状態が付くようになります。
この状態が付いた後は、更新一覧のフィルターで次のように設定するだけで、運用画面が一気に見やすくなります。
| フィルター | 設定例 | 期待できる効果 |
|---|---|---|
| 承認 | 未承認 | これから判断すべき更新だけを表示 |
| 状態 | 必要（Needed） | 社内端末に必要な更新だけが残り、旧バージョン向け更新が自然に消える |
| 分類 | Security Updates / Critical Updates | 月次運用の対象に集中できる |
「旧バージョン向け更新が大量で、どれを拒否すべきか迷う」場合は、まず Pilot 端末だけでも WSUS に接続させ、状態が付いてから Needed で絞ると、拒否の判断量そのものを減らせます。
「1809 と書かれていないが、実は対象外」を見分けるコツ
タイトルにバージョンが出ない更新は、次の2点を見ると判断しやすくなります。
- 更新の詳細（Details）の「この更新プログラムは次の製品に適用されます（Applies to）」
- 製品（Products）や 分類（Classifications）、KB番号
たとえば、更新の詳細に「Windows 10 Version 1709」などが明記されていれば、1809 端末には不要な可能性が高いので拒否対象にできます。逆に、Defender 定義や .NET 更新などは OS バージョンでは切れないことが多いため、“バージョン表記がない＝不要”ではない点に注意してください。
置き換え済み（Superseded）更新はどう扱うのが正解？
WSUS では更新が新しい更新に置き換えられると、古い更新が Superseded（置き換え済み）としてマークされます。置き換え済み更新を残しておくと次のデメリットがあります。
- 更新一覧が膨らみ、承認作業の判断が遅くなる
- クリーンアップしない限り、コンテンツや DB が肥大化しやすい
- “どれを承認すべきか”が曖昧になり、誤承認・誤拒否が起きやすい
そのため、運用としては 置き換え済み更新は定期的に拒否して掃除するのがおすすめです。
置き換え済み更新を拒否する前に確認したいこと
置き換え済みは原則整理対象ですが、次の条件を満たすようにすると安全性が上がります。
| 確認項目 | 理由 | 目安 |
|---|---|---|
| 置き換え元を置き換える更新（後継）が WSUS に存在する | 置き換え先が未同期・未承認だと穴が開く | 少なくとも後継が同期済み |
| 後継更新が Pilot で適用できている | 稀に後継で問題が起きることがある | Pilot に承認し正常性確認 |
| 置き換え済みが「最近の更新」ではない | 端末が追いついていないと必要になる場合がある | 運用に合わせて猶予を設ける |
WSUS のクリーンアップとセットで考える
拒否しただけでは、WSUS のコンテンツフォルダや SUSDB から即座に消えるとは限りません。拒否 → クリーンアップをセットにすると、見た目だけでなく容量面でも改善しやすくなります。
WSUS クリーンアップ（GUI 編）：拒否した更新を“掃除”して軽くする
Windows Server 2012 R2 の WSUS なら、まずは標準の サーバークリーンアップウィザードが基本です。
- WSUS コンソールで オプションを開く
- サーバークリーンアップウィザードを実行
- チェック項目を選択して実行
よく使うチェック項目の考え方は次のとおりです。
| チェック項目（表記は環境で多少異なる） | 効果 | 注意点 |
|---|---|---|
| 期限切れ（Expired）更新の削除/拒否 | 不要更新を整理 | 基本的に有効で OK |
| 置き換え済み（Superseded）更新の削除/拒否 | 一覧と DB を整理 | 後継が承認済み/適用済みか確認すると安全 |
| 不要な更新ファイルの削除 | コンテンツ容量削減 | 実行中に負荷が上がることがあるため業務時間外が無難 |
| 未使用コンピューターの削除 | DB の整理 | 長期間未接続の端末を整理したい場合に |
| 不要な更新のリビジョン（revisions）の削除 | DB を軽くする | WSUS の健康診断的に重要 |
更新ビュー（Update View）で「見やすい運用画面」を作る
拒否とクリーンアップで件数を減らしても、日々の承認作業は“見やすさ”がないと迷いが出ます。WSUS の運用を安定させるには、更新ビューを自分の運用に合わせて作るのが効果的です。
おすすめのビュー構成例（1809 固定運用）
| ビュー名の例 | フィルターの例 | 狙い |
|---|---|---|
| 未承認（セキュリティ） | 承認：未承認 / 分類：Security Updates / 状態：任意 | 毎月ここだけ見れば良い状態にする |
| 未承認（Critical） | 承認：未承認 / 分類：Critical Updates | セキュリティ以外の重要分を拾う |
| 置き換え済み（掃除対象） | 置き換え：置き換え済み / 承認：任意 | 掃除の入口を固定する |
| 拒否済み（確認用） | 承認：拒否 | 一括拒否した結果を後から確認できる |
| 要注意（失敗/未ダウンロード） | 状態：失敗 / ファイルなし など | 配布トラブルの早期発見 |
“全部見る”のではなく、見るべきビューを先に固定すると、運用が一気に楽になります。
PowerShell で「置き換え済み更新の拒否」を自動化する（例）
GUI での一括拒否は、初回の整理で便利ですが、置き換え済み更新は継続的に増えます。定期運用にするなら、PowerShell で自動化しておくと管理が安定します。以下は WSUS API を使った例です。
（実行前にテスト WSUS / Pilot グループで動作確認し、スクリプトの対象条件を自社ポリシーに合わせて調整してください）
# 置き換え済み（Superseded）更新を一括で拒否する例
# 実行には WSUS 管理ツールがインストールされていることが前提です。
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("localhost",$false)
# まだ拒否されていない、置き換え済みの更新を取得
$updates = $wsus.GetUpdates() | Where-Object {
$*.IsSuperseded -eq $true -and $*.IsDeclined -eq $false
}
Write-Host ("Target updates: " + $updates.Count)
foreach ($u in $updates) {
try {
$u.Decline()
Write-Host ("Declined: " + $u.Title)
} catch {
Write-Warning ("Failed: " + $u.Title + " / " + $_.Exception.Message)
}
} 旧バージョン文字列を含む更新を拒否する例（慎重に）
「1511〜1803 など明確に対象外のバージョンを拒否したい」場合の例です。タイトルだけに依存するため万能ではありませんが、初回の大量整理では現実的に効きます。
# タイトルに旧バージョン表記を含む更新を拒否する例
# 1809 固定運用を想定（必要に応じて配列を調整）
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("localhost",$false)
$keywords = @(
"version 1511",
"version 1607",
"version 1703",
"version 1709",
"version 1803"
)
$all = $wsus.GetUpdates() | Where-Object { $_.IsDeclined -eq $false }
$targets = $all | Where-Object {
$t = $_.Title.ToLower()
foreach ($k in $keywords) {
if ($t.Contains($k)) { return $true }
}
return $false
}
Write-Host ("Target updates: " + $targets.Count)
foreach ($u in $targets) {
try {
$u.Decline()
Write-Host ("Declined: " + $u.Title)
} catch {
Write-Warning ("Failed: " + $u.Title + " / " + $_.Exception.Message)
}
} ポイントは、キーワードの対象を“明確に不要”に限定することです。例えば「Windows 10」だけで拒否すると必要な更新まで巻き込むので、絶対に避けてください。
運用テンプレ：毎月の承認作業を迷わない形にする
整理が済んだら、次は“増え続ける更新をどうさばくか”が勝負になります。1809 固定運用でよくある運用テンプレを例として載せます。
| タイミング | やること | WSUS 側の操作 |
|---|---|---|
| パッチ公開後 | Pilot に先行適用 | 「未承認（セキュリティ）」ビューから該当更新を Pilot のみ承認 |
| 問題なし確認後 | 本番へ展開 | 同じ更新を 本番グループへ承認 |
| 月次の安定後 | 置き換え済みの掃除 | Superseded を拒否 → クリーンアップ |
| 四半期ごと | 設定棚卸し | 製品/分類/言語が増えていないか見直し |
よくある落とし穴と回避策
「1809 と書いてないから拒否」で Defender 定義まで捨ててしまう
Definition Updates を拒否すると、端末が最新の防御を受け取れません。WSUS を使うなら、Defender を利用している限り Definition 更新は捨てないのが基本です（別経路で更新する設計なら別）。
置き換え済みを掃除したのに容量が減らない
拒否だけでは容量は減りにくいことがあります。クリーンアップ（不要な更新ファイルの削除、リビジョン整理）を実行して、はじめて効果が見えるケースが多いです。必要に応じて「WSUS コンテンツの場所」「ディスク残量」も併せて確認してください。
クリーンアップ後に同期や承認が遅くなった気がする
クリーンアップは WSUS に負荷をかけます。業務時間外に実行し、完了後に WSUS のイベントログや同期結果を確認しておくと安心です。DB（SUSDB）の肥大が疑われる場合は、再インデックスなどのメンテナンスも検討すると改善することがあります。
まとめ：初回の大量未承認は「拒否で整理」＋「置き換え済み掃除」＋「ビュー運用」で解決できる
WSUS（Windows Server 2012 R2）で初回同期直後に未承認更新が大量になるのは、製品選択の性質上ほぼ避けられません。重要なのは、社内の運用対象（今回なら Windows 10 1809）を前提に、不要な更新を拒否して“見える量”をコントロールすることです。
そのうえで、置き換え済み更新を定期的に拒否し、クリーンアップで掃除する流れを習慣化すると、WSUS は「初回だけ大変で、その後は淡々と回る」状態を作れます。まずは Pilot で小さく試し、問題がないことを確認しながら、全体へ広げていくのが安全です。
コメント