閉域WSUSで月例パッチを取り込む方法｜個別インポート不可・wsusutil Export/Import運用

閉域（隔離）ネットワークのWSUSに月例パッチだけを取り込みたいのに、オンラインのようにKB単位で直接インポートできず困るケースは多いです。本記事では、WSUSが「個別パッチの直接取り込み」に対応しない理由を整理し、運用で破綻しにくいExport/Import中心の手順とコツをまとめます。

結論：閉域WSUSに「月例パッチを個別に直接インポート」はできない

まず結論からです。インターネット非接続（閉域／隔離）環境のWSUSサーバーに対して、オンラインWSUSカタログのように「必要な更新だけを個別に直接インポートする」機能は、WSUSとしては基本的に想定されていません。

• WSUSは、質問のような「KB（個別パッチ）だけをファイルで取り込む」方式に対応していない
• 閉域環境に更新を持ち込む“サポートされている正攻法”は、wsusutil.exe の Export / Import が中心
• Microsoft Update Catalogから手動でダウンロードした .msu は、そのままWSUSに取り込めない

ポイント
「閉域WSUSにパッチファイルを置けば勝手に配布できる」タイプの発想は、WSUSの仕組みとズレやすく、監査・保守・障害対応で詰まりがちです。設計段階で“Export/Import前提”に寄せるほど、長期運用が安定します。

なぜWSUSは「.msuを拾ってきて取り込む」運用ができないのか

WSUSが管理しているのは、単なる更新ファイル（.msu）そのものではありません。WSUSは「更新をクライアントに配布し、適用判定を行い、承認・拒否・レポートを回す」ために、更新ごとのメタデータ（適用条件や依存関係など）を含む一連の情報を持つ必要があります。

WSUSが実際に保持している要素

要素	中身の例	主な保存先	閉域へ持ち込む際の考え方
更新メタデータ	更新ID、適用対象、前提条件、置き換え関係（superseded）、タイトル/説明、分類/製品	SUSDB（WID/SQL）	wsusutil.exe export/importで移送するのが基本
更新コンテンツ（バイナリ）	実際の更新ファイル一式	WSUSContent（コンテンツ保存フォルダ）	閉域側へファイルコピーが必要（ダウンロードできないため）
承認状態	Approve/Decline、期限切れ、グループ別承認	SUSDB	オンライン側で承認方針を確定し、閉域側でも同じ状態を再現する設計にする
同期・リビジョン情報	更新の改訂（Revision）、同期履歴	SUSDB	世代差があると事故の原因。オンライン/オフラインで揃える

Microsoft Update Catalogから落とせる .msu は、クライアント端末に「単体で適用」することを主目的にしたパッケージです。一方、WSUSは、更新を“配布サービス”として扱うため、メタデータと配布の整合性が非常に重要です。ここが噛み合わないため、.msuを「WSUSに投げ込んで取り込む」ような公式の仕組みがありません。

「Microsoft Update Catalogで手動DL → WSUSへ取り込み」が成立しない落とし穴

「必要なKBだけMicrosoft Update Catalogからダウンロードして、閉域WSUSに入れたい」という発想は自然ですが、実際には次の理由で行き詰まります。

• WSUSには、.msu（単体更新パッケージ）を“ファイルとして”インポートするサポート手段がない
• WSUSコンソールの［更新のインポート］は、基本的にカタログ連携（オンライン）前提で、閉域で再現しづらい
• メタデータ（適用条件・置き換え関係・依存関係）がWSUSに登録されないと、クライアントは「その更新を必要とする」と判定できない
• 仮に何らかの非公式手段で登録できたとしても、サポート外・監査で説明しづらい・トラブル時に戻れない

閉域で“WSUSとして”月例パッチ運用を安定させたいなら、「オンライン側でWSUSを正しく同期し、Export/Importで閉域側へ運ぶ」に寄せたほうが、結局は手戻りが減ります。

実務で安定する推奨構成：オンラインWSUS＋オフラインWSUSの2台運用

閉域WSUS運用で現場が落ち着きやすいのは、「オンラインで更新を集約し、オフラインへ搬送する」2台構成です。

方式比較（何が現実的か）

方式	閉域での現実性	メリット	デメリット／注意点
オンラインWSUS → Export/Import → オフラインWSUS	高い	サポートされる範囲で説明しやすい／監査に強い／運用が定型化できる	媒体搬送と手順管理が必要／初回はデータ量が大きい
Microsoft Update Catalogからmsuを集めて手動配布（WSUS非使用）	中～低	KB単位の選別はしやすい	適用判定・承認・レポートが別物になる／端末台数が増えるほど破綻
WSUSを1台だけ（閉域側）に置き、何らかの方法で個別インポートを試みる	低い	構成は単純に見える	サポート外になりやすい／再現性が低い／更新の整合性が崩れやすい
構成管理製品（例：別の配布基盤）で更新配布	要件次第	閉域前提の運用機能が揃うことがある	導入コスト・設計が重い／既存WSUS前提の環境では移行が必要

2台運用にすると、「オンライン側で必要な更新だけを集める」「閉域側では配布だけに集中する」という役割分担ができ、トラブルシュートもしやすくなります。

運用の前提：オンライン／オフラインで“揃えるべきもの”

Export/Import運用で事故が起きやすい原因の多くは、オンライン側とオフライン側の“前提の違い”です。閉域環境ほどやり直しが効かないため、最初に揃える項目を決めておくのが重要です。

揃える項目	なぜ重要か	実務的な揃え方
WSUSのバージョン／適用済み更新	メタデータ解釈やDB差分で詰まりやすい	同じWindows Server世代＋同じWSUS更新適用を基本にする
製品（Products）と分類（Classifications）	同期対象がズレると“必要更新が見えない”が起きる	オンライン/オフラインで同一に固定し、途中変更は手順化する
言語設定（Language）	コンテンツ量と適合判定に影響する	必要言語だけに絞る。閉域で追加言語が必要なら事前に決める
コンテンツ保存先（WSUSContentのパス）	コピーと整合性確認が複雑になる	可能なら両環境で同じドライブ/パス設計にする
承認ポリシー／コンピューターグループ設計	閉域側で「承認漏れ」「意図しない承認」が起きやすい	オンライン側で承認ルールを固め、閉域側でも同じ分類で運用する

手順全体像：月例パッチを“必要な分だけ”集めて閉域WSUSへ持ち込む

ここからは、2台構成（オンラインWSUS＋オフラインWSUS）を前提に、月例パッチを閉域へ持ち込む流れを具体化します。ポイントは「オンライン側で“必要な更新だけ”に絞り込み、その状態をExport/Importで搬送する」ことです。

ステップ1：オンラインWSUSで同期対象を絞り、月例パッチを確定させる

閉域へ持ち込む量を減らすには、オンラインWSUS側で最初からスコープを狭めるのが有効です。

• 製品は「実際に閉域で使っているOS/サーバー/Office等」だけに絞る
• 分類は原則「Security Updates」「Critical Updates」「Updates」など、運用方針に沿って絞る（Drivers等は慎重に）
• 不要な言語を外す（多言語を入れるほどコンテンツが増える）

月例パッチの“個別取り込み”に近い運用を実現したい場合は、次の発想が現実的です。

• 「KB単位で“承認対象を選ぶ”」ことで、結果的に“必要な分だけ配る”
• オンラインWSUSでKBを検索し、対象グループにだけ承認する
• 承認した更新のコンテンツをサーバーにダウンロードしてから搬送する

ステップ2：オンラインWSUSで“コンテンツが揃っている状態”を作る

閉域側はインターネットに出られないため、オンラインWSUSで「承認した更新のコンテンツがWSUSContentに揃っている」状態にしておくのが重要です。

• WSUSの設定で「更新ファイルをローカルに保存（ダウンロード）」する構成にしておく
• 承認した更新が実際にダウンロード済みかをWSUSコンソール上で確認する
• 不要な更新（期限切れ、置き換え済みなど）を整理し、搬送サイズを抑える

運用のコツ
月例で増えた分だけ搬送したいなら、毎月の作業前に「サーバークリーンアップ」「不要更新のDecline」「言語・製品の見直し（むやみに増やさない）」を定例化すると、WSUSContentの肥大化が抑えられます。

ステップ3：オンラインWSUSでExport（メタデータ）を作る

オンラインWSUSで wsusutil.exe を使い、閉域へ持ち込むためのエクスポートファイルを作成します。実行はWSUSサーバー上の管理者権限で行います。

REM オンラインWSUSで実行（例）
cd "C:\Program Files\Update Services\Tools"

REM エクスポート（CABとログを作成）
wsusutil.exe export D:\WSUS_Transfer\wsus_export_2026-01.cab D:\WSUS_Transfer\wsus_export_2026-01.log

エクスポートのログは、監査や障害対応で非常に役に立ちます。閉域へ搬送する媒体には、CABだけでなくログも一緒に保管する運用がおすすめです。

ステップ4：WSUSContent（コンテンツ）を媒体へコピーする

閉域側で更新ファイルをダウンロードできない以上、更新コンテンツをコピーで持ち込む必要があります。大量ファイルの転送には robocopy が実務向きです。

REM オンラインWSUS → 搬送媒体へコピー（例）
robocopy D:\WSUS\WsusContent E:\Transfer\WsusContent /MIR /Z /R:3 /W:5 /FFT /NP /LOG:E:\Transfer\robocopy_content.log

• /MIR はミラーリングです。搬送先のフォルダ内容が同期されるため、使う先を間違えると削除が発生します。運用手順で“必ず媒体側を宛先にする”ルール化が重要です。
• 媒体コピーのログも残しておくと、欠損・途中失敗の切り分けが速くなります。

閉域（オフライン）WSUS側の手順：インポートして配布できる状態にする

ステップ5：オフラインWSUSの初期状態を整える

閉域WSUSは、原則「Microsoft Updateへ同期しない」構成で運用します。ここで重要なのは、オンライン側と同じ製品/分類/言語に揃えておくことです。

• 製品（Products）・分類（Classifications）・言語（Language）をオンライン側と一致させる
• 同期スケジュールは無効化（もしくは空運用）し、誤って外部同期を試みないようにする
• コンテンツ保存先（WSUSContentのパス）を設計通りにする

ステップ6：コンテンツを閉域WSUSへ配置する

媒体にコピーしたWSUSContentを、閉域WSUSのコンテンツ保存先へコピーします。

REM 搬送媒体 → オフラインWSUSへコピー（例）
robocopy E:\Transfer\WsusContent D:\WSUS\WsusContent /MIR /Z /R:3 /W:5 /FFT /NP /LOG:D:\WSUS_Transfer\robocopy_content_import.log

コピー先のパスが設計と違う場合は、後続の整合性確認や運用で混乱しがちです。可能な限りオンライン/オフラインで同じパスに揃えると、作業手順が単純になります。

ステップ7：オフラインWSUSでImport（メタデータ）を取り込む

次に、オンラインWSUSで作成したCABを、閉域WSUSでインポートします。

REM オフラインWSUSで実行（例）
cd "C:\Program Files\Update Services\Tools"

wsusutil.exe import E:\Transfer\wsus_export_2026-01.cab D:\WSUS_Transfer\wsus_import_2026-01.log

インポート後、WSUSコンソールで該当月の更新が認識されているか、想定どおりの製品・分類に紐づいているかを確認します。ここでズレている場合は、ほとんどが「製品/分類/言語の不一致」か「世代差」です。

ステップ8：承認（Approve）の扱いを“運用として固定”する

閉域WSUSで月例パッチを安全に回すなら、承認の方針を事前に固定しておくのが重要です。おすすめは次のような二段構えです。

1. オンライン側：KB単位で対象更新を絞り込み、テストグループに承認して動作確認
2. 閉域側：同じKB（同じ意図）を同じグループへ承認し、本番展開

「オンラインで検証したのに、閉域では別の更新が配られた」「承認漏れで当月の累積更新が出ない」といった事故は、承認のルールが曖昧なときに起きがちです。承認は“作業”ではなく“設計”として扱うと安定します。

オンライン側で「必要な更新だけ」を集める現実解：Import-WsusUpdateの位置づけ

オンラインWSUSで“必要な更新だけ”を揃える際に、WSUSコンソールの［更新のインポート］が使いづらい（環境や制約で動かない）ことがあります。そのため実務では、Microsoft Update Catalogからの取り込みを補助するPowerShellツールを使うケースがあります。代表例として Import-WsusUpdate（PSWSUSなどのモジュール／スクリプト）が挙げられます。

ただし、ここは誤解しやすいポイントです。

• Import-WsusUpdateは「オンラインWSUSへ、カタログ由来の更新を登録する」用途
• 閉域WSUSへ“直接”個別パッチを入れる道具ではない
• 導入・利用は便利ですが、組織のポリシー上「追加ツール禁止」「スクリプトは審査が必要」などの制約がある場合は、無理に使わず手順をシンプルにした方が強いです

整理すると、Import-WsusUpdateは「オンライン側で“集める工程”を楽にする」ための選択肢であり、閉域への持ち込みは結局 Export/Import＋コンテンツ搬送が軸になります。

つまずきやすいポイントと対策（閉域WSUS運用のチェックリスト）

閉域WSUSは「一度ズレると復旧コストが大きい」ため、よくある不具合を事前に潰すチェックが有効です。

症状	ありがちな原因	対策
インポート後に更新が表示されない／少ない	製品/分類/言語がオンラインと不一致	両WSUSの設定を突合し、同期スコープを揃える
クライアントが「更新なし」になってしまう	GPOのWSUS指定先が違う／SSLやポート設定の不一致	GPO・レジストリ・ポート（8530/8531）・証明書を再確認
ダウンロードが進まない／配布が遅い	WSUSContentが欠損している／コピー失敗	robocopyログで欠損確認。媒体の健全性もチェック
ディスクがすぐ逼迫する	不要製品/言語を同期／Express更新を有効にしている	対象を絞り、不要更新を整理。設計で容量を見積もる
月例を回すたびに手順がブレる	承認ルールが人依存になっている	「テスト→本番」の承認フローを固定し、KBリストを管理

監査・保守の観点で「Export/Import正攻法」が強い理由

閉域環境は、通常よりも「説明責任」「再現性」「改ざん耐性」が求められます。Export/Import＋媒体搬送は手間に見えますが、次の点で監査・保守に強い運用です。

• 毎月の搬送物（CAB・ログ・コピーログ）を成果物として残せる
• 更新の来歴（いつ、どのWSUSから、何を持ち込んだか）を追いやすい
• サポート外の“裏技”を避けられ、障害時に切り分けが容易
• 手順を定型化しやすく、引き継ぎやすい

「閉域WSUSに直接パッチを放り込む」系のアプローチは、短期的には楽に見えても、長期では運用負債になりやすいです。特に人が変わったタイミングで破綻することが多いため、最初から正攻法で回す設計が安全です。

月例運用を“型化”する：毎月の作業テンプレート例

最後に、月例パッチ（Patch Tuesday相当）を閉域WSUSへ取り込む作業を、毎月同じ手順で回せるようにするテンプレート例を示します。

タイミング	オンラインWSUS側	搬送	オフラインWSUS側
月例公開後	同期 → KB確認 → テスト承認 → 検証	—	—
検証OK後	本番承認の確定 → コンテンツ揃え → Export作成	CAB/ログ/コピーログを媒体へ	—
閉域反映日	—	WSUSContentを閉域へ搬送	コンテンツ配置 → Import → 表示/分類確認 → 本番承認
配布後	—	—	適用状況確認 → 承認漏れ確認 → 次月へ改善点反映

このテンプレートの強みは、どの月も「オンラインで絞る → Export/Importで搬送 → 閉域で配る」に収束する点です。閉域運用で本当に必要なのは、“高度な裏技”よりも、“毎月同じ品質で回る仕組み”です。

まとめ：個別インポートではなく「オンラインで選別し、Export/Importで閉域へ持ち込む」が最短距離

閉域WSUSへの月例パッチ取り込みは、「WSUSに個別パッチを直接インポートする」方向で考えるほどハマりやすくなります。WSUSの仕組み上、更新はメタデータとコンテンツの整合性が命であり、閉域ではそれを崩さない運用が求められます。

そのため、実務で安定しやすい答えは次の通りです。

• オンラインWSUSで必要更新を絞る（KBで承認対象を決める）
• wsusutil.exe Export / Import とコンテンツ搬送で閉域WSUSへ反映する
• オンライン/オフラインで世代差（製品/分類/言語/WSUS更新）を揃え、手順を型化する

この形に寄せるほど、「今月だけ特別対応」「担当者の勘で回す」といったブレが減り、閉域でも月例パッチ運用が継続可能になります。