Webアプリケーション脆弱性診断とは？項目・方法・費用と進め方

Webアプリケーション脆弱性診断は、WebサイトやWebアプリケーションに潜む脆弱性を発見し、サイバー攻撃による被害を未然に防ぐための対策です。脆弱性は被害が発生するまで表面化しないことも多く、攻撃手法が高度化する現在、適切な方法で早期にリスクを把握し、継続的に対策を講じることが安全性を維持する鍵となります。

本記事では、Webアプリケーション脆弱性診断の主な診断項目、診断方法の選び方、実施タイミング、費用や診断の進め方について解説します。

Webアプリケーション脆弱性診断とは

Webアプリケーション脆弱性診断とは、WebサイトやECサイト、会員向けサービスなどのWebアプリケーションに、情報漏えいや不正操作の原因となる脆弱性がないかを調べる検査です。「Webアプリケーション診断」とも呼ばれ、Webシステムの安全性を調べるセキュリティ診断（脆弱性診断）の一種です。

診断では、ログイン画面や入力フォーム、管理画面、APIなどに対し、攻撃を模した操作や不正なリクエストを制御された条件下で送信します。権限のない操作や本来公開されない情報へのアクセスが可能かを確認し、見つかった脆弱性の影響と危険度を評価します。

プラットフォーム診断・ペネトレーションテストとの違い

Webアプリケーション脆弱性診断と比較されるものに、プラットフォーム診断とペネトレーションテストがあります。それぞれ主な対象と検証の目的が異なりますが、実際の対象範囲には重なる部分もあります。

表1: 診断の種類ごとの対象と目的の違い

Webアプリケーション脆弱性診断とプラットフォーム診断は、Webシステムの異なる部分を主な対象とします。前者はログインや入力処理、アクセス権限などアプリケーションの機能を、後者はOS・ミドルウェア・サーバーなど、その動作を支える基盤を調べます。両者はシステムの異なる層を受け持ち、設定や認証基盤などで診断範囲が一部重なることもあります。

一方、ペネトレーションテストは、あらかじめ定めた攻撃目標に対して侵入や権限の悪用が成立するかを検証するもので、アプリケーションと基盤の両方を対象とする場合も、一部に限る場合もあります。脆弱性診断をすべて包含する上位の検査ではなく、検証目的が異なります。こうした違いを理解するうえでは、Webアプリケーション脆弱性診断における具体的な診断項目を押さえることが重要です。

Webアプリケーション脆弱性診断における診断項目

Webアプリケーション脆弱性診断では、入力値の処理、認証・セッション管理、認可制御、設定・公開範囲などを確認します。主な診断項目と検査内容、問題があった場合の影響は次のとおりです。

表2: Webアプリケーション脆弱性診断の主な項目と確認内容

例えば認可制御では、一般利用者のアカウントで他人の注文履歴や管理者向け機能にアクセスできないかを確認します。操作自体は正常に処理されても、利用者ごとの権限を確認しなければ見落とす場合があるため、画面だけでなくAPIや業務処理も検査対象になります。

診断項目の整理にはIPAの「安全なウェブサイトの作り方」やOWASPの資料が参照されます。OWASP Top 10:2025でもアクセス制御の不備は主要なリスクに位置づけられています。ただし、これらはすべての検査項目を定めるものではなく、決済や会員情報など、実際の機能・データ・利用者権限に応じて確認内容が異なります。

Webアプリケーション脆弱性診断の方法

Webアプリケーション脆弱性診断には、自社の担当者が実施する方法と、セキュリティの専門会社へ依頼する方法があります。いずれの場合も、診断ツールによる自動検査と、人が仕様や操作を確認する手動検査があり、実施する体制と検査の手法は区別されます。

自社で診断する方法

社内の開発・運用担当者がツールを使って脆弱性を確認する方法です。ZAPなどの無料ツールやクラウド型の診断サービスを利用し、入力処理や既知の脆弱性パターンを継続的に確認できます。十分な知識と体制があれば、権限の違いなどを手動で調べることも可能です。

表3: 自社で診断する場合のメリットとデメリット

自社での診断が向いているケースには、次のようなものがあります。

• 開発中や改修後に、同じ検査を繰り返して実施する場合
• 社内にセキュリティ知識を持ち、結果を判断できる担当者がいる場合
• 情報公開が中心のサイトなどで、基本的な検査から始める場合
• 検査結果を社内の開発チームによる修正に活用する場合

専門会社に依頼する方法

専門会社への依頼では、診断ツールを用いた検査のほか、担当者がシステムの仕様や権限を踏まえて手動で検証するサービスも選べます。例えば、注文番号を書き換えることで他人の注文履歴が表示される不備や、処理の順番を変えると本来認められない操作ができてしまう不備は、業務の仕組みを理解した確認が必要です。

表4: 専門会社に依頼する場合のメリットとデメリット

専門会社への依頼が向いているケースには、次のようなものがあります。

• 複数の権限がある：会員・管理者・取引先などで閲覧・操作できる情報が異なる
• 決済や個人情報を扱う：注文・支払い・会員登録など重要な処理がある
• 外部APIや他システムと連携する：複数のサービスをまたいで情報を処理する
• 第三者の証跡が必要：取引先や監査などで報告書の提出が求められる

自社で行う検査と専門会社による診断は、実施主体と確認できる範囲、必要な工数が異なります。診断結果を比較するときは、自動・手動の実施範囲、報告書の内容、修正支援、再診断の条件を区別して確認します。

Webアプリケーション脆弱性診断を実施するタイミング

Webアプリケーション脆弱性診断は、新規リリース前、機能追加・改修後、運用中の定期点検、ガイドラインや取引先から求められたときなどに実施します。いつ、どこを調べるかは、システムの変更内容や扱う情報、外部から求められる条件によって異なります。

表5: 実施タイミングごとの診断範囲と頻度

1. 新規リリースの前

公開前の診断では、利用者に影響が及ぶ前に脆弱性を発見し、修正できます。公開後に問題が判明すると、修正に加えて障害対応や利用者への連絡が必要になる場合があります。

診断の相談から再診断までにかかる期間の目安は、次のとおりです。

表6: 診断の工程別の期間の考え方

※参考として、ラックの従来型サービスについては、相談から報告までの総期間が2〜5週間程度、診断の実施・報告が7〜17営業日程度と紹介されています（IT Leaders、2022年）。これらは一部の工程が重なる期間であり、足し合わせるものではありません。上表は全サービス共通の標準日数を示すものではなく、修正・再診断には別途期間が必要です。

リリース前のスケジュールには、診断と報告書の作成に加えて、重大な脆弱性の修正・再診断にかかる期間も含まれます。修正に設計変更が必要な場合は、その分だけ公開時期に影響することがあります。

開発を外部に委託している場合は、発注の段階で次の点を決めておきましょう。

• リリース前の診断を、納品の受け入れ条件に含めるか
• 診断で指摘された脆弱性を、どこまで開発会社が修正するか
• 修正にかかる費用を、どちらが負担するか

2. 機能追加・改修のあと

次のような重要な変更を加えたときは、変更した部分を中心に診断します。

• ログイン方式の変更
• 決済手段の追加
• 管理画面の改修
• 開発に使っている部品（ライブラリなど）の更新

部品の更新だけでも動作が変わる場合があるため、影響する範囲を開発チームと確認したうえで対象を決めます。

3. 定期的な診断

運用中のアプリケーションも、新しい攻撃手法の登場や設定の変更によって、以前は問題がなかった箇所が脆弱になることがあります。リリース時のツール診断に加えて、重要機能はリスクに応じて手動診断を計画すると、変更の積み重ねによる見落としを減らせます。年1回などの定期実施は一つの例ですが、扱うデータや変更頻度、業界の要件に応じて判断します。

なお、脆弱性診断は実施した時点の安全性を確かめる点検であり、日々発生する攻撃の兆候は捉えられません。運用中の不正アクセスは、ログ監視などの監視体制と組み合わせて検知しましょう。

4. ガイドラインや取引先から求められたとき

次のような場合は、外部からの要請をきっかけに診断が必要になります。

• 業界のガイドラインで求められている場合：クレジットカード決済を扱うECサイトなど、業界のセキュリティ要件で定期的な検査や脆弱性対策が求められている
• 取引先や親会社から求められた場合：委託先の選定や契約の更新にあたり、診断の実施状況や報告書の提出を求められることがある

Webアプリケーション脆弱性診断の流れ

Webアプリケーション脆弱性診断は、目的と範囲の決定、見積もりと計画、準備、診断の実施、報告と修正、再診断の6つの段階で進みます。診断そのものは専門会社やツールが担いますが、範囲の決定や環境の準備、修正の判断は発注側の役割であり、この部分が診断の成果を左右します。

1. 診断の目的と対象範囲を決める

最初に、リリース前の確認、定期点検、取引先への提出など、診断の目的を明確にします。目的によって、必要な診断の深さと報告書の形式が変わるためです。

予算や期間が限られる場合は、攻撃を受けたときの影響が大きい機能から優先して範囲を決めます。前述の、専門会社への依頼を検討したい機能（権限が分かれる機能や管理画面、決済・ポイント、個人情報の入力・表示、外部連携）が優先の目安です。

範囲を決めたら、対象となる画面やAPIの一覧を作成します。見積もりには画面数やリクエスト数に加え、権限の種類、操作の複雑さ、確認する項目の深さなどが影響します。対象一覧を整理することで、必要な作業量を把握しやすくなります。

2. 見積もりを取り、診断計画を確定する

作成した対象一覧と機能の概要を専門会社に渡し、見積もりと診断計画の提案を受けます。複数社を比較するときは、金額だけでなく、準拠する診断基準、手動診断の範囲、再診断の有無などの条件をそろえて並べます。

診断計画では、次の点をあらかじめ決めておきます。

• 診断の日時と、実施する環境（本番環境か、本番と同じ構成のテスト用環境か）
• 診断中の緊急連絡先
• 重大な脆弱性が見つかった場合に、サービスを止めるかどうかの判断基準

3. 診断環境とアカウントを準備する

診断の精度とスケジュールを左右するのが、発注側の準備です。準備が遅れると診断の開始が後ろにずれ、リリース日までに修正が間に合わなくなるため、次の項目は計画の確定と同時に着手します。

表7: 診断の前に発注側が準備するもの

表のうち、機能仕様・権限表とテスト用アカウントは手動診断の質を直接左右します。同じ権限のアカウントが2つあれば「他人のデータを閲覧・変更できないか」を確かめられるため、認可制御の不備を見つけやすくなります。

4. 診断を実施する

診断期間中は、専門会社からの問い合わせにすぐ回答できる担当者を決めておきます。重大な脆弱性が見つかった場合に報告書を待たずに連絡を受け、公開の停止や一時的な回避策を含めて判断できる体制にしておくと、被害が生じうる期間を短くできます。

5. 報告書を確認し、修正の優先順位を決める

IPAに届け出られたウェブサイトの脆弱性のうち、運営者に通知してから90日以上たっても修正の報告がないものが1,067件あります（2026年9月末時点）。診断で脆弱性が見つかっても、修正されなければリスクは減りません。報告書を受け取ったら、次の順で対応を進めます。

1. 脆弱性ごとの危険度と、影響する機能や情報の範囲を確認する
2. 危険度と影響範囲をもとに、修正の優先順位をつける
3. 危険度の高いものから、担当者と期限を決めて修正する

開発会社と診断会社が異なる場合、報告書に再現手順や影響範囲、修正方針が含まれていると、開発担当者が原因を追跡しやすくなります。特に重大な脆弱性は、担当者と対応期限を明確にする必要があります。

6. 修正後に再診断する

修正が完了したら、指摘された箇所が正しく直っているか、修正によって別の不具合が生まれていないかを再診断で確認します。再診断が見積もりに含まれるか、何回まで・いつまで受けられるかは会社によって異なるため、契約前に確認しておきましょう。

Webアプリケーション脆弱性診断の費用

Webアプリケーション脆弱性診断の費用は、診断の方法と対象の規模によって大きく変わり、手動診断では小規模なサイトでも数十万円、大規模なシステムでは1,000万円を超えることもあります。

表8: 脆弱性診断の方法・規模別の費用の目安

※ITトレンド（2026年6月時点）の公開価格例を参考に整理した概算です。画面数の数え方やAPI・権限ごとの検証範囲は各社で異なり、「1画面あたり」の単価をすべての区分に一律適用できるわけではありません。報告会、修正支援、再診断が含まれるかも確認してください。

費用を左右する主な要因の一つが、手動診断の対象となる画面や操作の数です。加えて、API数、利用者の権限の種類、業務処理の複雑さ、報告・再診断の範囲などによっても変わります。リスクの高い機能を優先しつつ、必要な対象を見落とさない範囲で見積もりを比較しましょう。

見積もりで確認すべきポイント

同じ名称の診断サービスでも、見積もりに含まれる作業は会社によって異なります。安く見える見積もりが再診断や報告会を別料金にしている場合もあるため、次の項目をそろえて比較しましょう。

• 対象の数え方：画面数で数えるか、操作（リクエスト）の数で数えるか、APIを含むか
• 手動診断の範囲：どの機能を手動で確認し、どこをツールのみとするか
• 準拠する診断基準：IPAやOWASPのどの基準に沿うか、診断項目の一覧があるか
• 診断の体制：担当する診断員の経験や資格、同種のシステムでの診断実績
• 公的なリストへの掲載：IPAの「情報セキュリティサービス基準適合サービスリスト」に載っているか
• 報告書の内容：危険度、再現手順、修正方法、経営層向けの要約が含まれるか
• 再診断と問い合わせ：再診断の回数と期限、報告後の質問への対応範囲
• 緊急時の連絡：重大な脆弱性の発見時に、報告書を待たずに連絡を受けられるか

診断費用を抑える方法

診断費用は、対象の規模や複雑さ、手動で確認する範囲と深さなどによって変わります。費用を抑えるには、リスクに応じて検査の優先順位を決めることが基本です。具体的には、次の3つが効果的です。

• 重要な機能を優先する：影響の大きい機能から手動診断し、変更のない画面はツール診断で確認する
• 開発工程で先に解消する：ツール診断で定型的な脆弱性を修正してから専門家に依頼する
• 再診断込みで契約する：修正後の確認を追加費用なしで受けられるようにする

あわせて、Webアプリケーションの開発や保守の予算を組む段階で診断と修正の費用を含めておくと、リリースの直前でも予定どおり診断を実施できます。Webアプリ開発費用の内訳や、公開後にかかる保守・運用費の考え方もあわせて押さえておくと、診断を含めた予算を立てやすくなります。

まとめ

Webアプリケーション脆弱性診断は、システムに潜む脆弱性を発見し、危険度や影響範囲を把握することで、サイバー攻撃による被害を未然に防ぐ取り組みです。安全性を維持するには、リリース前や改修後、運用中など適切なタイミングで継続的に診断し、発見した問題を修正・再診断することが重要です。

専門会社に依頼する際は、費用だけでなく、診断範囲や修正支援、再診断への対応も確認しましょう。カオピーズでは、診断から修正支援、再テストまで一貫してサポートしています。Webアプリケーションのセキュリティにお悩みの方は、お気軽にご相談ください。

よくある質問（FAQ）

参考文献

1. 独立行政法人情報処理推進機構（IPA）.（2026）.
   「ソフトウェア等の脆弱性関連情報に関する届出状況[2026年第3四半期（7月～9月）]」.
   https://www.ipa.go.jp/security/reports/vuln/software/2026q3.html（2026年11月4日閲覧）
2. OWASP Foundation.（2025）.
   「OWASP Top 10:2025」.
   https://top10.owasp.org/2025/ja/（2026年11月4日閲覧）
3. 独立行政法人情報処理推進機構（IPA）.（2021）.
   「安全なウェブサイトの作り方」.
   https://www.ipa.go.jp/security/vuln/websecurity/about.html（2026年11月4日閲覧）
4. 独立行政法人情報処理推進機構（IPA）.（2012）.
   「安全なウェブサイトの作り方」別冊「ウェブ健康診断仕様」.
   https://www.ipa.go.jp/security/vuln/websecurity/ug65p900000196e2-att/000017319.pdf（2026年11月4日閲覧）
5. クレジット取引セキュリティ対策協議会.（2025）.
   「クレジットカード・セキュリティガイドライン【6.0版】」.
   https://www.j-credit.or.jp/security/document/index.html（2026年11月4日閲覧）
6. 経済産業省・独立行政法人情報処理推進機構（IPA）.（2023）.
   「ECサイト構築・運用セキュリティガイドライン」を公開.
   https://www.ipa.go.jp/archive/press/2022/press20230316.html（2026年11月4日閲覧）
7. IT Leaders.（2022）.
   「ラック、自動診断でスピードを重視したセキュリティ診断「DiaForce」、最短2営業日で結果を報告」.
   https://it.impress.co.jp/articles/-/22895（2026年11月4日閲覧）
8. ITトレンド編集部.（2026）.
   「セキュリティ診断（脆弱性診断）の費用相場と料金の決まり方｜手動診断・ツール診断・ハイブリッドの価格を解説」.
   https://it-trend.jp/security_assessment_service/article/61-7052（2026年11月4日閲覧）