Microsoft IntuneやWindows Autopatchを運用する管理者にとって、今回の公式情報で最初に確認したいのは、「新しい緊急パッチが公開されたのか」「すぐに設定変更が必要なのか」という点でしょう。
結論から言うと、2026年7月10日付のMicrosoft公式記事は、特定のCVEや強制的な仕様変更を告知するものではありません。AIによって脆弱性の発見と分析が高速化する状況を前提に、Microsoft Intuneを中心として、更新の自動化、リスク評価、未更新端末の封じ込めを一つの運用にまとめるパッチ戦略を示したものです。(TECHCOMMUNITY.MICROSOFT.COM)
そのため、すべての組織が新機能を直ちに有効化する必要はありません。一方で、Windows Autopatchの割り当て漏れ、更新が7日以上遅れている端末、サポート切れOS、Hotpatchの適格性、業務アプリの更新経路、コンプライアンスポリシーと条件付きアクセスの連携は、優先的に確認すべきです。
Microsoft Intune / Windows Autopatchの「Microsoft publishes an Intune-centered patch strategy for AI-accelerated vulnerability discovery」とは
「Microsoft publishes an Intune-centered patch strategy for AI-accelerated vulnerability discovery」は製品名や新機能名ではありません。Microsoftが公開した公式記事の内容を表すもので、AIによって脆弱性の発見速度が上がる時代に合わせて、Intuneをパッチ運用の中心に据える考え方を指します。
公式記事では、パッチ戦略を次の3段階に整理しています。
| 段階 | 目的 | 主な機能・サービス | 管理者が判断すること |
|---|---|---|---|
| Mitigate（緩和） | 更新できる対象を素早く更新する | Windows Autopatch、Hotpatch、Enterprise App Management | どの端末やアプリを自動更新へ移せるか |
| Assess（評価） | 深刻度だけでなく、露出状況や業務影響から優先順位を決める | Security update status、Microsoft Defender Vulnerability Management、Vulnerability Remediation Agent | 何を、いつまでに修正するか |
| Contain（封じ込め） | すぐに更新できない端末からの被害を限定する | コンプライアンスポリシー、条件付きアクセス、セキュリティベースライン、ASRルール | 未更新端末に何を許可し、何を制限するか |
重要なのは、「すべての更新をすべての端末へ一斉配信する」という方針ではない点です。自動化できる定型作業と、変更管理や互換性検証が必要な例外を分け、例外には期限付きの封じ込め策を適用します。(TECHCOMMUNITY.MICROSOFT.COM)
従来の月例パッチ中心の運用では、深刻度の異なる脆弱性が同じ日程で処理されがちでした。今回の戦略では、実際に悪用されているか、外部へ露出しているか、対象端末が多いか、重要業務へ影響するかを加味したリスクベースの対応が重視されています。
自社で対応が必要かを判断する基準
今回の公式情報だけを理由に、全テナントで緊急変更を実施する必要はありません。次の表を使うと、対応の優先度を判断しやすくなります。
| 現在の状況 | 対応優先度 | 最初に実施すること |
|---|---|---|
| Security update statusにCriticalやサポート切れ端末がある | 高 | 対象端末、更新失敗理由、業務用途、外部露出を確認する |
| Intune管理端末数とAutopatchのポリシー対象数が一致しない | 高 | 割り当て漏れ、除外グループ、未管理状態を調査する |
| 重大なアプリ脆弱性があるが、配布元や更新担当者が不明 | 高 | アプリ所有者と更新パッケージの作成経路を決める |
| Windows 11 24H2以降を利用しているがHotpatchを確認していない | 中 | ライセンス、VBS、ベースライン、品質更新ポリシーを確認する |
| 未更新端末にも社内サービスへのアクセスを許可している | 中 | コンプライアンスポリシーと条件付きアクセスを段階導入する |
| Security Copilotを契約していない | 低 | 追加購入より先に、Autopatchと既存レポートの運用を整える |
| 全端末がポリシー対象で、Criticalがなく、例外も管理されている | 緊急性なし | SLO、監査証跡、例外期限を定期的に見直す |
Security update statusのCriticalは、おおむね1週間以上更新が遅れている端末や、サポート対象外のバージョンを示します。ただし、段階展開中の端末もExposedやCriticalに見える場合があります。ダッシュボードは更新の新しさを評価するもので、Autopatchの展開リングや予定どおり進行しているかまでは判定しません。(Microsoft Learn)
したがって、「赤く表示されたから直ちに全社へ一斉配信する」のではなく、Autopatchのレポートでポリシー対象、展開段階、更新エラー、端末のチェックイン状況を確認する必要があります。
保護対象と影響範囲
今回のパッチ戦略は、Windowsの品質更新だけを対象にしたものではありません。OS、アプリ、ドライバー、ファームウェア、アクセス制御までを一連の運用として扱います。
| 対象 | 主な保護・管理方法 | 確認すべき制約 |
|---|---|---|
| Windowsクライアント | Autopatchによる品質更新、機能更新、ドライバー、ファームウェア、Hotpatch | 対応OS、ライセンス、ポリシー割り当て、端末の準備状態 |
| Microsoft 365 Apps、Edge、Teams | Windows Autopatchによる更新管理 | 対象チャネルや端末の登録状態 |
| Windows向け業務アプリ | Enterprise App Management、Intuneアプリ配布、拡張アプリインベントリ | すべてのサードパーティーアプリが自動更新されるわけではない |
| Windows Server | Security update statusによる可視化 | クライアント向けAutopatchと同じ運用だと考えず、サーバー側の管理経路を別途確認する |
| Appleデバイス | OS自動更新、Background Security Improvement、アプリ更新 | Windows AutopatchではなくIntuneのApple向けポリシーを使用する |
| Androidデバイス | OS更新ポリシー、インストール時間帯、凍結期間、OEM連携 | メーカー、管理方式、端末モデルによって利用可能な機能が異なる |
| 個人所有端末 | アプリ保護ポリシー、コンプライアンス、条件付きアクセス | 会社所有端末と同じ強制更新はできない場合がある |
Windows Autopatchは、Windowsに加えてMicrosoft 365 Apps for enterprise、Microsoft Edge、Microsoft Teamsの更新を自動化します。品質更新では特定更新の迅速化も可能で、ドライバーやファームウェアも管理対象にできます。(Microsoft Learn)
一方、Security update statusダッシュボードは、Windowsクライアント、Windows Server、Microsoft 365 Appsを集約表示しますが、サードパーティー製品の更新状況は含みません。Windowsアプリについては、Enterprise App ManagementやIntuneのアプリインベントリを組み合わせる必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
管理者が確認すべき設定
Security update statusで全体のリスクを確認する
最初に開くべき画面は、Intune管理センターの次の場所です。
Devices > Monitor > Security update status
ダッシュボードには、Windowsクライアント、Windows Server、Microsoft 365 Appsの更新状況がCurrent、Exposed、Criticalなどで表示されます。レポートは約6時間ごとに更新されるため、件数だけでなく「Last updated」の時刻も確認してください。90日以上チェックインしていない端末は、主要なリスク計算から除外されます。(Microsoft Learn)
確認時は、次の順序で調査します。
- Criticalの件数と対象ワークロードを確認する
- Unknown buildと90日以上未接続の端末を別途抽出する
- Intune、Configuration Manager、Microsoft Defender for Endpointなど、必要なデータソースが接続されているか確認する
- Autopatchレポートでポリシー割り当てと展開状況を確認する
- 対策後にダッシュボードへ戻り、件数が減少したか確認する
このダッシュボードは、原因調査やリアルタイム検知の画面ではありません。履歴推移も保存されないため、月例更新ごとに件数やエクスポート結果を保存しておくと、監査や改善確認に利用できます。(Microsoft Learn)
Windows Autopatchの割り当て漏れを探す
Windows Autopatchの設定で最も見落としやすいのは、展開リングの細かな日数よりも「そもそもポリシー対象に入っていない端末」です。
Windows Autopatch management status reportでは、Autopatchのクラウドポリシー、通常の更新リング、未管理状態を含む、Intune管理下のWindows端末全体を確認できます。Update readinessでは、接続性、空き容量、Safeguard Hold、互換性評価、Hotpatchの前提条件など、更新前の阻害要因も検出できます。(Microsoft Learn)
管理者は、少なくとも次の項目を確認してください。
- Intune管理端末数と更新ポリシー対象数が一致しているか
- 除外グループに不要な端末が残っていないか
- 更新の延期日数と期限が社内SLOを超えていないか
- テスト用リングに業務を代表する端末やアプリが含まれているか
- 更新エラーや準備不足のアラートに担当者が割り当てられているか
- 品質更新だけでなく、機能更新、ドライバー、ファームウェア、アプリ更新も管理されているか
展開リングは「全端末を遅くする仕組み」ではありません。代表端末で問題を早期に見つけ、安全性を確認できた端末から順に広げる仕組みです。重要度の低い端末まで長期間待たせる設計では、AI時代の脆弱性発見速度に追いつけません。
Hotpatchが実際に有効かを確認する
Hotpatchは、対象となる月例セキュリティ更新を再起動なしで適用する仕組みです。ただし、「Windows 11 24H2以降なら自動的に再起動不要になる」と考えるのは危険です。
Microsoft Learnで示されている主な前提条件は次のとおりです。
- 対象ライセンスを保有している
- Windows 11 バージョン24H2以降を使用している
- 最新のHotpatchベースラインが適用されている
- Virtualization-based Security、VBSが有効である
- Hotpatchを許可したWindows品質更新ポリシーが作成され、端末へ割り当てられている
Intune管理センターでは、次の経路からWindows品質更新ポリシーを作成または編集します。
Devices > Windows updates > Quality updates
設定内の「When available, apply without restarting the device（Hotpatch）」をAllowにし、対象端末へ割り当てます。既存の延期設定、期限、アクティブ時間はそのまま適用されるため、Hotpatchを有効にしただけで配信速度が自動的に上がるわけではありません。(Microsoft Learn)
公式ブログではWindows 11 24H2以降でのHotpatchが強調されていますが、ブログの表現だけを見て「全端末で適用済み」と判断しないでください。ポリシーのAllow設定、割り当て、VBSの稼働、ベースライン適用状況を実機で確認する必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
また、通常のHotpatchサイクルでは1月、4月、7月、10月が再起動を伴うベースライン月です。2026年7月は通常のベースライン月に当たるため、「Hotpatchを有効にしたのに再起動が発生した」というだけで異常とは判断できません。前提条件を満たさない端末にも、再起動が必要な標準の累積更新プログラムが配信されます。(Microsoft Learn)
Windowsアプリの更新経路を明確にする
OSを最新に保っていても、ブラウザー拡張、PDF閲覧ソフト、圧縮ソフト、開発ツール、VPNクライアントなどに古いバージョンが残っていれば、攻撃経路は残ります。
Microsoftは、Enterprise App Managementの自動更新、アップグレードの置き換え管理、拡張アプリインベントリを、Windowsアプリの更新を早める手段として挙げています。拡張アプリインベントリでは、アクティブな端末のアプリ情報が1日に複数回更新される場合があります。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、Security update statusにはサードパーティー製品の更新状況が表示されません。次の項目をアプリごとに決めておく必要があります。
| 管理項目 | 決める内容 |
|---|---|
| アプリ所有者 | 脆弱性情報を確認し、更新可否を判断する担当部署 |
| 配布方法 | Enterprise App Management、Win32アプリ、ベンダー更新機能など |
| 検出ルール | 修正版がインストールされたことを判定する条件 |
| 展開順序 | 検証端末、先行グループ、全社展開 |
| 例外処理 | 更新できない端末の期限、代替策、ネットワーク制限 |
| 証跡 | 更新前後のバージョン、承認記録、対象端末数 |
「Intuneに端末を登録しているから、業務アプリもすべて自動更新される」という認識は誤りです。アプリごとに更新経路がない場合は、OSパッチとは別の未管理領域として扱います。(Microsoft Learn)
コンプライアンスポリシーで許容するOSビルドを定義する
IntuneのWindowsコンプライアンスポリシーでは、Minimum OS versionだけでなく、Valid operating system buildsを使って複数のOSリリースごとに許容ビルド範囲を指定できます。
複数のWindowsリリースを併用している組織では、単一の最小バージョンよりも、サポート対象リリースごとのビルド範囲を管理する方が実務的です。端末が許容範囲外になった場合は非準拠として扱えます。(Microsoft Learn)
一方、Maximum OS versionを設定したまま更新し忘れると、新しい正常なOSビルドまで非準拠となり、企業リソースへのアクセスを妨げる可能性があります。上限を使う場合は、月例更新や機能更新に合わせて必ず見直す運用が必要です。
コンプライアンスポリシーには、端末を非準拠としてマークするアクションが既定で追加され、初期スケジュールは0日です。いきなりアクセスを遮断するのではなく、利用者への通知、修正手順、猶予期間を設計したうえで条件付きアクセスへ接続してください。(Microsoft Learn)
条件付きアクセスはレポート専用モードから始める
条件付きアクセスでは、「準拠としてマークされたデバイスを要求する」をアクセス条件にできます。これにより、更新基準を満たさない端末からMicrosoft 365などへのアクセスを制限できます。(Microsoft Learn)
ただし、最初から全ユーザーへ強制すると、設定ミスによって管理者自身がサインインできなくなるおそれがあります。Microsoftの手順に沿って、次の順序で進めるのが安全です。
- Intuneでコンプライアンスポリシーを作成する
- 少なくとも1台が正常に準拠状態になることを確認する
- 緊急アクセス用アカウントを条件付きアクセスの対象外にする
- 条件付きアクセスポリシーをレポート専用モードで作成する
- 影響を受けるユーザー、端末、サービスを確認する
- 例外と復旧手順を整備した後に有効化する
Microsoftも、コンプライアンスポリシーを先に作成し、少なくとも1台の準拠端末を確認すること、緊急アクセス用アカウントを除外すること、最初はレポート専用モードで評価することを案内しています。(Microsoft Learn)
更新できない端末には期限付きの封じ込めを適用する
業務アプリの互換性や法令上の変更手続きにより、すぐにパッチを適用できない端末もあります。その場合、例外申請だけで終わらせず、次のような代替策を組み合わせます。
- 条件付きアクセスで利用できるクラウドサービスを限定する
- ASRルールやネットワーク保護を強化する
- Microsoft推奨のセキュリティベースラインを適用する
- インターネットや管理ネットワークへの接続を制限する
- ローカル管理者権限を見直す
- 例外の有効期限と再評価日を設定する
これらはパッチの代替ではなく、適用までのリスクを下げる暫定策です。期限のない例外は、未更新端末を恒久的に残す原因になります。Microsoftも、コンプライアンス、条件付きアクセス、セキュリティベースライン、ASRルールを、更新の遅い端末を保護するための封じ込め策として位置付けています。(TECHCOMMUNITY.MICROSOFT.COM)
監査と検知への影響
ダッシュボードは脆弱性攻撃の検知画面ではない
Security update statusは、「どのワークロードで更新が遅れているか」を判断するための画面です。マルウェア感染、侵入、脆弱性の悪用をリアルタイムに検知するものではありません。
また、更新リングや段階展開を直接評価せず、履歴推移やサードパーティー更新も保持しません。したがって、次の情報を組み合わせる必要があります。
- Security update statusによる更新状況
- Autopatchレポートによるポリシー対象と展開状況
- Update readinessによる更新阻害要因
- Microsoft Defender Vulnerability ManagementによるCVEと露出端末
- Microsoft Defender for Endpointによる脅威検知
- チケットシステムや変更管理台帳による対応記録
「ダッシュボードが緑だから安全」とは限りません。更新対象外のアプリ、未接続端末、オンボードされていないサーバー、別管理の端末が存在しないかも確認してください。(Microsoft Learn)
Intune監査ログで設定変更を追跡する
Intuneでは、ポリシーの作成、編集、削除、割り当て、リモート操作などが監査イベントとして記録されます。監査は全顧客で有効で、無効化できません。
監査ログは、Intune管理センターの次の場所から確認できます。
Tenant administration > Audit logs
監査ログには、操作したユーザーやアプリケーション、変更対象、変更されたプロパティが含まれます。Azure Monitorへ転送することも可能です。(Microsoft Learn)
パッチ運用では、少なくとも次の変更を監視対象にします。
- 更新リングの延期日数や期限の変更
- 品質更新ポリシーの割り当て変更
- Hotpatchの有効化・無効化
- 除外グループへの端末追加
- コンプライアンスポリシーの基準変更
- 条件付きアクセスポリシーの有効化
- アプリ配布や置き換え関係の変更
監査ログだけでは「脆弱性が修正されたか」は分かりません。変更記録と、更新後のOSビルド、アプリバージョン、準拠状態を関連付けて保存する必要があります。
Vulnerability Remediation Agentは自動パッチ機能ではない
Vulnerability Remediation Agentは、Security CopilotとMicrosoft Defender Vulnerability Managementのデータを使い、Intune管理下のWindows端末やアプリに関するCVEを優先順位付けする機能です。影響分析、露出端末、推奨操作、Intuneでの対応手順を提示しますが、現時点ではパブリックプレビューです。(Microsoft Learn)
最も重要な注意点は、エージェントが修正を自動適用するわけではないことです。「Mark as applied」は管理者が修正済みであることを自己申告し、時刻を記録する操作であり、端末側の設定変更やパッチ配信は実行しません。(Microsoft Learn)
また、パブリックプレビュー時点では、次の制約があります。
- Windows Serverは関連CVE数や露出端末一覧に含まれない
- スコープタグをサポートしない
- エージェントの提案データが、管理者に割り当てられたIntuneロールやスコープの外まで見える可能性がある
- 実行開始後に停止または一時停止できない
このため、本番テナント全体で利用する前に、閲覧権限、担当者、対象データ、監査方法を確認してください。(Microsoft Learn)
Security Copilotのエージェントログには、作成、削除、実行、権限エラーなどは記録されますが、検出された脆弱性や修正を適用した時点は含まれません。監査証跡を完結させるには、エージェントのApplied記録だけでなく、変更チケット、Intune監査ログ、修正後のレポートを保存する必要があります。(Microsoft Learn)
Vulnerability Remediation Agentの利用には、Intune Plan 1、Security CopilotのSecurity Compute Units、Microsoft Defender Vulnerability Managementなどの条件があります。今回のパッチ戦略を実行するために、必ずSecurity Copilotを導入しなければならないわけではありません。既存のAutopatch、Intuneレポート、Defenderの情報を整備することが先です。(Microsoft Learn)
実務で使えるリスクベースSLOの例
Microsoftは、固定日程だけでなく、深刻度、露出、業務影響に応じたSLOを設定する考え方を示しています。(TECHCOMMUNITY.MICROSOFT.COM)
次の表は社内ルールを作る際の一例であり、Microsoftが指定する必須値ではありません。
| 区分 | 判断基準の例 | 判断期限 | 修正または封じ込めの目安 |
|---|---|---|---|
| 緊急 | 悪用を確認、外部公開端末、管理者端末、重要認証基盤 | 発見当日 | 可能な限り当日中に封じ込め、72時間以内を目安に修正 |
| 高 | Critical、広範囲の端末に影響、回避策が限定的 | 1営業日以内 | 7日以内 |
| 中 | Highだが外部露出が低く、代替制御がある | 3営業日以内 | 14日以内 |
| 標準 | 既定の月例更新で対応可能 | 次回定例会まで | 月例サイクル内 |
| 例外 | 互換性や規制上の理由で更新できない | 例外申請時 | 封じ込めを適用し、期限を設定して再評価 |
優先度はCVSSだけで決めないことが重要です。同じCriticalでも、インターネットから到達できる端末と、隔離された検証端末では緊急度が異なります。
最低でも、次の要素を評価します。
- 実際の悪用状況
- インターネットや社外ネットワークからの到達可能性
- 対象端末数
- 管理者権限や重要データの有無
- 攻撃に必要な条件
- 回避策や代替制御の有無
- 更新による業務停止の影響
優先して実施すべき対応
今日確認すること
- Security update statusを開き、Current、Exposed、Critical、Unknown buildの件数と更新時刻を記録する
- Windows Autopatch management status reportで、更新ポリシーに入っていない端末を抽出する
- Criticalとサポート切れ端末に、担当者、対応期限、業務用途を割り当てる
- 更新できない端末には、条件付きアクセスやネットワーク制限などの暫定策を設定する
- サードパーティーアプリの重大な脆弱性が、OSダッシュボードの外に残っていないか確認する
今週中に整えること
- Autopatchの展開リング、延期日数、期限、再起動通知を社内SLOと照合する
- Windows 11 24H2以降の端末で、Hotpatchのライセンス、VBS、ベースライン、ポリシー割り当てを確認する
- 重要アプリごとに所有者、配布方法、検出ルール、例外手順を決める
- サポート対象OSごとのValid operating system buildsを設計する
- 条件付きアクセスをレポート専用モードで評価する
- Intune監査ログの保存期間とAzure Monitorへの転送要否を確認する
次回の月例更新までに決めること
- 緊急、高、中、標準のリスク分類と対応期限
- パッチ適用を承認する責任者
- 更新できない場合の封じ込め責任者
- 例外の有効期限と再評価日
- 更新前後の証跡を保存する場所
- Security Copilotを利用する場合のエージェント権限と監査方法
完了の判断基準は、「ポリシーを作ったか」ではありません。次の状態を確認できて初めて、運用が成立しています。
- 稼働中の会社管理端末が、更新対象または承認済み例外のどちらかに分類されている
- Critical端末に担当者と期限が設定されている
- 更新できない端末に封じ込め策が適用されている
- 重要アプリの更新担当者と配布経路が明確になっている
- 条件付きアクセスによる想定外の遮断がない
- 変更内容と修正結果の証跡が保存されている
失敗しやすいポイント
Critical表示を展開失敗と決めつける
Security update statusは、展開リングの計画を評価しません。段階展開が予定どおり進んでいても、更新が新しくない端末はExposedやCriticalになる場合があります。Autopatch側でポリシー、リング、エラーを確認してから判断してください。(Microsoft Learn)
Hotpatchなら再起動が不要だと思い込む
Hotpatchでも、四半期ごとのベースライン更新や例外的なベースライン更新では再起動が必要です。前提条件を満たさない端末には、標準の累積更新プログラムが配信されます。(Microsoft Learn)
Autopatchですべてのアプリが更新されると考える
Windows Autopatchが主に自動化するのは、WindowsとMicrosoft 365 Apps、Edge、Teamsなどの対応ワークロードです。業務用のサードパーティーアプリは、Enterprise App Management、Win32アプリ配布、ベンダー更新機能などを個別に整備します。(Microsoft Learn)
AIエージェントが自動修正すると誤解する
Vulnerability Remediation Agentは、脆弱性を優先順位付けし、推奨手順を示す機能です。修正の適用、検証、変更承認は管理者側で実施します。「Mark as applied」を押しても、端末には変更が加えられません。(Microsoft Learn)
条件付きアクセスを最初から全社で有効化する
準拠状態や例外を確認せずに有効化すると、利用者だけでなく管理者も締め出される可能性があります。コンプライアンスポリシーを先に作り、レポート専用モードと緊急アクセス用アカウントを利用して段階的に展開します。(Microsoft Learn)
OSバージョンの上限を更新し忘れる
Maximum OS versionやValid operating system buildsを固定したまま放置すると、新しい正常なビルドが非準拠になる場合があります。月例更新と機能更新の運用に、許容ビルド範囲の見直しを組み込んでください。(Microsoft Learn)
まず可視化し、次に自動化と封じ込めを整える
2026年7月10日に公開されたMicrosoftの公式情報は、単発の新機能紹介ではなく、AIによって脆弱性対応の速度が上がる時代に合わせた運用モデルです。
管理者が優先すべきなのは、いきなり新しいAI機能を購入することではありません。まずSecurity update statusで更新状況を可視化し、Windows Autopatchで割り当て漏れと更新阻害要因を特定します。そのうえで、Hotpatchとアプリ更新を自動化し、更新できない端末にはコンプライアンス、条件付きアクセス、セキュリティベースラインによる封じ込めを適用します。
最初の一歩は、Intune管理センターでSecurity update statusを開き、Critical、Unknown build、90日以上未接続の端末を確認することです。緊急対応が必要な端末がなければ、一斉変更は不要です。割り当て漏れ、サポート切れ、未管理アプリ、期限のない例外が見つかった場合は、担当者と期限を決めて修正または封じ込めへ進んでください。
コメント