生成AIの脆弱性診断は「モデル任せ」では機能しない｜精度を左右するハーネス設計と11ステップの診断プロセス

2026年4月、Anthropicは、未公開のフロンティアAIモデル「Claude Mythos Preview」を防御目的の脆弱性調査に活用する「Project Glasswing」を発表しました。この取り組みにより、AIが未公表の脆弱性を発見し、開発者による確認や修正につなげる動きが現実のものとなっています。

Project Glasswingの発表当時、Claude Mythos Previewは一般提供されていませんでしたが、当社では一般利用可能な高性能モデルと独自のハーネスを組み合わせることで、同等のレベルで代表的な未公表脆弱性を検出できることを再現検証しました。

現在、当社は「フロンティアAI対応プロアクティブ脆弱性診断」として複数の企業・組織のソフトウェア製品等を対象に、脆弱性の検証から修正案・緩和策の提示までを支援しています。

LLMによる脆弱性診断の品質を左右するのは、モデル単体の性能だけではありません。

当社では、一般に利用可能な高性能モデルと独自の検証基盤を組み合わせ、調査対象の選定から候補の反証、攻撃成立性の検証、修正・緩和策の作成までを11ステップに分けて実行しています。

本稿ではその設計思想と、既存SASTとの役割の違い、安全に運用するためのポイントを紹介します。 

フロンティアAI対応プロアクティブ脆弱性診断の提供フロー（掲載時点）

LLMによる脆弱性検査におけるハーネスの必要性

LLMは「このソフトウェアから脆弱性を見つけて対応策を提示してください」のような単純な指示でも、ソースコードを読み、脆弱性候補を回答することができます。

しかし、大規模なコードベースを一度に処理しようとすると、モデルが一度に扱える情報量の上限に達し、調査範囲や着目点が希薄になるおそれがあります。

また、LLMの出力は非決定的であり、探索や検証の基準を示さなければ検出漏れや誤検知を起こすおそれがあります。

そのため、LLMを活用したソフトウェア開発のプラクティスと同様に、一度に実行する作業の範囲を絞り、作業指示や制約事項を明確にするハーネスが不可欠です。

当社提供サービスで使用するハーネスの実施ステップ

当社のフロンティアAI対応プロアクティブ脆弱性診断（本稿では便宜上、以下「LLM脆弱性診断」と呼びます）では、バックエンドのモデルにかかわらず一定の手順と成果物を維持できるよう、11のステップに分けるハーネスを構築しています。

11のステップは6つのフェーズに分類されます。

• ①事前準備：調査対象を理解し、探索範囲を絞る

• ②脆弱性検出：網羅的な観点で検証し、少しでも疑わしい発見はすべて記録する

• ③誤検知の排除：各発見事項が本当に脆弱性であるか疑う

• ④リスク評価：外部からの攻撃が成立するか検証し、対策が必要な脆弱性を特定

• ⑤対策立案：ソースコードの修正案とシグネチャ等の防御策を作る

• ⑥報告：調査結果を整理し、アナリストが確認できる状態にする

脆弱性の検出と報告は複雑な課題であるため、候補を広く洗い出す役割と、候補を反証する役割を分離し、異なる観点から段階的に検証します。

当社11ステップハーネスの実行フェーズ

①事前準備

1.調査対象範囲の絞り込み

コードベースのみから、または入力として設計書を併用しながら、対象プロジェクトの構成理解を行います。
並行して、脅威モデリングの考え方を用いてソース内の深掘り対象を絞り込みます。

これにより外部入力の影響を受けるモジュール・関数等の呼び出しフローにターゲットを絞り、LLMのコンテキストを浪費せず、着目点を維持して脆弱性調査を行うことができます。

→成果物：構成理解を説明する文書（Markdown）、次ステップで各エージェント（特定の役割を与えたLLM実行単位）が深掘りする範囲を列挙したJSON

②脆弱性検出

まずはコードベースを探索し、脆弱性の疑いがある箇所を可能な限り洗い出します。

2.調査・検出

ステップ1「調査対象範囲の絞り込み」の成果物を入力とし、複数のエージェントが並列分担して脆弱性探索を行います。各エージェントに対象のデータフローと必要な構成情報だけを与え、互いの判断に影響されない状態で並列に調査します。この段階では見逃しを抑えることを優先し、確度が十分でないものを含めて脆弱性候補を幅広く抽出します。

調査観点として、OWASP Top 10等の公開情報、NRIセキュアの診断サービス提供時の観点等を指定し、エージェントが担当する調査対象に対し各観点を一巡して照合します。

→成果物：データフローごとに発見した脆弱性一覧のJSON（脆弱性要旨、コードベースの該当箇所、CWE、判断根拠、誤検知の可能性）

3.観点補完

ステップ2「調査・検出」で洗い出した脆弱性候補のCWE分布を作成し、既知の脆弱性をもとに静的に用意した期待CWE分布と比較します。各調査範囲で不足しているCWEを特定し、当該CWEを念入りに探索するよう再度ステップ2「調査・検出」のエージェントを呼び出します。

ただし、本工程で作成するCWE分布は、調査観点の偏りを可視化するためであり、再調査のきっかけにするものです。特定のCWEが存在することを前提とするものではありません。

4.重複統合

これまでのステップで出力された発見事項をまとめ、同一の根本原因に基づく発見は1件のみになるよう統合します。

③誤検知の排除

これまでは脆弱性の可能性が少しでもあるものを列挙したのに対し、ここからは各発見事項の詳細を見極めます。このフェーズでは、明らかな誤検知でないかを確認します。

5.敵対的検証

各発見について「バグや脆弱性ではないとすれば、どのような反証があるか」を独立したエージェントに検討させます。

入力は対象のコード、発見事項の客観事実であり、並列して1つの発見事項に対する反証のみに専念します。
以下のいずれに該当する場合は当該発見事項を却下します。

• データバリデーション等の防御機構が存在する
• フレームワーク等による実効的な防御が存在する
• 想定する利用条件では、当該コードが実行されず、脆弱性が成立しない

④リスク評価

③に引き続き、発見事項を見極めるフェーズです。

このフェーズでは、各脆弱性が外部から実際に侵害されうるかを確認します。
順に網の目が細かくなるよう、異なる観点で確認します。

6.到達性確認

ここでは外部入力の入口（source）から問題となる処理（sink）まで実際に到達できるかを確認します。

シンボル情報を用いた静的解析とLLMによる経路分析を組み合わせ、到達に必要な条件（常時、要認証、要設定等）とともに呼び出し経路を記録します。

7.悪用可能性判定

ステップ5「敵対的検証」と類似していますが、データフローの過程でペイロードがどのように変化するかをより細かく追跡します。

脆弱性箇所（sink）から逆方向にデータ変形を追跡し、既知のバイパステクニックの応用で対策を突破できないか確認します。

8.サンドボックス検証

悪用可能と判定された脆弱性に対して、PoCコードの作成を行います。

これまでの情報から攻撃シナリオとPoCコードを作成するエージェント、作成されたPoCコードを机上検証するエージェント、実際にDocker上でサンドボックス検証環境を作成し、作成したPoCが成立するかを確認するエージェントの3つが動作します。

⑤対策立案

9.修正案生成

PoCが成立した脆弱性に対し、ソースコードの修正提案をします。
PoCのペイロードだけを弾く対症療法にならないよう根本原因を修正し、以下を検証します。

• ステップ8「サンドボックス検証」で作成したPoCが成立しないこと
• 既存テストの再実行もしくはスモークテストの作成を行い、修正によるリグレッションが起きないこと
• 独立セッションが修正後のソースコードを確認し、根本原因が除去されたと認めること

10.防御策作成

修正コードをすぐに適用できない環境を考慮し、到達可能かつ危険度の高い脆弱性に対して防御策を作成します。脆弱性の性質と対象環境に応じ、WAF・IPS等のシグネチャ、ミドルウェアの設定変更といった緩和策を検討します。

⑥報告

11.報告

人間が確認することを目的としたレポートの作成と成果物統合を行います。

• HTMLレポート：脆弱性の一覧、詳細（該当コード、悪用シナリオ、影響）、修正パッチを報告
• SARIF：静的解析結果の標準交換フォーマット。機械的に処理する場合に使用

当社サービスではHTMLレポートを開発者向け速報としてご提供し、セキュリティアナリストによる精査を踏まえた正式報告を後日実施します。

LLMの強みが活きた検出脆弱性の一例

複数ファイルにまたがる認可不備

特定のリクエスト条件を満たした場合にのみ、高い権限が付与される処理を検出しました。問題の成立には複数ファイルをまたぐデータフローと、付与される権限の意味を併せて理解する必要があり、コード全体の文脈を分析できるLLMの特徴が生きた例です。

類似機能間の認証条件の不整合

同等の機能を提供する複数の経路のうち、一方だけ再認証条件が弱いケースを検出しました。個々のコードパターンの違反ではなく、機能間のセキュリティ要件の不整合を捉えた例です。

既存SASTとの違い

既に多数のセキュリティ企業および研究者によってLLMのフロンティアモデルを活用した脆弱性調査の実施例は報告されています。
それらのすべてに共通する特徴ではないものの、当社のLLM脆弱性診断はSASTと異なる以下の特徴を持っています。

• 脅威モデリングをベースに、ソースコードの探索範囲に濃淡をつける
• 濃淡のため完全な網羅性はないが、外部からの到達点（エントリポイントからのコールフロー）を徹底的に洗い出す
• 対象ソースコードの文脈と想定脅威をもとに、現実に悪用されうる脆弱性を探索する
• LLMの出力は非決定的であるため、探索した箇所の脆弱性が必ず見つかるとは限らない（NRIセキュアでは執筆現在、同じサイクルを複数回繰り返すことで検知可能性を上げています）
• 対象ソフトウェアの構成を把握した上で攻撃シナリオの想定やコードの生成を行う

既存SASTとLLM脆弱性診断の特徴比較

安全性への取り組み

当社LLM脆弱性診断サービスの提供にあたっては、お客様の機密情報であるソースコードをお預かりし、すでに本番環境で稼働中の可能性があるシステムの脆弱性を調査することから、以下の取り組みにより安全性を確保しています。 

ソースコードの機密性確保の対応

お預かりしたソースコードは、診断関係者に限定したアクセス制御下で管理し、契約および当社所定の手続に従って、診断・フォローアップ終了後に当社管理環境から削除します。

LLMサービスの利用によるソースコードの外部流出懸念への対応

利用するAIサービスと契約形態（データの取り扱い、保持期間、利用リージョン等）を診断実施前に説明します。

また、万が一診断対象内に含まれたシークレット情報が何らかの原因で流出することがないよう、診断実施前に機械的なシークレットスキャンを実施します。

なお、診断対象のソースコードや診断結果を、LLMサービス以外の外部サービスへ送信する連携は行いません。依存パッケージの取得等に必要な通信は、許可した宛先に限定して制御します。

サンドボックス検証中 における意図しない外部通信への対策

当サービスの診断は、通信先を許可リストプロキシで厳密に制限した環境内で実施します（通信先はLLMサービスのAPI、依存パッケージのダウンロード先等に限定）。

また、PoCの検証は追加でコンテナを起動しており、同じく通信先を制限することで、意図せず外部や本番環境に接続することを防止しています。

まとめ

LLM脆弱性診断は、既知パターンを継続的に検査するSASTを直ちに置き換えるものではありません。一方で、複数ファイルにまたがる処理、業務ロジック上の不整合など、コードの文脈を伴う問題を深掘りする手段として大きな可能性があります。

ただし、その品質はモデル単体の性能だけで決まるものではありません。調査対象の選定、幅広い探索、独立した視点での反証、隔離環境での実証といったステップを組み合わせ、人間が最終判断できる形に整理する仕組みが重要です。

NRIセキュアのフロンティアAI対応プロアクティブ脆弱性診断サービスでは、独自の検証ハーネスとセキュリティ専門家の知見を組み合わせ、高度な脆弱性の検出から、悪用可能性の確認、修正案・緩和策の提示までを支援します。