見つける速度が、直す速度を追い越した——AIが起こしたパッチの渋滞

ソフトウェアの欠陥探しは、長いこと人手のかかる地味な作業でした。詳しい人が時間をかけてコードを読み、あやしい場所に見当をつけ、本当に危ないかどうかを確かめる。ひとつ見つけるのに何日もかかることは珍しくありませんでした。

そこにAIが入ってきた結果、2026年の夏に起きているのは、こういう事態です。見つかる欠陥の量が、直す側の処理能力を超えはじめた。

7月のひと月だけで、オラクルは334製品・1,434件の脆弱性に対して1,449件の修正を出しました。マイクロソフトの月例更新は570件。Linuxカーネルは30時間ほどで432件のCVE（脆弱性に振られる識別番号）を公表しています。そしてマイクロソフトは「更新は3日以内に当ててほしい」と言い、シスコは「もう一件ずつCVEを振るのはやめる」と宣言しました。

発見のペースを変えたもの

まず、なぜ急に増えたのか。答えははっきりしていて、各社が自社のコードにAIをけしかけているからです。

マイクロソフトは2026年5月、社内で使っている脆弱性探索システムを公開しました。開発コード名は「MDASH」。ひとつの賢いAIに全部を任せるのではなく、100体を超える役割別のAIエージェントを組み合わせて動かす仕組みです。

流れはこうです。まずコードを読み込んで、どこが攻撃の入り口になりうるかの地図を作る。次に「監査役」のエージェントたちがあやしい箇所を洗い出す。そこで出てきた候補を、今度は「討論役」のエージェントが受け取り、本当に到達可能で悪用できるのかを賛成・反対の両側から議論します。生き残った候補は重複を整理したうえで、最後に「証明役」が実際にその不具合を引き起こす入力を組み立てて、机上の空論でないことを確かめる。

効き目は数字に出ています。あらかじめ21個の欠陥を仕込んだ非公開のテスト用ドライバーに対して、21個すべてを検出し、誤検知はゼロ。過去5年ぶんの実際の脆弱性報告を対象にした再現テストでは、あるカーネル部品で96％、別の部品で100％を掘り当てました。公開ベンチマークでも当時の首位です。

そのMDASHが実際の製品で見つけたものが、5月の月例更新に16件のCVEとして載りました。うち4件は最上位の「緊急」で、認証なしにネットワーク越しから任意のコードを実行できてしまう類のものです。

同じことをシスコもやっています。同社は静的なコード解析、実機での動作テスト、設定の点検、悪用の模擬といった役割に分かれたエージェント群を、製品ラインナップ全体に対して走らせていると説明しています。オラクルも7月の大型更新について、AIによる指摘事項の抽出が規模拡大の要因のひとつだと公式に述べました。

つまり、いま各社の製品から大量に出てくる欠陥は、攻撃者に見つけられたものではなく、自社でAIに探させて先回りして掘り出したものが相当な割合を占めています。

数字で見る7月

マイクロソフトの月例更新の推移が、変化の速さをいちばん素直に映しています。

月	2025年	2026年
4月	134件	167件
5月	72件	120件
6月	66件	200件
7月	137件	570件

7月だけを見ると前年同月の4倍以上、1〜7月の累計では前年の約2倍です。修正の対象はカーネル、ファイルシステム、リモートデスクトップ、Hyper-V、セキュアブート、BitLocker、印刷、USBドライバーと、Windowsの中核部品がほぼ総なめになりました。

オラクルの7月更新は同社史上最大規模で、対象製品は334にのぼります。データベースからJava、業務システム、通信機器向けソフトまで、名前の並びを眺めるだけでも骨が折れる量です。

Linuxカーネルについては、7月19日の午前から20日の夕方までのおよそ30時間で432件のCVEが公表されました。管理者向けメーリングリストにこれを報告したシステム管理者のJan Schaumann氏は、「個々の変更に優先順位をつけるやり方は、もう成り立たないことがはっきりした」「これからどうすればいいのか分からない」と率直に書いています。Hackadayの週次まとめによれば、その後の数日でさらに323件が追加されました。

直す側に生じた詰まり

問題は、これを受け取る側です。

マイクロソフトが示した新しい推奨は、かなり踏み込んだ内容でした。品質更新プログラムの延期期間は3日未満、適用期限は0〜1日、猶予期間は最長2日。ひらたく言えば「出たらすぐ当てろ」です。同社は、AIによって脆弱性の発見から悪用までの時間が「数週間から数時間へ」縮んでいると説明しています。

企業のIT部門にとって、これは相当に厳しい注文です。多くの組織は、更新が出てから自社の環境で試験し、業務が止まらないことを確かめてから展開します。その工程を3日に押し込めというのは、実質的に試験をやめろと言うに等しい。実際、複数のセキュリティ専門家が「すべての脆弱性に一律3日を求めるのは、大きな組織にとって現実的でも安全でもない」と反応しています。

シスコが選んだのは別の道でした。同社は2026年6月、7月からセキュリティ更新を毎月第1・第3水曜日の2回にまとめ、7日前に対象製品を予告する方式へ移行すると発表しています。同時に、束ねた更新に含まれる個々の不具合へ一件ずつCVEを振るのをやめました。代わりに「入力値の検証に関する複数の修正」「アクセス制御に関する複数の修正」といった弱点の種類ごとに、まとめてひとつのCVEを割り当てます。

理由として同社が挙げたのは、CVEを一件ずつ評価して個別に回避策を当てていく方法は、もはや目的に合わなくなった、というものです。ひとつずつ潰すより、修正が入った新しい版へ丸ごと上げるほうが確実に安全になる、という考え方への転換でもあります。ただし、回避策の適用が必要なものや、実際に悪用が確認されているものについては、これまでどおり個別のCVEを振って詳細を公開するとしています。

オラクルはさらに直球で、四半期ごとだった更新を毎月へ移すよう顧客に強く促しました。そして「運用手順の見直しが必要になるかもしれない」と断ったうえで、その移行を手伝う自社のコンサルティングサービスを案内しています。

急いだ更新が壊すもの

ここで、もうひとつの力が逆向きに働きます。急いで出した更新ほど検証が薄くなり、壊れやすくなる、という当たり前の事実です。

7月14日に配信されたWindows 11の更新プログラム（KB5101650）が、まさにその例でした。570件の修正を含む必須の更新でしたが、一部のDell製PCで予期しないシャットダウン、動作の低下、発熱、バッテリーの急速な消耗が起きたのです。

原因は脆弱性の修正そのものではなく、6月のプレビュー更新で追加されたUSB Type-C関連の新しい仕組みと、インテル製の電力・温度管理ドライバーとの相性でした。マイクロソフトは該当する機種への配信を止め、7月18日に別途修正版を出しています。

この件自体は、配信前に不具合をつかんで該当機だけ止めた、という意味では仕組みが働いた例です。それでも構図ははっきりしています。「早く当てないと危ない」と「当てると壊れることがある」が同時に押し寄せていて、しかも前者の圧力だけが強まっている。更新をためらう理由と、ためらってはいけない理由が、同じ月に両方とも増えた——それが2026年夏の実情です。

手元の端末でできること

ここまでは大企業のIT部門の話に見えますが、個人のPCやスマートフォンにもそのまま降りてきます。

いちばん大事な点から書きます。今回の話は「更新を止めたほうがいい」という結論にはなりません。むしろ逆です。攻撃者側も同じようにAIを使っていて、公開された修正の中身から悪用方法を組み立てるまでの時間が、以前とは比べものにならないほど短くなっています。更新を当てずに放置した端末は、その間ずっと無防備なままです。

個人利用なら、自動更新を有効にしたまま、出たものを素直に当てるのが結局いちばん安全です。更新の一時停止機能は、業務でどうしても止められない事情があるときのための逃げ道であって、常用するものではありません。

気にかけたいのは、むしろ更新が届かない機器のほうです。家庭用のルーター、ネットワークカメラ、各種のIoT機器には、メーカーが更新を出さなくなったまま動き続けているものが少なくありません。今回Hackadayが取り上げたルーター用ソフトウェアOpenWRTの重大な欠陥も、修正版は出たものの、更新を受け取れないまま残る機器が数万台規模で存在すると見られています。

もしパソコンに不具合が出て更新が原因ではないかと疑ったときは、自力でドライバーを古い版に戻すような操作に走る前に、メーカーの案内を確認するほうが安全です。先ほどのDell機の件でも、ドライバーを手動で戻す方法が掲示板で出回りましたが、それは温度管理に必要な部品を外すことになり、正規の修正版を待つより不利になります。

解釈上の留意点

数字の受け取り方に、いくつか注意が要ります。

まず、CVEの件数は「新たに開いた穴の数」ではありません。とくにLinuxカーネルの場合、修正が安定版に取り込まれたあとで番号を振る運用になっているため、公表された時点ですでに直っているのが普通です。件数が多い週は、危険な週というより、記録が追いついた週と読むほうが実態に近い。

そして7月19〜20日の432件についても、当事者の説明があります。カーネルのCVE運用を統括するGreg Kroah-Hartman氏は、あれは数週間ぶん滞っていた査読待ちの案件を週末にまとめて処理した結果であり、6週連続で学会と休暇が重なって遅れていたものだ、と書いています。「AIが3日で432件を掘り当てた」という話ではありません。

ただし同じ投稿で氏は、AIが見つけてくる問題は現に増えていて、この状況から抜け出すには少なくとも18か月はかかるだろうとも述べています。そのうえで、その間ずっと更新を当て続けていなければ安全は保てない、と釘を刺しました。氏はセキュリティ研究者ハルバー・フレイク氏の言葉を引いて、ソフトウェアはもともと完璧な安全性のために設計されてはおらず、その選択のツケが今になって回ってきているのだ、とまとめています。

もうひとつ。公表された件数のうち、どれだけがAI由来なのかを示す全体の内訳は、どのベンダーも出していません。マイクロソフトの5月の16件のように、個別に「これはAIが見つけた」と明示された例はありますが、7月の570件やオラクルの1,449件の何割がAIによるものかは公表されていない。各社が「AIによる発見の加速」を理由に挙げているのは事実ですが、全件がAI由来であるかのように読むのは行きすぎです。

最後に、件数と危険度は別物だという点も押さえておきたいところです。数百件のうち大半は、特定のドライバーや限られた設定でしか成立しない、悪用の難しいものです。Kroah-Hartman氏も、自分が実際にビルドして使っているファイルとCVEの対象ファイルを突き合わせれば、注意すべき件数は全体の1割ほどまで絞れると助言しています。