記憶しているだけなのか？AIセキュリティ製品の評価の難しさ

はじめに：AIセキュリティ製品の台頭と評価の落とし穴

ユーザ企業においてLLMを搭載したセキュリティ製品の導入は、検討段階から実装段階へと移行しつつあります。GitHub Copilotのようなコーディング支援ツールが定着する一方で、主要なセキュリティベンダ各社も「AIによる脆弱性診断ツール」や「AI SOC アナリスト」といった次世代製品を市場に投入しています。これらは、従来のシグネイチャを用いたパターンマッチベースのツールが見逃していた複雑なロジックエラーや未知の脆弱性を発見し、運用負荷を劇的に下げると期待されています。

しかし、ここに評価上の留意点が存在します。それは、「そのAIは本当に脆弱性を理解して発見しているのか、それとも単に答えを記憶しているだけなのか？」という疑念です。

本レポートでは、LLMを用いたセキュリティ製品の評価がなぜ難しいのか、その根本原因である「データ漏洩」と「暗記」のメカニズムを解き明かします。そして、ユーザ企業がベンダのマーケティングを客観的に評価し、自社を守るための真の実力を見極めるために必要な、具体的な評価手法と選定基準について解説します。

なぜ「いつものテスト」が通用しないのか？

従来の評価手法とLLMの決定的な違い

これまで、セキュリティ製品(SAST/DASTなど)の性能を評価する際、ユーザ企業では標準的なベンチマークアプリを使用してきました。例えば、わざと脆弱性を作り込んだWebアプリケーション(やられ環境)である「OWASP Juice Shop」や「DVWA(Damn Vulnerable Web Application)」などです。

従来型のツールは「ルールベース」で動いていたため、これで大きな問題ありませんでした(公開されているやられ環境に製品が特化してしまっている場合はありますが…)。ツールはプログラムされたルールに従って動くため、テスト対象が有名アプリであろうと自社アプリであろうと、同じロジックが適用されるからです。

しかし、LLMは違います。LLMは「ルールベース」ではなく、「学習データ」に基づいて動いています。ここが性能を検証する際に問題となります。

「カンニング済み」のAIたち

現在主流のLLMは、インターネット上の膨大なテキストデータを学習して作られています。その中には、GitHub上の公開コード、Stack OverflowのQ&A、そして「脆弱性診断の練習用アプリのソースコードとその解答」も含まれています。

OWASP Juice Shopのような有名な検証用アプリは、LLMにとって「初見の問題」ではありません。学習データの中に、そのアプリのソースコードや、「どこに脆弱性があるか」を解説した記事(Write up)が含まれているのです。

この状態でAIセキュリティ製品にJuice Shopをスキャンさせると、AIはコードのロジックを解析して推論しているのではなく、「これは学習データで見たJuice Shopだ。記憶にある通り、ここにはSQLインジェクションがある」と、記憶から答えを導き出している可能性が高いのです。

これは、試験前に答えを丸暗記してきた学生に同じ問題を解かせて「天才だ」と評価するようなもので、実務能力の証明にはなりません。

「未知の脅威」に対する実効性の疑念

「答えを覚えていても、脆弱性が見つかるならいいではないか」と思われるかもしれません。しかし、企業の現場で守るべき対象は、有名なOSSだけではありません。社内で独自開発されたシステムや、業務特有のロジックを持つアプリケーションです。

• 学習データにあるOSS: AIは「記憶」を頼りに高得点を出します。
• 学習データにない自社システム: AIは「記憶」を使えず、「推論能力」だけで勝負する必要があります。

もし導入製品が「記憶」に依存していた場合、ベンダのデモでは完璧に動作しても、いざ自社システムに導入すると全く脆弱性を見つけられなかったり、大量の誤検知(ハルシネーション)を出したりすることになります。これが、評価における難所です。

データ漏洩と暗記のメカニズム

LLMの学習データの正体

LLMのトレーニングデータには、次のような情報が含まれており、これらがテストデータの「漏洩」源となっています。

「汎化」と「暗記」の境界線

AI評価で重要なのは「汎化能力」です。これは「ユーザ入力をそのままSQL文に結合するのは危険」といった抽象的なルールを理解し、未知のコードにも適用できる能力を指します。

一方、最新の研究では、変数名を変えたりコメントを削除したりするだけで、LLMの検知率が大幅に下がることが報告されています。これは、AIがロジックではなく、見た目のパターンやキーワードに過剰に適合している証拠です。

正しい評価のための戦略：演習環境と「未知」の作り方

ユーザは「AIが記憶を使えない状況」を作り出して評価する必要があります。ここでは、SAST/DASTなどの脆弱性を検知する製品の評価を例に挙げます。

戦略1：オリジナルの検証用プログラムの作成

最も効果的なのは「世の中に存在しない、オリジナルの脆弱なプログラム」を作成し、テストデータとすることです。意図的に脆弱性を埋め込んだプログラムを検証に用いることで、AIがロジックを理解しているかどうかを評価できます。検証のためだけに作成したプログラムはインターネット上に存在しないため、学習済みの可能性はゼロです。

戦略2：コード・パータベーション

既存の検証用アプリを使う場合でも、コードに変更を加えることで評価精度を高められます。これがコード・パータベーションです。ソースコードの機能は変えずに、変数名をランダムな文字列(例:getUser→func_x9z)に置換したり、コメントを削除したりします。変数名を変えただけで検知できなくなる場合、その製品はロジックを理解しておらず、表層的なパターンに依存しています。

戦略3：「ゼロデイ」シミュレーション

「学習されていないであろう新しい脆弱性」を使うアプローチです。これを「テンポラル・カットオフ(Temporal Cutoff)テスト」と呼びます。評価対象の製品が用いているだろうLLMの学習データ期間(例：2025年12月まで)を確認し、それ以降(例：2026年1月以降)に発見された脆弱性(CVE)を持つOSSを選定してテストします。学習データ期間外の脆弱性は、製品が学習していないため、推論能力の評価として有効です。

ユーザ企業の担当者がベンダに問うべき質問

ユーザ企業の担当者は、製品を検討する際に、機能について質問を行うべきです。質問の一例を紹介します。

• Q. 学習データの漏洩(リーク)対策は？
  良い回答例: 「時系列でデータを分離し、学習期間外のデータや独自の非公開データセットで検証しています。」
  悪い回答例: 「OWASP Juice Shopなどの有名な検証用アプリで高得点を出しています。」
• Q. 誤検知(ハルシネーション)の抑制策は？
  良い回答例: 「社内規定を参照させ、自己点検させています。」
  悪い回答例: 「最新モデルを使っているので間違いは少ないです。」
• Q. データプライバシーと学習利用は？
  良い回答例: 「社内規定を参照させ、自己点検させています。」
  悪い回答例: 「最新モデルを使っているので間違いは少ないです。」

まとめ

AIセキュリティ製品の評価は暗記による「知識の再生」と推論による「知能による解決」を見極めるプロセスです。安易な検証はAIの「記憶力テスト」にしかならず、実戦での防御力を保証しません。ユーザは、公開ベンチマークを疑い、AIが学習していない「未知」のコードや最新の脆弱性を用いてPoCを行う姿勢が求められます。

また、AIセキュリティ製品は、存在しない脆弱性を自信満々に報告する「ハルシネーション」を起こすことがあります。これは運用現場のアラート疲れを招きます。評価時には、「安全なコードを渡したときに、どれだけ静かにしていられるか」も重要な指標となります。

魔法のような万能ツールとしてではなく、時には間違いも犯すものの、適切な評価と運用次第で強力な味方になる「新人アナリスト」としてAIを捉え、厳格かつ現実的な評価プロセスを構築してください。