Webアプリケーション診断の費用構造｜画面数×深度×手動比率

Webアプリケーション診断の費用は、対象画面の定義と診断深度、手動で確認する範囲を揃えて初めて比べられます。画面数だけを見ても、認証後の機能を含めるか、どの業務機能を一つの対象として扱うかが違えば、見積の前提は一致しません。

この記事では、Webアプリケーションに絞って対象条件を整理します。プラットフォームのIP数やホスト数、再診断の詳細な条件を一つの費用比較に混ぜず、画面、機能、診断深度、手動での確認の関係を発注者の視点で確認します。

Webアプリケーション診断の費用条件とは

Webアプリケーション診断の費用条件とは、画面、機能、認証後画面、診断深度をどのように定義するかという発注仕様です。同じ「Webアプリケーション診断」という名称でも、対象の数え方と確認資料が異なれば、見積書の総額だけを同じ条件として扱えません。

画面と機能を対象条件として定義する

画面と機能を対象条件として定義する際は、画面名だけを並べるのではなく、その画面がどの業務で使われるかを対応付けます。申込み、登録、管理、外部連携など、役割が分かる表現を添えると、技術担当と事業部門が同じ対象を確認しやすくなります。URLが異なっていても同じ機能の画面がある場合や、一つの画面に複数の操作がある場合は、数え方を事前に確認します。

対象条件には、対象外とする画面や機能も記載します。対象外の理由を残さないと、ある見積に含まれていない画面が、別の見積では含まれていることに気付きにくくなります。対象一覧と見積書の表現が対応しているかを確認し、追加や除外があれば同じ資料に反映します。

画面一覧を作る担当と、見積を確認する担当が異なる場合は、一覧の作成者だけが分かる略称を避けます。画面名、機能、利用者区分、対象化の有無を並べれば、依頼先から確認があったときに社内でも照合できます。対象数を確定する前に、重複している画面や同じ機能の別表示がないかも確認します。

認証後画面を別条件として記録する

認証後画面は、公開画面と別の条件として記録します。利用者がログインした後に使う画面には、利用者区分、扱う情報、実行できる操作が異なるものがあります。認証後に利用する機能を対象へ含めるかどうかを、単にログインの有無で決めず、業務上の役割と管理上の条件を確認します。

見積書では、認証後画面の対象化の有無、必要な準備、対象外にする範囲を確認します。権限が複数ある場合は、同じ画面でも利用者区分によって確認条件が異なることがあります。発注者は、誰が利用する画面か、どの機能を含めるかを整理し、依頼先ごとに同じ前提で見積が作られているかを比較します。

認証後の領域について、準備が必要な場合は、その準備を誰が行うか、対象の確認に必要な条件をどう伝えるかを社内で決めます。実施できる時間帯やサービス変更の予定も、対象の説明と一緒に記録します。こうした前提が違えば、同じ画面数でも同じ発注条件ではなくなります。

画面数と診断深度を揃える

画面数と診断深度を揃えることは、同じ数の画面でも確認内容が異なれば比較できないことを前提にする作業です。画面の数は対象を整理する入口であり、診断の範囲、認証後画面、手動で確認する内容を含めて初めて見積条件になります。

動的な画面を数える前提を確認する

動的に内容が変わる画面を数えるときは、画面の見た目だけで一律に数えるのではなく、機能、入力内容、利用者区分の違いを確認します。同じ画面構成でも、利用者によって利用できる機能が異なる場合があります。また、外部連携によって表示内容が変わる場合は、自社が管理する部分と連携先の部分を分けて整理します。

数え方に迷う対象は、見積依頼前に質問事項として残します。発注者側で仮の数を決めてしまうと、依頼先ごとに異なる解釈で条件が作られるおそれがあります。対象一覧には、画面や機能の名称、役割、対象に含めるか、確認が必要な点を記載し、依頼先からの回答と対応付けます。

動的な画面に関する説明は、技術的な手順を細かく記すためではなく、対象を誤解なく伝えるために使います。画面の役割、利用者区分、表示や入力の条件を発注者側で整理し、依頼先が対象の定義を確認できるようにします。未確認の点は空欄を埋めず、質問として比較表に残します。

手動で確認する範囲を明記する

手動で確認する範囲は、画面数とは別に明記します。手動という言葉だけでは、どの画面、機能、認証後の領域をどの程度確認するのかが分かりません。対象と確認方法の対応を見積条件に残し、自動的な確認との分担を質問します。依頼先ごとに表現が異なる場合も、発注者側の比較表では同じ欄に書き換えて確認します。

手動での確認を含める理由は、価格の高低を示すためではなく、必要な確認を対象と結び付けるためです。取引先への説明や社内の対応検討に必要な成果物がある場合は、その目的と対象範囲を共有します。確認方法が違う見積を比較するときは、総額の差ではなく、対象と成果物の差として記録します。

手動で確認する範囲を確認するときは、成果物に何が記されるかも合わせて見ます。対象の一部だけを確認する条件であれば、その対象が画面一覧のどこに対応するかを追えるようにします。依頼先ごとの用語が異なるときは、発注者側の比較表で対象、方法、成果物の三つに整理し直します。

見積書に対象を写す

見積書に対象を写すことは、画面や機能の一覧で整理した条件を、依頼先が同じ意味で読めるようにすることです。対象、対象外、前提資料、変更時の扱いを分けて記載すれば、受け取った見積書の条件差を確認しやすくなります。

除外条件と前提資料を確認する

除外条件には、第三者が管理する連携先、実施できない時間帯、一時的に停止できない機能などを記載します。対象外にすること自体が問題なのではなく、何が対象外なのかを発注者と依頼先で同じように理解することが重要です。理由を残しておけば、総額の差が対象範囲の差によるものかを確認できます。

前提資料には、対象一覧を作成した時点、サービス変更の予定、認証後画面の利用条件、連絡先を含めます。見積依頼後に対象が変わったときは、口頭のやり取りだけで終えず、比較に使う資料も更新します。同じ更新内容を全ての依頼先へ共有すると、比較する見積の前提を揃えやすくなります。

対象外にする理由には、管理下にないこと、今回の確認範囲に含めないこと、実施条件が未確定であることなどを区別して残します。理由が異なれば、後で範囲を見直す際に必要な確認先も変わります。対象外の項目を比較表から消さずに残すことで、見積書に含まれる条件との違いを確認できます。

比較表を作る前に確認する

比較表を作る前に確認することは、料金表のような見せ方より先に、同じ課金単位と対象条件で比べられるかを確かめることです。Webアプリケーション診断では、画面、機能、認証後画面、手動での確認が別々の条件になるため、どれか一つだけを比較の基準にしません。

同じ課金単位で比べられるかを確認する

同じ課金単位で比べられるかを確認するには、画面単位の見積と、機能や別の対象単位を基準にした見積を、同じ条件のように扱わないことが必要です。対象の定義が異なる場合は、数を無理に合わせず、どの機能や画面を含むかを確認します。比較表では、同じ単位で確認できる項目と、別途確認が必要な項目を分けます。

IPAが公表する情報セキュリティサービス基準適合サービスリストでは、脆弱性診断サービスという区分を確認できます。リストはサービス区分を確認する入口であり、掲載だけで個別の見積条件や発注の結論を示すものではありません。発注者は、区分の確認と、対象画面・診断深度・成果物の比較を別の作業として進めます。2026-09-11確認。

比較表の各欄に同じ単位が書けない場合は、無理に一つの数字へ換算しません。画面数、機能数、認証後の領域、手動で確認する範囲を別々に記録し、総額との関係を確認します。条件をそろえられない見積は、どの項目が異なるのかを質問し、回答を得てから比較対象として扱います。

よくある質問

画面数だけで費用を比べられるか

画面数に加え、診断深度、認証後画面、手動で確認する範囲が同じかを確認します。画面数だけでは、対象外の範囲や確認方法の違いを見落とします。画面と機能の対応、利用者区分、成果物の条件を比較表に記録してから総額を確認します。

認証後画面は別に確認するか

認証後画面を対象に含めるかは、機能や扱う情報を確認したうえで見積条件に記載します。ログインが必要な画面を一律に対象外または対象内とせず、利用者区分、業務上の役割、実施条件を分けて確認します。対象外にする場合は、理由も見積条件に残します。

手動診断の範囲はどう確認するか

自動的な確認と手動での確認の分担、対象画面、成果物を見積書で確認します。手動という言葉だけで条件を比較せず、どの画面や機能を対象にするか、認証後の領域を含めるか、必要な説明が何かを同じ欄に記録します。

まとめ

Webアプリケーション診断の費用条件は、画面数だけでなく、機能、認証後画面、診断深度、手動での確認範囲で決まります。対象一覧と見積書の表現を対応させ、対象外と前提資料も記録すると、同じ条件で比較できるかを確認しやすくなります。費用全体の考え方は脆弱性診断の費用構造、対象範囲の整理はWebアプリ診断の対象範囲、発注準備はセキュリティ診断の発注ガイドで確認できます。

費用に関する記事は費用の記事一覧へ進めます。