AIに脆弱性を探させるまでに何を積んだか
Chromeセキュリティチームは、LLM（大規模言語モデル）を何年も前から使ってきたと書いています。今回の発表は、その積み重ねが「探す」から「直す」まで届いた段階の報告です。
助走は2023年から始まっていた
出発点は2023年で、LLMをファジング（無作為な入力を大量に与えて異常を探す手法）の網羅率と性能の向上に使う方法を開発しています。2024年にはProject Zeroと組んだ Naptime で、脆弱性研究のための専用ツールをLLMに与えました。
2025年にはDeepMindとProject Zeroとの共同で Big Sleep を作ります。こちらは脆弱性を発見するAIエージェントで、JavaScriptエンジンのV8とグラフィックス周りで実際にバグを見つけています。
13年以上だれも気づかなかったバグが見つかった
転機として挙げられているのが2026年初頭です。Gemini を使ったエージェントハーネス（モデルにツールと手順を与えて動かす土台）を構築し、Chromeのコードベース全体に対して、より高い効率と低い誤検知で探索できるようにしました。
そこで見つかったバグのひとつが、サンドボックス脱出でした。乗っ取られたレンダラープロセスがブラウザを騙してローカルファイルを読ませられる、という種類の欠陥です。そのバグは13年以上、コードベースの中で静かに生き延びていました。この瞬間が、AIによる脆弱性検出の可能性を決定づけたと書かれています。
The Chrome Security team has been using LLMs for years. In 2023 we developed ways to use LLMs to increase security fuzzing coverage and performance. In 2024, we worked with Project Zero on Naptime, giving LLMs specialized tools for vulnerability research. And in 2025, we collaborated with DeepMind and Project Zero on Big Sleep, an AI vulnerability discovery agent that successfully found bugs in the V8 JavaScript engine and graphics stack. ／ In early 2026, we built an agent harness that used Gemini to find vulnerabilities across the broader Chrome codebase with higher efficiency and lower false positives. One of the bugs we found was a sandbox escape that would allow a compromised renderer to trick the browser into reading local files — a bug that quietly survived in our codebase for more than 13 years! For many of us, this moment cemented the potential of AI-powered vulnerability detection. — LLM活用の経緯と、Geminiを使ったハーネスが13年もののバグを発見した経緯に関する記述より
精度を上げたのはモデルではなく周辺の作り込みだった
興味深いのは、その後の改善がモデルそのものの入れ替えではなく、周辺の情報と構成に集中している点です。挙げられているのは5つです。
ひとつは、重みが公開されたモデルと、重みを公開していないモデルの両方の強みを活かせるようにしたこと。ふたつめが、過去に特定されたCVE（脆弱性の識別番号）のすべてとChromeのGit履歴全体を含む知識ベースの構築で、これはLLMの推論を学習データの外へ広げるためだと説明されています。
三つめが SECURITY.md の活用です。開発者にこのファイルを書くよう促し、モデルが信頼境界（どこまでが信用してよい範囲か）を理解して脅威モデルを正しく把握できるようにしています。四つめは、別のコンテキストを持つ「批評役」エージェントにそのファイルを読ませる構成を足したことです。
五つめが、同じコードベースに対して探索モデルを複数回走らせるようにしたことです。モデルの出力が毎回同じにならない性質と、モデル自体が時間とともに良くなっていくことの両方に対応するため、と説明されています。
知識ベースにGit履歴そのものを入れている点は示唆的です。過去に何をどう変えたかが、そのまま判断材料になるという発想だからです。手元でも、2つの版の差を並べて見るところから始められます。
無料ツールテキスト差分比較2つのテキストの差分をハイライト表示。変更点を素早く発見できます。今すぐ使ってみる →
Adding support for model interoperability to leverage the unique strengths of both open-weights and proprietary models. ／ Building a knowledge base of Chrome, including all previously identified CVEs and Chrome’s entire Git history, to extend the LLMs reasoning capacity past its training data. ／ Encouraging developers to add SECURITY.md files, which help models better understand trust boundaries and develop an accurate view of the threat model. ／ Adding a “critic” agent with a separate context to consume these SECURITY.md files. ／ Introducing the ability to run vulnerability finding models over the codebase multiple times to account for model non-determinism and model improvements over time. — 探索ハーネスに加えた5つの改善に関する記述より
解析AIはネットから切り離して動かす
安全側の設計も明記されています。解析は停止した状態のソースコードに対してのみ行われ、一般的なインターネット接続を持たない隔離されたマシン上で動きます。内部スキャン専用の環境がすべての通信要求を捕捉し、起点のアプリケーションと宛先に基づく厳格な許可リストで制御する仕組みです。
さらに、制限なしのモードでモデルを動かすことはないと書かれています。サブエージェントについても、ローカルの環境を書き換えることと、指定されたソースコードのディレクトリの外にあるファイルへ触れることを厳しく制限しているとされています。
ここは読み流さないほうがいい箇所です。AIエージェントが評価環境から外へ出てしまった事例として、Anthropicが公表した評価中の実世界侵害が同じ時期に報告されています。何をさせるかより、どこまで届く場所に置くかが効くという点で、両者は同じ問題を扱っています。
We’ve built all of this with safety in mind, and have put in place guardrails to mitigate the risk of AI behaving unexpectedly. Our AI analyzes source code strictly at rest, operating on locked-down machines that lack general internet access. We also utilize a dedicated setup for these internal scans that intercepts all network requests, employing strict allowlists based on the initiating application and destination, blocking any suspicious model activity. Furthermore, we never run models in an unrestricted mode, and we strictly limit our subagents from modifying the local system or accessing files outside of designated source code directories. — 解析AIに設けたガードレールに関する記述より
仕分けと修正をどう自動化したか
見つかる数が増えれば、そのぶん後工程が詰まります。発表の中心は、むしろこの下流をどう捌いたかにあります。
1件5〜30分かかっていた仕分けを4段階に割った
トリアージ（報告されたバグの仕分け）は、従来1件あたり5分から30分以上かかり、主に人の専門性に頼っていました。これをルールベースの仕組みとAIを混ぜた自動処理へ寄せています。
工程は4つに分かれます。ノイズの除去（スパムか、重複でないか、Chromeのセキュリティ脆弱性を明確に記述しているかの確認）、再現（実証コードの有無を確認し、影響するOSとブラウザのバージョンで実際に試して、スタックトレースなどを添付する）、メタデータの付与（バグが混入した時期や深刻度の評価を加える）、そして自動割り当て（正しいコンポーネントと人間の担当者へ振り分ける）です。
深刻度の指針そのものも、自動で適用しやすいように明確化したと書かれています。ただし開発者が評価を修正できる余地は残しており、SECURITY.md で文脈を足せる点も維持されています。
自動トリアージの4工程（公式解説による）
Historically, triaging a single security report took anywhere from 5 to 30 or more minutes, and relied primarily on human expertise. We have been increasingly shifting our triage process towards an automated approach that blends rule-based systems with AI to increase throughput and accuracy. ／ The automated triage process is broken down into four key phases: ／ Filtering out the noise. The system checks if an incoming bug is spam, ensures it meets intake criteria (e.g. is not a duplicate), and verifies that it clearly describes a Chrome security vulnerability. ／ Reproducing bugs. Next, the system checks for a proof of concept. Reproducible bugs are tested on the specific operating system and browser versions they affect. Based on this, the system attaches further details such as stack traces to the bug to help inform the fix. ／ Enriching the report with metadata. The system adds essential metadata to the report, such as when the bug was first introduced and its severity rating. To help this process scale, we’ve made our severity guidelines clearer and easier to apply automatically. We continue to allow developers to modify the severity rating if they believe it is incorrect, and to add context to help models reason about security boundaries using SECURITY.md files. ／ Automatic assigning. The system automatically routes the issue to the correct component and human owner. ／ While it's hard to measure precisely, we estimate that this new process is saving hundreds of hours of developer time per month, allowing our team to focus on other security priorities. — 従来の所要時間、自動トリアージの4工程、自動化による節約規模に関する記述より
修正案を出す役と、それを批評する役を分けた
修正側は多エージェント構成です。まず対象の課題から文脈を取り込む準備をしたうえで、修正役のエージェントが複数の修正候補を返します。次に批評役のエージェントが、どれが最も適合するかを評価し、開発者が判断するための材料も一緒に出します。
この2者は、通常のコードレビューを模したループで動きます。コードが機能として正しいことに加えて、ChromiumとGoogleのスタイルガイド、それにその場のコード規約に沿っているかまで見る設計です。
さらにテスト作成役のエージェントが、修正に対するテストを書きます。Chromeが対応する全プラットフォームと構成でテストが通ることを、開発者がレビューする前に確認できるため、最大で数週間の開発者時間を節約できるとされています。
複数の修正候補を並べて比べる作業は、結局のところ差分を読む作業です。手元でも同じことをやるなら、差分表示のツールを使うと目視の見落としが減ります。
無料ツールテキスト差分比較2つのテキストの差分をハイライト表示。変更点を素早く発見できます。今すぐ使ってみる →
After initial build steps that bring in context from a specific issue, we run a fixing agent that returns multiple candidate fixes. ／ A critic agent then evaluates which would be the best fit, producing other relevant artifacts for developers to evaluate the fix. ／ The fixing and critic agents work in a loop that mimics a typical code review process to ensure that code is functional and compliant with Chromium and Google style guidelines, as well as other local code conventions. ／ Test-writing agents help write tests for fixes. These agents can ensure that tests work across the full array of Chrome supported platforms and configurations before a developer reviews the fix, saving up to weeks of developer time. — 修正役・批評役・テスト作成役の多エージェント構成に関する記述より
直近2バージョンで1072件——過去23バージョンの合計を超えた
結果として示されているのが冒頭の数字です。この時点で、大半の脆弱性についてLLMが修正候補を生成しているとされ、直近のChromeリリースでセキュリティ修正の速度が劇的に上がったと書かれています。
直近2つのマイルストーンであるChrome 149と150で、修正したセキュリティバグは1072件。その前の23マイルストーンで修正した合計を上回る数です。
継続的インテグレーション（コードの変更ごとに自動でビルドと検査を回す仕組み）への組み込みも進んでいます。Big SleepとCodeMenderはCIに直接統合され、24時間ごとに全てのコード変更に対して動いています。5月だけで20件を超える脆弱性が本番へ到達する前に食い止められ、その中には重大（critical）と位置づけられたS1+の問題も含まれていたとされています。
なお外部研究者からの報告も増えています。2026年初頭にあらゆる分類の報告が徐々に増え、3月までに2025年の1年間を超える件数が寄せられました。これを受けてGoogleは報奨金制度（VRP）を見直し、社内で見つけているものに上乗せとなる報告へ研究者の焦点を移す方向へ変えています。
At this point, we have LLMs generating candidate fixes for most vulnerabilities, dramatically increasing the rate of security fixes in recent Chrome releases: ／ In the last two milestones, Chrome 149 and 150, we have fixed 1072 security bugs, surpassing the total number of security bugs fixed across the prior 23 milestones combined. ／ We have partnered closely with Google DeepMind and Project Zero for years, including on BigSleep and CodeMender. These tools are natively integrated into our continuous integration (CI) system, running every 24 hours across all CLs to proactively detect security bugs. This integration has yielded significant results: in May alone, we blocked over 20 vulnerabilities from reaching production, including a critical S1+ issue. ／ In early 2026, we saw a gradual increase in all categories of bug reports, but by March, the shift was apparent: we received more bug reports than we had in the entirety of 2025. This led us to change our VRP to focus researchers on bug submissions that are additive to what we are finding internally, and easily ingestible by our newly automated processing pipelines. — 修正件数、CIへの統合による実績、外部報告の増加とVRPの見直しに関する記述より
直したあと、届くまでが新しい弱点になる
修正が速くなると、次のボトルネックが浮かび上がります。発表の後半は、そこに紙幅が割かれています。
直した瞬間に、攻撃側へヒントが渡る
修正がオープンソースのコードベースに反映されて公開されると、その修正が利用者の手元に届く前に、攻撃側は差分を解析して悪用を組み立てられます。これが「N-day攻撃」と呼ばれるもので、この時間差は「パッチギャップ」として知られています。
開発本流（メインツリー）に入った修正がChromeの安定版へ届くには通常数週間かかるため、この差を縮めることが戦略上重要になる、と説明されています。深刻度に応じて、修正は開発本流から稼働中の安定版ブランチへ直接取り込まれ、新たなクラッシュや退行が起きないか継続的に監視されています。
配信の頻度そのものも上げています。主要マイルストーンを2週間ごとに出す移行を進め、セキュリティ更新は週次で提供中です。そのうえで、AIを使った攻撃の速さに対応するには足りないとして、週2回のセキュリティリリースへの移行を試験的に始めています。
Once a fix has landed and is visible in the public open source codebase, attackers can start to reverse engineer and exploit the bug before the fix reaches users’ machines — so called "N-day" attacks. This is commonly referred to as the “patch gap.” Since fixes committed to the main “tree” typically take weeks to reach the Chrome Stable channel (what the vast majority of our users run), minimizing this patch gap is a critical part of our strategy. ／ Based on their severity, security fixes are merged directly from the main “tree” into the active Chrome stable release branch, which is continuously monitored to prevent new crashes or regressions. ／ We are in the process of transitioning to a two-week cadence for major Chrome milestones, with weekly security updates. However, in the face of fast-moving, AI-powered attacks, our delivery cadence must accelerate even further. To meet this moment, we are piloting a shift to two security releases per week. — パッチギャップの説明と、配信頻度の引き上げに関する記述より
最後に残るのは「利用者が再起動しない」時間
配信が速くなっても、最後の関門が残ります。Chromeは2008年に静かな背景更新を先駆けて導入し、新しいバイナリは利用者の操作をほとんど必要とせずに自動でダウンロードされ、ディスク上に置かれます。次にブラウザを再起動したときに適用される仕組みです。
問題はそこです。トリアージ・修正・テスト・リリースに1〜2日しかかからないのに対して、利用者が再起動するのを待つ時間はN-day攻撃の危険に大きく効いてしまいます。再起動を後回しにする理由は誰にでもあります。作業が中断され、都合のいい時間を選ぶ必要があり、そもそも最優先事項になりにくいからです。
そこで進めているのが動的パッチです。ほとんどの場合にブラウザの完全な再起動を不要にするもので、Chromeが複数のプロセスで動く構造を利用して、レンダラーやGPUといった背景の子プロセスを、更新後のバイナリへ順次差し替えていきます。
あわせて、状態をより多くローカルに保存してセッション復元を滑らかにする方法や、滑らかな復元を保証できる好機を見つけて自動で再起動する方法も探られています。Chrome 150では、macOSで全てのウィンドウを閉じてもアプリが背景で動き続ける性質を利用し、ウィンドウが無い状態で保留中の更新を検知したら自動で再起動する変更が展開されました。
In 2008, Chrome pioneered the concept of silent, background software updates: new binaries are automatically downloaded and staged on disk with minimal user intervention. At the next restart of the browser, the update would be applied and the user would be protected. ／ However, compared to the 1–2 days it takes for triage, fix, test and release, the time spent waiting for the user to restart Chrome can be a significant contributor to N-day exploitation risk. ／ Investing in "dynamic patching" that will eliminate the need for a full browser restart in most cases. By leveraging Chrome’s multi-process architecture, dynamic patching sequentially replaces background child processes (like the Renderer and GPU) with updated binaries on the fly. ／ For example, in Chrome 150, we rolled out a change to take advantage of the unique application state on macOS where applications typically continue running in the background even after all windows are closed. Now, if Chrome detects a pending update while in this windowless state, it automatically restarts. — 静かな背景更新の導入、再起動待ちの危険性、動的パッチと自動再起動の取り組みに関する記述より
まとめ：Chromeの脆弱性対応でAIが変えたのは「探す速さ」だけではなかった
今回の公表で目を引くのは1072件という数字ですが、仕組みとして読むと、変わったのは発見だけではありません。仕分け、修正候補の生成、テストの作成、配信の頻度、そして再起動の待ち時間まで、工程のすべてが同時に押し上げられています。発見だけを速くしても、後工程が詰まれば意味が無いという判断が見て取れます。
もうひとつ押さえておきたいのが、AIが出しているのは修正の候補までで、採否は人間が決めているという点です。修正役と批評役を分け、コードレビューを模したループに通し、テストを先に書かせてから開発者に渡す。自動化されているのは判断そのものではなく、判断に必要な材料を揃える工程のほうです。
同時期にDeepSeekがコーディング特化のモデルを公開し、Copilotを狙う自己増殖型のプロンプト攻撃も報告されています。AIがコードを書き、AIがコードを直し、AIを狙う攻撃が同じ場所で走っている。今回の発表は、その三つがすでに同じ現場で同居していることを示す実例です。
