MENU

WSUS 2019のProducts（製品）選択ガイド：Servicing Driversの意味と最小構成の設定手順

Windows Server

WSUS 2019 の初期設定で「Products（製品）」を開くと、似た名前の項目が大量に並び、どれを選べばよいか迷いがちです。本記事では Servicing Drivers など Drivers 系カテゴリの意味と、Windows Server の月次更新を安全に配布するための“必要最小限の選び方”を実務目線で解説します。

目次

WSUS 2019 の「Products（製品）」が分かりにくい理由

WSUS の「Products（製品）」は、“更新プログラムの対象となる製品ファミリーを絞り込むためのカタログ」です。ここで選んだ製品のメタデータ（更新の一覧・依存関係・適用条件など）だけが同期され、承認・配布の候補としてコンソールに出てきます。

問題は、近年の Windows Update が「OS本体の更新」だけでなく、ドライバー、機能更新（Upgrade）、セットアップ時の動的更新（Dynamic Update）など複数の流れを持つようになり、WSUS 側の製品カテゴリもそれに合わせて細分化されたことです。その結果、次のような“似た名前”が並びます。

  • Windows Server 2019 and later, Servicing Drivers
  • Windows Server 2019 and later, Upgrade & Servicing Drivers
  • Windows Server version 1903 and later

名前だけを見ると「Servicing＝サービス（保守）だから必須？」「1903＝古いけど later だから新しいの？」と混乱しがちですが、多くのサーバー運用では“選ばなくてよいもの”が混ざっているのがポイントです。

まず押さえる：Products（製品）と Classifications（分類）の役割分担

WSUS の初期設定で迷ったら、まずは「Products は“対象物”、Classifications は“更新の種類”」と分けて理解すると整理できます。

設定項目何を決めるか例実務的なコツ
Products（製品）どの製品の更新を扱うか（カタログの範囲）Windows Server 2019 / Microsoft Defender / Office など増やすほど同期量・DB・運用負荷が増える。まずは必要最小限から。
Classifications（分類）どんな種類の更新を扱うか（セキュリティ、重要、ドライバー等）Security Updates / Critical Updates / Updates / Drivers などサーバーならセキュリティ中心＋必要な更新に絞る。Drivers は慎重に。

つまり、「Products をサーバーOSに絞り、Classifications で月次更新に必要な種類を選ぶ」のが基本戦略です。

結論：月次パッチ配布が目的なら、Drivers 系カテゴリは無理に選ばない

質問に出てきた Servicing Drivers / Upgrade & Servicing Drivers は、結論から言うと“ドライバー配布用の製品カテゴリ”です。ドライバー更新を WSUS で配るつもりがないなら、無理にチェックする必要はありません。同期対象が増えるだけになりがちです。

特に Windows Server の運用では、ドライバーは「安定しているものを固定する」方針が多く、OS の累積更新（LCU）やセキュリティ更新のように毎月追従するものとは性質が違います。WSUS で Drivers を扱う場合は、“承認の責任を自分たちが持つ”運用になります。ドライバーは不具合の影響範囲が広く、ロールバックも面倒なので、目的が明確でない限りは後回しで問題ありません。

「Servicing Drivers」と「Servicing Stack Update（SSU）」は別物

ここは混乱ポイントです。WSUS でよく聞くSSU（Servicing Stack Update）は、Windows Update の内部コンポーネント（サービススタック）を更新するもので、月次更新と同じ文脈で重要になりがちです。

一方でServicing Drivers は“ドライバー”です。名前が似ていますが、SSU のために Servicing Drivers を選ぶ必要はありません。SSU を含む通常の Windows 更新は、基本的に対象OS（例：Windows Server 2019）を選んでいれば配布できます。

Drivers 系カテゴリの意味：Servicing Drivers と Upgrade & Servicing Drivers

では、Drivers 系カテゴリは何が違うのでしょうか。実務的に押さえるべきポイントだけを表にまとめます。

Products に出てくる項目目的（ざっくり）主な利用シーンサーバー月次更新だけなら
Windows Server 2019 and later, Servicing Drivers通常運用（保守）で提示されるドライバーの配布デバイスドライバーを Windows Update 経由で継続配布したい場合基本は未選択でOK。必要になったら追加。
Windows Server 2019 and later, Upgrade & Servicing Driversアップグレード時も含む、より広い場面で提示されるドライバー配布インプレースアップグレード時の互換性・セットアップ支援も含めてドライバーを扱いたい場合通常は不要。インプレースアップグレードを WSUS 管理で厳密にやるなら検討。

この表の通り、どちらも“OS のビルド番号を上げる累積更新”とは別系統です。サーバーに「毎月のセキュリティ更新を配りたい」だけなら、まずは OS の Products と、必要な Classifications を揃えるのが先決です。

Drivers を WSUS で配る場合のメリット・デメリット

「Drivers を配らない」判断をしやすいように、運用上の得失も整理しておきます。

観点メリットデメリット／注意点
標準化クライアントPCなど大量端末で同一ドライバーを配布しやすいサーバーでは機種差・構成差が大きく、一律配布が事故に繋がる
管理コストWSUS 上で一元管理できる同期量・承認対象が増え、コンソールが重くなりやすい
リスク既知の不具合修正ドライバーを配れる場合があるドライバー更新は影響が大きい。不具合時の切り戻し手順が必須
代替手段―サーバーはベンダー提供の更新ツール／ファームウェアバンドルの方が安全なことが多い

少数のサーバー（今回のように 4 台）を安全に更新したい、という目的なら、まずは Drivers を扱わない構成で運用を安定させる方が成功率が高いです。

「Windows Server version 1903 and later」は何のための製品カテゴリ？

Windows Server version 1903 のように「version + 数字」で表現されるものは、主に“特定の提供形態（リリース系統）”向けに分かれている更新対象です。Windows Server の世界には、長期サポートの LTSC（例：2016 / 2019 / 2022）と、過去に存在した SAC（Semi-Annual Channel）のようにバージョン番号で区別される系統があります。

ここで重要なのは、あなたが更新したいサーバーOSがどちらの系統かです。ほとんどのオンプレサーバーは LTSC を採用していることが多く、その場合は 「Windows Server 2019」など年号の製品を選べば足りることがほとんどです。

製品カテゴリの見え方対象のイメージよくある用途選択の判断
Windows Server 2019（年号）LTSC（長期サポート）系統の Windows Server一般的なオンプレサーバー、基幹系、AD/ファイル/仮想化などServer 2019 を更新するなら選ぶ
Windows Server version 1903 and later（version 1903）バージョン番号で区別される系統の Windows Server（主に特定用途）コンテナ用途など、短いサイクルの提供形態を前提とした環境該当OSが無いなら不要

迷ったら、更新対象サーバーで「OS の正式名称」を確認し、年号系（2019/2022など）なら version 1903 系は選ばない、で大きく外しません。

おすすめの選び方：最小構成から始める手順

ここからは「インターネットに出られないサーバー 4 台に、月次更新を配る」ことを前提に、実務で失敗しにくい手順をまとめます。ポイントは最初から全部選ばないことです。

対象サーバーの OS を棚卸しする（最初にやる）

Products を選ぶ前に、対象サーバーの OS を正確に把握します。年号（2016/2019/2022）とビルド番号が分かれば十分です。

PowerShell（管理者）
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

複数台あるなら、リモート実行できる環境では次のように一覧化しておくと後で迷いません。

$servers = @("SVR01","SVR02","SVR03","SVR04")
Invoke-Command -ComputerName $servers -ScriptBlock {
  Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion, OsBuildNumber
}

Products（製品）の選び方：まずは「対象OSそのもの」だけ

棚卸し結果が Windows Server 2019 のみであれば、WSUS の Products は次の発想で選びます。

  • 必須：Windows Server 2019（対象OS）
  • 原則不要：Windows Server 2019 and later, Servicing Drivers
  • 原則不要：Windows Server 2019 and later, Upgrade & Servicing Drivers
  • 対象が無ければ不要：Windows Server version 1903 and later

この段階で「他も選ばないと更新が足りないのでは？」と不安になりますが、WSUS は後から追加しても運用を壊しにくい設計です。まずは絞って同期し、“不足が確認できたときだけ追加”が安全です。

Classifications（分類）の選び方：サーバー向けの推奨セット

次に、月次更新に必要な分類を選びます。サーバー用途では、一般的に以下が扱いやすい構成です（環境のポリシーに合わせて調整してください）。

分類同期する目的サーバー運用での推奨補足
Security Updatesセキュリティ修正を配布有効基本はここが最優先
Critical Updates重大な品質問題の修正有効セキュリティ以外でも重要な修正が入ることがある
Updates一般的な品質更新（SSU などが入る場合あり）有効（推奨）“セキュリティだけ”にすると足りない月が出ることがある
Update Rollups複数修正のまとめ配布環境次第現在は累積更新（LCU）中心だが、製品によっては残る
Driversドライバー更新を配布原則無効Drivers を扱うなら検証手順とロールバックを用意する
Upgrades機能更新（OS の大きな更新）原則無効サーバーのインプレースアップグレードを WSUS で管理する場合のみ

この「分類」の設計ができていれば、Products を余計に増やさずに月次運用を回しやすくなります。

同期・承認・検証の運用フロー（4台構成で失敗しにくい）

WSUS は「同期した＝配られる」ではありません。承認（Approve）して初めて配布されます。少数サーバーほど、次のように段階的に進めると安全です。

  1. コンピューターグループを2つ作る：「検証」「本番」
  2. まず検証グループにだけ承認：更新後の再起動、役割（AD/DNS/ファイル共有等）の動作確認
  3. 問題がなければ本番へ展開：承認対象を広げる

この運用は、Drivers を配らない構成でも非常に有効です。更新が原因で想定外の事象が起きたときに、被害範囲を小さくできます。

Products を増やし過ぎると何が起きる？（そして、どう戻す？）

WSUS は Products を増やすほど同期するメタデータと更新数が増え、環境によってはWSUS コンソールが重い／同期が終わらない／DBが肥大といった症状が出やすくなります。特に Drivers を含めると候補数が跳ね上がりがちです。

よくある症状ありがちな原因実務的な対処
同期に時間がかかる／失敗するProducts を広げすぎ、メタデータ量が過大不要な Products を外し、まず OS に絞る。その後に同期。
WSUS コンソールが非常に遅い更新数が多すぎる（Drivers で特に増える）Server Cleanup Wizardの実行、不要更新の否認（Decline）
DB（WID/SQL）が肥大・バックアップが重い不要メタデータの蓄積クリーンアップ＋定期メンテ（インデックス再構成など）
承認作業が終わらないドライバー・不要製品の更新が大量に出る承認対象を「セキュリティ中心」に絞り、自動承認ルールを最小限にする

一度選んだ Products は後から外しても構いません。ただし、すでに同期しているメタデータがすぐに消えるわけではないため、クリーンアップ（不要更新の削除、期限切れの削除、置き換え更新の削除など）を合わせて実施すると効果が出やすいです。

「どれを選べばいいか分からない」時の判断チャート

最後に、現場で迷いがちな判断を“質問”に落として整理します。YES が多いほど、そのカテゴリを選ぶ理由が明確になります。

確認したいことYES の場合NO の場合
更新対象に Windows Server 2019（LTSC）がいる？Windows Server 2019 を選ぶ対象OS（2016/2022など）を選ぶ
ドライバー更新も WSUS で配布したい？（目的が明確）Drivers の分類＋該当 Drivers 製品カテゴリを検討Drivers は選ばない
インプレースアップグレードを WSUS 主導で管理する？Upgrades（分類）や Upgrade & Servicing Drivers を検討Upgrade 系は不要
version 1903 系の Windows Server を運用している？Windows Server version 1903 and later を検討不要

よくある質問

Servicing Drivers を選ばないと、累積更新（CU）が降ってこない？

降ってきます。累積更新（CU）やセキュリティ更新は、基本的に対象OS（例：Windows Server 2019）の製品カテゴリで扱われます。Servicing Drivers はドライバー配布のためのカテゴリで、CU とは別系統です。

最小構成で始めた後、足りない更新があったらどうする？

不足が分かった時点で、Products を追加→同期すれば対応できます。最初から広げるより、運用を壊しにくいのがメリットです。追加後は更新数が増えるので、承認ルールや検証グループ運用で安全側に倒してください。

WSUS サーバー自体もインターネットに出られない場合は？

その場合は、別のネットワークにある上位 WSUS からのエクスポート／インポート、あるいは更新ファイルの持ち込みなど、“カタログと更新ファイルをどう持ってくるか”を別途設計する必要があります。まずは Products/分類の設計を最小構成にして、同期・承認・配布の流れを固めると、持ち込み運用にも展開しやすくなります。

すぐ使える：WSUS 2019 Products 選択の実務チェックリスト

  • 更新対象サーバーの OS 名（2016/2019/2022 等）とビルド番号を一覧化した
  • Products は対象OSのみから開始する（迷うものは後で追加）
  • Classifications はSecurity/Critical/Updatesを基本セットにする
  • Drivers は目的が明確で、検証と切り戻し手順がある場合のみ有効化する
  • コンピューターグループは「検証」「本番」を作り、段階承認で運用する
  • Products を広げたら、同期量・DB・コンソール性能への影響を必ず確認する

WSUS 2019 の Products（製品）選択は、最初に“全部入り”を目指すほど運用が難しくなります。必要最小限（対象OS＋必要な分類）で開始し、必要になったら足す。これが、少数サーバーの安全なパッチ管理で一番失敗しにくい進め方です。

Windows Server
wsus Windows Update パッチ管理 Windows Server 2019

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次