ペネトレーションテストとは？脆弱性診断との違い・進め方・発注時の確認事項を解説

経営層向けの要点：目的を決めれば、頼むべき点検が決まる

時間のない方は、この章だけ読めば判断に必要な要点がつかめます。詳しい根拠と手順は次の章から説明します。

• 「攻撃者の目で点検する」に当たるのは、ペネトレーションテストです。経済産業省の「情報セキュリティサービス基準」は、「攻撃者が実際に侵入等を行うために用いる手法と同様の手法」でセキュリティ機能を回避できるかを試験するサービスと定め、脆弱性診断の定義を満たすことを前提にしています。経済産業省の2024年4月4日の発表によると、ペネトレーションテストは脆弱性診断の「オプション」として追加され、登録されたサービスは脆弱性診断を包含するものとして扱われます。
• 目的で使い分け、頻度を変えて組み合わせます。弱点が残っていないかを定期的に確かめるなら脆弱性診断やスキャン、侵入されたらどこまで到達されるかを確かめるならペネトレーションテストです。米国国立標準技術研究所（NIST）の手引き「SP 800-115」は、ペネトレーションテストは費用と影響の大きさから年1回程度で足りる場合があるとし、定期的な脆弱性スキャンと組み合わせる運用を検討するよう述べています。
• 実施前に、範囲と中止の条件を文書で合意します。対象と対象外、実施してよい時間帯、中止の条件、結果の扱いを決めておきます。NISTの手引きは、計画の段階で経営層の承認を得て、ルールを文書に残すこととしています。
• 取引先から★4を求められる会社は、公開している機器の検査が評価に含まれる予定です。IPA「SCS評価制度の詳細情報」によると、取引先が委託先の対策を確かめるSCS評価制度の★4では、インターネットに公開しているVPN装置やルータなどへの脆弱性検査が、技術検証として行われる予定です。
• 業務に組み込んだAIも、点検の範囲に入れるかを検討します。AIセーフティ・インスティテュートは「AIセーフティに関するレッドチーミング手法ガイド」を公開しています。主な読者はAIの開発者と提供者ですが、AIを利用する企業が調達の際に参照することもありうるとしています。詳しくは後半の章で紹介します。

指示も提案も、目的・範囲・期限の3点で伝える

経営者が担当者に出す指示は、たとえば「自社のWebサイトを含め、社外に公開している機器とサービスを対象に、外部の専門事業者による点検を年度内に1回行い、侵入された場合に社内のどこまで到達されるかと、その対策案を報告してほしい」の一文で足ります。目的（侵入された場合の到達範囲を知る）と範囲（社外に公開している機器とサービス）と期限が入っていれば、担当者は脆弱性診断とペネトレーションテストのどちらを、どの事業者に頼むべきかを判断できます。

指示を受けた側は、この3点が指示に入っているかを役員に確かめ返し、頼む点検の種類と頻度、結果の報告のしかたを添えて提案すると、話が早く進みます。報告の受け取り方は、後半の「結果を経営の判断につなげる」で触れます。

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

経済産業省は「情報セキュリティサービス基準」を策定しています。IPAが公開している「情報セキュリティサービス基準適合サービスリスト」は、同基準のペネトレーションテスト（侵入試験）サービスの定義を次のように引用しています。脆弱性診断のサービスの定義を満たすサービスのうち、攻撃者が実際に侵入等を行うために用いる手法と同様の手法により、アプリケーション、システム、又はネットワークのセキュリティ機能を回避して攻撃の目的を達成できるかの観点から試験を行い、その結果をもとに助言を行うサービスです。

弱点を組み合わせて、どこまで到達できるかを見る

米国国立標準技術研究所（NIST）が2008年に公表した「SP 800-115 Technical Guide to Information Security Testing and Assessment」は、ペネトレーションテストを、評価者が現実の攻撃をまねて、アプリケーション、システム、ネットワークのセキュリティ機能を回避する方法を見つける試験と説明しています。

攻撃者がよく使う道具や技術で、実際のシステムとデータに対して攻撃を仕掛けることが多く、手間がかかり、対象のシステムへのリスクを抑えるには高い専門性が要るとしています。同手引きによると、多くのペネトレーションテストは、1つの弱点だけでは得られない権限に、複数の弱点を組み合わせて到達できるかを探すものです。

たとえば外部から入り込めた1台を足がかりに、社内の別のサーバーへ権限を広げられるかを確かめます。

テストで分かること

NISTの同手引きは、ペネトレーションテストで判断できることとして、システムが現実の攻撃パターンにどこまで耐えるか、攻撃者が侵害に成功するにはどの程度の技量が必要か、脅威を和らげる追加の対策は何か、防御する側が攻撃を検知して適切に対応できるか、を挙げています。最後の点は見落としやすいところです。侵入できたかどうかだけでなく、侵入の途中で監視の仕組みが異常に気づけたかも、テストの結果として得られます。

技術以外の手口を含むこともある

NISTの同手引きは、ペネトレーションテストに技術以外の攻撃手法が含まれることもあると述べています。例として、物理的な入館管理を突破して社内ネットワークに接続することや、ヘルプデスクの担当者を装って利用者にパスワードを尋ねるといった、人をだまして情報を引き出す手口（ソーシャルエンジニアリング）が例に挙がっています。こうした手口を範囲に含めるかどうかも、発注前に決めておく事項です。

脆弱性診断との違い：実際に侵入を試みるかどうか

経済産業省は2024年4月4日の発表「『情報セキュリティサービス審査登録制度』の対象に『ペネトレーションテスト（侵入試験）サービス』を追加しました」で、情報セキュリティサービス基準を第4版に改訂し、既存の「脆弱性診断サービス」のオプションとしてペネトレーションテストを追加したと説明しています。同発表によると、ペネトレーションテストは、脆弱性診断の基準を満たすサービスのうち、実際に既知の技術を用いて侵入を試みるテスト方式を提供するものです。登録されたサービスは、既存の脆弱性診断サービスを包含するものとして扱われます。

脆弱性診断の3つの区分

IPAの適合サービスリストに引用されている情報セキュリティサービス基準の定義では、脆弱性診断サービスは、システムやソフトウェアの脆弱性について一定の知見を持つ者が行う、Webアプリケーション脆弱性診断、プラットフォーム脆弱性診断、スマートフォンアプリケーション脆弱性診断のいずれか、またはすべてのサービスです。

ペネトレーションテストの定義は、この脆弱性診断の定義を満たすことを前提にしています。

自社サイトに問い合わせフォームや、管理画面からお知らせを更新できる仕組みがあれば、Webアプリケーション脆弱性診断の対象に含めるかを事業者と相談しておくと安心です。点検を頼む前に、自社サイトが何で動き、誰が更新を担っているかを把握しておくと、診断の範囲を決めやすくなります。その確かめ方は、PHPの脆弱性から自社サイトを守るための解説記事で整理しています。

NISTが挙げる違い：悪用して確かめる

NISTのSP 800-115は、両者の違いを、脆弱性スキャナーは脆弱性が存在する可能性を確かめるだけであるのに対し、ペネトレーションテストの攻撃の段階では脆弱性を実際に悪用してその存在を確かめる、と説明しています。同手引きによると、攻撃に成功すればその脆弱性は実在が確かめられ、それを和らげる対策が特定されます。

使い分けは「組み合わせ」で考える

NISTの同手引きは、ペネトレーションテストは費用と影響の大きさから、年1回の実施で足りる場合があるとしたうえで、より手間の少ない試験を定期的に行い、必要なセキュリティ水準を保っているかを確かめることを検討するよう述べています。定期的なネットワークや脆弱性のスキャンに、周期的なペネトレーションテストを組み合わせた計画が、多くの種類の攻撃を防ぎ、成功した攻撃の影響を減らすのに役立つとしています。

どちらか一方を選ぶものではなく、頻度を変えて組み合わせる、というのが同手引きの考え方です。

テストの種類と進め方：想定する攻撃者を決め、4つの段階で進める

ペネトレーションテストは、想定する攻撃者と、社内のどこまでに実施を知らせるかによって形が変わります。NISTのSP 800-115は、外部からの攻撃を想定するか内部からの攻撃を想定するか、システム担当者に知らせて行うか知らせずに行うか、という2つの軸で説明しています。

外部からの攻撃を想定するテスト

NISTの同手引きによると、外部の攻撃者を想定したテストでは、評価者には対象のIPアドレスやその範囲以外の情報がほとんど渡されません。評価者は公開されているWebページなどから情報を集め、ポートスキャナーや脆弱性スキャナーで外部から到達できる機器を特定し、そのうち1台への侵入を試みます。侵入に成功すれば、その足がかりから、外部からは通常届かない別の機器への侵入を試みます。

内部と外部の両方を行う場合、通常は外部のテストが先というのが同手引きの説明です。

内部からの攻撃を想定するテスト

内部のテストは、悪意のある内部者の行動をまねるものです。NISTの同手引きによると、評価者は社内ネットワーク（ファイアウォールの内側）にいて、一定のアクセス権を与えられた状態から、権限を引き上げてより広い範囲に到達できるかを試します。評価者に渡す情報は、一般の従業員が持つ程度が基本で、テストの目的によってはシステム管理者が持つ情報を渡すこともあります。

外部から1台を乗っ取られた後に何が起きるかを確かめたい場合にも、この形を検討できます。

担当者に知らせて行うか、知らせずに行うか

NISTの同手引きは、システム担当者が承知し同意したうえで行うテストと、担当者には知らせず、経営層の承知と許可のもとで行うテストを分けて説明しています。前者は担当者が影響を抑える助言をしやすく、担当者の学習の機会にもなります。後者は、技術的な対策に加え、担当者がインシデントにどう対応するかも確かめられますが、すべての弱点を洗い出すことは目的にしておらず、時間と費用もかかりやすいとされています。

知らせずに行う場合、同手引きは、テストを本物の攻撃と取り違えて対応を始めないよう、信頼できる第三者が関係者の間を取り持つ方法も紹介しています。

進め方：計画・調査・攻撃・報告の4段階

NISTのSP 800-115は、ペネトレーションテストを計画、調査、攻撃、報告の4段階に分ける例を示しています。同手引きは、これは段階の分け方の一例で、他にも妥当な分け方があるとしています。

計画：経営層の承認と、実施前の取り決め

NISTの同手引きによると、計画の段階では、テストの規則を定め、経営層の承認を得て文書に残し、テストの目標を設定します。この段階では実際のテストは行いません。同手引きは、セキュリティ試験の実施に関する詳しい指針と制約を「ROE（Rules of Engagement）」と呼び、試験の開始前に定めることで、評価者が追加の許可なしに定められた作業を行えるようにするものと定義しています。

計画書が答えるべき問いとして、評価の範囲、評価を行う権限を持つ者、実施の段取り、機微なデータの扱い、インシデントが起きたときの対応を挙げています。

対象外のシステムと、他社が管理するネットワーク

NISTの同手引きは、計画書に、評価してよいシステムとネットワークをIPアドレスやその範囲で示すとともに、評価してはならないシステムを、少なくともIPアドレスで、できればシステム名でも挙げるよう求めています。例として、給与のデータベースのように業務上重要すぎるシステムを除外する場合を挙げています。また、ネットワークの一部が第三者のネットワーク上にある場合は、通常、そのネットワークの所有者からも計画書への書面の同意が必要になるとしています。

外部のデータセンターやクラウドサービスを使っている企業では、発注前に確認しておく事項です。同手引きは、対象として渡された公開IPアドレスがすべて組織の管理下にあるかを、テストを始める前に評価者が確かめるべきだとも注記しています。

調査と攻撃：情報を集め、弱点を実際に悪用して確かめる

NISTの同手引きによると、調査の段階では、ポートやサービスの特定などで情報を集め、見つかった機器やソフトウェアを脆弱性のデータベースと照らし合わせます。攻撃の段階は、調査で見つけた脆弱性を実際に悪用して確かめる、ペネトレーションテストの中心です。悪用に成功して権限を広げられた場合は、さらに調査に戻り、どの情報を読み取り、変更し、削除できるかを確かめます。

同手引きは、ペネトレーションテストで悪用される脆弱性の多くが、安全でない初期設定を含む設定の誤りや、入力の検証不足などの類型に当てはまると説明しています。

報告と再テスト：指摘ごとの対策と、対策後の確かめ方

NISTの同手引きは、報告の段階は他の3段階と並行して進み、テストの終了時には、見つかった脆弱性、危険度の評価、弱点を和らげる方法の指針を記した報告書を作るとしています。対策の提案には、特定の修正プログラムの適用のような技術的なものと、修正プログラムの管理手順の見直しのような業務の進め方に関わるものがあるとしています。

報告書は経営層、セキュリティの責任者、システムの担当者など読み手ごとに形式を変える必要がある場合があるとも述べています。

対策を実施したあとについて、同手引きは、システムの監査や再テストなどで、対策が適切に実施されたかを確かめるとしています。再テストで対策の完了を確かめられるのは、元のテストと同じ内容でテストを行った場合に限られる点にも注意を促しています。

本番環境への影響と、中止の条件

NISTの同手引きは、ペネトレーションテストは本番のシステムとデータに対して実際の攻撃手法を使うため、組織のネットワークとシステムに高いリスクをもたらすと述べています。経験のある評価者はこのリスクを下げられても、完全になくすことはできないとし、慎重な検討と通知、計画のうえで行うよう求めています。同手引きは、次の操作で損害が生じる時点に達したらテストを止めるよう設計できるとも述べています。組織の方針によって、特定の手法や時間帯を制限する場合もあります。

発注するときに確認すること：基準への適合と、合意の中身

ペネトレーションテストを外部の事業者に頼む場合、まず確かめられるのが、経済産業省の基準を満たすサービスかどうかです。IPAの「情報セキュリティサービス基準適合サービスリスト」は、IPAが同基準に適合する情報セキュリティサービスの提供状況を調査し、サービスを利用しようとする人が参照できるように公開しているものです。

2026年10月9日の更新時点で、情報セキュリティ監査、脆弱性診断、デジタルフォレンジック、セキュリティ監視・運用、機器検証のサービスごとにリストが公開され、ペネトレーションテスト（侵入試験）のリストは脆弱性診断のオプションとして掲載されています。

リストの位置づけを理解して使う

IPAの同リストには、掲載された事業者とサービスについてIPAがいかなる保証もするものではないこと、基準に適合するかの審査と判定は特定非営利活動法人日本セキュリティ監査協会（JASA）が運営していることが明記されています。経済産業省の2024年4月4日の発表は、リストに掲載された企業を政府調達や地方公共団体の調達で活用することが推奨されるなど、制度の活用が進んでいるという説明です。

同リストにはサービスごとに、サービスの名称と概要、事業者の名称と所在地、主な顧客の分野や業種、対象とする地域、登録年月日と有効期限、審査登録機関の名称が載っています。登録には有効期限があるため、発注の時点で期限内かを確かめます。リストは候補を絞るための出発点として使い、個々の提案内容は自社で確かめる必要があります。

見積もりを比べる前にそろえる項目

複数の事業者から見積もりを取る場合は、前提をそろえないと比べられません。次の表は、NISTのSP 800-115が計画書と報告書、対策後の検証について述べている事項を、発注側が確かめる項目として並べ直したものです。表の項目をそろえたうえで、各社に同じ条件で見積もりを依頼すると、金額と内容を比べやすくなります。

結果を経営の判断につなげる

NISTの同手引きは、ペネトレーションテストの結果は真剣に受け止め、見つかった脆弱性を和らげるべきだとし、結果は組織の管理者に示すべきだとしています。同手引きは対策の例として、方針や手順の見直し、セキュリティの構成の変更、新しいセキュリティ技術の導入などを挙げています。発注の段階で、経営層向けの要約を報告書に含めるよう依頼しておくと、対策の優先順位と予算を経営の場で決めやすくなります。

点検の範囲は、取引先の評価制度とAIにも広がる

点検の範囲を決めるときに、ここ数年で加わった論点が2つあります。取引先が委託先の守りを確かめるSCS評価制度での技術検証と、業務に組み込んだAIへの点検です。

SCS評価制度の★4では、公開している機器への技術検証が予定されている

取引先が委託先の守りを確かめる仕組みとして、経済産業省と内閣官房国家サイバー統括室は2026年3月27日に、SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）の制度構築方針を公表しました。経済産業省のSCS評価制度のページによると、★3と★4は2026年度末頃の申請受付の開始を目指しており、FAQでは令和8年度末頃（1月〜3月頃）の予定としています。

同ページのFAQは、本制度を任意の制度とし、★の取得は取引契約の中で決められるものだと説明しています。

技術検証の対象と方法

制度を運営するIPAの「SCS評価制度の詳細情報」（2026年5月29日更新）が経済産業省の制度構築方針から抜粋して示す内容によると、★3はセキュリティ専門家が書類を確認する自己評価で、★4は評価機関と技術検証事業者が文書の確認に加えて実地審査と技術検証を行います。技術検証は、取得を希望する組織がインターネットに公開している機器のうち、脆弱性を悪用されると組織の内部に侵入されるリスクが高い機器（例としてVPN装置やルーター）を対象に、既知の脆弱性の悪用などの一般的な攻撃パターンを試み、技術的な検証として脆弱性検査を行うと説明されています。

所要期間は、事前準備と報告書の作成を除いて1〜2日程度が想定されています。合格には、★3・★4ともに原則としてすべての評価基準への適合が求められます。★4で不適合が見つかった場合でも、指摘から一定期間内（例として1か月以内）に是正の報告を出し、了承を得られれば取得できるとされています。

「脆弱性検査」という言葉の扱いに注意する

IPAの同ページは、★4の技術検証を「脆弱性検査」と表現しており、ペネトレーションテストという言葉は使っていません。IPAが2026年9月11日に公開した「技術検証事業者指定基準」は、技術検証で行う診断の具体的な範囲と実施項目を「★4技術検証ガイド」で定めるとしています。同基準の公開ページには、2026年10月時点でこのガイドは掲載されていません。

技術検証にどこまでの手法が含まれるかは、ガイドが公表された段階で確かめる必要があります。同ページは、直近の対象機器への脆弱性検査の結果など、検証に相当する証跡を提出して確認を受けることで、検証の実施に代えることも検討するとしています。外部の専門事業者に点検を頼むなら、その結果をこの証跡として使えるかどうかも、制度の詳細が公表された段階で確かめておくと安心です。

IPAの注意喚起と重なる対象

IPAは2025年10月31日の「VPN機器等に対するORB（Operational Relay Box）化を伴うネットワーク貫通型攻撃のおそれについて」で、VPN機器などの脆弱性が悪用されると機器が乗っ取られ、他の組織への攻撃の中継拠点として使われるおそれがあると注意を呼びかけています。対策として、修正プログラムの速やかな適用、管理画面を外部に公開しないこと、インターネットに公開している範囲の把握などを挙げています。

★4の技術検証の対象として例示された機器と、この注意喚起の対象は重なっており、点検の範囲を決める際の優先順位の手がかりです。

社内で使われているAIを、攻撃者の視点で点検するという考え方

生成AIを社内の文書やシステムとつないで使う場合、AIシステムそのものを攻撃者の視点で点検するという考え方があります。AIセーフティ・インスティテュートの「AIセーフティに関するレッドチーミング手法ガイド（第1.10版）」（2025年3月31日）は、レッドチーミングを、攻撃者がどのようにAIシステムを攻撃するかの観点で、AIセーフティへの対応体制と対策の有効性を確かめる評価手法と定義しています。

同ガイドの掲載ページによると、第1.10版は2024年9月に公開したガイドを改訂したもので、RAG（社内の文書などを検索して回答の生成に使う仕組み）を実装したAIシステムに実際にレッドチーミングを行い、その手順と成果物をまとめています。

AIシステムに特有の攻撃：プロンプトインジェクション

同ガイドは、大規模言語モデル（LLM）を使うシステムに特有の攻撃手法として、プロンプトインジェクションを挙げています。LLMに意図的に異常な動作を起こさせる指示を与え、攻撃者が意図した応答を実行させる攻撃で、禁止された情報の出力、システムの制御の奪取、機密情報の窃取、不正な操作につながりうると説明しています。

同ガイドの分類では、攻撃者が敵対的なプロンプトをAIシステムに直接注入する直接プロンプトインジェクションと、悪意のある指示を仕込んだWebサイトや、RAGが参照する文書などを通じて間接的に注入する間接プロンプトインジェクションの2種類に大別されます。従来のペネトレーションテストが対象としてきたネットワークや機器とは別に、AIの入力と参照先が新しい攻撃の経路になります。

実施の時期は、運用開始前と運用開始後

同ガイドは、レッドチーミングを初めて行う場合は、AIシステムのリリースや運用開始の前までに実施することを基本としています。運用開始後についても、一度実施して完了ではないとし、新たな脅威が懸念される場合や、システムの改修、モデルの更新、システムプロンプトの変更などの際に、定期的に、また必要に応じて随時実施することが望ましいとしています。

同ガイドの主な読者はAIの開発者と提供者にあたる事業者で、その中でも特に、AIシステムの構築や提供を管理する担当者と、事業戦略と一体でAIセーフティの施策を進める責任者を挙げています。AIを利用する企業が調達の際に参照することもありうるとしています。

誰がどのAIを使っているかの把握から始まる

AIの点検は、点検する対象が見えていなければ始められません。社内で誰がどのAIを使い、そのAIがどの情報やシステムにアクセスできるのかを整理することが出発点になります。2027年1月28日（木）の「イプロスAI 2027 冬」では、株式会社Elithによる講演「そのAI、誰が何に使っていますか？ "攻撃者からの視点"で確かめる、AI活用の情報漏えい対策」が予定されています。

講演の案内によると、社内のAI利用とアクセスできる情報の整理、攻撃する側の視点で弱点を探すAIレッドチーミングで対策が機能しているかを確かめる方法、利用ルールや責任体制の整え方が扱われます。

まとめ：点検の目的を経営が決め、結果を経営が受け取る

ペネトレーションテストは、経済産業省の基準では脆弱性診断のオプションとして位置づけられ、攻撃者と同じ手法で守りを回避できるかを確かめる点検です。NISTの手引きは、定期的な脆弱性スキャンと周期的なペネトレーションテストを組み合わせる計画を検討するよう述べています。どちらを、どの範囲で、どの頻度で頼むかは、守りたい業務と取引先から求められる水準によって変わります。

会社案内サイトや問い合わせフォームのように、インターネットに公開している自社のWebサイトも、範囲を決めるときに外せない対象です。SCS評価制度の★4の技術検証やIPAの注意喚起が示すように、インターネットに公開しているVPN機器やルーターは、点検の優先順位を考える手がかりになります。生成AIを社内のシステムとつないで使う企業では、AIシステムを点検の範囲に含めるかも検討に値します。

AIセーフティ・インスティテュートのレッドチーミングのガイドは、主にAIの開発者と提供者に向けたものですが、AIを利用する企業が調達の際に参照することもありうるとしています。目的と範囲を決めて担当者に指示を出し、結果の報告を経営の場で受け取る流れを作っておけば、点検の結果が対策と予算の判断につながります。