Webアプリ診断は「どこまで」見るのか|診断範囲の決まり方
著者・監修: 依田尚人(YDAIコンサルティング株式会社 代表)
Webアプリ診断は「どこまで」見るのか|診断範囲の決まり方
Webアプリ診断の範囲は、公開画面だけでなく認証後画面や連携の境界を含め、管理下と承諾範囲を基準に決めます。URLや画面の数を先に固定するのではなく、どの機能が誰の管理下にあり、どこまでを依頼できるかを整理してから見積条件へ写します。
範囲の整理は、診断を法律上の一律の義務として扱うためのものではありません。発注者が対象資産と実施の制約を明確にし、依頼先と同じ前提で見積や成果物を確認するための準備です。
Webアプリ診断の対象範囲とは
Webアプリ診断の対象範囲とは、画面、機能、認証後の領域、連携する境界を組み合わせて定めるものです。同じURL配下にあっても、利用者、管理者、扱う情報、管理する組織が異なれば、発注時に確認する範囲も同じにはなりません。
| 対象として整理する領域 | 確認すること | 見積条件に残す内容 |
|---|---|---|
| 公開画面 | 誰でも利用できる画面と機能 | 対象に含める画面と除外理由 |
| 認証後画面 | 利用者区分と利用できる機能 | 対象化の有無と前提 |
| 管理画面 | 管理者が使う機能と権限の区分 | 管理下か、実施条件は何か |
| 連携 | 外部サービスとの入口と接続先 | 自社管理か、第三者管理か |

公開画面と認証後画面を分ける
公開画面は外部から利用できる機能、認証後画面は利用者がログインして使う機能として、対象一覧では別の欄に記録します。画面の見た目が似ていても、入力する情報、実行できる操作、利用者の権限が異なる場合があります。公開画面だけを対象とするのか、認証後の領域まで含めるのかを、対象名と機能の両方で確認します。
認証後画面を含めるときは、利用者区分、必要な事前準備、実施できる時間帯を関係者と整理します。単にログインが必要という理由で対象外にせず、業務上の重要度と管理上の条件を確認します。対象に含めない場合も、理由と将来見直す条件を残すことで、サービス変更時に範囲を再確認できます。
認証後の領域は、利用者全員が使う機能と、限られた担当だけが使う機能を分けて整理します。画面名だけでは役割が分からない場合は、業務上の用途を短く併記します。これにより、対象を確認する担当と、実施条件を判断する担当が同じ範囲を見やすくなります。
連携先と第三者管理領域を区別する
Webアプリには、決済、認証、通知、データ連携などで外部サービスとつながる機能があります。連携がある事実は対象台帳に記録しますが、連携先を直ちに診断対象へ含めるわけではありません。自社が管理する入口と、連携先の事業者が管理する領域を分け、どの境界までを対象として説明するかを決めます。
第三者管理の領域を含める可能性がある場合は、管理者、承諾の有無、対象外にする部分を先に確認します。発注者が利用者であっても、管理者と同じ権限で対象を決められるとは限りません。連携の構成が変わると対象範囲も変わるため、見積時の資料だけでなく、実施前に最新の状態を確認します。
連携先の情報を対象一覧に書くときは、サービス名だけでなく、自社の画面や機能との関係を残します。接続先の内側までを対象と誤解させないよう、発注者が管理する入口と、第三者が管理する先を区別します。承諾の確認先が未確定なら、対象候補として記録して実施範囲には入れません。
範囲を決める条件を整理する
範囲を決める条件とは、事業上の重要度、扱う情報、資産の管理者、承諾の境界、実施上の制約を確認することです。重要な機能を優先する場合も、対象を広げる前に、どの資料で範囲を説明できるかを確かめます。
| 条件 | 確認する資料 | 発注時の整理方法 |
|---|---|---|
| 業務上の重要度 | 機能一覧、業務フロー | 優先する機能と理由を記録する |
| 扱う情報 | 画面の役割、データの流れ | 画面と連携の関係を整理する |
| 管理範囲 | 資産管理台帳、運用分担 | 管理者と対象可否を確認する |
| 実施条件 | 変更予定、利用時間、連絡体制 | 避ける時間帯と判断先を明記する |

重要な機能とデータの流れを確認する
重要な機能を確認する際は、業務への影響が大きい画面や、情報を受け渡す機能を対象候補として整理します。たとえば、申込み、登録、管理、外部連携といった役割を画面や機能と対応付けると、事業部門と技術担当が同じ対象を確認しやすくなります。対象を決める理由が分かれば、優先順位も共有できます。
データの流れを確認するときは、詳細な技術的な操作を記載する必要はありません。どの機能からどの管理領域へ情報が渡るか、外部の管理領域があるかを整理します。範囲を広げる判断は、扱う情報の重要度だけでなく、管理者の確認と承諾の条件を合わせて行います。
対象の優先順位は、全ての機能を同じ順番で確認するための順位ではありません。サービス運用に影響する機能、利用者への説明が必要な機能、変更が予定されている機能を区別し、今回の発注で確認する範囲を定めます。判断の根拠を残せば、次回の範囲見直しにも使えます。
診断深度と実施時間の前提を確認する
診断深度は、対象の数だけでは表せない確認条件です。同じ画面数でも、どの機能を対象にするか、認証後画面を含めるか、手動で確認する範囲をどう扱うかによって、見積の前提は変わります。対象一覧には、画面や機能の名称に加えて、確認したい範囲と除外する条件を記載します。
実施時間については、通常利用への影響を避けるために、利用が集中する時間帯、変更予定、連絡可能な担当を確認します。深度と実施時間は、依頼先だけで決める事項ではありません。発注者がサービスの運用条件を共有し、範囲変更が生じた場合の判断先を決めることで、実施前の認識差を小さくできます。
見積を比較する場合は、実施時間に関する制約も同じ欄で確認します。ある見積だけが特定の時間帯を前提としていると、対象の数が同じでも条件は一致しません。対象、深度、実施時間、連絡体制の関係を残しておくと、総額だけでは見えない差分を確認できます。
見積条件へ範囲を写す
見積条件へ範囲を写すことは、対象一覧で確認した内容を、依頼先が同じ条件で読める形にすることです。対象名だけでなく、含める範囲、対象外、前提資料、変更時の扱いを記載すると、見積ごとの条件差を確認しやすくなります。
| 見積書に残す欄 | 記載する内容 | 確認する理由 |
|---|---|---|
| 対象 | 画面、機能、認証後の領域 | 何を確認する見積かを示す |
| 対象外 | 連携先、管理外の領域、除外理由 | 範囲の境界を共有する |
| 前提資料 | 対象一覧、利用者区分、変更予定 | 見積の基礎をそろえる |
| 変更時の扱い | 追加対象の確認先と手順 | 当初条件との差分を残す |

除外範囲と前提条件を明記する
除外範囲は、確認しないことを隠すためではなく、見積と成果物の境界を明らかにするために記載します。第三者が管理する連携先、実施できない時間帯、一時的に停止できない機能などは、対象外とした理由を添えます。対象外の説明がなければ、見積の総額だけを見ても、何が含まれていないかを判断できません。
前提条件には、対象一覧を作成した時点、認証後画面を含める場合の準備、連絡先、変更予定を記載します。依頼先から追加の質問があった場合は、条件を口頭だけで更新せず、見積比較に使う資料にも反映します。これにより、依頼先ごとの説明の違いではなく、仕様の違いとして確認できます。
複数の見積を受け取るときは、同じ対象一覧を渡したかも確認します。依頼先ごとに資料の版や対象説明が違うと、後で同じ条件を比べられません。変更があれば全ての依頼先へ同じ内容を伝え、回答に反映されたかを比較表で確認します。
承諾範囲を事前に確定する
承諾範囲を事前に確定することは、管理下にある資産と第三者が管理する資産を分け、診断対象を適切に定めることです。本記事で用いる「〔2026年9月時点〕」は、その条番号が有効な時点を表し、確認日を表すものではありません。不正アクセス行為の禁止等に関する法律第8条〔2026年9月時点〕は、アクセス管理者に識別符号等の適正な管理とアクセス制御機能の有効性の検証などへの努力を求めていますが、脆弱性診断の実施を直接義務づける規定ではありません。
不正アクセス行為の禁止等に関する法律(平成11年法律第128号。現行版は令和4年法律第68号による改正の2025-06-01施行版)第2条第4項〔2026年9月時点〕と第8条〔2026年9月時点〕を、範囲を確認する際の根拠として参照します。2026-09-08確認。
| 承諾の確認順 | 確認すること | 残す内容 |
|---|---|---|
| 対象を分ける | 自社管理か、第三者管理か | 対象候補と管理者 |
| 管理者を確認する | アクセス管理者は誰か | 確認先と連絡方法 |
| 範囲を定める | 対象、対象外、実施条件 | 承諾の範囲を記した文書 |
| 変更を確認する | 連携や資産に変更がないか | 最新状態の確認記録 |

依頼先と連携先の承諾を混同しない
依頼先との契約や連絡だけで、すべての対象について承諾が確認できるわけではありません。不正アクセス行為の禁止等に関する法律第2条第4項〔2026年9月時点〕では、アクセス管理者の承諾を得て行う診断は三つの類型すべてで不正アクセス行為に当たりません。したがって、診断の承諾はアクセス管理者から得ることを標準にします(出典: e-Gov 法令検索「不正アクセス行為の禁止等に関する法律」、2026-09-08確認)。
他人の識別符号を入力する第一の類型では、アクセス管理者またはその識別符号に係る利用権者の承諾で除外されます。一方で、制限を免れる情報または指令を入力する第二、第三の類型では、利用権者の承諾だけでは除外されず、アクセス管理者の承諾が必要です。連携先の管理領域を対象に含める前に、誰の承諾が必要かを一般化せず、管理者と範囲を文書で確認します。
承諾の文書では、管理者の名称、対象となる資産、実施できる範囲、対象外、連絡方法を対応付けます。こうした確認は、発注者が第三者の資産を判断するためのものではなく、診断対象を適切に限定するための準備です。対象や連携の状態が変わった場合は、以前の承諾をそのまま広げずに確認します。

よくある質問
認証後画面も対象に入れるべきか
認証後画面に含まれる機能や扱う情報を確認し、対象に含めるかを見積条件に明記します。公開画面だけで一律に決めるものではありません。利用者区分、業務上の重要度、実施条件を整理し、対象外にする場合は理由も残します。
外部サービスとの連携先は対象にできるか
連携がある事実は対象一覧に記録し、自社が管理する範囲と連携先を管理する事業者の範囲を分けて確認します。対象を広げる前に、アクセス管理者との承諾範囲を確認します。利用しているだけのサービスを、自社の判断だけで実施対象にしないことが大切です。
診断は法律で必ず必要か
不正アクセス行為の禁止等に関する法律第8条〔2026年9月時点〕は、アクセス管理者に防御措置への努力を求める規定であり、脆弱性診断の実施を直接義務づけるものではありません。発注の背景は、取引先からの要請や管理上の判断と分けて考えます(出典: e-Gov 法令検索「不正アクセス行為の禁止等に関する法律」、2026-09-08確認)。
まとめ
Webアプリ診断の範囲は、公開画面、認証後画面、連携先を分け、業務上の重要度と管理・承諾の境界を確認して決めます。対象と対象外、前提資料、変更時の扱いを見積条件に残すと、比較する見積の差分を読み取りやすくなります。発注全体の流れはセキュリティ診断の発注ガイド、種類の違いは脆弱性診断とペネトレーションテストの違いで整理できます。
法令・制度に関する記事は法令・制度の記事一覧で確認できます。ほかのテーマを含めて読む場合はブログ一覧をご覧ください。
出典
本記事の出典は に内容を確認しています。
- e-Gov 法令検索「不正アクセス行為の禁止等に関する法律」(laws.e-gov.go.jp)
著者・監修
依田尚人YDAIコンサルティング株式会社 代表
依田尚人は YDAIコンサルティング株式会社 代表。セキュリティ診断の調達実務と IPA 適合サービスリスト・SCS評価制度について、IPA・JASA・経済産業省等の公開情報を一次ソースまで確認する工程を標準として、本サイトの記事を設計・監修しています。
security-shindan-hikaku.comは、YDAIコンサルティング株式会社が運営する情報メディアです。掲載情報の収録基準・出典の考え方は情報の収録基準と運営方針をご覧ください。
掲載内容に誤りや古い情報を見つけられた場合は、お問い合わせフォームよりご連絡ください。内容を確認のうえ対応します。
