Azure Update ManagerでAzure／Arcのパッチ管理を一元化する

結論。Azure VM、オンプレミスサーバー、他クラウド上のサーバーを含めてパッチ管理を説明できる状態にするなら、Azure Update Managerは単なる「更新ツール」ではなく、パッチ管理台帳・例外管理・監査証跡の基盤として設計すべきです。

理由は、パッチ適用状況を説明できない状態だと、監査対応、脆弱性対応、インシデント発生時の初動で必ず詰まるからです。「どのサーバーに、いつ、どの更新が入り、何が未適用で、なぜ例外なのか」ここを説明できなければ、情シス担当者も経営層も、リスクを正しく判断できません。

数字で見ると、最低限管理すべき項目は10個です。

1. 対象サーバー

2. Azure VM／Azure Arc対応サーバーの区分

3. OS種別

4. システムオーナー

5. 重要度

6. メンテナンスウィンドウ

7. 最終評価日時

8. 未適用パッチ

9. 最終適用結果

10. 例外理由・期限・承認者

Microsoft公式情報では、Azure Update Managerは、Azure、オンプレミス、その他クラウド環境にあるAzure Arc接続済みマシンを含め、WindowsおよびLinux更新プログラムのコンプライアンスを単一の管理画面で監視し、定義したメンテナンス期間内で更新をスケジュールできる統合サービスです。確認日：2026年7月8日、Microsoft Learn最終更新日：2025年11月19日。

ここで大事なのは、「Azure上のVMだけを見る」のでは足りないという点です。現場では、Azure VM、オンプレミスのWindows Server、Linux、閉域環境、既存WSUS配下のサーバー、段階的にArc化されたサーバーが混在します。クラウド移行期の企業ほど、パッチ管理が複数台帳・複数ツール・属人運用になりがちです。

Azure Update Managerを使う意味は、この混在環境を一つの管理軸に寄せることです。ただし、ツールを入れれば監査に耐えられるわけではありません。監査で問われるのは、画面の有無ではなく、説明できる運用です。

たとえば、次の質問に即答できるでしょうか。

「本番サーバーで未適用のCritical／Security更新は何件ありますか」「その未適用は作業漏れですか、業務都合の例外ですか」「再起動不可のサーバーは誰が承認していますか」「WSUS承認待ちで止まっている更新はありませんか」「Arc接続サーバーはAzure VMと同じ基準で見えていますか」「パッチ適用失敗後、誰がいつ再実行判断をしましたか」

ここに答えられないと、パッチ管理は“実施しているつもり”で止まります。

NIST SP 800-40 Rev.4では、エンタープライズパッチ管理は、組織全体でパッチ、更新、アップグレードを識別、優先順位付け、取得、インストール、検証するプロセスとされています。また、パッチ管理は技術の予防保守であり、侵害、データ漏えい、運用停止などを防ぐために重要と説明されています。公開日は2022年4月です。

つまり、パッチ管理は「毎月Windows Updateを当てる作業」ではありません。資産管理、脆弱性管理、変更管理、再起動調整、業務影響確認、例外承認、監査説明まで含む、企業のリスク管理です。

Azure Update Managerを実務で使う場合、私は次の順番で整理します。

まず、対象サーバーを棚卸しします。Azure VMだけでなく、Azure Arc対応サーバーも含めます。サーバー名、リソースID、OS、環境区分、本番／検証／開発、業務システム名、担当部署、システムオーナー、再起動可否、保守時間帯を台帳化します。

次に、タグ設計を行います。たとえば、Environment=Prod、PatchGroup=Monthly-Prod、Owner=FinanceSystem、RebootAllowed=Yes/No、Criticality=Highのように、パッチ管理に使うタグを標準化します。タグが曖昧だと、Dynamic Scopeで対象を自動選定しても、意図しないサーバーが含まれたり、逆に重要サーバーが漏れたりします。

Microsoft公式情報では、Azure Update Managerのスケジュール更新ではMaintenance Configurationを使い、更新対象マシン、インストールする更新、メンテナンス期間、日次・週次・月次などの繰り返し条件を指定できます。なお、Azure Update Managerはドライバー更新をサポートしないことも明記されています。確認日：2026年7月8日、Microsoft Learn最終更新日：2025年8月21日。

この「ドライバー更新は対象外」という点は、意外と重要です。監査や障害対応で「Update Managerで全部見ているはず」と言ってしまうと危険です。OS更新、セキュリティ更新、Critical更新は見えていても、ドライバー、ファームウェア、ミドルウェア、アプリケーション更新は別管理になる可能性があります。

次に、Maintenance Configurationを設計します。本番サーバー、検証サーバー、開発サーバーを同じ時間帯にまとめて更新するのは危険です。本番は月次、検証は本番の1週間前、開発はさらに前倒し。Web、AP、DBで段階を分ける。再起動が必要なサーバーは業務停止時間と紐付ける。このように、業務影響を前提にスケジュールを組む必要があります。

Azure Update Managerでは、即時更新と、定義されたメンテナンスウィンドウ内でのスケジュール更新を選択できます。また、スケジュールパッチ適用ではAzure VMのパッチオーケストレーションをCustomer Managed Schedulesに設定することが前提として示されています。確認日：2026年7月8日、Microsoft Learn最終更新日：2025年9月14日。

ここで現場が詰まりやすいのが、Windows Update設定やWSUSとの関係です。Microsoft公式情報では、Azure Update ManagerはネイティブのWindows Updateクライアントを使ってパッチを管理し、Azure VMとAzure Arc対応サーバーで動作が異なること、WSUSを使う場合はWSUS側で更新が承認されている必要があることが説明されています。確認日：2026年7月8日、Microsoft Learn最終更新日：2026年6月15日。

つまり、Azure Update Managerの画面上でスケジュールを作っても、WSUS側で更新が承認されていなければ、期待どおりに適用されない可能性があります。これは現場ではかなり重要です。「Azure側は設定済みです」「でもOS側・GPO側・WSUS側で止まっています」この切り分けができないと、パッチ管理はすぐに責任分界の問題になります。

次に、評価結果と履歴の見方を標準化します。Microsoft公式情報では、Azure Update Managerの履歴画面からAzure VMとAzure Arc対応サーバーの評価・展開履歴を確認でき、さらに更新評価・展開データはAzure Resource Graphでクエリできると説明されています。確認日：2026年7月8日、Microsoft Learn最終更新日：2024年12月4日。

ここは、監査対応で非常に使えます。画面で確認するだけでなく、Resource Graphで一覧化し、Excelや監査回答資料に落とす。「本番サーバーの最終評価日時」「Critical未適用件数」「前回パッチ適用の成功／失敗」「例外対象」を定期的に出せるようにする。ここまでやって、初めて“説明できるパッチ管理”になります。

ただし、注意点もあります。Microsoft公式情報では、Azure VMの評価では、最新更新の取得はRunning状態のAzure VMに対して行われ、StoppedまたはStopped deallocated状態のマシンは未適用更新のスキャン対象にならないと説明されています。確認日：2026年7月8日、Microsoft Learn最終更新日：2024年12月6日。

これは、停止中の検証機や夜間停止しているコスト削減対象VMで問題になります。「パッチ未適用がない」のではなく、「評価されていないだけ」というケースがあり得ます。監査資料では、この違いを分けて説明しなければなりません。

私が推奨するパッチ管理台帳の項目は、次の通りです。

・サーバー名・AzureリソースID・Azure VM／Arc対応サーバーの区分・OS種別、OSバージョン・環境区分・業務システム名・システムオーナー・運用担当者・重要度・メンテナンスウィンドウ・再起動可否・最終評価日時・最終パッチ適用日時・未適用Critical件数・未適用Security件数・前回適用結果・失敗理由・例外有無・例外理由・例外期限・例外承認者・代替策・次回見直し日

特に重要なのは、例外管理です。パッチ管理で一番危険なのは、未適用そのものではありません。「未適用の理由が誰にも説明できない状態」です。

例外には、あり得る理由があります。

・業務アプリの互換性確認待ち・ベンダー検証待ち・再起動不可期間・決算期、繁忙期、止められない業務日程・WSUS承認待ち・既知不具合の回避・後継サーバー移行予定・EOL対応中・閉域環境での更新配布制約

ただし、例外は放置ではありません。例外には、必ず期限、承認者、リスク所有者、代替策が必要です。

たとえば、「KBxxxxは業務アプリ不具合のため30日延期」「承認者：システム責任者」「代替策：該当サーバーへの外部通信制限、EDR監視強化、WAFルール確認」「次回見直し：翌月パッチ会議」ここまで書いて初めて、例外管理になります。

監査対応で強いのは、こういう台帳です。

「未適用はあります。理由はこれです。期限はこれです。承認者はこれです。代替策はこれです。次回見直し日はこれです。」

逆に弱いのは、こういう状態です。

「たぶん適用されています」「未適用はなかったと思います」「担当者が確認しているはずです」「例外はありますが、理由は詳しくわかりません」

この差は大きいです。

Azure Update Managerの導入で目指すべき姿は、単なる自動更新ではありません。目指すべきは、次の状態です。

・Azure VMとArc対応サーバーを同じ軸で見られる・本番、検証、開発でパッチ適用方針が分かれている・Maintenance Configurationが業務カレンダーと合っている・Dynamic Scopeやタグで対象漏れを減らしている・WSUS、GPO、Windows Update設定との関係が整理されている・未適用パッチをCritical／Securityで説明できる・例外理由、期限、承認者が台帳化されている・履歴と証跡をResource Graph等で出力できる・監査、事故対応、経営説明に使える資料になっている

山崎行政書士事務所では、Azure技術支援とクラウド法務・ガバナンス支援を一体で行います。

Azure Update Managerの設計、Azure Arc対応サーバーの整理、Maintenance Configuration設計、パッチ管理台帳、例外管理、監査説明資料、社内規程、運用ルール整備まで、技術面と法務面の両方から支援します。

行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域は切り分けつつ、企業がクラウドを安全に運用し、情シス担当者や経営層が説明できる状態を整えることを重視しています。

パッチ管理は、単なる更新作業ではありません。企業の情報資産を守り、事故時に説明責任を果たすための、重要なクラウドガバナンスです。

Azure／Arc環境のパッチ管理台帳、例外管理、監査対応資料の整備は、山崎行政書士事務所へご相談ください。