AIを使った脆弱性診断とは？自動化できる範囲と従来の診断・ASMの違い

AIを使った脆弱性診断とは、調べる箇所の探索、ソースコードの読み取り、結果の整理をAIに任せ、候補が成立するかは人が確かめる脆弱性診断だ。

調べていない範囲は別の手段で補う。AIを組み込んだシステム自体を調べる診断とは別の話だ。JPCERT/CCは2026年10月、国内で相次いだ不正アクセスの調査で、攻撃者がAIを使って既知の脆弱性のスキャンやAPI経由の攻撃をしていたことを確認したと報告している。守る側がAIを使う診断を入れるときは、AIを使うかどうかより、対象の機能、利用者の権限の違い、検査で行う操作、結果の根拠、修正後の再診断を確かめる。

AIを使う脆弱性診断：AIを使う診断と従来の診断の役割

AIを使う診断が主に受け持つのは、応答やコードを読んで脆弱性の候補を見つける工程で、候補が本当に成立するかの検証は人に残ると我々は考える。

NISTは『情報セキュリティの試験と評価の技術ガイド』で、試験の手法を3つに分けている。設定やログを人が読む「レビュー」、主に自動ツールで機器・サービス・脆弱性の候補を見つける「対象の特定と分析」、脆弱性が実在することを示す「脆弱性の検証」だ。同じガイドは、どの手法も単独では全体像を示せないので組み合わせるよう求めている。AIが速くするのは2つ目の工程にあたる。

AI診断と従来の自動診断の違い

NISTは、脆弱性スキャンは既知の脆弱性を見つけられるが誤検知が多いとしている。OWASPは『Webセキュリティテストガイド』で、自動ツールは汎用に作られていて、そのWebアプリ固有の文脈を持たないことが多く、深刻な問題ほど業務の処理や独自の設計に絡むと説明する。

脆弱性診断の自動化で、AIはこの文脈を読む工程を変えうる。DARPAの競技会「AIサイバーチャレンジ」の決勝では、出場チームのAIシステムが計5,400万行のコードを対象に、主催者が埋め込んだ63件の脆弱性のうち54件を見つけ、43件を修正した。実在する脆弱性も18件見つかった。ソースコードがあり、答えの決まった脆弱性を埋め込んだ競技の結果で、稼働中のWebアプリを外から試す診断にそのまま当てはまる数字ではない。

AI脆弱性診断ツールを比べるときは、「AI」という名前より、どの工程をAIが担い、何を入力にするか（URLだけか、ソースコードや設計書もか）を確かめる。

AI診断と手動検証の役割

NISTは脆弱性の検証の目的を、脆弱性が実在することを示し、悪用されたときに何が起きるかを明らかにすることとしている。対象のシステムに影響を与えやすく、手法の中で最もリスクが高いとも書いている。

検証で人が受け持つのは、検出された候補の再現と、業務への影響の判断だ。誰のどのデータが見えてはいけないかは、仕様を知る側でないと決められない。

たとえば通販サイトで、一般の会員が注文番号を変えると他人の注文を取得できるかを試すには、権限の違う診断用アカウントが2つ以上要る。OWASPは、オブジェクトのIDを受け取るAPIはすべて、その利用者が操作してよいかをサーバー側で確かめるべきだとし、認可の仕組みを試すテストを書くよう勧めている。

AIを使う脆弱性診断：ASM・アセスメントを含む目的別の比較

脆弱性診断は依頼側が渡した対象を調べ、ASMは外から見える資産を探し、アセスメントは評価したいリスクから対象と方法を決める。AIを使っても、診断が調べるのは渡された対象だけだ。

ASMによる資産発見と脆弱性診断

経済産業省の『ASM導入ガイダンス』は、ASMを、外部からアクセスできるIT資産を発見し、そこにある脆弱性などのリスクを継続的に検出・評価する一連のプロセスと定義している。

同じガイダンスは、情報システム部門以外が作ったキャンペーン用のサイトや、本社で管理しきれていないグループ会社の資産を見つける場面を挙げている。国内のセキュリティ企業は、AIが使われた攻撃基盤の分析で、最も深い侵入例の入口も認証のない公開管理画面を持つ古いWebシステムだったとし、公開Webシステムの棚卸しを最初の対策に挙げる。一覧にない資産は、AIを使う診断でも調べられない。

アセスメントの目的と診断範囲

アセスメントでは、評価したいリスクを先に決め、そこから対象と方法を選ぶ。

自社が避けたい被害を一文で書いてから表に当てはめると、AIを使う診断がどの行を受け持つかが決まる。

AIを使う脆弱性診断：検出結果の再確認と見落としへの対応

AIを使う診断の結果は、検出の件数より、各指摘を再現できたかと、調べなかった範囲を先に読み、範囲外は手動の試験やソースコードのレビューで補う。

AI診断結果の誤検知の再確認

AIの出力を確かめずに受け取ると、確認の手間は受け取る側に移る。オープンソースのcurlの開発者は、脆弱性の報告に報奨金を払う制度で、2025年以降は届いた報告のうち実在の脆弱性が5%を下回ったとし、AIで作った低品質な報告を理由の一つに挙げて、2026年1月に制度を終えた。診断とは別の、外部から報告を受ける場面の例だ。

報告書では、各指摘に次の根拠が付いているかを見る。

診断対象外と見落としへの補完

報告書には、調べていない機能と条件を書いてもらう。管理者だけが使う画面、決済の後の処理、仕様書に載っていないAPIなどだ。

JPCERT/CCの注意喚起には、公開されたスマートフォンアプリを解析してAPIの接続先やキーを特定し、内部のAPIで利用者の権限を変えたり不正なアカウントを作ったりした事例がある。画面をたどって調べる診断では、スマートフォンアプリだけが使うAPIが範囲から漏れることがあると我々は考える。漏れた部分は、手動の試験やソースコードのレビューで補う。

アプリの解析から接続先のAPIを狙う手口と、自社のAPIで何から確かめるかは、A2B攻撃の解説にまとめた。

AIを使う脆弱性診断：自社に必要な範囲と依頼条件

AIを使う脆弱性診断を頼むときは、診断する資産、AIに渡す情報、人が確かめる範囲を書面で分けて決める。依頼の前に決める項目は次の6つだ。

1. 診断したい資産：URL、API、スマートフォンアプリ。ASMや資産の一覧から選ぶ
2. AIに渡す情報：URLと認証情報だけか、ソースコードや設計書も渡すか。渡した情報を処理するAIの提供元、保存期間、学習に使わない設定
3. 人が確かめる範囲：候補の再現、業務への影響の判断、権限の検証
4. 権限ごとの診断用アカウントと、検査で行ってよい操作（登録・更新・削除・メール送信）、それ以外の操作を止める方法
5. 調べない機能と、その理由
6. 成果物：候補と確認済みの区別、再現の条件、修正後に同じ条件で再試験するか

診断の通信には、利用者の個人データが含まれることもある。個人情報保護委員会は、本人の同意なく個人データを含むプロンプトを生成AIに入力し、応答以外の目的で扱われるおそれがあるなら、提供事業者がそれを学習に使わないことなどを十分確かめるよう求めている。ソースコードや認証情報についても、送った先で保存されるか、学習に使われるかを書面で確かめておく。

結果を受け取った後の段取りも先に決める。誰が指摘を読み、どの基準で直す対象を選び、直した後にどう確かめるかだ。NISTは、修正が終わったことを試験チームが確かめられるのは、元の試験と同じ試験を行った場合だけだとしている。

始め方は、自社の状況で分かれる。

まず、自社の公開資産の一覧と、権限ごとの診断用アカウントを用意できるかを確かめるとよい。

このテーマの記事

• 「Strix」とは？単一URLのAI診断が約78秒で完了！検証の条件：Strixは、生成AIがWebアプリやコードを調べる診断用エージェント。2026年10月8日の単一URLの検証結果を基に、約78秒の実行に含まれる範囲、診断前に用意する情報、人が確認する証拠を整理する。
• AIによるログ解析・異常検知｜元ログとの照合と人が判断する範囲：AIによるログ解析を不正アクセスの調査に使う方法。生成AIに渡すログの範囲、異常検知で候補を拾う観点、元のログとの照合で誤りと見落としを確かめる手順、機密情報の扱いと遮断・報告の承認まで解説。