- 目次
1.AIを活用した脆弱性診断は「件数」だけでは比べられない
本稿では、LLMやAIエージェント(※1)を用い、ソースコード、設計情報、診断方針などを参照して脆弱性を調べるものを「AIを活用した脆弱性診断」と呼びます。
脆弱性診断の目的は、AIの利用有無にかかわらず、発見した問題を修復につなげ、システムを安全にすることです。そのため、製品の優劣を検出件数だけで判断することはできません。例えば、同一システムに対する報告件数が一方は20件、他方は3件であっても、前者が未検証の候補で、後者が脆弱性の成立を確認した結果であれば、件数のみで比較することは適切ではありません。また、3件にとどまった理由が探索範囲の狭さにある可能性もあります。
従来のSAST(※2)は、あらかじめ定義されたルールやデータフロー解析に基づいて脆弱性の可能性を検出するため、同一の対象・設定では比較的安定した結果を得やすく、指摘箇所や検出根拠を一定の形式で出力します。
一方、AIを活用した脆弱性診断では、複数のファイルや処理の関係を読み取り、成立条件や想定される影響、修正案まで示す場合があります。その反面、与える情報や診断方針、診断ごとの探索経路によって、探索範囲や出力内容が変わることがあります。そのため、AIを活用した脆弱性診断を比較する際は、件数だけでなく、検出結果の妥当性、説明の十分性、結果の安定性、修正支援の実用性を確認する必要があります。
図1:従来のSASTとAIを活用した脆弱性診断の違い
目的に応じて情報やツールを自律的に選び、複数の作業を進めるAIシステム
Static Application Security Testingの略。アプリケーションを実行せず、ソースコードなどを解析する手法
2.診断能力を左右するのはLLMだけではない
AIを活用した脆弱性診断において、AIエージェントはLLMを使って状況を解釈し、関連ファイルの検索、呼び出し関係の追跡、解析ツールの実行など、次に行う調査を選択します。こうした行動をLLMの外側から制御・支援する仕組みが「ハーネス(※3)」です。ハーネスには、入力情報、診断方針、探索範囲、利用可能なツールや検証環境、再確認の手順、終了条件、報告基準、人による確認・承認の条件などが含まれます。同じLLMでも、入力情報の範囲、利用可能なツール、検証水準によって、調査の深さや出力品質は変わります。したがって、LLMとハーネスを一体として評価する必要があります。
図2:LLM、AIエージェント、ハーネスの関係
AIエージェントを制御し、導き、検証し、必要に応じて修正を促すための環境全体を意味する
https://www.nttdata.com/jp/ja/trends/data-insight/2026/0625/
3.製品差を整理する3つの工程
次に、AIを活用した脆弱性診断を行う際に生じる製品ごとの差を、「発見」「検証」「結果提示・修正支援」の3工程に分けながら整理します。以下は各工程における代表的な処理例であり、実装方法や対応範囲、出力内容などは製品によって大きく異なります。
- 発見
ソースコードや設計情報などを参照し、脆弱性候補と確認対象を抽出します。製品によっては、複数のファイルや機能の関係を解析し、システム固有の問題を仮説として提示します。 - 検証
処理の到達経路、入力値の受け渡し、成立条件、防御処理などを確認します。製品によっては、再現手順やテストコードを生成し、隔離環境での部分実行や脆弱性が成立しない条件の確認を行います。 - 結果提示・修正支援
検出箇所に加え、成立条件、想定される影響、確認方法などを整理して提示します。製品によっては、修正案や修正コードの生成、修正後の再検証を支援します。
図3:AIを活用した脆弱性診断の三工程における製品差(筆者による整理)
4.選定時に確認すべき3つの観点
利用目的や運用体制を踏まえて製品を選定することは、従来のSASTでも、AIを活用した脆弱性診断でも変わりません。AIを活用した脆弱性診断で特に確認すべきなのは、入力情報、ハーネスの設計、診断ごとの探索経路によって、結果が変動する可能性があることです。そのため、採用するLLMや単一回の診断結果のみを判断基準とせず、実際の診断対象に近いコードを用いて、次の点を確認します。
- 利用目的に適合するか
脆弱性候補の幅広い抽出、脆弱性の成立確認、修正支援など、自社が必要とする工程に重点を置いた製品かを確認します。 - 想定する利用者に適合するか
利用者自身によるコードや仕様の解釈が必要か、影響、確認方法、修正方針まで整理して提示されるかを確認します。利用者に求められる知識や確認作業は、製品によって異なります。 - 想定する運用に適合するか
定期診断や修正前後の比較では、同一条件における結果の安定性を確認します。一方、探索を重視する場合は、診断ごとに異なる候補が提示されることにも価値があります。
AIを活用した脆弱性診断では、結果の変動を一律に問題とせず、利用目的に応じて、必要な結果の安定性と探索の広がりを評価することが重要です。
5.診断を修復につなげる
AIは診断の手段を変えても、脆弱性診断の目的を変えるものではありません。脆弱性を見つけること自体ではなく、修正すべき問題を判断し、修正と再検証を通じて安全なシステムを実現することが目的です。そのため、製品の導入前に、誰が診断結果を確認し、どのような基準で修正対象を決め、修正後にどのように再検証するかまで定めておく必要があります。診断後に対応方法を検討するのではなく、修復までを含むプロセスとして設計することが重要です。
NTT DATAでも、複数のAI技術を評価・検証して得た知見と、セキュリティとシステム開発・運用の専門性を組み合わせ、脆弱性の発見から影響評価、修復、継続運用までを支援する取り組みを進めています。これは、特定のAI技術だけで判断せず、お客さまのシステムや運用に応じて、AI技術と専門家の知見を組み合わせる考え方です。
AIを活用した脆弱性診断は、製品の導入だけで完結するものではありません。目的に合う製品を選び、結果を修復へつなげる運用まで含めて設計することが、実効性のある活用につながります。


AIエージェントのハーネス設計についてはこちら:
https://openai.com/index/harness-engineering/
SAST(静的アプリケーション・セキュリティテスト)についてはこちら:
https://owasp.org/www-community/Source_Code_Analysis_Tools
フロンティアAIを活用したサイバーリスク対応サービスについてはこちら:
https://www.nttdata.com/global/ja/news/release/2026/070700/
あわせて読みたい: