Microsoft Defenderの「Evolving Windows vulnerability management to meet the speed of AI-powered discovery」は、Defenderに新しいスイッチが追加されたという告知ではありません。MicrosoftがAIを使ってWindowsの脆弱性をより早く発見し、修正・検証までの時間を短縮する方針を示したものです。
企業の管理者にとって重要なのは、今後、1回のセキュリティリリースに含まれる修正が増える可能性を前提に、パッチ管理を「毎月決まった日に配布する作業」から「リスクの高い端末を継続的に優先する運用」へ変えることです。
Windows端末やWindows Serverを管理している組織は対応状況を確認する必要があります。ただし、すでに更新リング、パイロット検証、Microsoft Defenderの更新監視、重要資産の優先順位付けが機能している場合、緊急で有効化すべき新設定はありません。見直すべき対象は、更新が長期間遅延している端末、Defenderの状態を確認できない端末、外部公開サーバー、重要業務を担う端末です。(Windows Blog)
Microsoft Defenderの「Evolving Windows vulnerability management to meet the speed of AI-powered discovery」とは
2026年7月10日時点で公開されているMicrosoft公式記事では、原文ページの掲載日は2026年7月9日と表記されています。
発表の中心は、AIの進歩によって脆弱性の発見速度が大幅に上がるなか、Windowsの開発・修正・更新プロセスも同じ速度に対応させるという方針です。
Microsoftは、複数のAIモデルを組み合わせた脆弱性スキャン基盤「MDASH」をWindowsの解析に利用しています。候補となる問題を単に列挙するのではなく、複数モデルによる検証や議論、Windows向けの実証工程を通じて、誤検知を減らしてからエンジニアへ引き渡す仕組みです。最終的なコードレビューやリスク判断には人間が関与します。(Windows Blog)
今回示された変化を整理すると、次のようになります。
| 観点 | Microsoft側の変化 | 管理者への影響 |
|---|---|---|
| 脆弱性の発見 | AIを使って、より広いWindowsコードを高速に分析 | セキュリティ更新で修正される問題が増える可能性がある |
| 問題の検証 | 複数モデルによる検証と実証工程で誤検知を除外 | 単なるAIの指摘ではなく、再現性の高い問題が修正対象になる |
| 修正の作成 | 原因分析、修正候補、関連箇所の探索、回帰テスト選定をAIで支援 | 発見から修正提供までの期間が短くなる可能性がある |
| 更新品質 | 社内検証やSecurity Update Validation Programなどを継続 | 配布速度を上げつつ、互換性や安定性も検証する |
| 顧客側の運用 | CVE情報、プレビュー更新、DefenderやIntuneの情報を提供 | 一律配布ではなく、リスクに応じた優先配布が必要になる |
Microsoftは、AIによって防御側が発見できる問題が増えるため、各セキュリティリリースに含まれる修正の件数も増えると説明しています。したがって、CVE件数の増加だけを見て「Windowsの品質が急激に低下した」と判断するのは適切ではありません。
一方で、修正件数が増えれば、企業側の検証・配布・監査にかかる負荷も増えます。管理者は、すべてのCVEを同じ優先度で扱うのではなく、自社環境で実際に攻撃経路が成立するかを判断しなければなりません。(Windows Blog)
新しいDefender機能を有効化する発表ではない
今回の発表には、次のような変更は示されていません。
- 新しいMicrosoft Defenderポリシーの強制適用
- 新しいWindows監査ポリシー
- 固有のイベントIDやアラート名
- すべての端末に対する自動修復
- 特定のKBやCVEだけを対象とした緊急対応
つまり、管理者が最初に行うべきことは「新しい設定項目を探すこと」ではありません。既存のMicrosoft Defender、Microsoft Intune、Windows Autopatch、WSUS、Configuration Managerなどを使った更新運用が、脆弱性発見の高速化に耐えられる状態かを確認することです。
影響範囲と保護対象
今回の発表が直接対象としているのは、Windowsのコード、Windowsセキュリティ更新、Windowsを保護するMicrosoft Defenderの仕組みです。
ただし、「Windowsの更新対象」と「Microsoft Defender Vulnerability Managementで可視化できる対象」は一致しない点に注意してください。
| 対象 | 今回の影響 | 管理者の判断 |
|---|---|---|
| サポート対象のWindowsクライアント | 直接影響を受ける | セキュリティ更新の検証・配布期間を見直す |
| サポート対象のWindows Server | 直接影響を受ける | 外部公開、認証基盤、重要業務サーバーを優先する |
| Defender for Endpointにオンボード済みの端末 | 脆弱性、ソフトウェア、推奨事項を確認できる | 未適用端末や高リスク端末を特定する |
| 古いWindows OS | 一部は脆弱性情報を収集できる場合がある | 可視化できても、セキュリティ更新が提供されるとは限らない |
| macOS、Linux、Android、iOS | Defender Vulnerability Managementの製品対象には含まれる | 今回のWindows更新方針による直接影響は限定的 |
| 未オンボード、長期オフライン端末 | Defender上で状態を正しく把握できない | 最も優先して可視化の空白を解消する |
| サードパーティー製アプリ | Defenderで脆弱性を検出できる場合がある | Windows更新だけで修正されるとは限らない |
Microsoft Defender Vulnerability Managementは、WindowsだけでなくmacOS、Linux、モバイルOS、ネットワークデバイスなども対象にしています。一方、今回の公式発表はWindowsの脆弱性発見・修正・更新プロセスを扱ったものです。両者を混同しないようにしてください。(Microsoft Learn)
Windowsでは、Windows 10の一部バージョン、Windows 11、複数世代のWindows Serverについて脆弱性評価機能が提供されています。ただし、Defender Vulnerability Managementの機能表に掲載されていることは、OS自体が通常のセキュリティサポート期間内であることを保証しません。
特に古いOSでは、「脆弱性が見えるが、修正プログラムを通常の方法では入手できない」という状態が起こり得ます。OSのサポートライフサイクル、延長セキュリティ更新の有無、実際の更新提供状況を別に確認する必要があります。また、Windows Serverの脆弱性管理はLTSCビルドが対象で、年次チャネルやInsider、プレビュービルドはサポート対象外とされています。(Microsoft Learn)
管理者が確認すべきMicrosoft Defenderの設定
今回の発表を受けて、すべての環境で共通して変更しなければならない設定はありません。まずは、現在の構成に抜けがないかを確認します。
| 確認項目 | 主な確認場所 | 判断基準 |
|---|---|---|
| Defenderへのオンボード状況 | Microsoft Defenderポータルのデバイス一覧・インベントリ | 管理対象台数とDefender上の台数に大きな差がない |
| 脆弱性管理の推奨事項 | Exposure managementまたはEndpoints配下のVulnerability management | 重要資産に未処理の高リスク推奨事項が残っていない |
| Defender Antivirusの更新状態 | Reports → Device health and compliance → Microsoft Defender Antivirus health | エンジン、プラットフォーム、セキュリティインテリジェンスが最新 |
| Intune連携 | Settings → Endpoints → General → Advanced features | DefenderからIntuneへ修復依頼を送る場合は接続が有効 |
| Windows更新ポリシー | IntuneのWindows updates、更新リング、品質更新ポリシー | 過度な延期、対象外グループ、再起動待ちがない |
| 更新失敗・未報告端末 | IntuneやWindows Autopatchのレポート | Critical、Exposed、Unknownを端末単位で確認できる |
| Defender更新チャネル | Intune、グループポリシーなど | 検証用・段階配布用・本番用の役割が明確 |
Microsoft Defender Vulnerability Managementを利用するには、対象端末がDefender for Endpointの要件を満たし、適切にオンボードされている必要があります。閲覧権限と修復管理権限は分けられるため、セキュリティ担当者と端末管理者の役割も確認してください。(Microsoft Learn)
DefenderとIntuneの修復連携を確認する
Defender Vulnerability Managementでは、セキュリティ推奨事項からMicrosoft Intuneへ修復依頼を作成できます。
この機能を利用する場合は、Microsoft Defenderポータルで次の場所を確認します。
Settings → Endpoints → General → Advanced features → Microsoft Intune connection
Microsoft Intune connectionは既定でオフとされています。利用する場合は、接続を有効にしたうえで、Defender for EndpointとIntuneのサービス間接続、端末のオンボード、必要なライセンスを確認します。(Microsoft Learn)
注意したいのは、Defenderから修復依頼を送信しても、その時点で端末に更新が適用されるわけではないことです。
修復依頼は、Intune側の管理者が内容を確認し、承認または却下し、実際の配布作業を行うためのワークフローです。「チケットが作成された」状態と「端末が修正された」状態を分けて監査してください。(Microsoft Learn)
Defenderの更新とWindowsの更新を分けて管理する
Microsoft Defenderに関係する更新は、一つではありません。
| 更新の種類 | 主な内容 | 一般的な提供頻度 |
|---|---|---|
| セキュリティインテリジェンス更新 | マルウェアや攻撃手法の検出情報 | 1日に複数回提供される場合がある |
| Defenderエンジン更新 | 検出・解析エンジン | 原則として月次 |
| Defenderプラットフォーム更新 | Defender Antivirus本体の機能や基盤 | 原則として月次 |
| Defender for Endpointセンサー更新 | EDRセンサーの修正や改善 | Windowsや管理基盤を通じて提供 |
| Windowsセキュリティ更新 | OSの脆弱性修正 | 原則として月次。必要に応じて臨時提供 |
Windowsの累積更新だけを最新にしても、Defenderのセキュリティインテリジェンスやプラットフォームが古ければ、パッチ適用までの防御力が下がります。反対に、Defenderが最新でも、Windowsの脆弱性そのものが修正されるわけではありません。
Microsoftは、Defender Antivirusがパッシブモードで動作している場合でも、セキュリティインテリジェンス、エンジン、プラットフォームを最新に保つよう案内しています。(Microsoft Learn)
Microsoft Defenderポータルでは、次の場所から更新状態を確認できます。
Reports → Device health and compliance → Microsoft Defender Antivirus health
ここでは、Antivirus mode、エンジン、プラットフォーム、セキュリティインテリジェンスのバージョンと更新状態を端末単位で確認できます。(Microsoft Learn)
公式レポートでは、セキュリティインテリジェンスの公開時刻が7日を超えた端末を「古い」と判定します。ただし、この7日はレポート上の分類基準であり、組織の更新目標にすべき期間ではありません。
今回のWindows公式発表では、エンドポイント保護ソフトを最新にし、日々のシグネチャ更新を受け取ることが推奨されています。通常運用では、少なくとも毎日更新できていることを確認し、7日近く更新が止まっている状態を許容しない方が安全です。(Windows Blog)
Defender更新にも検証用チャネルを設ける
Microsoft Defenderの月次更新には、Beta、Current Channel Preview、Staged、Broadなどの段階的な更新チャネルがあります。
代表性のある少数端末をPreviewまたはStagedへ割り当て、本番端末より先に互換性やパフォーマンスを確認できます。Microsoftは、Stagedチャネルの対象として、端末全体の約10％に相当する代表グループを例示しています。(Microsoft Learn)
ただし、セキュリティインテリジェンス更新まで長期間遅らせるのは避けるべきです。検証すべき対象は主に月次のプラットフォームやエンジン更新であり、日々変化する検出情報は迅速に受信できる構成を維持します。
Windows更新ポリシーをリスクベースで見直す
Microsoftが今回強調しているのは、単に更新を自動化することではありません。
重要なのは、次の条件に応じて配布速度を変えることです。
- 実際に攻撃へ利用されているか
- インターネットから到達できるか
- 認証基盤や重要業務を担っているか
- 端末に高い権限を持つユーザーがサインインするか
- 代替緩和策が存在するか
- DefenderやEDRで端末状態を確認できるか
- 更新失敗や再起動待ちが続いていないか
Microsoft Defender Vulnerability Managementの推奨事項も、脅威情報、侵害の可能性、資産の業務価値を組み合わせて優先順位を付けます。現在のスコアリングには、EPSSによる悪用予測、インターネット公開状態、資産の重要度なども反映されます。(Microsoft Learn)
実務では、次の考え方で優先順位を決めると整理しやすくなります。
対応優先度 = 悪用可能性 × 外部からの到達可能性 × 資産の重要度 × 未適用期間
CVSSが高いという理由だけで、すべての端末を同じ順序で更新する必要はありません。外部から接続できない検証端末より、インターネットに公開され、認証やVPN接続を処理しているサーバーを先に対応すべきケースがあります。
対応優先度の判断表
| 優先度 | 該当する状態 | 推奨する対応 |
|---|---|---|
| 最優先 | 悪用確認済み、外部公開、重要サーバー、更新失敗、Defender情報が古い | 対象を限定して迅速に配布し、適用結果を端末単位で確認 |
| 高 | 重大な脆弱性があり、パッチ提供済みだが一部端末が未適用 | パイロット結果を確認後、次の配布波へ進める |
| 中 | 外部到達性が低く、緩和策があるが、更新期限を超えている | 期限と担当者を設定し、修復タスクとして追跡 |
| 通常 | 最新状態でDefenderの報告も正常、重要な脅威情報なし | 通常の更新リングで継続監視 |
| 要調査 | Unknown、長期オフライン、管理対象外、台帳と不一致 | パッチ以前に端末の所在と管理状態を確認 |
更新リングと検証期間を短縮する方法
更新を速くすることと、全端末へ一斉配布することは同じではありません。
安全に速度を上げるには、少なくとも次の配布層を用意します。
- IT部門や検証専用端末
- 業務アプリを幅広く利用する代表端末
- 一般的な本番端末
- 特殊用途・重要業務・停止が難しい端末
パイロット端末は「余っているPC」ではなく、実際の本番環境を代表する端末を選びます。業務アプリ、VPN、プリンター、認証方式、デバイスドライバーなどが一般端末と異なる検証機だけでは、互換性問題を発見できません。
Windows AutopatchやIntuneの更新リングでは、延期期間、期限、再起動動作、ユーザー通知をグループごとに設定できます。品質更新ポリシーでは、重大なセキュリティ更新を通常の延期設定より早く配布するExpediteや、対象端末で再起動を待たずにセキュリティ修正を適用するhotpatchも利用できます。(Microsoft Learn)
Microsoftは、翌月のセキュリティ更新に含まれる品質改善を事前検証できるよう、月の第4週を目安にオプションの非セキュリティプレビュー更新、いわゆるDリリースを提供しています。
業務アプリとの互換性を早めに検証したい組織は、すべての端末へDリリースを配布するのではなく、代表的な検証端末へ限定して利用すると効果的です。(Windows Blog)
監査と検知への影響
新しい監査イベントやアラートが追加されたわけではない
今回の公式発表には、新しいWindowsイベントID、Defenderアラート名、Advanced Huntingテーブル、監査ポリシーの追加は記載されていません。
そのため、発表への対応としてイベントログの収集設定を一律に変更する必要はありません。
一方で、AIによる脆弱性発見が進むと、環境に該当するCVE、セキュリティ推奨事項、脆弱なソフトウェア、未適用端末がDefenderポータル上で増える可能性があります。監査担当者は、単純なCVE件数ではなく、次の変化を確認すべきです。
- インターネット公開資産の未修正件数
- 重要資産に残っている高優先度の推奨事項
- 更新期限を超えた端末数
- Defenderの状態がUnknownの端末数
- 修復タスクの期限超過件数
- 例外申請に設定された有効期限
- パッチ適用後も残る検知やアラート
Defenderによる検知はパッチの代わりにならない
Microsoftは、脆弱性の公開からセキュリティ更新が全端末へ適用されるまでの間、可能な場合にはMicrosoft Defenderで追加の検知や保護を提供すると説明しています。
ただし、すべての脆弱性に対して専用の検知や防御が提供されるわけではありません。Defenderで攻撃を検知できる可能性があっても、脆弱性のあるコード自体は残っています。
したがって、Defenderのアラートが出ていないことを理由に、セキュリティ更新を延期しないでください。(Windows Blog)
Intuneのリスク表示は配布失敗と同じではない
IntuneのSecurity update statusダッシュボードでは、Windowsクライアント、Windows Server、Microsoft 365 Appsの更新状況をCurrent、Exposed、Criticalなどで確認できます。
公式ドキュメントでは、一般に新しい更新の適用から約3日を過ぎるとExposed、1週間以上遅れるとCriticalになる場合があると説明されています。ただし、更新リングや段階配布のスケジュールはダッシュボードの状態に直接反映されません。
そのため、正常な段階配布中でも、一部端末がExposedと表示されることがあります。表示だけで配布失敗と判断せず、ポリシーの割り当て、更新の提供時刻、端末のチェックイン状況、インストール状態まで掘り下げて確認してください。(Microsoft Learn)
監査証跡として保存すべき情報
AIによる脆弱性発見が高速化すると、「何を修正したか」だけでなく、「なぜその順序で修正したか」を説明できることが重要になります。
| 監査項目 | 保存する情報 |
|---|---|
| 保護対象 | 管理台帳の端末数、Defenderオンボード数、未報告端末 |
| リスク判断 | CVE、悪用状況、外部公開状態、資産重要度、緩和策 |
| 配布判断 | パイロット対象、検証結果、本番配布日、更新リング |
| 適用結果 | 成功、失敗、再起動待ち、長期オフライン、対象外 |
| Defender状態 | エンジン、プラットフォーム、セキュリティインテリジェンスのバージョン |
| 例外管理 | 承認者、理由、代替対策、再評価日、有効期限 |
| 修復管理 | Defenderからの依頼日、Intuneでの承認、完了確認日 |
| 障害対応 | 発生した回帰、影響範囲、Microsoftの既知問題、復旧方法 |
Defender Vulnerability Managementの修復アクティビティは、完了後180日で画面から削除されます。監査証跡をそれ以上保持する必要がある組織は、CSV出力やチケット管理システムへの転記を運用に組み込んでください。(Microsoft Learn)
更新後に問題が起きた場合の注意点
Windows更新で回帰問題が発生した場合、MicrosoftはKnown Issue Rollback、KIRを提供することがあります。KIRは、累積更新全体をアンインストールするのではなく、問題を起こした特定の変更だけを以前の動作へ戻す仕組みです。
ただし、KIRが対象にするのは非セキュリティの変更や修正です。セキュリティ修正そのものはKIRの対象になりません。
そのため、「問題が起きてもKIRでセキュリティ修正を元に戻せる」と考えるのは誤りです。既知の回帰が発生した場合は、Windows Release Healthや該当KBの既知の問題を確認し、Microsoftが示すKIR、回避策、追加更新の内容に従ってください。(Microsoft Learn)
管理者が実施する対応手順
管理対象の空白を確認する
資産管理台帳、Intune、Configuration Manager、Defenderの端末数を比較します。
特に次の端末を抽出してください。
- Defenderにオンボードされていない
- 7日以上チェックインしていない
- セキュリティインテリジェンスが古い
- エンジンやプラットフォームが古い
- OSバージョンが不明またはサポート外
- 更新ポリシーが割り当てられていない
脆弱性の数を数える前に、状態を観測できない端末を減らすことが重要です。
Defenderの推奨事項から優先対象を決める
Microsoft Defenderポータルで、脆弱性、推奨事項、インベントリを確認します。
テナントの状態によって、メニューは次のいずれかになります。
Exposure management → RecommendationsExposure management → Vulnerability managementEndpoints → Vulnerability management → Recommendations
重大度だけで並べず、インターネット公開、資産重要度、悪用情報、アラートとの関連を確認します。
パイロット端末へ配布する
代表的な端末へ更新を配布し、次の項目を確認します。
- 業務アプリの起動と主要操作
- VPNやリモートアクセス
- Windowsサインインと認証
- ファイル共有や印刷
- セキュリティ製品との競合
- CPU、メモリ、ディスク負荷
- 再起動後のサービス起動
- Defenderセンサーの報告状態
問題がなければ、次の更新リングへ進めます。
重要資産を優先して本番配布する
全端末を一斉に更新するのではなく、リスクに応じて配布順を変えます。
優先候補は、外部公開サーバー、認証基盤、VPN関連サーバー、管理者端末、重要業務端末、攻撃経路に含まれる端末です。
一方、特殊な業務アプリを使用する端末は、検証を省略するのではなく、専用の短い検証リングを設けます。
配布命令ではなく端末の状態で完了を判断する
IntuneやWSUSで配布操作を行っただけでは、対応完了ではありません。
次の状態を端末単位で確認します。
- 更新がインストールされた
- 必要な再起動が完了した
- Defenderへ新しい状態が報告された
- 脆弱性または推奨事項が解消された
- 更新後に新しいアラートや障害が発生していない
Defenderの修復タスクは、実際の端末状態を確認してから完了にします。
失敗しやすいポイント
CVEの件数だけをKPIにする
AIによって発見件数が増えると、CVE総数や推奨事項の数も増える可能性があります。
件数の増減だけでは、実際の危険度を判断できません。重要資産に残る高リスク項目、外部公開資産の未修正件数、期限超過端末などをKPIにします。
Defenderの検知をパッチの代替にする
Defenderは、パッチ適用までの攻撃経路を減らす防御層です。脆弱性そのものを修正するものではありません。
検知がないこと、アラートがないこと、EDRが導入されていることを、更新延期の理由にしないでください。
すべての更新を長期間検証する
安定性を重視するあまり、すべてのセキュリティ更新を数週間保留すると、攻撃可能な期間が長くなります。
外部公開資産や悪用確認済みの脆弱性は短い検証で優先配布し、影響が限定される端末は通常リングで配布するなど、検証期間をリスク別に変えます。
Defenderの「7日以内」を運用目標にする
レポート上でUp to dateと判定されても、数日前のセキュリティインテリジェンスを使用している可能性があります。
7日は監視上の分類基準です。実際の運用では毎日の更新状況を確認してください。
修復チケットの作成を完了と扱う
DefenderからIntuneへ修復依頼を作成しても、端末は自動的に更新されません。
Intuneでの承認、配布、インストール、再起動、Defenderへの再報告まで確認します。
古いOSがDefenderに表示されるため安全だと判断する
脆弱性の評価対象になっていることと、OSのセキュリティサポートは別です。
修正プログラムを受け取れないOSでは、Defenderによる可視化だけでリスクを解消できません。アップグレード、隔離、アクセス制限などを優先してください。
まず実施すべき対応
今回の「Evolving Windows vulnerability management to meet the speed of AI-powered discovery」は、単発の設定変更ではなく、Windowsの脆弱性管理を継続的な運用へ変えるための方針です。
管理者は、まず次の4点を確認してください。
- 管理台帳とDefenderの端末数を比較し、未オンボード・未報告端末を特定する
- Defenderのセキュリティインテリジェンス、エンジン、プラットフォームを別々に確認する
- 外部公開状態、悪用可能性、資産重要度を基準に修復順を決める
- パイロット、本番配布、適用確認、例外管理までを監査可能な形で記録する
すでに更新リングと監視が機能している組織は、緊急のポリシー変更より、現在の配布速度と対象範囲の検証が優先です。
一方、長期オフライン端末、状態がUnknownの端末、更新対象外グループ、古いDefenderコンポーネント、サポート外OSが残っている場合は、AIによる発見速度以前に、既存の防御情報を活用できていません。最初に可視化の空白を解消し、そのうえでリスクベースのパッチ運用へ移行することが重要です。
コメント