AIが6月のたった1か月で2年分のChromeバグを直した方法 — 1,072という数字の読み方

はじめに — 1,072 対 1,036
系譜 — 2023年のファズターゲット生成から2026年のエージェントハーネスまで
なぜ巨大なC++コードベースのメモリ安全性バグなのか
この数字が語ること、語らないこと
ボトルネックは発見から配備へ移った
Chrome規模ではないチームが実際にコピーできること
おわりに — 多く見つかったということは、ずっとそこにあったということ
参考資料

はじめに — 1,072 対 1,036

2026年7月30日、GoogleがStronger with every updateというタイトルのセキュリティブログを公開しました。核となる数字は二つです。6月にリリースされたChrome 149と150、たった二つのマイルストーンで修正されたセキュリティバグが1,072件。その前の2年間、23のマイルストーンで修正されたのが1,036件です。

そしてそのうちの一つは、侵害されたレンダラーがブラウザを騙してローカルファイルを読み取らせるサンドボックスエスケープで、13年以上コードベースに潜み続けていたバグでした。Chromeのエンジニアリングディレクターを務めるDoug Turner氏はTechCrunchに対して、「Geminiのようなモデルを適用して脆弱性を先回りして修正しており、攻撃者より先を行っている」と語っています。

こうした数字に出会うと、二つの間違った反応が出がちです。一つはそのまま信じて「AIがセキュリティを解決した」と結論づけること、もう一つはマーケティングだと切り捨てることです。どちらも実務には何も残りません。この記事がやろうとしているのは三つです — 実際に動いているメカニズムが何か、この数字がコード品質について何を語り何を語らないか、そしてChromeの規模を持たない普通のチームがそのうち何をコピーできるかです。

系譜 — 2023年のファズターゲット生成から2026年のエージェントハーネスまで

この結果は突然出てきたものではなく、4年分の積み重ねです。Googleの発表文に載っている順番をたどるとこうなります。

2023年、ファズターゲットの作成。 Chromeのセキュリティチームが、LLMでファジングのカバレッジを広げる作業を始めます。発想は単純です — ファジングの成果はファザーではなくハーネスが決めるのに、ハーネスを手で書くのは退屈でプロジェクトごとにバラバラです。これをLLMに任せるのです。OSS-Fuzz側の公開結果を見ると、成果は具体的です。C/C++プロジェクト300以上に適用してカバレッジが30パーセント増え、272プロジェクトで37万行以上が新たにカバーされ、LLMが作ったターゲットなしには発見できなかったバグが26件出ました。そのうちの一つがOpenSSLのCVE-2024-9143で、20年間、数十万時間のファジングを耐え抜いて生き残っていた境界外読み書きでした。

この段階のループは4段階として公開されており、そのままコピーできます — 草稿のハーネスを書き、コンパイルしてコンパイルエラーをモデルが直し、実行してランタイムの問題を直し、動かし続けながらクラッシュをモデルが分類する、という流れです。

2024年、Naptime。 Project Zeroと共同で、LLMに脆弱性研究用のツール(デバッガ、コードブラウザ、実行環境)を持たせる方向に進みます。コードを「読んで推論する」側です。

2025年、Big Sleep。 DeepMindとProject Zeroの協業で、実際にV8 JavaScriptエンジンとグラフィックススタックでバグを見つけ出します。

2026年初頭、Geminiエージェントハーネス。 Chromeのコードベース全体を洗いつつ誤検知を減らすことに焦点を置いたハーネスが導入されます。発表文に書かれた設計が興味深いところです。コードを静的な状態のみで分析し、インターネットを遮断した隔離マシンで動かし、ネットワークリクエストは厳格な許可リストで捕捉します。モデルの非決定性は同じコードベースを複数回スキャンすることで相殺し、過去のCVE全件とgit履歴を知識ベースとして付与して「このプロジェクトでバグがどんな形で出ていたか」を参照させます。そして別文脈の批評エージェントが発見結果を評価します。

発見後も自動化されています。トリアージは4段階です — スパムと重複を除いてセキュリティ関連性を確認し、概念実証で再現し、導入時期や深刻度といったメタデータを埋め、担当コンポーネントのオーナーに自動的に割り当てます。修正段階でも修正エージェントと批評エージェントがコードレビューを模したループを回し、テスト作成エージェントが開発者のレビュー前にクロスプラットフォームのテストを作って付けます。Googleはこのトリアージ自動化だけで月に数百開発者時間を節約したと見積もっており、同時に「正確に測るのは難しい」という留保も自ら付けています。

なぜ巨大なC++コードベースのメモリ安全性バグなのか

この成果が再現可能かどうかを判断するには、問題そのものの性質を見る必要があります。メモリ安全性バグ狩りには、LLMにとりわけ有利な条件が四つも揃っています。

第一に、判定が機械的です。 ASan、MSan、UBSan、LeakSanitizerで計測されたバイナリでクラッシュレポートが出れば、それは議論の余地のないバグです。人間の判断は不要です。これが決定的な理由は、LLMベース自動化の最大の弱点が自分の出力を自分で評価することにあるからです。サニタイザーはモデルの外側にいる審判であり、モデルがどれほどもっともらしく言い張っても結果は変わりません。

第二に、再現ケースが安上がりです。 ファジングにおいて、バグの証拠はバイト列一つです。保存して、自動的に最小化して、そのまま回帰テストとして付けられます。ロジックバグのように「特定のアカウントが特定の時刻に特定の順序でリクエストしたとき」を記述する必要がありません。

第三に、バグの形が局所的で反復的です。 境界チェック漏れ、解放後使用、型混同は、コード数行の範囲で判別できるパターンです。しかもChromeには20年分のCVEとコミット履歴があり、「このプロジェクトでこのクラスのバグがどういう見た目をしているか」の学習材料がすでに蓄積されています。Googleが知識ベースに過去のCVEとgit履歴をまるごと入れた理由がここにあります。

第四に、攻撃対象領域が巨大です。 Chromeは世界中の信頼できない入力をすべてパースします — 画像、フォント、動画コーデック、ネットワークプロトコル、JavaScript。パーサーが多いということは、ファジングがよく効く面が多いということです。

逆に言えば、この四条件がない領域では同じ手法はうまく機能しません。権限チェック漏れ、ビジネスルール違反、サニタイザーが捕まえられない種類の競合状態、設計レベルの欠陥には機械オラクルがありません。だからこの発表を「AIがセキュリティを自動化した」と読むのは間違いです。正確な文章はこうです。機械が採点できる脆弱性クラスにおいて、探索コストが急落した。

この数字が語ること、語らないこと

1,072は本物の数字であり、意味もあります。発見され修正されたバグ一つは、攻撃者に残る足場が一つ減ったということです。ただし、この数字が何の指標なのかは正確に押さえておく必要があります。これは発見率の指標であって、欠陥密度の指標ではありません。

この発表にある数字	この発表にない数字
Chrome 149・150での修正1,072件	深刻度分布(致命的・高・中の割合)
直前2年・23マイルストーン合計1,036件	AIが見つけたものと人間・外部報告の比率
13年物のサンドボックスエスケープ1件	自動生成パッチの取り消し(revert)率
5月にプロダクション到達前にブロックされた20件以上(致命的1件含む)	新たに混入した欠陥数に対する純減量
3月に2025年一年分より多い報告受信	誤検知率とそのレビューにかかった人的時間

この表の右列は、Hacker Newsの議論で出た指摘とぴったり重なります。最も繰り返された質問は「自動修正のうち何件が取り消され、何件が新しいバグを生んだか」であり、あるコメントは発表文が「うまくいったことは全部数え、うまくいかない可能性のあることは何も数えていない」とまとめました。Chromeチームのエンジニアがそのスレッドに答えることはありませんでした。

ここに私自身が付け加えたい方法論上の注意がもう一つあります。比較の単位はマイルストーンですが、マイルストーンの長さが変わりつつあります。 直前2年の23マイルストーンはおおよそ月1回の周期でしたが、6月には二つ出ました。しかもGoogleは同じ発表の中で、メジャーリリースを2週間周期に移し、週次のセキュリティアップデートを、さらには週2回のセキュリティリリースを試験運用すると明かしています。リリースが頻繁になれば、「マイルストーンあたりの修正件数」の分母は変わり続けます。時系列比較をしたいなら単位時間あたりに正規化した数値が必要ですが、その数値は発表文にありません。

そして最も重要な解釈が一つ。バグが多く見つかったということは、そのバグがずっとそこにあったということです。 13年物のサンドボックスエスケープがその証拠です。この発表は、Chromeのコードが6月に良くなったという根拠ではなく、これまで私たちがどれだけ見つけられずにいたかという証拠に近いものです。そして同じツールは攻撃者も使います。

ボトルネックは発見から配備へ移った

この発表で実務家にとって一番役立つ部分は、実は1,072という数字ではなく、Googleがその次に何を変えたかです。

脆弱性発見のコストが下がると、ボトルネックは即座に下流へ移動します。見つける速度が直す速度を追い越し、直す速度が配備する速度を追い越します。Chromeでは、修正がメインツリーからステーブルブランチまで流れるのに数週間かかります。発見が10倍速くなっても、この区間がそのままなら、ユーザーが守られる時点はほとんど変わりません。

だからGoogleの対応はリリースパイプライン側に集中しています — メジャー周期を2週間に短縮、週次セキュリティアップデート、週2回のセキュリティリリース試験運用、CVEとリリースノート生成の自動化(人手がボトルネックだったということです)、そして全体再起動なしでバックグラウンドプロセスを入れ替える動的パッチの研究。最後の項目についてはまだ研究段階だと自ら明かしています。

同時に構造的な防御も進み続けています。1次Chromeコードの97パーセントが厳格なunsafe-buffer警告を有効にしてコンパイルされるスパン化作業、割り当て計算へのchecked math適用、ポインタと非ポインタを分離するヒープパーティショニング、解放後使用を無力化するMiraclePtrとMiracleObject、そしてパーサー・コーデック・フォントのようなバグ密度の高い領域にRustを選別投入する計画です。ここでGoogleが正直に書き記している一文があります。ランタイムの緩和策は数年以内に収穫逓減に達すると見ているというものです。だから言語レベルの解決へと移りつつあります。

Chrome規模ではないチームが実際にコピーできること

Googleの資源を真似ることはできませんが、このパイプラインの中に安価で持ち運び可能な部分は確かにあります。順番が重要です。

1. LLMより先にサニタイザーです。 これらすべての前提は機械オラクルです。C/C++プロジェクトなら、CIにASanとUBSanビルドを一つ追加することが、どんなAIツールを付けるよりも先です。審判なしでエージェントを付けても、捕まるものはなく誤検知だけが増えます。

# オラクルから始める。これがなければ残りは意味がない。
cmake -B build-asan -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \
  -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer"
cmake --build build-asan -j

# 既存のテストをサニタイザービルドで一度動かしてみるだけでも、大抵何か出てくる
ASAN_OPTIONS=detect_leaks=1 UBSAN_OPTIONS=print_stacktrace=1 ctest --test-dir build-asan

2. モデルにバグを探させるのではなく、ハーネスを書かせましょう。 これが2023年にGoogleが実際にやったことであり、成果対コストが最も良い地点です。パーサー、デコーダー、シリアライズコードのような「バイト列を受け取る関数」を一覧にして、それぞれについてハーネスの草稿を生成させ、コンパイルエラーとランタイムエラーをモデルに直させる四段階ループを回せばよいのです。ここではモデルの出力が即座にコンパイラとファザーによって検証されるので、幻覚が生き残りにくくなります。

3. 修正よりトリアージを先に自動化しましょう。 Googleが最大の時間節約を見た場所がここです。重複除去、再現、深刻度推定、担当者割り当ては判定基準が明確なので、自動化が失敗したときの被害も小さいです。一方でパッチの自動生成は、間違えば新しいバグになるので、後から付けるのが正解です。

4. 自動パッチには回帰テストを義務づけましょう。 Chromeパイプラインのテスト作成エージェントがこの役割を担っています。パッチとテストを同じ変更にまとめ、テストがパッチなしでは失敗することを機械的に確認する段階を入れてください。これがなければ、「直したと主張するパッチ」と「実際に直したパッチ」を区別する方法がありません。

5. 批評エージェントは別文脈に置きましょう。 同じセッションで自分の出力を評価させると、確証バイアスがそのまま残ります。Googleも、先に見た大規模マイグレーションの事例も同じ構造を使っています。

6. 指標を発見件数にしないでください。 取り消し率、誤検知率、発見から配備までの時間、深刻度別分布を見てください。発見件数はツールを入れた最初の月に必ず跳ね上がり、その後は必ず落ちます。その曲線を成果として報告すると、二か月目に説明することがなくなります。

7. 配備経路も一緒に手直ししましょう。 これがChrome事例の本当の教訓です。発見を10倍にしてリリース周期をそのままにすると、増えるのはセキュリティではなく未配備パッチの在庫です。

おわりに — 多く見つかったということは、ずっとそこにあったということ

1,072は、Chromeが6月に安全になったという証拠であると同時に、そのバグがそれまでずっと生きていたという証拠でもあります。13年物のサンドボックスエスケープがその一文を最もよく要約しています。そして発見コストを下げたツールは、防御側専用ではありません。

持ち帰るべきことを三行に縮めるとこうなります。

この成果が成立した理由は、モデルが賢いからではなく、サニタイザーという機械判定オラクルがすでにそこにあったからです。オラクルのない脆弱性クラスには同じ方法は通用しません。
最も安くコピーできる部分は、バグ検知ではなくハーネス生成とトリアージ自動化です。どちらも出力が即座に機械検証されます。
発見コストが下がると、ボトルネックは配備へ下りていきます。Googleがリリース周期を2週間に縮め、動的パッチを研究している理由がそれであり、それがこの発表で最も実務的な部分です。

バグ数を成果指標にした瞬間、その指標はツールを入れた月だけ良く見えます。長く見たいなら、取り消し率と配備までの時間を数えるほうがいいでしょう。