AIの進化によって、ソフトウェアの脆弱性を発見するスピードが大きく変わり始めています。
AIは防御側にとって、膨大なプログラムから問題を見つけ、修正を支援する有効な技術です。一方で、攻撃者もAIを利用して脆弱性を分析し、攻撃コードの作成や悪用を高速化できます。
これまで企業では、Windows Updateの公開後、数週間かけて検証し、段階的に適用する運用も珍しくありませんでした。しかし、脆弱性の発見から攻撃までの時間が短縮されるなか、従来と同じパッチ適用スケジュールでは、未修正の端末が長期間残り続ける恐れがあります。
Microsoftは2026年7月、AIによって発見される脆弱性の増加を踏まえ、Windows Updateの適用を高速化するための考え方を紹介しました。Windows Autopatch、Microsoft Intune、Hotpatch、条件付きアクセスなどを組み合わせ、更新プログラムの展開と未適用端末の管理を見直す内容です。
本記事では、AI時代にWindowsのパッチ管理がなぜ重要になるのか、企業がどのように更新運用を見直すべきかを、セキュリティコンサルタントの視点から解説します。
AIによってWindowsの脆弱性管理はどう変わるのか
Microsoftは、AIをセキュリティ分析へ活用することで、Windowsのコードに含まれる問題のパターンを従来より早く特定し、より広い範囲から脆弱性を発見できるようになると説明しています。
同社は複数のAIモデルを組み合わせたスキャン基盤を利用し、候補となる脆弱性の検出、検証、修正、テストを高速化しています。AIが発見した内容をそのまま脆弱性として扱うのではなく、複数モデルによる検証と人間の専門家による判断を組み合わせる仕組みです。
防御側がこれまで見つけられなかった問題を早期に修正できることは、利用企業にとって大きなメリットです。
一方、発見される脆弱性が増えれば、毎月提供されるセキュリティ更新プログラムの件数や重要性も高まる可能性があります。Microsoftも、AIによる検出能力の向上に伴い、セキュリティ更新に含まれる修正が増える可能性があるとしています。
つまり、企業側に求められるのは、更新プログラムが公開されるのを待つだけではありません。
更新プログラムを短期間で検証し、問題がない端末から段階的に適用し、適用できなかった端末を継続的に把握する運用が必要になります。
従来の「月1回のパッチ適用」では何が問題なのか
Windowsのセキュリティ更新は、原則として毎月提供されます。
そのため、多くの企業では、更新プログラム公開後に情報システム部門が内容を確認し、検証端末へ適用した後、一般端末へ順次展開しています。この段階的な更新自体は、業務システムとの互換性を確認するうえで有効です。
問題は、検証期間や適用猶予が必要以上に長く設定されているケースです。
例えば、更新プログラムの公開から30日間適用を延期し、さらにユーザーが再起動を先延ばしできる設定になっている場合、実際に修正が反映されるまで1カ月以上かかることがあります。
その間、攻撃者が脆弱性の詳細や攻撃方法を把握すれば、更新されていない端末が狙われる可能性があります。
今後は「毎月更新しているか」だけでなく、次の点を確認しなければなりません。
- 公開から何日以内に更新を開始するか
- 何日以内に全端末への適用を完了するか
- 再起動されていない端末を把握できるか
- 適用に失敗した端末を誰が対応するか
- 長期間更新されていない端末を業務環境へ接続させるか
パッチ管理は、更新プログラムを配信する作業ではありません。未適用端末を特定し、例外を解消するまでがパッチ管理です。
Microsoftが示した新しい更新リングの考え方
Windows Autopatchでは、すべての端末へ同時に更新を適用するのではなく、複数の更新リングへ分けて段階的に展開できます。
2026年7月に更新されたMicrosoftの推奨設定では、品質更新プログラムの延期日数について、テスト端末は0日、第1リングは1日、最終リングでも2日という短い期間が示されています。品質更新の適用期限についても、テストと第1リングは0日、最終リングは1日です。
これは、従来の長い延期期間を前提とした運用から、短期間の段階展開へ移行する考え方といえます。
ただし、すべての企業がこの設定値をそのまま採用すべきという意味ではありません。
基幹システムや特殊な業務アプリケーションを利用する端末では、互換性を確認するための時間が必要です。製造設備や医療機器、開発環境など、更新による停止の影響が大きい端末もあります。
重要なのは、「何となく30日延期する」のではなく、端末の用途とリスクに応じて延期期間を決めることです。
Windows Autopatchとは
Windows Autopatchは、Windows、Microsoft 365 Apps、Microsoft Edgeなどの更新展開を自動化するMicrosoftのサービスです。
企業が定義したグループや更新リングに従い、テスト端末から一般端末へ段階的に更新を配信します。更新の順序、スケジュール、展開状況の管理を自動化することで、情報システム担当者は個別端末への配信作業ではなく、ポリシーや例外の管理に集中できます。
ただし、Autopatchを導入すれば、すべての端末が自動的に安全になるわけではありません。
ネットワークへ接続されていない端末、ポリシーが割り当てられていない端末、ストレージ容量が不足している端末、アプリケーションの互換性問題がある端末などは、更新に失敗する可能性があります。
そのため、自動配信と同時に、失敗端末や管理対象外端末を継続的に確認する運用が必要です。
未更新端末のリスクを可視化する新しいレポート
Microsoft Intuneでは、Windows端末の更新状況を「Current」「Exposed」「Critical」などに分類して表示する機能が提供されています。
「Current」は最新、または一定の猶予期間内にある端末、「Exposed」は最新更新から遅れ、初期猶予期間を超えた端末、「Critical」は必要な更新が長期間適用されていない端末です。
Microsoftの説明では、新しい更新が適用可能になってからおおむね3日を超えるとExposed、1週間以上遅れるとCriticalになる可能性があります。サポートが終了したWindowsバージョンもCriticalとして扱われます。
この可視化で重要なのは、単に未更新端末の台数を表示するだけではないことです。
ポリシーが割り当てられていない、配信設定によって延期されている、端末が長期間通信していないなど、未更新となっている原因を確認できます。
管理画面上では更新率が高く見えても、対象ポリシーから漏れている端末が集計に含まれていない場合があります。Windows Autopatchの管理ステータスレポートでは、Intuneで管理されているものの、クラウド更新ポリシーや更新リングへ所属していない端末も確認できます。
Hotpatchとは
Hotpatchは、対象となるWindowsのセキュリティ更新を、端末の再起動を必要とせずに有効化する仕組みです。
通常のWindows Updateでは、更新ファイルをインストールした後、端末を再起動しなければ修正が反映されない場合があります。ユーザーが再起動を先延ばしすると、管理画面上では更新が配信済みでも、脆弱性が残る可能性があります。
Hotpatchでは、対象となるセキュリティ更新がインストール後に有効になるため、再起動待ちによる未修正期間を短縮できます。更新ファイルも通常の累積更新より小さく、ネットワーク帯域や適用時間の負担を抑えられます。
ただし、「Hotpatchを有効にすれば今後一切再起動が不要になる」という理解は誤りです。
Hotpatchでは、四半期ごとに基準となる累積更新を適用する必要があり、その際には再起動が発生します。基本的には1月、4月、7月、10月がベースライン更新、その後の2カ月が再起動不要のHotpatchという構成です。セキュリティ上の理由から、予定外の再起動が必要になる場合もあります。
また、Hotpatchを利用できるWindowsのバージョン、エディション、ライセンス、管理方法には条件があります。導入前には、自社端末が対象要件を満たしているか確認が必要です。
なお、2026年5月以降、Windows Autopatchで管理される対象端末では、Hotpatchが標準で有効化されています。企業側で準備が整っていない場合は、テナントまたはポリシー単位で無効化できます。
更新されていない端末からのアクセスを制御する
更新プログラムを配信しても、長期間オフラインになっている端末や、更新に失敗している端末は残ります。
こうした端末を放置すると、脆弱な状態のまま社内システムやクラウドサービスへアクセスできてしまいます。
Microsoft IntuneとMicrosoft Defender for Endpointを連携すると、端末のリスクや更新状態に応じてコンプライアンス判定を行い、条件付きアクセスを使って社内リソースへの接続を制御できます。
例えば、必要な更新が適用されていない端末を非準拠として扱い、Microsoft 365などへのアクセスをブロックする運用が考えられます。
ただし、最初から全端末へ厳格なアクセス制御を適用すると、業務停止につながる恐れがあります。
まずはレポートのみを取得するモードで影響を確認し、対象端末数や業務上の例外を把握してから段階的に制御することが重要です。
パッチ適用を速める際の7つの注意点
1．全端末を同じスケジュールにしない
一般的なオフィス端末、管理者端末、役員端末、開発端末、製造設備、共有端末では、更新による影響も、攻撃された場合のリスクも異なります。
端末を用途と重要度で分類し、それぞれに適した更新リングを設定します。
インターネット利用が多い端末や、管理者権限を使用する端末は、より早いリングへ配置することが望まれます。
2．検証端末を実際の業務環境に近づける
検証用に用意した新品のPCへ更新を適用し、起動できたことだけを確認しても、十分な検証にはなりません。
社内で利用しているVPN、EDR、資産管理ソフト、プリンタードライバー、業務アプリケーションなどを導入した端末で検証する必要があります。
部門ごとに代表端末を選び、実際の業務操作が行えるか確認する方法が現実的です。
3．延期日数と適用期限を混同しない
延期日数は、更新が公開されてから端末へ配信を開始するまでの期間です。
適用期限は、配信開始後、ユーザーによる先延ばしをどこまで許可するかを決める期間です。
延期を3日に設定していても、その後ユーザーが再起動を7日間先延ばしできる場合、実際の修正まで10日以上かかる可能性があります。
配信開始日だけでなく、最終的に更新が有効になる日を確認する必要があります。
4．更新失敗を例外として放置しない
パッチ管理で問題になりやすいのは、全体の95％が更新済みになった時点で、運用が完了したと判断してしまうことです。
残り5％に、重要な管理端末や長期間利用されていない予備端末が含まれている可能性があります。
更新に失敗した端末について、担当者、原因、対応期限、例外理由を記録し、解消まで追跡する仕組みが必要です。
5．Windows以外のソフトウェアも管理する
Windows Updateを高速化しても、ブラウザー、PDF閲覧ソフト、圧縮・解凍ソフト、VPNクライアント、リモート管理ソフトなどが古いままでは、攻撃経路が残ります。
Microsoftのセキュリティ更新ダッシュボードにも、サードパーティー製品の更新状況は含まれないという制約があります。
Windows、Microsoft製品、サードパーティーアプリケーションを分けて管理し、それぞれの未更新状況を把握する必要があります。
6．更新トラブル時の復旧方法を決める
パッチを早く適用するほど、問題のある更新による業務影響を心配する企業も多いでしょう。
Microsoftは、更新に問題があった場合、一部の変更を以前の動作へ戻すKnown Issue Rollbackという仕組みを用意しています。
ただし、すべての問題が自動で元に戻るわけではありません。
更新の一時停止、対象端末の切り分け、更新プログラムのアンインストール、端末の再構築など、社内で実行可能な復旧手順も準備しておく必要があります。
7．更新率ではなく、リスクが残る期間を評価する
「今月の更新率は98％」という数字だけでは、十分な評価になりません。
更新公開から適用までの平均日数、重大な更新が期限内に適用された割合、適用失敗端末数、例外の平均解消日数などを確認する必要があります。
重要なのは、何台更新したかではなく、脆弱な状態がどれだけ長く残ったかです。
パッチ運用を見直すための実践手順
最初に、Windows端末の台数、バージョン、用途、管理方法を整理します。Intuneへ登録されていない端末や、更新ポリシーが割り当てられていない端末がないか確認します。
次に、端末をテスト、先行、本番、例外などのグループへ分類します。
テストリングには情報システム部門だけでなく、主要部門の代表端末を含めます。先行リングには一般的な業務を行う少数の利用者、本番リングには残りの一般端末を割り当てます。
その後、現在の延期日数、適用期限、再起動猶予を確認します。長期間に設定されている場合は、一度に短縮せず、業務影響を確認しながら段階的に見直します。
更新開始後は、適用率だけでなく、失敗端末、オフライン端末、ポリシー未割り当て端末を確認します。
最後に、例外端末の理由と期限を管理します。「業務上必要なため更新しない」という状態を無期限に認めず、代替対策や更新可能時期を決めることが重要です。
まとめ
AIは、脆弱性の発見と修正を高速化する一方、攻撃者による分析や悪用も速める可能性があります。
そのため、Windows Updateを月次作業として処理するだけではなく、公開された更新を短期間で検証し、段階的に適用し、失敗端末を解消する継続的な運用へ移行する必要があります。
Windows AutopatchやHotpatchは、更新展開の高速化と再起動による負担軽減に有効です。しかし、ツールを導入するだけで、パッチ管理が完成するわけではありません。
企業が確認すべきなのは、次の点です。
- どの端末を何日以内に更新するか
- 更新に失敗した端末を誰が対応するか
- 例外をいつまで認めるか
- 未更新端末のアクセスをどう制限するか
- 更新による問題が起きた場合にどう復旧するか
AI時代のパッチ管理では、すべての端末へ即日適用することが正解なのではありません。
業務影響を確認する仕組みを残しながら、不要な待ち時間をなくし、リスクの高い端末から素早く更新することが重要です。
よくある質問
Windows Updateは公開当日に全端末へ適用すべきですか？
必ずしも全端末へ即日適用する必要はありません。まず少数のテスト端末へ適用し、問題がないことを確認した後、段階的に展開する方法が現実的です。ただし、明確な理由なく数週間から1カ月延期する設定は、見直す必要があります。
Hotpatchを使えば再起動は不要になりますか？
常に再起動が不要になるわけではありません。Hotpatch対象月のセキュリティ更新は再起動なしで有効化できますが、四半期ごとのベースライン更新などでは再起動が必要です。
Windows Autopatchを導入すれば管理者の作業はなくなりますか？
配信や展開の自動化によって作業量は減りますが、例外端末や更新失敗への対応は必要です。管理者の役割が、個別配信からポリシー、リスク、例外の管理へ変わると考えるべきです。
Intuneを利用していない企業はどうすればよいですか？
WSUS、Configuration Manager、RMM、資産管理ツールなどでも段階展開は可能です。利用製品にかかわらず、端末のグループ分け、延期日数、適用期限、失敗端末の把握、例外管理を設計することが重要です。
Windows以外のアプリケーションも更新が必要ですか？
必要です。攻撃にはブラウザー、PDFソフト、VPN、リモート管理ツールなどの脆弱性も利用されます。Windows Updateとは別に、サードパーティーアプリケーションの更新状況を管理する仕組みが求められます。