脆弱性診断の費用相場を把握する方法

脆弱性診断の費用が「わかりにくい」理由と、相場を知る前に押さえる前提

脆弱性診断の見積もりを取ってみると、同じ「診断」という言葉でも金額が数十万円〜数百万円、時にはそれ以上まで幅が出ます。これは、脆弱性診断が“商品棚に並ぶ定価品”ではなく、対象システムのリスクと作業量に合わせて設計されるサービスだからです。まずは費用がぶれやすい理由を理解すると、相場の把握が一気に楽になります。

費用差が出る主因は大きく4つあります。1つ目は「対象範囲」です。Webサイト1つでも、ログイン前の画面だけなのか、会員ページや管理画面まで含むのか、APIやスマホアプリも含むのかで工数が変わります。2つ目は「診断方法」。ツールで自動チェックするだけなのか、専門家が手作業で“攻撃者の視点”から検証するのかで深さが変わります。3つ目は「品質と成果物」。結果レポートが“脆弱性一覧”で終わるのか、再現手順、影響範囲、優先度、改修の助言、再診断まで含むのかで価値が変わります。4つ目は「前提条件の整備」。テスト環境・認証情報・IP制限解除・ログ取得など、診断の受け入れ体制によっても工数が増減します。

相場を知りたい読者の多くは「適正価格かどうか」「何にお金を払っているのか」を明確にしたいはずです。そこで本記事では、脆弱性診断の費用相場を“金額の一覧”としてだけでなく、見積もりの分解方法と比較の軸として整理します。開発の専門知識がなくても、情シスや管理部門が社内説明・稟議に使える形を目指します。

費用相場を左右する「診断の種類」：まずは区分を揃える

脆弱性診断の相場を把握する最短ルートは、各社の提案を同じ土俵に並べることです。そのために最初に揃えるべきなのが「何の診断か」という区分です。代表的には、Webアプリケーション診断、プラットフォーム診断（ネットワーク/サーバ）、クラウド設定診断、スマホアプリ診断、API診断、そしてペネトレーションテスト（侵入テスト）があります。名称が似ていても、狙いも作業も別物です。

Webアプリケーション診断は、入力フォームやログイン、権限、セッションなど“アプリの動き”に潜む脆弱性を見ます。プラットフォーム診断は、OS・ミドルウェア・ネットワーク機器の設定やパッチ状況など“土台”を見ます。クラウド設定診断は、IAM権限、ストレージ公開設定、ネットワーク境界、ログ設定など、AWS/Azure/GCPの運用設定の穴を確認します。スマホアプリ診断は、端末内データの保護、API連携、証明書ピンニング、難読化など、アプリ特有のリスクを扱います。

さらに混同されやすいのが、脆弱性診断とペネトレーションテストの違いです。脆弱性診断は“弱点の洗い出し”が主で、網羅性を重視します。一方、侵入テストは“実際に侵入できるか、どこまで到達できるか”を検証し、シナリオに沿って深掘りすることが多いです。一般に侵入テストの方が高額になりやすい一方、目的が合えば投資対効果が高いこともあります。見積もり比較の前に、診断の種類を一致させることが、相場把握の第一歩です。

社内向けには、「今回はWebアプリの脆弱性診断（会員・管理画面を含む）で、侵入テストは別途」といった形で、目的と範囲を言語化すると誤解が減ります。ベンダー比較も“同じ診断種別”に揃えるだけで、金額の差が妥当かどうかを説明しやすくなります。

相場観の作り方：見積もりを「対象範囲×深さ×成果物」に分解する

脆弱性診断の費用相場は、単価表を眺めるより、見積もりを分解して自社の条件に当てはめる方が正確です。分解の軸はシンプルに「対象範囲」「深さ（手動/自動、工数）」「成果物（レポートと支援範囲）」の3つです。この3軸を揃えると、価格差の理由が説明可能になります。

まず対象範囲。Webなら「URL数」ではなく、機能の数（ログイン、検索、決済、ファイルアップロード、管理機能など）と、権限ロール（一般/管理者/代理店など）で工数が決まります。APIならエンドポイント数と認証方式、データ更新系の有無が効きます。ネットワークならIP数や機器の種類、外部公開範囲で変わります。ここが曖昧だと、同じ「Web診断」でも、実態は2倍以上の差が出ます。

次に深さ。自動スキャン中心は安く見えますが、誤検知・見落としの扱い、認証後の動的な検証、業務フローを悪用した不正操作などは手動比率が上がります。逆に、公開ページだけを広く浅く見るなら自動比率を高める設計も可能です。重要なのは、ベンダーの説明が「どこからどこまで手で確認するのか」「検証の再現性はあるのか」を語れているかです。

最後に成果物。レポートが“脆弱性の指摘”で終わるか、“直し方まで支援”するかで価値が変わります。たとえば、再現手順（HTTPリクエスト例）、影響（情報漏えいの可能性、権限昇格の可能性）、優先度（今すぐ/計画的）、改修案（設定変更・実装方針）、そして再診断（改修確認）が含まれると、情シスが開発会社やSIerへ依頼しやすくなります。社内外の改修を動かすための資料として使えるかがポイントです。

この3軸で自社の診断を定義し、各社の見積もりに同じ項目で回答してもらうと、相場のブレが減ります。価格だけでなく、「なぜその金額なのか」が理解できるため、稟議でも“安いから”ではなく“必要な内容だから”で通しやすくなります。

金額レンジの目安：よくあるケース別に相場を掴む

ここでは、実務で頻出するケースの“相場観”を掴むための目安を示します。なお、対象の複雑さ、環境数（本番/ステージング）、認証の段数（SAML/多要素認証）、権限ロールの多さ、夜間対応の有無などで変動します。「何を含むか」を揃えた上で、レンジとして捉えるのがコツです。

「思ったより高い」と感じる場合は、診断の深さと成果物が手厚い可能性があります。逆に「安すぎる」場合は、対象範囲が狭い、手動検証が少ない、報告が簡易、再診断が別料金、といった条件が隠れていることがあります。特に脆弱性は、見つけるだけでなく“直して再発を防ぐ”ところまでがコストの本体です。安価な診断で指摘が大量に出て、社内が動けず放置されると、結果的にリスクも費用も増えます。

相場を掴むもう一つの方法は、「年1回の定期診断」か「リリース前のスポット診断」かを明確にすることです。定期なら範囲と手順が標準化され、工数が読みやすい一方、スポットは短納期や仕様変更が絡み、割高になりがちです。自社の事情（監査対応、取引先要件、ISMS、個人情報保護など）に合わせて、必要十分なレンジを選びましょう。

見積もり比較で失敗しないチェックリスト：価格差の正体を見抜く

相場を調べて2〜3社から見積もりを取っても、「結局どれが良いかわからない」となりがちです。そこで、脆弱性診断の見積もりを比較する際に、非エンジニアでも判断できるチェックポイントを整理します。価格そのものより、“条件の違い”を言語化できるかが重要です。

• スコープの明確さ：対象URL/機能/ロール/アプリ版数/クラウドアカウント範囲が具体的に書かれているか
• 診断手法の内訳：自動スキャンと手動検証の比率、認証後の検証有無、ロジック不正（業務フロー悪用）まで見るか
• 前提条件と依頼事項：テスト環境、認証情報、アクセス制限、テストデータ、通信ログ取得などが整理されているか
• 検証の安全設計：負荷試験の有無、攻撃的テストの制御、業務時間帯への配慮、データ破壊を避ける取り決めがあるか
• レポートの粒度：再現手順、影響、優先度、改修案、参考設定、スクリーンショットやリクエスト例があるか
• コミュニケーション：キックオフ、途中報告、速報（クリティカル時の即連絡）、報告会が含まれるか
• 改修支援と再診断：質問対応の回数/期間、再診断が含まれるか、どこまでが追加費用か
• 体制と実績：担当者の経験、診断者の固定、過去の類似業界・類似規模の実績が説明できるか

特に注意したいのは「診断対象の増減」に関する取り決めです。診断を進めると、隠れた管理画面や追加機能が見つかることがあります。ここを“追加料金で都度対応”にするのか、“一定範囲は吸収”するのかで、最終額の納得感が変わります。契約前に、スコープ変更時のルールを確認しておくと安心です。

また、情シスが少人数の場合は、運用負荷も見積もりに入れる発想が有効です。たとえば「指摘の意味がわからず開発に伝えられない」「再現ができない」といった事態は、社内工数を膨らませます。報告会での質疑や、改修優先度の助言が含まれる診断は、結果として総コストを下げることがあります。

社内で相場を説明できる「費用の出し方」：RFPテンプレ的な進め方

脆弱性診断の相場を把握する目的の多くは、最終的に社内稟議・上申で「なぜこの金額なのか」を説明することです。そこで、相場を“自分で作る”ための進め方を紹介します。ポイントは、見積もり依頼書（RFPの簡易版）で条件を揃え、比較可能な形で回答をもらうことです。相見積もりは、揃えた条件で初めて意味を持ちます。

まず、対象の棚卸しをします。Webなら「主要画面一覧（ログイン前/後）」「権限ロール」「外部連携（決済、ID連携、メール配信等）」「管理画面の有無」を箇条書きで十分です。ネットワークなら外部公開IPと機器種類、クラウドならアカウント数や主要サービス（S3、IAM、VPC等）を整理します。難しければ、システム構成図がなくても“利用しているサービス名”だけでも構いません。

次に、診断の目的を1行で定義します。例：「取引先要件により年1回のWebアプリ脆弱性診断が必要」「新規リリース前に認証後画面を中心に脆弱性診断を実施し、改修確認まで行いたい」などです。目的が曖昧だと、ベンダーは広めに見積もりを作りがちで、相場が読みづらくなります。

そして、見積もりで必ず回答してほしい項目を指定します。たとえば「作業内訳（準備/診断/報告）」「診断手法（自動/手動）」「報告会の有無」「再診断の条件」「納品物のサンプル（目次レベルで可）」などです。これだけで比較の軸が揃い、相場が見えます。最後に、スケジュール（いつまでに結果が必要か）と、受け入れ条件（テスト環境の有無、アカウント発行可否、VPN可否）を添えると現実的な提案が集まります。

相場の説明では、「レンジ」と「根拠」をセットにします。例として、「当社は会員制Webで管理画面もあるため、一般的なWeb診断の中でも認証後機能を含むレンジ（概ね80万〜250万円）が相場。今回は成果物に改修案と再診断を含めるため、中〜上位の価格帯が妥当」といった形です。金額の正当性が“機能と支援範囲”に結びつくと、非エンジニアの役員にも伝わります。

脆弱性診断を「やりっぱなし」にしない：費用対効果を上げる運用設計

脆弱性診断は、実施した瞬間よりも、その後の改修と再発防止で効果が決まります。費用相場だけを追うと、最安値の診断を選びたくなりますが、運用まで含めた総コストで見ると逆転することがあります。診断費用を“保険料”で終わらせず、改善投資にするための設計ポイントを押さえましょう。

まず、改修の責任分界を決めます。自社開発なのか、外注なのか、保守ベンダーがいるのかで、動かし方が変わります。診断会社が出す指摘を、誰がチケット化し、誰が優先度を決め、誰がリリース判断をするのかを決めておくと、診断結果が滞留しません。特に情シスが窓口の場合、報告会での質疑を通じて「開発に渡せる粒度」に落とし込むのが重要です。

次に、優先順位の付け方です。脆弱性には深刻度の高いもの（外部から不正ログイン、個人情報漏えいにつながる等）もあれば、条件が限定されるものもあります。診断レポートの優先度を鵜呑みにせず、「自社のデータの重要性」「公開範囲」「悪用のしやすさ」「検知のしやすさ」を加味して判断すると、限られた改修予算でも効果が最大化します。

さらに、再発防止の仕組み化が費用対効果を押し上げます。たとえば、開発のチェックリスト（入力値検証、権限チェック、ログ出力、秘密情報の扱い）を整備する、ライブラリの更新ルールを決める、CIで簡易スキャンを回す、リリース前に最低限のセキュリティ観点レビューを入れる、といった運用です。これにより、次回の脆弱性診断で致命的な指摘が減り、結果として診断費用や改修費用も安定します。

最後に、診断タイミングの最適化です。大きな改修の直後、機能追加の前、外部公開範囲が変わる前（新ドメイン、WAF変更、認証方式変更など）に実施すると、リスクを先回りできます。逆に、仕様が固まっていない段階や、改修の時間が取れない時期に診断を入れると、指摘が出ても直せず“相場以上に高い買い物”になりがちです。

まとめ

脆弱性診断の費用相場は、単純な価格表ではなく「診断の種類」「対象範囲」「深さ」「成果物」を揃えて初めて把握できます。相場のブレは、スコープの曖昧さや、手動検証・改修支援・再診断の有無といった条件差から生まれます。見積もりは3社程度でも、同じ条件で依頼し、内訳と前提を比較すれば“高い/安い”ではなく“適切かどうか”で判断できます。

また、脆弱性診断は実施して終わりではなく、改修・再発防止まで含めた運用設計で費用対効果が決まります。社内説明では、レンジと根拠（対象の特性、求める成果物、再診断の有無）をセットにすると稟議が通りやすくなります。自社のリスクと運用体制に合った診断を選び、脆弱性を“見つけて直し、再発を減らす”サイクルへつなげてください。