WSUSで機能更新プログラムを段階展開しているのに、未承認のはずの「Windows 10 20H2」が一部端末で勝手に始まる――。この現象は、端末がWSUSだけでなくインターネット側のWindows Updateも同時に参照する設定（Dual Scan）で起きやすい。原因の見分け方と、再発させない構成を整理します。
起きていたことを整理する
今回のポイントは「WSUSで承認していないのに機能更新がインストールされた」だけではありません。WSUS側で事前に『必要（Needed）』として検出されていないのに、端末側ではダウンロード／インストールが進んだ点が“違和感”の正体です。言い換えると、端末が“WSUS以外”のルートで更新を見つけている可能性が高い、という合図です。
| 観点 | 想定していた挙動（WSUSのみ） | 実際に起きた挙動 |
|---|---|---|
| 検出（Needed） | 端末はWSUSでスキャンし、必要な更新がWSUSに「必要」として上がる | 端末はMicrosoft側でもスキャンし、WSUSに出ていない更新を“必要”と判断 |
| 配布トリガー | 承認したコンピュータグループだけがインストール開始 | WSUS未承認でも、インターネット側の更新フローからインストール開始 |
| 管理者の見え方 | WSUSコンソールの状態と端末の動きが一致する | WSUS上は静かなのに、端末側だけ先に進む（管理の外で動く） |
結論：Dual Scan（デュアルスキャン）が原因になりやすい
Dual Scanとは、端末が更新を探すときにWSUS（社内）とWindows Update/Microsoft Update（インターネット側）を両方参照してしまう状態です。WSUSで承認していない更新でも、インターネット側で検出・取得できてしまうため、結果として「未承認なのに勝手に入る」事故が起きます。
特にWindows 10では、WSUSの指定とWindows Update for Business（WUfB）系の“延期・プレビュー・リング”設定が混在すると、スキャン元が意図せずWindows Update側に寄ることがあります。Microsoft Learnでも、WSUSとクライアントポリシーを併用する場合の挙動や、Dual Scan（旧ポリシー）の扱い、そして更新種別ごとに取得元を指定できる「scan source policy」の考え方が整理されています。
なぜ「必要（Needed）」に出ないのにインストールが始まるのか
WSUSの「必要（Needed）」は、端末がWSUSをスキャンした結果としてWSUSが把握している状態です。ところがDual Scan状態では、端末がインターネット側のWindows Updateでも別途スキャンし、そこで「Feature update to Windows 10, version 20H2」のような機能更新プログラムを検出します。
つまり、管理者が見ているWSUSの画面は“WSUSに対するスキャン結果”しか映していないのに、端末は端末で“別ルートのスキャン結果”を根拠にインストールを進めるため、両者が噛み合わなくなります。これが「Neededに出ないのに始まる」現象の仕組みです。
Dual Scanが発生しやすい代表パターン
WUfBの延期・プレビュー系ポリシーを使っている
Dual Scanは、Windows Updateクライアント側の機能で、WSUSが設定されている端末にWUfBの延期ポリシー等を有効化すると発生し得ることが説明されています（WUfBの遅延ポリシーを有効にした状態でWSUSが設定されているとdual-scanが有効になる、という整理）。
たとえば次のような“便利な設定”を、WSUS運用のまま部分的に入れると要注意です。
- 「Select when Preview Builds and Feature Updates are received（プレビュー ビルドと機能更新プログラムの受信タイミング）」
- 「Select when Quality Updates are received（品質更新プログラムの受信タイミング）」
- IntuneのUpdate rings（更新リング）やFeature update policy
- 一部端末だけRelease Preview相当で早期検証したい、という運用
Intune/ConfigMgrなど“別の更新管理”が混ざっている
組織によっては、端末管理を段階的にクラウドへ移行する過程で、WSUSとIntune/ConfigMgrの設定が混在します。このとき、意図せずスキャン元が増えると、WSUSの承認制御から外れやすくなります。Microsoft Learnでは、WSUSとWindows Updateクライアントポリシーを併用する場合に、更新の種類（機能更新、品質更新、ドライバー、他製品更新）ごとに取得元を指定できる「scan source policy」が案内されています。
ユーザー操作で“オンライン確認”の導線が残っている
端末のWindows Update画面で「更新プログラムのチェック」「オンラインで確認」といった導線が残っていると、ユーザーが意図せずインターネット側の更新探索を起動してしまうことがあります。Microsoft Learnでも、WSUSを設定していてもユーザーの操作によりWindows 11へのオプションアップグレードが見える可能性があるため、スキャン元ポリシー等で抑制することが推奨されています。
WSUS運用での“機能更新プログラム”の基本
まず前提として、WSUSで機能更新（Feature Updates）を扱う場合、WSUSコンソール上は「Upgrades（アップグレード）」分類として見えるのが一般的です。リング（グループ）ごとに承認することで段階展開を作れます。
ただし、機能更新はサイズも影響も大きいので、WSUS側の運用として次の2点を押さえると事故が減ります。
- 自動承認ルールでUpgradesをうっかり対象にしない（「品質更新だけ自動、機能更新は手動承認」が定石）
- 1台に複数の機能更新を同時に承認しない（クライアント側でエラーの原因になり得る、という注意が案内されています）
対策の考え方は「更新の入口を1つにする」
Dual Scan問題の本質は、端末が参照する更新ソースが複数あることです。再発防止はシンプルで、運用モデルをどちらかに寄せます。ここを曖昧にすると、機能更新プログラムのように“効いたら戻りづらい”更新で、必ずどこかのタイミングで破綻します。
| 運用モデル | 向いている組織 | メリット | 注意点 |
|---|---|---|---|
| WSUSで完全管理 | 承認制御が最優先／社内NW基準が厳しい | 「承認したものだけが入る」を作りやすい | WUfB/Insider/リング混在を避ける。機能更新の早期検証は別の仕組みで。 |
| WUfB/Intuneで段階配布 | クラウド管理へ寄せたい／拠点外端末が多い | リング／延期／フェーズ配布が得意 | WSUSで“全部コントロール”は捨てる。運用思想を統一する。 |
WSUSで完全管理したい場合の典型構成
ここでは「未承認なのに勝手に機能更新が入る」を最優先で潰すための、現場で効きやすい最小セットを紹介します。環境によっては追加調整が必要ですが、まずは混在要素を消し、WSUSに寄せるのが第一です。
優先順位：WUfB系設定を“使わない”に揃える
WSUSで配布するなら、WUfBの延期・プレビュー系を残す理由が薄い一方、残すとDual Scanの温床になりがちです。具体的には、WUfB関連のGPO/MDMを「未構成」へ寄せ、WSUSのGPOだけを有効にします。
Dual Scan抑止は「旧方式」と「新方式」を使い分ける
Windowsの世代によって、抑止方法の考え方が少し変わります。押さえるべきポイントは“端末がどの更新ソースをスキャンするか”を明確に決めることです。
| 観点 | 旧方式（Dual Scan抑止ポリシー） | 新方式（scan source policy） |
|---|---|---|
| 目的 | WUfBの延期ポリシー等があってもWindows Updateをスキャンしないようにする | 機能更新／品質更新／ドライバー等を「どこから取るか」を種類ごとに指定する |
| ポイント | “混在を止める”発想 | “混在を設計して制御する”発想 |
| 注意 | Windows 11では旧方式が推奨されない、と案内されている | OS世代・ADMX/更新適用状況に依存するため、適用対象を整理する |
クライアント側GPOの例（WSUS専用運用の核）
以下は「WSUSに寄せる」ための代表的なGPOの考え方です。実際のポリシー名は環境（ADMXの世代）で微妙に揺れることがありますが、狙いは変わりません。
| 領域 | 設定（例） | 狙い | 実務メモ |
|---|---|---|---|
| WSUS | Specify intranet Microsoft update service location（社内WSUSを指定） | 検出・配布の参照先を社内に固定 | まずここがズレていると全てが崩れる |
| 自動更新 | Configure Automatic Updates（自動更新の方式を統一） | 勝手なタイミングでのインストールを抑える | “自動ダウンロード＋通知”など、社内運用に合わせて統一 |
| スキャン元制御 | （旧）Do not allow update deferral policies to cause scans against Windows Update （新）Specify source service for specific classes of Windows Updates | WSUSとWindows Updateの混在を避ける／制御する | 対象OSが2004以降なら新方式の検討価値が高い |
| 緊急用の封じ込め | Do not connect to any Windows Update Internet locations（必要に応じて） | インターネット側に行けないようにする | Store/ドライバー等に影響が出る場合があるため、恒久対応には慎重に |
scan source policyで「機能更新だけは絶対にWSUS」を作る
近年のWindowsでは、更新種別（機能更新／品質更新／ドライバー／他製品）ごとに取得元を選べるため、「機能更新はWSUSで慎重に」「品質更新はクラウドでもよい」「ドライバーはクラウドに寄せる」といった現実的な折衷案も設計できます。
| 更新の種類 | 推奨の考え方（例） | 理由 |
|---|---|---|
| 機能更新プログラム | WSUS（承認制御） | 業務影響が大きく、段階展開・検証が必須になりやすい |
| 品質更新プログラム | WSUS or クラウド（組織方針次第） | セキュリティ優先度が高い。配布の速さを重視する設計もあり |
| ドライバー／ファームウェア | クラウド（必要な場合のみ） | WSUSに載せると管理負荷が増える。影響評価の難しさもある |
| Microsoft製品（Office等） | 別管理（製品に合った仕組み） | 更新チャネルが異なる。WSUS一本化が必ずしも最適ではない |
「今すぐ止血したい」場合の実務的な順序
- 端末がWUfB/Insider系のポリシーを持っていないかを確認し、混在していれば解除する
- WSUS専用のGPO（WSUSサーバー指定）を再適用し、端末の参照先を揃える
- 必要なら、短期的に「インターネット側へ行けない」制御（GPO/FW/Proxy）を入れて暴走を止める
- 落ち着いたら、scan source policy等で“再発しない設計”に寄せる
早期検証をしたい場合は「WSUS管理から切り離す」が整理しやすい
「一部端末だけリリースプレビュー相当で先に試したい」という要件はよくあります。ただし、WSUSで承認制御をしたまま、プレビュー／リング運用も同時にやると、まさにDual Scanの温床になります。
おすすめは、検証端末群を以下のいずれかに明確に分離することです。
- WUfB/Intuneの更新リングで早期リングを作り、WSUS管理対象から外す
- Windows Insider Program for Businessとして運用し、検証専用のポリシーで管理する
Windows Insiderのプレビュー ビルドは、組織内でポリシー管理でき、WSUSを使う場合は「Windows Insider Pre-release」製品と「Upgrades」分類を同期して承認する流れが案内されています。ここまで来ると、更新の入口は“プレビュー用”として別物になるため、本番のWSUS承認フローと混ぜないのが安全です。
Release PreviewはWindows Insiderなのか
端末側の設定としては、Release Previewも含めて「Windows Insider Program」のチャネルの1つとして扱われます。Microsoft Learnでは、プレビュー ビルドのチャネル選択や、レジストリ（BranchReadinessLevel等）で状態を確認できることが示されています。
重要なのは名称よりも、その端末が“インターネット側の更新フロー”に寄るという点です。Release Preview相当を混在させるなら、WSUSの「承認したものだけ」を崩しやすいので、設計段階で分離しましょう。
WSUSでGA前に機能更新を承認できるのか
一般的なWSUS運用（Windows 10/11製品＋Upgrades分類）では、管理者が扱う機能更新は基本的に公開済みの更新を前提に設計するのが安全です。一方で、Insider向けの「Windows Insider Pre-release」製品を同期すれば、プレビュー ビルドをWSUSで扱う手段も案内されています。また、WSUSの手順では、機能更新の承認やリング展開、注意点（複数機能更新の同時承認を避ける等）が整理されています。
ただしプレビュー配布をWSUSでやる場合でも、実態としてはInsider（プレビュー）という別のチャネルを取り込むことになります。WSUSで“全部を厳密に承認制御”したい本番運用とは相性が悪く、設定ミス時の影響も大きいので、検証環境・検証OU・検証端末に限定するのが現実的です。
原因切り分けに効くチェックリスト
現場で「Dual Scanかどうか」を早く確定するためのチェックです。1台でも原因が確定できると、全体の是正が進めやすくなります。
| チェック観点 | 見る場所 | 確認ポイント | よくある落とし穴 |
|---|---|---|---|
| WSUS参照の有無 | GPO / レジストリ | WSUSサーバー（WUServer / WUStatusServer）が正しいか | 端末移設・OU変更後にGPOが外れている |
| WUfB/Insider系の混在 | 「構成された更新ポリシー」画面 / レジストリ | プレビュー/延期/リング関連の値が残っていないか | MDM側の設定が残り、GPOと競合している |
| スキャン元の実態 | WindowsUpdateClientログ | スキャンがWSUSか、Windows Update側か | “必要”がWSUSに出ないのに動く＝疑う価値が高い |
| ユーザー起因 | 端末の操作履歴・運用 | ユーザーがオンライン確認を押せるUIが残っていないか | ヘルプデスクが案内してしまうケースもある |
PowerShellで状況把握する例
端末側で「何が効いているか」を見るときは、まずGPOの結果とWindows Updateのログを押さえるのが近道です。
gpresult /h C:\\Temp\\gpresult.html
# Windows Update Client のログ（ETL）を人間が読める形式へ
Get-WindowsUpdateLog -LogPath C:\\Temp\\WindowsUpdate.log
ログに「どのサービスをスキャンしたか」が出ることがあります。WSUS運用のつもりでもWindows Update側を見ていれば、WSUSの「Needed」と端末の挙動がズレるのは自然です。ここが確認できると、次に何を消す（何を残す）べきかが一気にクリアになります。
再発防止のまとめ
- 「未承認なのに機能更新が入る」多くのケースは、端末がWSUS以外も見に行っている（Dual Scan／スキャン元混在）が原因
- 対策は更新の入口を1つにすること。WSUSで完全管理するならWUfB/Insider系を混ぜない
- 早期検証が必要なら、検証端末はWSUS管理から切り離してリング運用に寄せる
- 近年のWindowsでは、更新種別ごとの取得元を指定するscan source policyが整理に役立つ
コメント