私たちはパッチ・アポカリプスのただ中にいる。つまり、IT部門のこの3つの言い訳はもう通用しない。

要点

• AnthropicのClaude MythosのようなAIモデルが、主要なOSやブラウザーで深刻度の高い脆弱性を次々と発見している。これにより、悪用までの猶予期間は短くなり、従来型の手作業によるパッチ適用プログラムは対応しきれなくなっている。
• 規模が大きくなると、従来のパッチ適用ワークフローは機能しなくなる。脆弱性スキャナーだけに頼ったり、チケットベースの直線的な承認を行ったり、可視性の限られたエンドポイントツールを使ったりすると、CVEの件数と発生ペースが急増した際に遅延や見落としが生じ、リスクが拡大する。
• 攻撃者と防御側の双方がAIを活用して高速化する中、IT・セキュリティチームが追随するには、継続的なトリアージ、リスクベースの優先順位付け、ロールバックに対応したリング方式の展開、そしてクローズドループの検証しかない。

4月7日、Anthropicは、Claude Mythos Previewモデルが主要なすべてのOSと主要なすべてのウェブブラウザーで、深刻度が高い、または重大なゼロデイ脆弱性を数千件、自律的に特定したと発表した。その99%以上が、開示された当日には未パッチだった。

2週間後の4月21日、Mozillaは、同じモデルを使って最新版Firefoxの脆弱性271件を発見し、パッチを適用したと発表した。Mozilla自身の評価はこうだ。「これまでのところ、人間が発見できてこのモデルには発見できない脆弱性のカテゴリーや複雑さは見つかっていない」

271件は第一波にすぎない。Chrome、Edge、Windows、macOS、Linux、FreeBSD――Anthropicのレッドチームが開示したFreeBSDの17年前から存在するリモートコード実行の欠陥（CVE-2026-4747）は、これから起きることの初期の一例だ。AnthropicのProject Glasswingの傘下にあるすべてのベンダーが、業界がこれまで見たことのないペースで修正をリリースする態勢にある。そうした修正はすべて、パッチが利用可能な公開CVEとなり、同じ場所に行き着く。つまり、あなたの環境だ。

封じ込めにもほころびが見えている。4月21日、Bloombergが報じたところによると、Discordとつながりのあるグループが、サードパーティーベンダーの環境を通じてMythosへの不正アクセスを得た。Anthropicは、この活動はそのベンダーの範囲を超えていないとしている。同様の能力がすでに攻撃者の手中にあるかどうかにかかわらず、防御に残された時間は、4月7日の発表が示唆したものより短い。

Mythosが登場した世界は、すでにこの方向へ進んでいた。CrowdStrikeの2026年グローバル脅威レポートは、2025年にAIを活用した攻撃が前年比89%増加したと記録している。この傾向はMythos以前から存在していた。

これをパッチ・アポカリプスと呼ぼう。ここでいうのは、パッチが利用可能な公開CVEの件数と発生ペースが、ほとんどのIT・セキュリティチームの現在の対応能力をまもなく上回るという、ありふれた運用上の危機だ。

NISTはすでにパッチ・アポカリプスの影響を受けている。4月、同機関は、登録件数が263%急増したことを受け、National Vulnerability Database（NVD）の運用を大幅に変更すると発表した。NISTは今後、登録されたすべての脆弱性に詳細な補足情報を提供することはせず、CISAのKnown Exploited Vulnerabilitiesカタログに掲載されたものや、政府の重要なソフトウェアに影響するものなど、高リスクの基準を満たす脆弱性にのみ提供する。NISTは独自に評価を行うのではなく、IvantiなどのCVE Number Authorities（CNA）に依存することになる。

この発表以来、顧客や同業者から、同じ反応を3通りに表現したものを聞いてきた。いずれも、より遅い世界を前提に設計されたプログラムの変形にすぎない。

「脆弱性スキャナーがある」

Qualys、Rapid7、Tenableは脆弱性の発見に長けている。スキャナーは見つけ、警告し、スコアを付け、一覧化する。展開、検証、再起動への対応、ロールバックは対象外だ。その作業はどこかで行わなければならない。ほとんどのプログラムでは、別のツール、別のチーム、別の頻度で行われている。

悪用までの猶予が数時間となり、Glasswingのキューによって未処理分がまもなく倍増する状況で、重大な脆弱性587件を出力して人間のチームにリストを渡すだけのスキャナーは、むしろ負債になる。実務的には、すでに保有しているスキャナーを、その検出結果に自動で対応できる修復エンジンに接続することだ。さらに、自律型エンドポイント管理（AEM）プラットフォームを、リング方式の展開とロールバック、そして効率的な修復判断のためのリスクベースのコンテキストを提供する脆弱性インテリジェンスとともに導入すれば、人間が一つひとつ判断しなくてもリストを縮小できる。

「チケットシステムで承認を進めている」

人間が判断しなければならない話といえば……長く直線的な承認プロセスは、修復を大幅に遅らせる。最新のOSやブラウザーのアップデートを展開するかどうか、最後に判断しなければならなかったのはいつだろうか。

組織はすでに、これらのアップデートを展開することを理解している。承認プロセスが必要になるのは、多くの場合、社内政治が複雑で、セキュリティ上の成果について認識が一致していないためだ。結果はどうなるか。先ほどの脆弱性スキャナーが必要になり、すでに実施すべきだと分かっていることをアナリストが承認し、承認を求めるチケットが業務オーナーに送られて受信箱で待機し、結局のところ、すでに十分理解されていて判断する必要もなかった事柄に貴重な時間を浪費する、非常に直線的なプロセスになる。

市場で進むエクスポージャー管理への移行では、このプロセスにまったく異なる方法で取り組み、組織のリスク許容度を定義し、リスク態勢を監視する。次にWindows OSのアップデートがリリースされたとき、展開することも、展開するスケジュールも、成功を測るSLAやコンプライアンス指標も、すでに分かっている。本当に知りたいのは次の点だ。

1. そのアップデートに既知の悪用済み脆弱性が含まれているため、より迅速に対応する必要があるか？

それとも

2. アップデートが業務に影響するため、ペースを落とす必要があるか（自律型エンドポイント管理プラットフォームにロールバック対応のリング展開が含まれているのはありがたい）？

「Intuneがある」

Microsoft Intuneには、ここで重要になる適用範囲の限界が2つある。

第一に、管理できるのは登録済みのデバイスだけだ。未登録・未管理のエンドポイント――サーバー、請負業者のノートPC、シャドーIT、放置されたエッジデバイス――は、完全に可視性の外にある。脆弱性の件数が増える時期には、こうした死角がチームの手作業による対応能力を上回る速度で増えていく。

第二に、Intuneはアプリケーションの展開と更新を簡素化する一方、サードパーティーアプリのカバレッジと優先順位付けの深さは、多くの管理者が認識しているより限定的だ。Intuneが教えてくれるのは期限切れのものであって、実際にエクスポージャーを高めるものではない――そのため、時間が限られていると、チームはすべてに場当たり的にパッチを適用するか、推測に基づいて対応することになる。

企業環境の大半は、Windowsだけで構成されているわけでも、すべてのデバイスが登録済みなわけでも、同質な小規模のアプリケーション群を実行しているわけでもない。脆弱性の開示が急増すると、パッチ適用の振り分けに抜け漏れが生じ、システミックリスクへと発展する。

Intuneはそのまま使えばよい。Intuneから見えない資産を見つけ、最も重要な脆弱性に優先順位を付け、Intuneがカバーしていないアプリケーション全体に確実にパッチを適用できる、検出・修復レイヤーと組み合わせよう。

どう対応すべきか

自動化が運用モデルになる。それをワークフローに組み込まなければならない。

実務担当者は以前からこの原則を理解していた。それは次の3つに表れている。

• 継続的なトリアージ。既知の悪用済み脆弱性には、組織内でもエンドユーザーシステムのように安全性が低い部分で特に、ゼロデイ対応の手順を適用できる。その上で、ブラウザーや通信アプリなど、優先対応の対象として具体的なアプリケーションを設定・定義し、毎週、場合によっては毎日チェックして更新する。それ以外は、定期メンテナンスの時間が来るまで待てばよい。
• 自動ロールバック付きのリング展開。テストリング、アーリーアダプターリング、本番環境全体、ミッションクリティカル。順序は退屈だが、ほとんどのメンテナンスで機能する。変わったのは、一部のアップデートでは、月次メンテナンスを待つのではなく、悪用までの猶予に合わせて期間を短縮する必要があることだ。テストリングは自動化し、計測可能にしなければならない。人間によるチェックリストでは、これほど速く対応できない。
• クローズドループの検証。エンドポイントにインストールされたことを検証するまでパッチの展開を完了せず、再スキャンで確認するまでCVEをクローズしない。ほとんどのチームはこの手順を省くため、監査の1週間前になってコンプライアンスの証拠集めが突貫作業になる。だからこそ私たちは今週、プラットフォームに継続的なコンプライアンス機能を搭載した。パッチの展開に合わせてコンプライアンスの証拠を継続的かつ自動的に生成し、ほとんどのチームに対応する余力がない優先順位付けの判断を自動化するためだ。

MozillaによるFirefoxの脆弱性271件は、その予告編だ。Glasswing傘下の主要ソフトウェアベンダーはすべて、より多くの脆弱性を、これまでより速いペースで修正し始めようとしている。同じクラスの能力を持つ攻撃者は、同様のモデルにアクセスできるようになれば、まさにそうした隙を探すだろう。その結果生じるAI軍拡競争は、組織が修復しなければならないアップデートの件数と頻度に直接影響し、しかも対応ペースは加速する。プログラムを支えるのは自動化だ。月1回だけパッチを適用しているチームには、厳しい局面が待っている。

ITまたはセキュリティのプログラムを運用しているなら、今すぐ自己評価を行う価値がある。最後に適用した重大なパッチを取り上げてみよう。さらに言えば、金曜日にゼロデイが発生した場合、月曜日までに修復できるだろうか。CVEの公開から、最後のエンドポイントでインストールを検証するまでの時間を測ってみる。その数字が週単位で測られるなら、パッチ・アポカリプスはあなたのもとにもやって来る。

よくある質問