脆弱性診断とペネトレーションテストの違い｜範囲・AI活用・修正の進め方【2026年版】

脆弱性診断は、システムの弱点を調べ、影響と対策を整理するために行います。ペネトレーションテストは、合意した攻撃シナリオや目的に沿って、侵入や権限の悪用などが成立するかを検証します。両者を「自動で浅く調べるもの」と「手動で深く調べるもの」だけで区別すると、発注内容と期待する成果にずれが生じます。

本記事では2026年10月時点で確認したIPA・NIST・OWASP等の一次資料をもとに、目的の違い、実施範囲の決め方、自動化とAIの扱い、報告・修正・再確認の進め方を整理します。

脆弱性診断とペネトレーションテストの違いは、目的と確認範囲にある

脆弱性診断では、対象とする機能や構成、検査項目を定めて、脆弱性や設定の問題を調べます。自動スキャンだけでなく、認証や権限、業務固有の処理を人が確認する方法も含まれます。診断の成果物も、警告一覧を渡すだけとは限りません。問題の箇所、発生条件、想定される影響、対策を整理して、修正する担当へつなげることが重要です。「脆弱性診断では悪用可能性や影響を一切確認しない」という説明は適切ではありません。

ペネトレーションテストでは、たとえば「許可されていない権限で特定の業務データへ到達できるか」という目的を設定し、想定した経路と許可された手法で検証します。複数の弱点を組み合わせた場合の影響を確認することもあります。一方で、限られた期間とシナリオに沿う検証なので、すべての脆弱性を網羅的に発見する保証にはなりません。目的を達成できなかった場合も、その条件で確認した結果として解釈します。

比較点	脆弱性診断	ペネトレーションテスト
主な問い	定めた対象・項目にどのような弱点があるか	定めた攻撃目的やシナリオが成立するか
進め方	ツールと手動確認を対象に応じて組み合わせる	合意した経路・手法で目的への到達を検証する
報告で見る点	箇所、条件、影響、対策、確認できなかった範囲	検証経路、成立条件、影響、制約、対策

IPAが公開する「脆弱性診断内製化ガイド」も、自動・手動の診断と、攻撃目的の成立を検証するテストの違いを説明しています。両者は名称だけで優劣を決めるものではなく、何を確認したいかに応じて使い分けます。サービスによって呼称や含む作業が異なるため、提案書の目的・対象・成果物で比較します。

ブラックボックス、グレーボックス、ホワイトボックスという分類は、提供する情報の範囲を説明するために使われます。設計書やコード、テスト用アカウント等をどこまで提供するかを具体的に決めます。グレーボックスを必ず内部不正者の想定としたり、ホワイトボックスなら全機能を完全に検証できるとしたりする必要はありません。外部・内部などの攻撃の出発点と、検証者へ渡す情報の範囲は分けて整理します。

実施前に決めること：対象・許可・停止条件を具体化する

準備では、守る業務と確認したいリスクを明確にします。公開Web、API、社内システム、クラウド等の名称だけでは、対象範囲は確定しません。ドメインや環境、機能、利用者の権限、外部サービスとの接続、対象の版と設定を確認し、含むものと除外するものを合意します。ログインが必要な機能を調べるなら、必要な役割ごとのアカウントと、使ってよい検証データを用意します。テスト環境で行う場合は、本番との差異が結果の解釈にどう関係するかも記録します。

実施のルールは開始前に決めます。NISTのRules of Engagement（ROE）の定義は、テストの実行に関する詳細な指針と制約を、事前に定めるものとしています。参考資料であるSP 800-115（2008年）の計画・ROEの考え方も、対象、許される行為、連絡、データ取扱い等を確認する際に使えます。古い資料の個別ツールを現行の推奨として採用することとは分けます。

合意する項目	具体化する内容の例
範囲と到達目標	対象環境・機能・権限、確認する経路、対象外の連携先
実施条件	期間、時間帯、送信元、許可する手法、負荷や更新を伴う操作
停止と連絡	異常時の停止基準、連絡先、判断者、再開の条件
データ管理	検証用データ、証跡の保存・閲覧・受渡し、保管期間と終了後の扱い
成果物	速報、最終報告、説明、修正支援と再確認の範囲

特に、注文、通知メール、外部決済、ファイル削除等の処理は、検証中の操作が実業務へ影響する可能性があります。どの操作を許可し、どのように影響を抑えるかを関係者と確認します。第三者のクラウドや委託先を利用する場合も、所有者だけの判断で接続先すべてを対象にせず、必要な条件を確認します。テスト中に想定外の情報や実際の侵害の兆候を見つけた場合の連絡・中断も、事前の手順へ含めます。

準備資料は、情報を多く渡すこと自体が目的ではありません。システム構成、データの流れ、役割別の操作、保守の担当等を、必要な範囲で共有するためのものです。対象を決めた後に機能や構成が変わった場合には、合意した範囲と条件を見直します。

自動化・AI・手動検証をどう組み合わせるか

自動スキャンは、対応する検査を繰り返し実行し、調査候補を集めるために役立ちます。ただし、検査を起動できたことと、必要な機能まで確認できたことは異なります。ログインに失敗して公開画面しか見ていない、権限の異なる利用者を区別していない、対象のAPIへ到達していない、といった場合は、その範囲を結果に残します。警告が出なかったという事実だけを、対象システム全体の安全性と読み替えないことが大切です。

ZAPのアクティブスキャンの公式説明も、対象へ攻撃を試みる検査であることと、検出できる問題の種類に限界があることを説明しています。ツールを使う検査も、合意した対象と実施条件の中で行います。ツールの結果には誤検知や見落としがあり得るため、対象の仕様や権限を踏まえた確認が必要です。「自動なら安全に無制限で実施できる」「手動なら未知の問題をすべて発見できる」という前提はいずれも置きません。

AIを使う場合は、作業ごとに役割を分けます。コードや警告の整理、検証候補の作成、修正案や報告文の下書きなどと、実際のアクセスや変更を伴う操作は別です。ツールが提案した経路へ接続してよいか、どのデータまで渡せるか、結果を誰が確認するかを定めます。製品名にAIが含まれていることだけで、優先順位や悪用可能性の判断が自動的に正しくなるわけではありません。対応機能、入力、解析方法、出力の根拠を確認します。

比較するなら、同じ対象と条件で、確認できた機能、問題の再現性、誤検知の確認工数、修正につながる情報を見ます。「AIツールの普及率は何％」「手動なら何倍発見できる」といった、対象や測定方法が明らかでない数値を自社の判断根拠にはしません。業務固有の権限や処理の関係をどう確認するかを先に定め、繰り返せる部分を自動化すると、検証担当の役割が明確になります。

日常のコード・依存部品の確認は、DevSecOpsとCI/CDのセキュリティ運用へつなげられます。部品の一覧と製品の版を結び付けるSBOMの管理も、既知の脆弱性を調べる基礎になります。定期的な実行と、目的を定めた検証を組み合わせ、確認した範囲を追える状態にします。

診断結果を修正へつなぐ：報告書と再確認の要件

報告書は、検出件数の多さだけで評価しません。開発担当が修正に使え、業務責任者が影響と対応の順序を判断できることが重要です。対象の環境・版・実施時点、検査した範囲と手法、確認できなかった項目を最初に明示します。個々の問題では、該当箇所、成立する条件、再現に必要な情報、想定される影響、根拠、対策を整理します。自動ツールの出力をそのまま最終的な問題一覧とせず、確認状況を区別します。

OWASP WSTG 4.2の報告に関する説明は、問題の種類、脅威、原因、検査手法、対策、深刻度などを挙げています。診断項目を合意する際にも、使用する資料や項目の版を記録すると、後から何を確認したかを追えます。深刻度のスコアは判断材料の一つです。インターネットからの到達性、必要な権限、対象データ、業務への影響、既存対策等も踏まえて優先順位を決めます。

ペネトレーションテストで目的へ到達できた場合は、どの条件と経路が重なったかを整理します。逆に到達できなかった場合には、制約や未実施の範囲を含めて説明します。確認していない経路まで安全と結論付けたり、実証した範囲を越えて被害額や全顧客への影響を断定したりしないようにします。重大な問題を見つけた際は、最終報告まで待たずに連絡する基準も、事前の合意へ含めます。

修正計画には、担当、期限、依存する作業、更新先、確認する環境を記載します。直ちに修正できない場合は、代替策や残るリスク、承認者、期限と見直す条件を残します。修正後は、元の問題が再現しないことに加え、必要な動作・権限の確認を行います。コードだけ更新して稼働環境へ適用していない場合や、別の版を再検査した場合は、同じ完了状態として扱えません。

結果は、個別の修正だけでなく、同じ原因を持つ機能や開発の仕組みの見直しにも使います。たとえば認証・権限の問題であれば、ログイン方式、復旧経路、利用者が操作できる範囲を合わせて確認します。多要素認証の方式と限界やパスキーと復旧の設計を参照しながら、診断時点で終わらない改善へつなげます。

APIの検証範囲を具体化するときは、APIセキュリティとOWASP Top 10の実践ガイドも参照してください。認証とデータ・項目・機能の認可、処理量の制御、実行時の監視を分けて整理しています。診断で確認する範囲と、日常の開発・運用で継続する確認を揃える際に役立ちます。

費用・頻度・依頼先を決めるときの判断軸

費用は「Webサイト一つなら一律いくら」という数字だけでは比較できません。同じサイト名でも、機能、API、利用者の権限、対象環境、提供資料、検査項目、シナリオ、手動確認、再確認の範囲で作業が変わります。複数の見積もりを比べるときは、対象外の機能、準備を誰が行うか、速報と報告説明、修正の相談、再確認に含む回数や条件をそろえます。診断費用に加えて、自社で行う準備と修正の工数も確保します。

実施頻度は、公開・変更の頻度、扱う情報、外部への接点、現在の脅威、契約や適用要件から決めます。すべての企業に同じ「年1回」「毎月」という回数を当てはめる説明は避けます。定期的な確認に加え、新機能の公開、認証・権限の変更、構成の移行、重要な脆弱性情報の公表などを、対象と手法を再検討するきっかけにします。要求がある場合は、その規則の対象と条項、スキャンと侵入テストのどちらを求めるかまで確認します。法令・契約・推奨実務を混同して、一括して義務化と結論付けないことが必要です。

内製と外部委託も、どちらか一方で統一する必要はありません。日常の変更に合わせて行う検査と、専門家が目的を定めて行う検証を分担する方法があります。外部へ依頼しても、事業上の優先順位、対象データ、修正の責任、公開判断は社内で整理する必要があります。依頼先は、名称やツールの一覧だけでなく、対象の技術・業務への理解、実施ルール、根拠を示す報告、修正後の確認条件で評価します。

renueのAI脆弱性診断支援サービスでは、業務とシステム構成を確認し、診断対象・検証環境・使用するAIやツールを決めます。コード分析と既知の脆弱性の確認、認証・権限や外部接点の検証を組み合わせ、結果を該当箇所・想定影響・改善方法と優先順位へつなげます。コード受領型と現場常駐型等から、環境の制約に合わせて進め方を相談できます。

提供形式を具体的に確認する場合は、2026年10月9日のAI脆弱性診断支援サービスの開始告知も参照できます。コード受領・現場常駐・ローカルLLMの条件と、診断後の対応範囲を整理しています。現在の提供内容はサービスページを確認し、診断と改修・移行の作業範囲を分けて相談してください。

診断で確認した技術的な弱点は、データの扱い、利用者への説明、修正の責任者や事故対応の流れにもつなげます。組織全体の点検方法はデジタルトラストの実践ガイドを参照してください。技術診断で確認した範囲と、別途検討するプライバシーや運用の課題を分けると、診断の実施だけを全体の対策完了と誤解しにくくなります。

侵入テストは事前に合意した範囲とテスト環境で行い、診断後の改修・刷新も別途範囲を合意して支援します。まずは、対象システム、扱う情報、公開・連携先、困っている点を整理するところからご相談ください。検査を実施した事実だけで完了にせず、何を確認し、何が残り、誰がどの対策を進めるかを明確にします。