Googleは、自社の内部AIツールが6月に行われた2回のブラウザリリースで、Chromeの1,072件のセキュリティバグ修正を支援したと述べている。これは、約2年間にわたる直近23回のリリースで記録された1,036件の修正を上回る。

これらの数値は、AI支援による脆弱性発見とパッチ適用に関するGoogleのホワイトペーパーとあわせて公表されたもので、大規模言語モデルがソフトウェアセキュリティの経済性をどう変えているかを示す具体例となっている。ブラウザベンダーや企業のITチームにとって、この動きは、攻撃者が悪用する前により多くの欠陥が見つかることを意味する一方で、修正の検証、優先順位付け、展開に関する運用負荷がはるかに重くなることも意味する。

Googleによると、この比較は6月に公開された2つの「マイルストーン」であるChrome 149とChrome 150を対象としている。以前の期間は2024年6月のChrome 126から始まった。Googleは、数値の独立検証や、どれだけの修正がAIによって直接生成、発見、あるいは加速されたのかを示す詳細な内訳は示していない。

GoogleがChromeのセキュリティで変わったと述べる点

Chromeのエンジニアリング担当ディレクターであるDoug Turner氏はTechCrunchに対し、大規模言語モデルによって脆弱性発見は、主に手作業の活動から、産業規模で動く自動化プロセスへと変わったと語った。同氏は、GoogleがGeminiのようなモデルを適用し、攻撃者が利用する前に欠陥を特定・対処していると述べた。

この違いは重要だ。Googleの見出しとなる数値は、公開されたChromeのバージョンで修正されたバグを示しており、必ずしもAIシステムだけで発見された脆弱性を意味するわけではない。同社の公開説明によれば、AIツールはより広いワークフローを支援しており、コード分析、不審なパターンの特定、修正案の提示、テストやリリース工程を通じてエンジニアを支援することなどが含まれる。

6月の2回のリリースでは合計1,072件のセキュリティ修正が行われ、前の23回のリリースでは1,036件だった。単純平均で見ると、1リリースあたりの修正数は大きく増えている。しかし、この比較だけでは、追加された修正すべてがAIによってもたらされたことは示せない。リリース規模、報告慣行の変更、セキュリティ研究活動、そしてGoogleの「セキュリティバグ」の定義も総数に影響しうる。

したがって、Googleのグラフとホワイトペーパーは、管理された性能ベンチマークというより、変化するセキュリティ運用の証拠として読むのが適切だ。結果は同社自身が報告しており、提供された証拠には手法に対する第三者監査は含まれていない。

より広いAI支援の脆弱性競争

Googleの発表は、Microsoftの同様の主張に続くものだ。7月初旬、Microsoftは月例のPatch Tuesdayで製品群全体にわたる570件のセキュリティ欠陥を修正し、その増加の一部はAIの利用によるものだと述べた。

これらの発表は、長年のサイバーセキュリティ上の懸念を裏付けている。AIシステムが欠陥を見つけるのが上手くなるにつれ、防御側はより多くの脆弱性をより速く見つけるようになる。組織が迅速にパッチを適用すればセキュリティは向上するが、これまで見落とされていた製品の弱点が露呈し、セキュリティチームに求められる作業量が増える可能性もある。

この傾向は大手テック企業で一様ではない。TechCrunchが引用した独自集計では、Appleは2026年に482件のバグを修正しており、前年の総数に並ぶか上回るペースにあるという。Appleは同誌のコメント要請に応じておらず、公開されている証拠では、同社の内部AI利用がGoogleやMicrosoftと異なるかは示されていない。

現時点で最も妥当な結論は、一部の大手ソフトウェアベンダーが、AIツールの広範な導入とともにセキュリティ修正の大幅な増加を報告しているということだ。その増加のどれだけが真に新しい発見能力を反映しているのか、それともエンジニアリングプロセスや開示慣行の変更なのかは、なお不明である。

ブラウザおよび企業チームにとって数字が重要な理由

ブラウザは、広い攻撃対象領域と頻繁なリリースを併せ持つため、この変化の影響を特に受けやすい。Chromeには、Webページのレンダリング、コード実行、メディア処理、認証情報の管理、OSサービスとの接続のための複雑なコンポーネントが含まれている。そうした領域の微妙な欠陥を見つけるツールは、Googleが発見から修正までの時間を短縮するのに役立つ。

Google Chromeの上に製品やセキュリティ体制を構築しているチームにとって、直近の影響は理論的というより運用上のものだ。修正頻度が増えれば、ブラウザの検証をより迅速に行う必要があり、パッチ管理のプロセスを厳格化し、従業員端末への更新配布方針をより明確にする必要がある。ブラウザ更新を遅らせる企業は、脆弱性の発見から現場への展開までのギャップが広がる可能性がある。

AI支援の脆弱性発見は、検証上の問題も生む。自動生成された発見には、誤検知、重複報告、再現が難しい欠陥が含まれることがある。提案されたコード変更はレビューとテストが必要であり、特にセキュリティパッチが性能、互換性、あるいは他のセキュリティ制御に影響を及ぼす可能性がある場合はなおさらだ。数百万人が使うブラウザでは、不適切な修正が大規模な新たな障害を生み出す可能性がある。

競争圧力は攻撃者にも及ぶ。防御システムがコードをより速く検査し、弱点を特定できるなら、攻撃的研究者や犯罪組織も同様の能力を使って公開ソフトウェア、ブラウザ拡張、アプリケーション、インフラを探索するかもしれない。結果として、パッチの速さと安全な展開が、バグを見つける生の能力と同じくらい重要になる可能性がある。

次に注目すべき点

次に有用なシグナルとなるのは、Googleから測定プロセスに関するより詳しい説明だ。セキュリティチームや研究者は、1,072件の修正のうち何件がAIで発見されたのか、何件がモデル支援で提案または実装されたのか、そしてGoogleがどのように削減された時間を測定したのかを知りたがるだろう。

今後のChromeのリリースデータは、6月が異例の急増だったのか、それとも持続的な増加の始まりだったのかも示す。複数のブラウザをまたぐより広い比較は、Google固有のプロセス変更と業界全体の動向を切り分ける助けになるかもしれない。

企業の購入担当者は、Chromeのパッチ頻度、緊急アップデートの回数、自動展開に関するガイダンスの変化に注目すべきだ。また、自社のセキュリティツールが、エンジニアリングチームを圧倒せずに、より多くの脆弱性情報を優先順位付けできるかも評価すべきである。

最後に、独立した研究者は、増え続ける修正件数が、悪用率の低下、修復期間の短縮、あるいは利用者に届く深刻な脆弱性の減少に結びついているかを調べる可能性がある。修正されたバグが増えることは重要な運用指標だが、それだけで全体的なリスクが低下した証拠にはならない。

Creati.aiの視点

GoogleのChromeに関する数値は、AIセキュリティをめぐる議論をより具体的にしている。重要なのは、モデルがバグを見つけられるということだけではない。AIが、弱点の発見からパッチ準備まで、セキュリティライフサイクルの複数の段階を圧縮しうる点にある。それは、資金力のあるベンダーにとって、広く使われるソフトウェアを守るうえで大きな優位性になりうる。

しかし、その加速は厳格なレビューの価値も高める。発見が増えれば、優先順位付け、検証、展開がボトルネックになる。ビルダーや企業のセキュリティ責任者にとっての戦略的な問いは、AIを使うべきかどうかではなく、生成される大量の成果物を自社のエンジニアリングシステムが安全に処理できるかどうかである。