Webブラウザのセキュリティ維持は、新たな局面を迎えている。GoogleのChromeセキュリティチームは、2026年6月から7月にかけて公開されたChrome 149および150において、合計1,072件のセキュリティバグを修正した。これは、過去23回のメジャーリリースで修正された脆弱性の総数を上回る規模だ。
劇的な修正数の増加は、セキュリティ研究者からの報告増だけが理由ではない。最大の要因は、Google内部におけるAIを活用した脆弱性発見ツールの進化だ。Googleは大規模言語モデルに対して、過去のすべての脆弱性（CVE）やChromiumの膨大なソースコードの変更履歴を学習させている。従来のファジング（ランダムなデータを大量に入力してクラッシュを引き起こすテスト手法）では、構文のバグやメモリ破壊は発見できた。しかし、開発者の思い込みに起因する論理的な欠陥までは見抜けない。
AIはこの壁を越えた。コードの抽象構文木（AST）やバグトラッカーの議論履歴を言語モデルが読み込み、人間のプログラマが陥りやすい思考の死角を突く。たとえば、文法的には正しいが特定の状態下でのみ意味論的に破綻する境界条件チェックなど、ファジングが見逃す経路を特定できる。長年放置されていたような古いコードの脆弱性までもが、光速で洗い出されるようになったのだ。実際、Chromeのコードベースに13年間潜み続けていた深刻なバグも発見されている。AIは防御側の切り札となる。
AIによるバグ発見の自動化は、防御側であるGoogleにとって強力な武器となる。だが、これだけでは終わらない。悪意ある攻撃者も同様のAIモデルを利用して未知の脆弱性を探し出し、悪用する能力を高めている。攻防のスピードが上がる中、Googleはセキュリティパッチの提供ペースをかつてない水準に引き上げざるを得なくなっている。
パッチギャップという魔の時間帯
脆弱性を見つけて修正プログラムを開発する速度が上がっても、それだけではユーザーを守り切れない。Googleがコードベースに修正をコミットしてから、大半のユーザーが利用するStable（安定版）チャンネルに行き渡るまでの間にはタイムラグが生じる。この空白期間を「パッチギャップ」と呼ぶ。
Chromiumはオープンソースプロジェクトだ。Googleが修正プログラムをリポジトリに公開した時点で、変更されたソースコードは全世界に公開される。攻撃者はその差分（コミット）をAIに読み込ませ、リバースエンジニアリングを行う。修正内容から逆算すれば、どのような脆弱性が存在し、どうすれば悪用できるかを数時間で特定できる。まだパッチを適用していないユーザーを狙う「Nデイ攻撃」を仕掛ける危険がある。パッチ開発の迅速化は、皮肉にも攻撃者にヒントを与える速度をも上げてしまった。
パッチギャップを埋めるため、GoogleはChromeのリリースサイクルを極限まで加速させている。2026年9月に公開予定のChrome 153からは、これまでの4週間隔から2週間隔でのメジャーリリースへと移行する。さらに、これまではメジャーリリースの合間に週1回提供していたセキュリティアップデートを、週2回に増やすパイロットテストも実施している。
しかし、アップデートの頻度を上げることは、ユーザーに別の負担を強いる。現在の仕組みでは、新しいアップデートをダウンロードしても、ユーザーが手動でブラウザを再起動しなければインストールは完了しない。作業の途中でブラウザを再起動することは多くのユーザーにとって煩わしく、後回しにされがちだ。結果として、パッチは手元にあるのに適用されていないという危険な状態が続くことになる。
競合ブラウザもこのジレンマに直面している。MicrosoftのEdgeは、Windowsのバックグラウンド更新機構やグループポリシーと密接に連携することで、特に企業環境におけるパッチ適用の確実性を高めている。しかし、OSの再起動や強制終了が伴うことへのユーザーの不満は根強い。一方、AppleのSafariはmacOSやiOSのアップデートサイクルに依存する部分が大きい。コアとなるWebKitエンジンの更新はOSレベルの変更を伴うことが多く、緊急時には「緊急セキュリティ対応（Rapid Security Response）」を利用して、マイナーアップデートによる再起動を最小限に抑えようと試みている。だが、ブラウザ単体で完結し、かつユーザーの作業を一切妨げない理想的な更新体験は、どのプラットフォームでもまだ実現していない。
ブラウザ再起動を過去のものにする動的パッチ技術
矛盾を解消すべく、Googleはユーザーに負担をかけずに最新のセキュリティ状態を維持するための技術開発に投資している。Windows、macOS、Linux、Androidと多岐にわたる環境をサポートするChromeにとって、OSの機能に頼らない独自のシームレスな更新機構が急務となっていた。
第一歩として、Chrome 150ではmacOS向けに「ゼロウィンドウリスタート（Zero window restart）」という機能が導入された。macOSでは、すべてのウィンドウを閉じてもアプリケーション本体はバックグラウンドで動作し続けるという特性がある。この仕組みを利用し、ウィンドウがすべて閉じられた状態でアップデートが待機していることを検知すると、Chromeはバックグラウンドで自動的に再起動を行う。次回の起動時にはアップデートが完了した状態になる。
さらにGoogleは、OSを問わず抜本的な解決を図る「動的パッチ（Dynamic patching）」の開発を進めている。Chromeは、レンダリングやGPU処理などを複数の独立したバックグラウンドプロセスに分割するマルチプロセスアーキテクチャを採用している。動的パッチは、この構造を利用し、ブラウザ全体を再起動することなく、動作中のバックグラウンドプロセスをアップデート済みのバイナリに順次置き換えていく技術だ。
しかし、実行中のプロセスを熱交換のようにすり替えるのは容易ではない。動画を再生中のタブや、テキストを入力中のフォームがある場合、GPUプロセスやレンダラープロセスを入れ替える際における画面のちらつきやクラッシュを防ぐ必要がある。これを実現するためには、描画中のフレーム状態やメモリ内のDOM（Document Object Model）状態、JavaScriptのヒープなどを極めて短時間でシリアライズ（直列化）し、新しいプロセスへプロセス間通信（IPC）経由で正確に引き継がなければならない。
Googleは現在、新旧のプロセスをミリ秒単位で並行稼働させるアプローチをテストしている。新しいバイナリが安定して動作することを確認してから、ユーザーに気づかれることなく通信の経路を切り替える。わずかでも失敗すれば「エラーが発生しました（Aw, Snap!）」画面が表示されてしまうため、極めて難易度の高いエンジニアリングだ。
動的パッチの一般提供時期は未定だが、Googleの最終的なビジョンは、ユーザーが意識することなく常に最新かつ安全な状態が保たれるブラウザだ。AIがもたらした脆弱性発見のインフレーションは、皮肉にもウェブブラウザのアーキテクチャそのものを、より洗練された自己更新システムへと進化させようとしている。Googleが再起動という「摩擦」をどこまでゼロに近づけられるか。今後の開発動向が注目される。
