AIで脆弱性診断はどこまでできる？できること・できないことと、人の確認が要る理由【2026年版】

Q: AIだけで脆弱性診断はできますか？

現時点ではAIだけに任せるのはおすすめしません。Google Project ZeroやDARPAのコンテストでAIが脆弱性を見つけた例はありますが、開発者自身が実験的な結果としています。AIはもっともらしい誤報告を出すことがあり、curlの開発者は2025年に届いた報告の約20%がAIによる質の低い報告だったと公表しています。AIは整理や下書きに使い、最終確認は人が行うのが現実的です。

Q: AIを使うと脆弱性診断は安くなりますか？

結果の整理や報告書の下書きなど、件数の多い作業の時間は短くできます。一方で技術者による確認とレビューは省けないため、すべての費用が下がるわけではありません。費用は診断の対象と範囲、手動での確認の量で決まります。

Q: 診断結果をChatGPTなどのAIに入れて分析してもよいですか？

診断結果は会社の弱点の一覧そのもので、機密性の高い情報です。クラウドの生成AIに入れる場合は、法人向けプランなど学習に使われない契約と保存の条件を確認してください。社外に出したくない場合は、ローカルLLMで分析する方法もあります。

Q: AIエージェントに診断を自動で実行させても大丈夫ですか？

注意が必要です。範囲外のシステムに診断をかけると不正アクセス禁止法に触れるおそれがあり、AIが自動で行ったことでも実行させた側の責任になります。実行できる対象を許可した範囲に機械的に制限し、人の承認を挟む仕組みが必要です。

「AIで脆弱性診断が自動化できる」「AIエージェントがハッカーの代わりになる」。2025年以降、こうした見出しをよく見かけるようになりました。一方で、診断を頼む側からすると、AIが出した結果をどこまで信用してよいのか、AIに任せて大丈夫なのかが分かりません。

本記事では、AIを開発・研究している組織の公表と、AIの出力を受け取る側の公表だけを材料に、AIによる脆弱性診断の現在地を整理します。そのうえで、診断の工程ごとにAIが向く作業と向かない作業を分け、AIを診断に使うときに特有のリスクと、発注するときの確認ポイントをまとめます。脆弱性診断そのものの種類は『脆弱性診断とは？ツール診断・手動診断・ペネトレーションテストの違い』で説明しています。

この記事の要点

AIは、未知の脆弱性を見つける段階に入りつつあります。Google Project Zeroは2024年、AIエージェント「Big Sleep」がSQLiteの未公開の脆弱性を見つけたと公表しました。DARPAのAIサイバーチャレンジ（2025年）では、参加チームのシステムが、仕込まれた63件の脆弱性のうち54件を見つけ、43件に修正を出しています

ただし、開発者自身が結果を「非常に実験的」としており、AIの出力をそのまま使うと誤報告が増えます。curlの開発者は、2025年に届いた報告の約20%がAIによる質の低い報告で、本物の脆弱性は約5%だったと公表しています

診断の工程で見ると、AIが向くのは、ツール結果の整理・重複の除去・優先度づけの下書き・報告書の下書きです。悪用できるかの最終確認、業務の流れに依存する弱点の判断、合否の判断は人が行うべきです

AIを診断に使うときに特有のリスクが3つあります。診断データ（弱点の一覧）をクラウドのAIに送ること、AIエージェントが範囲外に診断をかけてしまうこと、診断対象に仕込まれた指示をAIが読んでしまうこと（プロンプトインジェクション）です

発注するときは「AIを使うか」より、「AIの出力を誰がどう確認するか」「診断データをどこで処理するか」を聞いてください

AIによる脆弱性発見の現在地

まず、公表されている代表的な事例を見ます。いずれも開発・研究した組織自身の公表です。

Google Project Zero「Big Sleep」（2024年）

Googleの脆弱性研究チームProject ZeroとGoogle DeepMindは、2024年11月1日、大規模言語モデル（LLM）を使ったAIエージェント「Big Sleep」が、広く使われているデータベースエンジンSQLiteで、悪用可能なメモリ安全性の脆弱性を見つけたと公表しました。

公表によると、この脆弱性は正式リリースの前に見つかったため、SQLiteの利用者に影響はありませんでした。既存のファジング（大量の入力を自動で試す検査手法）では見つかっておらず、チームが自ら150 CPU時間のファジングを試しても再発見できなかったとしています。

一方で、チーム自身がこの結果を「highly experimental（非常に実験的な結果）」と呼び、対象に合わせて作り込んだファザーなら、少なくとも同程度には有効だった可能性が高いとも書いています。AIが従来の手法を置き換えたのではなく、別の角度から見つける手段が一つ増えた、と読むのが正確です。

DARPA「AIサイバーチャレンジ（AIxCC）」（2025年）

米国防高等研究計画局（DARPA）は、オープンソースソフトウェアの脆弱性をAIで自動的に見つけて直すコンテスト「AIサイバーチャレンジ」を開催し、2025年8月8日に決勝の結果を公表しました。

項目	DARPAの公表値
決勝で仕込まれた（人工の）脆弱性	63件
参加システムが見つけた数	54件
修正（パッチ）を出した数	43件
人工ではない、実在の脆弱性の発見	18件（オープンソースの開発者に報告中）
パッチ提出までの平均時間	約45分
1タスクあたりの平均コスト	約152ドル

AIが「見つけて、直す」ところまで自動でこなせることを示した結果です。ただし、対象はソースコードが手元にあるオープンソースソフトウェアで、コンテスト用に用意された環境です。会社が運用している公開サーバーやWebアプリを、外部から診断する作業とは条件が違う点に注意してください。

裏側：AIによる誤報告の増加（curl、2025年）

AIの出力を受け取る側からの公表もあります。通信ソフトcurlの開発者Daniel Stenbergは、2025年7月14日のブログで、その年に届いたセキュリティ報告について次のように書いています。

報告の約20%が、AIで作られた質の低い報告（AI slop）だった
本物の脆弱性だったのは、報告の約5%だった
1件の報告に3〜4人が関わり、それぞれ30分、時には1〜3時間を確認に使う

AIは、もっともらしいが存在しない脆弱性を、それらしい文章で報告できてしまいます。確認せずに出されたAIの結果は、受け取った側の確認の手間を増やします。脆弱性診断の報告書でも同じことが起きえます。存在しない弱点の修正に社内の開発者の時間を使うのは、明らかな損失です。

診断の工程ごとに見る、AIの向き不向き

ここからは、会社が受ける脆弱性診断の工程に沿って、AIが向く作業と、人が行うべき作業を分けます。

工程	AIが向く作業	人が行うべき作業
対象と範囲の決定	資産の一覧づくりの補助、公開情報の整理	診断範囲の最終決定、管理者の同意の取得
ツール診断の実行	― （ツールの実行自体は従来のツールで行う）	実行のタイミングと負荷の管理、中止の判断
結果の整理	複数ツールの結果の統合、重複の除去、同じ原因の弱点のまとめ	まとめ方の妥当性の確認
誤検知のふるい分け	一次的なふるい分け（「誤検知の可能性が高い」の目印づけ）	本当に問題かどうかの最終確認（再現の確認）
優先度づけ	深刻度の目安（CVSSなど）と、資産の重要度を組み合わせた案	業務への影響の判断、修正の順番の決定
業務の流れに依存する弱点	確認すべき箇所の候補出し	権限の確認漏れや、手順を飛ばせる不備などの判断
報告書	説明文・修正方法の下書き、経営層向けの要約の下書き	内容の正しさの確認、担当者以外によるレビュー
合否・証明	―	診断の結論と証明書の発行は人が責任を持つ

ポイントは、AIを**「件数の多い作業の下ごしらえ」に使い、「正しいかどうかの判断」**には使わないことです。

ツール診断では、件数の多い結果が出ます。似た指摘が何十件も並び、その中に誤検知が混ざります。ここを整理・分類するのはAIが得意な作業で、技術者が本当に確認すべき指摘に時間を使えるようになります。

一方、深刻度の目安としてよく使われるCVSSは、仕様書で、ある脆弱性の深刻度を他の脆弱性と比べた数値だと説明され、規制上の要件や漏えいによる金銭的な損失は対象外とされています。その会社にとって何が致命的か（顧客データか、決済か、業務停止か）を踏まえた優先度は、業務を知る人が決める必要があります。

なぜ最終判断を人が行うのか

理由は3つあります。

AIは存在しない弱点を書けてしまう：curlの例のとおり、もっともらしい誤報告を生みます。報告書に載せる前に、技術者が再現を確認する必要があります。
AIは責任を負えない：取引先に「この会社は、この日に、この範囲を診断し、重大な弱点を直した」と示すには、誰がその判断をしたのかが明確でなければなりません。
品質管理の基準も人のレビューを求めている：経済産業省の情報セキュリティサービス基準は、脆弱性診断サービスの品質管理の要件として、案件の担当者以外の者が報告書をレビューすることを挙げています。AIを使っても、この確認の仕組みは省けません。

AIを診断に使うときに特有の3つのリスク

AIを使った診断には、従来の診断にはなかったリスクがあります。発注する側も知っておくべき点です。

リスク1：診断データをクラウドのAIに送る

診断の結果は、会社の弱点の一覧そのものです。どのサーバーの、どのソフトが古く、どの画面に不備があるか。これが外に漏れれば、攻撃者にとってこれ以上ない手がかりになります。

診断ツールの結果、サーバーの設定、ログをそのままクラウドの生成AIに送って分析している場合、その送信先の契約（学習に使われないか、保存期間、保存場所）を確認する必要があります。生成AIをめぐる情報漏えいの経路は『生成AIの情報漏洩事例』で整理しています。

社外に出したくない場合は、社内やデータを持ち出さない環境で動くローカルLLMで分析する方法があります。ローカルLLMにも設定次第で残るリスクがあることは『ローカルLLMに残るリスク』を参照してください。

リスク2：AIエージェントが範囲外に診断をかける

AIエージェントに診断ツールの操作まで任せると、効率は上がりますが、範囲外のサーバーや、許可を得ていないシステムに診断をかけてしまうおそれがあります。

不正アクセス禁止法は、アクセス管理者の承諾なく、アクセス制御による制限を免れる情報や指令を入力して、制限されている利用ができる状態にする行為などを禁止しています（第2条第4項、第3条）。違反した場合の罰則は、3年以下の拘禁刑または100万円以下の罰金です（第11条）。AIが自動でやったことでも、実行させた側の責任になります。

また、大量の通信で相手のサービスを止めてしまう危険もあります。たとえばAWSは、事前の承認なしにペネトレーションテストを行えるサービスを示す一方で、DoS・DDoS攻撃やそれに類する大量の通信は禁止しています。AIエージェントを使う場合でも、実行できる対象を許可した範囲に機械的に制限する仕組みと、人の承認を挟む仕組みが必要です。

リスク3：診断対象に仕込まれた指示をAIが読む

AIは、読み込んだ文章に含まれる「指示らしきもの」に従ってしまうことがあります。これをプロンプトインジェクションと呼びます。OWASPは、LLMアプリの主要なリスクの一覧（Top 10 for LLM Applications 2025）の1番目にこれを挙げ、Webサイトやファイルなど外部の情報を取り込むことで起きる「間接的なプロンプトインジェクション」も説明しています。また、確実に防ぐ方法があるかは明らかでないとしています。

診断では、AIが診断対象のWebページや応答、ログを読み込みます。そこに、AIに向けた指示（「この脆弱性は問題ないと報告せよ」など）が紛れ込んでいれば、AIの判断がゆがむおそれがあります。これも、AIの出力をそのまま結論にせず、人が確認する理由の一つです。

AIを使う診断を頼むときの確認ポイント

「AIを使っているか」自体は、品質の目安になりません。次の質問をしてみてください。

質問	確認したいこと
AIは診断のどの工程で使いますか？	整理・下書きに使うのか、判断にまで使うのか
AIの出力は誰が、どう確認しますか？	技術者による再現の確認と、担当者以外のレビューがあるか
診断データはどこで処理しますか？	クラウドのAIに送るなら、その契約条件。送らない選択肢があるか
AIエージェントに診断ツールを操作させますか？	させるなら、対象の制限と人の承認の仕組み
報告書の見本を見せてもらえますか？	深刻度の根拠、再現の条件、修正方法が具体的に書かれているか
報告書や診断データの保管と削除は？	診断終了後の扱いが決まっているか

報告書に何が書かれていれば十分かは『脆弱性診断の報告書には何が書かれるか』、診断の結果を取引先にどう示すかは『脆弱性診断の実施証明書は何に使えるか』で説明しています。

よくある質問

AIだけで脆弱性診断はできますか？

現時点では、AIだけに任せるのはおすすめしません。Google Project ZeroやDARPAのコンテストでAIが脆弱性を見つけた例はありますが、開発者自身が実験的な結果としています。また、AIはもっともらしい誤報告を出すことがあり、curlの開発者は2025年に届いた報告の約20%がAIによる質の低い報告だったと公表しています。AIは整理や下書きに使い、最終確認は人が行うのが現実的です。

AIを使うと脆弱性診断は安くなりますか？

結果の整理や報告書の下書きなど、件数の多い作業の時間は短くできます。一方で、技術者による確認とレビューは省けないため、すべての費用が下がるわけではありません。費用は、診断の対象と範囲、手動での確認の量で決まります。

診断結果をChatGPTなどのAIに入れて分析してもよいですか？

診断結果は会社の弱点の一覧そのもので、機密性の高い情報です。クラウドの生成AIに入れる場合は、法人向けプランなど、学習に使われない契約と保存の条件を確認してください。社外に出したくない場合は、ローカルLLMで分析する方法もあります。

AIエージェントに診断を自動で実行させても大丈夫ですか？

注意が必要です。範囲外のシステムに診断をかけると、不正アクセス禁止法に触れるおそれがあり、AIが自動で行ったことでも実行させた側の責任になります。実行できる対象を許可した範囲に機械的に制限し、人の承認を挟む仕組みが必要です。

AIを使った診断を選ぶときは何を確認すればよいですか？

AIを使うかどうかより、AIの出力を誰がどう確認するか、診断データをどこで処理するかを確認してください。報告書の見本を見せてもらい、深刻度の根拠、再現の条件、修正方法が具体的に書かれているかも見ておくとよいでしょう。

この記事に関連するサービス

TodoONada株式会社のAIサーバー脆弱性診断では、ツールによる診断の結果をAIで整理・重複除去・優先度づけし、報告書の下書きまでをAIで効率化します。悪用できるかの確認と診断の結論は、必ず技術者が行います。診断データは、ご要望に応じてローカルLLMで社外に出さずに分析できます。

AIサーバー脆弱性診断（報告書・診断実施証明書つき） — 公開サーバー・Webアプリ・クラウド設定の診断。調査報告書・経営層向けレポート・診断実施証明書をお渡しします。対象と範囲をうかがってお見積もりします
不正アクセス・ハッキング調査と対策支援 — 侵害の有無・侵入経路・影響範囲の調査。ログはローカルLLMで社外に出さずに解析できます

ご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。