ペネトレーションテストと脆弱性診断の違い｜目的・手法・頻度・使い分けを比較|セキュリティ対策Lab

投稿日時: 2026年09月24日更新日時: 2026年09月24日

ペネトレーションテストと脆弱性診断の最大の違いは、「弱点を見つけること」を中心にするか、「その弱点を攻撃者が悪用した場合に何を達成できるか」を検証するかです。

脆弱性診断は、Webアプリケーション、サーバー、ネットワーク機器などから脆弱性や設定不備を広く発見し、修正につなげます。ペネトレーションテストは、攻撃シナリオを設定し、侵入、権限拡大、横展開、重要資産への到達といった攻撃経路を許可された範囲で検証します。

両者は代替関係ではありません。英国NCSCは、ペネトレーションテストを脆弱性管理の主要な代替手段ではなく、組織の脆弱性評価・管理プロセスが有効かを確認する保証手段として位置付けています。

ペネトレーションテストと脆弱性診断の違いを比較

比較項目	脆弱性診断	ペネトレーションテスト
主な目的	脆弱性・設定不備を発見する	攻撃者が弱点を悪用した場合の侵入可能性と影響を検証する
基本的な問い	どこに弱点があるか	その弱点から何を達成できるか
対象	Web、API、OS、ミドルウェア、ネットワーク、クラウドなど	システム横断の攻撃経路、境界、内部ネットワーク、Web、認証基盤など
手法	自動スキャン＋手動確認	手動中心の攻撃シナリオ、脆弱性の組み合わせ、侵入後の検証
網羅性	広い範囲の弱点を洗い出しやすい	特定のシナリオを深く確認する
悪用確認	必須ではない	許可された範囲で悪用可能性を検証する
侵入後の横展開	通常は主目的ではない	主な検証対象になり得る
実施頻度	継続的・定期的な実施に向く	定期、重要変更時、特定リスクを確認したいとき
必要なスキル	診断対象に応じた専門知識	攻撃手法、複数技術領域、攻撃経路分析の専門性
成果物	脆弱性一覧、重要度、修正方法	攻撃経路、到達範囲、事業影響、改善策
向く目的	弱点を漏れなく減らしたい	現在の防御で実際に攻撃を止められるか確かめたい

オーストラリア政府のInformation Security Manual（ISM）も、脆弱性スキャン・脆弱性評価・ペネトレーションテストを別の活動として整理しています。

ISMでは、脆弱性スキャンはソフトウェアツールによる既知脆弱性の自動確認、脆弱性評価はアーキテクチャレビューや詳細なハンズオン評価を含む活動です。これに対しペネトレーションテストは、重要なシステムやデータを侵害するなど、現実の攻撃シナリオで特定の目標を達成できるかを確かめる評価とされています。

脆弱性診断は「弱点を広く見つける」

脆弱性診断の中心は、修正すべき弱点を発見することです。

対象によって確認内容は異なりますが、代表的には次のような問題を探します。

既知CVEを含む古いソフトウェア
未適用のセキュリティ更新
不要な外部公開ポート
弱い暗号設定
Webアプリケーションの入力値処理不備
認証・認可の不備
クラウドやデータベースの公開設定ミス
管理画面やデバッグ機能の露出

NIST SP 800-53のRA-5では、脆弱性の監視とスキャンを、組織が定めた頻度で実施するほか、新しい脆弱性が対象システムへ影響する可能性がある場合にも行う考え方を示しています。

脆弱性診断は、1回のイベントよりも継続的な脆弱性管理の一部として扱う方が制度設計に合います。

詳しくは脆弱性診断とは？目的や種類、実施頻度をUS・UK公的機関の推奨から解説で整理しています。

ペネトレーションテストは「弱点をつないだときの影響を見る」

NISTはペネトレーションテストについて、自動化された脆弱性スキャンより踏み込んだ評価であり、攻撃者の行動を模してセキュリティ上の弱点を分析すると説明しています。

単独の脆弱性では重大に見えない問題でも、複数を組み合わせると大きな影響につながる場合があります。

たとえば、

インターネット公開サービスから初期アクセスを得る
一般ユーザーの権限を取得する
設定不備や認証設計を利用して権限を拡大する
ネットワークを横断する
重要サーバーや機密情報へ到達する

という攻撃経路が成立するかを検証します。

NIST SP 800-53のCA-8は、ペネトレーションテストについて、脆弱性を検証し、指定された時間・リソース・スキルの範囲でシステムが攻撃へどの程度耐えられるかを判断できるとしています。

違い1：目的は「発見」か「影響確認」か

脆弱性診断では、弱点を見つけて修正対象を増やすことが目的です。

ペネトレーションテストでは、すでに把握している弱点や攻撃者が発見できる弱点を使い、「どこまで被害が広がるか」を確認します。

NCSCは、理想的にはペネトレーションテストを実施する前に、組織自身がテスターの発見内容をある程度予測できている状態が望ましいとしています。

つまり、

脆弱性診断
→「VPNに脆弱性がある」

ペネトレーションテスト
→「VPNが侵害された状態から、どのアカウントを使い、どのサーバーまで到達できるか」

という違いです。

違い2：網羅性は脆弱性診断、攻撃経路の深さはペネトレーションテスト

脆弱性診断は、決めた診断項目に沿って広く確認しやすい方法です。自動スキャナーを利用すれば、多数のサーバーやネットワーク機器を定期的に確認できます。

CISAのCyber Hygiene Servicesも、インターネット公開資産を継続的にスキャンし、既知脆弱性や設定上の問題を通知する仕組みです。

一方、ペネトレーションテストは期間と工数が決まっています。

英国NCSCは、Closed box型テストでは対象情報が少ないため、実際には存在する脆弱性でもテスト期間内に発見できない場合があると説明しています。

そのため、

多数の資産を継続的に確認する → 脆弱性スキャン・診断
特定の攻撃経路を深く検証する → ペネトレーションテスト

という役割分担が現実的です。

違い3：単一の脆弱性か、複数の弱点の組み合わせか

脆弱性診断では、個別の弱点を1件ずつ検出し、重要度や修正方法を整理することが一般的です。

ペネトレーションテストでは、単独では低・中程度に見える弱点でも、他の設定不備や過剰な権限と組み合わせた場合の影響を確認します。

NIST SP 800-115は、ペネトレーションテストの多くが、単一または複数システム上の脆弱性の組み合わせを調べ、単一の脆弱性だけでは得られないアクセス権を取得できるか確認すると説明しています。

この違いは、CVSSなど単一の脆弱性スコアだけでは判断しにくい「自社環境での実害」を確認するときに表れます。

違い4：実施頻度が異なる

脆弱性は継続的に公開されるため、脆弱性スキャン・診断は高い頻度で回す必要があります。

NIST RA-5は、組織が定めた頻度に加え、新たな脆弱性が対象システムへ影響する可能性がある場合のスキャンも示しています。

一方、NIST CA-8ではペネトレーションテストの頻度を「organization-defined」としており、組織がリスクに応じて決めます。

オーストラリア政府ISMでは、同フレームワークの対象システムについて、導入前、重大な変更前、その後少なくとも6カ月ごとに脆弱性評価とペネトレーションテストを実施する管理策を示しています。

この「6カ月」は日本企業へ一律に適用される義務ではありません。実務では、

外部公開の重要システムか
個人情報や機密情報を扱うか
構成変更の頻度が高いか
規制や顧客契約で条件があるか
攻撃者から狙われやすい業務か

を基に頻度を決めます。

違い5：結果の読み方が異なる

脆弱性診断では、「何件の脆弱性があり、どの重要度か」を確認します。

ペネトレーションテストでは、件数だけを見ると判断を誤ります。

重要なのは、

初期侵入できたか
どの権限を取得したか
ネットワーク分離を越えられたか
重要システムへ到達できたか
機密情報へアクセス可能だったか
EDRやSOCが行動を検知したか

です。

重大な攻撃経路が1本成立するだけでも、数十件の軽微な診断結果より優先して対応すべき場合があります。

どちらを実施すべきか

「脆弱性診断か、ペネトレーションテストか」の二択ではなく、確認したい課題で判断します。

自社の課題	向く方法
インターネット公開資産の既知脆弱性を定期確認したい	脆弱性スキャン
WebアプリのSQLインジェクションや認可不備を調べたい	Webアプリ脆弱性診断
サーバー・VPN・FWの設定不備を広く確認したい	プラットフォーム／ネットワーク脆弱性診断
VPNが侵害された後、重要サーバーまで到達できるか知りたい	ペネトレーションテスト
一般ユーザーのアカウントから管理者権限へ昇格できるか知りたい	ペネトレーションテスト
ネットワーク分離やゼロトラスト設計の実効性を確認したい	シナリオ型ペネトレーションテスト
SOCが攻撃行動を検知・対応できるかまで確認したい	ペネトレーションテスト／レッドチーム演習
新規リリース前に弱点を広く確認したい	脆弱性診断＋必要に応じてペネトレーションテスト

NCSCは、特定のシナリオについて追加の保証が必要な場合、対象を絞ったペネトレーションテストが有効としています。

脆弱性診断だけでは不足するケース

脆弱性診断で「Criticalが0件」でも、攻撃経路が存在しないとは限りません。

たとえば、

複数のMedium脆弱性を組み合わせる
権限設定の不備を利用する
侵害した一般アカウントから管理系へ移動する
本来分離されるネットワーク間を横展開する
監視されていない管理経路を利用する

といった経路は、個々の診断項目を見るだけでは全体の影響が分かりにくい場合があります。

2026年のデジタル庁GSSへの不正アクセスでは、当初CVSS「Medium」と評価されていたVPN機器の脆弱性が侵入経路として悪用され、侵入後には保守運用担当者のアカウントを利用した大量のファイルアクセスが確認されました。

デジタル庁 GSSへの不正アクセス、保守運用アカウントの権限とゼロトラスト設計を検証

この事案について、ペネトレーションテストを実施していれば防止できたと断定することはできません。ただし、「境界機器が侵害された後にどこまで到達可能か」を確認するシナリオテストが必要になる理由は理解できます。

ペネトレーションテストだけでも不足する

逆に、年1回のペネトレーションテストだけで脆弱性管理を代替することもできません。

NCSCは、ペネトレーションテストが確認できるのはテスト時点の状態であり、テスト間隔が1年以上空けば、その間に新しい脆弱性が長期間残る可能性があると説明しています。

セキュリティ対策Labで取り上げた個人情報保護委員会の2026年度第1四半期資料では、

VPN機器の既知脆弱性放置
ECサイト関連アプリケーションの既知脆弱性放置
弱いID・パスワード
データベースのアクセス制御不備
RDPの不適切な外部公開
サーバーの全ポート公開

などが実際の不正アクセス事案で確認されています。

個人情報保護委員会、第1四半期に141件を指導　ランサムウェア15件、VPN脆弱性放置や弱い認証を問題視

これらの多くは、ペネトレーションテストを待たず、資産管理、脆弱性スキャン、設定管理、パッチ管理で継続的に発見・是正すべき問題です。

Webアプリケーションでは両方をどう使い分けるか

2024年末に「くすりのしおりデータベース」が受けた攻撃では、Webサイトの脆弱性を原因とするSQLインジェクションによってデータベースが改ざんされました。

くすりのしおり、SQLインジェクションによるサイバー攻撃の調査結果と再発防止策を発表

Webアプリケーションでは、まず脆弱性診断でSQLインジェクション、XSS、認証・認可不備、設定ミスなどを確認します。

そのうえで、重要なサービスではペネトレーションテストを使い、

発見した弱点からどのデータへ到達できるか
一般ユーザーから管理機能へ到達できるか
Webサーバー侵害後に内部ネットワークへ移動できるか
APIや管理機能を組み合わせると権限外操作が成立するか

など、実際の攻撃経路を確認できます。

公開情報だけから、当該事案が事前の診断やペネトレーションテストで防げたとは判断できません。事例は、外部公開サービスに対して継続的な脆弱性管理と、必要に応じた攻撃経路の検証を組み合わせる理由を示す材料として扱うのが適切です。

脆弱性診断とペネトレーションテストを組み合わせる流れ

両者を別々のイベントにせず、一つの脆弱性管理サイクルに入れると使いやすくなります。

1. 資産を把握する

外部公開資産、社内システム、クラウド、Webアプリ、API、VPN、ネットワーク機器を棚卸しします。

2. 継続的にスキャン・診断する

既知脆弱性、パッチ未適用、設定不備、Webアプリケーションの問題を定期的に確認します。

3. リスクの高いシナリオを選ぶ

診断結果だけでなく、資産の重要度、公開範囲、実悪用情報、権限、ネットワーク接続関係を見て、「侵害された場合に何が起きるか」を確認すべき対象を選びます。

4. ペネトレーションテストで攻撃経路を検証する

「VPN侵害後の横展開」「Webアプリ侵害から顧客DBへの到達」「一般アカウントから管理権限取得」など、事業リスクにつながるシナリオを確認します。

5. 修正後に再確認する

脆弱性を修正し、重大な攻撃経路については再診断・再テストで遮断できたか確認します。

NCSCは、ペネトレーションテストで新たに発見された問題があれば、「なぜ通常の脆弱性評価で見つからなかったのか」まで確認し、内部の脆弱性管理プロセス改善へ戻す考え方を示しています。

発注時に間違えやすいポイント

「脆弱性診断」と「ペネトレーションテスト」は、サービス会社によって名称や提供範囲が異なる場合があります。

名称だけで判断せず、提案書や仕様書で次を確認します。

目的は脆弱性の網羅的な発見か、攻撃シナリオの検証か
自動ツールだけか、専門家による手動検証を含むか
脆弱性を実際に悪用して影響を確認するか
権限昇格や横展開まで対象にするか
外部ネットワークだけか、内部ネットワークも含むか
Web、API、クラウド、認証基盤のどこまで対象か
本番環境で実施するか、検証環境で実施するか
レポートに攻撃経路と事業影響が含まれるか
修正後の再診断・再テストを含むか

「ペネトレーションテスト」という名称でも、実際にはスキャナー中心の脆弱性確認に近いサービスであれば、期待した攻撃経路の検証ができない可能性があります。

情報システム部門が使い分けるための確認項目

次の質問に答えると、どちらを優先するか整理しやすくなります。

自社の外部公開資産をすべて把握できているか
既知脆弱性を継続的にスキャンする仕組みがあるか
Webアプリのリリース前診断が運用に組み込まれているか
発見した脆弱性の修正期限と例外承認が決まっているか
「侵入された後」の攻撃経路を検証したことがあるか
一般ユーザーから管理者権限へ到達できないことを確認しているか
VPN、管理ネットワーク、重要サーバーの分離を実地検証しているか
EDR・SIEM・SOCが攻撃行動を検知できるか確認しているか
大規模な構成変更後にセキュリティ評価を行っているか

前半の項目が不足している場合は、まず脆弱性管理の基盤整備が優先されます。後半の項目を確認したい場合は、ペネトレーションテストを組み合わせる余地があります。

まとめ

脆弱性診断は「弱点を広く発見して修正する」、ペネトレーションテストは「弱点を攻撃者が利用した場合に、どこまで侵害できるかを検証する」という役割の違いがあります。

NIST、NCSC、オーストラリア政府ISMはいずれも、ペネトレーションテストを自動スキャンより踏み込んだ評価として扱っています。一方、NCSCはペネトレーションテストだけで日常の脆弱性管理を置き換えないよう示しています。

企業では、脆弱性診断を継続的な弱点管理に使い、重要システムや高リスクな攻撃経路についてペネトレーションテストで実効性を確認する形に分けると、それぞれの目的が重なりにくくなります。

ペネトレーションテストと脆弱性診断の違い｜目的・手法・頻度・使い分けを比較