「みなづちAI」はリンクフリーです。リンクを行う場合の許可や連絡は不要です。引用する際は、引用元の明記と該当ページへのリンクをお願いします。
Chromeの脆弱性1,072件をAIで修正。数え直したら10件合わなかった
みなづちです。
2026年7月30日、GoogleがChromeの公式セキュリティブログに1本の記事を公開しました。タイトルは「Stronger with every update: How we’re making Chrome and the web safer in the AI Era」です。
その下のリード文には「Chromeが脆弱性の発見・トリアージ・修正にAIをどう使っているか」とあります。
そこに書かれていた数字が、開発者コミュニティで大きな議論になりました。直近2バージョンで1,072件のセキュリティバグを修正し、それ以前の23バージョンの合計を上回ったという数字です。
そして、その原動力としてAIが挙げられていました。日本語圏を含む多くの記事が「Chromeの脆弱性修正の大半をAIが生成した」と報じています。
ただ、公式ブログの原文を開くと、書かれていたのは少し違う一文でした。本記事では、その差から話を始めます。
本記事では、以下のポイントから解説します。
- Googleが公表した1,072件の中身と、公開情報から積み上げると10件ずれること
- 13年間潜んでいたサンドボックス脱出をGeminiのエージェントが見つけた経緯と、4層のエージェント構成
- Google自身が2025年に公開した論文が示す、「もっともらしい修正」と「正しい修正」の差
- 同じAI時代に、curlがバグ報奨金を終了した理由と、その後に起きたこと
- 日本のブラウザ利用の7割超に関わる話として、2026年9月8日から何が変わるのか
目次
結論：Googleが公表したのは「AIが直した」ではなく「AIが修正候補を出した」だった
まず記事全体の結論からお伝えします。今回の発表で最も重要なのは、公式原文が使っている言葉が「修正」ではなく「修正の候補」だったという点です。
Googleの原文はこうです。「At this point, we have LLMs generating candidate fixes for most vulnerabilities」。日本語にすると「現時点で、我々は大半の脆弱性についてLLMに修正候補を生成させている」となります。
candidate fixes、つまり修正の候補です。最終的にマージされ、利用者のブラウザに届いたパッチのうち何%がLLM由来なのかは、公式には一切公表されていません。
この1語があるかないかで、話の意味は変わります。「AIが直した」なら成果の報告ですが、「AIが候補を出した」なら工程の一部を自動化したという報告にとどまります。
そして後述するとおり、Google自身が2025年に公開した研究論文は、AIが出した修正が「テストは通るが正解とは挙動が違う」ことのある割合を、自社のデータで測っています。
数字そのものは本物です。1,072件は公式ブログに明記されています。ただ、その1,072件の内訳、誤検知率、差し戻し率は、どこにも書かれていません。ここを押さえて読むのが、今回の発表の要点です。
筆者の視点：公式原文と報道見出しを並べて、1語が消えていることに気づいた
この発表を追う中で、自分の読み方が途中で変わった経験があります。ここではその過程を書きます。
報道の見出しを先に読み、あとから公式原文を開いて驚いた
最初にこのニュースに触れたのは、英語圏のテックメディアの見出しでした。「Googleは過去2年分を上回るChromeのバグを修正した。AIのおかげで」という趣旨の書き方でした。
その時点では、AIが自動でパッチを書いて出荷している状況を想像していました。それだけ大きな数字だったからです。
ところが公式ブログを開いて該当箇所を読むと、書かれていたのは candidate fixes でした。候補を出すところまでで、その後には批評エージェントによる選別と、開発者によるレビューが置かれています。
見出しから消えていたのはcandidate という1語だけですが、その1語が工程のどこまでをAIがやったのかを決めていました。要約の過程で最も削られやすいのは、こうした限定語なのだと改めて感じました。
1,072件を数え直したら、10件合わなかった
もうひとつ気になったのは、1,072件の中身です。何件をAIが発見し、何件をAI生成の候補で修正したのか。重大度の分布はどうか。外部の研究者からの報告は何件含まれるのか。
公式ブログにはグラフが1枚掲載されています。ただ、元になる数表は公開されておらず、グラフから正確な値を読み取ることはできません。
そこで、公開されているリリースノートから積み上げてみました。結果は後の章に書きますが、どう数えても1,072件にならず、10件のずれが残りました。
誤検知率も、差し戻し率も、AI生成の修正が新たに埋め込んだバグの数も、記載がありません。公式が数字を出しているのは、うまくいった側だけです。
これは隠しているという話ではないと思います。ただ、判断に必要な分母が欠けたまま1,072件だけが流通していることは、押さえておくべきだと考えています。
Chrome 149と150で1,072件。過去23バージョンの合計を超えた数字の中身
ここで押さえておきたいのは、1,072件がどの期間の、どのバージョンの数字なのかという点です。公式リリースノートと突き合わせると、輪郭がはっきりします。
Chrome 149は429件、150は433件。合計862件だった
Googleの公式ブログには「直近2つのマイルストーン、Chrome 149と150で1,072件のセキュリティバグを修正した」と書かれています。マイルストーンとは、Chromeのメジャーバージョンのことです。
Chrome Releasesの公式ブログで各リリースを確認すると、Chrome 149がStableチャンネルに昇格したのは2026年6月2日で、この初回リリースに含まれていたセキュリティ修正は429件でした。
Chrome 150の昇格は2026年6月30日で、初回リリースの修正は433件です。両者を足すと862件になります。
公式が挙げる1,072件との差は210件です。Chromeは各バージョンの提供期間中に「stable refresh」と呼ばれる追加更新を出すため、まずそこを疑いました。
そこで実際に数えました。Chrome 149系の追加更新は6月8日に74件、11日に27件、16日に33件、23日に18件、25日に3件で計155件です。150系は7月8日に27件、14日に15件、16日に7件、21日に12件、23日に4件で計65件でした。
合わせて220件、初回リリースの862件に足すと1,082件になります。公式の1,072件とは10件ずれるため、この差は追加更新だけでは説明がつきません。1,072件が何をどう数えた数字なのかは、公開情報からは再現できない状態です。
なお、Chrome 151は2026年7月29日に370件のセキュリティ修正とともにリリースされています。1,072件が一度きりの数字ではなく、この水準が続いていることを示す材料です。
「過去23バージョンの合計を上回った」の比較対象は公表されていない
公式ブログのもう一つの主張は「それ以前の23マイルストーンの合計を上回った」というものです。ここで気をつけたいのは、その23バージョンで実際に何件修正されたのかを、Googleが書いていない点です。
一部の報道は「1,036件」という具体的な数字を出し、期間を「過去2年間」としています。ただ、この数字と期間はGoogleの公式ブログ本文には存在しません。
同様に「6月に修正した」という時期の書き方も、公式ブログにはありません。Chrome 150の昇格が6月30日であることは公式リリースノートで確認できますが、ブログ自身は月を書いていないのです。
比較の分母が示されていないため、「何倍になったのか」を正確に計算することはできません。言えるのは、公式が「上回った」と述べていることまでです。
公式が示したのはグラフだけで、元の数表は公開されていない
公式ブログには、バージョンごとの修正件数を示す棒グラフと、そのうち社内で発見した分を示す折れ線が掲載されています。視覚的には、直近数バージョンで急カーブを描いて増えていることが分かります。
ただし、グラフの元データは数表としては公開されていません。各バージョンが何件だったのか、社内発見分が何件だったのかを、正確な数字として引用することはできない状態です。
Googleは記事の結論部分で「発見され修正されるバグが増えることは失敗の兆候ではない」と先回りして述べています。攻撃者の足がかりが一つ減ったという意味だ、という主張です。
この主張自体には理があります。ただ、それを検証するための内訳が同時に示されていないという構造は、記事を読むうえで頭に置いておく必要があります。
13年間眠っていたサンドボックス脱出を、Geminiのエージェントが掘り出した
この発表で最も具体的な成果として挙げられているのが、1件のバグの発見です。数字よりも、この事例のほうが手法の有効性を示しています。
侵害されたレンダラーがローカルファイルを読む、13年もののバグ
公式ブログによると、2026年初頭に構築したGeminiベースのエージェントが見つけたのは、サンドボックス脱出と呼ばれる種類の脆弱性でした。
サンドボックスは、ブラウザがウェブページを表示する部分を、パソコンの他の部分から隔離する仕組みです。悪意のあるページを開いても、そこから端末のファイルには手が届かないようにする壁だと考えてください。
見つかったのは、この壁を回り込む経路でした。原文には「侵害されたレンダラーが、ブラウザを騙してローカルファイルを読み取らせる」と書かれています。レンダラーとは、ページを描画する担当のプロセスです。
そしてGoogleはこう続けています。「13年以上、我々のコードベースに静かに生き延びていたバグだ」。感嘆符付きで書かれており、社内での驚きが伝わる書き方になっています。
なお、このバグのCVE番号や技術的詳細は公表されていません。公式ブログからリンクされているバグトラッカーのページは非公開で、外部からは開けない状態です。
ファジングにも人間のレビューにも、13年間見つけられなかった
この事例が示すのは、AIの能力の高さだけではありません。従来の手法が13年にわたって見落とし続けたという事実のほうが、実は重い意味を持っています。
Chromeは世界で最も攻撃対象になっているソフトウェアの一つです。Googleは自社のファジング基盤を持ち、外部研究者向けの報奨金制度も長く運営してきました。
ファジングとは、プログラムに大量のでたらめな入力を与えて異常を探す自動テスト手法です。Chromeはこれを大規模に回してきました。それでも、この経路は残っていたことになります。
Google自身は、AIによる脆弱性検出を既存の仕組みを「補完するもの」と位置づけています。原文は「AI-powered vulnerability detection complements our existing security testing infrastructure」です。
離れた場所にあるコードどうしの長距離の相互作用から生じるバグには、引き続きファジングが有効だとも述べています。役割分担が変わったのであって、置き換えではないという整理です。
NaptimeからBig Sleepへ。2024年に始まった取り組み
公式ブログには、GoogleのAI活用の年表が短く書かれています。2023年にLLMでファジングの範囲と性能を高める手法を開発、2024年にProject ZeroとNaptimeで協業、2025年にDeepMindとProject ZeroでBig Sleepに取り組んだ、という流れです。
この年表を一次情報で補足しておきます。Project Zeroの公式ブログによると、Naptimeの公開は2024年6月20日、Big Sleepの公開は2024年11月1日です。
つまりBig Sleep自体は2024年11月に公表されています。公式ブログが「2025年」と書いているのは、ChromeセキュリティチームがBig Sleepと協業し、V8エンジンやグラフィックス周りのバグ発見に至った年を指しているとみられます。
2025年7月15日にGoogleが発表したのは、Big SleepがSQLiteの脆弱性を実際の攻撃に使われる前に発見したという成果でした。発表したのは、GoogleおよびAlphabetのGlobal Affairs担当プレジデントを務めるケント・ウォーカー氏です。
同氏は「AIエージェントが、実環境での脆弱性悪用の試みを直接阻止した最初の事例だと考えている」と述べています。手法として形になるまでに、2年以上の積み重ねがあったことになります。
発見・トリアージ・修正・テスト。Chromeが公開した4層のエージェント構成
この点について端的に言えば、Googleが公開したのは単一のAIツールではなく、役割の違う複数のエージェントを組み合わせた工程です。どこまでをAIがやっているのかは、この構成を見ると分かります。
トリアージは4段階。1件5〜30分の作業を月数百時間分減らしたと推計
トリアージとは、報告されたバグを仕分けする作業のことです。公式ブログは、この工程を4つのフェーズに分けて説明しています。
1つ目はノイズの除去で、スパムや重複を弾き、Chromeのセキュリティ脆弱性を明確に記述しているかを確認します。2つ目は再現で、実証コードを確認し、影響するOSとバージョンでテストします。
3つ目はメタデータの付与で、バグが混入した時期や重大度を割り当てます。4つ目は自動割り当てで、正しいコンポーネントと担当者へ振り分けます。手法はルールベースとAIを混ぜた方式だとされています。
効果については、従来は1件のトリアージに5分から30分以上かかっていたものが、月あたり数百時間の開発者の時間を節約していると書かれています。
ただしGoogleは、この数字について「正確に測るのは難しいが、そう見積もっている」と自ら注記しています。実測値ではなく推計であることを明示している点は、公平な書き方だと感じました。
修正と批評のエージェントが、コードレビューを模したループを回す
修正の工程はさらに具体的です。まず修正エージェントが、1つのバグに対して複数の修正候補を返します。次に批評エージェントが、そのうちどれが最適かを評価します。
公式原文には「修正エージェントと批評エージェントは、典型的なコードレビューの過程を模したループの中で動く」と書かれています。目的は、コードが機能し、Chromiumとgoogleのスタイル規約や現地のコード慣習に沿っていることを確かめることです。
その後、テスト作成エージェントがChromeの各プラットフォーム向けのテストを書きます。そして最後に、開発者が修正をレビューするという順序になっています。
批評エージェントは、開発者が修正を評価するための材料も生成すると書かれています。つまりAIは人間を置き換えるのではなく、人間が判断する手前までを担う構図として説明されています。
Googleは工程全体について「我々は一貫してマルチエージェントのワークフローに依存している」と書いています。単発のモデル呼び出しではなく、役割分担を持った複数のエージェントによる工程だという整理です。
モデルを無制限モードで動かさない。Googleが自ら課したガードレール
見落とされがちですが、公式ブログにはAIの動作環境に関する制約も具体的に書かれています。ソースコードは「厳密に静止状態で」解析し、汎用のインターネット接続を持たないロックダウンされたマシンで動かすとされています。
内部スキャン専用の環境では、すべてのネットワーク要求を傍受し、発信元と宛先に基づく厳格な許可リストで制御して、疑わしいモデルの動きを遮断します。
そして原文にはこう書かれています。「we never run models in an unrestricted mode」。モデルを無制限モードで実行することは決してないという宣言です。
サブエージェントによるローカルシステムの改変や、指定されたソースコードのディレクトリ外へのファイルアクセスも厳しく制限されているとされています。
この記述が入っている理由は、直近の業界の出来事を考えると理解しやすくなります。2026年7月には、AI企業の評価環境からモデルの行動が外部の実システムにまで及んだ事例が、相次いで公表されていました。
OpenAIは7月21日に、隔離環境をゼロデイ脆弱性で突破したモデルがHugging Faceの本番インフラに到達したと公表しました。
Anthropicは7月30日に、第三者の評価環境の設定の行き違いでClaudeがインターネットに到達し、3組織の実システムに不正アクセスしたと公表しています。いずれもモデルそのものが流出したわけではありません。
Googleが1,072件について公表していない数字。誤検知率も差し戻し率もない
この問題の核心は、成功側の数字だけが示され、判断に必要な分母が示されていないところにあります。批判の多くはこの1点に集中しました。
誤検知率、差し戻し率、新規に埋め込んだバグの数がどこにもない
公式ブログが数字で示しているのは、修正件数1,072件、5月だけで20件超の脆弱性を本番到達前に阻止したこと、Chromeの一次コードの97%が厳格なバッファ警告のもとでクリーンにコンパイルされること、といった項目です。
なお阻止の件数について、原文に年の記載はなく、文脈上2026年5月とみられます。これはBig SleepとCodeMenderを継続的インテグレーションに組み込み、24時間ごとに全変更を走査した成果とされています。
一方で書かれていないのは、AIが出した修正候補のうち何件が採用され、何件が却下されたのかという比率です。
AI生成の修正が原因で差し戻し（revert）が発生した件数も、AI生成の修正が新たに埋め込んでしまったバグの件数も、記載がありません。
1,072件の重大度別の分布もありません。深刻なものが何件で、軽微なものが何件だったのかが分からないため、件数だけでは防御力の変化を評価できない状態です。
そして前章で見たとおり、公開情報から積み上げると1,082件になり、公式の1,072件と10件ずれます。分母どころか、分子の数え方も外部からは再現できません。
外部の研究者からの報告が何件含まれるのかも示されていません。社内発見分と外部報告分の比率は、グラフの折れ線から傾向は読めますが、数字としては公開されていません。
Hacker Newsの約490コメントで最も繰り返された問い
この発表は2026年7月31日にHacker Newsへ投稿され、8月1日時点で約480ポイント、約490件のコメントが集まる大きな議論になりました。
批判側で最も繰り返されたのは、次のような問いでした。「それらの自動修正のうち、何件が差し戻されたのか。何件が新しいバグを生んだのか」。
ほかにも、AIが「発見」したのか「修正」したのかが区別されていない、AIでバグを修正せよという社内目標が立った結果、古くて簡単なバグをまとめて処理しただけではないか、といった見方が出ていました。
軽微なバグ1,000件と、重大な遠隔コード実行1件では意味が違う、という指摘もありました。件数を成果指標にすること自体への疑問です。
一方で、擁護側の論拠も具体的でした。ブラウザへの攻撃は複数の脆弱性を連鎖させて初めて成立するため、連鎖のどれか一つを潰せば攻撃全体が成り立たなくなるという理屈です。
なお、これらはいずれも匿名の投稿によるものです。氏名と現職を明かしたセキュリティ研究者による評価は、発表から2日という時点では見当たりませんでした。
Google Project Zeroは、この話題に触れていない
補足として、社内の別チームの動きにも触れておきます。GoogleにはProject Zeroという著名な脆弱性研究チームがあり、公式ブログで研究成果を公開しています。
このブログを確認すると、2025年8月から2026年5月までの公開記事の中に、AI・LLM・自動パッチ生成を主題とした投稿が1本もありません。
確認できた2026年の記事は、いずれも従来型のエクスプロイト解析、ファジング、API解析に関するものでした。Big Sleepの共同開発者であるチームが、この話題について公式ブログでは書いていない状態です。
これをもって社内に不一致があると読むのは行き過ぎです。単に担当が違うだけかもしれません。ただ、Chromeチームの発表を評価する際の材料としては、記録しておく価値があると考えています。
Google自身の論文が示す差。20回試して正解に届いたのはバグの43%だった
ここでのポイントは、AIが出す修正候補の精度について、Google自身がすでに数字を出しているということです。今回の発表を読むうえで、最も重要な補助線になります。
Passerine論文：20回試行して正解が出たのは43%
2025年1月13日、Googleの研究者らがarXivに「Evaluating Agent-based Program Repair at Google」という論文を投稿しています。著者はパット・ロンドン氏ら、いずれもGoogleの所属です。
この研究は、Google社内のバグトラッカーから178件のバグを選び、エージェント型の自動修復システムPasserineで修正を試みたものです。178件の内訳は、人間が報告したものが78件、機械が報告したものが100件でした。
数字の読み方に注意が要ります。使われたモデルはGemini 1.5 Proで、1つのバグにつき20回試行し、そのうち1本でも条件を満たせば成功と数える方式です。1回で当たる確率ではありません。
その前提で、機械が報告したバグでは73%について「テストを通る修正」が少なくとも1本生成されました。しかし正解と意味的に等価な修正まで含まれていたのは43%です。
人間が報告したバグでは、テストを通る修正が出たのが25.6%、意味的に等価な修正が含まれていたのが17.9%でした。人間が報告するバグのほうが難しいという傾向も読み取れます。
ここで重要なのは、テストを通る修正が出たバグのうち、正解と等価なところまで届いたのは6割弱だったという点です。20回も試したうえで、この差が残ります。テストが通ることと正しく直っていることは別だという事実を、Google自身のデータが示しています。
SWE-benchの検証では解決率が6.2ポイント水増しされていた
同じ問題を、社外の研究者が別の角度から測っています。2025年3月に投稿された「Are “Solved Issues” in SWE-bench Really Solved Correctly?」という論文です。
SWE-benchは、AIがソフトウェアの課題をどれだけ解けるかを測る有名なベンチマークです。この研究は、そこで「解けた」とされたパッチを、差分テストという手法で検証しました。
結果は次のとおりです。全パッチの7.8%は開発者が書いたテストに落ちるのに正解として数えられていました。もっともらしいとされたパッチのうち29.6%は、正解のパッチと異なる挙動を示しました。
さらに、挙動が食い違ったパッチを人手で精査すると、28.6%は明確に誤りだったとされています。これらを合わせると、報告されている解決率は絶対値で6.2ポイント水増しされていると結論づけられています。
つまり「テストが通った」という基準は、AIの修正精度を測る指標としては甘いということです。Googleの工程にもテスト作成エージェントが組み込まれていますが、この論点は残ります。
セキュリティパッチでは完全に正しいのは24.8%という報告も
さらにセキュリティに特化した検証もあります。2026年3月10日に投稿されたプレプリントで、ドイツのパッサウ大学に所属するアミール・アル＝マーマリ氏によるものです。
この研究は、Java の脆弱性を集めたVul4Jというベンチマークの64件に対し、Gemini 3.0 Flashが生成した319件のセキュリティパッチを評価しました。
結果は、完全に正しかったのは24.8%のみ、51.4%はセキュリティと機能性の両方で不合格というものです。著者が定義した指標では、機能を壊さない度合いが平均0.832だったのに対し、セキュリティを直せた度合いは平均0.251でした。
「機能は壊さないが、セキュリティは直っていない」という失敗の形が、数字として出ていることになります。主な原因は意味理解の誤りで、構文的には妥当なコードを書きながら、誤った修復方針を適用してしまうと分析されています。
ただしこの論文は単著のプレプリントで、査読を経ているかは確認できていません。論文内でモデル名の表記に揺れがあり、序論では2.0 Flashと書かれている点も付け加えておきます。ここでは実験の記述に従いました。
数字の扱いには注意が必要です。それでも、Googleの論文とSWE-benchの検証と合わせて読むと、方向性は一致しています。
curlは逆の道を選んだ。2026年1月に報奨金を終了し、質だけが戻った
この点の結論を先に言えば、同じAI時代のセキュリティでありながら、Googleとオープンソースのメンテナでは対応がまったく逆方向に振れたということです。
2019年からの7年で87件、10万ドル超を支払った
curlは、インターネット上のデータ転送に使われるソフトウェアで、世界中の機器やサービスに組み込まれています。作者でリード開発者のダニエル・ステンベルグ氏は、2026年1月26日のブログでバグ報奨金制度の終了を発表しました。
制度は2019年4月に始まり、2026年1月31日で終了しました。期間中に87件の脆弱性が確認され、報奨金は10万ドル、1ドル160円換算で約1,600万円を超えて支払われました。
終了の理由として挙げられたのは、AIが生成した低品質な報告の氾濫です。ステンベルグ氏は「AIスロップ報告の爆発と、明らかなスロップではない報告においても質が下がったこと」と書いています。
スロップは、もともと泥だまりやどろどろした液状のものを指す古い英語で、そこから残飯や液状のごみの意味に広がった語です。
AI生成の粗雑なコンテンツを指す用法は2024年に一般化しました。2025年12月にはメリアム・ウェブスターが「slop」を年間ワードに選び、「人工知能によって主に大量生産される低品質のデジタルコンテンツ」と定義しています。
数字も示されています。以前は15%を超えていた有効報告の確認率が、2025年に入って5%を下回るまで急落したとされています。
対応の負担については、半年前の2025年7月14日の記事に記載があります。報告1件ごとに3〜4人が対応にあたり、1人あたり30分、長ければ1時間から3時間を費やすというものでした。
報奨金の廃止で殺到は一度収まった。ただし4月には再び増えた
その後の経緯も追っておきます。2026年2月1日、ステンベルグ氏はベルギーで開かれたFOSDEMというオープンソースの大規模イベントで、閉会基調講演を行いました。
演題は「Open Source security in spite of AI」でした。1,500席のホールが満席になり、入りきれない人が場外に出るほどの関心を集めています。
そして2026年2月25日、同氏は方針の一部撤回を発表しました。報奨金の廃止と同時に報告の受け付け先をGitHubの機能へ移していたのですが、これを「間違いだった」と認め、3月1日から元の窓口へ戻すとしています。
このとき書かれた一文が重要です。「報奨金をやめて以来、殺到の津波は大幅に引いた」。金銭的な報酬をなくしたことが、低品質な報告の抑制に実際に効いたということです。
同時に、元の窓口へ戻すことで再び門戸を開いてしまう懸念も、自ら述べています。そしてこの懸念は、部分的に当たりました。
2026年4月22日の記事で、同氏は報告の頻度がかつてないほど高く、2025年の約2倍に達していると報告しています。ただし内訳は変わりました。有効報告の確認率が15〜16%まで戻り、AIスロップが押し寄せる前の2024年の水準に回復したのです。
つまりcurlが失ったのは報奨金制度であって、報告そのものではありません。金銭のインセンティブを外したことで、量は戻りながら質だけが改善したという結果になっています。
同じ人物が、AI解析ツールは「驚くほど誤検出が少ない」と評価している
ここで見落としてはいけないのは、ステンベルグ氏がAIそのものを否定しているわけではないという点です。
2025年10月10日、同氏は「A new breed of analyzers」という記事を書いています。そこで紹介されているのは、AIを使った解析ツールによる高品質なバグ発見でした。
ジョシュア・ロジャーズ氏がZeroPathを、スタニスラフ・フォート氏が自社のAIパイプラインを使って報告した内容は、合計400件を超える疑わしい箇所の指摘でした。最初のバッチだけで約50件のバグ修正がマージされたとされています。
同氏はこう書いています。「完全な誤検出は驚くほど少なかった」。そして「この生産的なAIの活用が、AIスロップの雪崩とほぼ同時期に起きていることは興味深い。あるAIが必ずしも他のAIと同じではないことの証明だ」とも述べています。
さらに2026年6月29日の記事では、論点をより明確にしています。「偶然見つけたのか、全行を読んで見つけたのか、AIが指摘したのかは、セキュリティチームにとってほとんど関係がない」。
問題はAIを使ったかどうかではなく、報告の質と、人間として意思疎通できるかどうかだという整理です。1月の発表から半年で、論点が動いていることが読み取れます。
AnthropicがFirefoxで22件発見。AIの脆弱性発見は業界の標準になりつつある
この点の結論を先に言えば、AIによる脆弱性発見はすでにGoogleだけの取り組みではありません。競合するブラウザでも、監査会社でも、同じ手法が使われ、同じ但し書きが付いています。
AnthropicがClaudeで6,000ファイルを走査し22件発見
2026年3月6日に公開された事例では、競合ブラウザのFirefoxでも同じ手法が使われています。ただし主体に注意が必要です。
これはMozillaが自社でAIを導入した話ではありません。Anthropicのフロンティア・レッドチームが自社モデルの能力評価としてFirefoxのコードを走査し、結果をMozillaへ報告した外部からの脆弱性報告です。
フロンティア・レッドチームとは、自社の最新モデルが危険な能力をどこまで持つかを実地で試す社内の検証チームを指します。つまり主目的はFirefoxを守ることではなく、モデルの能力を測ることでした。
使われたのはClaude Opus 4.6で、6,000弱のC++ファイルを走査しました。2週間で22件の脆弱性が見つかり、そのうち14件をMozillaが高深刻度と判定しています。
提出された報告は合計112件でした。ただし112件すべてが脆弱性ではありません。脆弱性と認定されたのが22件で、残りの約90件はその他のバグです。
この22件には意味づけが添えられています。2025年に修正されたFirefoxの高深刻度脆弱性の、約5分の1にあたる規模だというものです。
パッチはClaudeが「提案パッチ」として報告に添え、実際に修正を投入したのはMozillaのエンジニアでした。大半はFirefox 148で修正されています。
もうひとつ見落とせないのが、悪用の実証結果です。約4,000ドル、日本円で約64万円分のAPI利用料を投じ、数百回試行して実証に成功したのは2件だけでした。見つける能力と、実際に攻撃へ仕立てる能力には距離があるということです。
この事例に添えられた一文も引用しておきます。「AIが書いたパッチをレビューする際は、外部の作者が作った他のパッチに適用するのと同じ厳しさで臨むことを推奨する」。AI製だから特別扱いするのではなく、外部からの提案として扱えという整理です。
Trail of Bitsは週15件から週200件へ。全件を人が検証
セキュリティ監査を専門とする企業でも、同様の変化が報告されています。Trail of Bitsのダン・グイド氏は2026年3月31日の記事で、AI導入の効果を数字で示しました。
同氏によると、監査人が見つけるバグの数は週約15件から週200件へと増えました。ただしこれは全案件の平均ではなく、コードベースと調査範囲が許す特定のクライアントに限った数字です。
但し書きも付いています。「監査人が一件ずつ検証している。AIは人間なら見落としていたか、調べる時間がなかったであろうものを浮かび上がらせている」。
同社は別の指標も出しています。クライアントに報告する全バグのうち、約20%が何らかの形でAIによる初発見だという数字です。週200件よりも、こちらのほうが実態に近いと言えます。
この構図は、Googleが公式ブログで説明している工程と同じです。AIが候補を大量に出し、人間が最終判断をする。増えているのは候補の数であって、人間の検証が不要になったわけではありません。
Google DeepMindが2025年10月6日に発表したCodeMenderというコード修復エージェントでも、同じ方針が明記されています。
発表者の一人であるラルカ・アダ・ポパ氏は、カリフォルニア大学バークレー校の准教授であり、Google DeepMindのセキュリティ・プライバシー研究の責任者を務めています。
同発表には「現時点で、CodeMenderが生成したすべてのパッチは、上流に送る前に人間の研究者がレビューしている」と書かれています。開発から6か月で72件の修正をオープンソースへ提供したという実績も示されました。
DARPAのAIサイバーチャレンジは2025年8月に決着していた
制度面の動きにも触れておきます。米国のDARPAとARPA-Hが主催したAI Cyber Challengeは、現地時間2025年8月8日、ラスベガスで開かれたDEF CON 33のメインステージで最終結果が発表されました。
優勝したのはTeam Atlantaで、ジョージア工科大学、Samsung Research、KAIST、POSTECHの合同チームです。システム名はATLANTISで、賞金は400万ドル、日本円で約6億4,000万円でした。
2位はTrail of BitsのButtercupで300万ドル、3位はTheoriで150万ドルでした。
決勝では、仕込まれた63件の合成脆弱性のうち54件、およそ86%が発見され、そのうち43件にパッチが当てられました。準決勝の発見率37%から大きく伸びています。
つまり「AIで脆弱性を見つけて直す」という発想は、2026年7月に突然現れたものではありません。競技として1年前に決着がつき、実装が各社に降りてきた段階だと理解するのが正確です。
日本のブラウザ利用の7割超が対象。2026年9月8日から更新の間隔が変わる
この話が日本の読者にどう関わるのかを整理します。結論から言えば、意識しなくても影響は届きますが、企業では準備が要ります。
Chromeが55.92%。Chromium系4つで72%を超える
StatCounterの集計によると、2026年7月時点の日本のブラウザシェアは、Chromeが55.92%、Safariが23.19%、Edgeが14.42%、Firefoxが2.84%、Braveが1.12%、Samsung Internetが0.70%です。
ここで重要なのは、Edge・Brave・Samsung InternetがChromiumという同じ土台の上で作られている点です。この4つを合わせると72.16%になり、日本のブラウザ利用の7割超が今回の取り組みの影響下にあります。
ただし引き継ぎは同時ではありません。各社がChromiumを取り込んで自社ビルドを配信するため、実際には1日から3日の時間差が出ます。Chromium 151.0.7922.71はChromeが7月29日、Braveが7月30日、Edgeが7月31日という具合です。
もうひとつ、Chromeを使っていない人の内訳も見ておきます。ChromiumベースのEdgeやBraveなどが約16%、SafariとFirefoxが約26%で、Chrome以外を選んでいる人の多数派はむしろ別のエンジンの上にいます。
修正の適用に地域差はなく、日本語環境だから遅れるということもありません。ただし配信は段階的で、Chromiumの公式ドキュメントは全利用者に行き渡るまで通常1〜2週間かかるとしています。
なお、2026年に入ってから実際に悪用が確認されたChromeのゼロデイ脆弱性は、Googleの公式リリースノートで確認できる範囲で5件あります。2月13日、3月12日、3月13日、3月31日、6月8日に、それぞれ公表されました。
2週間サイクルはChrome 153から。最初は2026年9月8日
公式ブログには「メジャーマイルストーンを2週間サイクルへ移行する過程にあり、セキュリティ更新は週次で行う」と書かれています。さらに「週2回のセキュリティリリースへの移行を試験導入している」ともあります。
ただし、いつから始まるのかはブログに書かれていません。そこでGoogleが公開しているリリーススケジュールを確認すると、具体的な日付が分かります。
Chrome 152までは4週間隔で、Stable到達は2026年8月25日です。そしてChrome 153が2026年9月8日、154が9月22日、155が10月6日と、そこから正確に14日間隔で組まれています。
つまり2週間サイクルが実際に始まるのは、Chrome 153の2026年9月8日です。7月30日のブログの時点では、まだ1本も2週間隔のバージョンは出ていませんでした。
ひとつ気になる点もあります。Chromiumの開発者向け公式ドキュメントは、2026年8月1日に確認した時点でも、新しいマイルストーンの提供間隔を4週間ごとと記述しています。
2週間ごとにメジャーバージョンを出すという記述は見当たりません。公式ブログの宣言と、実務で参照される文書の記述が揃っていない状態です。
更新の律速はGoogleではなく、利用者がブラウザを再起動するかどうか
Googleが今回の発表で強調しているのは、ボトルネックが移ったという主張です。パッチギャップという言葉で説明されています。
修正がオープンソースの公開コードに反映された時点で、攻撃者はそれを解析して悪用を始められます。一方、その修正が利用者の端末に届くまでには時間がかかります。この差がパッチギャップです。
公式ブログは、トリアージから修正、テスト、リリースまでにかかる時間を1〜2日と書いたうえで、それに比べて利用者がChromeを再起動するのを待つ時間のほうが大きな要因になりうると述べています。
対策として挙げられているのが、動的パッチという技術です。Chromeの複数プロセス構造を活かし、描画やGPUを担う子プロセスだけを更新済みのものに差し替えることで、多くの場合ブラウザ全体の再起動を不要にするという構想です。
ただしこれは研究開発中とされており、提供時期も対象プラットフォームも示されていません。現時点で利用者ができるのは、更新の通知が来たら再起動することです。
企業のIT部門向けには、3つの推奨が挙げられています。再起動を段階的に促すポリシーの適用、変更の検証が必要な環境ではExtended Stableチャンネルの利用、そして管理ツールによる組織全体のバージョン追跡です。
なお、Extended StableはWindowsとMacに限定されており、2026年8月1日時点ではChrome 150系が配信されています。2週間サイクル移行後にこのチャンネルがどうなるかは、公式に説明されていません。
AIは発見の速度を変えた。次に問われるのは、検証の速度が追いつくかどうか
今回の発表を通して見えてくるのは、脆弱性対応の工程のうち「見つける」部分が、AIによって大きく変わったという事実です。13年間見つからなかったバグが見つかり、修正件数は過去23バージョンの合計を超えました。
同時に、変わっていない部分もはっきりしました。Googleの工程では、批評エージェントの選別を経たあとに開発者のレビューが置かれています。MozillaもTrail of BitsもGoogle DeepMindも、AIの出力を人間が検証するという前提を明示しています。
そして、その検証がどれだけ必要なのかを示す数字も出ています。Google自身の論文では、20回試行しても正解に届いたのはバグの43%でした。セキュリティパッチに限った検証では、完全に正しかったのは24.8%という報告もあります。
Veracodeが2025年7月30日に公開した調査では、100を超えるLLMに80のコード生成課題を与えたところ、45%でOWASP Top 10に該当する脆弱性が混入しました。同社は「モデルの規模や訓練の高度さにかかわらず、セキュリティ性能は横ばいだった」としています。
開発者側の実感も同じ方向を向いています。2025年の大規模調査では、66%が「AIの答えはほぼ正しいが、完全には正しくない」ことを最大の不満に挙げました。
curlの事例が示したのは、この検証コストを誰が負担するのかという問題です。潤沢な人員を持つGoogleは検証を含めて工程化できましたが、少人数のオープンソースプロジェクトは受け取る側に回り、報奨金制度を畳むことになりました。
ただしcurlはその後、報告の量を保ったまま質を取り戻しています。制度を一つ手放すことで釣り合いを取り直した形で、同じ技術が体力の差をそのまま結果の差に変えたわけではありませんでした。
Googleは記事の最後を「守る側に優位が確実に残るようにしている」と締めくくっています。その主張の当否を外部から評価するには、成功件数だけでは足りません。
必要なのは、差し戻し率と、新規に混入したバグの件数です。次に見るべき数字は、1,072が2,000になるかどうかではありません。その分母が公表されるかどうかです。
まとめ：Chromeの1,072件とAIの「修正候補」をめぐる6つの要点
ここまでの内容を整理します。今回のGoogleの発表は、数字そのものより、その数字が何を測っているのかを確認することが重要でした。
- 公式原文が書いているのは「修正候補」： 出荷されたパッチの何%がLLM由来かは公表されていない
- 1,072件は数え直すと合わない： 初回429件＋433件に追加更新220件を足すと1,082件で、10件ずれる
- 13年もののサンドボックス脱出が見つかった： ファジングにも報奨金制度にも13年間見つけられなかったバグ
- Google自身の論文が精度の差を示している： 1バグにつき20回試行して正解に届いたのは43%
- curlは逆の道を選んだ： 報奨金を終了したが、4月には報告量が戻り確認率は15〜16%まで回復した
- 日本の利用者に作業は不要： Chromium系で72%以上が対象。ただし配信は段階的で、更新後の再起動は要る
AIがコードを書く場面は、すでに趣味の範囲を超えています。世界で最も使われているブラウザの安全に関わる部分にも入っています。その事実を、数字の限界も含めて正確に把握しておくことが、いま必要なことだと考えています。
よくある質問（FAQ）
Q1. 利用者として、何かする必要はありますか。
A. 特別な設定は不要です。Chromeは自動で更新をダウンロードするため、追加料金もオプトインもありません。ただし配信は段階的で、Chromiumの公式ドキュメントは全利用者に行き渡るまで通常1〜2週間かかるとしています。そのうえで、更新はブラウザを再起動して初めて適用されます。Googleは公式ブログで、トリアージから修正、テスト、リリースまでを1〜2日で回している一方、利用者が再起動するまでの待ち時間が悪用リスクの大きな要因になりうると述べています。更新の通知が出たら、その日のうちに再起動するのが最も効果的な対応です。
Q2. 修正件数が急に増えたのは、Chromeが危険になったという意味ですか。
A. Googleはそう読まれることを想定して、公式ブログで先回りして否定しています。「発見され修正されるバグが増えることは失敗の兆候ではなく、攻撃者の足がかりが一つ減ったということだ」という書き方です。ブラウザへの攻撃は複数の脆弱性を連鎖させて成立するため、連鎖のどれか一つを潰せば攻撃全体が成り立たなくなるという理屈も、擁護側から示されています。ただし1,072件の重大度別の内訳が公表されていないため、防御力がどれだけ上がったのかを外部から数値で評価することはできません。
Q3. AIが書いたパッチが原因で、新しい問題が起きることはないのですか。
A. その可能性を示す研究は複数あります。2025年に公開された大規模な調査では、GitHubの2万件超の課題を対象に、Llama 3.3 Instruct-70Bが生成したパッチから135件の新規脆弱性が確認されました。同じデータセットで開発者が書いたパッチの12件と比べて約11倍です。混入したのはOSコマンドインジェクションやパストラバーサルといった種類でした。Google自身の論文でも、テストを通った修正の一部は正解と挙動が違っていたと報告されています。ただしGoogleの工程では、批評エージェントによる選別とテスト作成エージェントの検証を経たあと、開発者がレビューする順序になっています。なおGoogleは、AI生成の修正による差し戻し件数を公表していません。
筆者より
この記事を書く過程で最も時間をかけたのは、公式ブログの原文と、それを伝える記事の見出しを一文ずつ突き合わせる作業でした。
candidate という1語が消えるだけで、読者が受け取る意味は変わります。同じことは、自分が書く記事でも起こりえます。要約は必ず何かを削る作業だからこそ、削ってはいけない語を見分ける必要があると、あらためて感じました。
もう一つ印象に残ったのは、curlのダニエル・ステンベルグ氏が半年のうちに論点を動かしていたことです。AI生成の粗雑な報告を厳しく批判した同じ人が、AIを使った解析ツールについては「驚くほど誤検出が少ない」と書いています。
技術そのものへの賛否ではなく、使い方と質の問題として扱う姿勢に、学ぶところが多くありました。
参考資料
- Google公式ブログ「Stronger with every update: How we’re making Chrome and the web safer in the AI Era」（Chrome Security Team、2026年7月30日）
- Chrome Releases（Google公式）Stable Channel Update for Desktop（2026年6月2日／6月30日／7月29日ほか各リフレッシュ）
- Chromium Dash リリーススケジュール（Google公式）
- Chromium公式開発者ドキュメント「Chrome Release Cycle」
- Google Project Zero「Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models」（2024年6月20日）
- Google Project Zero「From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code」（2024年11月1日）
- Google公式ブログ（ケント・ウォーカー氏、2025年7月15日）
- Google DeepMind「Introducing CodeMender: an AI agent for code security」（2025年10月6日）
- arXiv「Evaluating Agent-based Program Repair at Google」（パット・ロンドン氏ほか、2025年1月13日）
- arXiv「Are “Solved Issues” in SWE-bench Really Solved Correctly? An Empirical Study」（2025年3月19日）
- arXiv「Why LLMs Fail: A Failure Analysis and Partial Success Measurement for Automated Security Patch Generation」（アミール・アル＝マーマリ氏、2026年3月10日・査読状況は未確認のプレプリント）
- arXiv「How Safe Are AI-Generated Patches? A Large-scale Study on Security Risks in LLM and Agentic Automated Program Repair on SWE-bench」（2025年）
- daniel.haxx.se「The end of the curl bug-bounty」（ダニエル・ステンベルグ氏、2026年1月26日）
- daniel.haxx.se「Death by a thousand slops」（ダニエル・ステンベルグ氏、2025年7月14日）
- daniel.haxx.se「curl security moves again」（ダニエル・ステンベルグ氏、2026年2月25日）
- daniel.haxx.se 報告状況に関する記事（ダニエル・ステンベルグ氏、2026年4月22日）
- daniel.haxx.se「A new breed of analyzers」（ダニエル・ステンベルグ氏、2025年10月10日）
- daniel.haxx.se「Open Source security in spite of AI」（ダニエル・ステンベルグ氏、2026年2月3日）
- Merriam-Webster 2025年のWord of the Year「slop」（2025年12月15日）
- Anthropic「Partnering with Mozilla to improve Firefox’s security」（2026年3月6日）
- Mozilla Security Blog「Hardening Firefox with Anthropic’s Red Team」（2026年3月）
- Trail of Bits「How we made Trail of Bits AI-native (so far)」（ダン・グイド氏、2026年3月31日）
- DARPA公式「AIxCC Results」（2025年8月）
- Veracode「2025 GenAI Code Security Report」（2025年7月30日）
- Stack Overflow Developer Survey 2025（AIセクション）
- StatCounter Global Stats ブラウザシェア日本（2026年7月）
- Brave 公式リリースノート／Microsoft Edge セキュリティ更新リリースノート（2026年7月）
- Hacker News 該当スレッド（2026年7月31日投稿）
この記事が気に入ったら
フォローしてね！
お気軽にコメントどうぞ