GoogleがChromeの脆弱性をAIで発見｜13年潜んだサンドボックスエスケープとChrome 149/150の1,072件修正、Big Sleep・CodeMenderの仕組みを解説【2026年10月最新】

GoogleはGeminiを使ったAIエージェントでChromeのコードを解析し、13年以上見つからなかったサンドボックスエスケープの脆弱性を発見しました。さらにChrome 149と150の2リリースで計1,072件のセキュリティバグを修正したと公表しています（Googleの集計）。一般ユーザーへの影響でいうと、13年もののバグは2026年3月のChrome 145ですでに修正済みです。Chromeを最新版に更新し、再起動まで済ませていれば対象外です。

この記事でわかること

2026年7月30日にGoogleが発表した内容の要点と、「1,072件」という数字の読み方
13年潜んでいたサンドボックスエスケープ（CVE-2026-3545）の中身と、実際の危険度
Geminiエージェントハーネス・Big Sleep・CodeMenderという3つのAIの役割の違い
Chrome 153から始まった2週間リリースサイクルなど、発表後の続報
個人ユーザー・企業のIT管理者・開発者がそれぞれやるべきこと
CodeMenderを自社で使えるか（提供条件と料金）

こんな方に向けた記事です

「Chromeに13年も脆弱性があった」というニュースを見て、自分のブラウザが安全か気になっている方
社内PCのChrome更新ポリシーを管理している情報システム部門の方
AIによる脆弱性発見・自動修正の仕組みを自社の開発に取り入れられないか検討しているエンジニアやセキュリティ担当者

発表のポイントを一覧で確認

「13年もののバグの修正」と「Chrome 149/150での1,072件修正」は別々の出来事です。混同しやすい事実を、日付と数字で切り分けると次のようになります。

項目	内容
発表日・発表元	2026年7月30日、Google Chrome Security Team（Google公式ブログ）
発見に使ったAI	Geminiを使ったエージェントハーネス（2026年初頭に構築）
目玉の発見	13年以上潜んでいたサンドボックスエスケープ（Chromium Issue 487383169）
対応するCVE	CVE-2026-3545（CVSS v3.1：9.6）
13年もののバグの修正版	Chrome 145（145.0.7632.159/160）、2026年3月3日
修正件数の目玉	Chrome 149と150の2リリースで1,072件（Googleの集計）。直前23マイルストーン分の合計を上回る
常時稼働しているAI	Big Sleep・CodeMenderをCIに組み込み、24時間ごとに実行
本番前にブロックした数	2026年5月だけで20件超（うち重大度S1+が1件）
発表後の続報	2026年9月8日のChrome 153からリリースサイクルを4週間→2週間に短縮
ユーザーがやること	Chromeを更新して再起動する。Edgeなど他のChromium系ブラウザも更新する

Googleは何を発表したのか（2026年7月30日の公式ブログ）

Chromeのセキュリティ更新とAIによる脆弱性発見を表すGoogle公式ブログのイメージ画像

出典：Google公式ブログ

Googleは公式ブログ「Stronger with every update: How we're making Chrome and the web safer in the AI Era」で、Chromeのセキュリティ対策の全工程にAIを組み込んだと説明しました。脆弱性の「発見」だけでなく、「トリアージ（仕分け）」「修正」「ユーザーへの配信」まで、AI前提で作り直しているという内容です。

AI活用の歩み

ChromeのセキュリティチームによるLLM活用は、今回が初めてではありません。

時期	取り組み
2023年	ファジング（大量の自動テスト入力でバグを探す手法）の網羅率と性能をLLMで向上
2024年	Project Zeroが脆弱性調査用のLLMフレームワーク「Naptime」を公開（報道ベース）
2025年	Google DeepMindとProject Zeroの「Big Sleep」がChromeのV8などでバグを発見
2026年初頭	Geminiを使ったエージェントハーネスを構築し、Chromeのコードベース全体を対象に解析
2026年7月30日	公式ブログで、13年もののバグの発見と1,072件の修正を公表

公式ブログによると、2026年初頭に作ったエージェントハーネスは「より高い効率と、より少ない誤検知」でChrome全体の脆弱性を探せるようになったとされています。

「1,072件」と「過去23マイルストーン」の意味

公式ブログは「直近2つのマイルストーン（Chrome 149と150）で1,072件のセキュリティバグを修正し、それ以前の23マイルストーン分の合計を上回った」と書いています。Chromeは2026年8月まで約4週間ごとにメジャー版を出していたので、23マイルストーンはおよそ2年分です。単純計算で、約2カ月で2年分以上のバグを直したことになります。

1,072件とリリースノートの件数が合わない理由

各リリースのセキュリティ修正件数を報道（リリースノート準拠）で確認すると、Chrome 149が429件、Chrome 150が382件で、合計は811件です。Googleの1,072件とは約260件の差があります。

Googleは内訳を公表していません。CVEが割り当てられない内部バグや、マイナーアップデートでの修正を含めて数えている可能性がありますが、確認はできていません。1,072件はGoogleの集計値、429件・382件はリリースノート上の件数として、別の数字と考えるのが安全です。

リリース	安定版の公開日	セキュリティ修正	うちCritical	補足
Chrome 145（.159/.160）	2026年3月3日	—	—	13年もののバグ（CVE-2026-3545）を修正
Chrome 149	2026年6月上旬	429件	22件	単一リリースとして過去最多（SecurityWeek）
Chrome 150	2026年6月30日	382件	15件	382件のうち358件がGoogle内部の発見（PCWorld）
Chrome 151	2026年7月29日	370件	7件	149〜151の3リリースで1,442件（The Hacker News）
Chrome 153	2026年9月8日	—	—	2週間サイクルの初回
Chrome 154	2026年9月22日	108件	11件	Malwarebytesの報道

Chrome 149〜151のどのリリースでも、確認できた範囲では実際に悪用された脆弱性（ゼロデイ）は含まれていません。件数が多いのは「危険が増えた」からではなく、「AIで見つけて直すペースが上がった」ことの表れと読むのが妥当です。

13年潜んだサンドボックスエスケープとは（CVE-2026-3545）

13年もののバグは、乗っ取られた「レンダラー」がブラウザ本体をだまして、PC内のローカルファイルを読ませてしまう脆弱性です。Chromeの安全設計の要であるサンドボックス（隔離環境）を抜け出す種類のバグで、深刻度は高く評価されています。

項目	内容
Chromiumのバグ管理番号	487383169（Google公式ブログに記載）
CVE	CVE-2026-3545
対象コンポーネント	Navigation（データ検証の不備、CWE-20）
内容	侵害されたレンダラーがブラウザを欺き、ローカルファイルを読ませる
深刻度	Chromium評価：High／CVSS v3.1：9.6
報告	Google内部（2026年2月24日、第三者データベースの情報）
修正	Chrome 145.0.7632.159（Linux）／.160（Windows・Mac）、2026年3月3日
実際の悪用	確認できた範囲では報告なし
他ブラウザへの影響	Microsoft EdgeなどChromium系ブラウザも対象（第三者データベース）

公式ブログにCVE番号の記載はありません。脆弱性データベースOSV.devのCVE-2026-3545のレコードがChromiumのバグ487383169を参照しているため、両者が同じものだと特定できます。CVSSスコアはSecurityWeekが9.8と報じていますが、OSVなど複数のデータベースが9.6としているため、ここでは9.6を採用しました。

サンドボックスエスケープとは

Chromeは、Webページを表示する「レンダラー」を権限の弱いサンドボックスに閉じ込めています。悪意あるページがレンダラーを乗っ取っても、PC内のファイルや他のアプリには手を出せない仕組みです。サンドボックスエスケープは、この隔離を破ってレンダラーの外側（ブラウザ本体やOS）に影響を及ぼす脆弱性を指します。

なぜ13年も見つからなかったのか

今回のバグは「入力の検証が足りない」という論理的な欠陥でした。従来の主力だったファジングは、ランダムな入力を大量に流してクラッシュを探す手法です。メモリ破壊のようにプログラムが落ちるバグには強い一方、「落ちずに間違った動作をする」論理バグは見つけにくい傾向があります。

LLMを使ったエージェントは、コードの意味や過去の脆弱性パターンを読んで「ここは検証が抜けていないか」と推論できます。人間のレビューとファザーの両方をすり抜けてきたタイプのバグにAIが届いたことが、今回の発表で最も大きなポイントです。

単体ですぐ攻撃が成立するわけではない

サンドボックスエスケープを悪用するには、まずレンダラーを乗っ取る別の脆弱性が必要です。実際の攻撃では「レンダラーの乗っ取り」と「サンドボックス脱出」を組み合わせる（チェーン攻撃）のが一般的で、CVE-2026-3545はその後半を担う部品にあたります。危険なバグであることは確かですが、「ページを開いただけで即座にファイルを盗まれる」状態だったわけではありません。

Geminiエージェントハーネス・Big Sleep・CodeMenderの違い

コードセキュリティ用AIエージェントCodeMenderを紹介するGoogle DeepMind公式画像

出典：Google DeepMind公式ブログ

今回の発表には3種類のAIが登場します。13年もののバグを見つけたのは「Geminiエージェントハーネス」で、Big SleepとCodeMenderは開発中のコードを24時間ごとに監視する役割です。報道ではこの3つが混同されがちですが、開発元・役割・外部から使えるかどうかがそれぞれ異なります。

項目	Geminiエージェントハーネス	Big Sleep	CodeMender
開発元	Google Chromeセキュリティチーム	Google DeepMind × Project Zero	Google DeepMind
主な役割	Chromeのコードベース全体から脆弱性を探す	脆弱性の発見に特化したエージェント	脆弱性の発見・検証・修正パッチ生成
Chromeでの使われ方	2026年初頭に構築。13年もののバグを発見	CIに組み込み24時間ごとに実行。V8やグラフィックス周りで発見	CIに組み込み24時間ごとに実行
主な実績	CVE-2026-3545（13年もののバグ）	SQLiteの脆弱性発見（2024年）、Chrome 139のV8脆弱性 CVE-2025-9132 など	OSSへのセキュリティ修正のアップストリーム
外部からの利用	不可（Google社内）	不可（Google社内）	Google CloudでPublic Preview（限定顧客）
料金	—	—	トークン従量課金（使用するGeminiモデルに準拠）

Geminiエージェントハーネス

Chromeチームが2026年初頭に作った、脆弱性探索用のエージェントの実行基盤です。公式ブログで説明されている主な特徴は次のとおりです。

オープンウェイトとプロプライエタリの両方のモデルを差し替えて使える
過去に見つかったすべてのCVEと、ChromeのGit履歴をナレッジベースとして参照する
別コンテキストで動く「Critic（批評）エージェント」が、開発者の書いたSECURITY.mdを読んで本当に脆弱性かを評価し、誤検知を減らす
モデルの出力にはばらつきがあるため、同じコードベースを複数回スキャンする

Big Sleep

Google DeepMindとProject Zeroが共同開発した脆弱性探索エージェントです。2024年11月には、オープンソースのデータベースSQLiteで未知の脆弱性を見つけたと公表しました。2025年には、攻撃者だけが知っていて悪用寸前だったSQLiteの脆弱性（CVE-2025-6965）を、脅威インテリジェンスと組み合わせて先回りで発見しています。Chromeでは、JavaScriptエンジンのV8やグラフィックススタックでバグを見つけた実績があります。外部向けには提供されていません。

CodeMender

2025年10月にGoogle DeepMindが発表したAIコードセキュリティエージェントで、「見つける」だけでなく「直す」までを担います。処理は3段階に分かれています。

Find：コードをスキャンして脆弱性の候補を探す
Verify：顧客が管理するサンドボックス内で概念実証（PoC）のエクスプロイトを実行し、本当に悪用できるかを確認する
Fix：修正パッチを生成し、LLMを評価役に使う「LLM-as-a-judge」で既存機能を壊していないかを確認する

2026年7月22日からGoogle CloudでPublic Previewとして提供が始まりましたが、現時点で使えるのは営業経由で申請した限定顧客です。

発見から配信まで：ChromeはAIをどう組み込んだか

Googleの説明で重要なのは、AIを「脆弱性を見つける道具」で終わらせていない点です。脆弱性が見つかる数が増えると、人手のトリアージや修正、配信がボトルネックになります。Chromeチームは、その後ろの工程もまとめてAI前提に組み替えました。

工程	AIの役割	人間の関与
発見	Geminiエージェントハーネスがコード全体を複数回スキャン。Criticエージェントが誤検知をふるい落とす	結果を確認
トリアージ	①ノイズ除去 ②バグの再現 ③深刻度などのメタデータ付与 ④担当者の自動割り当て	開発者は深刻度評価を修正できる
修正	修正エージェントが複数の候補パッチを作り、Criticエージェントが最良案を選び、テスト作成エージェントが複数プラットフォーム向けのテストを書く	開発者がレビュー・承認
予防	Big Sleep・CodeMenderをCIに組み込み、24時間ごとに実行	—
配信	更新サイクル短縮、再起動タイミングの最適化	—

トリアージの自動化で「月に数百時間」を削減

脆弱性報告は、本物のバグかどうかの判定や再現作業に手間がかかります。Googleは4段階のトリアージを自動化し、開発者の作業時間を月に数百時間削減できていると見積もっています。

修正は「AIが候補を出し、人が承認する」

修正工程はコードレビューに近い反復ループです。複数のエージェントがパッチ案とテストを作って評価し合いますが、最終的に取り込むかどうかは開発者が判断します。「AIが全自動でChromeを書き換えている」わけではありません。

本番に届く前に止める

公式ブログによると、Big SleepとCodeMenderはCI（継続的インテグレーション）に組み込まれ、24時間ごとに動いています。2026年5月だけで、20件を超える脆弱性を本番に到達する前にブロックし、その中には最も重大な区分のS1+も1件含まれていました。リリース後に見つけて直すのではなく、リリース前に作り込まない方向にもAIが使われています。

根本対策としてのメモリ安全性

AIで見つけて直すだけでは、バグの総量は減りません。Chromeは並行して、バグの温床になりやすいC++コードの改善も進めています。

MiraclePtr／MiracleObjectの適用範囲を広げ、解放済みメモリの使用（Use-After-Free）を防ぐ
「Spanification」により、自社コードの97%が厳格な安全でないバッファの警告なしでコンパイルできる状態にした
長期的には、パーサー・コーデック・フォントなどバグの多い領域からRustへ移行し、UIのHTML/CSS/TypeScript化も検討する
2,300を超えるサードパーティ依存関係について、Googleのオープンソース分析基盤GOSSIPやNVD・OSVの情報を使い、更新を自動化する

続報：Chrome 153から2週間リリースに移行

Chromeの2週間リリースサイクル開始を告知するChrome for Developers公式画像

出典：Chrome for Developers

AIで修正が速くなった結果、今度は「直したものをユーザーにどれだけ早く届けるか」が課題になりました。Googleは2026年9月8日のChrome 153から、メジャー版のリリース間隔を4週間から2週間に短縮しています（Chrome for Developers公式ブログ）。

公式が挙げている理由は2つです。AIの自動発見ツールでパッチの量が増え、短いサイクルの方がセキュリティ修正を扱いやすいこと。そして、修正が公開コードベースに入ってからユーザーの手元に届くまでの期間（N-dayパッチギャップ）を縮めることです。

項目	通常のStable	Extended Stable
メジャー更新の間隔	2週間ごと（Chrome 153以降）	8週間ごと（例：Chrome 156、160）
セキュリティ修正	毎週	毎週（通常どおり）
想定する利用者	一般ユーザー、多くの企業	変更を検証してから展開したい高機密環境
Googleの推奨	セキュリティの標準として採用	必要な場合のみ使う

検討中の施策（確定ではない）

公式ブログでは、さらに次の施策にも触れています。いずれも2026年10月時点では試験や構想の段階です。

週2回のセキュリティリリース：試験的に運用を始めている（piloting）段階
動的パッチ（Dynamic Patching）：Chromeのマルチプロセス構造を活かし、裏側のプロセスを差し替えて再起動なしで修正を当てる構想
再起動タイミングの最適化：たとえばmacOSですべてのウィンドウが閉じている状態を検出して再起動する、といった工夫

なぜ更新を急ぐ必要があるのか：AIは攻撃側も使っている

脆弱性の修正は、Chromiumのようなオープンソースでは公開コードに入った時点で誰でも見られます。攻撃者は修正内容を逆算すれば、どこに脆弱性があったかを把握できます。ユーザーがまだ更新していない期間（N-day）は、攻撃者にとって狙い目になります。

この差分解析や攻撃コードの作成にもAIが使われ始めています。Googleの脅威インテリジェンスチームは、攻撃者のAI活用が当たり前になっていると報告しており、詳細はGoogleのGTIGレポート解説にまとめています。AIが攻撃コードを作った事例はAIが作ったゼロデイ脆弱性悪用の解説、公開済みの脆弱性をAIエージェントが突いた事例はPaperCutへのAIエージェント攻撃で取り上げています。

防御側のAIで修正が速くなっても、ユーザーが更新を適用しなければ効果は出ません。リリースが2週間ごとになった今、「更新ボタンを押して再起動する」ことの重要度は上がっています。

ユーザー・企業がやるべきこと

立場ごとに必要な対策は異なります。個人は「更新と再起動」、企業は「再起動を促す仕組みと、どのチャネルを使うかの判断」が中心です。

個人ユーザー

Chromeの右上に「更新」ボタンが出ていたら押して再起動する
メニュー（︙）→「ヘルプ」→「Google Chromeについて」を開き、最新版になっているか確認する（アドレスバーに chrome://settings/help と入力しても開けます）
更新後に「再起動」を押す。再起動するまで修正は反映されません
Microsoft Edge・Brave・OperaなどChromium系ブラウザも使っているなら、それぞれ更新する
スマートフォンのChromeも、App Store／Google Playで更新する

2026年10月上旬の時点では、Chrome 154系が安定版で、Chrome 155の配信が始まる時期にあたります（配信状況は端末や地域によって前後します）。少なくともChrome 145（2026年3月）より新しい版になっていれば、13年もののバグは修正済みです。

企業のIT管理者

RelaunchNotification ポリシーで、ユーザーへの再起動の通知や強制を段階的に設定する
通常のStable（2週間）をセキュリティの基本とし、Extended Stableは検証が必須の高機密環境に限定する
Extended Stableを使う場合は、社内のテスト工程を8週間の更新タイミングに合わせる
Chrome Enterpriseの管理画面で、組織内のChromeのバージョンを追跡する
Edgeなど他のChromium系ブラウザについても、更新ポリシーとバージョンを確認する

Webサービス・社内システムの開発者

Chrome Betaで、次のバージョンでの社内Webアプリや拡張機能の動作を事前に確認する
Chrome Platform Statusのロードマップで、仕様変更の予定を把握する
更新間隔が半分になったため、ブラウザ互換性テストの頻度を見直す

AIエージェントを業務に入れる際のセキュリティ全般はAIエージェントのセキュリティ対策ガイド、生成AI全体のリスクは生成AIのセキュリティリスク解説でまとめています。

CodeMenderは自社で使える？提供条件と料金

Chromeと同じ仕組みを自社のコードに使いたい場合、Googleの製品で選べるのは現時点でCodeMenderだけです。Big SleepとChromeのエージェントハーネスはGoogle社内のツールで、外部には提供されていません。CodeMenderも限定顧客向けのPublic Previewで、誰でもすぐ使える段階ではありません。

項目	内容（2026年10月時点の公式情報）
提供状況	Google CloudでPublic Preview（2026年7月22日発表）。営業経由で利用申請
提供経路	Gemini Enterprise Agent Platform、AI Threat Defense（Wiz連携）
対応モデル	Gemini 3.8 Flash Cyber、Gemini 3.8／3.7／3.6／3.5 Flash、Gemini 3.1 Pro（preview）
料金体系	トークン従量課金（使用するモデルの料金に準拠）
Gemini 3.6／3.7／3.8 Flash使用時	導入価格：入力$0.75／出力$3.75（100万トークンあたり、2026年12月31日まで）
2027年1月1日以降	入力$1.50／出力$7.50（100万トークンあたり）
対応言語	C/C++、C#/.NET、Go、Java、JavaScript/TypeScript、Kotlin、Python、Ruby、Rust、PHP
検出対象	メモリ破壊、インジェクション、Webセキュリティ、暗号の弱点、不適切なデータ処理
構成	Google側のマルチエージェント＋手元で動くクライアント（CLI兼デーモン、任意でプロセス単位のサンドボックス隔離）

料金はAgent Platformの料金ページの情報をもとにしています。プレビュー中は料金や条件が変わる可能性があり、Cyberモデルを使う場合の単価も公開情報では確認できなかったため、導入時は最新の料金ページで確認してください。Gemini 3.8 Flashの料金体系はGemini 3.8 Flashの解説でも整理しています。

導入前に知っておきたい制約

本番利用は推奨されていない：Pre-GA（正式提供前）の条件が適用され、公式ドキュメントも本番環境向けではないと明記しています
人の承認が必須：「手動の承認なしにリポジトリへ変更が入ることはない」設計です。レビュー体制を用意する必要があります
用途の制限：正当なセキュリティ防御目的に限られ、解析するコードの権限を持っている必要があります
誤検知はゼロにならない：Google自身も複数回スキャンやCriticエージェントで誤検知を抑えています。単発のAIスキャン結果をそのまま信じる運用は避けるべきです

政府機関や重要インフラ事業者向けには、Gemini 3.8 Flash CyberとCodeMenderを先行提供するGoogleの「Fairwind」プログラムも2026年9月に発表されています。

AIによる脆弱性発見の業界動向

Big Sleepを開発したGoogleのセキュリティ研究チームProject Zeroのロゴ画像

出典：Google Project Zero

AIで脆弱性を大量に見つけて直す動きは、Googleに限った話ではありません。2026年はAnthropic・OpenAI・Microsoftも同じ領域にサービスや研究成果を出しており、Microsoft・Adobe・Ciscoなどでも修正件数が急増していると報じられています。

企業	取り組み	特徴	解説記事
Google	Big Sleep／CodeMender／Chromeのエージェントハーネス	自社製品（Chrome）の開発工程に全面統合	—
Anthropic	Project Glasswing（Claude Mythos）	重要ソフトウェアの脆弱性を大量に発見	Project Glasswingとは
OpenAI	Daybreak／Codex Security	脆弱性検出と自動パッチ、コードスキャン	OpenAI Daybreakとは・Codex Securityとは
Microsoft	MAI-Cyber-1-Flash	セキュリティ特化モデル	MAI-Cyber-1-Flashとは

セキュリティ特化モデルについてはGPT-5.6-Cyberの解説、AIによる暗号研究の例はClaude Mythosが暗号の新攻撃法を発見したニュース、業界全体の流れはサイバーセキュリティ業界のAI活用で扱っています。

副作用：AIが量産する「質の低い報告」

AIの普及は、脆弱性報告の質という新しい問題も生んでいます。ChromeのバグバウンティプログラムであるChrome VRPは、2026年4〜5月に報奨金の体系を見直しました。AIで長文のレポートが量産されるようになったため、メモリ安全性バグの基本報酬を$500に引き下げ、簡潔で再現できるPoCを重視する方針に変えています（Security Affairs、2026年5月3日）。一方で、フルチェーン攻撃への$250,000などの高額報酬は維持されています。

AIが生成した偽の脆弱性情報がデータベースに混入している問題は、AI生成の偽CVE問題の解説で詳しく取り上げています。AIでコードを書く側のリスクはAIコーディングのセキュリティリスクを参照してください。

対応を急ぐべき人・急がなくてよい人

今回のニュースへの対応の優先度は、Chromeの使い方や管理する立場によって変わります。

特に確認をおすすめしたい人・企業

Chromeの「更新」ボタンが出ていても、再起動を何日も先延ばしにしている方
Chromeの自動更新を止めている方や、古いバージョンに固定しているPCがある企業
Edge・Braveなど、普段あまり更新を意識しないChromium系ブラウザを使っている方
社内Webアプリや拡張機能の互換性を理由に、Chromeの更新を手動で管理している情報システム部門
自社開発のコードが大きく、脆弱性診断の手が足りていない開発組織（CodeMenderの検討余地あり）

急いで対応しなくてよい人

Chromeの自動更新を有効にしたまま、ブラウザをこまめに再起動している個人ユーザー
MDMやChrome Enterpriseで更新と再起動のポリシーをすでに運用している企業

CodeMenderの導入をまだ見送るべき組織

本番システムにすぐ適用できるツールを求めている組織（現在はPre-GA）
AIが出したパッチをレビューする人員を確保できない組織
Google Cloudの利用環境がなく、営業経由の申請や契約が難しい組織

よくある質問

13年もの脆弱性を悪用した攻撃は起きていたのですか？

確認できた範囲では、CVE-2026-3545が実際の攻撃に使われたという報告はありません。Google社内のAIが見つけて報告し、公開前に修正された脆弱性です。過去13年のあいだに誰かがひそかに悪用していた可能性を完全には否定できませんが、悪用の痕跡が公表された事実はありません。

ChromeではなくEdgeやBraveを使っていれば関係ありませんか？

関係があります。EdgeやBrave、OperaはChromeと同じChromiumを土台にしているため、Chromiumの脆弱性の影響を受けることがあります。CVE-2026-3545もMicrosoft Edgeのセキュリティ情報の対象になっています。各ブラウザの提供元が修正を取り込んだ版を配信するので、それぞれのブラウザを更新してください。

2週間ごとの更新で、社内システムや拡張機能が動かなくなりませんか？

可能性はゼロではありませんが、セキュリティ修正のためにも更新を止めるのは得策ではありません。Googleは、Chrome Betaで事前にテストすることと、どうしても検証期間が必要な環境ではExtended Stable（メジャー更新は8週間ごと、セキュリティ修正は毎週）を使うことを勧めています。

個人でもBig SleepやGoogleのAIで自分のコードを診断できますか？

現時点ではできません。Big SleepとChromeのエージェントハーネスはGoogle社内のツールです。外部向けのCodeMenderも、Google Cloudの限定顧客向けPublic Previewで、営業経由での申請が必要です。個人開発者がAIでコードを診断したい場合は、OpenAIのCodex Securityなど他社のサービスや、一般的な静的解析ツールが現実的な選択肢になります。

AIが見つけた脆弱性を報告すれば、Googleから報奨金をもらえますか？

報奨金の対象になるかどうかは、AIを使ったかどうかではなく、報告の中身で決まります。Chrome VRPはAIによる長文レポートの増加を受けて、簡潔で再現できるPoCを重視する方向に変わりました。AIの出力をそのまま送るのではなく、自分で再現を確認したうえで報告することが前提になります。

Chromeの自動更新を止めていたらどうなりますか？

修正が手元に届かないため、公開済みの脆弱性が残り続けます。リリースが2週間ごとになった今は、古いバージョンとの差が以前より早く広がります。企業で更新を管理している場合でも、セキュリティ修正だけは遅らせない運用にしておくのが安全です。

まとめ

Googleは2026年初頭にGeminiベースのエージェントハーネスを作り、13年以上潜んでいたサンドボックスエスケープ（CVE-2026-3545）を発見した
このバグは2026年3月3日のChrome 145で修正済み。Chrome 149/150での修正ではない
Chrome 149と150では、Googleの集計で計1,072件のセキュリティバグを修正した。リリースノート上の件数（429件・382件）とは数え方が違う
Big SleepとCodeMenderは開発中のコードを24時間ごとに監視し、2026年5月だけで20件超の脆弱性を本番到達前に止めた
修正量の増加を受けて、Chrome 153（2026年9月8日）からメジャー更新は2週間ごとになった
個人は「更新して再起動」、企業は再起動ポリシーとStable／Extended Stableの使い分けを見直す
同じ仕組みを自社で使う選択肢はCodeMenderだが、現時点では限定プレビューで、本番利用は推奨されていない

AIによる脆弱性発見は、見つかる数を増やすだけでなく、更新の頻度や運用の前提まで変え始めています。ブラウザの更新を後回しにしない習慣が、これまで以上に効く状況です。

この記事のポイント