ChromeのAIバグハンティングが本格化、2回のリリースで過去2年分を上回る1,072件の脆弱性を修正

GoogleのChromeセキュリティチームは、Geminiを活用したAIパイプラインにより、2026年6月にリリースされたChrome 149とChrome 150で、合計1,072件のセキュリティ脆弱性を修正したと明らかにした。これは、それ以前の23回の安定版リリースで修正された1,036件を上回る。約30億人のChromeユーザーにとっては、従来なら発見と修正に数週間から数カ月を要したバグが、単一の開発サイクル内で、しばしばブラウザの公開前に発見されるようになったことを意味する。

■過去2年分を上回る脆弱性を2回のリリースで修正

Googleのセキュリティブログによると、同社のChromeセキュリティチームは水曜日の2026年7月29日、Geminiを活用したAIパイプラインにより、Chrome 149とChrome 150の2回のリリースで1,072件のセキュリティ脆弱性を修正したと公表した。両バージョンはいずれも2026年6月にリリースされた。この件数は、それ以前の23回の安定版リリースを通じてパッチが適用された1,036件のバグを上回る。端的に言えば、2回のブラウザリリースで、それまでの約2年間を上回る数のセキュリティ修正が行われたことになる。

これは、本番環境規模でAIを利用した脆弱性発見がどのように機能するのかについて、これまでGoogleが公表した中で最も具体的な実績値である。この公表は、Googleがパイプラインの背後にあるアーキテクチャの詳細を公開した翌日に行われ、その内容はTechCrunchも独自に確認した。

ChromeのエンジニアリングディレクターであるDoug Turner氏はTechCrunchに対し、「大規模言語モデルはサイバーセキュリティの経済性を根本的に変え、脆弱性の発見を自動化された産業規模のオペレーションへと変貌させた」と語った。さらに、「Geminiのようなモデルを適用することで、われわれは脆弱性を先制的に修正し、攻撃者を上回るペースで対応し、アップデートのたびにChromeをより安全にしている」と述べた。

約30億人のChromeユーザーにとって、この数字には具体的な意味がある。かつては発見とパッチ適用に数週間から数カ月かかっていたバグが、今では単一の開発サイクル内で、しばしばブラウザのリリース版に到達する前に検出されている。

■ChromeのAIパイプライン：発見、トリアージ、修正、テストを24時間サイクルで実行

1,072件という数字は、Googleが2023年から構築してきた多段階のマルチエージェントシステムの成果である。同社は当時、不正な入力をコードに大量に与えてクラッシュを引き起こし、問題を見つける「ファジング」という確立されたセキュリティ手法を改善するため、初めて大規模言語モデルを導入した。現在のシステムは、アーキテクチャと対象範囲の両面で当時とは大きく異なる。

2026年初頭、GoogleはGeminiを基盤とするエージェントハーネスを導入した。これは、ファジングツールが通常到達できるコードパスだけでなく、Chromeのコードベース全体を走査して脆弱性を探す仕組みである。

このハーネスは、重みが公開されたオープンウェイトモデルとプロプライエタリモデルの相互運用をサポートする。また、モデルの出力が毎回同じになるとは限らない非決定性を考慮して複数回の処理を行い、Chromeの完全なGit履歴と、過去に特定されたすべてのCVEから構築されたナレッジベースを参照する。このナレッジベースにより、モデルは学習データの作成後に生じた脆弱性パターンについても推論できる。

別の「批評役（critic）」エージェントは、開発者が信頼境界や脅威モデルを記録するために管理しているSECURITY.mdファイルを読み取る。これによりAIは、何がクラッシュを引き起こすかだけでなく、特定のコンポーネントで何がセキュリティ上の問題に当たるのかを理解できる。

Googleの従来の2つのプロジェクトも、Chromeの継続的インテグレーションシステムに組み込まれている。Google DeepMindとProject Zeroの共同プロジェクトであるBigSleepと、CodeMenderは、世界中の開発者が提出したすべてのコード変更を対象に24時間ごとに実行される。2026年5月だけでも、この統合によって20件を超える脆弱性が本番環境に到達するのを防いだ。その中には、Severity 1のクリティカルと評価された脆弱性が1件含まれていた。

脆弱性が確認されると、修正段階では別のマルチエージェントワークフローが動作する。修正エージェントが複数のパッチ候補を生成し、批評役エージェントが選択肢を評価して、エンジニアがレビューするための成果物を作成する。さらに、テスト作成エージェントがクロスプラットフォームのテストを生成し、人間が修正内容をレビューする前に実行する。これにより、修正と検証の反復にかかる時間を数週間短縮できる可能性がある。

Googleの推計では、この統合パイプラインによって、トリアージ作業だけでも月に数百時間分の開発者の作業時間が削減されている。

■13年前のバグはなぜ今まで生き残っていたのか

2026年に導入されたエージェントハーネスによる発見の中でも特に注目されるのが、Chromeのコードベースに13年以上にわたって存在していたサンドボックスエスケープの脆弱性である。

この欠陥を悪用すると、侵害されたレンダラープロセスが、ユーザーのマシンにあるローカルファイルをブラウザに読み取らせることが可能だった。レンダラープロセスとは、Webコンテンツを処理するChrome内部のコンポーネントである。Web経由のエクスプロイトによってレンダラーが侵害されても、通常はGoogleが設けたサンドボックスから脱出できない。しかし、この脆弱性はその隔離を破る可能性があった。

この欠陥が長期間残っていたのは、極めて見つけにくかったからではない。従来のセキュリティレビューが、活発に変更されているコード、クラッシュを引き起こす入力、外部研究者から提出された報告などを起点としていたためである。これらの手法は、大規模かつ絶えず変化するコードベースの中で、13年前のコードまで網羅的に再評価するようには設計されていない。

これに対し、Geminiを活用したハーネスは、Chromeの完全なGit履歴を推論コンテキストの一部として利用する。特定のコード構造がいつ導入されたかを追跡し、導入当時の脅威モデルが現在のアーキテクチャでも成立するかどうかを評価できる。

Chromeセキュリティチームは、「われわれの多くにとって、この瞬間はAIを活用した脆弱性検出の可能性を確信させるものだった」と記している。

■動的パッチ適用：修正からアップデートまでのギャップを埋める

脆弱性を発見して修正しても、リスクの一部が解消されるにすぎない。パッチがChromeの公開オープンソースリポジトリにコミットされると、修正内容も外部から確認できるようになる。大多数のユーザーがアップデートを受け取る前に、攻撃者が修正内容をリバースエンジニアリングし、エクスプロイトを作成できる可能性が生じる。

修正がメインのコードベースに反映されてから、大多数のユーザーが利用するChromeのStableチャネルに届くまでの期間は「パッチギャップ」と呼ばれる。従来、この期間は数週間に及ぶことがあった。

Googleは、このギャップを2つの方向から縮めようとしている。1つ目はリリース頻度である。同社はChromeの主要バージョンのリリースサイクルを2週間間隔へ移行しつつあり、週次のセキュリティアップデートに加えて、週2回のセキュリティリリースも試験運用している。

2つ目はアーキテクチャである。同社は「動的パッチ適用（dynamic patching）」と呼ぶ仕組みを開発している。Chromeのマルチプロセスアーキテクチャを利用し、ブラウザを動作させたまま、レンダラーやGPUプロセスなど個別のバックグラウンド子プロセスを更新済みのバイナリに置き換える。これにより、ほとんどの場合でブラウザ全体を再起動する必要がなくなることを目指す。

Chrome 150には、macOS向けに、この考え方を応用した初期の仕組みがすでに導入されている。すべてのウィンドウを閉じた後もアプリケーションが動作を続ける、macOSで一般的なウィンドウのないバックグラウンド状態で、Chromeが保留中のアップデートを検出すると、ユーザーの作業を中断せずに自動再起動してアップデートを適用する。

これは、動作中の子プロセスを個別に置き換える完全な動的パッチ適用そのものではなく、その目標に向けた初期の適用例である。Googleが掲げる長期的な目標は、「常に最新の状態にあり、継続的かつ動的にパッチが適用され、影響を最小限に抑えられる適切な時点で自動的に再起動される」ブラウザである。

■AI支援によるバグハンティングがChromeの報奨金プログラムを変えた理由

Chromeの内部パイプラインを改善したAI能力の急速な向上は、外部向けの脆弱性報告プログラムも変化させた。ただし、その変化が単純に良い結果だけをもたらしたわけではない。

2026年3月までに、GoogleがChrome Vulnerability Reward Program（VRP）を通じて1カ月間に受け取る脆弱性報告の数は、2025年の1年間に受け取った総数を上回っていた。

急増の一因は、外部研究者によるAIツールの利用である。こうしたツールの多くは、対象となる脆弱性が実在するか、既知の問題ではなく新規のものかを独自に検証しないまま、構造的にはもっともらしく見える報告を生成する。この大量の報告により、従来の人手によるレビュープロセスでは、それまでと同じペースで処理できないトリアージの滞留が発生した。

Googleは、内部AIシステムがすでに検出している問題に対して真に新たな価値を加えるバグや、新しい自動処理パイプラインに円滑に取り込める形式の報告に、外部研究者の作業を集中させるようVRPを再編した。

この再編には、当面の運用改善を超えた構造的な意味がある。Chromeにおける日常的な脆弱性発見では、Googleの内部AIパイプラインが、外部の研究者を集めるクラウドソーシング型モデルを機能面で置き換えたことになる。

プログラムにおける人間の研究者の価値は、AIが見つけられないバグを発見できるかどうかに、ますます左右される。具体的には、複数のコンポーネントをまたぐ複雑な相互作用、新しい攻撃チェーン、大規模コードベースのパターン認識だけでは発見できず、人間の創造性や文脈理解を必要とする最も深刻な脆弱性などである。

これは、報奨金プログラムの単なる管理上の変更ではなく、セキュリティ研究の労働市場における構造的変化である。TechTimesが報じたように、GitHubも4日前、同じ根本的な理由から公開バグ報奨金の支払額を少なくとも50％削減し、より高額な報酬を招待制の区分へ移すという、同様の対応を取った。

■バグだけでなくバグの種類そのものを排除する：Chromium規模でのメモリ安全性

1,072件という数字は、Chromeの既存のC++コードベースに対して、AIを利用した脆弱性発見が何を実現できるかを示している。一方、Googleは並行して、特定の種類のバグを最初から混入できないようにすることも目指している。

短期的な戦略の対象は、Use-After-Free（UAF）脆弱性である。これは、メモリが解放された後もコードがそのメモリ領域を参照し続けることで発生するメモリバグで、従来、ブラウザに対するエクスプロイトの大きな割合を占めてきた。

GoogleのMiraclePtrは、UAFバグを無効化することを目的に開発された技術であり、この種類の脆弱性をすでに大幅に減少させている。同社は現在、MiraclePtrの適用範囲をSkia、ANGLE、Dawnなどの追加ライブラリのほか、C++のイテレータや標準コンテナにも拡大している。

MiracleObjectと呼ばれる新しいツールは、GPUのメインスレッド上にあるUAF脆弱性の最大90％を対象とする。局所的な実行時性能を意図的に一部犠牲にする代わりに、時間的メモリ安全性を確保する仕組みである。

並行して進められている「spanification」と呼ばれる取り組みでは、従来のC++におけるポインタとサイズの組み合わせを、コンパイラによって制約を適用できる型へ置き換えている。これにより、境界外メモリアクセスを実行時の障害ではなく、コンパイル時に検出されるエラーにする。7月30日の公表時点で、Chromeが直接管理するコードの97％は、厳格なunsafe-buffer警告を有効にしても問題なくコンパイルできる状態になっている。

メモリ安全性に対する長期的な解決策は、プログラミング言語のレベルでの移行である。Googleは、新しいChromeコンポーネントでRustへの移行を加速させている。中核となるChromium APIをRustコードから直接利用できる一元的なRust SDKを構築し、Rustを「新しいコンポーネントにおける日常的で、導入時の障壁がないエンジニアリング上の選択肢」にすることを目指す。

移行では、過去にバグが集中してきたコード領域を優先する。複雑なデータパーサー、画像コーデック、フォントスタックなど、レビューされたコード行数に対するメモリ安全性脆弱性の比率が歴史的に高かった分野が対象である。

■Chromeを超えて：オープンソースの依存関係と共有されるセキュリティ問題

Chrome自体のセキュリティは、Googleが管理する対象の一部にすぎない。Chromiumプロジェクトは、V8 JavaScriptエンジン、BoringSSL暗号ライブラリ、グラフィックス関連コンポーネントのSkia、ANGLE、Dawnなどの周辺プロジェクトを通じて、2,300を超えるサードパーティー依存関係を抱えている。そのうち約1,700は、何らかの形でユーザー向け製品に組み込まれて提供されている。

こうした依存関係のいずれかに脆弱性があれば、Chrome、Edge、Brave、Operaのほか、Chromiumを基盤とする多くの企業向けブラウジングソフトウェアにも影響が広がる可能性がある。

Googleは、これらすべての依存関係を自動更新パイプラインへ移行し、アップストリームの最新バージョンへ先回りして更新する取り組みを進めている。パイプラインは、単に無条件で更新するのではなく、GOSSIP（Google's Open Source Security Intelligence Platform）が提供する安全性シグナルを利用し、サードパーティーによる変更で新たなリスクが持ち込まれるのを防ぐ。

Googleは最近、Alpha-Omegaプロジェクトに1,250万ドル（約19億8,750万円、1ドル＝159円換算）を拠出する連合にも参加した。このプロジェクトは、オープンソースのメンテナーにAIを活用したセキュリティツールへのアクセスを提供し、脆弱性報告への対応を迅速化できるよう支援する。

同社はAkritesプロジェクトの創設メンバーでもある。Akritesは脆弱性報告を一元的に受け付ける仕組みで、大量の報告を独力でトリアージする人員を持たないアップストリームのオープンソースメンテナーの負担軽減を目的としている。

■Chromeのパイプラインがソフトウェアセキュリティ業界に意味するもの

Googleの公表は、孤立した事例ではない。7月15日にリリースされたMicrosoftの2026年7月のPatch Tuesdayでは、過去最多となる570件のセキュリティ脆弱性が修正された。これは2025年7月の約3倍であり、Microsoftは、この増加の要因としてAIを利用した脆弱性発見を明示している。

MicrosoftのエグゼクティブバイスプレジデントであるPavan Davuluri氏は、パッチ件数の増加が今後は通常になると事前に警告していた。同氏は、「AIの進歩により、より広範なコードから、より多くの問題を、より速く見つけられるようになり、脆弱性発見のペースが変化している」と記している。

一方、Appleでは同様の加速は確認されていない。Apple製品で修正されたバグについての独立集計では、2026年のパッチ数は482件で、過去数年と同程度のペースであり、Appleが2015年に修正した件数とほぼ同じである。TechCrunchはAppleにコメントを求めたが、回答は得られなかったとしている。

この違いは重要である。発見、修正されるバグの急増が、ソフトウェア自体の安全性低下によるものではなく、企業がセキュリティパイプラインへAIを大規模に導入することを選択した結果である可能性を示しているからだ。

Chromeチームも、この状況が持つ二面性を認めている。同チームは、「AI時代によってソフトウェアセキュリティを巡る脅威が激化したことは否定できない。しかし、迅速な配信メカニズムと根本的な防御策を組み合わせることで、優位性を防御側に確実にとどめようとしている」と記した。

この評価が正しいかどうかは、動的パッチ適用システムが全面的に展開されるかどうかにかかっている。また、AIを活用した攻撃側の能力が、防御側に一層の対応を要求するペースで加速し続けるかどうかにも左右される。

現在Chromeを利用している約30億人にとって、最も直接的な意味は単純である。これまでブラウザが発見できていなかったバグが、以前より多く見つかるようになっている。これは明らかに良い知らせだ。

残された問題は、バグを発見してから、その修正をすべてのデバイスへ確実に届けるまでの時間を、このパイプラインがどれほど短縮できるかである。

■注目ポイントQ&A

●GoogleのAIはどのようにしてChromeのセキュリティバグを見つけるのですか？

GoogleのGeminiを基盤とするエージェントハーネスは、Chromeのコードベース全体を走査します。Chromeの完全なGit履歴と、過去に特定されたすべてのCVEから構築したナレッジベースを利用し、モデルの学習データ作成後に生じた攻撃パターンについても推論します。

別の批評役エージェントは、開発者が管理する信頼境界や脅威モデルの文書を読み取ります。Google DeepMindとProject Zeroが共同開発したBigSleepと、CodeMenderは、Chromeの継続的インテグレーションシステム内で、開発者が提出したすべてのコード変更を対象に24時間ごとに実行されます。

脆弱性が確認されると、修正エージェントが複数のパッチ候補を生成し、別の批評役エージェントが評価します。その後、テスト作成エージェントがクロスプラットフォームのテストを作成し、人間が修正をレビューする前に実行します。

●Chromeのパッチギャップとは何ですか？また、Googleはそれにどう対処していますか？

パッチギャップとは、セキュリティ修正がChromeの公開オープンソースリポジトリにコミットされてから、実際にStableチャネルのユーザーへ届くまでの期間です。従来は数週間に及ぶことがあり、その間に攻撃者が修正内容をリバースエンジニアリングして、エクスプロイトを作成する可能性があります。

Googleは、週2回のセキュリティリリースを試験運用するとともに、ブラウザを動作させたままバックグラウンドの子プロセスを更新済みバージョンへ置き換える「動的パッチ適用」の開発を進めています。

Chrome 150のmacOS版には、関連する初期の仕組みとして、すべてのウィンドウが閉じられた状態で保留中のアップデートを検出すると、自動再起動して更新を適用する機能が導入されています。ただし、これは動作中の子プロセスを個別に置き換える完全な動的パッチ適用そのものではありません。

●Use-After-Free（UAF）脆弱性とは何ですか？なぜChromeはそれを修正し続けているのですか？

Use-After-Freeバグは、メモリが解放された後もコードがそのメモリ領域を参照し続けることで発生します。その結果、不正な参照を行うダングリングポインタが生じ、攻撃者による任意コードの実行、権限昇格、機密データへのアクセスなどに悪用される可能性があります。

Chromeの中核部分は、開発者によるメモリ管理を必要とするC++で書かれているため、UAFバグは従来、Chromeのセキュリティ脆弱性の大きな割合を占めてきました。

MiraclePtrとMiracleObjectは、既存のC++コードベースにあるUAFバグを無効化するための実行時緩和策です。長期的には、組み込みの所有権規則によってUAFバグをコンパイル時に防ぐRustへ新しいChromeコンポーネントを移行し、この種類のエラーを構造的に混入できないようにすることが解決策となります。

●GoogleのAIセキュリティパイプラインは、Chromeのバグ報奨金プログラムにどのような影響を与えましたか？

Googleは2026年初頭、社内システムやAIツールを使う外部研究者からの報告が、既存のトリアージ能力を超えるほど急増したため、Chrome Vulnerability Reward Program（VRP）を再編しました。2026年3月までに、1カ月間に受け取る報告数が、2025年の年間総数を上回っていました。

再編後のVRPでは、内部AIシステムがすでに発見している問題に対して真に新しい価値を加える報告に重点が置かれます。具体的には、複雑で新規性の高いバグ、創造的な攻撃チェーン、パターン認識だけでは見つけられず、人間の専門知識を必要とする問題です。

これは、Chromeの外部報奨金プログラムへ有意義に参加しようとする人間の研究者が、AIではまだ到達できない水準の問題を発見する必要があることを意味します。Googleだけでなく、業界全体で進みつつあるセキュリティ研究の経済性の構造的変化でもあります。

元記事: Chrome AI Fixed More Security Bugs in Two Releases Than in Prior Two Years