「リリース前に脆弱性診断をやっておきましょう」。開発会社からそう提案され、見積もりに数十万円の追加費用が乗ってきた——。このページにたどり着いたあなたは、いま、その費用を承認すべきか迷っているのではないでしょうか。機能を作るための費用ならわかる。けれど、脆弱性診断は「動くものを作る」ことには直結しません。予算が限られている中で、本当にこの費用が必要なのか、判断する材料がないまま結論を出せずにいる方は少なくありません。
難しいのは、診断を勧めてくるのが開発会社自身だという点です。「これは営業トークではないのか」「断ったら何か問題があるのか」と疑いたくなる一方で、セキュリティの専門知識がないと、その提案が妥当なのかを自分で検証できません。さらに、この費用を社内（上司や経営層）に説明して承認をもらう必要もあり、「もし何かあったら」という漠然とした不安だけでは、説得力のある説明ができないのが実情です。
結論から言えば、脆弱性診断は「動くシステム」ではなく「事業そのもの」を守るための投資です。そして、やるかやらないかは、診断費用とインシデントが起きたときの損失を天秤にかければ、多くの場合おのずと答えが出ます。本記事では、脆弱性診断を売る立場ではない開発会社の視点から、できるだけ中立的に「やる・やらない」の意思決定そのものを支援します。
具体的には、脆弱性診断とは何かという基礎から、実施すべきタイミング、費用相場と見積もりの読み方、そして「診断を断った場合に何が起きるのか」を3つの具体的なリスクシナリオで金額とともに解説します。最後には、開発会社との次の打ち合わせでそのまま使える発注前チェックリストもお渡しします。読み終えるころには、自分でも社内でも「なぜこの費用が必要か」を自分の言葉で説明できるようになっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
脆弱性診断とは｜発注者がリリース前に確認すべきセキュリティ診断
脆弱性診断とは、ひとことで言えば「攻撃者と同じ視点でシステムを調べ、悪用されかねない弱点を洗い出す、リリース前の健康診断」です。人間ドックで体の不調を症状が出る前に見つけるのと同じように、システムが攻撃を受けて被害が出る前に、その弱点を事前に見つけて潰しておくための検査だと考えてください。
脆弱性診断の定義｜攻撃者の視点で弱点を洗い出す
ここで言う「脆弱性（ぜいじゃくせい）」とは、システムに潜むセキュリティ上の欠陥のことです。たとえば、入力フォームに不正な命令文を打ち込むとデータベースの中身を抜き取れてしまう「SQLインジェクション」や、他人になりすましてログインできてしまう認証の不備などが代表例です。こうした欠陥は、見た目には正常に動くシステムの内部に隠れているため、画面を操作しているだけでは気づけません。
脆弱性診断では、専門の診断員や診断ツールが、実際の攻撃で使われる手口を模倣してシステムに対してさまざまなアクセスを試みます。そして「この入力をするとエラー情報が漏れる」「この経路で他人のデータが見えてしまう」といった弱点を一つひとつ特定し、危険度の評価と対策方法をまとめた報告書として提出します。重要なのは、これが「攻撃を仕掛けて壊す」ものではなく、あくまで「弱点を見つけて報告する」客観的なチェックである点です。
脆弱性診断とペネトレーションテストの違い
脆弱性診断と混同されやすいものに「ペネトレーションテスト（侵入テスト）」があります。両者の違いを発注者向けに簡単に整理すると、目的が異なります。
脆弱性診断は「システムにどんな弱点があるかを網羅的に洗い出す」ことが目的で、いわば弱点の一覧表を作る検査です。一方、ペネトレーションテストは「特定の目標（例: 顧客データの窃取）を、攻撃者が実際に達成できてしまうかを試す」ことが目的で、弱点を組み合わせてどこまで侵入できるかを実証するものです。
リリース前の発注者がまず検討すべきなのは、多くの場合、網羅的に弱点を洗い出す脆弱性診断のほうです。ペネトレーションテストは、より高度なセキュリティ要件が求められるシステムや、すでに一定の対策を講じた上で実戦的な検証をしたい場合に選択肢となります。本記事では脆弱性診断を中心に解説しますので、両者の使い分けや発注のタイミングをより詳しく知りたい場合は、ペネトレーションテストとは？セキュリティ診断との違いと発注タイミングもあわせてご覧ください。
なぜ開発会社は自社で作ったシステムに診断を勧めるのか
「自分たちで作ったのだから、自分たちでチェックすればいいのでは」「わざわざ別費用を取るのは商売では」と感じるかもしれません。これは自然な疑問です。しかし、開発会社が脆弱性診断を勧めるのには、客観的な理由があります。
第一に、作り手には盲点が生まれやすいという問題があります。システムを設計・実装した人は「正しい使い方」を前提に作るため、攻撃者が狙う「想定外の使い方」に気づきにくいのです。これは、自分で書いた文章の誤字を自分では見つけにくいのと同じ構造です。
第二に、専門性の違いがあります。開発（作る技術）とセキュリティ診断（攻撃手口を知り尽くして弱点を探す技術）は、隣接していますが別の専門領域です。優れた開発会社ほど、自社開発のシステムであっても第三者の客観的なチェックを通すことの価値を理解しており、だからこそ診断を勧めます。診断を専門会社に外注する場合、開発会社にとっては必ずしも自社の利益が増えるわけではなく、むしろ「品質に責任を持つための提案」であるケースが多いのです。むしろ、リリース前のセキュリティチェックに一切触れない開発会社のほうが、発注者としては注意が必要だと言えます。
脆弱性診断を実施すべきタイミング
「今このタイミングで本当に必要なのか」は、発注者が最も判断に迷うポイントです。脆弱性診断を実施すべき代表的なタイミングは、大きく3つに整理できます。自社の状況がどれに当てはまるかを確認してみてください。
新規リリース前｜公開前の最終チェック
最も重要なのが、システムを世の中に公開する直前のタイミングです。Webサービスや業務システムは、インターネットに公開された瞬間から、世界中の攻撃者の目にさらされます。公開前であれば、弱点が見つかっても誰にも悪用されないうちに修正できますが、公開後に弱点が残っていれば、それは「開いたままの扉」として攻撃者を待ち受けることになります。
開発会社がリリース前に診断を勧めているなら、それはこの「最終チェック」を意味しており、タイミングとしては最も妥当な提案です。新しく作ったシステムや大規模リニューアルでは、それまで世に出ていなかったコードが一斉に公開されるため、リリース前診断の重要性は特に高くなります。
定期診断｜運用フェーズで継続的に実施する目安
一度診断して問題がなくても、それで永久に安全というわけではありません。新しい攻撃手法や、これまで知られていなかった脆弱性は日々発見されています。昨日まで安全だった仕組みが、今日報告された新たな脆弱性によって危険になる、ということが起こり得ます。
そのため、運用を続けるシステムでは定期的な診断が推奨されます。一般的な目安として、サーバーやネットワーク機器を対象とするプラットフォーム診断は年1回程度、扱う情報の重要度が高いサービスでは半期に1回といった頻度で実施されることが多くあります。ただし、これは絶対的な基準ではなく、システムの重要度や扱う情報の機密性に応じて判断するものです。リリース直前の今すぐ定期診断まで契約する必要はありませんが、「運用が始まったら継続的なチェックも必要になる」ことは頭に入れておくとよいでしょう。
重大改修・機能追加後｜変更が新たなリスクを生む
リリース後に大きな機能追加や仕様変更を行った場合も、診断を検討すべきタイミングです。プログラムは一部を変更すると、意図しないところに影響が及ぶことがあります。新しく追加した決済機能や会員登録機能が、それ自体は正しく動いていても、思わぬ弱点を生んでいるケースは珍しくありません。
特に、個人情報や決済情報を新たに扱うようになる改修では、変更箇所を対象とした診断を行うことで、リスクを早期に発見できます。「初回リリース時に診断したから、その後の追加機能は大丈夫」とは限らない、という点は覚えておいてください。
脆弱性診断の費用相場と診断範囲の目安
ここからは、最も気になる費用の話です。「見積もりの数十万円は妥当なのか」を判断するために、相場とその内訳の読み方を押さえておきましょう。
診断の種類別の費用相場
脆弱性診断の費用は、診断する対象と方法によって大きく変わります。2026年時点の一般的な相場の目安は以下のとおりです（株式会社セキュアイノベーションの費用相場解説、株式会社CyberCrew の費用相場解説を参考に整理）。
診断の種類 | 費用相場の目安 | 対象 |
|---|---|---|
Webアプリケーション診断 | 50万〜300万円程度 | 自社サービスや会員サイトなど、画面・機能を持つWebアプリ |
プラットフォーム診断（ネットワーク診断） | 1IPあたり5万〜20万円程度 | サーバー・ファイアウォール・VPN機器などのインフラ |
スマホアプリ診断 | 数十万〜100万円超 | iOS/Androidアプリ本体 |
同じWebアプリケーション診断でも、50万円で収まる場合と300万円かかる場合があります。この幅の大きさが、発注者が「うちの見積もりは高すぎないか」と不安になる原因です。次に、何がこの差を生んでいるのかを見ていきましょう。
費用を左右する4つの要因
費用は、おもに次の4つの要因で決まります。これを理解しておくと、見積もりが妥当な根拠に基づいているかを判断できます。
- 診断手法（ツール診断・手動診断・ハイブリッド）: ツール診断は、診断ソフトで既知の典型的な弱点を高速・広範囲に洗い出す方法で、比較的安価です。一方、手動診断は、診断員がシステム固有のロジック上の欠陥まで人の目で探る方法で、精度は高いものの費用も上がります。多くの場合、両者を組み合わせたハイブリッド診断で費用対効果のバランスを取ります。
- 診断対象の範囲（画面数・リクエスト数・IP数）: 診断する画面や機能（リクエスト）の数、対象となるサーバーのIP数が多いほど、費用は増えます。「サービス全体」なのか「ログイン機能と決済機能だけ」なのかで金額は大きく変わります。
- 診断の深さ: どこまで踏み込んで検査するか（検査項目の網羅度）によっても費用が変わります。
- 診断後のサポート（報告会・再診断の有無）: 報告書を渡すだけか、結果を口頭で説明する報告会があるか、修正後にもう一度確認する再診断が含まれるかで費用が変わります。これらが含まれているかは、後述するチェックリストで必ず確認すべきポイントです。
見積もりの内訳の読み方
見積もりを受け取ったら、金額の絶対額だけを見るのではなく、「何に対していくらか」が書かれているかを確認してください。妥当な見積もりには、診断対象（どの画面・どのサーバーか）、診断手法（ツールか手動かハイブリッドか）、診断項目数やリクエスト数、そして報告書や再診断が含まれるかが明記されています。
逆に、「Webアプリ診断一式 ○○万円」としか書かれていない見積もりは要注意です。範囲も手法も曖昧なまま金額だけが提示されている場合、後から「その画面は範囲外でした」と追加費用を請求されたり、肝心の部分が診断されていなかったりするリスクがあります。極端に安い見積もりも、ツールを流すだけの簡易診断で手動チェックが含まれていない可能性があるため、内訳の確認が欠かせません。見積もりの読み方の判断軸については、株式会社UBsecure による見積もりの読み解き解説も参考になります。
脆弱性診断なしでリリースした場合の3つのリスクシナリオ
ここが本記事の核心です。「やらない理由」を探しているなら、まず「やらなかったら何が起きるか」を具体的に把握してください。脆弱性を放置したままリリースした場合に起こり得る事態を、3つのシナリオで金額とともに見ていきます。これらは社内で費用を説明する際の材料にもなります。
シナリオ1｜個人情報・決済情報の漏洩
最も深刻なのが、顧客の個人情報や決済情報が外部に流出するケースです。SQLインジェクションなどの弱点を突かれてデータベースの中身を抜き取られると、氏名・住所・メールアドレス、場合によってはクレジットカード情報までが流出します。
このとき発生する損害は、漏洩した本人への損害賠償だけではありません。お詫びと通知の費用、問い合わせ対応のためのコールセンター設置、原因調査のための専門業者への依頼、再発防止策の構築など、対応コストが多方面に広がります。
損害賠償の規模感を示す参考として、過去の漏洩事案を集計した調査では、被害者1人あたりの想定損害賠償額は平均で約2万8千円とされています（NPO日本ネットワークセキュリティ協会（JNSA）の調査モデルに基づく集計）。仮に1万人分の個人情報が漏洩すれば、単純計算で賠償だけでも数億円規模に達し得ることになります。実際の裁判例でも、二次被害があったケースで1人あたり3万5千円の賠償が命じられた例があります（ScanNetSecurity による損害賠償の判例解説）。さらに、2022年4月施行の改正個人情報保護法では、一定の漏洩について本人通知・個人情報保護委員会への報告が義務化されており、原則30日以内の確報提出が求められるなど、対応を誤れば法的責任も問われます（個人情報保護委員会）。
数十万円の診断費用と、この規模の損害。どちらのリスクを取るべきかは明らかではないでしょうか。
シナリオ2｜改ざん・不正利用によるサービス停止と復旧費用
二つ目は、Webサイトやシステムそのものを乗っ取られ、改ざんや不正利用をされるケースです。攻撃者にサイトを書き換えられて偽の情報や不正なプログラムを埋め込まれると、被害は自社にとどまりません。サイトを訪れた利用者のパソコンにウイルスを感染させる「踏み台」にされ、自社が加害者側に立たされることもあります。
この場合、まず被害の拡大を止めるためにサービスを緊急停止せざるを得ません。実際に、ソフトウェア提供企業の公式サイトが改ざんされ、偽のインストーラーが配信された事案では、いったん全サイトを閉鎖した上で安全な構成に作り直す対応が取られました（IPA「情報セキュリティ10大脅威 2025」解説書）。サービスを停止している間は売上が止まり、機会損失が積み上がります。さらに、原因調査・システムの作り直し・再発防止策にも費用と時間がかかります。
ECサイトのように売上が直接サービス稼働に依存している事業では、停止が1日続くだけでも損失は大きく、信頼回復までを含めれば被害は金額換算が難しいほど膨らみます。
シナリオ3｜脆弱性の踏み台化と取引先・顧客への波及
三つ目は、すぐには表面化しにくいぶん見落とされがちなリスクです。自社システムの脆弱性を突かれて侵入されると、その経路を足がかりに、つながっている取引先や顧客のシステムにまで攻撃が波及することがあります。近年は、セキュリティの手薄な中小企業をまず狙い、そこを踏み台にして本来の標的である大企業に侵入する「サプライチェーン攻撃」が増加しています。IPA（情報処理推進機構）が公表する情報セキュリティ10大脅威 2026（組織編）でも、「サプライチェーンや委託先を狙った攻撃」は2位に位置づけられており、「規模が小さいから狙われない」という考えが通用しないことを示しています。
この場合、自社が直接の被害を受けるだけでなく、「うちが原因で取引先に迷惑をかけた」という事態になり、取引停止や契約解除、信用の失墜につながります。一度失った信用を回復するには長い時間がかかり、その間の売上機会の損失は計り知れません。金額には表れにくいものの、事業の継続性そのものを揺るがすリスクだと言えます。
診断費用 vs インシデント時の想定損失
ここまでの3シナリオを、診断費用と並べて整理してみましょう。
項目 | 想定される金額・影響 |
|---|---|
脆弱性診断の費用 | 数十万〜数百万円（1回） |
個人情報漏洩（1万人規模）の賠償・対応 | 数億円規模になり得る |
サービス停止・復旧 | 停止日数分の売上機会損失＋調査・復旧費用 |
取引先への波及・信用失墜 | 取引停止・契約解除など金額換算困難 |
こうして並べると、診断費用は「機能開発に無関係な余分なコスト」ではなく、起こり得る巨額の損失に対する保険料に近いことが見えてきます。火災保険に入るのと同じで、何も起きなければ「払い損」に感じるかもしれませんが、一度インシデントが起きれば、その差は取り返しのつかない規模になります。これが、脆弱性診断が「やらない理由がない」投資だと言える根拠です。
発注前の確認チェックリスト
診断を実施すると決めたら、次は「妥当な内容で発注する」段階です。専門知識がなくても、以下のチェックリストの項目を開発会社・診断会社に確認すれば、見積もりと診断内容の妥当性を判断できます。次の打ち合わせにそのまま持っていって使ってください。
診断範囲・手法・ガイドライン適合の確認
- 診断対象は明確か: どの画面・どの機能・どのサーバー（IP）が診断範囲に含まれるかが具体的に書かれているか。「一式」で済まされていないか。
- 診断手法は何か: ツール診断・手動診断・ハイブリッドのどれか。なぜその手法を選んだのか、理由を説明してもらえるか。重要なシステムでツール診断のみになっていないか。
- 診断基準（ガイドライン）に沿っているか: Webアプリの脆弱性で世界的に参照される「OWASP Top 10」など、業界標準の項目を網羅しているか。「どんな基準で何を診断するのか」を確認する。
報告内容・報告会・再診断の確認
- 報告書の内容は十分か: 見つかった脆弱性ごとに、危険度（深刻度）の評価、どう悪用され得るか、具体的な対策方法が記載されるか。専門用語だけでなく、発注者にも理解できる説明があるか。
- 報告会はあるか: 報告書を渡すだけでなく、結果を口頭で説明し質問に答えてくれる場があるか。
- 再診断は含まれるか: 見つかった脆弱性を修正した後、本当に直ったかをもう一度確認する「再診断」が費用に含まれるか、別料金か。修正したつもりが直っていなければ、診断の意味が半減します。
診断会社・開発会社の実績と体制の確認
- 実績はあるか: 同種のシステム（Webサービス・業務システムなど）の診断実績があるか。
- セキュリティ体制は信頼できるか: 診断会社や開発会社自身が、組織として情報セキュリティの管理体制を整えているか。その客観的な指標の一つが、第三者機関による認証の有無です。外注先のセキュリティ基準の見極め方については、ISMS認証取得の開発会社に発注するメリットで詳しく解説しています。
- ネットワーク要件は整理できているか: プラットフォーム診断では、どのサーバー・どの接続経路を対象とするかの整理が必要です。発注者として押さえておきたいネットワークの基礎は、IPアドレス・VPNとは｜発注者が仕様書に書くネットワーク要件の基礎が参考になります。
これらを確認できれば、「言われるがままに発注した」のではなく、「内容を理解した上で妥当な発注をした」と、自分でも社内でも説明できる状態になります。
まとめ｜脆弱性診断は「やらない理由がない」投資
最後に、本記事の要点を整理します。
- 脆弱性診断とは、攻撃者の視点でシステムの弱点を洗い出す、リリース前の健康診断です。作り手には盲点が生まれやすいため、開発会社が第三者チェックとして勧めるのは妥当な提案です。
- 実施すべきタイミングは、①新規リリース前、②運用中の定期診断、③重大改修・機能追加後の3つ。開発会社がリリース前に勧めているなら、タイミングとしては適切です。
- 費用相場は対象と手法で変わります。Webアプリ診断で50万〜300万円程度、プラットフォーム診断で1IPあたり5万〜20万円程度が目安です。見積もりは金額の絶対額ではなく、範囲・手法・報告内容・再診断の有無といった内訳で妥当性を判断してください。
- 診断を断った場合のリスクは、個人情報漏洩による数億円規模の賠償、サービス停止と復旧費用、取引先・顧客への波及による信用失墜など、診断費用を大きく上回り得ます。
脆弱性診断は、機能を作るための費用ではなく、事業そのものを守るための投資です。何も起きなければ「払い損」に見えるかもしれませんが、一度インシデントが起きれば、その損失は診断費用とは比べものにならない規模になります。本記事のチェックリストを手に、開発会社との次の打ち合わせで「診断範囲」「報告内容」「再診断の有無」を自分の言葉で確認してみてください。それができれば、もう「言われるがままの発注」ではなく、根拠を持った意思決定として、自信を持って前に進めるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
