脆弱性診断とペネトレーションテストの違い|発注前に押さえる分岐点
著者・監修: 依田尚人(YDAIコンサルティング株式会社 代表)
脆弱性診断とペネトレーションテストの違い|発注前に押さえる分岐点
脆弱性診断は弱点の把握を目的にし、ペネトレーションテストは想定した目的に対する検証を行うため、発注時は目的と承諾範囲で使い分けます。名称の違いだけで二者択一にせず、確認したい対象、必要な成果物、実施できる範囲を先に整理することが大切です。
発注者は、依頼先に技術的な作業を任せる前に、管理下の資産と承諾を得られる範囲を確定します。ここでは攻撃手法の手順には踏み込まず、調達時に比較するための目的、範囲、確認先の分け方を説明します。
脆弱性診断とペネトレーションテストの違い
脆弱性診断とペネトレーションテストの違いは、発注者が主に何を判断したいかと、依頼範囲をどう定めるかにあります。両方とも対象資産と承諾範囲の確認が必要ですが、成果物に期待する説明は同じではありません。
| 観点 | 脆弱性診断 | ペネトレーションテスト |
|---|---|---|
| 主な目的 | 弱点を把握し、対応の優先順位を整理する | 想定した目的に対する検証を行う |
| 発注時の起点 | 対象の画面、機能、IP、ホストなど | 検証目的、対象範囲、実施条件 |
| 成果物で確認すること | 確認した範囲、見つかった事項、対応の整理 | 想定した目的と実施範囲、検証結果の整理 |
| 共通して決めること | 管理下の資産、承諾、対象外、連絡方法 | 管理下の資産、承諾、対象外、連絡方法 |

脆弱性診断で確認する範囲を整理する
脆弱性診断を検討するときは、確認したい資産を画面、機能、認証後の領域、ネットワーク上の資産などに分けます。対象がWebアプリケーションであれば、公開画面だけでなく、ログイン後に使う機能を対象に含めるかを明記します。プラットフォームを対象にする場合は、IPやホスト、ネットワークの境界を別の計量単位として扱います。
範囲を決める際は、対象外にする領域と理由も記録します。見つけたい事項の種類を先に細かく決めるより、どの資産をどの前提で確認するかを共有する方が、発注条件の食い違いを減らせます。受け取る報告では、確認済みの範囲と未確認の範囲が追える状態を求めると、社内の対応検討に使いやすくなります。
対象一覧は、変更予定の機能と現在運用中の機能を混ぜずに扱います。公開直前の変更や一時的な機能がある場合は、対象に含めるか、別の時期に確認するかを発注者側で決めます。依頼範囲を後から広げる必要が出たときも、当初の見積条件との差分として確認できます。
ペネトレーションテストで検討する目的を整理する
ペネトレーションテストを検討するときは、何を検証したいのかを発注目的として言葉にします。たとえば重要な業務機能への影響を確認したいのか、複数の資産にまたがる範囲を検討したいのかによって、対象、実施の制約、説明してほしい内容が変わります。名称だけを指定しても、発注条件は確定しません。
目的を定めた後は、対象資産、実施を避ける時間帯、連携先への影響、緊急時の連絡方法を文書で整理します。対象の追加や変更があり得る場合は、誰が判断するかも決めておきます。具体的な手順を依頼内容へ求めるのではなく、発注者が管理する範囲と必要な検証の目的を明確にすることが、適切な準備につながります。
成果物の説明を誰が利用するかも、目的に合わせて確認します。技術担当が対応を検討するための整理と、事業責任者や取引先へ説明するための整理では、必要な粒度が異なる場合があります。発注時に利用場面を共有すれば、報告の受け取り方を社内で準備できます。
発注目的と成果物から分岐する
発注目的と成果物から分岐するとは、手法名を先に選ぶのではなく、弱点の把握と想定した目的の検証のどちらを主に求めるかを整理することです。目的を起点にすると、対象範囲と報告書に必要な説明を対応付けやすくなります。
| 発注目的 | 先に確認する事項 | 成果物で確認する事項 |
|---|---|---|
| 弱点を把握したい | 対象資産、優先する機能、認証後画面 | 確認範囲、把握した事項、対応検討の材料 |
| 特定の目的を検証したい | 目的、対象、制約、承諾の範囲 | 目的との関係、実施範囲、検証結果 |
| 取引先へ説明したい | 質問項目、対象、期限 | 確認条件と説明に必要な範囲 |

弱点の把握を優先する場合の確認項目
弱点の把握を優先する場合は、対象に含める画面、機能、IP、ホストといった単位を明らかにします。利用者の区分や認証後の領域を含めるか、対象外の連携先があるかも、見積依頼時に確認する項目です。対象数だけで判断せず、どの範囲を数えているのかを資料と対応付けます。
成果物については、対象ごとの確認結果を社内で追えるか、対応の検討に必要な説明が含まれるかを確認します。依頼先ごとに表現や構成が異なり得るため、事前に必要な項目を伝えます。比較するときは、総額の前に対象範囲、手動で確認する範囲、認証後画面、再診断、報告会といった条件を揃えます。
取引先から質問を受けている場合は、質問票の文言をそのまま発注条件にせず、確認する資産と成果物へ置き換えます。回答に必要な情報と、診断の範囲を分けて整理することで、必要以上に対象を広げず、説明に必要な条件を残せます。
想定シナリオの検証を優先する場合の確認項目
想定した目的の検証を優先する場合は、目的を抽象的な「安全確認」にせず、業務上どの範囲について説明が必要かを整理します。対象とする資産、対象外にする資産、実施を控える条件、連絡体制を分けて文書に残します。これにより、依頼先と発注者の間で実施範囲の理解を合わせやすくなります。
承諾の確認も、この段階で行います。発注者が利用している資産であっても、アクセス管理者が別にいる領域は同じ扱いにはなりません。連携先やクラウド上のサービスを含める場合は、対象へ入れる前に管理者と範囲を確認し、承諾の有無が分からない領域を実施対象にしないことが基本です。
依頼範囲の文書には、対象の名称だけでなく、対象外、実施条件、変更時の確認先を残します。これにより、依頼先が別の領域まで確認することを想定せず、発注者側も承諾した範囲を社内で説明できます。管理者が変わる資産は、改めて確認する契機にします。
IPAリスト上の位置づけを確認する
IPAリスト上の位置づけを確認することは、発注するサービスの区分を読むための入口です。リストの掲載状況は個別のサービスを評価する結論ではなく、依頼前に区分と確認できる事項を整理する材料として使います。
| 確認する点 | 読み方 |
|---|---|
| 運営 | IPAが情報セキュリティサービス基準適合サービスリストを公表している |
| 脆弱性診断 | リストの区分の一つとして確認する |
| ペネトレーションテスト | 脆弱性診断サービスのオプションとして扱われる |
| 掲載の意味 | IPAによるいかなる保証等をも意味するものではありません |

ペネトレーションテストの位置づけを読み違えない
IPA「情報セキュリティサービス基準適合サービスリスト」では、脆弱性診断サービスとペネトレーションテスト(侵入試験)サービスが確認できます。ペネトレーションテストは脆弱性診断サービスのオプションとして示されており、完全に別のカテゴリから一方だけを選ぶものとは扱いません。2026-09-11確認。
発注者は、リストを見て候補の区分を確認した後、対象範囲、目的、成果物、実施条件を別途整理します。掲載されているかどうかだけで、対象資産に適した依頼内容か、必要な説明が得られるかを判断することはできません。比較する際にも、サービス名より先に、どの範囲をどの条件で確認する見積なのかを確認します。
リストを確認した記録には、見た区分と確認日を残します。その後の見積比較では、掲載状況と仕様の比較を同じ評価欄に混ぜず、区分の確認と発注条件の確認を別の作業として扱います。こうすると、掲載の意味を過度に広げずに確認材料として使えます。
依頼範囲と承諾を文書で確定する
依頼範囲と承諾を文書で確定することは、診断の対象を発注者の管理下にある資産へ限定し、誰が承諾するかを明らかにする準備です。不正アクセス行為の禁止等に関する法律は、脆弱性診断の実施を直接義務づける規定ではありませんが、診断対象の承諾範囲を確認する際の前提になります。
本記事で使う「〔2026年9月時点〕」は、その条番号が有効な時点を示し、確認日を示すものではありません。不正アクセス行為の禁止等に関する法律(平成11年法律第128号。現行版は令和4年法律第68号による改正の2025-06-01施行版)第2条第4項〔2026年9月時点〕と第3条〔2026年9月時点〕を、対象と承諾の確認材料として参照します。2026-09-08確認。
| 確認する対象 | 承諾を確認する相手 | 発注時に残す内容 |
|---|---|---|
| 自社管理下の資産 | アクセス管理者 | 対象、実施範囲、制約 |
| 連携先の管理領域 | 連携先のアクセス管理者 | 対象外か、承諾済みか |
| 利用者が使う領域 | アクセス管理者を優先して確認 | 利用者の承諾と混同しない |

自社管理下と第三者管理下の資産を分ける
不正アクセス行為の禁止等に関する法律第2条第4項〔2026年9月時点〕では、不正アクセス行為の類型と、承諾を得てする行為の除外が定められています。アクセス管理者の承諾を得て行う診断は、三つの類型すべてで不正アクセス行為に当たりません。発注時の標準としては、診断の承諾をアクセス管理者から得る形で範囲を確定します(出典: e-Gov 法令検索「不正アクセス行為の禁止等に関する法律」、2026-09-08確認)。
利用権者の承諾があれば足りるという整理は、他人の識別符号を入力する第一の類型に限られます。制限を免れる情報または指令を入力する第二、第三の類型では、アクセス管理者の承諾が必要です。そのため、利用者の了解だけで対象範囲を決めず、資産を管理する者と対象、時間帯、制約を文書で確認します。個別の適法性判断が必要な場面は、契約や運用の担当者と確認します。
承諾の確認は、発注者が診断の可否を判定する作業そのものではなく、対象を適切に定めるための前提です。管理下かどうかが曖昧な資産を対象候補に見つけた場合は、実施条件を決める前に管理者を確認します。文書化した範囲を、発注者、管理者、依頼先の間で同じ内容として扱うことが重要です。

よくある質問
ペネトレーションテストは脆弱性診断の代わりになるか
目的が異なるため、代替と決めつけずに対象と成果物を確認します。IPAのリストでは、ペネトレーションテストは脆弱性診断サービスのオプションとして示されています。対象資産と検証目的を整理して、必要な組み合わせを検討します(出典: IPA「情報セキュリティサービス基準適合サービスリスト」、2026-09-11確認)。
両方を同じ依頼で行えるか
依頼範囲、対象資産、成果物、実施順を見積条件に明記すれば、必要な組み合わせを検討できます。画面、機能、IP、ホストなどの対象単位を混ぜず、目的ごとに確認したい範囲を分けて記載します。条件が異なる場合は、総額を比べる前に差分を確認します。
承諾範囲はなぜ確認するのか
不正アクセス行為に当たるかの判断ではアクセス管理者の承諾が重要になるため、診断対象と承諾範囲を事前に文書で確定します。アクセス管理者の承諾を得て行う診断は三つの類型すべてで不正アクセス行為に当たりません。利用権者の承諾だけで足りる場合と混同しないことが必要です(出典: e-Gov 法令検索「不正アクセス行為の禁止等に関する法律」 第2条第4項〔2026年9月時点〕、2026-09-08確認)。
まとめ
脆弱性診断は弱点の把握、ペネトレーションテストは想定した目的に対する検証を主に整理するため、名称ではなく目的と範囲で検討します。IPAのリストではペネトレーションテストが脆弱性診断サービスのオプションとして扱われます。発注時は、管理下の資産、対象外、成果物、アクセス管理者から得る承諾を文書で確定し、条件を揃えて比較します。
発注の準備全体はセキュリティ診断の発注ガイドで確認できます。法令・制度に関する記事は法令・制度の記事一覧へ、全体のテーマはブログ一覧へ進めます。
出典
本記事の出典は に内容を確認しています。
- IPA「情報セキュリティサービス基準適合サービスリスト」(ipa.go.jp)
- e-Gov 法令検索「不正アクセス行為の禁止等に関する法律」(laws.e-gov.go.jp)
著者・監修
依田尚人YDAIコンサルティング株式会社 代表
依田尚人は YDAIコンサルティング株式会社 代表。セキュリティ診断の調達実務と IPA 適合サービスリスト・SCS評価制度について、IPA・JASA・経済産業省等の公開情報を一次ソースまで確認する工程を標準として、本サイトの記事を設計・監修しています。
security-shindan-hikaku.comは、YDAIコンサルティング株式会社が運営する情報メディアです。掲載情報の収録基準・出典の考え方は情報の収録基準と運営方針をご覧ください。
掲載内容に誤りや古い情報を見つけられた場合は、お問い合わせフォームよりご連絡ください。内容を確認のうえ対応します。