ConfigMgr（SCCM）のSUP（Software Update Point）としてWSUSを統合した途端に、WSUSContent が数日でTB級まで増えてディスクを食い尽くす——この症状は「製品を少し選んだだけなのに大きすぎる」という違和感の通り、ほとんどの場合“設定または運用の噛み合わせ”が原因です。この記事では、なぜ膨張するのかの見立てから、止血→原因除去→縮小（削減）→再発防止まで、現場で迷いがちなポイントを含めて整理します。
まず結論：WSUS が“更新ファイル本体”をダウンロードしているのが主因
SUP用途のWSUSは、基本的に「更新メタデータ（カタログ情報）の提供役」に寄ります。更新の承認・配布管理は ConfigMgr 側で行い、更新ファイル本体（コンテンツ）は ConfigMgr がダウンロードして配布ポイント（DP）に配る、という役割分担が前提です。
それにも関わらず WSUSContent が 1TB、2TB と増えるときは、WSUS側が何らかの理由で「承認された更新のバイナリ」や「余計に巨大化する形式の更新ファイル」をローカルに溜め込んでいます。特に多いのが、次の2つが同時に起きるケースです。
- WSUS の自動承認（Automatic Approval）ルールが残っている／誰かが有効化している
- WSUS 側が「更新ファイルをローカルに保存する」運用のままになっている
SUP（ConfigMgr）と単体WSUSの“考え方の違い”を先に揃える
トラブルの根っこは、「単体WSUSとしての常識」がSUP運用に混ざることです。WSUS単体では“承認＝配布”なので、承認した瞬間からコンテンツを取りに行く運用が自然です。一方、SUP運用では、WSUSで承認を回し始めると ConfigMgr と責任範囲が重なり、結果として WSUSContent が肥大化しやすくなります。
| 項目 | 単体WSUS（一般的） | ConfigMgr（SUP） |
|---|---|---|
| 承認の主体 | WSUS | ConfigMgr（WSUSは原則触らない） |
| 更新ファイル本体の保持 | WSUSContent に保存することが多い | ConfigMgr の更新パッケージ/DP が主 |
| 自動承認ルール | 運用次第で使う | 基本的に使わない（事故率が高い） |
| トラブルの典型 | 配布対象の増加で徐々に肥大化 | 数日でTB級に急増（承認/保存の設定が原因） |
よくあるトリガー：なぜ「少し選んだだけ」でTB級になるのか
「Windows 10 製品を少し選んだだけ」でも、WSUSの設定次第で“更新ファイル本体”を片っ端から取り込み、さらに“膨張しやすい分類”まで混ざると一気に跳ねます。代表的なトリガーを先に列挙します。
| トリガー | 膨張の仕組み | 起きやすいサイン |
|---|---|---|
| 自動承認ルールが有効 | 承認→WSUSがコンテンツをダウンロード | 「承認済み」が大量に存在、ダウンロードが止まらない |
| 更新ファイルをローカル保存 | 承認された更新のバイナリをWSUSContentへ | WSUSContent が日次で増え続ける |
| 巨大化しやすい分類（例：ドライバー等） | 分類自体が数・サイズともに膨大 | 分類を有効化した直後から増加ペースが変わる |
| クリーンアップ未実施（長期間） | 不要コンテンツ・古いリビジョンが溜まる | WSUSの応答が遅い、同期やクリーンアップが完走しない |
まずは“止血”：これ以上増やさないための確認ポイント
削減作業に入る前に、増加を止めないと作業中にもディスクが食われ続けます。作業時間が取れない場合でも、最低限ここだけは先に潰すと被害が止まります。
WSUS の自動承認ルールを全て無効化/削除
- WSUS コンソール → オプション → 自動承認
- 有効なルールがあれば 無効化、可能なら 削除
SUP環境では、この自動承認が残っているだけで「WSUSとしては正しい動き（承認したら落とす）」をしてしまい、WSUSContent を爆速で肥大化させます。数日でTB級という“急増”は、このパターンが最有力です。
WSUS の「更新ファイル」設定を見直す（SUP前提に寄せる）
次に、WSUSがローカルに更新ファイルを保存する設定になっていないかを確認します。
- WSUS コンソール → オプション → 更新ファイルと更新言語
- 「更新ファイル」関連の選択肢を確認（保存/ダウンロード条件など）
SUP用途で“WSUSにコンテンツを持たせる必要があるか”は環境設計によりますが、少なくとも「自動承認が残っている状態」でローカル保存が有効だと、膨張の条件が揃ってしまいます。
いま増えているのが本当に WSUSContent かを再確認（見間違い対策）
現場で意外に多いのが、フォルダー名の見間違い・関連フォルダーの混同です。ConfigMgr 側にはコンテンツライブラリ（ContentLibrary）やパッケージソースなど、別の場所が肥大化しているケースもあります。
- 肥大化しているパスが WSUSContent であること
- ドライブ直下に別名でリパース/リンクされていないこと
- バックアップ・スナップショット・重複排除の除外対象が適切か（結果として見かけ上肥大化することがある）
縮小（削減）の王道手順：未承認化→クリーンアップ→繰り返し
原因が「承認が走ってWSUSがダウンロードした」なら、削減もそれに対応した順番でやるのが最短です。ポイントは、一発で終わらせようとしないこと。WSUSのクリーンアップは途中終了・タイムアウトが起きやすく、複数回回す前提になりがちです。
手順の全体像
- 自動承認を止める（増加を止血）
- WSUS側の承認済み更新を「未承認」に戻す
- WSUS Server Cleanup Wizard を実行（複数回）
- 必要に応じて PowerShell でクリーンアップを繰り返す
- DBメンテナンス（再インデックス/統計更新等）を組み込む
WSUS側の承認を“未承認（Not approved）”へ戻す
自動承認を止めても、既に「承認済み」の更新が大量に残っていると、クリーンアップで不要扱いされにくかったり、コンテンツ保持が続いてしまうことがあります。SUP用途なら、WSUSコンソール上で承認運用をしないのが基本なので、ここは大胆に“戻す”判断が効きます。
- WSUS コンソール → 更新プログラム
- フィルターで「承認済み」を絞り込み
- 対象を選択して、承認状態を 未承認 に戻す（環境により表示名は異なります）
※ConfigMgrで管理している更新の“配布”自体はConfigMgr側で維持されますが、運用が混在している環境では影響範囲が読みにくい場合があります。特に「単体WSUSとして参照しているクライアント」が存在するなら、先にその参照を断つ/移行することを優先してください。
WSUS Server Cleanup Wizard：チェックの勘所と“複数回”が前提な理由
クリーンアップウィザードは、環境によっては途中で止まったり、最後まで走り切らないことがあります。完走しない＝失敗ではなく、1回ごとに少しずつ片付くイメージで捉えると現実的です。
| クリーンアップ項目 | 狙い | SUP環境での優先度 | 補足 |
|---|---|---|---|
| 不要な更新ファイルの削除（Unneeded content files） | WSUSContent の実体削除に直結 | 最優先 | ここが効かないとディスクは減りにくい |
| 置き換えられた更新の拒否（Decline superseded updates） | 不要更新を整理して対象を減らす | 高 | 後段の削除が通りやすくなる |
| 期限切れ更新の拒否（Decline expired updates） | 同上 | 高 | 整理の基本 |
| 不要なコンピューターの削除（Obsolete computers） | DB負荷を軽くする | 中 | 直接の容量削減より安定化目的 |
| 更新の圧縮（Compress updates） | DBの軽量化 | 中 | クリーンアップ完走に効くことがある |
実行のコツは次の通りです。
- 最初は「不要な更新ファイルの削除」を必ず含める
- 一度に全部やって落ちるなら、項目を減らして“完走率”を上げ、回数で詰める
- 実行中はWSUS/IIS/DBに負荷がかかるため、メンテ時間を確保する
- ディスクが本当に逼迫しているなら、まず空き容量を確保してから（別ドライブ退避など）
PowerShell でクリーンアップを回す（途中停止しやすい環境ほど有効）
GUIのウィザードが途中で止まりやすい環境では、PowerShell で同等処理を回す方が安定することがあります。ログを取りながら何度も実行する、という運用がしやすいのが利点です。
以下は例です（実行は管理者権限、WSUS管理用モジュールが利用できる環境を前提）。環境によってモジュールの読み込み方法や実行ポリシーが異なるため、まずはテストで動作確認してください。
# 例：WSUS クリーンアップを複数回実行し、結果をログに残す
$log = "C:\Temp\wsus-cleanup-$(Get-Date -Format yyyyMMdd-HHmmss).log"
"==== START $(Get-Date) ====" | Out-File -FilePath $log -Encoding utf8
try {
$wsus = Get-WsusServer
1..5 | ForEach-Object {
"---- Run $_ : $(Get-Date) ----" | Out-File $log -Append -Encoding utf8
$result = Invoke-WsusServerCleanup -UpdateServer $wsus `
-CleanupObsoleteUpdates `
-CleanupUnneededContentFiles `
-DeclineExpiredUpdates `
-DeclineSupersededUpdates `
-CompressUpdates `
-CleanupObsoleteComputers
$result | Format-List * | Out-String | Out-File $log -Append -Encoding utf8
Start-Sleep -Seconds 30
}
}
catch {
"ERROR: $($_.Exception.Message)" | Out-File $log -Append -Encoding utf8
}
finally {
"==== END $(Get-Date) ====" | Out-File -FilePath $log -Append -Encoding utf8
}ポイントは、「5回」など回数を決めて回し、終わったらWSUSContentの実サイズを確認→足りなければ追加で回す、という運用に寄せることです。
「未承認＋クリーンアップ」でも減らないときの見直しポイント
ここまでやっても容量がほとんど変わらない場合、原因が“承認の残骸”以外にある可能性が高いです。以下を順番に疑うと、遠回りしにくくなります。
自動承認が本当に残っていないか（別条件・別担当・別サーバー）
- ルールが複数存在していないか
- 「分類」や「製品」の追加時に自動承認が効く条件がないか
- WSUSが複数台あり、別のWSUSで承認が走っていないか（上流/下流構成含む）
WSUS が“単体WSUS”としても参照されていないか
SUPとして使っているつもりでも、古いGPOや手動設定でクライアントがWSUSを参照していると、管理が二重化して予期せぬ承認・同期・ダウンロードが起きがちです。
- クライアントの Windows Update の参照先（ポリシー/レジストリ）を棚卸し
- 「このSUPはConfigMgr専用」という前提を崩す要素がないか確認
巨大化しやすい分類・構成が混ざっていないか
特定の分類（例：ドライバー系）や、更新の取り扱い方によっては、少しの選択でも増え方が極端になります。特に「何かを有効にした直後から増加ペースが跳ねた」なら、その変更点を疑うのが近道です。
クリーンアップが“完走していない”だけの可能性
完走していない場合、効果が出にくいことがあります。次のような工夫が有効です。
- クリーンアップ項目を減らして完走率を上げる（まずは不要ファイル削除を中心に）
- 実行時間帯を変える（同期やバックアップと被らない時間へ）
- WSUS/DBのメンテ（再インデックス等）を先に実施してからクリーンアップする
WSUSContent を“手で消す”前に知っておくべきこと
容量が厳しいと、フォルダーを直接削除したくなりますが、原則としておすすめしません。WSUSはDBとファイルの整合性を前提に動くため、乱暴に消すと「必要なものまで欠ける→復旧で逆に再ダウンロード」になりやすいからです。
どうしても緊急で空きを作る必要がある場合は、まずは次の優先順位で検討してください。
- 別ドライブへ退避（ディスク追加・拡張・移設）して“止血”し、正規手順でクリーンアップ
- 承認解除→クリーンアップを回してから、残骸が明らかなものだけを慎重に扱う
- 最終手段として「WSUSを再構築する」判断（SUPの再構成を含む）
WSUS の安定性を上げる：DBメンテナンスを“定期作業”にする
WSUSのクリーンアップが遅い・止まる・完走しない、という背景には、SUSDB（WID/SQL）の肥大化やインデックスの断片化が絡むことが多いです。SUP運用でも、WSUS/DBメンテを“やらない”と、いずれ同期やクリーンアップが苦しくなります。
| メンテ項目 | 期待できる効果 | 目安 | 注意 |
|---|---|---|---|
| インデックス再構成/再構築 | クリーンアップの完走率・処理速度改善 | 月1〜四半期 | DB負荷が上がるのでメンテ時間に実施 |
| 統計情報更新 | クエリ最適化 | 月1〜四半期 | 他処理と被せない |
| 不要データの整理（期限切れ/置き換え拒否） | DB肥大化を抑える | 月1 | 運用ポリシーと整合させる |
「クリーンアップ→DBメンテ→クリーンアップ（再実行）」の順でやると、途中停止が減って一気に進むことがあります。特にTB級まで膨らんだ後は、DBの状態も悪化している可能性が高いので、削減だけでなく“次から詰まらない状態”を作る意識が重要です。
再発防止：SUP環境で“触ってはいけない/触るならルール化する”ポイント
今回のような事故は、設定そのものより「誰がどこを触って良いか」が曖昧な環境ほど起きます。再発防止は、技術と運用の両方で固めるのが効果的です。
WSUSコンソールで承認運用をしない（触るなら“見るだけ”）
- 承認・配布は ConfigMgr 側で完結させる
- WSUS側の自動承認は原則禁止（必要があるなら“理由と範囲”を明文化）
- 権限（WSUS管理者）を絞り、変更履歴が追える体制にする
容量監視を“早期検知”に寄せる
TB級になる前に、数十GBの段階で気付ければ、止血も縮小も圧倒的に楽です。
- WSUSContent のサイズを日次で記録（増加率も見る）
- ディスク空き容量の閾値アラート（例：残り20%/10%）
- WSUS同期のタイミングと増加が連動していないかを確認
作業手順をテンプレ化して、担当交代に強くする
「クリーンアップは複数回が前提」「承認を戻してからやる」など、知っている人だけが回避できる地雷がWSUSにはあります。以下のような“短い手順書”を残すだけでも、次回の事故率が下がります。
- 自動承認の確認場所
- 更新ファイル設定の確認場所
- クリーンアップの推奨オプションと実行順
- PowerShellスクリプトの保管場所と実行ログの保存先
現場FAQ：よく聞かれる疑問
Windows 10 を少し選んだだけなのに、なぜ 1TB を超える？
選んだ“製品”が少なくても、承認や分類、保存設定が噛み合うと、WSUSは更新ファイル本体を大量にダウンロードします。自動承認が残っていると、管理者が意識しないうちに承認が進み、短期間で跳ね上がります。
クリーンアップを1回やったのに全然減らない
途中で止まっている、削除対象がまだ「不要」と判定されていない、承認が残っている、といった理由が多いです。承認を未承認に戻したうえで、不要ファイル削除を含めて複数回回すのが王道です。
どうしても急いで容量を空けたい
手動削除は整合性を崩しやすいので、まずは増加要因（自動承認など）を止め、可能ならディスク拡張・退避で時間を稼いでから正規手順で削減してください。最終的に再構築が早いケースもありますが、その判断は「SUP以外の利用が混ざっていない」ことを確認してからが安全です。
まとめ：TB級は“異常”として原因を潰せば、十分に制御できる
SUP環境で WSUSContent が 1TB を超えるような急増は、WSUSが更新ファイル本体を抱え込む設定・運用が紛れ込んでいるサインです。まずは自動承認の停止で止血し、承認状態を戻したうえでクリーンアップを複数回回し、仕上げにDBメンテを組み合わせると、削減と安定化を同時に進められます。再発防止として「WSUSは触らない（触るならルール化）」を徹底すると、次のディスク枯渇事故をかなりの確率で防げます。
コメント