Web脆弱性診断とは｜費用相場・診断範囲・依頼先の選び方

2026年2月14日

＠SOHO編集部

この記事のポイント

✓Web脆弱性診断とは何かを
✓ペネトレーションテストとの違いから費用相場
✓ツール診断と手動診断の使い分け

「Web脆弱性診断を受けろと取引先から言われたが、何をどこまで頼めばいいのか分からない」。まず、安心してください。この戸惑いは、発注する側のほとんどが最初に通る場所です。私も技術文書の品質管理を請け負う立場で何度も診断の現場に立ち会ってきましたが、初回の依頼で相場と範囲の両方を正しく見積もれた会社は、正直なところ多くありません。

この記事では、Web脆弱性診断とは何を調べるものなのか、ペネトレーションテストとどう違うのか、費用はどのくらいで、どこまでの範囲を頼めば十分と言えるのかを、発注する側の判断材料として順番に整理します。診断を受けたあとに何をすれば投資が回収できるのかまで書きます。専門知識がなくても読み進められるように、用語は出てくるたびに説明します。

Web脆弱性診断とは何を調べるものなのか

Web脆弱性診断とは、公開しているWebサイトやWebアプリケーションに対して、攻撃者に悪用されうる作りの弱さが残っていないかを体系的に洗い出し、その危険度を評価する作業です。対象になるのは、会員登録フォーム、ログイン画面、検索欄、問い合わせフォーム、ファイルのアップロード機能、管理画面、そしてスマートフォンアプリが裏側で呼び出しているAPIまで含まれます。要するに、利用者から何らかのデータを受け取っている場所はすべて検査の対象になります。

ここで多くの方が混同するのが、ペネトレーションテストとの違いです。両者は目的が違います。

脆弱性診断は、情報システムのセキュリティ上の弱点（脆弱性）を洗い出し、その危険性を評価するプロセスです。一方、ペネトレーションテストは、攻撃者の視点に立ち、実際の攻撃手法を用いてシステムへの侵入を試みるテストです。脆弱性診断が「健康診断」なら、ペネトレーションテストは「模擬攻撃演習」といえるでしょう。出典: gsx.co.jp

この健康診断と模擬攻撃という対比は、発注の場面でそのまま使えます。健康診断は、悪いところが一つもないことを確認するために全身をまんべんなく調べます。対して模擬攻撃演習は、特定の目的（たとえば顧客データベースに到達できるか）に向かって、道がつながっているかを実際に試します。初めて外部に検査を頼む会社が必要としているのは、ほぼ例外なく前者の健康診断です。順序として、全身を診てもらって明らかな弱点を潰したあとでなければ、模擬攻撃を頼んでも「入口が空いていました」で終わってしまい、費用に見合う知見が得られません。

もう一つ押さえておきたいのが、診断は一度受ければ終わりではないという点です。Webアプリケーションは機能追加のたびに新しい入力経路が増えますし、使っているライブラリやフレームワークには後から欠陥が公表されます。昨年の診断で問題がなかったことは、今日の安全を保証しません。診断を「取引先に出す証明書を取る作業」と捉えると一度きりで終わりますが、「作ったものを壊れていないか確かめる工程」と捉えれば、開発の流れの中に組み込む対象になります。後者の捉え方をしている会社ほど、二回目以降の指摘件数が素直に減っていきます。

診断にかかる費用の相場と、見積もりが割れる理由

費用の話を先にします。市場の相場として、ツールによる自動診断のみのプランはWebサイト1つあたり10万円前後から、技術者が手を動かす手動診断を含むプランは画面の数に応じて30万円〜200万円程度に収まることが多いです。大規模なECサイトや金融系のシステムで、APIや管理画面まで含めて網羅的に診断すると数百万円規模になります。振れ幅がここまで大きいのは、料金の単位が「サイト1つ」ではなく「診断対象の数」で決まるからです。

見積もりの単位は、事業者によって呼び方が違います。よく使われるのは、画面数、リクエスト数、パラメータ数、そして人日です。同じサイトでも、ログイン後の会員向け画面を含めるかどうかで対象数は倍以上に変わります。だからこそ、複数社に相見積もりを取るときは、こちらから対象を明示した一覧を渡すことが欠かせません。サイトのURLだけを送って「一式でいくらですか」と聞くと、各社が勝手に前提を置いて数字を出すため、金額を並べても比べようがなくなります。

安い見積もりが必ず悪いわけではありません。ただし、安さの理由は必ず確かめてください。理由はおおむね三つに分かれます。一つ目は、自動診断ツールの結果をそのまま報告書に流しているケース。二つ目は、診断項目を主要な脆弱性だけに絞っているケース。三つ目は、報告書の提出だけで、指摘内容の説明や再診断が別料金のケースです。このうち三つ目が一番やっかいで、報告書を受け取ったあとに「この指摘の意味が分からない」という状態で止まり、結果として何も直らないまま費用だけが出ていきます。

私が過去に立ち会った案件で、いま思い出しても惜しかったのが、報告書の読み合わせを見積もりに入れていなかった例です。指摘は40件ほど上がったのですが、開発を委託していた制作会社が「これは仕様です」と返してきた項目が半分を占め、そこから先に進めませんでした。診断側と開発側を同じ席に座らせる打ち合わせを一度設けるだけで解ける問題でしたが、その工数が契約に入っていなかったのです。見積もりを比べるときは、金額そのものよりも、報告後にどこまで付き合ってくれるかを見てください。

診断で見つかる代表的な脆弱性を知っておく

指摘の中身を発注側がある程度知っていると、報告書を受け取ってからの判断が速くなります。頻出するものは限られています。

代表的な脆弱性としてまず挙げられるのがインジェクションです。入力フォームや検索欄に不正なコードを埋め込まれることで、データベースに意図しない命令が実行され、情報が改ざんされたり漏えいしたりするリスクがあります。実際に94％のアプリケーションで何らかのインジェクションに関する問題が確認されており、その中でもクロスサイトスクリプティング（XSS）、SQLインジェクション、ファイル名やパス名の外部制御が代表的です。出典: cscloud.co.jp

ここに出てくる用語を、発注側の言葉に置き換えておきます。SQLインジェクションは、検索欄などに入力された文字列がそのままデータベースへの命令として解釈されてしまう作りの弱さです。会員情報の一覧がまとめて抜き出される、価格が書き換えられる、といった被害につながります。クロスサイトスクリプティングは、利用者のブラウザ上で攻撃者の書いたプログラムが動いてしまう弱さで、ログイン中の利用者になりすまされる、入力途中のカード情報が盗まれる、といった形で表れます。この二つは古くから知られているにもかかわらず、いまも指摘件数の上位に残り続けています。

これらと並んで多いのが、権限の抜けです。たとえば注文詳細画面のURLに注文番号が入っていて、その番号を書き換えると他人の注文が見えてしまう。管理者用の画面が、ログインしていなくてもURLを直接叩けば開いてしまう。こうした不備は、機能として正しく動いているために通常のテストでは見つかりません。人が意図を持って試す手動診断が効くのは、まさにこの領域です。自動ツールは「この画面は開けた」という事実は拾えても、「開けてはいけない人が開けた」という判断はできないからです。

設定に起因するものも軽視できません。通信が暗号化されていない、古い暗号方式が有効なまま残っている、エラー画面にサーバーの内部構造が表示される、管理画面の初期パスワードが変わっていない。技術的な難易度は低いのに、攻撃者からすれば最初に試す場所です。開発の話ではなく運用の話なので、担当部署が曖昧になりがちで、だからこそ残ります。診断を受ける前に、この種の設定だけでも自社で一度点検しておくと、報告書の件数が目に見えて減ります。無償で使える診断ツールでどこまで自己点検できるかについては、オープンソースのツールを使った自己診断の手順をまとめたオープンソースで始めるWebサイト脆弱性診断｜OWASP ZAPの使い方ガイドが参考になります。

ツール診断と手動診断はどう使い分けるか

診断の方式は、大きく自動と手動の二つに分かれます。自動診断は、専用のツールがサイトを巡回して既知のパターンを機械的に試す方式です。網羅性が高く、費用が安く、短期間で終わります。定型的な弱さ、たとえば古いライブラリの使用や基本的な設定の不備を拾うのに向いています。一方で、業務の流れに沿って初めて成立する弱さは見つけられません。会員登録から本人確認、注文、キャンセル、返金という一連の流れの途中で権限の確認が抜けている、といった指摘は自動では上がってきません。

手動診断は、技術者が実際に画面を操作しながら、通信の内容を書き換えて挙動を確かめていく方式です。時間も費用もかかりますが、業務ロジックに踏み込んだ指摘が出ます。前の節で触れた権限の抜けや、複数の機能を組み合わせて初めて成立する攻撃は、手動でしか見つかりません。逆に手動だけで網羅性を確保しようとすると工数が膨らむので、実務では両方を組み合わせるのが標準です。自動で広く浅く当たり、重要な機能に手動を厚く配る。この配分をどう決めたかが見積もりの根拠になっているかどうかを、発注時に確認してください。

判断の目安を挙げます。決済、個人情報の登録と閲覧、権限の切り替え、ファイルのアップロードとダウンロード。この四つを持つ機能には手動診断を入れる価値があります。反対に、静的な会社案内ページや、問い合わせフォームだけの小規模なサイトであれば、自動診断と設定の点検で足りることが多いです。全部に手動を入れようとして予算が足りず、結果として一年延期する会社を何度も見てきました。それは最悪の選択です。重要な機能から順に手をつけて、毎年少しずつ範囲を広げるほうが、実質的な安全度はずっと高くなります。

近年は、開発の途中で自動診断を回す仕組みも一般的になりました。コードを更新するたびにツールが走り、新しい指摘が出たらその場で気づける状態にしておくと、外部診断に出す前に基本的なものは片付きます。外部の診断は年に一度か二度、区切りのタイミングで受け、日々の検査は自社の仕組みに任せる。この二段構えが、費用と安全の折り合いをつける現実的な形です。Web開発そのものを外部の人材に委託している場合は、契約の中でこの自動検査の実施を求めておくと、後からの交渉が不要になります。開発を業務委託する際の役割分担の考え方は、Web・業務システム開発のお仕事で、発注側が何を決めておくべきかとあわせて整理されています。

診断を実施すべきタイミングと頻度

いつ受けるかは、費用対効果に直結します。最も効果が高いのは、公開する前です。設計や実装に問題が見つかっても、まだ利用者がいないので修正の影響範囲が小さく、リリース日を調整するだけで対応できます。公開後に同じ指摘が出ると、修正には稼働中のサービスを止める調整が必要になり、対応コストが跳ね上がります。新規サービスの開発計画を立てる段階で、公開の1カ月前に診断の枠を確保しておくのが理想です。

公開後は、次の四つのタイミングが節目になります。一つ目は、大きな機能追加をしたとき。決済手段を追加した、会員種別を増やした、外部サービスとの連携を始めた、といった変更は新しい入力経路を作るので、そこだけを対象にした差分の診断を入れます。二つ目は、システムの基盤を入れ替えたとき。サーバーの移行、フレームワークのバージョン更新、認証の仕組みの変更がこれに当たります。三つ目は、取引先から求められたとき。大企業や官公庁との取引では、診断結果の提出が条件になることが増えています。四つ目は、同業で情報漏えいが起きたとき。同じ作りをしている可能性があるので、自社の該当箇所を確かめる価値があります。

定期的な頻度としては、年に一度を基本線に考えてください。ただし、変更の頻度が高いサービスでは年一度では追いつきません。四半期ごとに自動診断、年に一度手動診断を含む網羅的な診断、という組み合わせにしている会社が多い印象です。予算が限られているなら、毎年全部をやり直すのではなく、対象を分割して順番に回す方法もあります。今年は決済と会員機能、来年は管理画面とAPI、というふうに二年で一周させる。網羅性は落ちますが、何もしない年を作らないことのほうが重要です。

タイミングの話でもう一つ。診断の日程は、修正の時間を含めて逆算してください。診断そのものが2週間で終わっても、報告書が出るまでに1週間、修正に2週間から1カ月、再診断に1週間。全部合わせると2カ月前後を見ておく必要があります。取引先への提出期限が決まっているなら、そこから2カ月半は遡ってください。期限の直前に発注して、修正が終わらないまま「指摘あり」の報告書を提出する事態は、実際によく起きます。

診断範囲をどこまで広げるか、判断の基準

「どこまでやれば十分ですか」という問いに、万人向けの答えはありません。ただ、判断の順序は決められます。優先順位は、そこで扱っているデータの重要度と、失われたときの影響で決まります。

第一優先は、個人情報と決済情報を扱う画面です。氏名、住所、電話番号、メールアドレス、クレジットカード情報、そして本人確認書類の画像。これらに触れる機能は、規模が小さくても必ず対象に入れてください。漏えいしたときの影響が、事業の継続に直結します。第二優先は、権限を持つ画面です。管理画面、社内向けの業務システム、代理店向けのポータル。ここを突破されると、扱えるデータの範囲が一気に広がります。第三優先が、一般利用者向けの機能全般。第四が、更新の止まっている紹介ページや古いキャンペーンサイトです。

この第四に置いた古いサイトが、実は曲者です。担当者が異動して誰も見ていない、使っているソフトウェアの更新が何年も止まっている、そもそも社内に存在自体が把握されていない。攻撃者は、本体のサイトではなくこうした放置されたサブドメインから入ってきます。診断の前に、自社が公開しているドメインとサブドメインの一覧を作る作業をおすすめします。この棚卸しだけで、閉じるべきサイトが見つかることが珍しくありません。閉じられるものを閉じてから診断に出せば、対象数が減って費用も下がります。

範囲を決めるときに一緒に決めておきたいのが、診断の深さです。ログイン後の画面を診断するには、テスト用のアカウントを用意して診断側に渡す必要があります。権限の種類が複数あるなら、それぞれのアカウントを用意します。ここを省くと、外から見える範囲だけの診断になり、前述した権限の抜けは一切見つかりません。手間はかかりますが、会員向けサービスを運営しているなら、テストアカウントの提供は必須と考えてください。中小規模の事業者が公的な補助を使ってこうした対策の費用を賄う方法については、中小企業のサイバーセキュリティ対策2026｜IT導入補助金で防御力を強化する方法に制度の使い方がまとまっています。

発注から報告までの流れを先に把握しておく

初めて依頼する方が不安に感じるのは、頼んだあとに自社が何をするのかが見えない点です。標準的な流れを書き出しておきます。

最初は事前のヒアリングです。対象のURL、画面の一覧、利用している技術、想定している期間、そして診断の目的を伝えます。ここで診断側から対象数の数え方が提示され、見積もりが確定します。目的の共有は軽く扱われがちですが、取引先への提出が目的なのか、実際の防御力を上げたいのかで、診断側の力の入れどころが変わります。正直に伝えてください。

次が準備です。テスト用アカウントの発行、診断元となるIPアドレスの通知と許可、実施する時間帯の調整、そして防御用の機器を一時的に緩める作業が入ります。ここでよくある落とし穴が、Webアプリケーションを守る機器が診断の通信を遮断してしまい、診断が成立しないケースです。遮断されたまま進むと「問題は検出されませんでした」という報告書が出てきますが、それは安全の証明ではありません。防御機器の裏側で診断できているかを、必ず確認してください。

実施期間は、小規模なら3日から1週間、中規模で2週間から3週間が目安です。この間、自社側で必要な作業はほとんどありません。ただし、診断中にサービスの挙動がおかしくなったときに連絡できる窓口を、双方で決めておきます。テストデータが大量に登録されるので、診断後にそれを消す段取りも先に決めておくと後が楽です。

実施後は、報告書の作成に1週間程度かかります。多くの事業者は、危険度の高い指摘だけを実施中に速報として知らせてくれます。重大なものが見つかったときに公開を止める判断ができるよう、この速報の有無は契約時に確認しておくとよいでしょう。報告書を受け取ったら読み合わせの場を設け、指摘の意味と修正方針をその場で確定させます。ここまでを一続きの作業として日程に入れておけば、期限に追われる展開を避けられます。

診断を依頼する会社の選び方

依頼先の選定で見るべき点を、優先度の高い順に挙げます。

一つ目は、診断する人の技術力を客観的に確かめられるかどうかです。診断の品質は、担当する技術者の腕にそのまま左右されます。所属する技術者が持っている資格や、これまでの診断件数は、判断材料になります。

エムオーテックスは、20年の実績と12,000件以上の診断経験を持つ国家資格保有者が多数在籍しています。これにより、高度な技術力と信頼性の高い診断を提供し、開発者とセキュリティ管理者のニーズに応えます。出典: lanscope.jp

二つ目は、報告書のサンプルを事前に見せてもらえるかどうかです。ここが決定的です。良い報告書には、指摘の内容、再現の手順、影響の大きさ、そして具体的な修正方法が書かれています。悪い報告書は、ツールの出力に日本語の見出しを付けただけで、「危険度: 高」という判定の根拠が読み取れません。サンプルを見せられないと言う事業者は、候補から外して構いません。

三つ目は、報告後の関わり方です。指摘内容の説明会を開いてくれるか、開発を委託している会社との間に入って話をしてくれるか、修正後の再診断が含まれているか。再診断が有料の場合、その金額も先に確認します。

四つ目は、公的な基準を満たしたサービスとして登録されているかどうかです。情報セキュリティサービス基準への適合を示すリストに載っているかは、最低限の体制が整っている目安になります。

五つ目は、診断中の事故への備えです。診断は対象システムに負荷をかける作業なので、サービスが一時的に不安定になる可能性があります。事前の通知、実施する時間帯の調整、異常時の連絡体制、そして万一の損害への対応が契約書に書かれているかを確かめてください。本番環境で診断するのか、検証環境で診断するのかも、ここで決めます。可能なら本番と同じ構成の検証環境を用意するのが安全ですが、環境差で見つからない指摘が出るため、最終的には本番での確認も必要になります。

報告書を受け取ってからが本番になる

診断は、報告書を受け取った時点では何も解決していません。ここから先の進め方で、投資が回収できるかどうかが決まります。

まず、指摘の仕分けをします。報告書には危険度の判定が付いていますが、それは一般的な基準での判定です。自社の事情を重ねて、対応の優先順位を付け直します。判断の軸は二つ。悪用されたときの影響と、悪用のしやすさです。影響が大きく、かつ簡単に悪用できるものが最優先。影響が小さく、特殊な条件が揃わないと成立しないものは後回しにしてよい、あるいは「対応しない」という判断を記録に残して閉じても構いません。全部を直そうとすると止まります。直さない決定を、理由付きで残すことが大切です。

次に、修正の担当を決めます。ここで揉めるのが、自社開発でない場合です。制作会社に作ってもらったサイトの指摘を、誰の費用で直すのか。契約書にセキュリティ要件が書かれていなければ、追加費用の交渉になります。この経験を踏まえて言えば、次の発注では契約時に「診断で指摘された項目のうち、実装に起因するものは受注側の責任で修正する」という一文を入れておくべきです。たった一文で、後の交渉が消えます。

修正が終わったら、再診断で確認します。直したつもりが直っていない、別の場所に同じ問題が残っている、修正が原因で新しい問題が生まれた。どれも実際に起きます。再診断まで含めて一区切りと考えてください。そして、指摘の内容と修正方法を社内に記録として残します。同じ種類の指摘が次の診断でまた出るなら、それは個別の不備ではなく、開発の進め方に原因があるということです。原因のほうを直せば、翌年の指摘件数は確実に減ります。

社内の意識を底上げする取り組みも、並行して効きます。技術的な対策を固めても、担当者が偽のメールから認証情報を渡してしまえば意味がありません。従業員向けの訓練をどう設計するかは、社員のセキュリティ意識を向上させるフィッシングメール模擬訓練の効果｜2026年最新の従業員教育ガイドに具体的な進め方が書かれています。

診断を担う人材と、在宅で関わる働き方

最後に、発注側とは逆の視点も書いておきます。この分野は、担い手が足りていません。診断を依頼しようとして「最短で3カ月後から着手」と言われた経験のある方は多いと思います。需要に対して技術者の数が追いついていないのが実情です。その結果として、企業に所属せず業務委託で診断に関わる働き方が広がっています。

20年この市場を見てきた立場から言うと、外部の技術者に仕事が流れる分野には共通した特徴があります。成果物の形が決まっていて、品質の判定基準が客観的で、そして常時ではなく波がある仕事です。脆弱性診断はこの三つをすべて満たします。報告書という明確な成果物があり、指摘の妥当性は再現手順で検証でき、繁忙期が年度末やサービス公開の時期に集中する。だから、正社員として抱えるよりも、必要なときに外部の技術者に出すほうが合理的になります。関連する職種の報酬水準を市場全体で見るなら、ソフトウェア作成者の年収・単価相場に職種別の分布が整理されています。

仲介の手数料が乗らない直接取引の場では、この構造がもう一段はっきり出ます。同じ予算を出す依頼者は、手数料の分だけ多くの作業を頼めます。受け手側は、額面が同じでも手取りが厚くなります。運営者として見てきた限りでは、長く続いている技術者は単発の診断案件を数で追うのではなく、同じ会社の年次診断を毎年任される関係を作っています。一度その関係ができると、前年の指摘内容を把握している強みが効いて、診断の精度も上がり、依頼側の説明コストも下がる。手数料0%の直接取引が持つ価値は、金額の多寡よりもこの継続関係を作りやすいことにあります。

これから学ぶ人にとっての入口も、以前より整っています。ネットワークの基礎を体系的に押さえる意味ではCCNA（シスコ技術者認定）が定番ですし、セキュリティの基礎知識を広く確認するならCompTIA Security+のような資格が指標になります。ただ、資格だけで診断の仕事が来るわけではありません。自分で検証環境を立てて、意図的に弱いアプリケーションを動かし、実際に攻撃を成立させてから直す。この往復を繰り返した記録のほうが、依頼側には響きます。私自身、技術文書の品質管理という周辺の立場から入りましたが、報告書を読める人材が不足していることに何度も助けられました。診断そのものを行う技術者だけでなく、指摘を発注側に翻訳して修正計画に落とす役割にも、確実に需要があります。

発注する側として最初にやるべきことは、大きな話ではありません。自社が公開しているドメインの一覧を作り、そのうち個人情報と決済に触れている画面を書き出す。この二つだけで、見積もりを依頼できる状態になります。完璧な計画を待つ必要はありません。範囲が狭くても、今年一度受けることが、来年の判断材料になります。