脆弱性診断とは？非エンジニアにもわかる目的・種類・費用と進め方

システムやWebサイトを持つと、必ず向き合うことになるのが「本当に安全なのか」という不安です。その答えを出す手段が脆弱性診断です。名前は専門的ですが、やっていることは「システムの健康診断」に近く、考え方はとてもシンプルです。この記事では、脆弱性診断とは何か、なぜ必要なのか、どんな種類があり、いつ・いくらで行うのかを、専門知識がなくてもわかるように整理します。あわせて「診断して終わり」にしないためのポイントや、開発会社への確認点もまとめます。

脆弱性診断とは — システムの弱点を検査すること

脆弱性診断とは、システムやWebサイトに攻撃者に悪用されうる弱点（脆弱性）がないかを専門的に検査することです。ここでいう脆弱性とは、たとえば「鍵のかかっていない裏口」「誰でも読める形で保存された顧客情報」「不正な文字を入れると誤作動する入力欄」といった、セキュリティ上の欠陥を指します。

イメージしやすいのは健康診断です。見た目は元気でも、検査してみると自覚のない不調が見つかることがあります。システムも同じで、普段は問題なく動いていても、内部には気づかない弱点が潜んでいることが珍しくありません。それを、攻撃者に突かれる前に、専門家やツールが先回りして洗い出すのが脆弱性診断です。

大切なのは、脆弱性診断が**「攻撃者と同じ視点で自分のシステムを見る」**作業だという点です。作った人の視点では「正しく使えば動く」ものでも、攻撃者は「わざと変な使い方をしたらどうなるか」を試します。その視点で先にチェックしておくことで、実際の被害を防ぎます。

• 対象は、Webサイト・業務システム・アプリ・サーバーなど幅広い
• 「動くかどうか」ではなく「悪用できる隙がないか」を見る
• 見つかった弱点は、危険度をつけて一覧で報告される

報告書には、どこに・どんな弱点があり、どれくらい危険で、どう直せばよいか、が一覧でまとめられます。専門用語が並ぶこともありますが、多くの診断では危険度を「高・中・低」のように色分けし、優先すべきものが一目でわかるように整理してくれます。発注側は、その一覧をもとに「どれから直すか」を判断していくことになります。

なぜ脆弱性診断が必要なのか

弱点をそのままにしておくと、具体的にどんな被害につながるのでしょうか。代表的なのは次の3つです。

リスク	どんなことが起きるか
情報漏えい	顧客情報・決済情報・個人情報が外部に流出する
改ざん	サイトの内容やデータを勝手に書き換えられる
踏み台	自社のサーバーを乗っ取られ、他社への攻撃や迷惑メールの発信元にされる

とくに見落とされがちなのが**「踏み台」**です。自社の情報が盗まれるだけでなく、乗っ取られたサーバーが他者を攻撃する加害者になってしまうケースがあります。この場合、被害者であると同時に「管理が甘かった側」として責任を問われることもあり、信用への打撃は小さくありません。

そして重要なのは、攻撃の多くが特定の企業を狙い撃ちにするものではないという点です。「うちは小さいから狙われない」という思い込みは危険で、実際にはインターネット上を機械的に巡回し、弱点のあるサイトを片っ端から突く攻撃が大半を占めます。規模に関係なく、穴があれば入られる——これが前提です。だからこそ、自分のシステムに穴がないかを確かめる脆弱性診断に意味があります。

被害が起きてからの復旧費用や賠償、信用の回復にかかるコストは、診断や修正にかける費用よりはるかに大きくなりがちです。復旧作業の外注、原因の調査、被害者への補償、取引先への説明、そして落ちた信用を取り戻すための時間——これらが一度に押し寄せます。「起きてから対応する」より「起きないか確かめておく」ほうが、結果的に安く済みます。

もう一つ大切なのは、発注側に説明責任が生じる場面があるという点です。個人情報を預かる以上、「きちんと守る努力をしていたか」を問われることがあります。脆弱性診断を実施していた事実は、万一のときに「やるべきことはやっていた」と示す材料にもなります。守りそのものだけでなく、対外的な信頼の裏づけとしても意味があるのです。

脆弱性診断の主な種類

脆弱性診断とひと口に言っても、いくつかの種類があります。まずは「何を対象にするか」で2つに分かれます。

種類	対象	見つけるもの
Webアプリケーション診断	サイトやアプリの画面・機能	入力欄の欠陥、ログインの甘さ、権限のミスなど
プラットフォーム診断	サーバーやネットワークの土台	古いソフトの放置、不要な入口の開放、設定ミスなど

Webアプリケーション診断は、問い合わせフォームやログイン画面など、利用者が操作する部分の弱点を調べます。プラットフォーム診断は、その裏側で動くサーバーやネットワークそのものの弱点を調べます。家に例えるなら、前者は「ドアや窓の鍵のかかり具合」、後者は「建物の基礎や配管」の点検にあたります。どちらか一方では守りきれないため、両方を組み合わせるのが理想です。

次に、「どうやって調べるか」で手動診断とツール診断に分かれます。

• ツール診断：専用ソフトで自動的に弱点を洗い出す方法。短時間・低コストで広く浅くチェックできる。定型的な弱点を機械的に見つけるのが得意。
• 手動診断：セキュリティ専門家が、実際に攻撃者のように手を動かして調べる方法。時間と費用はかかるが、ツールでは見つけにくい複雑な弱点や、その業務ならではの穴まで踏み込める。

現実的には、まずツール診断で全体を広くチェックし、決済や個人情報など重要な部分は手動診断で深く見るという組み合わせがよく使われます。ツール診断は「広く浅く・安く速く」、手動診断は「狭く深く・確実に」と役割が違い、どちらが優れているというより、補い合う関係だと考えるとよいでしょう。予算と守りたいものの重要度に応じて、範囲と方法を決めるのがコツです。診断を頼むときは「ツールと手動のどちらで、どこまで見るのか」を確認すると、内容と費用のバランスを判断しやすくなります。

いつ脆弱性診断をやるべきか

脆弱性診断は「一度やれば終わり」ではありません。システムは作った後も変化し、新しい弱点が世の中で次々と見つかるためです。実施する主なタイミングは次の3つです。

タイミング	目的
公開前	世に出す前に、危険な穴が残っていないか最終確認する
定期的（年1回など）	新しく見つかった脅威に対して、今も安全かを確かめる
改修後	機能追加や修正で、新たな弱点が生まれていないか確認する

もっとも大切なのは公開前です。オープンにした瞬間から、システムは世界中からアクセスできる状態になります。穴が残ったまま公開すると、気づかないうちに突かれてしまいます。公開前の診断1回で防げた被害、というのはよくある話です。

次に、改修後も見落とされがちです。機能を1つ足しただけでも、その部分が新しい入口になることがあります。「前に診断したから大丈夫」とは限りません。大きな変更を加えたら、その範囲だけでも診断しておくと安心です。

そして、脅威は日々更新されるため、年1回程度の定期診断で「今の基準でも安全か」を確かめるのが理想です。昨日まで安全だった作りが、新たに見つかった攻撃手法によって今日は弱点になる、ということが実際に起こります。個人情報や決済を扱うシステムほど、この定期チェックの価値は高まります。

どのタイミングをどこまでやるかは、扱う情報の重要度で決めるのが現実的です。たとえば、社内だけで使う小さなツールなら公開前の一度で十分なこともありますし、不特定多数が使い個人情報を扱うサイトなら、公開前・改修後・定期の三拍子をそろえたいところです。すべてを最高水準でやろうとすると費用がかさむため、重要度に応じてメリハリをつけるという発想が欠かせません。

脆弱性診断の費用の目安

気になる費用ですが、これは**診断の範囲（画面数・機能数）と方法（ツールか手動か）**でおおきく変わります。あくまで一般的な目安として、次のような幅で考えるとよいでしょう。

規模・方法	費用の目安
小規模サイトのツール診断	数万〜十数万円が目安
中規模サイトのツール＋一部手動	数十万円台が目安
重要システムの本格的な手動診断	数十万〜百万円台が目安

金額に幅があるのは、「どこまで見るか」で作業量が変わるからです。トップページだけを見るのと、ログイン後の全機能まで見るのとでは、手間がまるで違います。見積もりを取るときは、「どの画面・どの機能まで診断するのか」を具体的に伝えると、金額の根拠がはっきりします。

コストを抑えたい場合は、いきなり全体をやらず、個人情報や決済を扱う重要な画面から優先して診断するのが現実的です。守りたいものの重要度でメリハリをつけると、限られた予算でも効果的に守れます。安さだけを見て範囲を狭めすぎると、肝心な穴を見逃すおそれがある点には注意しましょう。

なお、脆弱性診断は開発費とは別に見込んでおくのが基本です。新規に開発する場合は、その開発費の中に公開前診断が含まれているか、別途いくらかかるのかを最初に確認しておくと、後から予算が膨らむのを防げます。既に動いているシステムを診断する場合も同様で、「診断の見積もり」と「見つかった弱点を直す見積もり」は分けて考えると、費用の全体像がつかみやすくなります。

診断で終わりではない — 直すまでが大事

ここが、脆弱性診断でもっとも誤解されやすいポイントです。**診断は弱点を「見つける」工程であって、それだけで安全になるわけではありません。**健康診断で不調が見つかっても、治療しなければ健康にならないのと同じです。見つかった弱点を「直す」ところまでやって、はじめて意味があります。

むしろ、診断して弱点を把握したのに放置するのは、リスクを知っていながら対策していない状態であり、かえって危険です。一連の流れは次のようになります。

1. 診断：弱点を洗い出し、危険度をつけて一覧化する
2. 優先順位づけ：危険度の高いものから順に対応を決める
3. 修正：開発会社が弱点をふさぐ改修を行う
4. 再診断：直った箇所が本当に安全になったかを確認する

とくに見落としがちなのが、「診断費用」と「修正費用」は別だという点です。診断だけを頼んで、直す作業や再診断が見積もりに入っていないと、弱点が見つかっても対応が進みません。発注の段階で「見つかった問題は誰が・いくらで直すのか」まで確認しておくことが大切です。

中小企業が最低限やっておきたいこと

「本格的な診断はまだ難しい」という場合でも、最低限これだけは押さえておきたい、という現実的なラインがあります。

• 公開前に一度は診断する：もっとも被害の入口になりやすいタイミングを押さえる
• 個人情報・決済・フォームを優先する：狙われやすく、被害が大きい部分から守る
• 見つかった弱点は必ず直す：診断結果を放置しない。直すまでをセットで考える
• 開発会社に診断を任せられるか確認する：作るだけでなく、安全性の確認まで含めて頼めると安心
• 大きな改修後はその範囲を再チェックする：変更した部分から穴が生まれていないか見る

すべてを一度に完璧にする必要はありません。**「重要なところから」「公開前に一度は」**という2点を守るだけでも、被害の可能性は大きく下げられます。予算や体制が整うにつれて、定期診断や範囲の拡大へ段階的に広げていけば十分です。派手な最新技術より、この当たり前の積み重ねが効く世界です。

セキュリティ対策全体の中での位置づけ

脆弱性診断は、セキュリティ対策全体の中の**「確認する」役割**を担う施策です。守りは大きく分けて、次の3つの積み重ねで成り立ちます。

役割	内容	具体例
防ぐ	弱点を作らない・入口をふさぐ	通信の暗号化、権限管理、こまめな更新
確認する	弱点が残っていないか調べる	脆弱性診断
備える	被害が起きた時に復旧できるようにする	データのバックアップ、復旧手順の準備

脆弱性診断だけをやっても、日々の防御やバックアップがなければ守りは完成しません。逆に、防御していても、それが本当に効いているかを確かめる診断がなければ、思い込みで穴を放置してしまいます。「防ぐ・確認する・備える」を組み合わせることで、はじめて安心できる状態になります。より広い視点はセキュリティ対策の基本、被害への備えはバックアップとBCPもあわせて確認してください。

発注時に開発会社へ確認すること

最後に、システムを発注する際、開発会社に確認しておきたいポイントをまとめます。専門知識がなくても、次の質問を投げるだけで相手の姿勢が見えてきます。

• 脆弱性診断は含まれていますか？ — 公開前のチェックが標準で入っているか
• どんな種類の診断をしますか？ — ツールだけか、手動も行うか、対象範囲はどこまでか
• 見つかった問題は直してもらえますか？ — 修正と再診断まで対応してくれるか、費用は別か
• 費用の総額はいくらですか？ — 診断・修正・再診断まで含めた金額が事前にわかるか
• 公開後の定期診断や改修時の対応は？ — 作って終わりでなく、継続的に見てくれるか

セキュリティの話を避ける、うまく説明できない、という会社は注意が必要です。逆に、こうした質問にきちんと答えられる会社は、目に見えない安全性にも手を抜かない可能性が高いといえます。運用まで見据えた費用感はシステム開発の保守費用、サーバー周りの基礎はサーバーとはも参考になります。

まとめ

脆弱性診断とは、システムやサイトに攻撃者が悪用できる弱点がないかを、健康診断のように検査することです。情報漏えい・改ざん・踏み台といった被害を未然に防ぐための、大切な備えといえます。攻撃は規模を問わず機械的に弱点を突いてくるため、中小企業でも公開前に一度は診断しておくのが安心です。診断はWeb診断とプラットフォーム診断、ツール診断と手動診断に分かれ、守りたいものの重要度に応じて範囲と方法を選びます。そして何より、診断は見つけるだけでは意味がなく、直して再確認するまでが一連の流れです。発注時には「診断・修正・再診断まで含めて、総額いくらか」を確認しておきましょう。

D-oneApp では、料金を一律に固定し、着手前に総額を確定したうえで、安全性の確認まで含めた開発を行っています。「自社のシステムは大丈夫だろうか」と少しでも不安があれば、まずは無料相談からお気軽にご相談ください。