ChromeとSQLiteの長期潜伏バグに学ぶAI検証術

POINT

  • Googleは2026年7月30日、AIエージェントがChromeに13年以上潜んでいた脆弱性を発見したと公表。直近2回の修正リリースで1,072件のセキュリティバグを直した
  • Tailscaleは16年物のSQLite内部バグに起因するデータベース破損を6カ月で19件経験し、WAL(Write-Ahead Logging)のチェックポイント処理に潜む欠陥を突き止めた
  • 読み終えると、Codex・Claude Codeに既存コードの調査を任せつつ、人が再現テストと回帰テストで検証する具体的な手順がわかる

Chromeの13年物バグとTailscaleの16年物バグ、何が起きたのか

2026年7月30日、GoogleはChromeの脆弱性対応をAIで自動化する取り組みを公式ブログで公開した。同社のAI「Gemini」を使ったエージェントが、コードベースに13年以上潜んでいた脆弱性を見つけ出した。2026年初めに構築されたこのエージェントは、バグ報告の選別、修正案の作成・評価、テスト作成までを支援し、直近2回の修正リリースだけで1,072件のセキュリティバグを解消した。過去23回分の修正を上回る数字だChromeに13年以上潜んでいた脆弱性、AIで発見

同じ頃、Tailscaleは別種の長期潜伏バグと格闘していた。2022年からSQLiteを主要データベースに使い、2023年初頭からは数分おきにスナップショットをS3へ送っていた。昨年8月、そのバックアップにSQLiteの整合性チェック機能であるPRAGMA integrity_checkをかけたところ破損が判明。以後6カ月で19件のデータベース破損が発生し、初期の停止時間は1時間を超えたTailscale Traces Database Corruption to 16y/o SQLite WAL-Reset Bug。原因は16年もの間SQLite内部に潜んでいたWALリセットのバグだった。

ChromeとTailscaleの超長期潜伏バグ 発覚と解決のプロセス
潜伏期間 13年以上 Chrome コードベース AIエージェントが発見 Chrome: AIエージェント導入によるバグ一括修正 2026年初め AIエージェント構築 ・脆弱性発見エージェント作成 ・選別 / 修正案 / テスト自動化 2026年7月30日 取り組みを公式発表 直近2回で 1,072件 修正 (過去23回分の修正数を凌駕) 潜伏期間 16年物 SQLite WAL-Reset バックアップ検証で発覚 Tailscale: 定期検証による異常検知と原因特定 2022年 SQLite採用 主要DBとして 運用を開始 2023年初頭 定期保存 数分おきにS3へ バックアップ 昨年8月 破損を検知 整合性チェック で不具合判明 以後6ヶ月 原因特定 破損19件発生後 根本解決 Chrome: 13年物バグの自動修正 潜伏期間: 13年以上 2026年初め 脆弱性発見AIエージェントを構築 バグ選別・修正案作成・テスト生成を自動化 2026年7月30日 公式発表:1,072件のバグを修正 直近2回のリリースで過去23回分を凌駕 Tailscale: 16年物SQLiteバグの特定 潜伏期間: 16年物 2022年: SQLiteを主要DBとして採用 2023年初頭: S3へ数分おきバックアップ開始 昨年8月 バックアップ整合性チェックでDB破損を検知 以後6ヶ月 破損19件発生後、根本原因を特定・解決
コード内に10年以上潜んでいた脆弱性・不具合が、AIエージェントや継続的なバックアップ検証によって発見・解決されたプロセスの対比。

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

Chromeの脆弱性もTailscaleのバグも、単発のテストでは再現しにくい条件が重なって初めて表面化する。ChromeはGeminiエージェントが人手では追いきれない量のコードパスを走査し、既存のテストがカバーしていない境界条件を洗い出した。

Tailscaleの場合、単一のGoプロセスがSQLiteファイルに単独アクセスする構成だったため、破損は「ありえないはず」の前提で長らく疑われなかった。実際にはWALファイルに実在するページ数を超えるページをコピーしてしまう不具合があった。あるトランザクションがコミットしたデータが、エラーも出さずに後続のトランザクションから消えていたのだ。SQLite開発者と専門サポート契約を結んで初めて、この挙動が技術的に裏付けられた。

AIエージェントに探索を任せ、人が再現テストに落とす手順

ChromeとTailscaleの事例に共通するのは、発見と検証を分けている点だ。AIが疑わしい箇所を大量に洗い出し、人間または別のテスト工程がそれを裏付ける。Codex・Claude Codeで既存コードの不具合を掘り起こす際も、この分業をそのまま使える。

  1. エージェントに「このモジュールの排他制御・境界条件・エラーハンドリングの抜け漏れを列挙して」と探索させる。Chromeのエージェントがバグ報告の選別からテスト作成まで担った流れに近い。
  2. 洗い出された候補ごとに、実際に壊れる手順を再現テストとして書き起こす。Tailscaleがintegrity_checkとトランザクションログで破損を裏付けたように、口頭の疑いを検証可能なコードに変換する。
  3. 修正後は再現テストをそのまま回帰テストに残す。Tailscaleが破損検知時にシャードを即時停止する監視を導入したのと同じ発想で、同じ不具合が二度目に起きたら即座に検知できる仕組みを埋め込む。

ここで人間が省いてはいけないのは検証の部分だ。エージェントの提案をそのままマージすると、疑わしいが実は無害な変更を紛れ込ませるリスクがある。再現テストが書けない指摘は保留にする、という運用ルールが要る。

導入すべき人、まだ様子見でいい人

個人〜小規模チームでCodexやClaude Codeを使い、既存コードの品質を上げたい人には向いている。Chrome規模の複雑さがなくても、境界条件の見落としや排他制御の穴は小さなコードベースにも潜む。エージェントに「怪しい箇所を挙げて」と頼むコストは低く、再現テストという形で成果を固定できるなら投資対効果は高い。

一方、まだテスト基盤が整っていないチームには向かない。エージェントが指摘した不具合候補を検証するには、再現テストを書ける土台が要る。テストコードを書く習慣がないままAIの指摘を鵜呑みにすると、Tailscaleが経験したような「エラーなしにデータが消える」類の見えないバグを見逃したまま次の変更を重ねることになる。

まとめ

AIエージェントは疑わしい箇所を大量に見つけるのが得意で、それを裏付けるのは人間の役目だ。Chromeの1,072件修正もTailscaleの19件の破損解決も、発見と検証を分けたからこそ再現性のある形で残った。既存コードにAIを向ける際は、指摘を再現テストに変換し、回帰テストとして固定する手順まで自分のワークフローに組み込んでおきたい。