■はじめに
Azure Update Manager（AUM）への移行に際し、以下の3点で混乱しやすい論点を実運用で解消した手順とナレッジをまとめます。
かなり長い内容となりますが、AUM運用の参考にして頂ければと思います。

・更新分類が初期化されるように見える
・Windows OS側の「更新履歴」に載らない
・「再起動しない」のはずが再起動されるてしまう

AUMの更新はWindows Updateクライアント（WUA）を用いて行われ、場合によってはOS の更新履歴UIに表示されないこと、またレジストリやGPO設定によっては「Never」でも再起動が発生し得ることを押さえるのがポイントです。

アップデートマネージャーの仕組み

■前提
今回の前提としては以下となる。

・既存のWSUS/手動更新からAUMへ移行
・運用は2リング：Latest（毎週）とStable（毎月）
・OSのみを更新対象（SQL Serverなどの他製品は除外）
・再起動はGPOで厳格管理。AUM の再起動設定は 原則「Never」で衝突回避
・Periodic assessment を有効化し、24時間毎に評価を実施（可視化と準備のため）
　アップデートマネージャーの評価オプション

補足：AUMは更新ソースを提供しません。Windowsは WUAが参照する更新元（Windows Update/Microsoft Update/WSUS）から取得しAUMはそのオーケストレーションを行います。

■まず押さえる仕様（混乱ポイント！！）

1．「更新履歴に載らない」ことがある
AUMはWUA API経由で更新を実施します。WUA経由のインストールは、Windows の「設定 > Windows Update > 更新の履歴」に表示されない場合があります。
適用可否はイベントログ（WindowsUpdateClient）やAUM側の結果で確認します。

・イベントビューア確認手順（Windows）
イベント ビューアー > Windows ログ > システム で ソース：WindowsUpdateClient をフィルタ。必要に応じて Setup ログや Get-WindowsUpdateLog も活用します。

・AUM 側の確認（Azure Resource Graph）
評価結果は直近7日間、インストール結果は直近30日間までARGで参照可能です（後述KQL例を参照）

2．「Never」にしても再起動する場合がある
AUMのドキュメントでは、レジストリで構成された自動更新／再起動関連キーが優先して再起動を引き起こす可能性が明記されています。「Scheduleの Reboot=Never」でも再起動する場合があるため、GPOと整合した全体設計が必須です。

今すぐアップデートをデプロイし、Azure Update Managerで結果を追跡しましょう

3．更新ソース・GPOの競合
グループポリシーはAUMの意図を上書き・衝突させ得ます。AUOptions や No auto-restart、WSUSの強制などの設定がAUMの挙動に影響するため、AUMとGPOの役割分担を決め、矛盾する値は置かないのがベストプラクティスです。

対象分類（OSの安定性重視）
・重要な更新／セキュリティ更新／定義の更新（Defender など）
　→OS以外のMicrosoft製品（SQL/Office等）は除外し、必要に応じて別リングやWSUS側で管理（製品更新を含めたい場合は Microsoft Update を有効化）。

■仕様を踏まえた運用方針

配信リング
・Latest：毎週日曜 0:00 開始（セキュリティ早取り）
・Stable：毎月「第1日曜」0:00 開始（本番重視）
・Periodic assessment：有効（毎24h）。評価→スケジュール実行へ

再起動ポリシー
・AUM：スケジュールのReboot=Neverを基本
・GPO：業務時間内の再起動禁止、自動再起動抑止、計画再起動は別ウィンドウ
　理由：レジストリ/GPOによりNeverでも再起動が発生し得るため、最終権限はGPOで担保。

監査と可視化
・イベントビューア（WindowsUpdateClient）でローカルの適用可否を確認
・AUM/ARGで評価・配布・結果を横断確認（KQLは後述)

■実装手順

1．Patch orchestrationの選択
Customer Managed Schedules（Azure-orchestrated）を利用し、Maintenance Configurationでスケジュールを管理

——————————–
Patch mode = Azure-orchestrated
BypassPlatformSafetyChecksOnUserSchedule = TRUE（安全性チェックを回避してユーザースケジュールを優先）
Periodic assessment有効化（24h）
※Arcサーバーは同様の考え方で適用可。
——————————–

2．Maintenance Configuration の作成
Latest/Stable の2本を作成し、各リングに対象VM（動的スコープ推奨）を紐づけサービス上限（スケジュール数、スコープ数）にも留意。

3．更新分類・KB含め方
スケジュールの分類は上記3種に限定
KB/パッケージ ID の個別指定は「ピンポイントの一斉配布」に有効（定常運用では最小限に）。

4．再起動制御の整合
AUM のReboot=Neverを設定
GPOで以下を設定しAUMの意図と矛盾しないように整理。

・自動更新の挙動（AUOptions）
・ログオン中は自動再起動しない
・アクティブ時間の明示

5．Microsoft Update を使うかの判断
OS以外（SQL/Office等）の更新もAUM配下で配布したい場合は、Microsoft Update を有効化。
第三者（サードパーティ）更新は AUM単体では扱えないため、WSUS等と組み合わせが必要。

■監査・可視化の実例

A. ARG（Azure Resource Graph）で結果を一覧
直近7日〜30日の評価/配布履歴を横断確認。下はインストール結果の例。

——————————–
※KQLのサンプル
// 直近30日のパッチインストール結果（要点表示）
patchinstallationresources
| where type !has “softwarepatches”
| extend prop = parse_json(properties)
| extend lTime = todatetime(prop.lastModifiedDateTime),
OS = tostring(prop.osType),
installed = tostring(prop.installedPatchCount),
failed = tostring(prop.failedPatchCount),
pending = tostring(prop.pendingPatchCount)
| where lTime > ago(30d)
| project lTime, OS, installed, failed, pending, name
| order by lTime desc
“
——————————–

失敗/警告のみを抽出する GitHub のKQLサンプルも参考になります

B. イベントビューア（ローカル確認）
WindowsUpdateClient で適用イベント、Setup ログでインストール履歴を追跡。必要に応じて Get-WindowsUpdateLogで確認すること。

■よくある落とし穴と回避策

・分類が初期化されるように見える
UIの反映遅延や別画面遷移で未選択に見えることがあります。実体はメンテナンス構成（スケジュール）側の保存内容とデプロイ実績をARGで検証し、矛盾がないかを確認します。

・履歴に載らない＝当たっていない？
WUA API適用分は設定アプリの履歴に出ない場合があります。イベントログ/ARGで確認するのが確実。

 

・Neverにしたのに再起動
レジストリ/GPOが再起動を要求し得ます。AUMのNeverは絶対抑止ではない前提で、GPO側を最終制御とする設計が安全。

・OS以外の更新が混ざった
Microsoft Updateを有効化すると他製品（SQL/Office等）も対象になります。OSだけに限定したい場合は有効化しない／分類選択を最小化。

■実運用で使えるテンプレ

今までの内容を踏まえたテンプレは以下となります。

 

・スケジュール（例）
Latest：毎週日曜 00:00（90分窓）／分類＝重要・セキュリティ・定義／Reboot=Never
Stable：毎月第1日曜 00:00（180分窓）／分類＝重要・セキュリティ・定義／Reboot=Never

・GPO（例）
自動更新の構成：通知中心／自動再起動の抑止を有効
アクティブ時間の指定：業務時間に合わせる（例：07:00–22:00）
他製品の更新：要件に応じて明示的に無効化／WSUS利用時はソース固定を徹底
（AUM と矛盾する値は設定しない）