【Patch Manager】 Windows Update との違いは？ 適用されるパッチの範囲と、自動更新を無効化したときの Scan を確認してみた！

はじめに

こんにちは！コンサルティング部のヒスです。

EC2 の Windows Server のパッチ適用は、標準の Windows Update ではなく、Systems Manager の Patch Manager に一本化する構成が使われることがあります。標準の自動更新は無効化して、Patch Manager のメンテナンスウィンドウで、決まった日時に適用する構成です。

ただ、この構成を使おうとすると、次のような疑問が出てきます。今回は、これらを公式ドキュメントで調べて、実機でも確認できる範囲を試してみました。

1. Patch Manager は、どんな更新プログラムを適用するのか
2. それは、Windows Update の月次の更新プログラムと同じ内容なのか
3. 更新は、どのくらいの頻度で出るのか
4. 適用のときに、再起動は発生するのか
5. 自動更新を無効化したあとも、Patch Manager は動くのか

この記事では、分かったことを Q&A で整理して、Windows Server 上で「Patch Manager の見ている範囲」と「Windows Update の見ている範囲」を比べた結果を紹介します。

先に結論：よくある疑問に答えます

Windows Server を Patch Manager に一本化するときに、よく出る疑問を先に整理します。詳しい根拠と検証は、後の章で説明します。

Q1. Patch Manager が適用するパッチは、Windows Update の月次の更新プログラム（KB）と同じですか？

出どころは同じです。 Patch Manager は独自のパッチを配るのではなく、Windows Update API を通して、Windows Update（または WSUS）の更新を適用します。

月次のセキュリティ更新（累積更新プログラム）も、この仕組みで適用されます。Patch Manager のパッチ一覧で確認すると、月次の累積更新プログラム（OS 用と .NET Framework 用）は、どちらも SecurityUpdates（重大度 Critical）に分類されていて、既定のベースラインの条件に当てはまります（「やってみた」の1）。

ただし、Windows Update が見ている更新の全部を適用するわけではありません。適用されるのは、パッチベースラインで承認された更新（既定では、分類が CriticalUpdates / SecurityUpdates、重大度が Critical / Important）です。セキュリティ以外の更新や、Defender の定義更新などは、既定では対象になりません（「やってみた」の5）。

Q2. 更新は、月に何回くらい出ますか？

Microsoft の月次の更新は、毎月1回、第2火曜日（日本時間では水曜日）に公開されます。Patch Manager のパッチ一覧でも、Windows Server 2025 向けの更新は、2026年7月から10月まで、毎月1回ずつ公開されていました。この4か月間に、月の途中で出た臨時の更新は、一覧にありませんでした（「やってみた」の1）。

Patch Manager 側では、公開から一定日数後（既定は7日後）に承認された更新を、メンテナンスウィンドウの実行日に適用します。公式ドキュメントでは、再起動は「更新をインストールした場合」に行われると書かれています。そのため、適用できる更新がない月は、インストールするものがなく、再起動も発生しません。

「毎月の更新は、承認されたあとの最初のウィンドウで適用される」と考えておくと、運用しやすくなります（詳しくは、後の「適用日と、パッチの公開日の関係」を参照）。

Q3. 適用のときに、再起動は発生しますか？

更新によって再起動が必要になった場合は、自動で再起動します。AWS-RunPatchBaseline の RebootOption は、既定が RebootIfNeeded です。再起動はメンテナンスウィンドウの時間内に行われるので、深夜帯に設定しておけば、日中の業務には影響しません。

再起動を避けたい場合は、NoReboot を指定すると、再起動だけを別のタイミングで実施できます。

Q4. 毎月の Windows Update の作業（グループポリシーなどで更新を入れて、再起動する作業）のイメージで合っていますか？

ほぼ合っています。毎月の更新と再起動の作業を、メンテナンスウィンドウで自動化したイメージです。次の点が違います。

• 適用する日時を、メンテナンスウィンドウで指定する（例：毎月の第○日曜の深夜）
• サーバーを、タグ（Patch Group など）でグループに分けて、グループごとに適用日をずらせる
• 適用結果が、Systems Manager のコンソールで一覧できる（準拠状況。「やってみた」の3）
• Patch Manager を使うためのグループポリシーの設定は、不要

なお、Windows Update に関するグループポリシーが、すでに設定されている場合は、その内容（WSUS の指定など）が反映されます。

Q5. Windows の自動更新を無効化しても、Patch Manager は動きますか？

「無効化」の方法によります。グループポリシーと同じ、自動更新のポリシー（NoAutoUpdate）で止める方法は、「自動で入れない」という設定です。一方、Windows Update のサービス（wuauserv）自体を止めると、Patch Manager が使う Windows Update API にも影響する可能性があります。

なお、今回の検証に使った AWS 提供の AMI は、起動した時点で、すでにポリシー（NoAutoUpdate=1）で自動更新が無効になっていました（「やってみた」の2）。

そのため、サービスは止めずに、ポリシーで自動更新だけを無効化するのが、無難な設計と考えています。サービスを無効化したあとでも Scan は成功しましたが、Scan の開始と同時に、サービスの起動の種類が「無効」から「手動」に変わって、起動していました（「やってみた」の6）。サービスが止まったままでも動くかは、今回の検証では確認できていません。Install まで動くかも、確認できていません。

Q6. EC2 の OS パッチ以外（RDS など）も、Patch Manager で適用されますか？

されません。 Patch Manager の対象は、Systems Manager で管理しているノード（EC2 など）の OS です。RDS はマネージドサービスなので、OS のパッチは AWS 側で適用されます。RDS のマイナーバージョンのアップデートは、RDS のメンテナンスウィンドウの設定で制御します。

前提条件・検証環境

なぜ、古い AMI を使うのか：最新の AMI には、直近の月次更新がすでに入っています。そのままだと、未適用の更新がほとんどなく、Patch Manager と Windows Update の見え方を比べられません。

なぜ、ベースラインを変えたのか：既定のベースライン（AWS-DefaultPatchBaseline）は、公開から7日後に承認します。直近に公開された更新が Missing に出ない場合があるため、条件（分類 CriticalUpdates / SecurityUpdates、重大度 Critical / Important）は同じまま、遅延だけを外しました。

Patch Manager は Windows で何をしているのか

公式ドキュメントによると、Windows Server では、次の流れでパッチを適用します。

1. ノードが、Systems Manager からパッチベースラインのスナップショット（承認済みの更新プログラムの一覧）を取得する
2. その一覧を Windows Update API に渡す
3. Windows Update API が、ノードに該当する更新だけを判断して、インストールする
4. 更新をインストールした場合は、必要な回数だけ再起動する（RebootOption で抑止できる）

つまり、Patch Manager が独自のパッチを配っているわけではありません。更新プログラムの出どころは、Windows Update（または WSUS）と同じです。このため、ノードから Microsoft の更新サイトに接続できないと、パッチ適用は失敗します（WSUS を使う構成なら、WSUS に接続できればよい）。

また、Windows Update API を使うので、Windows Update に関するグループポリシーの設定は、そのまま有効になります。 Patch Manager を使うためのグループポリシー設定は不要ですが、すでに設定している内容（WSUS の指定など）は反映される、と書かれています。

適用される範囲：ベースラインで絞られる

同じ出どころでも、Patch Manager が適用するのは、Windows Update の全部ではありません。公式ドキュメントには、次のように書かれています。

By default, Patch Manager doesn't install all available patches, but rather a smaller set of patches focused on security.

AWS が用意している既定のベースライン AWS-DefaultPatchBaseline の条件は、次のとおりです。

このほかに、次の点があります。

• KB 番号がある更新だけが対象です。Microsoft Update や WSUS で KB 番号が付いていない更新は、パッチ適用の対象になりません。
• 置き換えられた更新は、一覧から外れます。 たとえば KB4012214 が KB3135456 を置き換えている場合、Patch Manager の一覧には KB4012214 だけが残ります。
• Office などの Microsoft 製品のパッチは、AWS-WindowsPredefinedPatchBaseline-OS-Applications のように、アプリケーションも対象にするベースラインでないと、適用されません。
• 承認日の計算は、UTC で行われます。

Windows Update（自動更新）との違い

この表の右の列は、一般的な動作に基づく記述です。次の章で、同じサーバー上で、両方の見え方を比べます。

やってみた

0. 検証環境を用意する

インスタンスが、Systems Manager のマネージドノードとして表示されることを確認します。コンソールで Systems Manager → ノードツール → フリートマネージャー を開きます。

1. Patch Manager が知っている更新を見る

Patch Manager は、Microsoft が公開した更新を、リージョンごとに、1日1回以上の頻度で取り込んでいます。まず、どんな更新が、どの分類で入っているかを見ます。

コンソール右上の CloudShell のアイコンを押して、次のコマンドを実行します。

aws ssm describe-available-patches --region ap-northeast-1 \
  --filters Key=PRODUCT,Values=WindowsServer2025 \
  --query "Patches[?ReleaseDate>='2026-07-01'].[ReleaseDate,KbNumber,Classification,MsrcSeverity]" \
  --output table

結果を整理すると、次のとおりです（公開日は日本時間）。

なお、画像の公開日時は UTC で表示されています。上の表の日付は日本時間なので、画像の日付より1日後です（たとえば、2026-09-08T17:00:00+00:00 は、日本時間の 2026-09-09 02:00 です）。また、同じ KB 番号が2行ずつ並んでいるのは、.NET Framework の更新に、x64 用と arm64 用があるためです。

ここから、次のことが分かります。

• 月次の累積更新プログラム（OS 用と .NET Framework 用）は、どちらも SecurityUpdates / Critical に分類されています。既定のベースラインの条件に当てはまります。
• 公開は、毎月1回です。この4か月間に、月の途中で出た臨時の更新は、Windows Server 2025 向けの一覧にありませんでした。

2. 現在の自動更新の設定を確認する

まず、このサーバーの自動更新が、いまどういう設定なのかを確認します。コンソールで Systems Manager → ノードツール → Run Command を開き、右上の 「Run command」 ボタンを押して、次のように設定します。

"NotificationLevel = " + (New-Object -ComObject Microsoft.Update.AutoUpdate).Settings.NotificationLevel
"wuauserv = " + (Get-Service wuauserv).Status + " / " + (Get-Service wuauserv).StartType
(Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -ErrorAction SilentlyContinue | Out-String)

実行したら、コマンドの詳細画面で、対象のインスタンスの「出力を表示」を開きます。

NotificationLevel の値の意味は、次のとおりです。画像の値に当てはまる行が、このサーバーの設定です。

画像のとおり、今回のサーバーは、NotificationLevel = 1（無効）でした。ポリシーの設定（NoAutoUpdate = 1、AUOptions = 2）も入っていて、AWS 提供の AMI（2026.08.12）は、起動した時点から、ポリシーで自動更新が無効になっていることが分かります。Windows Update のサービス（wuauserv）は Stopped / Manual で、停止していますが、起動の種類は手動なので、必要になったときに起動します。

3. パターンA：Patch Manager で Scan する（この AMI の既定の状態）

インストールはせずに、未適用の更新を調べる Scan を実行します。Systems Manager → ノードツール → Run Command → 「Run command」ボタン で、次のように設定します。

次に、Missing（未適用）の更新を確認します。Systems Manager → ノードツール → フリートマネージャー を開き、対象のノードを選んで、左メニューの「パッチ」を開きます。検索欄に Missing と入力すると、未適用の更新だけが表示されます。

結果：Missing は 2件で、2026年10月の更新（OS 用：KB5126646、.NET Framework 用：KB5127690）が出ます。2026年8月の更新（KB5120233、KB5120708）は、この AMI にすでに入っていて、Installed です。

9月の更新（KB5122871、KB5126052）が、Missing に出ないのは、月次の更新が累積で、10月の更新が9月の更新を含んでいるためです。公式ドキュメントにも、新しい更新に置き換えられた更新は、Patch Manager の一覧から外れる、と書かれています。

また、インストール時刻の情報がない行（Missing、NotApplicable、一部の InstalledOther）は、インストール時刻が Thu Jan 01 1970 09:00:00 GMT+0900 と表示されます。これは、時刻の値が空のときに入る初期値（UNIX 時間の 0、つまり UTC の 1970-01-01 00:00:00）を、日本時間で表示したものと考えられます。エラーではありません。

4. Windows Update が見ている更新の「全体リスト」を取得する

同じノードで、Windows Update が見ている未適用の更新を、すべて取り出します。Run Command で、次のように設定します。

$s = New-Object -ComObject Microsoft.Update.Session
$r = $s.CreateUpdateSearcher().Search("IsInstalled=0 and Type='Software'")
"件数: " + $r.Updates.Count
$r.Updates | ForEach-Object {
  "{0} | {1} | {2} | {3}" -f ($_.KBArticleIDs -join ','), (($_.Categories | ForEach-Object Name) -join ','), $_.MsrcSeverity, $_.Title
}

5. 2つの一覧を比べる

「Patch Manager の Missing」と、「Windows Update の全体リスト」を、KB 番号でそろえて比べます。

下の表は、今回の結果です。

月次の更新プログラム（2026年10月分）は、両方に出ます。差が出るのは、ベースラインの条件（分類・重大度）に当てはまらない更新です。今回は、Windows Update の未適用リストが 5件、Patch Manager の Missing が 2件で、差の3件は、Defender の定義更新と、悪意のあるソフトウェアの削除ツールでした。

この3件は、Patch Manager では InstalledOther（ベースラインの対象外の更新）として扱われます。Defender の定義更新は、同じ KB 番号で、新しい版が頻繁に公開されるため、Patch Manager では「何らかの版がインストール済み」、Windows Update では「より新しい版が未適用」と見えている、と考えられます。

6. パターンB：Windows Update のサービスを止める

ここまでの Scan は、ポリシーで自動更新が無効になっている状態で実行しました。次は、もう1つの無効化方法として、Windows Update のサービス（wuauserv）自体を止めて、起動しない設定にします。Run Command（AWS-RunPowerShellScript）で、次のスクリプトを実行します。

Stop-Service wuauserv -Force
Set-Service wuauserv -StartupType Disabled
"wuauserv = " + (Get-Service wuauserv).Status + " / " + (Get-Service wuauserv).StartType

実行すると、wuauserv = Stopped / Disabled と表示され、サービスが停止して、無効になったことが分かります。

そのあと、AWS-RunPatchBaseline（Operation: Scan）を実行します。

Scan は成功して、パターンAと同じ未適用の一覧（KB5126646、KB5127690）が返ってきました。

ただし、ここで注意があります。Scan のあとで、サービスの状態をイベントログで確認すると、Scan の開始と同時に、起動の種類が「無効」から「手動」に変わって、サービスが起動していました。

11:42:20 は、Scan の開始時刻（OperationStartTime）と同じです。この間に実行した他のコマンドは、Run Command の履歴にもありません。そのため、Scan を実行したことがきっかけで、サービスが「手動」に戻って起動したと考えられます（ログには、変更した主体までは記録されていません）。

つまり、今回のパターンBは、「サービスが止まったままの状態で Scan が動いた」ことを示すものではありません。「サービスを無効化しても、Scan を実行すれば、サービスが手動に戻って起動し、Scan は成功する」という結果でした。また、Scan が動くことと、Install が動くことは、別の話です。今回は、Install まで動くかは、確認できていません。

7. 結果のまとめ

ここまでの結果を、表にまとめます。Install は、今回は確認していません。

設計で気をつけたいこと

なぜ、標準の Windows Update を無効化するのか

Patch Manager を使うために、標準の自動更新を止める必要は、必須ではありません。公式ドキュメントにも、無効化を求める記述はありません。それでも、次の理由で、無効化して Patch Manager に一本化する設計が使われることがあります。

• 適用のタイミングを統制できる：自動更新は、OS の予定に合わせてインストールと再起動をします。メンテナンスウィンドウで決めた日時と、ずれてしまいます。
• 再起動が重ならない：Web と App を1台ずつ止めながら適用する構成では、自動更新が両方を同時に再起動すると、サービス全体が止まります。
• 承認の規則を、迂回されない：「公開から7日後に承認」「AZ ごとに時期をずらす」といった規則は、自動更新には適用されません。
• 適用状況を、1か所で見られる：コンプライアンスの画面で、すべてのノードの状態を確認できます。

一方で、無効化すると、Patch Manager の設定が誤っていたり、メンテナンスウィンドウが失敗したりしても、サーバーは気づかれないまま、未適用の状態になります。コンプライアンスの状態を定期的に確認する運用が必要です。

適用日と、パッチの公開日の関係

Microsoft の月例の更新は、毎月の第2火曜日（8〜14日）に公開されます。これに「公開から7日後に自動承認」を組み合わせると、承認されるのは15〜21日です。

• 毎月の 第1日曜（1〜7日） に適用すると、その月の更新はまだ公開前 です。適用されるのは前の月までに承認された更新になります。
• 毎月の 第4日曜（22〜28日） に適用すると、その月の更新は、必ず承認済み です。

適用日を月の前半と後半に分けて、リスクを分散する場合は、この関係を踏まえて、「どの更新が、いつ、どのグループに適用されるか」を確認しておくと安心です。

まとめ

Patch Manager が何を適用するのか、Windows Update と並べて比べてみました。出どころは Windows Update と同じで、月次の更新プログラムも対象でしたが、適用されるのは、ベースラインの条件で絞った一部だけでした。

自動更新の止め方も試してみて、ポリシーで止めた場合は Scan が動くことを確認できました。サービスを無効化した場合も Scan は成功しましたが、Scan の開始と同時にサービスが手動に戻って起動していたため、止めたままでも動くかは確認できていません。次は、メンテナンスウィンドウでの自動実行や再起動も試してみたいと思います。