脆弱性診断を「やったほうがよい」とは分かっていても、自社のどのシステムに、どの範囲で、どのくらいの頻度で行えばよいのかは、担当者の判断に委ねられがちです。保有するシステムすべてに毎年診断をかける予算は限られ、どこで線を引くかの拠りどころがないまま、上司や監査、取引先への説明に悩む場面も少なくありません。
脆弱性診断の基準とは、こうした判断を支える線引きのことです。具体的には、診断の要否（どのシステムを対象にするか）、範囲（どこまで診断するか）、手法（ツール診断か手動診断か）、頻度（どのくらいの間隔で行うか）、その根拠（どの公的ガイドラインがそう求めているか）、そして検出後の改修（どこまで直せば対応済みといえるか）という6つの要素で考えると、自社の方針に落とし込みやすくなります。
本記事では、公開範囲と扱う情報の重要度から診断の要否を仕分ける考え方を起点に、範囲・頻度・改修の基準を、デジタル庁やIPAなど公的ガイドラインが実際に定めている内容とあわせて整理します。自社のシステムを棚卸しし、診断対象・範囲・頻度を社内のルールとしてまとめるための材料としてご活用ください。
脆弱性診断の基準は、次の6つの要素に整理できます。各要素を、この後のセクションで順に解説します。
目次
一括ダウンロードする
自社のどのシステムを診断すべきか——要否の判断基準
ここからは、脆弱性診断の要否をどう判断するかを解説します。対象を絞り込む物差しとして実務で広く使われているのが、システムの「公開範囲」と「扱う情報の重要度」の2軸です。
ECサイトやクレジットカードを扱う事業者には後述の業界別の基準もありますが、一般的なWebサービスや社内システムを運用している場合は、まずこの2軸と、JPCERT/CCやIPAがWebサイト運営者全般に向けて示す点検の考え方を下敷きにすると、自社の要否を判断しやすくなります。
公開範囲は、インターネットに公開して不特定多数が利用するか、特定の企業や取引先だけが利用する限定公開か、社内だけで使う非公開かで分かれます。これに、個人情報・決済情報・ログイン機能といった守るべき情報を扱うかどうかを掛け合わせると、自社のシステムをどの区分に当てはめ、診断の要否と範囲をどう決めるかが整理できます。
以下は、公開範囲と扱う情報の重要度から、診断の要否と範囲の目安を整理した表です。
| システム区分 | インターネットに公開（不特定多数が利用） | 限定公開（特定企業・取引先が利用） | 社内・非公開 |
|---|---|---|---|
| 重要情報を扱う場合 | 要診断。認証後の機能も含めたWebアプリケーション診断とプラットフォーム診断の両方。ログイン・決済・会員情報入力などの重要画面は優先対象 | 要診断。取引先情報・契約データを扱う認証後の機能まで含めて診断する | 要診断。人事・会計情報やActive Directoryなど全社の認証を扱うシステムは、内部からの到達を想定して診断する |
| 重要情報を扱わない場合 | 要診断。公開サーバーのプラットフォーム診断を中心に、外部からの到達経路を対象にする | 公開範囲が狭く機密性が低ければ、重要画面を優先して範囲を絞って実施する | 機密性が低ければ優先度を下げてよい。ただし棚卸しの対象には残す |
※上記は公開範囲と扱う情報の重要度から要否を整理した一般的な目安です。実際の判断は自社のシステム構成・契約先からの要求・適用される業界基準に応じて行ってください。
社内だけで使うシステムでも、全社のアカウントを管理する認証基盤や、人事・会計などの重要情報を扱うものは診断の対象に含めるのが基本です。外部に公開していなくても、ひとたび内部に侵入されれば被害が全社に広がるためです。
ここまでの2軸は実務で広く使われる物差しですが、公的なガイドラインは別の観点からも対象の線引きを示しています。デジタル庁が政府情報システム向けに定める「脆弱性診断導入ガイドライン」は、新規に構築したシステムや機能を追加・改修したシステムを構築時診断の対象とし（＝システムを変えたタイミングで診断する、という切り口）、次のように定めています。
新規構築または機能追加等の改修を行ったシステムを対象とする。ただし、Webアプリとスマートフォンアプリに対する脆弱性診断は、変更が軽微である場合の実施を任意とする。
出典：政府情報システムにおける脆弱性診断導入ガイドライン（DS-221、2024年1月31日）｜デジタル庁
このガイドラインは政府情報システムを前提としたもので、民間企業に一律の義務として適用されるわけではありません。もっとも、政府が自らに課す基準は民間でも診断方針の拠りどころにしやすく、自社の要否を決める際の参考モデルとして役立ちます。
どこまで診断するか——診断範囲の基準
診断すると決めたシステムについて、次に決めるのが範囲です。全機能を対象にするのか重要な画面に絞るのか、そしてWebアプリケーション診断とプラットフォーム診断のどちらを当てるのかを、ここで整理します。
Webアプリケーション診断とプラットフォーム診断の当て分け
脆弱性診断は、診断する層によって大きく2種類に分かれます。Webアプリケーション診断は、ログインフォームや入力画面など、アプリケーションが受け取るデータの処理に潜む欠陥を調べます。SQLインジェクションやクロスサイトスクリプティングのように、入力値の扱いが原因で起きる脆弱性が主な対象です。
一方のプラットフォーム診断は、サーバーのOS・ミドルウェア・ネットワーク機器といった、アプリケーションを動かす土台を調べます。古いバージョンの放置や設定の不備が主な対象です。自社でWebアプリケーションを開発・公開しているなら両方を、サーバーや機器を外部に公開しているだけならプラットフォーム診断を、というように、守る対象に応じて当て分けます。
全機能を診断するか、重要画面に絞るか
範囲を広げるほど見落としは減りますが、費用と期間はかさみます。そこで、被害が大きくなりやすい箇所から優先するのが現実的です。認証・決済・個人情報の入力といった、攻撃された場合の影響が大きい機能を優先対象にします。
公的な基準も、最低限押さえるべき範囲を具体的に示しています。IPA（情報処理推進機構）の「ECサイト構築・運用セキュリティガイドライン」は、公開前のWebアプリケーション診断について、次の画面を最低範囲として挙げています。
Webアプリケーション診断の実施範囲は、最低でも以下の画面について脆弱性診断を実施してください。ログイン画面、サイト利用者情報登録/変更画面、商品検索画面、注文・決済画面等
出典：ECサイト構築・運用セキュリティガイドライン（要件3）｜情報処理推進機構（IPA）
ECサイトに限らず、ログインや決済、個人情報の入力を扱う画面は、自社のシステムでも優先度の高い診断対象になります。
診断項目の最低ラインはOWASP Top 10（2025版）、水準はASVSのレベルで測る
Webアプリケーション診断で「どの脆弱性まで調べれば十分か」を測る物差しが、OWASP（オープンな非営利団体による標準化コミュニティ）が公開する基準です。代表的な脆弱性カテゴリをまとめた「OWASP Top 10」は、診断項目の最低ラインとして広く参照されます。2025年版は次の10カテゴリで構成されています。
- A01:2025 アクセス制御の不備（Broken Access Control）
- A02:2025 セキュリティ設定ミス（Security Misconfiguration）
- A03:2025 ソフトウェアサプライチェーンの不備（Software Supply Chain Failures）
- A04:2025 暗号化の失敗（Cryptographic Failures）
- A05:2025 インジェクション（Injection）
- A06:2025 安全でない設計（Insecure Design）
- A07:2025 認証の失敗（Authentication Failures）
- A08:2025 ソフトウェア・データの完全性の不備（Software or Data Integrity Failures）
- A09:2025 セキュリティログと警告の不備（Security Logging & Alerting Failures）
- A10:2025 例外的状態の取り扱いの不備（Mishandling of Exceptional Conditions）
2025年版は、2021年版からの変更が大きい点に注意が必要です。ソフトウェアサプライチェーンの不備（A03）が新設され、2021年版で独立項目だったサーバーサイドリクエストフォージェリ（SSRF）はアクセス制御の不備に統合されました。診断を委託する際は、最新版を踏まえた項目で実施されるかを確認するとよいでしょう。
診断の網羅度や厳しさの水準を測るには、同じくOWASPの「ASVS（アプリケーションセキュリティ検証標準）」が使われます。ASVSはレベル1からレベル3までの段階を持ち、一般的な業務アプリケーションはレベル2が目標の目安とされます。現行は2025年に大きく改訂された5.0.0で、要件数や章構成が刷新されています。
出典・参考資料（2件）
ツール診断と手動診断の使い分け——手法の基準
要否と範囲を決めたら、どの手法で診断するかを選びます。脆弱性診断には、スキャナーで機械的に調べるツール診断と、専門家が手を動かして調べる手動診断があり、それぞれ得意な領域が異なります。
ツール診断は、既知の脆弱性を網羅的に、短時間かつ低コストで調べられます。日常的な点検や、公開範囲の広いシステムを広く浅く確認する用途に向きます。一方で、画面の流れや権限設計に踏み込んだ業務ロジックの欠陥、複数の脆弱性が組み合わさって初めて問題になるケースは、ツールだけでは取りこぼしやすい領域です。
手動診断は、こうした業務ロジックや組み合わせの問題を専門家が確かめられる点が強みです。費用と期間はかかりますが、決済や認証など被害が大きい重要システムでは手動診断を組み合わせる価値があります。日常はツールで広く網羅し、重要な局面や重要なシステムには手動を足す、という使い分けが基本の考え方です。
ツールが取りこぼす領域を人の目で補うという考え方は、診断の実務でも重視されています。株式会社TECHFUNDの生田氏は、ツール診断と手動診断を組み合わせる理由を次のように説明します。
ツールを使えば大量の項目を短期間で効率的に診断できますが、ビジネスロジックに関わる部分や、複数の脆弱性の組み合わせで一つの問題が起きるようなケースは、単一のツールでは取りこぼしやすい領域です。そこは人間の目で判断する必要が必ずありますので、両方を組み合わせて診断しています。
どのくらいの頻度で診断するか——頻度・タイミングの基準
ここからは、診断をどのくらいの間隔で行うかを整理します。脆弱性は日々新しく見つかるため、一度診断して終わりにはできません。頻度とタイミングは、定期・節目・業界要件の3つの観点で考えると整理しやすくなります。
| 診断のタイミング | 定期診断 | リリース前・大改修時 | 改修後の再診断 | 業界要件（カード会員データを扱う場合） |
|---|---|---|---|---|
| 目安の頻度 | 年1回以上を基本。公開範囲が広い・変更が多いシステムは四半期〜月1回も | その都度 | 脆弱性を直すごとに1回以上 | 四半期ごとのスキャン |
| 主な対象 | 公開中のWebアプリケーション・サーバー | 新規公開・機能追加・改修を行ったシステム | 指摘を受けて改修したシステム | クレジットカード情報を保存・処理・伝送する環境 |
| 主な根拠 | JPCERT/CC・IPA（Webアプリ診断は年1回程度） | IPA ECサイトGL 要件2・JPCERT/CC（変更時） | デジタル庁 DS-221（再診断は必須） | PCI DSS 要件11.3 |
※頻度はシステムの公開範囲・変更の多さ・適用される業界基準によって変わります。各ガイドラインが求める具体的な頻度は次節で整理します。
定期診断の頻度は「年1回以上」が一般的な目安ですが、公開範囲が広く変更の多いシステムほど間隔を短くする必要があります。攻撃側も自動化が進み、新しい脆弱性が悪用されるまでの時間が短くなっているため、従来の年1回では間に合わない場面が増えています。
こうした頻度の見直しは、診断を手がける現場でも実感として語られています。CoWorker株式会社の一ノ瀬氏は、攻撃側の変化が診断の間隔に与える影響を次のように述べています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
クレジットカード情報を扱う事業者には、業界基準のPCI DSSが四半期ごとの脆弱性スキャンを求めます。これはカード会員データを保存・処理・伝送する環境に限って適用される要件で、すべてのシステムに一律に課されるものではありません。それぞれの頻度が、どの公的ガイドラインの、どの定めに基づくのかは、次節の対応表で整理します。
基準の根拠となる公的ガイドライン一覧
ここまでの要否・範囲・頻度は、公的なガイドラインや基準に根拠があります。上司・監査・取引先に説明する際に、どのガイドラインの何を根拠にしているかを示せるよう、主な基準が定めている内容を一覧に整理します。
| ガイドライン・基準 | デジタル庁 脆弱性診断導入ガイドライン（DS-221） | IPA ECサイト構築・運用セキュリティガイドライン | JPCERT/CC・IPA 共同注意喚起 | PCI DSS | OWASP Top 10:2025／ASVS 5.0.0 |
|---|---|---|---|---|---|
| 主な対象 | 政府情報システム（民間は参照モデル） | ECサイト運営事業者 | Webサイト運営者全般 | カード会員データを扱う事業者 | Webアプリケーション全般 |
| 要否・範囲について定めること | 構築時はアタックサーフェス全て、外部公開IPアドレス・インタフェースは全て必須。Webアプリ・スマホアプリは変更が軽微なら任意 | 公開前の脆弱性診断が必須（要件3）。Webアプリの最低範囲はログイン・利用者情報登録／変更・商品検索・注文／決済 | 利用製品の確認・ファイル確認・Webアプリ診断の3点検を推奨 | カード会員データ環境の脆弱性スキャン（要件11.3） | 診断項目の最低ライン（Top 10）と、診断水準の測り方（ASVSのレベル） |
| 頻度について定めること | 定期診断の頻度基準は設けない。改修後の再診断は報告書納品から最低1カ月以内に1回以上（必須） | 四半期に1回のプラットフォーム診断、改修の都度のWebアプリ診断（要件2） | 利用製品のバージョン確認は数週間〜1カ月、ファイル確認は1週間、Webアプリ診断は年1回＋変更時 | 四半期ごと | —— |
頻度についてよくある誤解が、「デジタル庁のガイドラインが年1回と定めている」というものです。実際には、デジタル庁のガイドラインは定期診断の頻度について「本書では選定の基準を設けないものとする」（脆弱性診断導入ガイドライン DS-221 3.1）とし、各機関の自己点検や監査計画に委ねています。年1回などの具体的な頻度は、IPAやJPCERT/CC、PCI DSSの側に定めがあります。
一方で、デジタル庁のガイドラインは改修後の再診断については明確に定めています。
検出された脆弱性の改修後、改修した脆弱性に対する再診断を行うこと。再診断は報告書の納品から最低1カ月以内の期間、1回以上の実施ができるようにすること（必須）
出典：政府情報システムにおける脆弱性診断導入ガイドライン（DS-221、2024年1月31日）｜デジタル庁
IPAのECサイト向けガイドラインは、公開後の定期的な診断の頻度を種別ごとに示しています。
新機能の開発・追加やシステム改修等のカスタマイズを行ったときには、その都度Webアプリケーション診断を実施することが重要です。（中略）上記のような新機能の開発・追加やシステム改修等のカスタマイズ等を行っていない場合でも、OSやミドルウェア等の脆弱性は継続的に発見されているため、四半期に1回の頻度でプラットフォーム診断を実施することが重要です。
出典：ECサイト構築・運用セキュリティガイドライン（要件2）｜情報処理推進機構（IPA）
JPCERT/CC（JPCERTコーディネーションセンター）とIPAの共同注意喚起は、点検項目ごとに頻度の目安を示しています。
出典：ウェブサイトへのサイバー攻撃に備えた定期的な点検を｜JPCERT/CC・IPA
- 利用製品（プラグイン等追加の拡張機能も含む）の最新バージョンの確認／頻度：数週間〜1ヶ月に1回程度
- ウェブサイト上のファイルの確認（改ざん等されていないか／ファイル名・サイズ・更新日時・ハッシュ値のリストの取得と比較）／頻度：1週間に1回程度
- ウェブアプリケーションのセキュリティ診断／頻度：1年に1回程度、および機能追加等の変更が行われた時
クレジットカード情報を扱う事業者が対象のPCI DSSは、カード会員データ環境について四半期ごとの脆弱性スキャンを求めています。要件番号や逐条の最新内容は、PCI Security Standards Councilの公式文書で確認してください。
このうちPCI DSSが四半期ごとに求める外部スキャンは、ASV（認定スキャンベンダー）による要件11.3のスキャンを指します。カード会員データを扱う環境で何を・どの頻度で実施すべきかは、以下の記事で解説しています。
ガイドラインを参照する際は、版の新しさにも注意が必要です。デジタル庁のガイドラインは2024年1月31日の改定版が現行で、Web API診断の記載などが加わっています。OWASP Top 10も2025年版が最新です。古い版を前提にした解説記事も残っているため、根拠として引く際は現行版を確認しましょう。
検出後どこまで直せば「対応済み」か——CVSSによる合否・改修の基準
診断を実施すると、多くの場合いくつもの脆弱性が見つかります。すべてを一度に直しきるのは難しいため、どれから優先し、どこまで直せば「対応した」といえるのかの物差しが必要です。ここで使われるのが、脆弱性の深刻度を数値で示すCVSS（共通脆弱性評価システム）です。
CVSSは脆弱性の技術的な深刻度を0.0〜10.0のスコアで表し、スコア帯ごとに5段階の深刻度に分類します。デジタル庁のガイドラインも、この区分を採用しています。
出典：政府情報システムにおける脆弱性診断導入ガイドライン（DS-221、表2-4）｜デジタル庁
- CVSSスコア 9.0〜10.0 ＝ 緊急（Critical）
- 7.0〜8.9 ＝ 重要（High）
- 4.0〜6.9 ＝ 警告（Medium）
- 0.1〜3.9 ＝ 注意（Low）
- 0.0 ＝ なし（None）
ただし、スコアだけで優先順位を決めるのは適切ではありません。緊急・重要に分類される脆弱性から優先し、自社にとっての影響の大きさを加味して順番を決めるのが現実的です。同じガイドラインも、次のように述べています。
基本評価基準はあくまでもその脆弱性の技術的特性を示すものであり、それ単体で対応の優先度を決めるべきものではない。基本評価基準を参考に自身のシステム環境において想定される具体的なリスクに基づいて対応の優先度を定めることが望ましい。
出典：政府情報システムにおける脆弱性診断導入ガイドライン（DS-221、2024年1月31日）｜デジタル庁
一方で、「緊急は何日以内に直す」といった数値の改修期限は、公的ガイドラインには定められていません。デジタル庁のガイドラインも、対応基準は「脆弱性の深刻度に基づいて策定されることが望ましい」とするにとどめ、具体的な日数は各機関に委ねています。
ただし、すでに悪用が観測されている脆弱性については、対応基準にかかわらず迅速に対応するよう求めています。自社で期限を定める場合は、この考え方を踏まえて社内ルールとして設定することになります。
公的な固定ラインがない前提で、実務では深刻度ごとの対応方針をあらかじめ決めておくのが一般的です。たとえば、緊急・重要にあたる脆弱性は必ず改修し、警告にあたるものは期限を決めて計画的に対応、注意にとどまるものは自社のリスク許容度に応じて受容も選択肢に入れる、といった方針です。こうした線引きを社内ルールとして明文化しておくと、検出のたびに判断がぶれません。
IPAのECサイト向けガイドラインは危険度を「高・中・低」の3段階で表しており、CVSSの5段階とは別のスケールです。複数の基準を併用する際は、どの物差しで評価しているかを取り違えないよう注意してください。
自社の脆弱性診断基準（社内ルール）の作り方
ここまでの要否・範囲・頻度・改修の基準を自社に当てはめ、社内のルールとして起案する手順を整理します。基準を一度文書にまとめておくと、担当者ごとの判断のばらつきを防ぎ、監査や取引先への説明にもそのまま使えます。
まず、自社が保有・運用するシステムをすべて棚卸しします。次に、各システムについて公開範囲と扱う情報の重要度から要否を判断し、対象にするものは範囲（全機能か重要画面か、Webアプリケーション診断かプラットフォーム診断か）と頻度を記入します。最後に、検出した脆弱性をどの深刻度まで、いつまでに改修するかの方針を添えて、社内の方針として起案します。
棚卸しの様式は、次のような項目を1システム1行で埋めていく形が扱いやすいでしょう。
| 棚卸し項目 | システム名・用途 | 公開範囲 | 扱う情報 | 診断の要否と範囲 | 頻度 | 改修の方針 |
|---|---|---|---|---|---|---|
| 記入する内容 | 対象システムの名称と、何に使っているか | インターネット公開／限定公開／社内・非公開のいずれか | 個人情報・決済情報・ログイン機能などの有無 | 診断する／しない／重要画面のみ、および診断種別（Webアプリ・プラットフォーム） | 定期の間隔、リリース・改修時の都度実施、業界要件の有無 | 優先する深刻度と、改修・再診断の進め方 |
この棚卸しができれば、どのシステムをどこまで・どのくらいの頻度で診断するかが一覧で見える状態になります。そのうえで、自社だけで対応しきれない範囲は、外部の診断サービスやツールへの委託を検討する段階に進みます。
棚卸しで診断対象と範囲が固まったら、次は各システムの診断を実際にどう進めるかを決める段階です。自社で診断する場合と業者に依頼する場合それぞれの手順・費用の目安・選び分け方は、以下の記事で解説しています。
一括ダウンロードする
決めた基準に合う診断サービス・ツールの選び方と依頼先
自社の診断基準が固まったら、その基準を満たせる診断サービスやツールを選びます。ここでは、委託先を選ぶ際に確認したい観点と、代表的なサービスを紹介します。
選ぶ際の観点は、大きく3つあります。1つ目は、信頼できる実施者かどうかです。デジタル庁のガイドラインは診断の実施者について、経済産業省の「情報セキュリティサービスに関する審査登録機関基準」における脆弱性診断サービスの認定を取得したベンダーであることを必須の要件としています。
出典・参考資料（2件）
民間でも、IPAが公開する「情報セキュリティサービス基準適合サービスリスト」への掲載の有無が、同じ基準に準拠しているかを確認する手がかりになります。
2つ目は、診断手法の精度と項目の網羅性です。ツール診断と手動診断を組み合わせているか、OWASP Top 10などの基準を満たす項目で診断するかを確認します。3つ目は、サポート体制です。検出後の改修支援や、再診断が無償か有償か、質問対応の窓口と期間がどうなっているかは、診断を回し続けるうえで差が出る部分です。
以下は、自社の診断基準に合わせて検討できる脆弱性診断サービスの比較表です。
| サービス名 | Aikido Security | Hi AUDIT | CoWorker 脆弱性診断サービス |
|---|---|---|---|
| 提供形態 | SaaS（継続検査） | 委託診断＋月額自動診断 | 委託診断 （定期診断も対応） |
| 診断手法 | ツール（自動スキャン） | ハイブリッド （ツール＋専門家） | ハイブリッド （AI＋専門家） |
| Webアプリ・API診断 | ● | ● | ● |
| ソースコード診断 | ● | △スマートコントラクト監査が中心 | ● |
| クラウド設定診断 | ● | × | × |
| OS・ミドルウェア診断 | ● | × | × |
| IoT・機器・ハードウェア診断 | × | ● | × |
| 料金の目安 | 月額5万円台〜 （AndGo窓口・年間契約／10名の参考価格） | 要お問い合わせ （成果報酬型） | 15万円〜 （ソースコード診断。動的診断30万円〜） |
| 改修・診断後サポート | オートフィックス （修正案を自動でプルリク作成） | 改修完了まで並走 （修正相談・再確認を無料） | 再診断に対応 （プランにより1〜2回） |
| 詳細情報 | 公式資料を見る | 公式資料を見る | 公式資料を見る |
※料金・対応範囲は各社の公式情報・提供元への取材にもとづく2026年11月時点の参考情報です。最新の内容は各社の公式情報でご確認ください。
1. Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコードの診断・クラウドの設定の検査・依存するミドルウェアの脆弱性といった、開発と運用の現場で起きやすい論点を1つの画面でまとめて扱えるオールインワンの診断ツールです。開発会社や開発部門向けに、個別のツールを足し合わせずに済む形を目指しています。
見るのは主に3つで、攻撃されやすいコードの書き方、AWSなどクラウド側の設定ミス、サーバーOSやWordPressなど依存ミドルウェアに起因する脆弱性です。検出した脆弱性について修正案のドラフトを作ってプルリクエストまで出せるオートフィックス機能があり、「見つけて終わり」にしない運用を取りやすいのが特徴です。
料金はスポットの1回いくらではなく、利用するエンジニアのスロット数で規模が決まる月額のサブスクリプション型で、開発の中で継続的に検査を回す使い方に向きます。日本国内では株式会社AndGoが窓口となり、日本語での導入・運用の支援を行っています。
2. Hi AUDIT（株式会社TECHFUND）
株式会社TECHFUNDが「Hi AUDIT」のブランドで提供するセキュリティ診断サービスです。2018年ごろから取り組んできたWeb3のスマートコントラクト監査で培った知見を土台に、Webサービスやアプリケーションの診断へ対象を広げてきました。IoT機器や医療機器といったハードウェアの診断にも対応している点が特徴です。
診断は、ツールによる自動診断と専門家による手動診断を組み合わせたハイブリッド方式です。重視しているのは、脆弱性を見つけて報告して終わりにせず、「この問題を悪用されると何が起きるか」という攻撃シナリオと事業への影響まで整理し、改修まで寄り添う進め方です。Web・IoT・医療機器など、業界ごとに異なるセキュリティ要件に合わせて診断を設計できることを強みとしています。
3. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker株式会社が提供する、WebアプリケーションやAPIを対象とした脆弱性診断サービスです。ソースコードを読み取る静的診断、実際にアクセスして調べる動的診断、仮想的な攻撃でどこまで侵入できるかを試すペネトレーションテストの3つを用意しています。
特徴は、自社開発のAI診断システム「Red Agent」を社内の専門家が使って診断する点にあります。AIで膨大な検査パターンを高速に処理したうえで、最終的に人の目で確認するフローを取ります。
料金は、静的診断が15万円から、動的診断がAPIのエンドポイント数に応じて30万円から、Webのペネトレーションテストが60万円から、ネットワークのペネトレーションテストが100万円からとなっています。これらは2026年10月時点で提供元への取材により確認した診断種別ごとの金額で、公式サイトには通常料金として50万円からと記載されています。
診断を安く早く回せる仕組みを活かし、年1回だった診断を四半期や月次で継続する使い方も想定しています。
ここで紹介したサービスを含め、より多くの脆弱性診断サービスを診断方法・費用相場・選び方で比較検討したい場合は、以下の記事で詳しく解説しています。導入を検討される方は、あわせてご覧ください。
まとめ
脆弱性診断の基準は、要否・範囲・手法・頻度・根拠・改修の6つの要素で考えると、自社の方針に落とし込めます。要否は公開範囲と扱う情報の重要度で仕分け、範囲は重要な機能や画面から優先し、手法はツール診断と手動診断を使い分け、頻度は定期・改修時・業界要件の観点で設定します。
それぞれの根拠は、デジタル庁・IPA・JPCERT/CC・PCI DSSといった公的ガイドラインに当たることで、説明できる形になります。
まずは自社のシステムを棚卸しし、基準を当てはめて診断対象・範囲・頻度を社内ルールとして整理してみてください。そのうえで、自社だけで対応しきれない範囲は、基準を満たせる診断サービスやツールへの委託を検討するとよいでしょう。
一括ダウンロードする
よくある質問（FAQ）
Q. 脆弱性診断の基準とは何ですか？
A. 脆弱性診断の基準とは、診断の要否（どのシステムを対象にするか）・範囲（どこまで診断するか）・手法（ツール診断か手動診断か）・頻度（どのくらいの間隔で行うか）・根拠（どの公的ガイドラインに基づくか）・改修（どこまで直せば対応済みとするか）の6つの要素で引く線引きのことです。
これらを社内のルールとして一度文書にまとめておくと、担当者ごとの判断のばらつきを防げるうえ、上司・監査・取引先への説明にもそのまま使えます。
Q. 自社のどのシステムに脆弱性診断が必要かは、どう判断すればよいですか？
A. 脆弱性診断の要否は、システムの「公開範囲」（インターネット公開／限定公開／社内・非公開）と「扱う情報の重要度」（個人情報・決済情報・ログイン機能の有無）の2軸で仕分けるのが実務の基本です。
インターネットに公開して重要情報を扱うシステムは優先的に要診断とし、社内だけで使うシステムでも、全社の認証基盤や人事・会計などの重要情報を扱うものは対象に含めます。外部に公開していなくても、ひとたび内部に侵入されれば被害が全社に広がるためです。
Q. 脆弱性診断は、システムのどこまでを対象にすればよいですか？
A. 脆弱性診断の範囲は、認証・決済・個人情報の入力など、攻撃されたときの影響が大きい機能・画面を優先するのが現実的です。
範囲を広げるほど見落としは減りますが、費用と期間はかさみます。IPAのECサイト向けガイドラインは、ログイン画面・利用者情報の登録／変更画面・商品検索画面・注文／決済画面を最低範囲として挙げています。
自社でWebアプリケーションを公開しているならWebアプリケーション診断とプラットフォーム診断の両方を、サーバーや機器を公開しているだけならプラットフォーム診断を当てる、というように守る対象に応じて当て分けます。
Q. 脆弱性診断は年1回で十分ですか？
A. 脆弱性診断の頻度は、システムの公開範囲・変更の多さ・適用される業界基準によって変わり、「年1回で十分」と一律には言えません。公開範囲が広く変更の多いシステムは四半期〜月1回が必要になり、クレジットカード情報を扱う環境にはPCI DSSが四半期ごとのスキャンを求めます。
なお「デジタル庁のガイドラインが年1回と定めている」という理解は誤りです。デジタル庁の脆弱性診断導入ガイドラインは定期診断の頻度基準を設けず、各機関の自己点検や監査計画に委ねています。年1回などの具体的な頻度は、IPAやJPCERT/CC、PCI DSSの側に定めがあります。
Q. 脆弱性診断の基準の根拠になる公的ガイドラインには何がありますか？
A. 代表的なのは、デジタル庁「脆弱性診断導入ガイドライン（DS-221）」、IPA「ECサイト構築・運用セキュリティガイドライン」、JPCERT/CCとIPAの共同注意喚起、PCI DSS、OWASP Top 10／ASVSです。
デジタル庁のガイドラインは政府情報システム向けですが民間の参照モデルになり、IPAはECサイトの範囲と頻度、JPCERT/CCは点検項目別の頻度、PCI DSSはカード会員データ環境の四半期スキャン、OWASPは診断項目の最低ラインと水準の測り方を示します。上司・監査・取引先に根拠として示す際は、解説記事の孫引きではなく各ガイドラインの原文に当たると確実です。
Q. 検出した脆弱性は、どこまで直せば「対応済み」といえますか？
A. 脆弱性の改修は、CVSS（共通脆弱性評価システム）で緊急・重要に分類されるものから優先し、自社環境で想定されるリスクの大きさを加味して順番を決めるのが基本です。
CVSSは深刻度を0.0〜10.0のスコアで表しますが、スコアだけで優先度を決めるべきではなく、自社のシステム環境で想定されるリスクに基づいて判断することが望ましいとされています。「緊急は何日以内に直す」といった数値の改修期限は公的ガイドラインには定められておらず、各社が社内ルールとして設定します。ただし、すでに悪用が観測されている脆弱性は、基準にかかわらず迅速に対応する必要があります。
Q. 脆弱性診断のツール診断と手動診断は何が違い、どう使い分けますか？
A. ツール診断は既知の脆弱性を短時間・低コストで網羅的に調べる手法、手動診断は業務ロジックの欠陥や複数の脆弱性の組み合わせを専門家が確かめる手法です。
画面の流れや権限設計に踏み込んだ問題はツールだけでは取りこぼしやすいため、日常の点検や公開範囲の広いシステムの確認はツールで広く網羅し、決済や認証など被害が大きい重要システムには手動診断を組み合わせる、という使い分けが基本の考え方です。
Q. 脆弱性診断の費用はどのくらいかかりますか？
A. 脆弱性診断の費用は、診断の手法・範囲・対象システムの規模によって変わり、月額数万円台の継続検査サービスから、手動を含む委託診断の数十万円以上まで幅があります。
目安として、ツールによる継続検査型のSaaSは月額数万円台から、委託型のソースコード診断は十数万円から、動的診断やペネトレーションテストは数十万円からとなります。範囲を重要画面に絞る、日常はツール・重要局面は手動と使い分けるなど、優先順位を付けることで費用を抑えられます（各サービスの最新の料金は公式情報でご確認ください）。
Q. 脆弱性診断の基準は社内でどう作ればよいですか？
A. 脆弱性診断の社内基準は、まず自社の全システムを棚卸しし、各システムについて公開範囲と扱う情報から要否・範囲・頻度・改修方針を1システム1行で記入して、社内の方針として起案するのが基本の流れです。
システム名・用途、公開範囲、扱う情報、診断の要否と範囲、頻度、改修の方針を項目として並べると、どのシステムをどこまで・どのくらいの頻度で診断するかが一覧で見える状態になります。この棚卸しができれば、自社だけで対応しきれない範囲を外部の診断サービスやツールへ委託する判断にも進みやすくなります。
脆弱性・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、Webアプリケーション・API・ソースコード診断から、サーバーやクラウドの継続的な検査、IoT機器まで対応する脆弱性診断サービスの最新資料を無料で一括請求できます。自社の診断基準に合うサービスを、診断対象や手法で見比べられます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
