WSUSで社内端末の更新を統制しつつ、出張・在宅など社外ではMicrosoft Updateからセキュリティ更新だけ受け取りたい。しかし機能更新（大型アップデート）は避けたい――この相反する要件を、GPOとWindows Update for Businessで両立する手順をまとめます。
WSUS運用で起きやすい「社外だけオンライン更新」問題
社内LANにいるWindows 10はWSUS（Windows Server Update Services）で更新管理しているが、ノートPCや在宅勤務ではWSUSへ到達できず更新が止まりがちです。そこで「社外ではオンライン（Microsoft Update/Windows Update）に取りに行ってよい」としたくなる一方、オンラインに開放すると機能更新（Feature Update）＝OSバージョンが上がる大型アップデートまで流れ込み、検証していない環境差分や互換性問題を招きやすくなります。
よくある対策としてGPOの「Windows Update のすべての機能へのアクセスを無効にする（Turn off access to all Windows Update features）」を有効化し、ユーザーが勝手にオンライン更新へ行けないよう抑え込みます。しかし、この設定は「社外ではセキュリティ更新だけは取りたい」という要件と相性が悪く、結局「全部止める」か「全部許す」かの二択に寄りやすいのが悩みどころです。
まず整理：品質更新と機能更新は“配信の考え方”が違う
Windows Updateを運用するうえで、まず押さえるべきは更新の種類です。ここを曖昧にしたままポリシーを触ると、意図せず大型アップデートが入ったり、逆に月例パッチが止まったりします。
| 種類 | 別名 | 例 | 影響 | 止めたい／急ぎたい理由 | 主な制御手段 |
|---|---|---|---|---|---|
| 品質更新 | Quality Update、累積更新、月例 | セキュリティ更新、累積更新プログラム | 基本は同一バージョン内での修正・強化 | 脆弱性対策は遅らせたくない（ただし即時適用は業務影響の検証が必要） | WSUSの承認、WUfBの品質更新遅延、更新リング |
| 機能更新 | Feature Update、バージョン更新、大型アップデート | 1903 → 20H2、21H2 → 22H2 など | OSのビルド/機能が変わる。互換性・UI・運用手順も変化 | 検証前に入るとトラブル要因。配布タイミングを“決め打ち”したい | WUfBの機能更新ポリシー（遅延/一時停止/固定）、WSUSの「Upgrades」制御 |
今回の要件は、品質更新は社外でも許可し、機能更新だけは抑止する、という“種類別の制御”です。つまり、オンライン更新を一律に遮断するポリシーだけでは設計が破綻しやすくなります。
「Windows Update のすべての機能へのアクセスを無効にする」の限界
このポリシーは強力で、ユーザーの操作画面（設定アプリのWindows Update周り）を抑え込む用途では便利です。しかし、運用要件が細かいほどデメリットが目立ちます。
- 品質更新まで一緒に止めやすい（社外でのセキュリティ維持と相反）
- “機能更新だけ”という粒度では制御できない（ブロックの単位が大雑把）
- ユーザーが更新状況を確認できず、ヘルプデスクの問い合わせが増えやすい
- 別のポリシー（WSUS、WUfB）を併用すると挙動が読みづらくなることがある
結論として、「オンライン更新を完全に遮断する」方向のGPOを主役にするよりも、機能更新だけを遅延／固定するほうが要件に合致します。
解決の方向性：Windows Update for Business（WUfB）で機能更新を制御する
要件を満たす現実的な答えは、Windows Update for Business（WUfB）のポリシーで機能更新の受信タイミングをコントロールし、社外ではオンライン更新（品質更新）を許可する設計です。WSUSを捨てる必要はありません。ポイントは「止める対象を“機能更新”に限定する」ことです。
中核となるポリシー
提示されている方針は次のとおりです。
- 適用するポリシー：「プレビュー ビルドおよび機能更新プログラムを受け取るタイミングを選択する（Select when Preview Builds and Feature Updates are received）」
- パス：コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → Windows Update → Windows Update for Business
- 進め方：まず検証端末に限定して適用し、想定どおりに“機能更新が来ない”ことを確認してから展開
このポリシーは、機能更新を受け取るまでの遅延日数や一時停止（Pause）を制御し、結果として社外でオンライン更新を許可しても大型アップデートを避けやすくするための軸になります。
さらに確実にしたいなら「機能更新のバージョン固定」を併用する
遅延だけだと「いつかは来る」設計になりやすいため、運用で“絶対にこのバージョン以上へ上げない”を実現したい場合は、WUfB側の「ターゲット機能更新バージョン」（例：Windows 10 22H2に固定）を併用すると強力です。遅延は保険、固定は本命という位置付けで考えると失敗しにくくなります。
事前準備：WUfBのGPO項目が見つからないときの対処
現場で意外と多いのが、「Windows Update for Businessの項目がグループポリシーに出てこない」「ターゲット機能更新バージョンの設定が見当たらない」という状態です。これは多くの場合、ADMXテンプレート（管理用テンプレート）が古いことが原因です。
- 管理端末/管理サーバーのADMXを、Windows 10世代に合った最新版へ更新する
- ドメインでセントラルストア（SYSVOLのPolicyDefinitions）を使っている場合は、そこへ反映して整合性を取る
- 「なぜこのポリシーが出ないのか」を潰してから検証を始める（途中でテンプレートを差し替えると切り分けが難しい）
テンプレート更新は運用に影響する作業なので、変更管理（バックアップ、適用範囲、ロールバック手順）もセットで用意しておくと安全です。
WSUSを維持したまま要件を満たす設計パターン
「社内はWSUS、社外はオンライン更新」という要件は、端末の所在（社内/社外）だけでポリシーを切り替えたいのが本音です。ただし、GPOは基本的に“ログオン時/更新時に適用される設定”なので、ネットワークの出入りに応じて自動で切り替える仕組みは別途工夫が必要です。現場では次の3パターンがよく採用されます。
| パターン | 社内の更新元 | 社外の更新元 | 機能更新の抑止 | 向いている環境 | 注意点 |
|---|---|---|---|---|---|
| 端末は常にWSUS（VPN必須） | WSUS | WSUS（VPN/Always On VPNで到達させる） | WSUS側でUpgradesを承認しない | VPNが安定して常時接続できる、更新統制を最優先 | VPNが切れると更新が止まる。社外で“オンライン更新”という要件とはズレる |
| モバイル端末はWUfB寄り（WSUSは固定端末中心） | 固定端末：WSUS モバイル：Windows Update | Windows Update | WUfBで遅延/固定 | 在宅・出張が多い、クラウド前提に寄せたい | 「WSUSを既定にしたい」を“全端末”で満たせない。運用ルールの明文化が必要 |
| WSUS＋WUfBの併用（社外はオンライン更新を許可） | WSUS | Windows Update（必要に応じて） | WUfBで遅延/固定 | 社内統制を残しつつ、社外でのセキュリティ維持も重視 | 設定の組み合わせ次第で挙動が変わる（Dual Scan等）。検証が必須 |
この記事では、質問の前提に合わせて「WSUSを維持しながら、社外ではオンライン更新（品質更新）を許可し、機能更新は抑える」を中心に解説します。
GPOは“分ける”ほど事故が減る：おすすめのGPO構成
同じGPOにWSUS関連とWUfB関連を全部詰め込むと、後から「どの設定が効いているのか」が追いづらくなります。運用を回すなら、次のように意図でGPOを分割しておくのがおすすめです。
| GPO名（例） | 目的 | 入れる設定の例 | 適用範囲の例 |
|---|---|---|---|
| WSUS-Base | 社内の標準（品質更新を統制） | 自動更新の構成、WSUSサーバー指定、再起動関連 | 固定端末OU、または全端末（社外でもVPN前提なら全端末） |
| WUfB-FeatureControl | 機能更新だけを抑止/計画化 | 機能更新の遅延/一時停止、ターゲットバージョン固定 | 検証OU → 本番OUへ段階的に展開 |
| WU-AccessPolicy | オンライン更新の扱いを決める | 「Windows Updateの全機能アクセス無効」を見直す、必要なら代替ポリシーへ分解 | 社外運用が必要な端末だけに限定（セキュリティフィルタ等） |
こうしておくと、「機能更新が止まらない」「品質更新が止まった」といったトラブルが出たときに、どのGPOを疑うべきかが一気に明確になります。
具体的なGPO設定例：品質更新は許可、機能更新だけ抑止
ここからは、GPOで組み立てるときの具体例です。実際の値は組織の検証ポリシーやサポート期限に合わせて調整してください。
WUfB側（機能更新をコントロールする）
| ポリシー名 | パス | 推奨の方向性 | 設定例 | 狙い |
|---|---|---|---|---|
| プレビュー ビルドおよび機能更新プログラムを受け取るタイミングを選択する （Select when Preview Builds and Feature Updates are received） | Windows Update for Business | 有効 | 機能更新の延期：例）180～365日 必要に応じて一時停止（Pause） | オンライン更新を許可しても、機能更新がすぐ降ってこない状態を作る |
| ターゲット機能更新バージョンを選択する （Select the target Feature Update version） | Windows Update for Business | 可能なら有効 | 製品バージョン：Windows 10 ターゲット：例）22H2 | “上げない”を明確化。遅延より確実に大型アップデートを抑える |
| 品質更新プログラムを受け取るタイミングを選択する （Select when Quality Updates are received） | Windows Update for Business | 有効（必要に応じて） | 延期：0～7日程度（例） | 社外端末でもセキュリティ更新を迅速に取り込む（ただし検証が必要なら少し遅延） |
スレッド内の見解としても、WSUS側の基本ポリシー（例：「自動更新の構成（Configure Automatic Updates）」）とWUfB側の機能更新制御は、設計次第で“致命的に競合しない”と整理できます。重要なのは、どの更新をどの更新元で取るのかを運用として決め、GPOをその意図に沿って分離することです。
WSUS側（社内の既定更新サーバーを維持する）
| ポリシー名 | パス | 設定例 | ポイント |
|---|---|---|---|
| 自動更新を構成する （Configure Automatic Updates） | Windows Update | 例）自動ダウンロードしてスケジュールに従ってインストール | 品質更新の適用を自動化。再起動運用（アクティブ時間、再起動通知）も合わせて設計 |
| イントラネットのMicrosoft更新サービスの場所を指定する （Specify intranet Microsoft update service location） | Windows Update | WSUSサーバーURLを指定 | 社内ではWSUSを既定にする“根幹”。端末が社外でもWSUSしか見ない構成になる点に注意 |
| Windows Update のすべての機能へのアクセスを無効にする （Turn off access to all Windows Update features） | Windows Update | 要件に応じて無効/未構成へ見直し | ここを有効のままだと「社外で品質更新だけ許可」が難しくなる。UI抑止が必要なら別の制御に分解 |
ここで重要なのは、質問にあるとおり「オンライン更新を完全に遮断する」方針だけで設計しないことです。機能更新を止めたいなら、止めるべき対象は“機能更新”であり、オンライン更新全体ではありません。
レジストリで“効いているか”を点検する（トラブルシュート用）
GPOを適用したのに動きが変わらない場合、ポリシーが反映されていない、または別のGPOに上書きされていることが多いです。反映確認の近道は、ポリシーが書き込むレジストリを点検することです（手動編集はせず、確認用途として使います）。
| 目的 | パス/値（代表例） | 意味 |
|---|---|---|
| WSUS参照の有無 | HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AUUseWUServer | WSUSを使うかどうかの目安 |
| WSUSサーバーの指定 | HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdateWUServer / WUStatusServer | 更新取得/状態報告先のURL（WSUS） |
| 機能更新の固定 | HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdateTargetReleaseVersionTargetReleaseVersionInfoProductVersion | 狙ったバージョンへ固定する設定の目安 |
| 機能更新の遅延 | DeferFeatureUpdatesPeriodInDays など | 機能更新を受け取るまでの延期日数 |
「期待どおりの値が入っていない」場合は、GPOのリンク順や優先度、セキュリティフィルタ、WMIフィルタ、継承ブロックなどを疑うのが定石です。
運用上の分岐点：社外で本当にMicrosoft Updateへ行かせたいなら
「社外ではオンライン更新を許可したい」という要件を文字通り満たすには、端末が社外でMicrosoft Updateを参照できる状態になっている必要があります。ところが、WSUSを指定するポリシー（イントラネットの更新サービスの場所を指定）が有効だと、端末は基本的にWSUSを参照し続けます。社外でWSUSに到達できない場合、更新が滞ります。
このギャップを埋める代表的なやり方は次のとおりです。
- Always On VPN / デバイストンネルで社外でもWSUSへ到達させる（更新元は常にWSUS）
- 端末種別（固定PC/モバイル）でGPOを分け、モバイル端末はWindows Update + WUfBへ寄せる
- Intune等のクラウド管理に寄せ、更新ポリシーを更新リングで運用する
「WSUSを既定として維持しつつ、社外はオンライン更新」という両立を狙うほど、設計は“端末の分類”と“到達性（VPN/ゼロトラスト）”に依存します。逆に言えば、ここを決めておくとGPOの答えがシンプルになります。
よくある落とし穴：WSUSとWUfB併用時の挙動（Dual Scan）
WSUS運用の現場でつまずきやすいのが、WSUS設定が入った端末にWUfBポリシーを追加したときの挙動です。環境や設定によっては、端末がWSUSだけでなくMicrosoft Updateにもスキャンしに行く状態（いわゆるDual Scanのような状態）になり、WSUSで承認していない更新が入ったと感じることがあります。
これを“問題”と見るか“要件実現の手段”と見るかは、組織の目的次第です。
- 社外で品質更新を確実に入れたい → Microsoft Update参照はむしろ歓迎（ただし社内の統制が崩れないよう範囲を限定）
- 社内の更新統制を最優先したい → 端末が勝手にMicrosoft Updateへ行かないよう制御（端末分類、VPN、追加ポリシー）
混在が怖い場合は、検証端末で「社内（WSUS到達可）」と「社外（WSUS到達不可）」の両方を再現し、どの更新がどこから来ているかをログで確認してから展開するのが安全です。
検証のすすめ：まずは1台で“想定どおり”を確認する
いきなり全社展開すると、機能更新の抑止がうまくいかなかった場合に被害が大きくなります。次の手順で段階導入すると、原因切り分けが容易です。
- 検証用のOU（または検証用セキュリティグループ）を用意し、テスト端末を1～数台だけ入れる
- WUfBの機能更新制御ポリシーを適用（遅延/固定を設定）
- 端末で
gpupdate /forceを実行し、gpresult /hで適用状況を確認 - 社外相当（VPN切断、社内ネットワーク外）を再現してWindows Updateを実行し、品質更新のみが降るか確認
- 想定外の機能更新が見える場合は、ターゲットバージョン固定やWSUS側のUpgrades制御を追加
確認に使える代表的なチェックポイント
| 確認対象 | 見る場所 | 見るポイント |
|---|---|---|
| GPOの最終適用 | gpresult /h、RSOP | WUfBポリシーが期待どおり“有効”になっているか。上書きされていないか |
| 更新元（WSUS/WU） | WindowsUpdateClientのイベントログ、WindowsUpdate.log | どのサービスへスキャンしているか、ダウンロード元がどちらか |
| 機能更新の提示 | 設定 → 更新とセキュリティ | 「機能更新プログラム」が表示されない/インストールボタンが出ないこと |
設定値を“言語化”してから触る：実務向けの考え方
GPOを触るときにありがちな失敗は、「この設定をオンにすれば止まるはず」という経験則だけで組み合わせてしまうことです。要件を次のように分解して、設定がその要件を満たしているかをチェックする癖を付けると、設計が崩れにくくなります。
| 要件 | 実現したいこと | 推奨アプローチ | 避けたいアプローチ |
|---|---|---|---|
| 社内はWSUSを既定にしたい | 承認した品質更新だけを配布し、再起動も統制 | WSUS指定GPO＋承認運用、WSUSレポート | 社内でもMicrosoft Updateを参照し放題にする |
| 社外でもセキュリティ更新は取りたい | WSUSに到達できなくても最新の累積更新を適用 | Windows Update参照を許可（端末分類/クラウド管理/VPN設計） | オンライン更新機能を丸ごと無効化する |
| 機能更新（大型アップデート）だけ止めたい | 検証したタイミングでのみ計画的に更新 | WUfBで遅延/固定＋WSUS側Upgrades制御 | 「止める系」ポリシーを増やし、結果的に品質更新まで止める |
WSUS側でもできる“機能更新の抑止”を忘れない
社内WSUSで更新統制をしている場合、そもそもWSUS側で機能更新を配らない（承認しない/同期しない）運用も重要です。WSUSでは機能更新が「Upgrades」に分類されることが多く、ここを同期・承認しない運用にしておけば、少なくとも社内で勝手に大型アップデートが入るリスクは下げられます。
- WSUSで「Upgrades」を同期するかどうかを見直す
- 同期している場合でも、承認ルール（自動承認）にUpgradesを含めない
- 機能更新を配布する年次/半期の“解禁手順”を決め、計画リリースにする
ただし、社外でMicrosoft Updateを許可するなら、WSUS側の制御だけでは足りません。だからこそ、クライアント側で機能更新を止めるWUfBポリシーが効いてきます。
よくある質問
機能更新の遅延を最大にしても、いつか勝手に上がりませんか？
遅延は“時間稼ぎ”であり、無期限の禁止ではありません。大型アップデートを確実に避けたいなら、遅延に加えてターゲット機能更新バージョンの固定を併用し、さらに解禁手順（いつ、誰が、どの端末に）を運用に落とし込むのが安全です。
1903のまま固定したいが問題ありますか？
サポート切れのバージョンに固定するのは、セキュリティ面で大きなリスクになります。要件が「勝手に上げない」ことであって「永久に上げない」ことではないなら、サポート期間内のバージョン（例：組織標準の22H2など）に固定し、計画的に次の標準へ移行する運用に変えるのが現実的です。
「自動更新の構成」とWUfBの機能更新ポリシーは本当に併用できますか？
設計によっては併用できます。ポイントは、品質更新の自動取得（どの更新元から、どのタイミングで入れるか）と、機能更新の受信タイミング（遅延/固定）を分けて考えることです。併用する場合は、検証端末で社内/社外の両条件を再現し、ログで更新元を確認してから展開してください。
まとめ：止めたいのは“オンライン”ではなく“機能更新”
「社外ではオンライン更新を許可したいが、機能更新は止めたい」という要件は、オンライン更新の全遮断では実現しづらい一方、Windows Update for Business（WUfB）のポリシーを使えば、品質更新は許可しつつ機能更新だけ抑止する設計に寄せられます。
中核は、「プレビュー ビルドおよび機能更新プログラムを受け取るタイミングを選択する」で機能更新をコントロールすること。さらに確実にしたい場合は、ターゲット機能更新バージョンの固定を併用し、WSUS側でもUpgradesの承認運用を見直す――この3点セットで、社内統制と社外のセキュリティ維持を両立しやすくなります。
コメント