セキュリティ診断とは？目的や実施時期と診断の流れを解説

セキュリティ診断とは、WebアプリケーションやサーバーなどのITシステムに潜む脆弱性を、攻撃者の視点で発見し、その危険度と対策を評価する検査です。近年、AIの悪用によってサイバー攻撃が高度化・高速化し、被害が発生する前に脆弱性を発見して対策を講じることが一層重要になっています。本記事では、セキュリティ上の脆弱性とは何かをはじめ、診断の実施時期、種類と進め方、脆弱性発見時の対処法を解説し、自社のリスク評価と適切な対策の選び方を紹介します。

セキュリティ診断とは

セキュリティ診断とは、Webアプリケーションやサーバー、ネットワーク機器、クラウド環境などに、サイバー攻撃の入口となる脆弱性がないかを調べ、その危険度と対策方針を評価する検査です。疑似攻撃や設定の確認によって脆弱性を洗い出し、結果を報告書にまとめるもので、「脆弱性診断」とほぼ同じ意味で使われます。

診断では、システムの構成や特性に応じて、専用ツールによるスキャンや専門家による疑似攻撃などを組み合わせます。単に脆弱性を見つけるだけでなく、どのような被害につながる可能性があるのかを明らかにし、優先して対処すべき問題や必要な対策を判断することが重要です。

ただし、脆弱性はシステムの改修や新たな攻撃手法によって生じるため、一度の診断だけで安全性を維持できるわけではありません。そのため、問題が発生する前にリスクを把握し、継続的に対策を講じることが重要です。カオピーズも、こうした先手を打つ主体的なセキュリティ対策を基本方針として重視しています。

セキュリティ診断が必要な理由

セキュリティ診断を定期的に行う必要があるのは、システムを安全に設計しても、運用中に新たな脆弱性が見つかったり、攻撃の方法が変化したりするためです。特に、外部からの侵入、攻撃の高速化、脆弱性情報の増加、対策の放置という4つの問題は、企業が継続して確認すべきリスクです。

1. 既知の脆弱性や設定不備が侵入経路になる

セキュリティ上の弱点は、Webアプリだけでなく、VPN機器やリモート接続環境などにも存在します。攻撃者はこうした外部からアクセスできる箇所を足掛かりに侵入するため、普段問題なく稼働している機器も診断対象から外せません。

警察庁が公表した2025年のランサムウェア被害報告は226件でした。感染経路に関する有効回答92件のうち、VPN機器が61件、リモートデスクトップが19件を占めており、外部接続の管理が重要な課題であることが分かります。

そのため、アプリケーションの機能だけでなく、公開している接続口や機器の設定、更新状況まで確認する必要があります。

2. AIの悪用で脆弱性を狙う攻撃が高速化している

侵入に使える弱点が見つかっても、修正まで十分な時間があるとは限りません。自動化された探索やAIの悪用によって、攻撃者が脆弱性を調べて試す速度が上がり、企業側が対策を検討できる時間は短くなっています。

2026年10月にJPCERT/CCが公表した国内の不正アクセス事案に関する調査では、攻撃者がAIを利用して既知の脆弱性のスキャンやAPIへの攻撃を行っていたことが示されています。脆弱性が公表された後だけでなく、悪用の兆候を早くつかむことが重要です。

個人情報保護委員会への不正アクセスによる漏えい等の報告は、2026年10月前半だけで830件と、9月1か月分（303件）の約2.7倍に達しています（速報値）。

同月に公表されたPHPの脆弱性では、公表の4日前から悪用の試みが観測されました。Amazonは、AIによって公表から攻撃までが数時間、場合によっては数分に縮まっていると指摘しています。

定期的な診断とあわせて、重大な脆弱性の情報を収集し、自社への影響を速やかに判断できる体制が求められます。

3. システムを変更しなくても新たな脆弱性が見つかる

公開時に安全性を確認したシステムでも、その後に利用中のOSやライブラリ、ミドルウェアで脆弱性が発見されることがあります。自社でプログラムを変更していなくても、外部から利用するソフトウェアの状況が変われば、リスクも変化します。

IPAの「JVN iPedia」に登録された脆弱性対策情報は、2026年4〜6月の3か月間で13,131件となり、2022年7〜9月の4,459件を大きく上回りました。この件数は個々の企業が抱える脆弱性の数を示すものではありませんが、継続的に情報を確認する必要性を表しています。

リリース前の診断だけで終わらせず、運用中の定期診断や構成変更後の確認を組み合わせることが大切です。

4. 脆弱性の放置が情報漏えいと復旧費用につながる

脆弱性の存在を把握していても、修正や更新が後回しになれば、被害につながるおそれがあります。特に顧客情報や決済情報を扱うシステムでは、インシデント発生後の調査、復旧、取引先対応などが事業に大きな負担を与えます。

経済産業省とIPAによる被害を受けたECサイト運営事業者20社の調査では、75%が脆弱性の放置または更新の不実施に該当し、運用時のセキュリティ対策を実施していない事業者は90%でした。また、事故対応費用を支出した19社の平均額は約2,400万円でした。

問題を発見するだけでなく、修正の優先順位を決めて対応を完了し、再診断で解消を確かめることが被害の防止につながります。

セキュリティ診断の必要性と実施時期をチェック

自社システムのセキュリティリスクを把握するには、公開・改修状況、情報の重要度、脆弱性の有無などを確認することが重要です。各項目によって診断の必要性や緊急度は異なるため、以下のチェックポイントを参考に、診断の実施時期と優先度を判断しましょう。

表1: セキュリティ診断の必要性と実施時期のチェックポイント

表と照らし合わせる際は、自社について次の4つの情報を整理しておくと、当てはまる項目を判断しやすくなります。

• 外部への公開範囲：インターネットから到達できるWebサイト、API、サーバー、VPN機器
• 扱う情報：個人情報、決済情報、取引先から預かった機密情報の有無
• 利用製品とバージョン：OS、ミドルウェア、言語・フレームワークのバージョンとサポート期限
• 変更と診断の履歴：直近の改修や設定変更の時期と、前回の診断日

当てはまった項目の優先度に応じて、次のように進めます。複数の優先度に当てはまる場合は、最も高い優先度に合わせて判断します。

• 高：定期診断を待たずに確認する
  1つでも当てはまる場合は、影響の確認やスポット診断を先に行います。不審なログや重大な脆弱性の公表が該当する場合は、「重大な脆弱性が見つかったときの緊急対応手順」に沿って進めます。
• 中：公開や改修の計画に組み込む
  公開や改修、移行の予定に合わせて、診断と修正、再診断の期間をスケジュールに入れます。前回の診断から1年以上たっている場合は、次の定期診断を前倒しで検討します。
• 低：定期診断で継続して確認する
  「低」の項目だけに当てはまる場合も、診断が不要になるわけではありません。侵入後に社内から悪用されることもあるため、年1回の定期診断の対象に含め、利用製品の脆弱性情報の確認は続けます。

IPAの「ECサイト構築・運用セキュリティガイドライン」でも、公開前と、定期的およびカスタマイズ時の脆弱性診断が必須の対策とされています。システムの重要度や業界基準、契約要件によっては、年1回より頻度を上げます。

セキュリティ診断の種類

セキュリティ診断には、システムに潜む脆弱性や設定不備を発見するための代表的な7種類があります。診断の目的や対象によって適した種類は異なり、複数の診断を組み合わせる必要がある場合もあります。そのため、自社のシステム構成や確認したいリスクに応じて、適切な診断を選ぶことが重要です。

1. Webアプリケーション診断

Webアプリケーション診断は、会員サイトやECサイト、業務Webシステムなど、利用者のデータを扱うWebサービスの基本となる診断です。診断の工数は画面やAPIの数で決まるため、すべてを同じ深さで検査すると費用が膨らみます。

個人情報や決済に関わる機能を優先し、機能ごとに診断の深さに差をつけて範囲を決めるのが効率的です。

2. スマートフォンアプリ診断

スマートフォンアプリでは、端末内のデータ保存や通信の安全性に加えて、アプリが接続するAPIの認証・認可を確認する必要があります。画面上でアクセスを制限していても、API側の権限確認が不十分であれば、他の利用者の情報が取得されるおそれがあります。

そのため、診断を依頼する際はiOS・Androidアプリ本体だけでなく、通信先のAPIや権限ごとの操作も診断範囲に含まれているかを確認しましょう。

3. プラットフォーム診断

プラットフォーム診断には、インターネット側から検査する「リモート診断」と、社内ネットワークから検査する「オンサイト診断」があります。

ランサムウェアの侵入経路の多くがVPN機器であることを踏まえ、導入から年数が経ち、更新状況を把握できていない機器は優先して診断対象に加えます。

4. クラウド設定診断

クラウド設定診断は、各社のベストプラクティスやCIS Benchmarksなどの業界基準と照らし合わせて設定を確認する診断です。構成変更が多い環境では、定期診断に加えて設定を継続的にチェックする仕組みを併用すると、不備を早く見つけられます。

AWS環境で確認すべき設定は、AWSセキュリティ対策の主なリスクと検討すべきサービスも参考にしてください。

5. ソースコード診断

ソースコード診断は、開発中の早期発見や受託開発の納品前確認に向いた診断です。システムを動かさずに検査でき、脆弱性の箇所をコードの行単位で特定できます。

ツールによる静的解析を開発工程に組み込み、リリース前のWebアプリケーション診断と組み合わせると、手戻りを減らせます。

6. ペネトレーションテスト

ペネトレーションテストは、「顧客情報を盗み出す」などの攻撃シナリオを設定し、実際に侵入や目的の達成ができるかを検証するテストです。脆弱性を網羅的に洗い出す一般的な診断に対し、侵入された場合にどこまで被害が及ぶかを確かめる点が異なります。

基本的な脆弱性が残ったままでは検証の効果が小さいため、まず通常の診断で脆弱性を修正し、そのうえで機密情報を扱う基幹システムなどに実施するのが効果的な順番です。

7. 生成AIアプリケーション診断

生成AIを組み込んだシステムでは、従来のWebアプリケーションの弱点に加えて、LLM特有の入力処理や情報参照の制御を確認する必要があります。社内文書を検索するAIやチャットボットでは、意図しない情報の表示や権限を超えた参照が問題になります。

たとえばプロンプトインジェクションへの耐性や出力内容の制御は、一般的なWeb診断だけでは十分に確認できません。生成AIを業務に組み込む場合は、公開前の検証項目にこうした固有のリスクを含めましょう。

セキュリティ診断の方法

診断の種類が決まっても、どの範囲をどの深さまで検査するかによって、発見できる問題は変わります。広い範囲を効率よく確認するツール診断と、仕様や権限の違いまで踏み込む手動診断の特徴を理解し、自社で実施する範囲と外部へ任せる範囲を考えましょう。

1. ツール診断と手動診断の違い

同じセキュリティ診断でも、ツールを用いて多数の箇所を確認する場合と、専門家が操作や仕様を理解したうえで検証する場合では、発見しやすい問題が異なります。どちらか一方だけで十分と考えるのではなく、診断対象の重要度と確認したいリスクに合わせて組み合わせることが重要です。

表2: ツール診断と手動診断の比較

両者の差が最も大きいのは、システムの仕様を理解しないと判定できない脆弱性です。たとえば「URLの番号を書き換えると他人の注文履歴が表示される」といった認可の不備は、ツールでは正常な応答と区別しにくく、手動診断でなければ見つけにくい代表例です。

そのため、全体はツール診断で定期的に検査し、決済や会員情報など被害が大きい機能に手動診断の工数を集中させるのが現実的です。

2. セキュリティ診断の内製と外部委託の選び方

ツール診断は、ツールを導入すれば自社でも実施できます。ただし、検出結果には誤検知が含まれるため、どれが本当に危険で、どう直すべきかを判断できる人材がいることが内製の前提です。

手動診断やペネトレーションテストを外部へ委託する場合は、対象範囲や診断基準だけでなく、報告書に再現手順や修正方法が含まれるか、修正後の再診断まで依頼できるかを確認しましょう。社内の開発担当者と診断員が直接相談できる体制も重要です。

社内に判断できる人材がいない場合は、まず外部委託で診断と修正の流れを経験し、そのうえで定期的なツール診断から内製に移していくと、無理なく体制を整えられます。

セキュリティ診断の流れ

セキュリティ診断は、目的と範囲の決定、依頼先の選定、実施条件の調整、診断の実施、報告書の確認、修正・再診断の6段階で進めます。特に、診断前の範囲設定や実施条件の調整に加え、診断後の脆弱性への対応まで計画し、検査漏れや業務への影響を防ぐことが重要です。

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

診断を始める前に、何のために安全性を確認するのかを明確にします。新規公開前の確認なのか、改修後の検証なのか、取引先への説明なのかによって、対象となるシステムや求められる検査の深さは変わります。

目的が決まったら、診断対象のURLやAPI、IPアドレスの一覧を作り、優先して検査する機能を決めます。本番環境と検証環境のどちらで実施するかも、この段階で決めておきます。

リリース計画を立てる段階で、診断と修正、再診断に必要な期間をスケジュールに組み込んでおくと、診断結果を理由にリリースが遅れる事態を防げます。

2. 依頼先を選び、見積もりを比較する

範囲が決まったら、複数の事業者に同じ条件で見積もりを依頼します。条件がそろっていないと、画面数の数え方や手動で検査する範囲が事業者ごとに異なり、金額だけでは比較できません。見積もりの段階では、次の点を確認します。

• 診断基準：OWASPの基準やIPA「安全なウェブサイトの作り方」など、何を基準に検査するか
• 診断範囲と深さ：対象の画面数・API数と、手動で検査する範囲
• 報告書の内容：危険度、再現手順、修正方法の具体性（サンプルで確認）
• 再診断の条件：修正後の確認が見積もりに含まれているか
• 修正の支援：修正方法の相談や、開発チームへの説明に対応できるか

価格だけで比較すると、報告書の質や再診断の有無といった差を見落とすため、同じ範囲で見積もりをそろえてから比較します。

3. 診断の実施条件を調整する

診断の日程と時間帯、診断中の緊急連絡先を事業者と取り決めます。疑似攻撃は実際の攻撃と同じように見えるため、社内の監視担当者やデータセンターへの事前連絡、クラウド事業者の利用規約で求められる手続きも確認しておきます。

WAFやIPSが稼働している場合は、診断の通信を遮断しない設定にするかどうかも決めます。遮断したまま診断すると、防御装置の効果は確認できても、アプリケーション自体の脆弱性は見えなくなるためです。

4. セキュリティ診断を実施する

診断の実施条件が整ったら、合意した範囲でツールによる検査や専門家による確認を進めます。対象の規模や手動検査の比率によって所要日数は変わるため、途中で重大な問題が見つかった場合の連絡方法もあらかじめ決めておきます。

診断によってテストデータの登録やメール送信が発生することもあります。本番環境で実施する場合は、利用者への影響が出ないよう対象の機能と時間帯を限定します。

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

診断が終わると、検出された脆弱性ごとに危険度、再現手順、修正方法をまとめた報告書が提出されます。報告会の場で開発担当者も交えて内容を確認すると、修正の進め方を具体的に決めやすくなります。

危険度は、共通脆弱性評価システム「CVSS」などの基準で評価されるのが一般的です。ただし、同じ危険度でも、インターネットから到達できるか、個人情報を扱うか、すでに悪用が確認されているかによって、実際のリスクは大きく変わります。

IPAの「重要なセキュリティ情報」で注意喚起されている脆弱性や、すでに攻撃への悪用が報告されている脆弱性は、危険度の数値にかかわらず最優先で扱います。優先度と対応期限の目安は、たとえば次のように設定できます。

表3: 脆弱性への対応の優先順位（設定例）

※対応期限は一例です。自社の体制や取引先との契約条件に合わせて基準を定めてください。

報告書には、業務上の仕様として許容しているものや、すでに別の対策で防いでいるものが含まれる場合もあります。検出結果を「修正する」「別の対策で補う」「リスクを受け入れる」に仕分け、判断の理由を記録しておきます。優先順位の基準を社内であらかじめ決めておけば、緊急時にも報告書や注意喚起を受け取ってすぐに対応へ移れます。

6. 脆弱性を修正し、再診断する

脆弱性への対応の基本は、プログラムの修正や修正パッチの適用といった根本対策です。修正に時間がかかる場合は、WAFによる攻撃の遮断、該当機能の一時停止、アクセス元の制限などの暫定対策で被害を防ぎ、解除の条件と根本対策の期限を決めて放置されないよう管理します。

サポートが終了した製品に依存し、修正自体が難しいシステムでは、レガシーシステムの刷新も含めて対応方針を検討します。

修正が完了したら、同じ方法で再診断を行い、脆弱性が確実に解消されたかを確認します。脆弱性ごとに「検出日・対応方針・修正日・再診断の結果」を記録する管理表を作ると、対応漏れを防げるうえ、取引先や監査への説明資料にもなります。

同じ種類の脆弱性が繰り返し検出される場合は、コーディング規約やレビューの観点に加え、ソースコードの静的解析を開発工程に組み込みます。診断と診断の間も脆弱性情報の収集と監視を続け、常時の監視体制を自社だけで確保するのが難しい場合は、24時間365日の運用監視体制の外部委託も含めて検討します。

重大な脆弱性が見つかったときの緊急対応手順

通常のセキュリティ診断では、発見した問題を報告書にまとめ、優先順位を付けて修正を進めます。一方、実際の悪用が確認されている脆弱性や不審なアクセスが判明した場合は、通常の診断日程を待たずに対応する必要があります。まず影響を受ける製品やシステムを特定し、被害の拡大を防ぎながら侵害の有無を調べてください。

表4: 重大な脆弱性が見つかったときの初動対応

緊急度は、CVSSの数値だけでなく、次の4つの観点で判断します。

表5: 緊急度を判断する4つの観点

1つでも「緊急度が高いケース」に当てはまれば最優先で対応し、判断に迷う場合は緊急度を高く見積もります。初動を終えた後の修正の順番は、手順5の優先順位（表3）に沿って計画します。

例えば、2026年10月のPHPの脆弱性について、IPAは対象バージョンを確認して更新や移行を進め、困難な場合には暫定対策やアクセス制限、必要に応じた外部アクセス遮断などを検討するよう注意喚起しました。この脆弱性では公表前から悪用の試みがあったため、Amazonは、ログの調査を公表日ではなく、悪用が最初に確認された時点までさかのぼって行うよう呼びかけています。

緊急時の判断： 実際の侵害が疑われる場合は、証拠保全と封じ込めを並行して進め、インシデント対応担当者・専門家へ速やかに連絡してください。ログ削除や無計画な再起動は調査に影響する場合があります。不正アクセスによる個人データの漏えい等が発生した場合（そのおそれがある場合を含む）は、個人情報保護委員会への報告と本人への通知が必要で、速報は概ね3〜5日以内が目安です。

まとめ

セキュリティ診断は、システムに潜む脆弱性や設定不備を発見し、危険度の評価から修正・再診断まで行う取り組みです。実施する際は、システムの公開状況や取り扱う情報、既知の脆弱性を確認し、診断範囲と優先度を決めることが重要です。

診断にはツール診断と手動診断があり、複雑な脆弱性の発見には専門家による手動診断が有効です。カオピーズでは、診断から修正支援・再診断まで一貫して対応していますので、お気軽にご相談ください。

よくある質問（FAQ）

参考文献

1. 経済産業省・独立行政法人情報処理推進機構（IPA）.（2023）.
   「サイバーセキュリティ経営ガイドライン Ver3.0」.
   https://www.meti.go.jp/policy/netsecurity/downloadfiles/guide_v3.0.pdf
2. 経済産業省.（2026）.
   「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」.
   https://www.meti.go.jp/policy/netsecurity/scs.html
3. 警察庁.（2026）.
   「令和7年におけるサイバー空間をめぐる脅威の情勢等について」.
   https://www.npa.go.jp/publications/statistics/cybersecurity/
4. 一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）.（2026）.
   「連続不正アクセス事案の攻撃手法に関する調査」.
   https://blogs.jpcert.or.jp/ja/2026/10/web_api_attacks.html
5. 個人情報保護委員会.（2026）.
   「最近の不正アクセスによる個人データの漏えい等の傾向（参考資料2）」.
   https://www.ppc.go.jp/files/pdf/261028_sankoushiryou-2.pdf
6. Amazon Web Services.（2026）.
   「Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot」.
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
7. 独立行政法人情報処理推進機構（IPA）.（2026）.
   「脆弱性対策情報データベースJVN iPediaの登録状況［2026年第2四半期（4月〜6月）］」.
   https://www.ipa.go.jp/security/reports/vuln/jvn/ipedia2026q2.html
8. 独立行政法人情報処理推進機構（IPA）.（2022）.
   「脆弱性対策情報データベースJVN iPediaの登録状況［2022年第3四半期（7月〜9月）］」.
   https://www.ipa.go.jp/security/reports/vuln/jvn/ipedia2022q3.html
9. 独立行政法人情報処理推進機構（IPA）.（2023）.
   「プレス発表『ECサイト構築・運用セキュリティガイドライン』を公開」.
   https://www.ipa.go.jp/archive/press/2022/press20230316.html
10. 独立行政法人情報処理推進機構（IPA）.（n.d.）.
    「安全なウェブサイトの作り方」.
    https://www.ipa.go.jp/security/vuln/websecurity/about.html
11. 独立行政法人情報処理推進機構（IPA）.（n.d.）.
    「共通脆弱性評価システムCVSS v3概説」.
    https://www.ipa.go.jp/security/vuln/scap/cvssv3.html
12. 独立行政法人情報処理推進機構（IPA）.（n.d.）.
    「重要なセキュリティ情報」.
    https://www.ipa.go.jp/security/security-alert/index.html
13. 独立行政法人情報処理推進機構（IPA）.（2026）.
    「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」.
    https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html
14. 個人情報保護委員会.（2022）.
    「漏えい等報告・本人への通知の義務化について」.
    https://www.ppc.go.jp/news/kaiseihou_feature/roueitouhoukoku_gimuka/