大規模言語モデル（LLM）をセキュリティスキャンに応用する動きが広がる一方で、新たな課題が生まれている。AIが生成する脆弱（ぜいじゃく）性報告の相当部分が未検証の仮説や誤検知を含む「AIスロップ」（AIが生成した低品質なコンテンツ）で、セキュリティチームが対応に追われ、報告を受け取る製品チームの負担もかえって増えているという問題だ。Googleは2026年9月23日（現地時間）、公式ブログでこの課題への自社の取り組みを公開した。
社内AIエージェント「PageBreak」が500件超の脆弱性を発見
同社の製品セキュリティチームは、自社Webアプリケーションの安全性を検査する社内AIエージェント「PageBreak」を開発した。2025年11月に試験運用を始め、2026年1月に本格的なプロジェクトに移行した。大規模に運用した結果、機密性の高いドメインを含むGoogleのWebアプリケーションから、500件を超えるクロスサイトスクリプティングの脆弱性を発見したという。
ただし、AIによる脆弱性発見で問われるのは件数よりも報告の精度だ。GoogleはPageBreakの報告について「誤検知はほぼゼロ」と説明する。従来のAIスキャナーと何が違うのか。
誤検知ほぼゼロを支える検証の仕組みとは
GoogleがPageBreakの中核に据えたのは、AIが立てた脆弱性の仮説を、実際に稼働する環境で攻撃コードを実行して確かめる「決定的検証」だ。
PageBreakは潜在的な欠陥を見つけると、その仮説を脆弱性の種類ごとに用意された専用のバリデーター（検証プログラム）に渡し、実際のペイロード（攻撃コード）を実行して悪用可能かどうかを確認する。バリデーターはAIが書いたものではなく、検証結果が確実に再現できるよう設計されている。バリデーターの例は次の通りだ。
- クロスサイトスクリプティング：特定のJavaScriptコードを注入し、ページ読み込み時にそのコードが実際に実行されるかどうかを監視する
- SQLインジェクション：ペイロードを注入し、出力や応答時間からデータベースクエリを操作できるかどうかを検証する
- パストラバーサル：誰でも読み取れる場所に新しいファイルを作成し、アプリケーションからそのファイルを読み取れるかどうかを確認する
- リモートコード実行（RCE）：処理を意図的に遅延させる、書き込み可能な場所にファイルを作成できるかを確かめる、外部へのDNSやHTTPリクエストを発生させるといった複数の手法で、コードが実行されたかどうかを確認する
- サーバーサイドリクエストフォージェリ（SSRF）：アプリケーションが内部サービスへのリクエストを発生させたかどうかを検出する
検証で確認できなかった報告は製品チームに送らない。Googleは、この運用によって製品チームが確度の高い報告に集中できるとしている。ただし、Googleによると現在のバリデーターでは全ての脆弱性の種類や複雑なシナリオを検証し切れず、見落とし（偽陰性）が生じるリスクがある。そのため、未検証の検出結果も捨てずに、次回スキャンの手掛かりや、バリデーターに不足している機能を判別するための材料として活用している。
PageBreakは複数のAIモデルで動作するが、利用の大半は「Gemini 3.1 Pro」や「Gemini 3.5 Flash」などGeminiモデルを基盤にしているという。
高保証フレームワークには通用したのか
Googleは2025年に、Webの脆弱性を設計段階で排除する「高保証Webフレームワーク」の設計構想を公開している。PageBreakをこのフレームワークで構築したアプリケーション群に対して実行したところ、2026年9月4日時点で発見できたクロスサイトスクリプティングは数百のWebアプリケーション中2件にとどまった。その2件も、社内向けアプリケーションや権限（けんげん）化が不十分なデバッグ用エンドポイントに限られていた。Googleはこの結果について、セキュアバイデザインのフレームワークで安全なソフトウェアを構築するアプローチの価値を実環境で裏付けるものだとしている。
検証済みの脆弱性に絞っても、製品チームが受け取る報告の量は多い。GoogleはPageBreakを、自動でバグ修正を生成する社内の取り組み「CodeMender」などと連絡させており、今後は製品チームの関与を修正案の確認だけに減らすことを目指すという。
