---
title: "診断の対象と範囲の決め方"
description: "脆弱性診断を依頼する前に、対象の一覧（URL、ホスト、API、アカウント種別）、範囲外の明示、本番か検証環境かの判断を決める手順と、範囲が決まった後に決める方式・基準・報告書・直す順番を整理します。"
canonical: https://uniquex-knowledge-center.pages.dev/security/ordering-a-vulnerability-assessment
type: "手順"
domain: "security"
chapter: 3
section: "3.2"
keywords: ["診断の対象と範囲の決め方"]
aliases: ["CVSS"]
entities: []
sources: [{"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 日 掲載分","url":"https://www.ipa.go.jp/security/it-service/service_list.html","accessed":"2026-10-08"},{"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"}]
author: "UNIQUEX 編集部"
reviewer: ""
published: 2026-10-08
updated: 2026-10-09
verified: 2026-10-08
---

# 診断の対象と範囲の決め方

> 脆弱性診断を依頼する前に、まず対象の一覧と範囲外、そして本番か検証環境かを決めます。対象は URL、ホスト、API、アカウント種別（未ログイン、一般利用者、管理者）を一覧にし、第三者のサービスや共有基盤など範囲外の対象も書きます。検証環境で行うなら本番との差分を書き添え、本番で行うなら外部連携が検査中に実際に動かないよう止めるか試験用に切り替えます。範囲が決まった後に、許可と連絡体制の文書、方式と基準、報告書の形式と再診断の条件、受け取った後の直す順番を、この順に決めます。後の項目ほど前の答えに依存するので、順番を変えません。



脆弱性診断を依頼する前に決めることは、対象の範囲と環境、許可と連絡体制、方式と基準、報告書の形式と再診断の条件、受け取った後の直す順番の五つです。後の項目ほど前の答えに依存するので、この順番で決めます。この節は最初の「対象の範囲と環境」を扱い、許可と連絡体制は次の節 [3.3](/security/assessment-authorization-and-contacts) で扱います。診断は所有者または管理者の許可を得た対象にだけ行います。

## 対象の一覧に書くこと [#対象の一覧に書くこと]

診断する対象を一覧にします。一覧が見積もりの前提になり、報告書を本番に当てはめられるかを決めます。

1. **URL、ホスト、API。** 画面の URL だけでなく、画面から呼ばれる API、管理画面、バッチや外部連携の入口も書きます。書いていないものは検査されません。
2. **アカウントの種別。** 未ログイン、一般利用者、管理者など、検査に使う権限の種別ごとに試験用のアカウントを用意します。認可の不備は、権限の違うアカウントを比べないと見つかりません。
3. **扱うデータ。** 個人情報や決済に触れる機能に印を付けます。範囲を絞るときの優先順位と、直す順番の判断に使います。
4. **範囲外の対象。** 第三者のサービス、共有基盤、検査しない機能を明示します。クラウドや外部サービスを含む場合は、その事業者が定める事前申請の要否を確かめます。

## 本番か検証環境かの判断 [#本番か検証環境かの判断]

環境は次の分岐で決めます。

| 環境   | 書き添えること                                                                         | 止めるか切り替えること                                    |
| ---- | ------------------------------------------------------------------------------- | ---------------------------------------------- |
| 検証環境 | 本番との差分（データ量、WAF の有無、外部連携の停止）。差分を書かずに始めると、本番にだけある WAF や設定で結果が変わり、報告書を本番に当てはめられない | 本番と同じ版と設定になっているかの確認                            |
| 本番   | 検査の時間帯と、対象が止まった場合の復旧の手順                                                         | メール送信や決済などの外部連携が検査中に実際に動かないよう、止めるか試験用の宛先に切り替える |

範囲を絞るときは、外部に公開しているもの、個人情報や決済を扱うもの、大きく変更したものの順に残します。実施条件を計画で固めてから検査に進む流れは NIST SP 800-115 と同じです。

## 範囲が決まった後に決めること [#範囲が決まった後に決めること]

範囲と環境が決まった後、次の順に決めます。

1. **許可と連絡体制を文書にする。** 所有者の承認、実施期間、実施元 IP アドレス、停止手順、連絡先を 1 枚の文書にまとめます（[3.3](/security/assessment-authorization-and-contacts)）。
2. **方式と基準を決める。** 方式は、ツールによる自動検査、人手による手動検査、その組み合わせのいずれかです。

   | 方式      | 向く対象              | 留意点                   |
   | ------- | ----------------- | --------------------- |
   | ツール（自動） | 画面数が多い、定期的に繰り返す   | 認可やビジネスロジックの不備は見つけにくい |
   | 手動      | 認証・認可・決済など業務固有の処理 | 範囲を絞らないと期間と費用が伸びる     |
   | 組み合わせ   | 初回の診断、リリース前       | 両者の分担を書面で分ける          |

   初回は組み合わせ、2 回目以降は自動検査に変更箇所の手動検査を足す形が、費用と見落としの釣り合いを取りやすい選び方です。検査項目は IPA「安全なウェブサイトの作り方」（改訂第 7 版）第 1 章の 11 種類の脆弱性を土台にし、業務固有の処理を足します。深刻度は CVSS か依頼側の基準かを先に決めます。依頼先は、IPA の「情報セキュリティサービス基準適合サービスリスト」に脆弱性診断サービスとして載っているかを 1 つの目安にできます（掲載は品質の保証ではありません）。
3. **報告書の形式と再診断の条件を決める。** 報告書に含める項目（検出箇所、再現条件、深刻度、根拠、対策の方向）、納品形式、報告会の有無を決めます。再現条件がない報告書では、修正担当が直せたかどうかを確かめられません。修正後の再診断は、回数、期限、対象（検出箇所のみか全体か）を契約前に合意します。決めずに始めると、再診断が追加費用になるか、修正の確認が取れないまま終わります。
4. **受け取った後の直す順番を決める。** 順番は、深刻度、攻撃の成立しやすさ（認証なしで届くか）、影響範囲（個人情報や決済に触れるか）の三つで決めます（[2.3](/security/cvss-epss-kev)）。項番は優先順位ではないので、報告書の並び順のまま直しません。直し方は原因そのものをなくす根本的な解決を基本にし、すぐに直せない項目は WAF や設定変更で影響を抑えたうえで修正予定日を記録します（IPA「安全なウェブサイトの作り方」と同じ考え方です）。低い項目も放置すると次回の診断に同じ項目が並ぶので、項目ごとに担当者と期限を決めます。

## 依頼前の確認の一覧 [#依頼前の確認の一覧]

* 対象の一覧（URL、ホスト、API、アカウント種別）と範囲外の対象が書かれている
* 本番か検証環境かが決まり、検証環境なら本番との差分、本番なら外部連携の扱いが書かれている
* 所有者の承認と連絡先、停止手順、遮断の例外設定が 1 枚の文書にある
* 方式、基準、深刻度の付け方が決まっている
* 報告書の項目と再診断の条件が契約に含まれている
* 受け取った後に判断する人と、直す順番の基準が決まっている


## 参考文献

- 独立行政法人 情報処理推進機構（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 日 掲載分. https://www.ipa.go.jp/security/it-service/service_list.html（参照日 2026-10-08）
- 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）

## 更新履歴

- 2026-10-08: 初版（題「脆弱性診断を依頼する前に決めること」）
- 2026-10-08: 書籍型の目次に合わせて改題・再構成（許可と連絡体制の部分を節 3.3 に分割）
- 2026-10-09: 監修実施の記録がないため監修者表示を未実施へ訂正。本文の全主張を再確認した日ではない
