---
title: "脆弱性診断とペネトレーションテストの違い"
description: "脆弱性診断（弱点を広く列挙する）とペネトレーションテスト（弱点を悪用して目標への到達を確かめる）の定義と種類、目的・範囲・深さの違い、使い分けと順番、結果の限界を整理します。"
canonical: https://uniquex-knowledge-center.pages.dev/security/vulnerability-assessment
type: "解説"
domain: "security"
chapter: 3
section: "3.1"
keywords: ["脆弱性診断とペネトレーションテストの違い"]
aliases: ["CVSS"]
entities: []
sources: [{"title":"SP 800-115: Technical Guide to Information Security Testing and Assessment","author":"Karen Scarfone、Murugiah Souppaya、Amanda Cody、Angela Orebaugh","year":"2008","publisher":"NIST","version":"Final（2008 年 9 月）","url":"https://csrc.nist.gov/pubs/sp/800/115/final","accessed":"2026-10-08"},{"title":"安全なウェブサイトの作り方","author":"独立行政法人 情報処理推進機構（IPA）","year":"2015","publisher":"独立行政法人 情報処理推進機構（IPA）","version":"改訂第 7 版（2015 年 3 月 12 日公開、2021 年 3 月 31 日 第 4 刷）","url":"https://www.ipa.go.jp/security/vuln/websecurity/about.html","accessed":"2026-10-08"},{"title":"情報セキュリティサービス基準適合サービスリスト","author":"独立行政法人 情報処理推進機構（IPA）","year":"2026","publisher":"独立行政法人 情報処理推進機構（IPA）","version":"2026 年 9 月 18 日 更新分（ページ更新 2026 年 10 月 1 日）","url":"https://www.ipa.go.jp/security/it-service/service_list.html","accessed":"2026-10-08"}]
author: "UNIQUEX 編集部"
reviewer: ""
published: 2026-10-08
updated: 2026-10-09
verified: 2026-10-08
---

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

> 脆弱性診断とは、システムやアプリケーションに存在する既知の弱点を、所有者の許可を得た対象に対して検査し、見つかった弱点と対策の方向を報告する作業です。ペネトレーションテスト（侵入試験）とは、許可を得た対象に対して攻撃者の手法を模し、弱点の悪用と目標への到達を実際に試みて、どこまで侵入できるかと検知・対応の状況を確かめる検査です。診断は弱点が存在する可能性を広く浅く列挙し、ペネトレーションテストは複数の弱点の組み合わせで目標まで到達できるかを狭く深く追います。順番は診断と修正が先で、ペネトレーションテストは重要なデータや権限が実際に守れているか、検知と対応の体制が働くかを確かめたいときに依頼します。どちらの結果も、検査した時点・範囲・項目の中だけで有効で、検出なしや侵入できなかったことは安全の保証ではありません。



脆弱性診断とは、システムやアプリケーションに存在する既知の弱点（脆弱性）を、所有者の許可を得た対象に対して検査し、見つかった弱点と対策の方向を報告する作業です。ペネトレーションテスト（侵入試験）とは、許可を得た対象に対して、攻撃者が使う手法を模して弱点の悪用と目標への到達を実際に試み、どこまで侵入できるかと、検知と対応の状況を確かめる検査です。どちらも許可のない検査は相手にとって攻撃と区別がつきません。この節は発注側の視点で両者を区別し、実施の手順や道具は扱いません。

## 脆弱性診断の定義と種類 [#脆弱性診断の定義と種類]

対象、方式、視点の三つの分け方があります。依頼のときは三つをそれぞれ決めます。

| 分け方 | 種類                      | 主に見つかるもの                                                |
| --- | ----------------------- | ------------------------------------------------------- |
| 対象  | Web アプリケーション診断          | 入力の扱い、認証とセッション、認可の不備（IPA「安全なウェブサイトの作り方」第 1 章の 11 種類が土台） |
| 対象  | プラットフォーム（ネットワーク・サーバー）診断 | 古いソフトウェアの版、未適用の修正、設定の誤り                                 |
| 対象  | スマートフォンアプリ診断、クラウド設定診断   | 端末内のデータの扱い、公開範囲や権限の設定                                   |
| 方式  | ツール（自動）、手動、組み合わせ        | 自動は既知の型を広く、手動は業務固有の処理を深く                                |
| 視点  | 外部から、内部から               | 外部は公開面の弱点、内部は境界の内側から見える弱点（NIST SP 800-115）              |

## ペネトレーションテストの定義と種類 [#ペネトレーションテストの定義と種類]

発注のときに決める三つの軸で分けます（NIST SP 800-115）。

| 軸      | 種類                                         | 向く目的                             |
| ------ | ------------------------------------------ | -------------------------------- |
| 視点     | 外部から（インターネット側から境界を越える）、内部から（境界の内側に足場がある前提） | 外部は公開面の守り、内部は侵入後の広がりと内部不正への備え    |
| 情報の与え方 | 与えない（外部の攻撃者を模す）、与える（構成や認証情報を渡し、内部者や侵入後を模す） | 与えないと実態に近く、与えると期間内に深く見られる        |
| 周知     | 運用担当に周知する、経営層の許可のもとで運用担当に知らせない             | 周知すると影響を抑えやすく、知らせないと検知と対応の体制を試せる |

運用担当に知らせない形は「攻撃者がどこまで被害を出せるか」と「体制が気づけるか」を見るもので、実際の攻撃と区別するために検査を知っている窓口を 1 人置きます。

## 目的・範囲・深さの違い [#目的範囲深さの違い]

| 観点        | 脆弱性診断             | ペネトレーションテスト                         |
| --------- | ----------------- | ----------------------------------- |
| 目的        | 弱点を網羅的に列挙する       | 目標（データや権限）まで到達できるかを確かめる             |
| 確かめ方      | 弱点が存在する可能性を確認する   | 弱点を実際に悪用して存在と影響を確認する                |
| 範囲        | 広く浅く              | 狭く深く。複数の弱点の組み合わせを追う                 |
| 結果の形      | 弱点の一覧と深刻度         | 到達した経路と影響、検知と対応の状況                  |
| 対象が止まる可能性 | 低いが、自動検査の負荷で起こりうる | 経験のある実施者でもゼロにはならない（NIST SP 800-115） |

診断が「可能性の確認」で、ペネトレーションテストが「悪用による確認」である点が、両者を分ける線です（NIST SP 800-115）。

## 使い分けと順番 [#使い分けと順番]

順番は診断と修正が先です。既知の弱点を直さないままペネトレーションテストを行うと、そこから入られて終わり、組み合わせの経路や体制の確認には届きません。診断は、公開前、認証や決済など重要な機能の変更後、定期の三つの機会を決めて繰り返します。ペネトレーションテストが必要になるのは次の場面です。

* 診断と修正を済ませ、重要なデータや権限が実際に守れているかを確かめたいとき
* 複数の弱点の組み合わせで、外から内部のどこまで届くかを知りたいとき
* 検知と対応の体制（監視、連絡、遮断）が働くかを試したいとき

診断や復旧の体制が無い段階では、ペネトレーションテストより先にそちらを整えます。

## 成り立つ条件と結果の限界 [#成り立つ条件と結果の限界]

どちらの検査も、次の四つが決まって初めて成り立ちます。許可と連絡体制の文書は [3.3](/security/assessment-authorization-and-contacts)、対象と範囲の決め方は [3.2](/security/ordering-a-vulnerability-assessment) で扱います。

* 許可。対象の所有者または管理者の承認、実施期間、実施元、停止手順を文書にします。
* 範囲。検査する URL やホスト、アカウントの種別、範囲外の対象を一覧にします。ペネトレーションテストでは「何に到達できたら成功か」の目標も文章にします。
* 環境。本番か検証環境か、検証環境なら本番との差分（WAF の有無、外部連携）を書きます。
* 基準。検査項目と深刻度の付け方（CVSS か依頼側の基準か）、ペネトレーションテストでは許す手法の線引き（人をだます手法や物理的な侵入を含めるか）を先に決めます。

検出なしは、検査した時点、範囲、項目の中で見つからなかったという意味で、安全の保証ではありません（IPA も「ウェブ健康診断」について、安全宣言には繋がらないと説明しています）。自動検査は既知の型との照合が中心なので、誤検知と、業務固有の処理の見逃しがあります（NIST SP 800-115）。ペネトレーションテストの結果も、決めた目標・範囲・期間の中での到達の有無だけを示し、「侵入できなかった」は「安全」ではありません。

## 依頼のときに決めることと詰まり [#依頼のときに決めることと詰まり]

* 誰に。自社でツールを回す方法と、外部に依頼する方法があります。外部なら、IPA の「情報セキュリティサービス基準適合サービスリスト」に脆弱性診断サービス（ペネトレーションテストは付記）として載っているかが 1 つの目安です（掲載は品質の保証ではありません）。
* 報告書の形。診断では検出箇所、再現条件、深刻度、根拠、対策の方向を、ペネトレーションテストでは到達した経路、根拠、影響、直す順番の提案に加えて、侵入できなかった場合も試した範囲を書いてもらいます。
* 結果の読み方。ツールが付けた深刻度をそのまま受け取らず、自社の環境での影響（外部から認証なしで届くか、個人情報や決済に触れるか）を重ねて直す順番を決めます（NIST SP 800-115 も評価者の判断を求めています）。深刻度の読み方は [2.3](/security/cvss-epss-kev) にまとめています。

よくある詰まりは、再診断の条件を決めずに依頼して修正の確認が取れないこと、報告書の項番の順に直して重要な項目が後回しになること、範囲を決めずに「全部」と依頼すること、知らせない形のペネトレーションテストで窓口を置かず監視チームが本物の攻撃として対応することです。


## 参考文献

- Karen Scarfone、Murugiah Souppaya、Amanda Cody、Angela Orebaugh. SP 800-115: Technical Guide to Information Security Testing and Assessment (2008). NIST、Final（2008 年 9 月）. https://csrc.nist.gov/pubs/sp/800/115/final（参照日 2026-10-08）
- 独立行政法人 情報処理推進機構（IPA）. 安全なウェブサイトの作り方 (2015). 独立行政法人 情報処理推進機構（IPA）、改訂第 7 版（2015 年 3 月 12 日公開、2021 年 3 月 31 日 第 4 刷）. https://www.ipa.go.jp/security/vuln/websecurity/about.html（参照日 2026-10-08）
- 独立行政法人 情報処理推進機構（IPA）. 情報セキュリティサービス基準適合サービスリスト (2026). 独立行政法人 情報処理推進機構（IPA）、2026 年 9 月 18 日 更新分（ページ更新 2026 年 10 月 1 日）. https://www.ipa.go.jp/security/it-service/service_list.html（参照日 2026-10-08）

## 更新履歴

- 2026-10-08: 初版（題「脆弱性診断とは」。「ペネトレーションテストとは」は別ページ）
- 2026-10-08: 書籍型の目次に合わせて改題・再構成（「ペネトレーションテストとは」を統合）
- 2026-10-09: 監修実施の記録がないため監修者表示を未実施へ訂正。本文の全主張を再確認した日ではない
