Windows Server 2016 をインターネット非接続環境で運用していると、「未適用分も含めた公開済み Windows Update 一覧が欲しい」と悩みがちです。本記事では、公式の完全一覧が用意されていない前提で、Microsoft Update Catalog と更新履歴ページを使って必要なKBを集める実務手順をまとめます。
公開済みの更新一覧が欲しくなる背景
「インストール済み更新の一覧」は、OS 上で簡単に確認できます。ところが、オフライン端末にパッチを当てたい場合は、未インストール分も含めて、Microsoft が公開してきた更新を網羅的に把握したいというニーズが出ます。
典型的なシーンは次のとおりです。
- 製造装置・検査端末など、インターネットに直接出せない Windows Server 2016 を長期運用している
- 別PCで更新プログラムをダウンロードし、USBや共有フォルダ経由でオフライン端末へ持ち込んで適用する
- 監査や脆弱性対応の観点から、「どの更新をいつまでに当てたか」を説明できる状態にしたい
| 知りたいこと | 端末内だけで分かるか | 補足 |
|---|---|---|
| インストール済みのKB一覧 | 分かる | Get-HotFix や DISM で取得可能 |
| 未インストールを含む公開済みKB一覧 | 分からない | 公開情報（Catalog／更新履歴）から追う必要がある |
| OS以外（.NET/Office等）の更新 | 一部のみ | 製品ごとに追跡経路が分かれる |
先に結論
Windows Server 2016 向けに「公開済み更新を網羅した公式の完全一覧」は用意されていない、という整理で進めるのが現実的です。理由はシンプルで、Windows Update は「OSの累積更新」だけでなく、.NET Framework、各種コンポーネント、Microsoft Office、デバイスドライバ、セキュリティ定義ファイルなど、対象が分岐するためです。
そのため実務では、「完全一覧を作る」よりも、次のように発想を切り替えると運用が安定します。
- OS は更新履歴で「どの累積更新まで当てるか」を決め、原則として最新の累積更新へ寄せる
- 必要な更新の取得は Microsoft Update Catalog を起点にし、検索語を工夫して取りこぼしを減らす
- Office など別製品の更新は、製品別の更新情報に分けて管理する
現実的な代替策
Microsoft Update Catalog で公開済み更新を検索して拾う
オフライン更新で最も現実的なのが、Microsoft Update Catalog から更新をダウンロードして持ち込む方法です。Catalog は「更新プログラムそのもの（.msu/.cab）」を直接入手できるため、インターネットに出せない端末でも適用できます。
ただし、Catalog の検索にはクセがあります。特に覚えておきたいのが、検索結果が最大1000件で頭打ちになり、単純に「Windows Server 2016」と検索しただけでは最新が見えないことがある点です。
| 課題 | 起きること | 実務での回避策 |
|---|---|---|
| 検索結果が多すぎる | 1000件上限で途中までしか表示されない | 年/月、KB、更新種別（Cumulative/Servicing Stack）などで絞る |
| 別製品が混ざる | Windows 10 1607、ドライバ、他エディションが同時に出る | Products/Title/Architecture を確認し、Windows Server 2016 x64 を選ぶ |
| 前提更新が必要 | SSUを先に入れないとLCUが失敗する場合がある | まず最新のSSU、次に最新LCUの順を基本にし、詳細ページの前提条件を読む |
検索を分割するコツとして、Catalog 上で更新日が「YYYY/MM/DD」のように表示されることを利用し、年を含めた検索で結果を絞り込む方法がよく使われます。
Microsoft Update Catalog 検索例（Windows Server 2016）:
https://www.catalog.update.microsoft.com/Search.aspx?q=windows+server+2016
年で絞る検索例:
https://www.catalog.update.microsoft.com/Search.aspx?q=Windows+Server+2016+2020%2f
さらに精度を上げたい場合は、次のような検索語が有効です。
| 狙い | 検索語の例 | 意図 |
|---|---|---|
| 月例のOS累積更新を探す | Windows Server 2016 Cumulative Update 2024/ | 年で分割しつつ「Cumulative Update」を含めてOS寄りに寄せる |
| KBが分かっている | KB503xxxx Windows Server 2016 | 取りこぼしを最小化できる |
| SSUを探す | Windows Server 2016 Servicing Stack Update 2023/ | LCUの前に必要になりやすい更新を優先して見つける |
| .NET更新を探す | .NET Framework Windows Server 2016 2024/ | OSの更新履歴に出ない更新を拾う |
| 検索結果をもっと絞る | 14393 Cumulative Update | Windows Server 2016 の系統（OSビルド 14393）に寄せる |
Catalog で更新を選ぶときのチェックポイント
Catalog には似た名前の更新が並びます。オフライン運用では選定ミスがそのまま手戻りになるため、次のポイントをチェックしてからダウンロードすると安全です。
| チェック項目 | 見る場所 | 判断の目安 |
|---|---|---|
| Products | 検索結果の製品欄、詳細ページ | 「Windows Server 2016」に該当するものを優先 |
| Architecture | Title、詳細ページ | 通常は x64。x86 や ARM を持ち込まない |
| Classification | 詳細ページ | Security Updates / Update Rollups / Updates の違いを意識 |
| 置き換え関係 | 詳細ページの情報 | 「より新しい更新がある」場合は原則として新しい方へ寄せる |
| 前提条件 | 詳細ページの説明 | SSU の前提や、特定更新が必須かを確認する |
ファイル名が「Windows10.0-…」で始まることがあり、Server 2016 なのに Windows 10 と表示されて戸惑うことがありますが、同じ枝（version 1607 系統）の更新として配布されるためです。ファイル名よりも対象製品とアーキテクチャで判断しましょう。
| よくある勘違い | 実際はどうか | 対処 |
|---|---|---|
| 「Windows10.0」とあるからServerには使えない | 1607 系統の累積更新として共通配布されることがある | Products が Windows Server 2016 になっているか確認して選ぶ |
| 同じKBが複数あるのは重複 | x64/x86、対象製品、更新形態の違いで複数存在する | 対象OSとアーキテクチャに一致するものだけ選ぶ |
更新履歴ページで累積更新の流れを追う
Windows Server 2016 は Windows 10 version 1607 系統と同じ枝で更新が提供されており、Microsoft のサポートページにはOSビルドと対応するKB（累積更新）が時系列で並ぶ更新履歴ページがあります。
この更新履歴ページの価値は、個々のファイル一覧ではなく、「その月の累積更新を当てるとOSビルドがいくつになるか」が一目で分かる点にあります。現場では次のように使うと便利です。
- オフライン端末の現在のOSビルドを確認する
- 更新履歴で、目的の月（または最新）のOSビルドとKBを確認する
- そのKBを Catalog で検索して取得する
| 用語 | 意味 | オフライン更新での扱い |
|---|---|---|
| LCU | Latest Cumulative Update（累積更新） | 原則として最新LCUを当てれば、過去の同系列修正を包含する |
| SSU | Servicing Stack Update | 更新基盤の更新。古い環境ではLCU前に必要なことがある |
| OSビルド | 14393.xxxx のような番号 | 更新履歴上のKBと対応するため、棚卸しの軸になる |
| プレビュー更新 | 任意適用の品質更新 | セキュリティ目的なら通常は必須ではない。必要性を判断して採用 |
「累積更新は過去分を包含する」という性質を活かせば、公開済み更新を全部集めるより、最短ルートで最新状態へ近づけることができます。オフライン運用では、これが結果的に最も安全で工数が少ない方法になりやすいです。
オフライン端末へ更新を当てる実務フロー
「未適用を知りたい」＝「公開一覧を作りたい」となりがちですが、現場で回るのは次のフローです。ここでは、インターネット接続できない Windows Server 2016 を想定します。
| フェーズ | やること | コマンド・手段の例 | ポイント |
|---|---|---|---|
| 棚卸し | 現在のOSビルドと適用済みKBを収集 | winver systeminfo Get-HotFix dism /online /get-packages /format:table | Get-HotFix は一部が欠けることがあるため、DISM も併用すると確実 |
| 目標設定 | どこまで更新するか（例：今月の最新LCUまで）を決める | 更新履歴ページでKBとOSビルドを確認 | 「プレビュー更新」まで入れるかは運用方針で決める |
| 取得 | Catalog で必要な更新をダウンロード | KB番号、年/月、SSU、LCU、.NET で絞る | 同名の更新でも対象OS/アーキテクチャ違いがある。選定ミスに注意 |
| 適用 | オフライン端末へ持ち込み適用 | wusa.exe Windows10.0-KBxxxxxxx-x64.msu /quiet /norestart dism /online /add-package /packagepath:xxx.cab | 再起動が必要な更新が多い。適用順と再起動のタイミングを計画する |
| 検証 | OSビルドとKBが目標通りか確認 | winver Get-HotFix | Sort-Object HotFixID dism /online /get-packages | ビルド番号が合っているかを確認すると早い。イベントログも確認 |
棚卸し結果を残す
棚卸しの結果をファイルとして残したい場合は、PowerShell でCSVに出しておくと監査対応にも使いやすくなります。
# 適用済みKBの一覧をCSVに保存（例）
Get-HotFix |
Select-Object HotFixID, Description, InstalledOn, InstalledBy |
Sort-Object HotFixID |
Export-Csv -NoTypeInformation -Encoding UTF8 "C:\Temp\installed_kb.csv"
# OSビルドなども合わせてメモ（例）
Get-ComputerInfo |
Select-Object WindowsProductName, OsVersion, OsBuildNumber, OsHardwareAbstractionLayer |
Format-List
MSU と CAB の違いを押さえる
Catalog から落とせる更新は主に .msu と .cab です。現場で迷わないために、ざっくりした使い分けを覚えておくと便利です。
| 形式 | 特徴 | 代表的な適用方法 | メモ |
|---|---|---|---|
| MSU | Windows Update Standalone Installer で扱える | wusa.exe /quiet /norestart | ログはイベントログや CBS.log を確認 |
| CAB | DISM でパッケージとして追加する | dism /online /add-package | オフラインWIMへの組み込み（スリップストリーム）にも使う |
適用順の基本形
環境や時期によって細部は変わることがありますが、オフライン運用では次の順がトラブルを減らします。
- SSU（必要な場合）
- LCU（OSの累積更新）
- .NET Framework の更新
- その他の製品更新（Office 等）
再起動が必要な更新をまとめて適用したくなりますが、失敗時の切り分けを考えると、SSU と LCU の間、LCU と .NET の間は一度再起動しておくのが無難です。
ハマりどころ
更新履歴ページに載らない更新がある
更新履歴ページは便利ですが、掲載されるのは主にOS の累積更新です。ところが現実の運用では、OS 以外の更新も重要です。
| 対象 | 例 | 追い方の基本 | 注意点 |
|---|---|---|---|
| .NET Framework | 品質更新／セキュリティ更新 | Catalog で「.NET Framework」「Windows Server 2016」で検索 | OSのLCUとは別物。未適用だと脆弱性が残る |
| Microsoft Office | Excel 2016 のセキュリティ更新 | Office の更新情報／セキュリティ更新情報で追跡 | OS更新履歴には出ないことが多い |
| Defender 定義更新 | マルウェア定義 | ネットワーク設計により、内部更新サーバや定義配布を検討 | オフライン端末は定義の鮮度が落ちやすい |
| ドライバ更新 | NIC/ストレージ | 原則はベンダー配布を優先し、必要時のみCatalog | OS更新とは別に検証が必要 |
SSUとLCUの前後関係
Windows の更新は「更新を適用するための基盤（Servicing Stack）」自体が更新されることがあります。環境が古い場合、SSU が古いと LCU の適用に失敗するケースがあるため、オフライン運用では次の方針が安全です。
- まず SSU（必要な場合）を適用し、再起動する
- 次に LCU を適用し、再起動する
- その後に .NET 更新など、追加の更新を適用する
「必要な場合」の判断は、更新履歴やCatalog詳細の前提条件を確認するのが確実です。迷う場合は、SSU を先に入れる運用に寄せておくとトラブルが減ります。
「未適用」を完全にリストアップしようとして沼にはまる
公開済み更新の完全一覧を作ろうとすると、次の理由で手間が雪だるま式に増えます。
- 同じKBでも対象OSやアーキテクチャが複数ある
- 古い更新は新しい更新で置き換え（superseded）され、全部入れる必要がない
- OS以外の更新（.NET/Office/ドライバ）まで含めると対象範囲が広すぎる
そこでおすすめなのが、「公開済みの全件」を追うのではなく、目標を定めて差分だけを確実に埋めるアプローチです。
適用失敗時に見るログ
オフライン環境は、オンラインの自動回復が効きにくいぶん、失敗時の情報をどこから取るかが重要です。代表的なログの場所を押さえておくと、原因調査が早くなります。
| ログ | 場所の例 | 見るポイント |
|---|---|---|
| CBS.log | C:\Windows\Logs\CBS\CBS.log | パッケージ適用の成功/失敗、依存関係、破損検知など |
| DISM.log | C:\Windows\Logs\DISM\dism.log | DISM 実行時のエラーと詳細 |
| イベントログ | イベント ビューアー | セットアップ、WindowsUpdateClient、Servicing など |
おすすめの管理方法
管理単位を分けて、情報の軸を固定する
オフライン端末の更新管理は、「何を軸に追うか」を決めるだけで難易度が下がります。例えば、次のように軸を固定します。
- OS：OSビルド（14393.xxxx）と最新LCUのKB
- .NET：対象バージョン（例：4.8など）と最新の品質更新KB
- Office：製品（例：Office 2016）とセキュリティ更新のKB
| 管理対象 | 台帳に残す項目 | おすすめの更新方針 |
|---|---|---|
| Windows Server 2016（OS） | OSビルド、LCU KB、SSU KB、適用日 | 原則は最新LCUへ追随。例外は検証後に限定的に採用 |
| .NET Framework | 対象バージョン、KB、適用日 | OSの更新と同じ月で合わせると管理しやすい |
| Office | 製品/チャネル、KB、適用日 | セキュリティ更新を優先し、品質更新は必要性で判断 |
ダウンロードした更新を再利用できる形で保管する
オフライン更新は「毎月ゼロから探す」運用にすると確実に破綻します。おすすめは、ローカルに更新保管庫（リポジトリ）を作ることです。
- フォルダを年月で区切る（例：2026-01、2026-02）
- OS（SSU/LCU）と .NET と Office をサブフォルダで分ける
- 各フォルダに「この月に適用するKB一覧.txt」を残す
例：保管庫のフォルダ構成
\\FileServer\PatchRepo\2026-01\OS\
\\FileServer\PatchRepo\2026-01\DotNet\
\\FileServer\PatchRepo\2026-01\Office\
例：KB一覧.txt（イメージ）
- SSU: KB50xxxxxx
- LCU: KB50yyyyyy
- .NET: KB50zzzzzz
こうしておくと、次回以降は「前回のフォルダを起点に、今月分を追加していく」だけで済みます。監査対応でも「何を配布したか」を説明しやすくなります。
オフライン更新の安全策
パッチ適用は成功して当たり前に見えますが、オフライン端末は復旧に時間がかかることが多いです。次の安全策をセットにしておくと、事故の確率を下げられます。
- 更新前にスナップショットやバックアップを取る（仮想環境なら特に有効）
- 本番機に当てる前に、同構成の検証機で適用テストをする
- 適用するKBと適用順を「手順書」として固定し、属人化を防ぐ
- 適用後は OSビルド と主要サービスの動作確認を必ず行う
よくある質問
Catalog で見つかった更新を全部入れれば安全ですか
更新を闇雲に全部入れるのはおすすめしません。特にドライバ更新は環境依存が強く、OS更新のつもりで適用すると不具合の原因になります。基本は、OSはSSUとLCUを中心に最新へ寄せる、追加の更新は必要性を判断して採用する、という運用が安全です。
累積更新だけ入れれば他は不要ですか
OSの脆弱性対策としては累積更新（LCU）が中心ですが、.NET Framework や Office を使っているなら、それぞれのセキュリティ更新も別に必要です。更新履歴ページはOS中心なので、別製品の更新は別レーンで管理してください。
どのKBが未適用かを自動で判定できますか
「公開済み更新の完全一覧」が公式に提供されていない以上、完全自動での突合は難易度が高いです。一方で、運用を「最新LCUへ寄せる」方針にすれば、未適用判定はかなり単純化できます。現在のOSビルドと、更新履歴上の目標ビルドを比較し、差分のKB（主にLCU/SSU）を持ち込む、という考え方が現実的です。
インターネット非接続端末が複数台ある場合はどうすべきですか
台数が増えるほど、USB持ち込みの運用はミスが起きやすくなります。もし端末が社内LANには接続できるなら、内部の更新配布サーバ（WSUS等）を用意して、社内で一元配布する方が再現性が上がります。完全にスタンドアロンでなければならない場合でも、最低限「更新保管庫」と「適用手順のテンプレ化」は必須です。
まとめ
Windows Server 2016 の「公開済み（未適用含む）Windows Update 一覧」を完全に網羅するのは現実的ではありません。代わりに、更新履歴でOSの累積更新の流れを押さえ、Microsoft Update Catalog で検索語を工夫して必要なKBだけを確実に集める、という手順がオフライン運用では最も強力です。
まずは「棚卸し → 目標設定 → Catalog で取得 → 適用 → 検証」をテンプレ化し、毎月の作業を“儀式化”してしまいましょう。更新管理は、情報を全部集めるより、再現性のある運用に落とし込むことが成果につながります。
コメント