脆弱性診断は本当に必要？判断の目安と依頼先の選び方・費用が決まる仕組み

2026年9月18日2026年10月1日

開発会社や取引先から「公開前に脆弱性診断を受けたほうがいいですよ」と言われたものの、それが本当に必要なのか、どこに頼めばいいのか、いくらかかるのかが分からない。セキュリティの専門知識がない発注者にとって、脆弱性診断は判断材料の少ない買い物です。

「脆弱性診断を勧められたけど、本当に必要なのか判断できない。どこに頼めばいいのか、費用がいくらなのかも分からない…」

先に結論をお伝えします。脆弱性診断が必要かどうかは「インターネットに公開しているか」「個人情報や決済を扱うか」「大きく作り変えたか」の3点でおおむね判断できます。どれかに当てはまるなら、受ける価値は高いと考えてよいでしょう。依頼先は、経済産業省の基準に適合したサービスの公開リストが手がかりになります。費用は「何をどこまで診るか」で決まるため、先に診断の範囲を決めてから見積もりを取るのが近道です。

この記事では、脆弱性診断とは何か、必要性の判断の目安、依頼先の選び方、費用が決まる仕組み、報告書を受け取った後の動き方まで、発注者の目線で解説します。

脆弱性診断とは？システムの「弱点」を専門家が点検するサービス

脆弱性（ぜいじゃくせい）とは、システムのセキュリティ上の弱点のことです。脆弱性診断は、その弱点が残っていないかを、実際の攻撃に近い方法で点検するサービスです。建物でいえば、完成後に専門家が鍵や窓の状態を点検する「防犯診断」に近いイメージです。

デジタル庁が政府情報システム向けにまとめたガイドラインでは、広く使われている診断を次のように分けています。民間のシステムでも、この分け方で考えると整理しやすくなります。

📰 出典：デジタル庁「DS-221 政府情報システムにおける脆弱性診断導入ガイドライン」（2024年2月6日版）

診断の種類	何を診るか	見つかる問題の例
Webアプリケーション診断	自社用に作ったWebシステムの画面・API（＝システム同士がやり取りする窓口）	他人のデータが見えてしまう、ログインを回避できる、入力欄から不正な命令を送り込める
プラットフォーム診断	サーバー・ネットワーク機器・VPN機器など土台部分	不要な通信口が開いている、古いソフトが使われている、初期パスワードのまま
スマートフォンアプリ診断	iPhone・Androidアプリとその通信	通信が暗号化されていない、アプリ内に認証情報が埋め込まれている

ツール診断と手動診断の違い

同じガイドラインでは、Webアプリケーション診断の手法として「ツールによる自動診断」「専門家による手動診断」「両者の併用」の3種類があると説明しています。

ツール診断：診断ソフトが自動で大量のパターンを試します。効率が良く、よく知られた弱点を網羅的に確認するのに向いています
手動診断：専門家がシステムの仕組みを理解したうえで確認します。「他人の注文履歴が見えてしまう」といった、そのシステム固有の仕様に起因する問題はツールでは見つけにくく、人の目が必要です

ガイドラインは、ツールによる自動診断だけでは不十分で、専門家による手動診断との併用が不可欠だとしています。あくまで政府システム向けの基準ですが、民間でも「ツールだけで済ませてよいか」を考えるうえで参考になります。

なお、ガイドラインは、診断はすでに作り込まれた弱点を見つけるものであり、診断だけでセキュリティリスクを防ぐことはできないとも述べています。設計段階での対策（セキュリティ要件）と組み合わせてはじめて効果が出るものだと考えておきましょう。

脆弱性診断が必要かどうか判断できない3つの理由

判断できないのは、発注者の知識不足というより、脆弱性診断という商品の性質によるところが大きいです。

理由1：受けても「目に見える成果物」が増えない

診断をしても、画面が増えたり機能が便利になったりはしません。成果は「問題が見つかった／見つからなかった」という報告書だけなので、費用に見合うかどうかを実感しにくいのです。

理由2：勧める側の立場がさまざま

診断を勧めるのは開発会社・セキュリティ会社・取引先などさまざまで、理由も「品質確認」「取引条件」「念のため」と異なるため、必要度が見えにくくなります。

理由3：費用が「範囲次第」で比べにくい

脆弱性診断には定価がなく、何画面を診るか、手動でどこまで確認するかで見積もりが大きく変わります。

脆弱性診断が必要なケースの判断目安

次の表に当てはまる項目が多いほど、診断を受ける価値は高くなります。

判断の目安	当てはまる場合の考え方
インターネットに公開している	誰でもアクセスできるため、攻撃を受ける前提で考える必要がある。まず優先すべきはここ
個人情報を扱う（会員情報・問い合わせ内容など）	漏えい時の影響が大きい。取引先や利用者への説明責任も生じる
決済やクレジットカード情報を扱う	業界のガイドラインで定期的な診断が求められている（後述）
新規に構築した、または大きく改修した	ログイン・入力フォーム・ファイルのアップロードなどを追加・変更した場合は特に
開発会社が替わった	前任と後任で作り方の前提が違うため、弱点が紛れ込みやすい
取引先・親会社から診断結果の提出を求められている	取引の条件として必要になる

デジタル庁のガイドラインでも、過去に診断をしたことがないなら、インターネットからアクセスできる部分を優先して診断すべきとしています。また、改修時に診断を行うことが望ましい目安として、入力フォームやAPIの追加・変更、認証（ログイン）や暗号化・ファイルアップロードなど注意を要する処理の追加・変更、そして開発を担当する会社が替わった場合を挙げています。

決済を扱うECサイトの場合は、業界団体の基準も確認しておきましょう。

📰 出典：クレジット取引セキュリティ対策協議会「クレジットカード・セキュリティガイドライン【6.1版】」（2026年3月）

このガイドラインでは、EC加盟店（＝ネットでカード決済を受け付けるお店）が講じる脆弱性対策の一つとして、脆弱性診断またはペネトレーションテスト（＝侵入を試みる実践的なテスト）を定期的に実施し、必要な修正対応を行うことが挙げられています。自社が対象になるかどうか、具体的に何が求められるかは、契約している決済代行会社やカード会社に確認するのが確実です。

逆に、社内ネットワークだけで使う小規模なツールで重要な情報も扱わないなら、優先度は下がります。その場合も「診断しない」と決めた理由を記録しておきましょう。

脆弱性診断の依頼先と選び方

依頼の方法は「開発会社経由」と「直接依頼」の2通り

脆弱性診断の頼み方は、大きく分けて2つあります。どちらが正解ということはなく、状況に応じて選びます。

頼み方	良い点	注意点
開発会社経由（開発会社が手配、または自社で実施）	診断の日程調整や、見つかった問題の修正までの流れがスムーズ	作った会社が自分で点検する場合、見落としの傾向が作り方と同じになりやすい。誰がどの方法で診断するのかを確認したい
発注者が専門会社に直接依頼	開発会社とは別の「第三者の目」で点検できる。結果を発注者が直接受け取れる	日程・診断環境の準備・修正の依頼を発注者が調整する必要がある

開発会社経由で頼む場合も、「どの会社が、ツールと手動のどちらで診断するのか」「報告書の原本を発注者も受け取れるか」は確認しておきましょう。開発会社が自社で点検すること自体は悪いことではなく、開発中のセルフチェックとして大切です。ただ、公開前の最終確認として第三者の診断を入れるかどうかは、扱う情報の重要度に応じて検討する価値があります。

依頼先探しの手がかりは「情報セキュリティサービス基準適合サービスリスト」

どの診断会社に頼めばいいか分からない場合、手がかりになるのが公的なリストです。

📰 出典：IPA（情報処理推進機構）「情報セキュリティサービス基準適合サービスリスト」

これは、経済産業省が定めた「情報セキュリティサービス基準」に適合すると審査されたサービスを、IPAがまとめて公開しているリストです。脆弱性診断サービスの分野があり、オプションとしてペネトレーションテストに対応しているかも分かるようになっています（執筆時点：2026年9月）。基準への適合の審査は審査登録機関が行っています。

ただし、IPA自身が「リストへの掲載はIPAによる保証を意味しない」と明記しています。リストに載っていることは「一定の基準を満たしている」という入口の確認にとどめ、実際の選定では次の点も比べましょう。

診断の種類（Webアプリ／プラットフォーム／スマホアプリ）と、ツール・手動の割合
診断を担当する人の経験や資格（デジタル庁のガイドラインでは、国際資格の保有や脆弱性の届出実績などを確認することが有効とされています）
報告書のサンプルが見られるか、専門家でなくても読める書き方か
報告会（結果説明の場）や、修正後の再診断が含まれているか
診断中にシステムを止めてしまった場合などの連絡体制・安全対策

脆弱性診断の費用が決まる仕組み

脆弱性診断の費用は、会社や診断内容によって幅が大きく、この記事で具体的な金額を示すことはできません。そのかわり、何によって金額が変わるのかを押さえておくと、見積もりの妥当性を判断しやすくなります。

デジタル庁のガイドラインでは、Webアプリケーション診断の費用は主に画面数やAPIなどのリクエスト数（＝システムへの操作の種類の数）によって変動し、プラットフォーム診断はIPアドレス（＝ネットワーク上の住所）の数に応じて変動すると説明しています。これに加えて、一般的には次のような要素が金額に影響すると言われます。

費用を左右する要素	考え方
診断する画面・APIの数	多いほど高くなる。全画面ではなく、ログイン・入力・決済など重要な部分に絞る選択もある
サーバー・機器（IPアドレス）の数	プラットフォーム診断の場合の主な単位
ツールのみか、手動を含むか	手動の割合が多いほど工数がかかる
診断する環境	本番環境か、本番と同じ構成の検証環境か。夜間・休日の実施は追加費用になることがある
再診断・報告会の有無	見積もりに含まれているかを確認する
現地作業の有無	社内ネットワークの内側を診る場合、訪問費用が加わることがある

複数社に見積もりを取るときは、システム開発の見積もりの比べ方と同じく、「同じ範囲・同じ条件」で依頼することが大切です。範囲がそろっていないと、安い見積もりが「診断範囲が狭いだけ」ということも起こりえます。

報告書を受け取った後にやること

診断は、報告書を受け取って終わりではありません。むしろ、ここからが発注者の出番です。

ステップ1：報告会で「自社にとってのリスク」を確認する

報告書では、見つかった問題ごとに「緊急」「重要」などの深刻度が付けられるのが一般的です。デジタル庁のガイドラインでは、CVSS（＝脆弱性の深刻度を0.0〜10.0の点数で示す国際的な指標）がよく使われる一方で、その点数だけで対応の優先度を決めるべきではなく、自社のシステムで想定される具体的なリスクに基づいて判断することが望ましいとしています。

報告会では「この問題が悪用されると、うちの場合は何が起きますか？」と質問すると、優先度をつけやすくなります。

ステップ2：修正計画を立て、費用負担を確認する

深刻度の高いものから、いつ・誰が・どう直すかを開発会社と決めます。ここで確認したいのが「修正の費用は誰が負担するか」です。契約で決めたセキュリティ要件を満たしていなかった場合と、要件になかった新しい対策を追加する場合とでは、扱いが変わることがあります。判断に迷う場合は契約書を確認し、必要に応じて専門家に相談しましょう。

ステップ3：修正後に再診断で確認する

直したつもりでも、本当に直っているかは確かめるまで分かりません。デジタル庁のガイドラインでも、修正した脆弱性に対する再診断を求めています。再診断が見積もりに含まれているか、含まれている場合は「いつまで・何回まで」かを事前に確認しておきましょう。

ステップ4：次の開発や運用に活かす

同じ種類の問題が繰り返し見つかる場合は、作り方そのものに原因があるかもしれません。診断結果は、次回の開発での要件や、運用中の定期診断の計画に反映させると効果が高まります。発注時に決めておきたいセキュリティ要件の全体像は、個人情報を扱うサイトのセキュリティ要件の決め方で解説しています。

脆弱性診断でやりがちな失敗

公開直前に慌てて申し込む：診断会社の日程が埋まっていたり、見つかった問題を直す時間がなかったりします。開発スケジュールの段階で、診断と修正の期間を組み込んでおきましょう
関係者に知らせずに診断する：診断は疑似的な攻撃を行うため、監視のアラートが鳴ったり、システムに負荷がかかったりすることがあります。開発会社・運用担当・クラウド事業者などへの事前連絡と、実施可否の確認が必要です
報告書をもらって満足する：修正しなければ弱点は残ったままです。報告書は「修正のための資料」と考えましょう
一度受けたから安心と考える：新しい弱点は日々見つかります。大きな改修時や定期的な見直しのタイミングで、再度の診断を検討しましょう