事実：2バージョンで2年分を超えた
Googleが6月にリリースしたChrome 149と150で修正したセキュリティバグは合計1,072件。同社によれば、この2つの「マイルストーン」だけで、Chrome 126（2024年6月）以降の23バージョン2年分の1,036件を上回りました。発表と同時に公開されたホワイトペーパーには、リリースあたりの修正件数が指数関数的に伸びるグラフが添えられています。
Chromeのエンジニアリング担当ディレクターDoug Turner氏は、LLMが「サイバーセキュリティの経済構造を根本から変え、脆弱性発見を自動化された産業規模のオペレーションに変えた」と述べ、「Geminiのようなモデルを適用することで、我々は先回りして脆弱性を修正し、攻撃者を出し抜いている」と説明しています。
なぜ重要か：発見コストがゼロに近づいた
数字の本質は「Chromeが急に脆くなった」ことではありません。同じコードベースに元々あったバグを、見つけられる速度が一桁変わったということです。従来、脆弱性発見はセキュリティ研究者の時間という希少資源に律速されていました。その律速が外れると、防御側だけでなく攻撃側の発見コストも同時に下がります。
LLM登場以来、専門家が警告してきたのはまさにこの非対称性の消滅でした。AIで大量にバグを見つけられる時代には、防御側もAIを使わなければ「見つかっていないが存在するバグ」を攻撃者に先に拾われる。Googleの1,072件は、その予測が実データとして現れた最初の大きな事例です。
同じ現象がMicrosoftでも起きている
今月初め、MicrosoftはPatch Tuesdayで過去最多となる570件の脆弱性を修正し、その増加要因としてやはり自社のAI活用を挙げました。プラットフォーマー2社が同時期に同じ説明をしている点は重要です。これは一社の特殊事情ではなく、大規模コードベースを持つ企業に共通して起きる構造変化だと考えるのが自然です。
Appleは同じカーブに乗っていない
一方、Appleには同様の爆発的増加が見られません。独立した集計では2026年の修正件数は482件で、昨年並みかやや上回るペース。これは2015年の水準とほぼ同じです。TechCrunchはAppleにコメントを求めましたが、回答は得られていません。
この差をどう読むかは慎重であるべきです。AI活用が遅れている可能性もあれば、公表の粒度やカウント方法が異なる可能性もあります。ただ、利用者・企業の情シスから見れば「修正件数が公開情報として爆発的に増えているベンダー」と「そうでないベンダー」の間で、リスク評価の材料の量が明確に非対称になっているのは事実です。
💼 事業会社視点：これは自社にどう効くか
日本企業がまず直視すべきは、パッチ適用の運用サイクルが実態に追いついていない点です。Chromeが2バージョンで1,072件を潰す速度は、月次の検証・展開サイクルを前提とした社内標準と噛み合いません。基幹システムやEC管理画面をChromeの特定バージョンに固定している企業、キオスク端末やデジタルサイネージでブラウザ更新を止めている小売・サービス業は、放置しているバグの絶対数が従来の何倍かで積み上がる構図になります。自動更新の強制と、固定運用の棚卸しは今四半期の議題です。
SaaS事業者にとっては競争条件の変化です。Googleが「Geminiで先回りして直す」と言い切った以上、エンタープライズ商談のセキュリティチェックシートに「脆弱性発見にAIを使っているか」が入るのは時間の問題でしょう。自社プロダクトへのAIによる継続的なコード監査導入は、コスト項目ではなく受注要件として見積もるべきです。
受託開発・SIerはさらに直接的です。AIが産業規模でバグを掘り出す前提に立つと、納品後に発見される脆弱性の件数は構造的に増えます。保守契約の瑕疵責任の範囲、脆弱性対応の有償・無償の線引き、対応SLAを、旧来の「年に数件」を前提とした条項のまま更新しないのは経営リスクです。役員レベルで契約雛形の見直しに着手してください。
