Chromeが2リリースで1,072件のセキュリティバグを修正 - GoogleのAI脆弱性発見が変えたブラウザ更新の常識

Googleは2026年7月30日、Chrome Security Team名義の公式ブログ「Stronger with every update: How we're making Chrome and the web safer in the AI Era」を公開し、Chrome 149と150の2マイルストーンで1,072件のセキュリティバグを修正したと発表しました。同記事は、この件数が「直前の23マイルストーンで修正したセキュリティバグの合計を上回る」と述べています。そして同じ日、Chrome 151が安定版に昇格し、こちらは370件の修正を含んでいます。

数字だけ見ると「Chromeが急に危険になった」ようにも読めますが、実態は逆です。Googleが社内でGeminiベースのエージェントを走らせて脆弱性を掘り出す体制に切り替えた結果、これまで見つかっていなかったバグが一気に表に出てきた、というのが今回の本質です。本記事では、Google公式ブログとChrome Releases公式リリースノートを一次情報として、実際の件数と深刻度の内訳を数え直したうえで、この変化がブラウザセキュリティと自社プロダクトの脆弱性管理に何をもたらすのかを整理します。AIによるコードスキャンという文脈では、以前に扱ったClaudeによるセキュリティ脆弱性スキャンとも地続きの話題です。

まず結論: 何が起きたのか

Googleは2026年初頭に、Geminiを使ったエージェントハーネス(agent harness)をChromeコードベース全体に適用し、脆弱性発見を自動化しました。
発見だけでなく、トリアージ・修正パッチ生成・テスト作成までLLMエージェントのワークフローに載せています。公式ブログは「ほとんどの脆弱性について、LLMが修正候補を生成している」と述べています。
その結果、Chrome 149・150の2マイルストーンで1,072件のセキュリティバグを修正。直前23マイルストーンの合計を超えました。
Chrome 151(2026年7月30日)も370件を修正。うち349件はGoogle自身による報告です。
反動として、バグバウンティ(Chrome VRP)の報奨金体系が見直され、Chrome側の単価は引き下げられました。
利用者側の実務的な結論は単純で、Chromeの再起動を先延ばしにしないことに尽きます。

早見表: 直近3リリースの修正件数

Chrome Releasesの公式リリースノートに掲載されている個別エントリを数えた結果が次の表です。合計件数は各記事冒頭の「This update includes N security fixes」の記載と一致します。

リリース	公開日	バージョン	修正件数	Critical	High	Medium	Low	Google報告分
Chrome 149	2026年6月2日	149.0.7827.53/.54	429件	22	87	226	94	371件
Chrome 150	2026年6月30日	150.0.7871.46/.47	433件	20	88	186	139	401件
Chrome 151	2026年7月30日	151.0.7922.71/.72	370件	7	71	170	122	349件

「Google報告分」は、リリースノート内で報告者が「Reported by Google」と記載されているエントリ数です。Chrome 151では370件中349件、割合にして約94パーセントが社内発見という内訳になります。外部研究者からの報告は21件で、うち8件に報奨金額が明記されており、その合計は58,500ドルでした(残る13件は「TBD」表記で金額未確定)。

深刻度の分布にも変化が見えます。Chrome 149ではCritical 22件だったものが、Chrome 151では7件まで減っています。件数全体は依然多いものの、CriticalとHighの比率は下がってきており、AIが掘り出しているバグの多くがMedium・Low帯に集中していることが読み取れます。

公式の「1,072件」と、CVE件数の合計が一致しない理由

ここで注意が必要なのは、公式ブログの「1,072件」と、リリースノートに列挙されたCVE件数の合計が一致しない点です。Chrome 149の429件とChrome 150の433件を足しても862件で、1,072件には210件足りません。

Googleの表現は「security bugs fixed in recent Chrome Stable release milestones(直近のChrome安定版マイルストーンで修正したセキュリティバグ)」であり、CVEが採番されたものだけを数えているとは書かれていません。マイルストーン昇格時のリリースノートは、そのバージョンで新規に公開されたCVEを列挙したものであり、同一マイルストーン期間中に別途出る安定版パッチリリース(例: 149.0.7827.xxの後続更新)の修正分は含まれません。この差分と、CVE番号が振られない社内発見バグの存在が、862件と1,072件のギャップを説明していると考えるのが自然です。

ただしこの内訳はGoogleが明示していないため未確認です。公式ブログはグラフを掲載しているものの、マイルストーンごとの内訳数値やCVE採番の有無について定義を書いていません。「1,072件」を引用する際は、「CVE 1,072件」ではなく「セキュリティバグ1,072件」と正確に書くのが安全です。

なお、Chrome 150について一部の記事では「382件の修正、うちCritical 15件」と報じられていますが、Chrome Releases公式リリースノートの現在の記載は433件であり、こちらを一次情報として採用しています。

GoogleはAIで何をしているのか

公式ブログは、セキュリティバグのライフサイクルを「発見 -> トリアージ -> 修正 -> リリース -> 適用」の5段階に分け、各段階でどうAIを入れたかを説明しています。

発見: Geminiベースのエージェントハーネス

Chrome Security TeamはLLM活用を2023年から始めており、公式ブログは次の系譜を挙げています。

2023年: LLMでファジングのカバレッジと性能を向上させる手法を開発
2024年: Project Zeroと共同で「Naptime」を開発し、LLMに脆弱性リサーチ用のツールを与える
2025年: DeepMindおよびProject Zeroと共同で「Big Sleep」を開発。V8 JavaScriptエンジンとグラフィックススタックでバグを発見
2026年初頭: Geminiを使ったエージェントハーネスを構築し、Chromeコードベース全体に適用

エージェントハーネスの改良点として、公式ブログは次の5つを挙げています。

オープンウェイトモデルとプロプライエタリモデルの双方の強みを活かすため、モデル相互運用性を追加
過去に特定された全CVEとChromeのGit履歴全体を含むナレッジベースを構築し、LLMの推論能力を訓練データの範囲外まで拡張
開発者にSECURITY.mdファイルの追加を推奨し、モデルが信頼境界と脅威モデルを正しく理解できるようにする
別コンテキストを持つ「critic(批評)」エージェントを追加し、そのSECURITY.mdを読ませる
モデルの非決定性とモデル自体の改善を考慮して、同じコードベースに対して脆弱性発見モデルを何度も走らせる

つまり「過去のCVEとGit履歴を学習資源として与え、同じコードを何度もスキャンし直す」という設計です。これは「過去に似た欠陥が出た箇所には別の欠陥も潜んでいる」という、人間のセキュリティ研究者が経験的に使ってきた戦略をそのまま自動化したものと言えます。

安全側の作りにも触れられています。AIはソースコードを静的に解析するのみで、汎用インターネットアクセスを持たないロックダウンされたマシン上で動作し、全ネットワークリクエストを傍受して発信元アプリケーションと宛先に基づく厳格な許可リストで制御する、と記載されています。またモデルを無制限モードで動かすことはなく、サブエージェントがローカルシステムを変更したり指定されたソースコードディレクトリ外のファイルへアクセスすることも制限しています。この種の「エージェントを閉じ込める」設計思想は、AI評価環境からのサンドボックス脱出事例で扱った論点と重なります。

13年間潜んでいたサンドボックス脱出バグ

象徴的な事例として公式ブログが挙げているのが、13年以上コードベースに潜んでいたサンドボックス脱出の脆弱性です。侵害されたレンダラープロセスがブラウザプロセスを騙してローカルファイルを読ませることができるというもので、公式ブログは「多くの我々にとって、この瞬間がAIによる脆弱性検出の可能性を確信させた」と書いています。

公式ブログ本文はCVE番号を書いておらず、Chromiumのバグトラッカー(issue 487383169)へリンクしているだけです。同じissue IDでChrome Releasesを追うと、CVE-2026-3545「Insufficient data validation in Navigation」に対応することが確認できます。これは2026年3月3日公開のChrome 145.0.7632.159で修正されており、報告日は2026年2月24日、報告者は「Google」です。

この脆弱性については報道間で記述が食い違っています。SecurityWeekはCVSS 9.8のCriticalとして報じていますが、Chrome Releasesのリリースノート上の分類はHighであり、NVDに登録されているGoogle提供のCVSS v3.1スコアは9.6(ベクタはCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H)です。Chromiumの深刻度分類とCVSSスコアは別体系であり、両者がずれること自体は珍しくありませんが、記事や社内報告で引用する際はどちらの基準の話かを明示したほうが混乱を避けられます。

トリアージ: 4段階の自動化

従来、セキュリティ報告1件のトリアージには5分から30分以上かかり、人間の専門知識に依存していました。GoogleはこれをルールベースとAIのハイブリッドに置き換え、次の4フェーズに分解しています。

ノイズの除去: スパムかどうか、重複でないか、Chromeのセキュリティ脆弱性を明確に記述しているかを判定
バグの再現: PoCの有無を確認し、再現可能なバグを該当OS・該当ブラウザバージョン上でテスト。スタックトレース等の情報を付加
メタデータの付与: バグがいつ混入したか、深刻度はいくつかといった情報を自動付与。自動適用しやすいように深刻度ガイドライン自体も明確化
自動アサイン: 正しいコンポーネントと担当者へ自動ルーティング

公式ブログはこの効果を「正確な計測は難しいが、月あたり数百時間の開発者の時間を節約していると見積もっている」と表現しています。深刻度の判定はエンジニアが上書きできる余地を残しており、SECURITY.mdでセキュリティ境界の文脈をモデルに与える運用も併用されています。

修正: fixingエージェントとcriticエージェントのループ

修正フェーズは複数エージェントのワークフローです。まずfixingエージェントが複数の修正候補を返し、criticエージェントがどれが最適かを評価します。この2つはコードレビューを模したループで回り、Chromium・Googleのスタイルガイドやローカルのコード規約に適合しているかを確認します。さらにtest-writingエージェントが、開発者がレビューする前にChromeがサポートする全プラットフォーム・全構成でテストが通ることを保証します。公式ブログはこれで「数週間分の開発者の時間を節約できる」としています。

加えて、Big SleepとCodeMenderはCIに統合されており、24時間ごとに全CL(変更リスト)に対して走ります。公式ブログは「5月だけで20件を超える脆弱性が本番へ到達するのを防ぎ、その中にはCritical S1+の問題も含まれていた」と述べています。

リリースと適用: パッチギャップとの戦い

見つけて直せるようになると、次のボトルネックは「ユーザーに届くまでの時間」です。修正が公開リポジトリにコミットされた瞬間から、攻撃者はそれを解析して修正前バージョンを狙えるようになります。これがいわゆるパッチギャップ、Nデイ攻撃の問題です。

Googleはすでにメジャーマイルストーンの2週間サイクルへの移行を進めており、セキュリティ更新は週次で提供されています。そのうえで公式ブログは、「週2回のセキュリティリリースへの移行をパイロット中」と明かしています。さらに、リリースノートとCVE説明文の生成自体を自動化し、脆弱性発見から公開までの窓を短くする作業も進めているとしています。

最後の関門はユーザー側の再起動です。Chromeは2008年からサイレント更新を実装していますが、バイナリが適用されるのはブラウザ再起動時です。トリアージから修正・テスト・リリースまでが1日から2日で回るようになった今、ユーザーが再起動を先延ばしにしている時間のほうが、Nデイ攻撃のリスク寄与として大きくなっています。これに対してGoogleは「動的パッチ適用(dynamic patching)」への投資を表明しています。Chromeのマルチプロセスアーキテクチャを活かし、レンダラーやGPUといった子プロセスを順次、更新済みバイナリへ差し替えることで、ほとんどの場合にブラウザの完全再起動を不要にするという構想です。ただしこれは研究開発段階として告知されているもので、提供時期は公表されていません。

ファジングは不要になったのか

「AIが脆弱性を見つけるならファジングは要らないのでは」という疑問には、公式ブログが明確に答えています。AIによる脆弱性検出は既存のセキュリティテスト基盤を補完するものであり、置き換えるものではない、という立場です。

具体的には、「ファジングは、コードベースの離れた部分どうしの長距離の相互作用から生じるバグや、一見無関係な操作の組み合わせを必要とするバグを見つけるのに、依然として特に効果的である」と述べられています。Chrome Releasesのリリースノート末尾にも、AddressSanitizer、MemorySanitizer、UndefinedBehaviorSanitizer、Control Flow Integrity、libFuzzer、AFLといった従来からのツール群で多くのバグが検出されている旨の定型文が今も掲載されています。

これは実務上も重要な示唆です。LLMベースのスキャンは「このコード片は危なそうだ」という静的な推論に強く、ファジングは「実際に走らせたら壊れた」という動的な事実に強い。両者は得意分野が違うので、自社プロダクトにAIコードスキャンを導入する場合も、既存のサニタイザやファザーを外す理由にはなりません。

バグバウンティ(Chrome VRP)への影響

社内発見が急増した副作用として、外部研究者との関係も変わりました。公式ブログによれば、2026年初頭からあらゆるカテゴリのバグ報告が緩やかに増え、3月には2025年通年を上回る件数の報告を受け取ったといいます。AIツールを手にした研究者が低難度のバグを大量に見つけて投稿できるようになったためです。

Googleはこれを受けてChrome VRPのルールを変更し、「社内で見つけているものに対して付加価値のある報告」「自動処理パイプラインで扱いやすい報告」へ研究者を誘導する方針へ転換しました。詳細はGoogle Bug Huntersの公式記事「Evolving the Android & Chrome VRPs for the AI Era」にまとまっています。

報奨金の具体的な増減について、SecurityWeekは2026年5月1日付の記事で、Androidの最高額(Pixel Titan Mに対する永続性ありゼロクリック)が100万ドルから150万ドルへ引き上げられた一方、Chrome側の単価は引き下げられ、メモリ安全性の問題の基本報奨は500ドル+乗数になったと報じています。フルチェーンのChromeエクスプロイトは25万ドルのまま据え置きです。これらの金額は報道ベースの数値であり、最新の正確な条件はChrome VRPの公式ルールページで確認してください。

構図としては、「量」で稼げるバグはAIが社内で拾い切るので、外部研究者には「AIには出せない深さ」に対して払うという再配分です。実際の悪用可能性を証明する、複数の欠陥を連鎖させる、システムへの深い理解が要る、といった領域が今後の外部研究者の主戦場になります。

CVE件数インフレという副作用

この動きはChromeだけの話ではありません。同時期にMicrosoftも記録的な件数のCVEを1回のPatch Tuesdayで公開しており、詳細は2026年7月のPatch Tuesdayで622件のCVEが公開された件で扱いました。The Hacker Newsは、NVDに登録された2026年の脆弱性が7月末時点で46,872件に達し、2025年通年の49,920件に迫っていると報じています。

脆弱性管理の現場から見ると、これは以下のような実務的な負荷として現れます。

件数ベースのSLAが破綻する: 「全CVEを30日以内に対応」といったポリシーは、1リリース400件規模では成立しません。深刻度と実際の露出面に基づくトリアージが必須になります。
脆弱性スキャナの出力が膨らむ: Chromiumベースのアプリケーション(Electron製ツールなど)を同梱している製品は、上流のCVE増加がそのままSBOMスキャン結果の件数増になります。
「Criticalが減った」ことの読み替えが要る: Chrome 151のCritical 7件という数字は、危険が減ったのではなく、大量発見の内訳がMedium・Low帯に寄っている結果です。前年同期との単純比較には意味がありません。
公開までの時差が縮む: GoogleがリリースノートとCVE説明文の生成自動化を進めているため、修正コミットからCVE公開までの間隔は今後さらに短くなります。情報収集の頻度も上げる必要があります。

実務者が取るべき対応

1. Chromeを再起動する運用を明文化する: 最も費用対効果が高い対策です。個人利用なら「更新あり」の表示が出たら当日中に再起動する。組織なら、ChromiumのポリシーRelaunchNotificationを「Required」に設定すると、通知期間の経過後に再起動が強制されます。この通知期間はRelaunchNotificationPeriodで指定でき、既定値は604800000ミリ秒(1週間)です。週2回のセキュリティリリースが視野に入っている以上、既定の1週間は長すぎる可能性があります。件数が多いこと自体より、修正済みバイナリがディスク上にあるのに適用されていない時間のほうが実害に直結します。

2. 使っているバージョンを確認する: chrome://versionまたはchrome://settings/helpで確認できます。2026年8月2日時点の安定版は151.0.7922.71/.72(Windows/Mac)、151.0.7922.71(Linux)です。ロールアウトは数日から数週間かけて段階的に行われるため、表示されない場合はヘルプ画面を開いて更新を促してください。

3. Chromiumベースの周辺ソフトを棚卸しする: Edge、Brave、Opera、Vivaldiといったブラウザに加え、Electron製のデスクトップアプリ、組み込みのWebViewを持つ社内ツールも同じ上流の修正を必要とします。特にElectronアプリはメジャーバージョン更新が遅れがちなので、Chromiumのどのバージョン系列に載っているかを把握しておく価値があります。

4. 対応の優先度を「深刻度 × 露出面」で決める: 400件のCVEを1件ずつ読む運用は現実的ではありません。CriticalおよびHighのうち、サンドボックス脱出・リモートコード実行に至るもの、レンダラー侵害を前提としないもの(ユーザーがページを開くだけで成立するもの)を優先します。逆に、Chromecast向けやiOS向けなど自組織で使っていない領域のCVEはトリアージで落とせます。

5. 自社コードにも同じ手法を持ち込む: Googleがやっていることの本質は、「過去のCVEとGit履歴をコンテキストとして与え、同じコードを繰り返しスキャンする」ことです。規模は違えど、CIにAIコードスキャンを24時間ごとに走らせる、リポジトリにSECURITY.mdを置いて信頼境界を明文化する、といった要素は小規模チームでも真似できます。ただしAIの誤検知率とコストは無視できないので、既存のSAST・依存関係スキャン・ファジングを置き換えるのではなく追加する形が現実的です。フレームワーク側のセキュリティリリース追跡についてはNext.jsの2026年7月セキュリティリリースでも扱っています。

6. 報奨金プログラムを運用しているなら受け入れ体制を先に整える: Googleが3月に2025年通年を超える報告数を受け取ったのと同じことが、規模の小さいプログラムでも起こりえます。重複判定と再現確認の自動化、報告フォーマットの規定(再現手順と必要成果物のみに絞る)を先に整えないと、トリアージ側が先に潰れます。

報道と公式発表のずれについて

今回の件は報道量が多い一方で、数値の食い違いも目立ちました。記事や社内共有で引用する際は次の点に注意してください。

論点	一次情報の記載	報道で見られる表現
1,072件の中身	「security bugs」であり、CVE件数とは明記されていない	「1,072件の脆弱性」「1,072件のCVE」と書かれることがある
Chrome 150の件数	公式リリースノートは433件	382件・Critical 15件とする記事もある
13年もののバグ	公式ブログはCVE番号を書かず、issue 487383169へリンク。リリースノート上はCVE-2026-3545でHigh	CVSS 9.8のCriticalとする記事がある(NVDのGoogle提供スコアは9.6)
修正時期	CVE-2026-3545はChrome 145.0.7632.159(2026年3月3日公開)で修正	「2026年5月初旬に修正」とする記事がある
動的パッチ適用	「投資している」「詳細は今後」という研究開発段階の記述	実装済みの機能のように読める書き方が散見される

Chromeが持つブラウザ内蔵AI機能そのものについてはChrome組み込みAI APIで別途扱っています。あわせて読むと、Googleが「AIでブラウザを守る」側と「ブラウザにAIを載せる」側の両方を同時に進めている構図が見えやすくなります。

まとめ

Googleは2026年7月30日の公式ブログで、Chrome 149と150の2マイルストーンで1,072件のセキュリティバグを修正し、直前23マイルストーンの合計を上回ったと発表しました。
Chrome Releasesの公式リリースノート単位では、Chrome 149が429件、Chrome 150が433件、Chrome 151が370件です。合計862件と1,072件の差は、マイルストーン期間中の後続パッチやCVE未採番のバグによると考えられますが、Googleの明示がないため未確認です。
Chrome 151の370件のうち349件はGoogle自身の報告で、外部研究者からは21件、公開されている報奨金の合計は58,500ドルでした。
中核はGeminiベースのエージェントハーネスで、過去の全CVEとGit履歴をナレッジベース化し、同じコードを繰り返しスキャンします。13年間潜んでいたサンドボックス脱出(CVE-2026-3545、Chromium分類はHigh)がその成果です。
トリアージ・修正生成・テスト作成もエージェント化されており、Googleは月あたり数百時間の開発者時間を節約していると見積もっています。
ファジングは置き換えられていません。公式ブログは、離れたコード間の相互作用に起因するバグにはファジングが依然として有効だと明記しています。
副作用としてChrome VRPの報奨金体系が見直され、Chrome側の単価は引き下げられました。外部研究者の価値は「AIが出せない深さ」へ移っています。
利用者・運用者が今日できる最も効果的な対策は、Chromeを最新版へ更新し、再起動を先延ばしにしないことです。

Chromeが2リリースで1,072件のセキュリティバグを修正 - GoogleのAI脆弱性発見が変えたブラウザ更新の常識

まず結論: 何が起きたのか

早見表: 直近3リリースの修正件数

公式の「1,072件」と、CVE件数の合計が一致しない理由