Chromeはどうやって「AI時代」に強くなっているのか？

元記事: Stronger with every update: How we're making Chrome and the web safer in the AI Era（Google公式ブログ, 2026/7/30）

対象読者: IT業界に入ったばかりの新人でも理解できるよう、専門用語には簡単な解説を付けています。

1. なぜこの記事が重要なのか（背景）

近年、AI（大規模言語モデル＝LLM）の進化によって、攻撃者・防御者どちらの側も「脆弱性（セキュリティ上の弱点）」 を見つける速度が飛躍的に上がっています。Google Chromeチームは、この変化に対応するため、AI（Gemini）を活用して セキュリティ対応の全工程を高速化する取り組みを進めています。

用語メモ

  • 脆弱性（バグ）: ソフトウェアの欠陥のうち、攻撃者に悪用されうるもの。個人情報の窃取や端末の乗っ取りにつながる。
  • LLM（Large Language Model）: ChatGPTやGeminiのような、大量の文章データで学習されたAIモデル。

2. 「バグの一生」5つのステップ

Chromeチームは、バグが生まれてから修正が届くまでを次の5段階で捉え、各段階をできる限り高速化しようとしています。

  1. 発見（Found）: バグが見つかる
  2. トリアージ（Triaged）: バグの深刻度や担当者を判断・割り当てる
  3. 修正（Fixed）: バグを直す
  4. リリース（Released）: 修正版のChromeを配布する
  5. 適用（Applied）: ユーザーがChromeを再起動し、更新が反映される
flowchart LR
    A["① 発見
Found"] --> B["② トリアージ<br>Triaged"]
    B --> C["③ 修正<br>Fixed"]
    C --> D["④ リリース<br>Released"]
    D --> E["⑤ 適用<br>Applied"]

    style A fill:#e8f0fe,stroke:#4285f4,color:#174ea6
    style B fill:#fef7e0,stroke:#f9ab00,color:#7a5900
    style C fill:#e6f4ea,stroke:#34a853,color:#137333
    style D fill:#fce8e6,stroke:#ea4335,color:#a50e0e
    style E fill:#f3e8fd,stroke:#a142f4,color:#5b1e99

各段階の所要時間をいかに短縮するかが、Chromeのセキュリティ戦略の核心です。 以下、各ステップでのAI活用を見ていきます。

3. ステップ①：脆弱性を「見つける」

  • 2023年〜: LLMを使った「ファジング」
    （ランダムな入力を大量に試してバグを誘発させるテスト手法）の強化を開始。
  • 2024年: Naptime（Project Zeroと共同開発）で、
    LLMに専用ツールを持たせて脆弱性調査をさせる仕組みを構築。
  • 2025年: Big Sleep（DeepMind・Project Zeroと共同）というAIエージェントが、
    ブラウザの中核エンジン「V8」などから実際にバグを発見。
  • 2026年: Geminiを使った独自の「エージェントハーネス」（AIに調査させるための仕組み）を構築し
    Chrome全体のコードを効率よく調査。
    • この過程で、13年間も隠れていたサンドボックス回避バグを発見
      （サンドボックスとは、悪意あるコードが端末全体に影響しないよう隔離する仕組み）。
timeline
    title 脆弱性発見AIの進化
    2023 : LLMでファジング強化
    2024 : Naptime
　　　　　 : LLMに専用ツールを付与
    2025 : Big Sleep
　　　　　 : DeepMind・Project
　　　　　 : Zeroと共同
    2026 : Gemini製
         : エージェントハーネス
         : 全コード調査
         : 13年間隠れた
         : サンドボックス
         : 回避バグを発見

安全対策: AIは常にネット接続のない隔離環境で動作し ファイルアクセスや通信先も厳しく制限されています。 人間が想定していない挙動を防ぐ
ガードレールが設けられています。

また、外部の研究者にバグを報告してもらう**脆弱性報奨金制度（VRP）**も継続。
2026年には報告数が急増したため、
AI活用と相性の良い報告を優先する方向に制度を見直しました。

4. ステップ②：脆弱性を「トリアージ（仕分け）」する

トリアージとは、報告されたバグが「本物か」「どれくらい深刻か」「誰が対応すべきか」を判断する作業です。
従来は1件あたり人手で5〜30分以上かかっていましたが
AIとルールベースの仕組みを組み合わせて自動化を進めています。

自動トリアージは4段階：

  1. ノイズ除去: スパムや重複
    内容不明瞭な報告を除外
  2. 再現確認: 実際にバグを再現し
    影響するOS・バージョンを特定
  3. メタデータ付与: バグの深刻度や
    発生時期などの情報を自動付与
  4. 自動割り当て: 担当チーム
    担当者へ自動で振り分け
flowchart TD
    In["バグ報告が届く"] --> S1{"① ノイズ除去<br>スパム・重複でないか？"}
    S1 -- 不正な報告 --> Drop["除外・却下"]
    S1 -- 有効な報告 --> S2["② 再現確認<br>OS/バージョンを特定"]
    S2 --> S3["③ メタデータ付与<br>深刻度・発生時期を推定"]
    S3 --> S4["④ 自動割り当て<br>担当チーム/担当者へ"]
    S4 --> Out["開発者が対応開始"]

    style In fill:#e8f0fe,stroke:#4285f4
    style Out fill:#e6f4ea,stroke:#34a853
    style Drop fill:#fce8e6,stroke:#ea4335

これにより、月あたり数百時間の開発者の工数を削減できていると推定されています。

5. ステップ③：脆弱性を「修正」する

複数のAIエージェントが連携する「マルチエージェント・ワークフロー」で修正を作成します。

  • Fixingエージェント: 修正案を複数提示
  • Criticエージェント: どの修正案が最良かを評価
  • 上記2つがコードレビューのように対話しながら改善を繰り返す
  • テスト作成エージェント: 修正が様々な環境で正しく動くかのテストを自動生成
sequenceDiagram
    participant Bug as バグ情報
    participant Fix as Fixingエージェント
    participant Critic as Criticエージェント
    participant Test as テスト作成エージェント
    participant Dev as 人間の開発者

    Bug->>Fix: コンテキストを渡す
    Fix->>Fix: 複数の修正案を生成
    Fix->>Critic: 修正案を提出
    Critic->>Critic: 最良の案を評価
    Critic-->>Fix: フィードバック（レビューのように往復）
    Fix->>Test: 確定した修正案
    Test->>Test: 全プラットフォーム向けテスト生成
    Test->>Dev: 修正案＋テスト結果を提示
    Dev->>Dev: 最終レビュー・承認

結果として、Chrome 149・150の2つのリリースだけで1,072件のセキュリティバグを修正。これは、それ以前の23回のリリース分の合計を上回る数だそうです。

また、CodeMenderなどのツールをCI（継続的インテグレーション、コード変更のたびに自動テストする仕組み）に組み込み、5月だけで本番環境に届く前に20件以上の脆弱性をブロックしました。

6. ステップ④：修正を「リリース」する

修正がコードに反映されてから、実際にユーザーに届くまでの期間を**「パッチギャップ」**と呼びます。この期間が長いと、攻撃者が公開されたコードを解析して先回りで攻撃（Nデイ攻撃）できてしまうため、Chromeチームはこの期間の短縮に注力しています。

  • 主要バージョンは2週間サイクルでのリリースに移行中
  • セキュリティ更新は週2回のペースを試験導入中
  • 修正内容は内部発見・外部報告を問わず、必ず公開・文書化される
flowchart LR
    A["修正がコードに反映
(public tree)"] -->|"ここから攻撃者が
Nデイ攻撃を狙える"| B["Chrome Stableへ
マージ"]
    B --> C["ユーザーへ配信"]

    A -.->|"パッチギャップ
(できるだけ短縮したい期間)"| C

    style A fill:#fce8e6,stroke:#ea4335
    style B fill:#fef7e0,stroke:#f9ab00
    style C fill:#e6f4ea,stroke:#34a853

7. ステップ⑤：更新を「適用」する

Chromeは2008年から「サイレントアップデート」（自動でバックグラウンド更新）を導入していますが、ユーザーが再起動するまでは保護が完了しません。この「再起動待ち」の時間もリスクの一因です。

対策として：

  • ダイナミックパッチング（開発中）: ブラウザ全体を再起動しなくても、裏側のプロセス（レンダラーやGPU部分など）だけを差し替える技術
  • セッション復元の強化: 再起動してもタブなどの状態をきちんと復元できるようにする
  • タイミングを見た自動再起動: 例えばmacOSでは、ウィンドウが全て閉じてバックグラウンドで動いているだけの状態を検知し、自動的に再起動する仕組みをChrome 150で導入

企業のIT管理者向けには、以下の対策が推奨されています。

  • RelaunchNotificationポリシーで再起動を促す（最終的には強制再起動も可能）
  • 変更の少ないExtended Stable Channelの利用（更新頻度を抑えたい高セキュリティ環境向け）
  • Chrome Enterprise Core/Premiumでブラウザのバージョンを一括管理
flowchart TD
    U["更新が公開される"] --> Q{"ユーザーは
すぐ再起動する？"}
    Q -- しない --> Wait["再起動待ち
＝保護されない時間"]
    Wait --> Dyn["ダイナミックパッチング
(裏側プロセスだけ差し替え)"]
    Wait --> Auto["タイミングを見た自動再起動
(例: macOSのゼロウィンドウ検知)"]
    Dyn --> Safe["保護完了"]
    Auto --> Safe
    Q -- する --> Safe

    style Wait fill:#fce8e6,stroke:#ea4335
    style Safe fill:#e6f4ea,stroke:#34a853

8. 「治療」より「予防」：バグそのものを減らす取り組み

個別のバグ修正だけでなく、バグが生まれにくい仕組みへの投資も進めています。

メモリ安全性の強化

Chromeの大部分は**C++**という言語で書かれていますが、C++は「メモリ安全性」に弱点があります（プログラムが誤って解放済みのメモリ領域を使ってしまう「Use-After-Free」などの問題が起きやすい）。

対策の3本柱：

  • MiraclePtr / MiracleObject: メモリの誤使用を検知・防止する仕組みを、より多くのコンポーネントに拡大導入
  • Spanification（スパン化）: 配列などの範囲外アクセスを防ぐため、std::spanという安全な仕組みに置き換え（すでに社内コードの97%が対応済み）
  • 構造・割り当ての堅牢化: メモリ確保に関わる計算での「整数オーバーフロー」（数値が扱える範囲を超えてしまうバグ）を防ぐ仕組みを導入
mindmap
  root((メモリ安全性<br/>強化戦略))
    短期: C++の堅牢化
      MiraclePtr/MiracleObject
        UAFバグを最大90%抑制
      Spanification
        範囲外アクセスを防止
        97%が対応済み
      構造・割り当て堅牢化
        整数オーバーフロー対策
        ヒープの分離
    長期: Rustへの移行
      Rustフライホイール
        SDK整備
      バグ多発箇所を優先移行
        画像/フォント処理など
      高権限処理のモジュール化

メモリ安全な言語への移行（Rust）

C++の改善には限界があるため、長期的にはRustというメモリ安全性の高いプログラミング言語への移行を進めています。

  • Rustの開発基盤整備: RustからChromeの内部機能を呼び出せるSDKを整備
  • バグの多い箇所を優先的にRust化: 画像処理やフォント処理など、過去にバグが集中していた領域から着手
  • 高い権限を持つ処理のモジュール化: Rustで書くことで、安全性を保ちながら高速な処理を実現

さらに、ブラウザのUI部分をHTML/CSS/TypeScriptで実装する検討も進めています。

コードが取り込まれる前にバグを止める

CI（継続的インテグレーション）やCQ（コミットキュー：コードを本流に取り込む前の審査列）にAIモデルを組み込み、コードの変更（diff）を自動スキャン。危険なポインタ操作や数値の安全性の問題を、コードが本体に統合される前に検知します。

9. インターネット全体を守る取り組み

Chromeは自社製品だけでなく、オープンソースエコシステム全体の安全性向上にも貢献しています。

  • Alpha-Omegaプロジェクトへ1,250万ドルを寄付（OSSメンテナーへの支援）
  • Akritesプロジェクトの創設メンバーとして、脆弱性報告の一元管理を支援
  • Chromeには2,300以上の外部依存ライブラリがあり（V8、BoringSSL、Skiaなど）、うち約1,700がユーザーに届く製品に組み込まれている
  • NVD（米国政府の脆弱性データベース）やOSV（オープンソース向け脆弱性データベース）と連携した自動監視パイプラインを運用
  • 外部ライブラリを最新版へ自動更新する仕組みも導入中（安全性チェックにはGOSSIPという仕組みを利用）
flowchart TD
    Chrome["Chrome本体"] --> Deps["2,300以上の外部依存ライブラリ
(V8, BoringSSL, Skia, ANGLE, Dawn 等)"]
    Deps --> Shipped["約1,700個がユーザーに配信"]
    Feed1["NVD
(米政府DB)"] --> Pipe["自動監視・更新
パイプライン"]
    Feed2["OSV
(OSS向けDB)"] --> Pipe
    Pipe --> Deps
    Pipe --> Safety["GOSSIP
(安全性シグナル)"]
    Support1["Alpha-Omega
($12.5M支援)"] --> OSS["OSSエコシステム全体"]
    Support2["Akrites
(脆弱性報告の一元化)"] --> OSS

    style Chrome fill:#e8f0fe,stroke:#4285f4
    style OSS fill:#e6f4ea,stroke:#34a853

10. まとめ

  • AIの登場で「見つかるバグの数」は増えているが、これは失敗ではなく前進（見つかったバグ＝攻撃者の足がかりが1つ減ったということ）
  • 発見・トリアージ・修正・リリース・適用のすべての工程をAIで高速化
  • 短期的には既存言語（C++）の安全性強化、長期的にはRustなど安全な言語への移行で「バグが生まれない」仕組み作りを推進
  • Chrome単体でなく、オープンソースエコシステム全体の安全性向上にも投資

用語集（新人向け早見表）

用語 意味
脆弱性（バグ） 攻撃に悪用されうるソフトウェアの欠陥
LLM 大量のテキストで学習されたAIモデル（Gemini, ChatGPTなど）
ファジング ランダムな入力を大量に与えてバグを誘発させるテスト手法
サンドボックス 悪意あるコードの影響を隔離する仕組み
トリアージ 問題の深刻度や対応優先度を判断・仕分けする作業
CI（継続的インテグレーション） コード変更のたびに自動でビルド・テストする仕組み
Nデイ攻撃 修正が公開されてから、ユーザーに行き渡るまでの間を狙う攻撃
パッチギャップ 修正が公開されてからユーザーに適用されるまでの期間
メモリ安全性 プログラムが不正なメモリ操作（解放済み領域の使用など）を起こさない性質
Use-After-Free (UAF) 解放済みのメモリ領域を誤って使い続けてしまうバグ
Rust メモリ安全性を重視したプログラミング言語