Windows Server 2022 が社内の閉域網や検証ネットワークで稼働していて、サーバー自身はインターネットに接続できない――それでも脆弱性対策として「最新の Windows Update（主に累積更新プログラム）」を適用したい場面は多いです。本記事では、別PCで更新プログラムを入手してUSB等で持ち込み、前提条件・既知の問題を確認してオフライン更新するための手順とつまずきポイントをまとめます。
ここでいうオフラインは、起動中のサーバーがインターネットに接続できない状態です。DISMの /Online は「現在起動しているOS」を意味し、インターネット接続の指定ではありません。マウントしたWIMなどの「オフラインOSイメージ」への更新とは手順・前提条件を分けて確認してください。
Windows Server 2022は「インターネット接続なし」でも最新更新を適用できる
結論から言うと、Windows Server 2022（Standard / Datacenter など）がオフライン環境でも、最新の累積更新プログラム（LCU）を含む Windows Update を適用できます。やり方はシンプルで、インターネットに出られる別PCで更新ファイル（.msu/.cab）を入手し、USBメモリ等でオフラインサーバーへ転送してインストールします。
オフライン環境であってもパッチ適用が重要なのは、USBや持ち込み端末、内部ネットワークからの侵入、横展開など「インターネット起因ではない攻撃」も現実的だからです。特にサーバーは役割（AD DS、ファイルサーバー、Hyper-V、IISなど）によっては停止できる時間が限られるため、安全に・手戻りなく更新するための段取りが欠かせません。
全体像：オフライン更新の“王道フロー”
| 工程 | 実施する端末 | 目的 | ポイント |
|---|---|---|---|
| KB番号の特定 | インターネット接続できるPC | 最新の累積更新（LCU）と前提条件を把握 | Update Historyで製品/ビルドを間違えない |
| 更新ファイルの入手 | インターネット接続できるPC | Microsoft Update Catalogから正しいパッケージをダウンロード | Server 2022のx64用か、対象製品を確認 |
| 整合性チェック | インターネット接続できるPC | 改ざん・誤ダウンロードを防ぐ | デジタル署名/ハッシュを確認 |
| 持ち込み・検疫 | USB/共有フォルダ等 | オフライン環境へ安全に搬入 | ウイルススキャン、改ざん防止、ログ保全 |
| インストール | オフラインのWindows Server 2022 | 更新適用（.msuはwusa、.cabはDISM） | 対象KBの前提条件、終了結果、再起動計画 |
| 適用確認 | オフラインのWindows Server 2022 | KB・ビルド番号・再起動要否の確認 | Get-HotFix / DISM / winver で二重確認 |
事前準備：失敗しないために最初に確認すること
「更新ファイルを持ってきたのに適用できない」「途中でエラーが出た」を避けるには、ダウンロード前の確認が重要です。特に Windows Server 2022 は同じ“Server 2022”でも、適用対象（製品表記・アーキテクチャ・更新の種類）を間違えると簡単に“適用不可”になります。
確認1：OSのエディション/インストール形態/アーキテクチャ
| 確認項目 | 確認方法（例） | なぜ必要？ |
|---|---|---|
| エディション（Standard/Datacenter） | systeminfo | OS名・バージョンを確認。表示項目名はOS言語により異なる |
| Server CoreかGUI（Desktop Experience）か | 画面有無、または機能確認 | 手順自体は同じだが、操作方法が変わる |
| アーキテクチャ（Server 2022はx64） | echo %PROCESSOR_ARCHITECTURE% | 別製品や別アーキテクチャの更新を選ばない |
確認2：現在のOSビルドと、既に入っているKB
“最新更新”と言っても、更新は積み重なります。まず現状を把握し、更新順序や前提条件の不足を見落とさないようにします。
Windows Server 2022 は、Update History上でも「OS build 20348.xxxx」として扱われます。例えば手元のビルドが 17763 なら Server 2019 系、14393 なら Server 2016 系の可能性が高く、「Server 2022用のKBを持ってきても適用できない」典型パターンになります。
| 目的 | コマンド例 | 見どころ |
|---|---|---|
| OSビルド表示 | winver | 「20348.xxxx」かどうか、更新後にビルドが上がるか |
| インストール済み更新（KB）の確認 | powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20" | 直近の累積更新が入っているか |
| パッケージ状態の確認 | dism /Online /Get-Packages /Format:Table | more | Pending状態がないか、適用済みか |
確認3：バックアップとメンテナンスウィンドウ
- 可能なら更新前にスナップショット（仮想環境）またはバックアップを取得します。
- ドメインコントローラーやクラスターなど、役割によっては手順が変わるため、事前に復旧手順も用意します。
- 「再起動が必要」になる前提で、停止できる時間と影響範囲を整理しておくと、運用が安定します。
更新プログラム入手の王道：Update Historyで最新KBを確認 → Microsoft Update Catalogでダウンロード
オフライン更新の最短ルートは、Windows Server 2022 の更新履歴（Update History）で“最新の累積更新（KB番号）”を特定し、そのKBを Microsoft Update Catalog で検索してダウンロードする方法です。製品名で探すより、KB番号で探す方が確実です。
ステップ1：Update Historyで対象のKB番号を特定する
更新履歴ページでは、次の点を意識して確認します。
- 最新の「累積更新プログラム（Cumulative Update）」のKB番号（例：KB50xxxxxx の形式）
- 前提条件（必要に応じてServicing Stack Update（SSU）や関連更新）
- 通常版か、プレビュー版（Preview）か
運用上は、原則としてプレビューではなく、定例の累積更新（いわゆるPatch Tuesdayの更新）を選ぶのが無難です。緊急の帯域外（Out-of-band）更新が出ている場合は、同じ手順で適用できます。
ステップ2：Microsoft Update CatalogでKB検索し、正しいパッケージを選ぶ
Update Catalog では「KB番号」で検索します。検索結果には似た名称が並ぶことがあり、選び間違えると適用できません。以下の観点で見極めます。
| チェックポイント | 見るべき場所 | 判断のコツ |
|---|---|---|
| 対象製品 | 製品名（Product） | 「Windows Server 2022」または「Microsoft server operating system version 21H2」相当になっているか |
| 分類 | Classification | 多くは「Security Updates」または「Updates」 |
| アーキテクチャ | Title / Products / Details | Windows Server 2022向けのx64を確認 |
| サイズ/更新日 | Last Updated / Size | 日付やサイズだけで選ばず、製品・アーキテクチャ・KBの適用条件を照合 |
「Catalogに .msu が見当たらない」と感じるケースの多くは、製品名の表記ゆれで検索結果が散らばっている、またはKB番号を使わず製品名だけで探していることが原因です。迷ったら、更新履歴で確認したKB番号をそのまま検索するのが確実です。
ステップ3：必要になりやすい更新の種類を把握する
一般的に「まずは累積更新だけでOK」と言われがちですが、サーバー用途では追加で意識したい更新がいくつかあります。
| 種類 | 目的 | 補足 |
|---|---|---|
| 累積更新プログラム（LCU） | OSの主要なセキュリティ/品質修正 | 毎月更新。まずこれが本命 |
| Servicing Stack Update（SSU） | 更新を適用する仕組み自体の更新 | Server 2022の現在のLCUはSSUを統合。別途の前提更新が必要かは対象KBを確認 |
| .NET Framework の累積更新 | .NET関連の脆弱性/不具合修正 | 役割やアプリによって重要度が上がる |
| Microsoft Defender の定義更新 | マルウェア検知の最新化 | オフラインの場合、定義ファイルを別途持ち込む運用が必要 |
ダウンロードした更新ファイルの整合性を確認する（改ざん対策）
Update Catalog から入手したファイルでも、運用上は「正しいファイルを取れているか」「壊れていないか」を確認しておくと、後工程の切り分けが速くなります。特に閉域では再ダウンロードが簡単ではないため、持ち込む前にチェックしておくのがおすすめです。
| 確認方法 | コマンド例 | ポイント |
|---|---|---|
| デジタル署名の確認 | powershell -NoProfile -Command "Get-AuthenticodeSignature 'C:\Temp\LCU-KBxxxxxxx-x64.msu' | Format-List" | 署名者・検証結果を確認。検証できない場合は理由を調べ、確認を省略しない |
| ハッシュ値の計算（社内手順がある場合） | certutil -hashfile "C:\Temp\LCU-KBxxxxxxx-x64.msu" SHA256 | 搬入前後のSHA256を照合。自分で算出したハッシュだけでは正規配布元の証明にならない |
更新ファイルの種類とインストール方法（.msu / .cab）
Update Catalog から入手できるファイルは主に .msu と .cab です。どちらもオフラインで適用できますが、扱い方が異なります。
| 拡張子 | よくある中身 | 推奨インストール方法 | コマンド例 | 注意点 |
|---|---|---|---|---|
| .msu | Windows Update Standalone Installer用パッケージ | wusa（またはダブルクリック） | wusa.exe "C:\Updates\windows10.0-kbXXXXXXX-x64.msu" /quiet /norestart | 適用後に再起動が必要なことが多い |
| .cab | DISMで追加できるパッケージ | DISM /Online /Add-Package | dism /Online /Add-Package /PackagePath:"C:\Updates\KBXXXXXXX.cab" | 対象KBで案内されたパッケージと前提条件に従う |
通常は配布されたMSUをそのまま使います。KBの個別手順で指示されない限り、MSUを展開して中のCABを無差別にインストールしないでください。
オフライン環境への持ち込み：USB運用で意識したいセキュリティ
「更新ファイルを持ってくる」という作業は、同時に“外部媒体の持ち込み”でもあります。更新を安全にするつもりが、USB経由でリスクを持ち込むのは本末転倒です。
- 更新ファイルのダウンロードは、必ずMicrosoftの公式経路（Update Catalog）から行う。
- 持ち込み前に、インターネット接続PC側でウイルススキャン（可能ならEDR）を実施する。
- 更新ファイル専用のUSBを用意し、普段使いのUSBと混ぜない。
- オフライン側でのコピー先は、例：
C:\Updates\YYYYMM\のように月別に整理し、ログとセットで保管する。 - オフライン側での作業は、できれば管理者用の作業手順書（紙/社内Wiki）に沿って実施し、作業者判断の余地を減らす。
実作業：Windows Server 2022 に累積更新プログラムをオフライン適用する手順
ここからは、実際に適用する手順を“現場で迷わない”粒度で整理します。基本は「前提条件→本体（LCU）→必要に応じて追加（.NETなど）→再起動→確認」です。MSUの実行だけで完了とせず、終了結果・再起動・ビルドと業務サービスの確認まで行います。
手順1：更新ファイルを所定フォルダへ配置する
例として、オフラインサーバーのローカルに次のようなフォルダを作って格納します。
C:\Updates\2025-12\
windows10.0-kbXXXXXXX-x64.msu
対象に応じた.NET更新ファイル
上の名前は例です。実際に取得したファイル名を使い、KB・対象OS・前提更新・必要な再起動を作業台帳に記録します。単なる名前順で適用順序を決めません。
手順2：再起動保留（Pending Reboot）がないか確認する
前回の更新や役割追加の再起動待ちは、保守時間内に解消します。次の確認はCBSの一項目だけであり、Falseでも「再起動不要」の完全な判定にはなりません。更新画面・役割追加結果・パッケージ状態も確認してください。
powershell -NoProfile -Command "Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'"手順3：SSU統合と前提更新の対象を確認する
Server 2022の現在の累積更新は、SSUとLCUを組み合わせたパッケージです。「必ず別のSSUを先に入れる」とは限りません。対象KBの「Before you install this update」を読み、現在のビルドに必要な前提更新だけを適用します。SSUはインストール後に削除できません。
KB記事にある Prerequisite for offline OS image servicing は、マウントしたOSイメージを保守する場合の条件です。「インターネットに接続しない稼働中サーバー」と同一視しないでください。イメージ更新を行う場合は、そのKBで指定された最低SSU／LCUをイメージに含めます。
手順4：累積更新プログラム（LCU）を適用する
wusa.exe "C:\Updates\2025-12\windows10.0-kbXXXXXXX-x64.msu" /quiet /norestart手順5：必要に応じて .NET 更新などを追加適用する
業務アプリが .NET を使っている場合、.NETの累積更新も同じタイミングで入れる運用が多いです。
wusa.exe "C:\Updates\2025-12\03-dotnet-KBxxxxxxx-x64.msu" /quiet /norestart手順6：再起動し、適用を確定させる
更新は再起動で確定するものが多いため、処理終了と結果を確認してから計画通り再起動します。次は即時再起動の例です。利用者への通知・業務停止・クラスタ等の役割別作業を済ませてから実行してください。
shutdown /r /t 0適用後の確認：更新が入ったかを“二重で”チェックする
「インストールは成功と出たが、実は入っていない」「別のKBを入れてしまった」を避けるため、複数の観点で確認します。
| 確認観点 | コマンド/操作 | 期待する結果 |
|---|---|---|
| KBが入っているか | powershell -NoProfile -Command "Get-HotFix | Where-Object {$_.HotFixID -eq 'KBXXXXXXX'}" | 該当KBが表示される |
| OSビルドが上がったか | winver | ビルド番号が更新後の値になっている |
| パッケージ状態 | dism /Online /Get-Packages /Format:Table | 対象パッケージがInstalledか確認。名前にKB番号が含まれない場合もある |
| イベントログ | イベントビューア（WindowsUpdateClient等） | 更新の成功/失敗が記録されている |
ログの見方：エラー時に見るべき場所を押さえる
オフライン環境では「外部に問い合わせられない」「再現しづらい」ことも多いので、ログの場所を事前に把握しておくと強いです。
| ログ | 場所 | 用途 |
|---|---|---|
| DISMログ | C:\Windows\Logs\DISM\dism.log | DISMでの追加/削除が失敗したときの原因確認 |
| CBSログ | C:\Windows\Logs\CBS\CBS.log | コンポーネントストアや更新適用全般の詳細 |
| イベントログ | イベントビューア | WindowsUpdateClientなどでエラーコードの手がかりを得る |
ログは容量が大きくなることがあるため、障害解析のためにコピーする場合は、更新用の作業フォルダと分けて保管すると管理しやすいです。
よくあるつまずきと対処法（オフライン更新の現場QA）
オフライン更新で詰まりやすいポイントは、ほぼパターン化しています。症状から原因を切り分け、最短で復旧できるようにしておきましょう。
| 症状 | ありがちな原因 | 対処 |
|---|---|---|
| Catalogで目的の更新が見つからない | 製品名で探している、表記ゆれに吸われている | Update HistoryでKB番号を特定→CatalogでKB検索に切り替える |
| 「この更新プログラムはこのコンピューターに適用できません」 | 製品/アーキテクチャ違い、既に適用済み、前提SSU不足 | Server 2022 x64・現在のビルド・対象KBの前提条件を再確認。既に置き換えられた更新も確認 |
| wusaが成功したのに反映されない | 再起動未実施、保留状態（Pending） | 予定した再起動後にビルドとログを確認。破損修復が必要なら閉域で利用できる適合した修復ソースを準備 |
| DISMでエラーが出る | 順序ミス、コンポーネントストア破損、ディスク不足 | 対象KBの前提条件、DISM/CBSログ、空き容量を確認 |
| 更新適用に時間がかかる/止まって見える | サーバー性能、役割、ストレージ速度、バックグラウンド処理 | “無反応”に見えても処理中のことがある。ログとCPU/I/Oを見て判断 |
ロールバック：統合SSU＋LCUはwusa /uninstallで削除できない
更新前に既知の問題・業務アプリの対応状況を確認し、検証と復旧用バックアップを準備します。「最新なら必ず問題ない」とは限りません。更新を取り消すとセキュリティ修正も失われるため、障害との関係とメーカーの案内を確認して判断します。
Microsoftは、SSUとLCUを統合したパッケージでは wusa.exe /uninstall は使えず、SSU自体も削除できないと案内しています。LCUを削除する場合は対象KBの指示に従い、DISMで正確なLCUパッケージ名を確認します。
DISM /Online /Get-Packages /Format:Table削除が必要と確認できた場合の書式は次のとおりです。引用符内は、確認した対象LCUの実際のパッケージ名に置き換えます。名前を推測して実行したり、SSUや無関係なパッケージを指定したりしないでください。
DISM /Online /Remove-Package /PackageName:"確認したLCUのパッケージ名"削除可否・再起動・復旧方法はその更新とサーバーの役割に依存します。バックアップ／スナップショットも、AD DSやクラスタなどでサポートされた復旧手順を使います。
Microsoft Defenderの定義更新をオフラインで更新する（必要な場合）
Windows Server 2022 では Microsoft Defender Antivirus が有効な構成も多く、定義ファイル（シグネチャ）の鮮度がセキュリティに直結します。インターネットに出られない環境では、OS更新（LCU）とは別に定義更新の運用を考えます。
| 方法 | 概要 | 例 |
|---|---|---|
| 定義更新ファイルを持ち込んで実行 | オンラインPCで定義更新ファイルを入手し、オフラインへ転送して実行 | 取得したファイルをオフラインで実行し更新 |
| 共有フォルダを更新ソースにする | 閉域内に定義更新の置き場を作り、そこから更新 | powershell -NoProfile -Command "Update-MpSignature -UpdateSource FileShares" |
Defenderの定義更新は頻度が高いため、月次のLCUとは分けて運用設計すると回しやすいです。
複数台を運用するなら：オフライン更新を“仕組み化”すると楽になる
サーバーが1台なら手作業でも回りますが、複数台になると「毎月ダウンロード→コピー→手動実行」は属人化しがちです。次のように仕組み化すると、更新の品質と作業速度が上がります。
案1：更新ファイルの保管場所を決め、資産として管理する
- オンラインPCでダウンロードした更新ファイルを、月別・KB別に整理して保管する。
- 「どのサーバーに、いつ、どのKBを適用したか」を台帳（Excel等）で残す。
- 障害時にロールバックできるよう、更新前のバックアップ/スナップショットと紐づける。
案2：自動化は終了結果と再起動を管理する
フォルダ内のMSUを名前順にすべて実行して最後に「完了」と表示するだけでは、失敗や再起動待ちを見逃します。自動化する場合は、対象サーバー・適用するKB一覧・前提条件を固定し、一件ずつ終了コードとログを記録してください。失敗時は後続を止め、再起動が必要なら承認済みの保守手順へ移ります。
手動で検証した適用手順を基にスクリプトを作成し、組織の実行ポリシーを一律に回避する設定は付けません。自動化しても適用後のビルド・業務サービスの確認は必要です。
案3：内部ネットワークにWSUS等を置き、サーバーは“社内更新サーバー”から取る
オフラインと言っても「インターネットに出られないだけで、社内ネットワークには出られる」ケースもあります。その場合、WSUS（Windows Server Update Services）などの更新基盤を用意し、サーバーは社内更新サーバーから更新を受け取る設計にすると、月次運用が格段に楽になります。完全閉域では、組織の持ち込み基準とMicrosoftの切断ネットワーク向け手順に沿った構成・移送を設計します。運用中の更新サーバーを安易に外部ネットワークへ接続し直さないでください。
まとめ：KBの条件確認から適用後の動作確認まで行う
Windows Server 2022 がインターネット接続できない環境でも、最新の累積更新プログラムを適用することは可能です。ポイントは、Update Historyで最新KBを特定し、Microsoft Update CatalogでKB検索して正しい更新ファイルを入手すること、そしてSSUなど前提条件と適用順序を意識してオフラインサーバーへインストールすることです。
毎月、対象KBの前提条件と既知の問題を確認し直してください。検証環境での確認、バックアップ、保守時間、結果記録をセットにして運用します。
公式情報
Microsoft：Server 2022更新のSSU統合・オフラインイメージ前提条件・LCU削除方法。個々のKB番号は例であり、適用する更新の最新記事を確認してください。
Microsoft：2026年10月のServer 2022更新情報（2026年10月19日確認）。今後の更新では前提条件や既知の問題が変わる場合があります。
コメント