ペネトレーションテストとは？セキュリティ診断との違いと発注タイミング

本番リリースを前に、上司や開発会社から「ペネトレーションテストをやっておいた方がいい」と言われた経験はないでしょうか。

しかし、「ペネトレーションテストとは具体的に何をするのか」「これまで実施してきたセキュリティ診断と何が違うのか」「いつ・いくらで発注すればいいのか」——そうした疑問に、明確な答えを持てずにいる担当者は少なくありません。

ペネトレーションテストとセキュリティ診断は、一見似たサービスですが、目的・実施方法・成果物が根本的に異なります。この違いを理解しないまま発注を進めると、必要以上のコストをかけたり、逆に不十分な対策のままリリースしてしまうリスクがあります。

本記事では、ペネトレーションテストの意味・セキュリティ診断との違い・実施タイミングの判断基準・費用と期間の目安・発注前の準備事項まで、プロジェクト担当者が意思決定に必要な情報を一通り解説します。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

ペネトレーションテストとは？疑似攻撃でセキュリティの「実力」を測る手法

ペネトレーションテストの意味と定義

ペネトレーションテストとは、セキュリティの専門家（ホワイトハットハッカー）が、実際の攻撃者と同様の手法を用いてシステムへの侵入を試みることで、システムが現実の攻撃にどこまで耐えられるかを検証する手法です。「侵入テスト」「ペンテスト」とも呼ばれます。

ペネトレーションテストでは、「脆弱性が存在するか」を確認するだけでなく、「その脆弱性を実際に悪用した場合、どこまで侵入できるか・どのような被害が発生するか」を実証します。システムに一つひとつの穴がないかを調べるのではなく、「複数の穴を組み合わせて本当に侵入できるか」という現実的な攻撃シナリオで評価します。

テスト実施前には依頼元（発注者）との間でスコープ（対象範囲）・禁止事項・緊急時の連絡体制を合意した上で実施するため、無許可の攻撃（不正アクセス）とは根本的に異なります。

ペネトレーションテストで分かること・分からないこと

ペネトレーションテストで明らかになることは主に以下の3点です。

分かること:

• 攻撃者が実際に侵入できるか（侵入可否の実証）
• 侵入できた場合にどこまでアクセスが広がるか（被害範囲の見積もり）
• 既存のセキュリティ対策が実際の攻撃に機能しているか（対策有効性の検証）

分からないこと・不向きなこと:

• システム全体の脆弱性を網羅的にリストアップすること（脆弱性の「棚卸し」は脆弱性診断が適している）
• 定量的なスコアリング（「安全度80点」のような総合評価は出ない）

ペネトレーションテストは「点検」ではなく「実戦演習」です。システムのセキュリティを多角的に評価するには、脆弱性診断と組み合わせて実施することが理想的です。

セキュリティ診断（脆弱性スキャン）との違い——「発見する」か「侵入する」かの決定的差

比較表：脆弱性診断 vs ペネトレーションテスト

脆弱性診断とペネトレーションテストは、しばしば混同されますが、目的・実施方法・成果物・費用のすべてが異なります。

「健康診断」と「実戦演習」という比喩で整理すると分かりやすいでしょう。脆弱性診断はどこに問題があるかを網羅的にチェックする「健康診断」、ペネトレーションテストは現実の攻撃に対して本当に耐えられるかを確認する「実戦演習」です。

セキュリティ診断で十分なケース、ペンテストが必要なケース

脆弱性診断が適しているケース:

• はじめてセキュリティ対策を体系的に見直したい
• システム全体の脆弱性を一覧化・優先度付けしたい
• 定期的なセキュリティチェックを継続したい（年1〜2回の定期実施）
• 予算を抑えつつ一定のセキュリティ水準を確認したい

ペネトレーションテストが適しているケース:

• 個人情報・クレジットカード情報・医療情報などの機密データを扱うシステム
• 脆弱性診断で基本対策を済ませた後、さらに実際の攻撃耐性を確認したい
• 「本当に侵入できないか」の実証が要件（取引先・監査・法令対応）として求められている
• 攻撃を受けた際の被害範囲・影響範囲を把握しておきたい

脆弱性診断とペネトレーションテストは競合するものではなく、段階的に組み合わせるのが理想的です。「まず脆弱性診断で基本的な問題を洗い出して対処し、重要システムにペネトレーションテストを実施する」という順序が現実的なアプローチです。

ペネトレーションテストが必要な場面——「やるべきタイミング」5つの基準

ペネトレーションテストを実施すべき5つのタイミング

1. 新規Webシステム・アプリケーションの本番公開前

外部からアクセス可能なWebシステムや、不特定多数が利用するサービスは、攻撃者の標的になりやすい環境です。「問題ないだろう」という主観的判断は避け、第三者によるペネトレーションテストで客観的な評価を得ておくことが重要です。特にシステム開発会社から「テストをした方がいい」と言われる場面は、このケースが最も多いです。

2. 個人情報・決済データを扱う機能の実装・追加時

ECサイトの決済機能、会員登録・ログイン機能、医療情報の管理システムなど、機密性の高いデータを取り扱う機能を追加したタイミングはペネトレーションテストの好機です。万一の情報漏えいが重大な損害につながるシステムほど、事前の実証テストが有効です。

3. クラウド移行後・インフラ構成の大幅な変更後

オンプレミスからクラウド（AWS・GCP・Azure）への移行は、設定ミスや権限の過剰付与など新たな攻撃面（アタックサーフェス）が生まれやすい局面です。移行後の早い段階でペネトレーションテストを実施し、クラウド固有のリスクが存在しないか確認することが推奨されます。

4. コンプライアンス対応が求められるとき

PCI DSS（クレジットカード情報の取り扱い基準）では、要件11.3として年1回以上のペネトレーションテストが義務化されています（出典: PCI SSC 補足情報: 要件11.3ペネトレーションテスト）。ISO/IEC 27001の認証取得・維持においても、リスクアセスメントの一環としてペネトレーションテストが有効な対策として位置づけられています。

5. セキュリティインシデント後の再診断

過去に不正アクセス・情報漏えいのインシデントが発生した場合、対策済みであっても同様の手口での侵入が可能かを再検証する目的でペネトレーションテストが有効です。「対策が本当に機能しているか」の実証が、再発防止の信頼性を高めます。

セキュリティ診断（脆弱性スキャン）で代替できるケース

以下のような状況であれば、ペネトレーションテストより脆弱性診断の方が優先度が高い場合があります。

• セキュリティ対策をこれから始める段階: まずは脆弱性診断で基礎的な問題を洗い出すことが先決
• 予算が限られており、広くカバーしたい: 脆弱性診断の方がコストパフォーマンスが高い
• 定期的なチェックを継続したい: 脆弱性診断の方が実施頻度を高めやすい

「ペネトレーションテストを実施すべきか迷っている」という場合は、まず「脆弱性診断を実施したか」「基本的な脆弱性への対処が完了しているか」を確認した上で判断するとよいでしょう。

ペネトレーションテストの費用・期間の目安——発注計画に必要な数字

スコープ別の費用相場

ペネトレーションテストの費用は、対象システムの規模・テストシナリオ数・成果物の深度によって大きく変動します。2026年時点での一般的な相場は以下の通りです（出典: GMOサイバーセキュリティ byイエラエ 費用コラム、CyberCrew 費用解説）。

費用に幅が生じる主な要因:

• 対象範囲（スコープ）の広さ: 画面数・API数・サーバー台数が多いほど費用増
• テストシナリオの数・複雑さ: 「どのような攻撃者を想定するか」によって工数が変わる
• テスト手法（ブラックボックス/ホワイトボックス）: ブラックボックス（システム情報なし）は探索コストが高く、ホワイトボックス（設計情報あり）は効率的だが詳細な準備が必要
• 報告書の深度: 詳細な再現手順・修正方針まで含む報告書は費用が上がる傾向

テスト期間の目安と発注から完了までのスケジュール例

テスト実施期間（実際のテスト日数）の目安:

発注から完了までのスケジュール例（中規模Webアプリの場合）:

本番リリース前にペネトレーションテストを実施する計画であれば、リリース予定日の2〜3ヶ月前には発注先の選定を開始することをお勧めします。テスト後に発覚した脆弱性の修正・再確認の時間も見込んでスケジューリングするとよいでしょう。

発注前に準備すること・結果の活用方法

発注前に発注者が決めておくべきこと

ペネトレーションテストは、発注者が事前にいくつかの重要事項を決めておかないと、実施後に「思っていたテストと違う」という事態が起きやすいサービスです。以下の4点を発注前に整理しておきましょう。

1. スコープ（対象範囲）の明確化

「何を・どの範囲まで」テストするかを具体的に定義します。URLの一覧・IPアドレスの範囲・テスト対象の機能やAPIエンドポイントを洗い出します。スコープが曖昧だと、見積もり精度が下がるだけでなく、本当に検証すべき部分がカバーされないリスクがあります。

2. テスト環境の確保

本番環境へのダイレクトなテストは、サービスの停止や意図しないデータ破損を招く可能性があります。可能であればステージング環境（本番に近い環境）を用意し、テスト実施範囲と本番環境の切り分けを明確にしておきましょう。

3. 責任分担と禁止事項の合意

テスト中に万一サービスに影響が出た場合の対応方針、テストログの保管・提出条件、テスト結果の秘密保持（NDA）など、契約前に発注先と書面で合意しておくことが重要です。「どこまでやっていいか」という禁止事項（DoS攻撃の禁止・本番データの変更禁止など）も明確にします。

4. 社内の承認フローの確認

ペネトレーションテストは「外部から自社システムへの攻撃を許可する」行為です。情報セキュリティ担当・法務・経営層への事前承認が必要な場合があります。社内の承認プロセスを把握し、必要なステークホルダーへの説明資料を用意しておきましょう。

ペネトレーションテスト結果の正しい読み方と活用

テスト完了後に受け取る報告書には、「発見した侵入経路・悪用した脆弱性の詳細・攻撃によって到達したシステム・推奨される対策」が記載されています。報告書を最大限に活用するための3ステップを紹介します。

ステップ1: 発見事項の優先度付けと対応方針の決定

テスト報告書には複数の発見事項が含まれることが多いです。「Critical（緊急対応）」「High（優先対応）」「Medium・Low（計画対応）」といったリスクレベルが付与されているはずです。全項目を一度に対処しようとせず、リスクレベルの高い項目から順に対応計画を立てましょう。

ステップ2: 開発チームへの共有と修正対応

テスト報告書のうち、「脆弱性の詳細と再現手順」に関する部分は開発チームへの説明資料として活用します。ペネトレーションテストの報告書は「攻撃者の視点で書かれた侵入マニュアル」でもあるため、取り扱いには注意が必要です。社内での閲覧制限・保管方法についても事前に決めておきましょう。

ステップ3: 修正完了後の再確認（再テスト）

重大な脆弱性を修正した後は、修正が適切に機能しているかを再テストで確認することが推奨されます。発注先によっては再テストを標準サービスに含めている場合もありますが、含まれていない場合は別途費用が発生します。発注時に再テストの範囲・費用を確認しておきましょう。

まとめ——ペネトレーションテストが「必要な理由」を判断するチェックリスト

ペネトレーションテストは、実際の攻撃者と同様の手法でシステムへの侵入を試みることで、脆弱性診断では見えない「現実の攻撃耐性」を実証するセキュリティ評価手法です。

「脆弱性を発見する（脆弱性診断）」と「侵入できるかを実証する（ペネトレーションテスト）」は目的が異なります。どちらが必要かは、システムの重要度・現在のセキュリティ成熟度・予算・コンプライアンス要件によって判断します。

自己診断チェックリスト: ペネトレーションテストが必要かどうか

以下の質問に1つ以上当てはまる場合、ペネトレーションテストの実施を検討することをお勧めします。

• 個人情報・クレジットカード情報・医療情報など機密データを扱うシステムを本番公開予定である
• PCI DSS・ISO 27001などのコンプライアンス対応でペネトレーションテストが求められている
• 過去に脆弱性診断を実施し基本的な問題は対処済みだが、実際の攻撃耐性を確認したい
• クラウド移行後・大規模な機能追加後など、システム構成が大きく変わった
• 「本当に侵入できないか」の第三者による実証が、取引先や経営層から求められている

次のアクション:

1. 上記チェックリストで必要性を確認する
2. テスト対象のシステム・スコープ（URL・IPアドレス・機能の範囲）を整理する
3. リリース予定日の2〜3ヶ月前に発注先候補への問い合わせ・見積もり取得を開始する

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。