2025年7月9〜10日ごろから、WSUSで突然「2018年まで遡る古い更新プログラムが約2万件も同期された」「すべて新しいリビジョンとして表示される」といった報告が増えています。初見だと「ウイルスか？」「WSUSが壊れた？」と不安になりますが、多くの場合は仕組みを知っていれば落ち着いて対処できる事象です。本記事では、この大量同期の正体と安全な対処手順、今後の再発に備えた運用のポイントまでを、WSUS初心者〜中級者向けに整理します。
WSUSで「古い更新プログラム」が大量同期される現象とは？
今回のケースでは、2018年ごろまで遡る古い更新プログラムが、2025年7月9〜10日にかけて19,688件も「新しいリビジョン」としてWSUSに同期されています。WSUSコンソール上では、以下のような状況が発生します。
- 「すべての更新」に、過去に見覚えのある古い更新プログラムが大量に再出現する
- 状態列に「新しいリビジョン」と表示され、最近更新されたかのように見える
- 過去に却下済みにしていた更新まで一覧に戻ってくる
- 初回同期時にCPU・ディスクI/O・SQL負荷が一時的に跳ね上がる
見た目だけ追うと「古いパッチが再リリースされたのか？」「何かの大規模不具合か？」と疑いたくなりますが、実態はもう少し地味で、かつコントロール可能な動きです。
なぜ2018年の古い更新が2025年に同期されたのか（原因）
この種の大量同期は、多くの場合Microsoft側のメタデータ一括改版が原因です。ここでいうメタデータとは、更新プログラム本体（.cab や .msu）の中身ではなく、次のような「説明書き」や制御情報を指します。
- 検出ロジック（どのOS・どのバージョンに適用可能かを判定する条件）
- 適用条件（再起動の要否、他の更新との依存関係など）
- 置き換え関係（Supersedence）の見直し
- ライセンス条項（EULA）や説明文の修正
- バックエンド移行や内部ID整理に伴う更新
イメージしやすいように、更新プログラムを「パッチ本体」と「説明書き」に分けて整理してみます。
| 要素 | 中身 | 今回の改版で変わる可能性 |
|---|---|---|
| パッチ本体 | .cab / .msu ファイルなど、実際に端末へ配布されるファイル | 基本的に変わらない（再配布されない） |
| メタデータ | 検出ロジック、適用条件、置き換え関係、EULA など | まとめて書き換え・整理される |
Microsoft側でメタデータが更新されると、WSUSから見ると「同じ更新プログラムだがリビジョン番号が増えた新バージョン」が登場した扱いになります。このため、たとえ2018年の古い更新であっても、2025年の時点で新しいリビジョンとして再同期されてしまうのです。
よくあるメタデータ改版のパターン
| パターン | 具体例 | WSUSでの見え方 |
|---|---|---|
| 検出ロジックの調整 | 特定ビルドでは不要なパッチが検出されてしまう不具合を修正 | 古い更新に「新しいリビジョン」が付き、クライアントの検出結果が変わる |
| 置き換え関係の整理 | 累積更新プログラムが増えたため、古い更新との関係を整理 | 「置き換えられている」更新が増え、整理しやすくなる |
| 説明文・EULAの修正 | 誤記の修正、サポートポリシー変更の追記など | 内容は変わらないが、リビジョンだけ増える |
つまり、今回の大量同期は「危険なパッチがばらまかれた」のではなく、「昔の更新の説明書きが大量に更新された結果、WSUSがまじめに全部取り込み直した」だけと考えるのが正解に近いです。
大量同期がWSUSとクライアントに与える影響
とはいえ、約2万件という規模になると、放置してよいか不安になります。代表的な影響を整理しておきます。
| 対象 | 起こりうる影響 | ポイント |
|---|---|---|
| WSUSサーバー | 初回同期時のCPU・メモリ・ディスクI/O増加、DBサイズの肥大化 | 一度落ち着けば通常運用に戻るが、DBメンテナンスをサボっている環境ほどダメージ大 |
| クライアント | 「更新の確認」に時間がかかるケースがある | 評価対象となる更新の件数が一時的に増えるため。ネットワーク帯域への影響は限定的 |
| 自動承認ルール | 過去に却下していた更新が、再び承認されてしまうリスク | 「新しい更新」「特定分類を自動承認」などのルールを使っている場合は要注意 |
| ディスク容量 | メタデータ増加によるDB領域圧迫、場合によってはコンテンツディスクもひっ迫 | クリーンアップと再インデックスでかなり改善可能 |
なお、多くの更新はすでに新しい累積更新やロールアップに置き換え済みであり、クライアントにとっては「評価だけしてインストール対象外になる」パターンがほとんどです。そのため、適切に整理してしまえば、実害は最小限に抑えることができます。
短期的にやるべきWSUSの対処手順
今回のように古い更新が大量に同期された場合、まずは次の3ステップで「被害を広げない」「無駄なデータをためない」ことを意識して対処します。
- 置き換え済み（Superseded）の更新プログラムを一括却下する
- サーバーのクリーンアップウィザード（またはPowerShell）を実行する
- 自動承認ルールと対象製品・分類を見直す
ステップ1：置き換え済み更新プログラムを一括却下する
WSUSでは、他の更新に置き換えられた更新プログラムを却下しても、通常はクライアント側に悪影響はありません。むしろ、評価対象から外れることでスキャン時間の短縮やDB負荷の軽減につながります。
作業の流れは次のとおりです。
- WSUSコンソールで「すべての更新」を開く
- 表示する列に「置き換え状況（Supersedence）」を追加する
- 「置き換え状況」列で並べ替え、置き換えられている更新をまとめて選択する
- 右クリックして「却下」を実行する
「置き換え状況」のアイコンの意味を、分かりやすく表にまとめると次のようになります。
| アイコンのイメージ | 状態 | 基本方針 |
|---|---|---|
| 上にだけ青い四角 | この更新が他の更新を置き換える（現行の更新） | 原則として却下しない（最新パッチの可能性が高い） |
| 中央にだけ青い四角 | この更新は新しい更新に置き換えられている | 優先的に却下してよい |
| 上下に青い四角 | 他の更新を置き換えつつ、自分もさらに新しい更新に置き換えられている | 基本的には却下して問題ないが、不安なら段階的に実施 |
迷った場合は、まず「完全に置き換えられている（中央だけ青い四角）」更新から却下していくのがおすすめです。いきなり全件ではなく、OS種別ごと・年ごとなど、少しずつスコープを広げると安心感があります。
ステップ2：サーバーのクリーンアップを実行する
置き換え済み更新を却下したら、続いてクリーンアップウィザードを実行し、不要になったメタデータやコンテンツファイルを整理します。
WSUSコンソールの操作手順は次のとおりです。
- 「オプション」>「サーバーのクリーンアップ ウィザード」を開く
- 少なくとも次の項目にチェックを入れる
- 不要な更新プログラムを削除する
- 置き換えられた更新プログラムを削除する
- 未使用の更新ファイルを削除する
- 古いコンピューターを削除する（必要に応じて）
- 業務時間外に実行し、完了まで待つ（環境によっては数時間かかることもあります）
PowerShellが利用できる環境であれば、次のようなスクリプトで定期実行するのも効果的です。
Import-Module UpdateServices
$wsus = Get-WsusServer
Invoke-WsusServerCleanup ` -CleanupObsoleteUpdates`
-CleanupUnneededContentFiles ` -CompressUpdates`
-DeclineExpiredUpdates `
-DeclineSupersededUpdates スケジューラで週1回〜月1回程度回しておけば、今回のようなメタデータ改版があった場合でも、肥大化をかなり抑えられます。
ステップ3：自動承認ルールと対象範囲を見直す
大量同期時に一番怖いのは、「過去に手作業で却下した古い更新」が、自動承認ルールによって再び承認されてしまうことです。これを防ぐために、次の観点でルールを見直します。
- 対象製品を、実際に使っているOS・アプリケーションのみに絞る
- 分類は「セキュリティ更新」「定義の更新」など、本当に自動展開したいものに限定する
- 重要なサーバーは自動承認から外し、手動承認＋段階的展開の運用にする
- 「置き換えられている更新」を承認対象から外す（手動運用の場合も含む）
特に、クライアントとサーバーを同じ自動承認ルールで管理している環境では、サーバー向けだけ別ルールに分ける、あるいは完全に手動承認に切り替えるだけでもリスクを大きく減らせます。
長期的な再発予防とWSUS運用ベストプラクティス
今回のようなメタデータ一括改版は、数年に一度のペースで起こることがあります。そのたびに右往左往しないために、普段から次のような運用を仕込んでおくと安心です。
定期メンテナンスメニューを決めておく
| タスク | 推奨頻度 | 内容 |
|---|---|---|
| クリーンアップウィザード実行 | 月1回程度 | 不要・置き換え済み更新、未使用コンテンツ、古いコンピューターの整理 |
| PowerShellによる更新整理 | 月1回〜四半期ごと | スクリプトで期限切れ・置き換え済み更新を一括却下 |
| DBメンテナンス（再インデックスなど） | 四半期〜半年に1回 | WsusDBMaintenance.sql 等を利用し、インデックス断片化を解消 |
| 対象製品・分類の棚卸し | 半年〜1年に1回 | 使わなくなったOS・製品の同期設定を外す、自動承認ルールを見直す |
特に、DBメンテナンスを長期間実施していないWSUSは、今回のような大量同期がとどめになって、クエリが極端に遅くなったり、タイムアウトが頻発したりしがちです。WSUSのDBは「触らない方が安全」ではなく、「定期的に手入れした方が安全」と考えた方が現実的です。
スクリプトや手順書として「ルーチン化」する
担当者の経験や勘に頼る運用だと、担当交代のたびにWSUSの状態が悪化しがちです。今回紹介した対処やメンテナンスを、次のような形でルーチン化しておくと安心です。
- PowerShellスクリプトとして保存し、タスクスケジューラで実行する
- 週次・月次の運用チェックリストに「WSUSクリーンアップ」の項目を追加する
- 「大量同期発生時の対応手順書」として、社内Wikiや共有ドキュメントにまとめておく
「19,688件の更新が同期されたら、この手順書のとおりにやればOK」と言える状態にしておけば、将来同じ現象が起きても、チーム全体で落ち着いて対応できます。
ConfigMgr(SUP) 連携環境での注意点
System Center Configuration Manager（SCCM）やMicrosoft Endpoint Configuration Manager（MECM）のソフトウェア更新ポイント（SUP）としてWSUSを使っている場合も、基本的な考え方は同じです。Microsoft側のメタデータ改版は、WSUS経由でConfigMgrに同期されます。
この場合は、次のような追加ポイントを意識します。
- ConfigMgrの「期限切れ更新のクリーンアップ」タスクが正常に動いているか確認する
- 自動展開ルール（ADR）の対象を、必要最低限の製品・分類に絞る
- 不要な更新は、WSUS側だけでなくConfigMgrのコンソール上でも整理する
WSUS単体運用と比べてコンポーネントが増える分、どこで承認・却下・削除したかを意識しながら整理することが重要です。
よくある疑問と回答（FAQ）
Q. 19,688件も同期されたら、クライアントが全部ダウンロードしてしまいますか？
A. いいえ。クライアントは、WSUSから提供される更新の一覧をもとに「自分に必要な更新だけ」を絞り込んで評価します。ほとんどの古い更新は、すでにより新しい累積更新やロールアップに置き換えられているため、インストール対象にはなりません。
Q. 過去に却下した更新が、また承認されてしまいました。どうすればいいですか？
A. まずは対象の更新が「置き換えられている」状態かどうかを確認し、問題なければまとめて却下し直します。そのうえで、自動承認ルールの条件（製品・分類・グループなど）を見直し、同じことが起こらないように調整しましょう。
Q. WSUSのDBが急に大きくなりました。縮小できますか？
A. クリーンアップウィザードやPowerShellで不要な更新や未使用コンテンツを削除したうえで、SQL Server側での再インデックスや縮小を実施することで、多くのケースでサイズを抑えることができます。ただし本番環境では、事前のバックアップ取得とメンテナンス時間の確保を忘れないようにしてください。
Q. 今回の大量同期は、セキュリティ的に危険な兆候ではありませんか？
A. 現象そのものは、あくまでメタデータの改版に起因するものであり、パッチ本体が改ざんされたり、意図しないマルウェアが配布される類のものではありません。ただし、古い更新が誤って承認されることで検証されていないパッチが配布されるリスクはあるため、本記事で紹介した整理手順と自動承認ルールの見直しは実施しておくことをおすすめします。
まとめ：WSUSの大量同期は「仕組みを理解して淡々と整理」
- 2018年ごろまで遡る古い更新が、2025年7月9〜10日に約2万件同期されたのは、Microsoft側のメタデータ一括改版が原因である可能性が高い
- 多くの場合、配布されるパッチ本体は変わらず、「説明書き（検出ロジック・置き換え関係など）」だけが更新されている
- 短期的には、「置き換え済み更新の一括却下」→「クリーンアップ」→「自動承認ルールの見直し」の3ステップで被害を最小限に抑えられる
- 長期的には、定期的なクリーンアップとDBメンテナンス、対象製品・分類の棚卸し、スクリプトや手順書によるルーチン化が有効
- ConfigMgr(SUP) 連携環境でも基本的な考え方は同じであり、WSUS側とConfigMgr側の両方で整理することが重要
WSUSは一度トラブルが起きると「よく分からないまま怖くて触れない」存在になりがちですが、仕組みを押さえて運用ルールを整えておけば、今回のような大量同期も「よくあるイベントのひとつ」として淡々と処理できるようになります。この記事を、自社環境のWSUS運用を見直すきっかけにしていただければ幸いです。
コメント