GoogleのAIエージェント「PageBreak」、自社Webアプリで500件超のXSS脆弱性を発見
Googleは、製品セキュリティチームが開発した社内AIエージェント「PageBreak」が、自社のWebアプリケーションで500件を超えるクロスサイトスクリプティングの脆弱性を見つけたと明らかにした。疑わしい欠陥はすべて、AIが書いていない検証ツールが実際のペイロードで確認するため、誤検知はほぼゼロだという。

Googleは、自社のWebアプリケーションでセキュリティ上の欠陥を探す社内AIエージェント「PageBreak」の詳細を公表した。Googleのセキュリティエンジニア、ミハウ・ベントコフスキ氏が同社ブログで明らかにしたところでは、大規模に運用した結果、Googleのファーストパーティ製Webアプリで500件を超えるクロスサイトスクリプティング(XSS)の脆弱性を発見し、一部は機微なドメイン上にあった。台湾のiThomeも同じ数字を伝えている。
クロスサイトスクリプティングとは、攻撃者が他のユーザーが閲覧するWebページにJavaScriptのコードを注入できてしまう脆弱性の種類で、被害者のセッションで操作を行われるおそれがある。Webアプリで最もよく見られる欠陥の一つだ。
PageBreakが解決しようとする問題:AIのノイズ
Googleによると、大規模言語モデルでコードをスキャンする手法は脆弱性管理を一変させたが、同時にノイズも生んだ。多くのセキュリティチームは、受け取る候補報告のかなりの部分が、静的コード解析ツールとして動くモデルが生んだ未検証の仮説や誤検知で占められ、対応しきれなくなっている。同社はこれを「AI slop」と呼ぶ。本当に悪用できる欠陥と、もっともらしい幻覚を見分けることが大きな課題となり、かえって製品チームの負担が増えることも多い。
Googleによると、PageBreakは2025年11月に試験的に始まり、2026年1月に正式なプロジェクトとなった。さまざまなモデルで動作するが、利用の大半はGemini 3.1 ProやGemini 3.5 FlashなどのGeminiモデルに基づいている。
検証ツールの仕組み
設計上の要は決定論的な検証だ。エージェントが潜在的な欠陥を見つけると、その仮説をAIが書いていない専用の検証ツールに渡し、検証ツールが稼働中の環境に対して実際のペイロードを実行して悪用可能かを確かめる。未検証の候補が製品チームに送られることはない。Googleはこれにより誤検知率がほぼゼロになるとしており、iThomeもこの点を強調している。
- XSS:JavaScriptのペイロードを注入し、レンダリング環境でURLを読み込んで、注入したコードが実際に実行されるかを確認する。
- SQLインジェクション:出力や応答時間から、データベースへの問い合わせを操作できるかを確認する。
- パストラバーサル:誰でも読める場所にファイルを作り、アプリがそれを読めるかを確認する。
- リモートコード実行:遅延の発生、ファイルの書き込み、外部へのDNS・HTTP要求などの手法を試す。
- サーバーサイドリクエストフォージェリ:アプリが内部サービスへの要求を出すかを検知する。
Googleは、検証ツールがまだすべての脆弱性の種類や複雑なシナリオを網羅できておらず、見逃しのリスクがあることを認めている。そのため未検証の発見は社内にとどめられ、次回以降のスキャンでより深く調べる起点になり、新しい検証ツールが必要な分野を示す。エージェントは、発見を確認するのにどんな能力や権限が足りなかったかも報告する。
人間が見落としていた欠陥
iThomeによると、GoogleはPageBreakが見つけた深刻度の高い3件の事例も公表した。いずれも、以前にGoogleのセキュリティエンジニアや外部の脆弱性研究者が調べていながら見つからなかったものだ。その一つでは、エージェントがadmin.google.comでXSSを見つけたが、悪用するには要求に有効な署名が必要だった。エージェントは続いて、悪意ある内容を含むパラメーターにアプリが有効な署名を生成してしまう別のエンドポイントを見つけ、署名による保護を回避する攻撃用URLを作れることを示した。Googleは、こうした事例は言語モデルが複数の段階を経て初めて悪用できる脆弱性を見つけられるようになりつつあることを示すとしている。
Googleは、これらの攻撃の技術的な詳細をBug Huntersブログの関連記事で公開した。同社によると、そこにはサービスの設定ミスが原因の複雑なキャッシュポイズニングの欠陥や、エージェントが完全に自力で暗号による保護を回避した事例が含まれる。これらの例は、従来のスキャナーがすでに検出できる単純な注入パターンを超えている点で重要だ。
Googleによると、エージェントはGoogle特有の利点も生かした。数十億行のコードを収めた単一のリポジトリ、実際のHTTP通信をソースコードの行に結びつけるセキュリティシグナル、そしてほぼすべてのGoogle製Webアプリに認証できる既存のスキャナーだ。成功の確率を高めるため、Googleは同じシードでエージェントを何度も繰り返し実行している。
「設計段階からの安全」を備えたフレームワークの効果
最も目を引く結果は、悪用可能なWeb脆弱性を初期状態で排除するよう設計されたGoogleの高保証Webフレームワーク上で作られたアプリに関するものだ。Googleによると、2026年9月4日時点で、PageBreakがこれらのフレームワークで作られた数百のアプリから見つけたXSSは2件だけで、いずれも社内アプリか、強化が不十分なデバッグ用エンドポイントに限られていた。検証済みであっても報告の量はかつてないほど多いため、PageBreakは自動修正を生成するCodeMenderなど他のエージェントと連携しており、最終的には製品チームの役割を提案された修正の確認だけにすることを目指している。
日本企業にとっての意味
AIが生成した脆弱性報告を受け取るようになったソフトウェア企業や社内のセキュリティチームにとって、Googleのやり方は実践的な原則を示している。決定論的なテストで攻撃を再現できるまでは、モデルの疑いだけで動かないことだ。フレームワークの結果も同じように役立つ。自動化された攻撃者に耐える最も安上がりな方法は、欠陥を一つずつ後から探すのではなく、欠陥の種類ごと初期状態で防ぐフレームワークの上にWebアプリを構築することだ。
出典
- Agentic Hacks, Real Proofs: Inside Google's PageBreak ProjectGoogle · 2026年9月24日
- Google AI代理PageBreak找出自家Web應用程式逾500個XSS漏洞iThome · 2026年9月25日



