Big Sleep ── AI エージェントが SQLite の未知の脆弱性を見つける

Big Sleep（ビッグ・スリープ） は、Google の脆弱性研究チーム Project Zero と Google DeepMind が共同で作った、ソフトウェアの未知の脆弱性を探す AI エージェントである。2024年11月1日、チームはその最初の実戦での発見を公表した。多くのアプリケーションに組み込まれているデータベース SQLite に、悪用可能なスタックバッファアンダーフローを見つけたというものだ。報告は2024年10月上旬で、SQLite の開発者は同じ日に修正した。問題のコードは正式リリースに一度も含まれなかったため、チームの言葉では SQLite の利用者に影響はなかった。

チームはこれを、広く使われる実在のソフトウェアで、AI エージェントが未知の悪用可能なメモリ安全性の欠陥を見つけた「最初の公開事例」だと考えている、と書いた。この主張には「と考えている（we believe）」と「公開された」という2つの限定が付いている。第三者が認定した記録ではなく、Google 自身の評価として読むべきものである。

何が見つかったのか

欠陥は SQLite の拡張機能 generate_series（ext/misc/series.c）の関数 seriesBestIndex にあった。SQLite は ROWID 列への制約に −1 という特別な目印を使うが、この関数はその目印を扱っていなかった。細工したクエリを与えると、スタック上の配列の範囲外に書き込みが起きる。書き込み先がバッファの先頭より手前になるため「アンダーフロー」と呼ばれる。

Project Zero の解説はリリース番号ではなくコミットの識別子で場所を示している。脆弱なコードが開発ブランチにしか存在しなかったからである。チームはこの欠陥を「おそらく悪用可能」としたうえで、見つかったのはアサーションを有効にしたデバッグビルドであり、リリースビルドではアサーションが無く、結果はコンパイラと最適化の水準によって変わるとも書いている。

なぜファジングでは見つからなかったのか

ファジング（半ば無作為な入力を大量に与えて異常を探す手法）は、メモリ安全性の欠陥を探す標準的な方法である。チームは、なぜこの欠陥がそれで見つからなかったのかを調べた。Google の OSS-Fuzz が SQLite に使っていたテスト用の枠組み（ハーネス）は generate_series 拡張を有効にせずにビルドされており、別のハーネスには影響を受けない古い版の関数が入っていた。チームが AFL を SQLite のコマンドライン版に150 CPU 時間かけて走らせても、この欠陥は見つからなかった。

結論は控えめに書かれている。チームは結果を「きわめて実験的」と呼び、対象に特化したファザーなら少なくとも同程度には脆弱性を見つけられただろうと認めた。言語モデルがファジングを追い越したという主張ではない。コードを読んで推論するエージェントは、汎用のハーネスが一度も通らない場所に届きうる、という主張である。

1件の発見から運用へ

Big Sleep は、11月の記事の題名が示すとおり、Project Zero の先行研究の枠組み Naptime から発展したものだ。2025年には、少なくとも Google の説明では、1件の概念実証が運用される道具になっていく。

2025年7月の主張は最初のものより踏み込んでいた。Google の国際問題担当プレジデント Kent Walker 名の記事は、AI エージェントが実際の攻撃での脆弱性悪用の試みを直接阻止したのはこれが初めてだと考えている、と書いた。The Record によれば、Google の脅威インテリジェンス部門は攻撃者がゼロデイ攻撃を準備している兆候をつかんだが欠陥を特定できず、同僚が Big Sleep を使ってそれを突き止めたという。Google は攻撃者の名も、つかんだ兆候の中身も明かしていない。この主張を外部から検証できる証拠は公開されていない。

8月の20件について、Google の広報担当 Kimberly Samra は TechCrunch に、報告の前には人間の専門家が確認するが、各脆弱性は AI エージェントが人の介入なしに発見・再現したと説明した。詳細は Google の開示方針に従い、修正が出るまで伏せられた。

得をした者、負担を負った者

2024年11月の発見で得をしたのは、欠陥を含む版を受け取らずに済んだ SQLite の利用者と、のちに Big Sleep の報告を受けたオープンソースのプロジェクトである。この手法は、脆弱性研究を担える者の範囲も変える。成熟したコードからメモリ安全性の欠陥を見つけるには希少な専門家が必要だったが、Google は、エージェントなら人間のチームにはできない規模でコードを調べられると位置づけた。

負担は別のところに落ちた。同じ TechCrunch の記事は、複数のプロジェクトの保守者が、AI が作った幻覚混じりのバグ報告に苦情を述べていると伝えている。AI セキュリティ企業 RunSybil の共同創業者 Vlad Ionescu は、届く報告の多くは金に見えて実はがらくただと語った。良くても悪くても、AI が生んだ報告は最後に保守者の机に載る。Google の答えは「提出前に人間の専門家を挟む」ことだったが、受け取る側のボランティアのプロジェクトには同じ緩衝材がない。より多くの欠陥を見つけることと、それを直す人々を溺れさせることの緊張は、その後2年間の主題になる。詳しくは XBOW の記事 で扱う。

攻撃と防御の問題も残る。リリース前に悪用可能な欠陥を見つける道具は、誰が動かしても同じように見つける。Google は Big Sleep を社内で運用して結果を報告し、エージェント自体は公開しなかった。能力を限定し、防御に使い、結果を公表するという同じ選択は、2026年に Anthropic が Claude Mythos Preview と Project Glasswing ではるかに大きな規模で行うことになる。

歴史の中での位置

Big Sleep が脆弱性の自動発見を発明したわけではない。ファザーや静的解析ツールは何年も前から自動で欠陥を見つけていた。2024年11月に変わったのは方法である。大規模言語モデル がソースコードを読み、仮説を立てて試すという、人間の研究者と同じやり方で探した。SQLite の欠陥は小さく、早い段階で捕まった。意味があったのは前例を作ったことのほうで、それから1年半のうちに、この分野は AI 企業とセキュリティ企業の競争の場になった。

関連する出来事は サイバーセキュリティの年表 と AI の年表 にある。共有されたオープンソースの安全性をめぐる先行の危機としては Heartbleed と Log4Shell がある。