脆弱性診断とは？依頼前に知る種類・費用・流れ入門

2026 8/07

2026年8月7日 2026年8月7日

「顧客からセキュリティチェックシートが届いた」「リリース前にセキュリティの確認を求められた」——そんなきっかけで診断について調べ始めたものの、何を・どこまで・いくらで頼めばよいのかわからず戸惑っていませんか。脆弱性診断とは、システムに潜むセキュリティ上の弱点を網羅的に洗い出す取り組みです。

本記事では、初めて外部に診断を依頼する担当者の方に向けて、ペネトレーションテストとの違い、診断の種類、費用が決まる仕組み、依頼の流れと準備、報告書受領後の対応までを一気通貫で解説します。読み終えるころには、依頼者として自分の言葉で判断・説明できる状態になれるはずです。

脆弱性診断とは？定義とペネトレーションテストとの違い

まずは言葉の整理から始めましょう。ここが曖昧なままだと、診断会社との会話も、社内への説明も噛み合わなくなります。

脆弱性診断の定義と目的

脆弱性診断とは、WebサイトやサーバーなどのITシステムに潜むセキュリティ上の弱点（脆弱性）を、網羅的に洗い出す検査のことです。人間の身体にたとえるなら「健康診断」に近い取り組みです。

健康診断が全身をひととおり調べて異常の候補を挙げるように、脆弱性診断も対象システムを幅広く検査し、見つかった弱点を一覧化します。攻撃者に悪用される前に弱点を把握し、先回りして手当てすることが狙いです。

なお、ここでいう「網羅的」とは、合意した診断範囲と診断項目を漏れなく検査するという意味です。世の中のすべての脆弱性の発見を保証するものではない点は、依頼者として押さえておきましょう。

アウトプットは「攻撃が成功したかどうか」ではありません。脆弱性診断のゴールは、弱点の一覧と、それぞれの深刻度・対処方針をまとめた報告書を手に入れることです。この報告書があるからこそ、修正の優先順位を決め、顧客や上長に対応状況を根拠付きで説明できるようになります。

セキュリティ診断・脆弱性検査との言葉の関係

調べていると「セキュリティ診断」「脆弱性検査」「セキュリティ検査」など、似た言葉が次々に出てきます。結論から言うと、これらはほぼ同義の言い換えと考えて問題ありません。

セキュリティ診断：脆弱性診断を含む、やや広い総称として使われることが多い
脆弱性検査・脆弱性テスト：脆弱性診断とほぼ同じ意味で使われる
サービス名の違い：診断会社ごとの呼び方の差で、中身は範囲と手法で決まる

大切なのは名称ではなく、「どの対象を・どの手法で・どこまで調べるか」という中身です。見積もりを比較する際も、サービス名ではなく診断範囲と診断項目で比較しましょう。

ペネトレーションテストとの違い

最も混同されやすいのがペネトレーションテストです。両者は似ているようで、目的が根本的に異なります。

観点	脆弱性診断	ペネトレーションテスト
目的	弱点を網羅的に洗い出す	特定の目標へ侵入できるかを実証する
範囲	対象システム全体を幅広く	攻撃シナリオに沿って狭く深く
成果物	脆弱性の一覧と深刻度・対処方針	侵入の成否と攻撃経路の報告
向いている場面	リリース前確認・定期的な健康診断	高度な攻撃への耐性を検証したい場面

たとえるなら、脆弱性診断が「健康診断」なのに対し、ペネトレーションテストは「実際に泥棒役を立てて侵入訓練をする」ようなものです。健康診断を受けていない段階で侵入訓練だけを行っても、基本的な弱点が放置されたままになりかねません。

初めての依頼で「まず全体の弱点を把握したい」のであれば、選ぶべきは脆弱性診断です。ペネトレーションテストの詳しい進め方は、ペネトレーションテストの実践方法を解説した記事も参考にしてください。

なぜ脆弱性診断が必要なのか｜依頼のきっかけと放置リスク

「必要なのはわかるが、今すぐやる理由を社内に説明しづらい」という声はよく聞かれます。ここでは、依頼につながる典型的な3つのきっかけと、説明に使える公的資料を整理します。

顧客のセキュリティチェックシート・契約条件への対応

最も多いきっかけは、顧客や取引先からの要求です。「第三者による脆弱性診断を実施しているか」という設問がセキュリティチェックシートに含まれていたり、契約条件に診断の実施が明記されていたりするケースです。

この場合、診断は「やった方がよい施策」ではなく、取引を続けるための条件になります。チェックシートに根拠を持って回答できる状態をつくることが、依頼の第一の目的です。第三者による診断報告書は、その回答の裏付けとしてそのまま機能します。

リリース前の安全確認と定期診断

2つ目のきっかけは、新規リリースや大規模改修です。実施タイミングは次のように考えるのが一般的です。

新規サービスの公開前：本番相当の環境が整った段階で実施する
大きな機能追加・改修の後：変更箇所を中心にあらためて確認する
定期診断：年1回など周期を決め、新たに公表される脆弱性に備える

システムは公開した瞬間から攻撃の対象になります。また、リリース時点では安全でも、後から新しい攻撃手法や既知の脆弱性が公表されることがあります。一度きりで終わらせず、定期的な診断を前提に計画するのが安全です。

逆に、弱点を把握しないまま放置した場合のリスクも想像してみてください。情報漏えいやサービス停止が起きれば、復旧対応や顧客への説明に追われるだけでなく、取引先からの信頼回復には長い時間がかかります。診断費用は、こうした事後対応のコストと比べて判断するのが現実的です。

公的資料に見る脅威の動向

社内説明には、公的機関の資料を根拠に使うのが効果的です。IPA（情報処理推進機構）は毎年「情報セキュリティ10大脅威」を公表しており、組織を狙う脅威の顔ぶれと傾向を把握できます。

また、IPAの「安全なウェブサイトの作り方」は、届出の多い脆弱性とその対策をまとめた定番資料です。Webサイトの弱点がどのように悪用されるかを、非専門家でも理解しやすい形で解説しています。

「公的資料でも繰り返し指摘されている弱点が、自社システムに残っていないかを確認したい」という組み立てにすれば、上長への説明にも説得力が生まれます。

脆弱性診断の種類と自社に必要な診断の選び方

脆弱性診断は、対象ごとにいくつかの種類に分かれています。すべてを一度に実施する必要はありません。それぞれの役割分担を知り、自社に必要なものを選ぶことが大切です。

Webアプリケーション診断

Webアプリケーション診断は、WebサイトやWebシステムの「アプリケーションの作り」に起因する弱点を調べる診断です。ログイン機能や入力フォーム、検索機能などが主な検査対象になります。

代表的な脆弱性には、IPA「安全なウェブサイトの作り方」でも解説されている次のようなものがあります。

SQLインジェクション：不正な入力でデータベースを操作される弱点
クロスサイト・スクリプティング（XSS）：悪意あるスクリプトを埋め込まれる弱点
アクセス制御や認可制御の不備：他人のデータを閲覧・操作できてしまう弱点

これらの根本的な対策はアプリケーション実装の修正であり、サーバー基盤の強化だけでは解消できません。WAF（Webアプリケーションファイアウォール）で攻撃を緩和する保険的な対策もありますが、弱点そのものをなくすには、診断で特定して修正することが必要です。顧客情報を預かるWebシステムを提供しているなら、まず検討すべき診断です。

プラットフォーム診断（ネットワーク診断）

プラットフォーム診断は、アプリケーションを支えるサーバー・OS・ミドルウェアやネットワーク機器を対象とする診断です。ネットワーク診断と呼ばれることもあります。

主に確認するのは、次のような弱点です。

OSやミドルウェアに残る既知の脆弱性（バージョンの古さ）
不要なポートやサービスが外部に公開されている設定不備
推測されやすい設定・初期設定のまま運用されている箇所

アプリケーションの作りが堅牢でも、土台のサーバー設定に穴があれば侵入は起こり得ます。Webアプリケーション診断とは検査する層が異なるため、両者は補完関係にあります。

スマホアプリ診断・その他の診断

スマートフォンアプリを提供している場合は、アプリ本体とAPI（サーバー側の通信窓口）を対象とするスマホアプリ診断があります。アプリ内のデータ保存方法や通信の安全性などが検査対象です。

このほか、クラウドサービスの設定不備を確認するクラウド設定診断などもあります。クラウドの設定ミスが情報漏えいの原因になる事例は公的資料でもたびたび取り上げられており、クラウド中心の構成なら検討する価値があります。

自社に必要な診断を判断する3つの軸

種類を知ったうえで、自社に必要な診断は次の3つの軸で判断します。

判断軸	問いかけ	判断の例
①対象	守りたいシステムは何か	Webシステムが主ならWebアプリ診断＋プラットフォーム診断
②顧客要求	チェックシートは何を求めているか	「Webアプリケーション診断の実施」と明記されていればそれが必須
③リスク優先度	事故が起きたら最も痛い箇所はどこか	個人情報を扱うログイン後の画面を優先する

迷ったら「顧客要求で必須のもの」と「事故時の影響が最も大きい対象」から着手するのが実務的な判断です。全対象を一度に診断しようとして予算が合わず頓挫するより、優先度の高い範囲から確実に進める方が成果につながります。

ツール診断と手動診断の違いと使い分け

脆弱性診断とは弱点を網羅的に洗い出す検査だと説明しましたが、その実施方法には「ツール診断」と「手動診断」の2つがあります。「ツールだけで安く済むのか」は依頼前に最も迷うポイントなので、両者の関係を整理します。

ツール診断の特徴と限界

ツール診断は、専用ソフトウェアが自動でリクエストを送り、既知のパターンに合致する脆弱性を検出する方法です。OWASP ZAPのようなオープンソースのツールも広く知られています。

特徴は、短期間・低コストで広い範囲を検査できることです。既知の典型的な脆弱性を面で洗い出す用途に向いています。

一方で限界もあります。ツールは画面や機能の業務的な意味を理解できないため、「この操作をこの権限でできてはいけない」といった判断ができません。また、検出結果には誤検知（実際には問題がない指摘）が混ざるため、結果の見極めにはある程度の知識が必要です。

「ツールを回せば終わり」ではなく、結果を誰が検証するのかまで含めて考えることが、ツール診断を活かすポイントです。

手動診断の特徴

手動診断は、診断員がツールの結果を検証しつつ、システムの仕様を理解したうえで検査を行う方法です。

強みは、ツールでは見つけにくい弱点を検出できることです。

認可制御の不備（他のユーザーのデータにアクセスできる等）
業務ロジックの穴（手順を飛ばすと不正な操作が通ってしまう等）
複数の弱点を組み合わせた現実的な攻撃経路

そのぶん、時間とコストはツール診断より大きくなります。すべてを手動で行うのではなく、重要な機能に絞って手動診断を割り当てるなど、範囲設計でコストを調整するのが現実的です。

使い分けの判断基準

両者は対立するものではなく、補完関係にあります。比較の観点を表に整理します。

観点	ツール診断	手動診断
コスト	低い	高い
検査の範囲	広く浅く	重要箇所を深く
得意な検出	既知パターンの脆弱性	認可・業務ロジックの穴
向く場面	定期的な健康チェック	ログイン後機能・決済など重要機能

ログインや個人情報を扱う機能があるなら、ツール診断だけで済ませず、手動診断を組み合わせるのが基本です。逆に、静的なコーポレートサイトの定期チェックであれば、ツール中心の診断でも合理的な選択になります。

Webアプリケーションのツール診断で中核となる技術（DAST）の仕組みは、DASTの仕組みと活用方法を解説した記事で詳しく説明しています。

脆弱性診断の費用相場の考え方｜金額が決まる4つの要素

脆弱性診断とは何かがつかめたら、次に気になるのは費用ではないでしょうか。費用は診断会社や条件によって大きく変わるため、「相場は一律いくら」と断定することはできません。しかし、金額が決まる構造を知っていれば、見積もりの妥当性は自分で判断できるようになります。

価格を決める4つの要素

診断費用は、おおむね次の4つの要素で決まります。

要素	内容	金額への影響
①対象の規模	画面数・リクエスト数・IPアドレス数など	規模が大きいほど工数が増え高くなる
②手法	ツール中心か、手動中心か、併用か	手動の比率が高いほど高くなる
③報告の深さ	報告会の有無、再現手順や対策の詳細度	丁寧な報告ほど工数が乗る
④再診断の有無	修正後の確認診断が含まれるか	含まれると総額は上がるが安心につながる

つまり、見積金額の差は「診断員がどれだけの範囲に、どれだけ手をかけるか」の差です。

規模や手法によって大きく変わるため一律の相場は示せませんが、桁感のイメージは持てます。小規模なWebアプリを対象にツール中心で行う診断と、画面数の多いシステムを手動中心で行う診断とでは、数十万円台から数百万円規模まで金額の桁が変わることもあります。この桁感を知っておくと、予算枠を仮置きしやすくなるだけでなく、極端に安い見積もりへの違和感にも気づきやすくなります。

極端に安い見積もりは、範囲が狭いか、ツールのみか、報告が簡素かのいずれかである場合が多いと考えられます。なお、根拠のない「相場表」をうのみにするのは危険です。同じ「Webアプリケーション診断」という名称でも、対象範囲と手法が違えば工数はまったく別物になるためです。金額を見る前に、まず前提条件を確認する習慣をつけましょう。

見積もりの妥当性を見るポイント

複数社の見積もりを比較するときは、金額の絶対値ではなく前提条件を見比べます。

診断範囲の定義が明確か（対象URL・画面数・APIの数が特定されているか）
ツール診断と手動診断の割合が示されているか
報告書のサンプルを確認できるか
再診断や報告会が含まれているか、オプション扱いか

単価の安さではなく、「同じ前提条件に揃えたときにどちらが妥当か」で比較することが、見積もり判断の要点です。前提が曖昧なまま金額だけを比べると、後から範囲外の追加費用が発生しがちです。

上長・顧客に費用を説明するときの組み立て方

社内稟議では、「なぜこの金額が必要か」を構造で説明します。次の順で組み立てると伝わりやすくなります。

目的：顧客のチェックシート回答・リリース前確認など、実施しない場合の影響
範囲：診断対象と、対象を絞った理由（リスク優先度の判断）
金額の根拠：規模×手法×報告の深さという価格構造
実施後の効果：報告書による説明責任の履行と、リスクの低減

費用対効果の示し方や稟議の通し方は、テスト外注の費用対効果を上長に説明する方法をまとめた記事が参考になります。

脆弱性診断を依頼する流れと事前準備・診断会社の選び方

ここからは、実際に依頼するときの動き方です。全体の流れを知り、必要な情報を先に揃えておくと、見積もりも診断もスムーズに進みます。

依頼から報告までの一般的な流れ

一般的な流れは次のとおりです。

問い合わせ・相談：目的ときっかけ（顧客要求・リリース前など）を伝える
診断範囲の確定：対象システム・画面数・環境を共有し、範囲を決める
見積もり・比較検討：前提条件を揃えて複数社を比較する
契約・日程調整：診断時期と体制を確定する
環境・アカウント準備：テスト環境や診断用アカウントを用意する
診断実施：実施中の連絡窓口と緊急時の連絡ルールを決めておく
報告書受領・報告会：結果の説明を受け、質疑で不明点を解消する

期間の目安は、範囲確定から報告書受領まで含めると1〜2か月程度かかることも珍しくありません。リリース日や顧客への回答期限が決まっている場合は、そこから逆算して早めに動き始めることをおすすめします。

もし期限まで1か月を切っている場合でも、打ち手がないわけではありません。診断範囲をログイン後の重要機能などの優先箇所に絞って先行実施する、チェックシートには「実施予定時期」を回答して顧客と合意を取る、といった現実的な選択肢があります。期限が厳しいことも含めて、早めに診断会社へ相談してみてください。

とくに重要なのは2の範囲確定です。ここが曖昧だと、見積もりも診断結果も期待とずれてしまいます。打ち合わせでは目的ときっかけを最初に伝えると、診断会社側も範囲の絞り方を提案しやすくなります。診断の各工程で何が行われるかは、脆弱性診断のプロセスを工程ごとに解説した記事で詳しく紹介しています。

依頼前に準備しておく情報チェックリスト

問い合わせの前に、次の情報を整理しておくと話が早く進みます。

対象のURL・IPアドレスの一覧
対象の規模感（画面数・主要機能・APIの有無）
テスト環境の有無（本番環境しかない場合はその旨も伝える）
診断用アカウントを発行できるか（権限の異なる複数アカウントが理想）
診断可能な時間帯・避けたい日程（業務影響への配慮）
社内・顧客・ホスティング事業者など、関係者への周知の要否

画面数は正確に数えられなくても構いません。ログイン前後や管理画面の有無と、主要な機能を箇条書きで伝えれば、数え方は診断会社が案内してくれます。

また、本番環境で診断する場合は、性能への影響やテストデータの混入、メールの誤送信といったリスクがあります。時間帯の調整や一部検査項目の除外などの緩和策があるため、「本番で診断して大丈夫か」という懸念こそ、最初に診断会社へ相談すべき事項です。

この準備リストを埋めておくだけで、見積もりの精度と診断の立ち上がり速度は大きく変わります。すべて完璧でなくても、わかる範囲で伝えれば診断会社側から必要な確認が返ってきます。

診断会社を比較する観点

診断会社を比較するときは、次の観点を確認します。

比較観点	確認ポイント
公的リストへの掲載	IPA「情報セキュリティサービス基準適合サービスリスト」に掲載されているか
報告書サンプルの質	再現手順・対策・深刻度の記載が具体的か
再診断・報告会	修正後の再診断や報告会が標準か、オプションか
診断員の体制	手動診断の担当者・体制が説明されるか
診断範囲の提案力	こちらの目的に応じて範囲の絞り方を提案してくれるか

客観的な基準としては、IPAの「情報セキュリティサービス基準適合サービスリスト」が有用です。一定の基準を満たすと判断されたサービスが掲載されており、候補選定の出発点にできます。ただし掲載の有無だけで決めるのではなく、報告書サンプルや提案内容と合わせて総合的に判断しましょう。

提案を見極める質問リスト

商談や提案の場では、次の質問を投げかけてみてください。回答の具体性で、診断会社の実力と誠実さがある程度見えてきます。

「この診断範囲を提案する根拠は何ですか？」
「ツール診断と手動診断の割合はどれくらいですか？」
「報告書の再現手順はどこまで書かれますか？サンプルを見せてもらえますか？」
「診断中に重大な脆弱性が見つかった場合、報告書を待たずに連絡をもらえますか？」
「修正後の再診断は費用に含まれますか？」

質問の意図は相手を試すことではなく、前提条件を明確にして後々の齟齬を防ぐことです。曖昧な回答しか返ってこない場合は、範囲や成果物の認識がずれるリスクが高いと判断できます。

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

脆弱性診断は「受けて終わり」ではありません。報告書を読み解き、修正の優先順位を決め、関係者へ報告するところまでが依頼者の仕事です。

深刻度（CVSS）の読み方

多くの報告書では、脆弱性ごとに深刻度が付けられています。広く使われているのがCVSSという共通の採点基準で、攻撃のしやすさや影響の大きさをもとに0.0から10.0のスコアが付きます。

多くの診断会社は、このCVSSスコアとは別のレイヤーとして、「緊急・重要・警告・注意」「Critical・High・Medium・Low」といった独自のレーティングで結果を整理します。名称や段階数は診断会社によって異なるため、報告会で各レーティングの基準を確認しておくと安心です。まずは「深刻度の高い指摘が何件あるか」を把握しましょう。

そのうえで大切なのは、スコアを機械的に受け取らず、自社の文脈で解釈することです。同じスコアでも、個人情報を扱う画面の脆弱性と、社内限定ページの脆弱性では実際の影響が異なります。判断に迷う指摘は、報告会の場で「自社の環境ではどの程度危険か」を診断会社に率直に質問しましょう。