何が起きたか
Chromeセキュリティチームが木曜に公開したレポートによると、6月のメジャーバージョンリリース2本に含まれたセキュリティ修正は1,072件。これは直前の23回分のメジャーリリースを合計した数を上回ります。研究者からの報告も相当数を占めますが、量を押し上げた主因は、チーム内部で急速に進化しているAI活用のプロセス——脆弱性の発見、トリアージ、パッチ作成までをAIツールで回す体制だと説明されています。
Chromeはすでに「メジャーリリースは2週間ごと、加えて週次のセキュリティ更新」という新しい常態へ移行しつつありますが、発見量に追いつかず、現在は週2回のセキュリティ修正配信を試験しています。エンジニアリング担当ディレクターのDoug Turner氏は「これだけ修正が積み上がった結果、この期間は週2回出すのが最も理にかなっていた。それが永遠に続くかは、誰にも分からない」と述べています。
なぜ重要か
注目すべきは件数そのものより、リリース間隔が「開発都合」から「発見速度」に従属し始めたという点です。10年前、6週間ごとにパッチを配る（自動更新を最初に導入したブラウザである）Chromeのやり方は物議を醸しました。それが数週間おきの修正配信は当たり前になり、いま週2回が視野に入っている。ソフトウェアの更新頻度は、攻撃者と防御側の探索速度で決まる変数になったということです。
Chromeのバイスプレジデント兼ゼネラルマネージャーであるParisa Tabriz氏は、機械学習による脆弱性発見とファジング自動化は「AIと呼ばれる前から」遅くとも2012年には使ってきたとしたうえで、「今年は明らかに違う。攻撃側にとっても防御側にとっても変曲点だと感じる」と語っています。つまり、道具が新しいのではなく、効き方の次元が変わったという整理です。
なぜAIがこれほど見つけられるのか
鍵はモデルに与えている文脈の設計にあります。Turner氏によれば、Chromeは過去に観測したすべてのセキュリティ脆弱性とCVEをモデルに学習させ、さらにChromiumの歴史上のすべてのコード行について「その行がなぜ変更されたのか」という理由まで知っている状態にしています。
これは差分検索ではなく、過去の失敗のパターンを持って自コードを読み直す行為に近い。だからこそ、印刷機能のように積極的な開発が終わり、人間の目が届きにくくなった領域にまで探索が及びます。放置された成熟コードほど人的レビューの密度が下がる——AIはその空白を突く形で成果を出しています。
この急増は続くのか
チーム自身は続かない可能性を示唆しています。Turner氏は、Chromeのように成熟して安定した製品では、AIで見つけられるバグの大半を潰し終えた後、新規発見が落ち込む兆候があると述べています。Tabriz氏も「短期的なスパイクはあるが、新しい均衡点に落ち着くと思う」との見立てです。
そのうえでチームは、もぐら叩き的なパッチ適用の先として構造的な作り替えに軸足を置いています。C++で書かれた部分をメモリ安全なRustへ書き換え、バグの「カテゴリごと」消す方向です。AIで見つける速度を上げることと、そもそも見つかる余地を減らすことは、別々の投資として並走しています。
💼 事業会社視点：これは自社にどう効くか
経営層が読むべきは「Chromeが安全になった」ではなく、パッチ配信間隔が週2回まで縮む世界に自社の運用が耐えられるかです。
第一に、端末・ブラウザを固定バージョンで検証してから配布する日本企業の情シス運用は、この速度に構造的に合いません。金融・製造の情報システム部門は、バージョン固定と手動検証を前提にした社内標準を、自動更新前提へ書き換える時期に来ています。検証工数が更新頻度に比例して増える設計のままでは、遅延が脆弱性の露出時間に直結します。
第二に、SaaSや自社ECを運営する事業者は、Chrome側の挙動変更が週次で入る前提でE2Eテストと監視を組む必要があります。決済導線やファイルアップロードなど、ブラウザ実装に依存する箇所は自動テストの網を先に敷いてください。
第三に、受託開発企業には値付けの論点が生じます。Chromeが過去のCVEと全コード変更理由を学習させて脆弱性を掘っているのと同じ手法は、納品済みコードにも適用できます。「AIで探したら旧納品物から脆弱性が大量に出る」事態は現実的で、瑕疵担保の範囲と保守契約の設計を今のうちに見直す価値があります。逆に、AIによる脆弱性スキャンを保守メニューとして先に商品化できれば、値崩れしている運用保守の単価を引き上げる材料になります。
Tabriz氏は「業界全体として、ソフトウェアセキュリティに関わる人はAIを開発ワークフローに組み込むことが重要だ」「すべてがより安全になることを願うが、勝手に良くなるとは思わないし、タダで手に入るとも思わない」と述べています。投資判断としては、検出側への投資と、Rustへの書き換えのような構造的な作り替えを、別予算で並走させるのが妥当です。