Windows Server を WSUS なしで「Windows Update（インターネット側）」運用にしつつ、更新プログラムは先にダウンロードだけして、実際のインストールはパッチ適用ウィンドウで人の判断で実行したい──この要件はよくあります。一方でレジストリ（ポリシー相当）の AUOptions と NoAutoUpdate は組み合わせ次第で挙動が分かりづらく、さらに SoftwareDistribution\Download の増減が判断を難しくします。本記事では、この2値の関係、推奨設定（GPO）、ログでの確認手順まで、運用に落とせる形で整理します。
やりたいことを整理：ダウンロードは自動、インストールは手動
今回のゴールは「更新プログラムの取得（ダウンロード）を前倒し」しつつ、「インストール（適用）だけは勝手に始めない」状態です。これを Windows Update（インターネット）で実現する場合、基本は “自動ダウンロード＋インストールは通知” を狙います。
| 観点 | Windows Update（インターネット） | WSUS（参考） |
|---|---|---|
| 更新の承認（KB単位） | 原則できない（OSが必要と判断した更新を取りに行く） | できる（承認/拒否/リング分けが可能） |
| ダウンロードだけ先に実行 | 可能（設定により自動ダウンロード） | 可能（配布/事前キャッシュなど設計しやすい） |
| インストール開始の最終判断 | 通知後に管理者が実行（ただし例外や運用注意点あり） | スケジュール/手動/段階配布など柔軟 |
| なぜ/いつ取得したかの説明 | ログ追跡が必要（UIだけでは判断しづらい） | WSUS側で可視化しやすい |
つまり、Windows Update 単体でも「自動ダウンロード＋手動インストール」は狙えますが、“承認フローを厳密に握る（＝このKBだけOK/NGを確実にやる）” となると WSUS（または同等の更新管理）が向きます。ここを先に割り切っておくと、期待値ズレが減ります。
結論：AUOptions を効かせたいなら NoAutoUpdate は 0 が前提
質問の主題である AUOptions と NoAutoUpdate の関係は、運用上は次の理解が最も安全です。
- NoAutoUpdate=1：自動更新そのものを無効化する（＝AUOptions で期待する自動ダウンロード挙動も基本的に出ない）
- NoAutoUpdate=0：自動更新を有効化する（＝AUOptions のモード選択が意味を持つ）
- AUOptions=3：自動ダウンロードし、インストールは通知（人が実行する前提のモード）
「ダウンロードだけさせたいから AUOptions=3 にしたい」なら、NoAutoUpdate は 0（有効）にしておく必要があります。 NoAutoUpdate=1 のままでは、そもそも “自動更新機能” を止めてしまうため、AUOptions 側の「自動ダウンロード」まで含めて期待通りに動きません。
よくある誤解：NoAutoUpdate=1 なのに Download フォルダが増える
ここがハマりポイントです。NoAutoUpdate=1 のままでも C:\Windows\SoftwareDistribution\Download 配下にフォルダが増えたり、何かが入ってきたりすることがあります。これは多くの場合、次のどれか（または複合）で説明できます。
- 過去に取得した残骸（履歴・断片・配信最適化などが残っている）
- スキャン（更新の照会）やメタデータ取得は別トリガーで起きているように見える
- サービスが「停止」ではなく「トリガー起動」で一時的に動作し、結果としてフォルダが更新される
- 更新プログラム以外のコンテンツ（Defender 定義、互換性情報、配信に必要なメタ情報など）が混ざる
つまり「フォルダが増えた＝狙いの累積更新がダウンロード完了した」とは断定しづらく、判断の主軸はログに置くのが安全です（後述します）。
レジストリ設定の全体像：ポリシー相当のキーを触っているか確認する
GPO（グループポリシー）で設定する Windows Update の多くは、実体としてはレジストリの “Policies” 配下に反映されます。今回の値も基本はここです。
| 項目 | 場所（例） | 値 | 意味 | 今回の狙い |
|---|---|---|---|---|
| NoAutoUpdate | HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU | 0 / 1 | 自動更新機能の有効/無効 | 0（有効） |
| AUOptions | HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU | 2 / 3 / 4（など） | 自動更新の動作モード | 3（自動DL＋インストール通知） |
| UseWUServer | HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU | 0 / 1 | WSUS を使うか | WSUSなしなら0（または未設定） |
| WUServer / WUStatusServer | HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate | URL文字列 | WSUS の参照先 | WSUSなしなら未設定推奨 |
ポイントは、WSUS から Windows Update（インターネット）へ戻したいのに UseWUServer=1 や WUServer が残っていると、意図しない挙動になることがある点です。今回のテーマは AUOptions/NoAutoUpdate ですが、過去に WSUS を触った環境ほど まず WSUS 関連が残っていないかを確認しておくと事故が減ります。
推奨：レジストリ直書きより GPO（ローカルGPO含む）で管理する
レジストリを直接変更しても動かせますが、運用・監査・再現性の観点では GPO（グループポリシー）で設定する方が安全です。理由はシンプルで、
- どの設定を意図して入れたかが追跡しやすい（変更履歴・設計が残しやすい）
- レジストリは手作業ミスが起きやすい（キーの場所違い、DWORDの桁違いなど）
- ドメイン参加サーバーでは、後から GPO で上書きされて「いつの間にか変わった」が起きやすい
ドメインGPOが使えない場合でも、ローカル グループ ポリシー（gpedit.msc） で同じ狙いを実現できます。
GPOでの設定例（狙い：自動DL＋インストール通知）
代表的には次の設定を使います（名称は環境/OS世代で多少違うことがあります）。
- 「自動更新を構成する（Configure Automatic Updates）」：有効にして、オプションを 「3 – 自動ダウンロードし、インストールは通知」
- 「自動更新を無効にする（No auto update）」に相当する設定は 無効（=NoAutoUpdate=0） の状態にする
追加で、運用上の事故（勝手な再起動・適用）を防ぐために、次の系統も併せて検討すると現場のストレスが減ります。
- 自動再起動の抑止（ログオン中ユーザーがいる場合に自動再起動しない 等）
- 更新通知の表示方法（サーバー運用の方針に合わせる）
- ドライバー更新を避ける（必要に応じて）
どうしてもレジストリで設定する場合の具体例
手順を固定できる自動化（構成管理）や、検証環境での切り分け目的などで「レジストリ直書き」を使うこともあります。その場合は キーの場所を Policies 配下に統一するのがコツです。
現在値の確認
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer
狙いの設定を投入（AUOptions=3, NoAutoUpdate=0）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions /t REG_DWORD /d 3 /f
過去に WSUS を使っていた形跡があるなら、あわせて次も見ます（必要に応じて）。
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 0 /f
設定反映のタイミングは環境によりますが、検証を明確にするなら次を併用すると切り分けしやすいです。
- グループポリシーの更新（ドメイン参加の場合は特に）：
gpupdate /force - Windows Update 関連サービスの再起動（必要に応じて）：
net stop wuauserv net start wuauserv
注意：ドメインGPOが入っている環境では、レジストリ直書きの値が「次の gpupdate で上書きされる」ことがあります。検証機では一時的に OU を分ける、GPO の適用順を固定するなど、条件を揃えてください。
「自動インストールまで有効化されないか？」を運用目線で確認する
AUOptions=3 は “ダウンロード自動・インストール手動” を狙う設定ですが、現場で不安が残るのは「何かの拍子に勝手に適用されないか？」という点です。ここは “何が勝手に見えるか” を分解すると安心できます。
AUOptions=3 でも起き得る「勝手に進んだように見える」例
- ダウンロード済み（Downloaded）の状態が進む：これは想定内（ダウンロードは自動）
- インストール待ち（Pending install）が表示される：これも想定内（手動で実行するための準備）
- 再起動を要求される：手動でインストールを開始していないのに出る場合は、別系統（Defender/コンポーネント更新等）や過去作業の影響を疑う
インストールが本当に始まっていないかの確認ポイント
| 確認したいこと | 見る場所 | 判断のコツ |
|---|---|---|
| 更新がインストールされたか | 更新履歴 / Get-HotFix / イベントログ | 「インストール成功」の記録があるかで判断（DLだけでは残り方が違う） |
| いつダウンロードが走ったか | WindowsUpdateClient の運用ログ | スキャンとダウンロードは別イベントで出ることが多い |
| 勝手に再起動されたか | Systemログ（Kernel-Power等）/ タスクスケジューラ | 再起動トリガーが更新由来か、運用タスク由来か切り分ける |
ここで大事なのは、SoftwareDistribution\Download の増減だけで「インストールが走った」と判定しないことです。ダウンロードのキャッシュ、メタデータ、配布方式の違いで見え方が変わります。
Windows Update サービスは動いている必要があるのか？
結論から言うと、“ダウンロードさせたい”なら Windows Update 関連サービスは動作できる状態である必要があります。 代表的には次が関係します。
- wuauserv（Windows Update）：スキャン、ダウンロード、インストール制御の中心
- BITS：バックグラウンド転送（更新の取得で使われることが多い）
- （環境によって）配信最適化など、周辺サービス
ただし「サービスを停止したのにフォルダが変わった気がする」現象が起きるのは、サービスが“無効”ではなく“手動（トリガー起動）”として動いたり、OS側のメンテナンスタスクが関連動作を誘発したり、過去のキャッシュが残ったりするためです。
運用上のおすすめは次の考え方です。
- 更新を“ダウンロードだけ先に進めたい”期間：サービスは通常どおり（止めない）
- 絶対にネットへ出したくない/更新動作を止めたい期間：サービス停止ではなく、ポリシーやネットワーク制御で明確に止める（ただし目的が変わっている）
今回の目的は「先にダウンロードしたい」なので、サービス停止は基本的に逆方向です。止める・無効化するより、AUOptions=3 で “インストールだけ手動” に寄せる方が目的に合います。
SoftwareDistribution\Download が「入ってきたり来なかったり」する理由
このフォルダは “Windows Update が使う置き場の一部” ですが、運用目線で見ると落とし穴があります。
- ファイル名/フォルダ名から KB を判断しづらい（狙いの更新が揃ったかが分かりにくい）
- 途中ファイル、差分、メタデータなどが混ざる
- 更新の取得経路により保存場所や粒度が変わることがある
そのため「フォルダが増えた」「ファイルがある」を主判定にするのではなく、“いつ・何を・なぜ” をログで追うのが確実です。特に検証時は条件を揃えないと、再現性が取りづらくなります。
検証時に条件を揃えるコツ
- 検証開始前に「現在の状態」を記録する（レジストリ値、サービス状態、更新履歴）
- フォルダ増減を見るなら、開始時刻とログ時刻をセットで見る（何時に何が走ったか）
- 必要なら SoftwareDistribution を一度リセットして “空から” 確認する（ただし注意点あり）
ログで「いつ・何を・なぜ」を追う方法
Windows Update の挙動を最短で理解するには、イベントログと WindowsUpdate.log（生成）を使うのが近道です。
イベントログ（WindowsUpdateClient の運用ログ）
イベントビューアーで次のログを確認します。
- アプリケーションとサービス ログ
- Microsoft
- Windows
- WindowsUpdateClient
- Operational
ここに「スキャン」「ダウンロード」「インストール」「再起動要求」などの痕跡が出ます。Download フォルダの増減よりも、ログの時刻と内容の方が判断材料として強いです。
Get-WindowsUpdateLog（ETWからWindowsUpdate.logを生成）
新しめの Windows は従来の WindowsUpdate.log がそのまま更新されず、ETW から生成する形になります。PowerShell で次を実行し、生成されたログを読みます。
Get-WindowsUpdateLogログは情報量が多いので、まずは「検証開始時刻」付近を追うのがおすすめです。スキャンしたのか、ダウンロードを開始したのか、何がトリガーかが掴めると、フォルダの増減に振り回されにくくなります。
| 知りたいこと | 優先して見るもの | 補助的に見るもの |
|---|---|---|
| なぜ勝手に動いたように見えるのか | WindowsUpdateClient Operational | タスクスケジューラ（メンテナンス系）、サービス起動履歴 |
| ダウンロードしたのか、スキャンだけか | WindowsUpdate.log（生成） | SoftwareDistribution の更新時刻（補助） |
| インストールが走ったか | 更新履歴/イベントログ | Get-HotFix、再起動要求の有無 |
再現性高く「ダウンロードだけ」を検証する手順
「設定したはずなのに、DLされない/される」「NoAutoUpdate=1 でもフォルダが増える」などの混乱は、検証条件が揃っていないと起きやすいです。以下は現場で切り分けしやすい手順です（本番ではなく検証環境で推奨）。
手順
- 現在値を記録
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions - Windows Update 関連サービス状態を記録
sc query wuauserv sc query bits - （必要なら）SoftwareDistribution をリセット 更新履歴が見えなくなるなど影響があるため、目的と環境を選びます。実施する場合は一般的に次の流れです。
net stop wuauserv net stop bits ren C:\Windows\SoftwareDistribution SoftwareDistribution.bak net start bits net start wuauserv - NoAutoUpdate=0 / AUOptions=3 を設定
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 0 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions /t REG_DWORD /d 3 /f - ログを見ながらスキャン/ダウンロードを待つ UI の「更新プログラムのチェック」操作をする場合、環境によってはそのままインストール提案へ進むことがあるため、検証目的に合わせて慎重に行います。基本は WindowsUpdateClient の運用ログで “スキャン→ダウンロード” の流れを確認します。
- インストールが走っていないことを確認 更新履歴/イベントログに「インストール成功」が出ていない、または Get-HotFix で該当 KB が増えていないことを確認します。
この手順で「AUOptions=3 のときにダウンロードが走る」「インストールは勝手に走らない」を確認できれば、少なくとも レジストリ値の組み合わせとしては狙いに近い状態を作れています。
運用のコツ：パッチ適用ウィンドウに合わせて“準備”を設計する
AUOptions=3 を使う運用は、設定だけでなく手順（オペレーション）を整えると安定します。特に「いつダウンロードさせるか」「いつ誰がインストールを押すか」「再起動はどう扱うか」を定めると事故が減ります。
| フェーズ | 目的 | 具体アクション例 | 注意点 |
|---|---|---|---|
| 事前期間 | 更新のダウンロードを済ませる | AUOptions=3 で自動DLを許可、ログでDL完了を確認 | Downloadフォルダだけで判断しない |
| 適用ウィンドウ開始 | インストール判断と適用 | 管理者が更新画面でインストール実行、影響確認 | 再起動要否と順序（クラスタ/冗長構成）に注意 |
| 適用後 | 適用結果の記録 | KB一覧、再起動実施、障害監視、ロールバック手順確認 | 更新履歴が残る仕組み/ログ保存を整える |
「勝手に入れたくない」運用で特に効くチェックリスト
- 本番適用の前に、同一構成の検証機（またはリング）で先行適用する
- 適用ウィンドウ中に「誰が」「どの画面/手順で」インストールを開始するかを固定する
- 再起動が必要な更新を前提に、業務影響の少ない順序（冗長の片系→もう片系）を決める
- 「更新が入った/入っていない」の証跡（ログ/KB一覧/スクショ等）を残す
それでも「事前承認を厳密に握りたい」なら最適解は WSUS（または同等の更新管理）
今回のテーマは「WSUSなしで頑張りたい」ですが、運用要件として “承認” を強く求めるほど Windows Update 単体は苦しくなります。理由は、Windows Update は基本的に OS が「この端末に必要」と判断した更新を取得し、管理者が “KB単位で承認・拒否” する仕組みが薄いからです。
次のような要件がある場合は、WSUS や同等の更新管理を検討する価値があります。
- KB単位で承認/拒否をしたい（ロールバック要件が厳しい）
- サーバー台数が多く、適用状況（誰がいつ何を入れたか）を一元管理したい
- 更新の配信元（インターネット）を制限したい、帯域/プロキシ要件が厳しい
- 段階配布（リング）を仕組みとして回したい
逆に、台数が少ない・手順が整っている・監査要求がそこまで強くない、という環境なら AUOptions=3 を軸にした「自動DL＋手動適用」は現実的な落とし所になります。
よくある質問
NoAutoUpdate=0 にしたら、いつか自動でインストールされませんか？
狙いが AUOptions=3 の場合、基本は「ダウンロードは自動、インストールは通知」です。ただし、環境や更新種別によって“勝手に進んだように見える”ケースはあり得るため、運用としてログ確認・再起動制御・適用手順固定をセットで考えるのが安全です。
Download フォルダにファイルがあるのに、更新画面では「ダウンロードされていない」ように見えます
SoftwareDistribution\Download は「更新のキャッシュの一部」であり、メタデータや途中ファイルなども含み得ます。UI上の状態と一致しないことがあるため、WindowsUpdateClient のログや Get-WindowsUpdateLog でスキャン/ダウンロードの実行を確認する方が確実です。
Windows Update サービスを止めておけば勝手に入らないのでは？
確かに止めれば更新動作は抑止されますが、今回の目的は「先にダウンロードしたい」なので逆効果です。また、サービス停止だけだとトリガー起動やメンテナンスタスク、残骸などで見え方がブレることがあります。インストールだけを手動化したいなら AUOptions=3 を軸に、再起動や適用手順を固めるのが現実的です。
もっと確実に「ダウンロードだけ」を操作したい
組織のルールが許すなら、Windows Update API を利用する PowerShell モジュール等で “ダウンロード” と “インストール” を分離して運用する手もあります。ただし、サードパーティ要素や運用設計（権限、ログ、保守）まで含めて検討が必要です。純正の仕組みで厳密な承認をしたい場合は、やはり WSUS 等が向きます。
まとめ：迷ったら「NoAutoUpdate=0 + AUOptions=3」を軸に、ログで裏取りする
- AUOptions を効かせたいなら NoAutoUpdate は 0（有効）にする
- AUOptions=3 で「自動ダウンロード＋インストールは通知」を狙う
- SoftwareDistribution\Download の増減だけで判断しない（ログで “いつ・何を・なぜ” を確認）
- レジストリ直書きより GPO（ローカル含む）で管理する方が再現性・安全性が高い
- “承認” を厳密に握る要件が強いなら WSUS（または同等）を検討する
設定値だけを見ると単純に見えますが、運用では「何をもってダウンロード完了とするか」「いつ誰がインストールを押すか」「再起動の扱い」を決めることが、結局いちばん効きます。まずは検証環境で条件を揃えて挙動を掴み、ログで裏取りしながら本番へ展開するのがおすすめです。
コメント