年1回の外部脆弱性診断で数百万円の見積もりが常態化し、しかもスプリント制でリリース頻度が上がった開発現場に年1点検が追いつかない——「毎回外注していたら破綻する」「リリースの度に脆弱性が混ざり込む」と感じ、内製化と自動化を検討し始めた担当者向けの記事です。
診断項目のレベルで「これはツールで置き換えられる」「これは要人判断」「これは原理的に手動診断が要る」を切り分けます。そのうえで、内製に向く条件・PCI DSS等でツール診断だけでは要件を満たせないケース・年間コストの3パターン試算・CI/CDへの組込み方・社内運用の実像・失敗パターン・ハイブリッド運用の標準形までを、実務で使える粒度でまとめます。
読み終えたときに、社内提案書に転記できる要点と、候補ツールの資料請求に踏み込める材料が揃うことを目標にしています。
先に候補ツールの資料を集めてから読み進めたい方は、下記から脆弱性・セキュリティ診断サービスの資料を一括で入手できます。
目次
【診断項目 × 内製可否マトリクス】ツールで置き換え可能な項目・手動診断を残すべき項目
最初に、脆弱性診断の代表的な項目を「ツール（SAST／DAST／SCA）で検出できる」「一部検出できるが最終判断は人が要る」「原理的にツールでは検出できず手動診断が要る」の3列に振り分けた対応表を示します。OWASP Top 10（現時点の最新は2025版、日本語訳が揃っているのは2021版）とIPA『脆弱性診断内製化ガイド』の指摘事項をもとに、代表的な診断項目をカバーしています。
行の判定に迷うものは中央の「要人判断」に置き、その理由を最終列に記しました。
表中の略語は次のとおりです——SAST（静的アプリケーションセキュリティテスト、ソースコード解析）／DAST（動的アプリケーションセキュリティテスト、稼働中アプリへの疑似攻撃）／SCA（ソフトウェアコンポジション解析、依存ライブラリの既知CVE検出）／CSPM（クラウド設定管理、クラウド環境の設定不備検出）。
加えて、Secretsスキャナ（コード中に埋め込まれたシークレット情報の検出）／IAST（対話型アプリケーションセキュリティテスト、実行時計装）／IDOR（Insecure Direct Object References、他ユーザー資産への直接参照が通ってしまう仕様不備）。以降は略語のみで表記します。
| 診断項目 | 自動ツールで検出可（SAST／DAST／SCA／CSPM／Secretsスキャナ／プラットフォーム診断ツール等） | 一部可・要人判断（IAST含む） | 原理的に不可（要手動診断） | 推奨診断手法 |
|---|---|---|---|---|
| SQLインジェクション | ◯（DAST／SAST） | — | — | DASTで自動検出。SASTで開発時に前倒し検出 |
| クロスサイトスクリプティング（XSS） | ◯（DAST／SAST） | — | — | DASTで反射型・格納型を自動検出 |
| CSRF（クロスサイトリクエストフォージェリ） | ◯（DAST） | — | — | トークン欠落等のパターンはDASTで検出 |
| 依存ライブラリの既知CVE | ◯（SCA） | — | — | SCAで自動検出。CI組込で継続監視 |
| 認証・セッション管理の不備（トークン再利用等） | △ | ◯（DAST＋IASTで部分検出） | — | DAST＋IASTで一部検出、設計欠陥は人の目で追加確認 |
| アクセス制御・認可設計の欠陥（水平／垂直権限昇格） | — | △（IASTで実行時の権限逸脱を部分検出） | ◯ | ロールと業務仕様の理解が要るため手動診断が中核 |
| ビジネスロジック欠陥（割引計算悪用・状態遷移の不整合） | — | △（IASTでテスト自動化と組み合わせ部分検出） | ◯ | 仕様理解が前提。ツールでは原理的に不可 |
| 他ユーザーの契約情報・購入履歴の閲覧（IDOR等の仕様不備） | — | △（IASTでデータフロー可視化により部分検出） | ◯ | 「本来見えてはいけない」の判断は人が要る |
| ポートスキャン／SSL・TLS設定 | ◯（プラットフォーム診断ツール） | — | — | ツールで自動検出。四半期以上の頻度で継続 |
| クラウド設定不備（S3公開・IAM過剰権限等） | ◯（CSPM） | — | — | CSPMで継続監視 |
| ソースコード内のシークレット（APIキー等の埋め込み） | ◯（SAST／Secretsスキャナ） | — | — | コミット時のフックとCIで二重に検出 |
| 連鎖攻撃・ペネトレーション（攻撃者視点の到達） | — | — | ◯ | 攻撃者の思考トレースが要る。外注一択 |
| 認証・セッション管理／権限昇格の複合パターン | — | △（IASTが実行時計装で部分検出） | ◯ | 手動診断を中核に、IASTで実行時のデータフロー・権限遷移を補完 |
この表からわかるのは、次の2点です。SQLインジェクション・XSS・依存ライブラリCVE・クラウド設定不備・シークレット埋め込みといった「パターン化された既知の脆弱性」は、ツールでの内製化が現実的です。一方、認可設計の欠陥・ビジネスロジックの穴・他人の契約情報の閲覧のような「仕様理解を前提に『本来見えてはいけない』を判断する脆弱性」は、原理的にツールでは検出できません。
IPAガイドも「ビジネスロジックに深く依存する脆弱性（状態遷移の不整合など）や複雑な認証・権限管理の問題については自動検出が難しく、そういった脆弱性の発見には、ビジネスロジックの理解にもとづく手動診断が不可欠となる」と明示しています。
Web アプリケーション診断ツールは、HTTP リクエストやレスポンスを自動で解析し、SQL インジェクションやクロスサイト・スクリプティング（XSS）などの典型的な脆弱性を検知するものである。（中略）ただし、ビジネスロジックに深く依存する脆弱性（状態遷移の不整合など）や複雑な認証・権限管理の問題については自動検出が難しく、そういった脆弱性の発見には、ビジネスロジックの理解にもとづく手動診断が不可欠となる。
出典：脆弱性診断内製化ガイド 2.5.1 ツール診断（2025-08-29改訂）｜IPA
出典・参考資料（1件）
自動診断ツールの限界と誤検知・見逃しの実情
マトリクスで「原理的に不可」に振り分けた項目は、なぜツールでは検出できないのか。そして、ツールを入れれば見つかると期待した検出項目も、実際には誤検知（false positive）と見逃し（false negative）が付いて回ります。ここでは、ツールで内製化を進めた組織が現実にぶつかる限界を、ベンダー自身の言及と現場ブログの一次情報で押さえます。
ツールが原理的に不得意な領域——ビジネスロジック・認可バイパス・仕様不備
NRIセキュアは、自社のコンサル経験から「ツールでは検出できない仕様不備」の具体例を、逐語で挙げています。
アプリケーションの仕様の不備（例：他者の契約情報・購入履歴の閲覧、認証の仕組みを悪用した不正な商品購入など）に起因する脆弱性の検出はできません
出典：脆弱性診断を内製化する方法｜DevSecOps実現の最初の一歩（2024-04-03）｜NRIセキュア
ECサイトで「他ユーザーのマイページに遷移するURLを打ち替えると、他人の購入履歴が見えてしまう」といった穴は、HTTPリクエスト単位で見れば「200 OKで正常応答」に見えるため、DASTツールが自動で異常検出することはできません。「このパスからは本来自分の情報しか返してはいけない」という業務仕様は、人が理解して初めて判定できるからです。
認可バイパス・水平権限昇格（同じロールの他ユーザーの情報にアクセス）・垂直権限昇格（一般ユーザーが管理者機能にアクセス）も同型で、ツール診断だけでは原理的に発見できません。ペネトレーションテスト——攻撃者視点で複数の脆弱性を連鎖させて到達可能性を検証する診断——も、シナリオ設計に人の思考が要るため、外注として残すべき領域です。
サイボウズのPSIRT（Product Security Incident Response Team、自社プロダクトのセキュリティ対応を担う専任チーム、田口氏）は、実運用の中で「ツール検出可」と「手動対応が要る」の分業を、以下のように整理しています。
【自動化対象】パラメータに対する入力チェックやHTTPヘッダの確認など、パターン化されツールで効率的に検出可能なもの
出典：自動脆弱性診断ツールの導入と効率化の取り組み（2025-05-30）｜Cybozu Inside Out
【手動対応】アクセス制御やAI関連機能、製品特有の機能、特定の条件下でのみ発生する脆弱性など、仕様理解やコンテキストに基づく判断が求められるもの
誤検知（false positive）・見逃し（false negative）の実情と、運用が崩れる典型パターン
ツールを入れても、検出結果がそのまま「対応が必要な脆弱性のリスト」になるわけではありません。前掲IPA『脆弱性診断内製化ガイド』2.5.1節の「課題」でも、誤検知・未検出の発生と、最終的な結果の妥当性評価を人が行う必要があることが明記されています。
実運用では、サイボウズが自社ブログで「1件ずつ内容を確認し、それが有効な指摘か、対応が必要かを判断」「判断基準を明文化」「手動で再現確認を行い、誤検知でないことを確認した上で開発チームに報告」と、トリアージのフローそのものを開示しています。ツールを回した先の「1件ずつ精査する担当」を用意しないと、アラートが積み上がるだけで開発チームに届かなくなり、やがて誰も開かない検出結果になります。
誤検知だらけで運用が崩れるパターンは、後述の「失敗パターン(2) アラート疲れ」で扱います。
内製化に向く企業／外注を残すべき企業の判定チャート
「うちの会社は内製化に向いているのか、まだ早いのか」を判定するために、実務で使える5つの問いを用意しました。IPAガイド第3章「外部発注と内製の比較」およびdcrossに掲載されたIPA中核人材育成プログラム修了生（森山響氏／STNet）の「内製化が有効な3ケース／避けるべき3ケース」の実務判断を突き合わせて構成しています。
有効な3ケース：アジャイル開発などによりリリースサイクルが非常に早い場合／柔軟な修正のフォローアップや再診断が求められる場合／社内の実態に即したリスク評価が求められる場合。避けるべき3ケース：診断対象のシステム数が少ない場合／専門人材の採用や教育への継続的な投資体制が維持できない場合／監査やコンプライアンス上の理由で第三者診断が不可欠になっている場合。
出典：IPA「脆弱性診断内製化ガイド」の作成者が語る実践的な診断体制の設計と運用のポイント（2026-05-13、森山響氏／STNet 発言）｜dcross
この6ケースを踏まえて、Q1〜Q5に自社を当てはめていきます。
- Q1. リリース頻度は月1回以上（週次・スプリント制含む）ですか？——Yesなら内製化の効果が大きい。年1〜2回の大規模リリースであれば外注のみでも回る余地があります。
- Q2. 診断対象システム（Webアプリ・API）は3本以上ですか？——Yesなら内製化で年間コストを圧縮できる可能性が高い。1〜2本なら外注のスポット契約でも予算が回ります。
- Q3. セキュリティ人材への継続投資（採用・育成・書籍/研修予算）を今後2〜3年続けられますか？——Yesなら内製化を選択できる。「予算はあるが人は増やせない」ケースはハイブリッドで着手します。
- Q4. 扱う情報の機密度・PCI DSS等のコンプラ要件で「第三者診断が必須」の領域がありますか？——Yesなら第三者診断は外注として残し、それ以外の日常診断を内製化する分業になります（次節参照）。
- Q5. 開発チームがCI/CDを日常運用しており、脆弱性検出結果を受け止めるトリアージ担当を（兼任でも）確保できますか？——Yesなら内製化のツール導入効果が最大化される。担当が空欄のままなら、ツールを入れても検出結果が誰にも届かず失敗します。
Q1〜Q3のうち2つ以上Yes ＋ Q5 Yesで内製化のツール導入は有力で、年間コストとリードタイムの両方を改善できる可能性が高い企業です。Q4がYesの領域（PCI DSSカード会員データ環境など）は次節で扱うとおり第三者診断が要件で残り、それ以外を内製化する分業で組み立てます。
判定結果は後述の「内製化ロードマップと社内提案書に転記できる要点」節で、そのまま社内提案書の「現状整理」パートに書き込める形にしています。
PCI DSS・ISMS等でツール診断だけでは要件を満たせないケース
判定チャートのQ4で挙げた「第三者診断が必須の領域」は、内製化の議論で最も見落とされがちな論点です。ここを外して「うちはツール導入で内製化しました」と経営に報告すると、後に監査で不備を指摘され信用を失うリスクがあります。
カード会員データを扱うシステムがある場合、PCI DSS v4.0.1の要件11.3.2で「外部の脆弱性スキャンをASV（Approved Scanning Vendors、認定スキャンベンダー）が少なくとも3か月に1回実施した証跡」の提示が求められます。
evidence of passing external scans, performed by an ASV, at least once every three months
（訳：ASVが実施した外部脆弱性スキャンに合格した証跡を、少なくとも3か月に1回残すこと）
出典：Resource Guide: Vulnerability Scans and Approved Scanning Vendors（2024-07-10）｜PCI Security Standards Council
認定ASVはPCI SSC（PCI Security Standards Council）が認定する外部業者であり、自社のツールで内製化した診断ではこの要件を満たせません。加えて、要件11.3.2.1では「大幅な変更（significant change）」の後にも外部スキャンを求めており、CVSS 4.0以上の脆弱性は解決までフォローが必要です。
ISMS（ISO/IEC 27001）認証を維持している場合も、年次の外部監査に対応するため年1回程度の第三者診断を継続する運用が一般的です。
実務としては、「日常的な脆弱性診断はツールで内製化」＋「PCI DSS要件11のASVスキャンとISMS向けの年次外部診断は認定業者に外注」という分業が定着形です。認定ASVの選び方・四半期ごとの運用・スキャン失敗時のリスコアリング手続きなど、外注として残す ASV スキャン側の詳細は下記の別記事で扱っています。本記事では要件番号レベルでの位置づけを示すに留めます。
出典・参考資料（1件）
外注のみ／ハイブリッド／完全内製の年間コスト比較（3パターン実額試算）
コストは「安価になる可能性があります」で終わらせず、根拠付きの数字で並べます。前提を明示したうえで3パターンを比較しました。読者の会社のシステム数・リリース頻度に応じて数字を差し替え、社内提案書にそのまま転記できる粒度にしています。
試算前提：診断対象システム3本（Webアプリ2本＋API 1本）、リリース頻度は月1回、想定人月単価100万円、外注1本あたりの標準見積は100〜150万円／回（Webアプリ中規模の実勢帯）。ツール費用はSAST・SCA・DASTを組み合わせた統合SaaS型で月額5万円〜（Aikido Security・Snyk・SonarCloud等の低価格プラン水準）を採用。
NRIセキュアが試算シナリオとして提示する「年間予算500万円未満、対象システム10本、リリース3か月に1回」の構造モデルを参考に、本記事の中規模事業会社ケースにサイズを合わせています。
| 費用項目 | ①外注のみ | ②ハイブリッド | ③完全内製 |
|---|---|---|---|
| 初期費用 | 0円 | ツール導入・設定 約50万円 | ツール導入＋人材採用/育成 約200万円 |
| 年間ランニング（ツール費） | — | 統合型SaaS 60万円〜120万円（月5〜10万円） | SAST／SCA／DAST を分けて計 120万円〜240万円 |
| 年間ランニング（外注費） | 1回150万円 × 年1回 × 3本 = 450万円 | 年1回の手動診断 150万円 × 2本 = 300万円 | 0円（緊急時のみスポット） |
| 必要人月（社内工数） | 0.5人月（窓口・調整） | 2〜3人月（ツール運用・トリアージ） | 6〜9人月（診断計画・運用・改善） |
| 年間人件費（人月単価100万円） | 50万円 | 200〜300万円 | 600〜900万円 |
| 年間トータル | 約500万円 | 約560〜720万円 | 約720〜1,140万円 |
① 外注のみ「年1回」の前提について：本表は月次リリース環境でも外注が年1回に限られる想定で組んでいます。月次リリースの度に外注（1回150万円）を回せば、150万円 × 12回 = 1,800万円／年となり、事業会社の脆弱性診断予算では非現実的です。
NRIセキュアが試算シナリオで示す「年間予算500万円未満・年1回程度」の水準もこの構造的な上限に沿ったものです。したがって「外注のみ」を選ぶ組織は、リリース頻度が高くても年1回の総合診断＋大幅変更時のスポット追加という運用に落とし、リリースの間に混入する脆弱性は次回診断まで検知できない構造を受け入れることになります。この受け入れがコスト差の隠れた前提です。
人月単価100万円の前提について：福利厚生・オフィス費・研修費まで burdened cost 込みの一般的な社内単価として置いています。外注の常駐エンジニアに置き換える場合は150〜200万円レンジで再計算してください。
数字を並べると、診断対象が3本の中規模事業会社では、単純な「年間トータル」だけを見ると外注のみが最も安く見えます。しかしこの試算には「リリースの度に脆弱性が入り込むリスクを許容する」隠れコストが含まれていません。
ハイブリッドでは月次スプリントに合わせて自動スキャンが回るため、リリース直前の脆弱性混入を検知でき、緊急対応の外注（スポット100万円級）を避けられます。診断対象が5本・10本と増えると、外注のみは件数×150万円で掛け算に膨らみ、内製化は足し算で済むため、下記のとおり経済性が逆転します。
| 診断対象規模 | ①外注のみ | ②ハイブリッド | ③完全内製 |
|---|---|---|---|
| 3本（本記事の基準ケース） | 約500万円 | 約560〜720万円 | 約720〜1,140万円 |
| 5本 | 約800万円（150万×5＋人件費50万） | 約700〜900万円（ツール80〜140万＋手動150万×3＋人件250〜350万） | 約860〜1,300万円 |
| 10本（NRIセキュアS2シナリオ相当） | 約1,550万円（150万×10＋人件費50万） | 約950〜1,300万円（ツール100〜180万＋手動150万×5＋人件400〜600万） | 約1,200〜1,800万円 |
| 実質診断カバレッジ | 年1回/年12リリース中（≒8%） | 毎PR＋年1回手動（≒100%） | 毎PR（≒100%） |
この2枚目の表を見ると、5本の時点で外注のみとハイブリッドは並び、10本ではハイブリッドが約250〜600万円安くなります。
しかも「実質診断カバレッジ」の行に示したとおり、ハイブリッドは毎PRでツールが走ります。外注のみが取り逃す11回分のリリース窓を構造的にカバーできる設計です。診断対象が3本以上でリリース頻度が月次以上の組織にとって、ハイブリッドは「コストを削る手段」であると同時に「カバレッジを桁で上げる手段」でもあります。
読者の次の一手として、現行ベンダーに「手動診断部分だけスポットで頼む形に切り替えたい」と交渉するときには、次の切り出し方が根拠付きで通しやすい伝え方です。
ツールで自動化できる範囲（前節のマトリクスで◯を付けた項目）はSaaSで内製化します。認可設計・ビジネスロジック・ペネトレはこれまでどおり御社にお願いしたく、年契約から都度契約へ切り替えると年間費用は300万円台に収まる見込みで、リリースサイクルに沿った再診断のリードタイムも短縮できます。
DevSecOps／CI・CDへの組込——SAST／SCA／DAST／IASTをどこに挿すか
「シフトレフト」「セキュリティを開発ライフサイクルに統合」といった概念だけでは、開発チームは何を実装すればよいか判断できません。ここではCI/CDパイプラインの各フェーズに、どの類型のツールをどう挿すかを、GitHub Actions・GitLab CIのいずれでも共通する組み立てで示します。
パイプラインは大きく5つのフェーズに分かれます——コミット時（ローカル or push直後）／プルリクエスト（PR）作成時／マージ後のメインブランチ／ステージング環境へのデプロイ後／本番デプロイ前。各フェーズでの標準的な挿し方は次のとおりです。
- コミット時（pre-commit）：Secretsスキャナ（APIキー・パスワード誤コミット検出）とlinter系SAST。開発者のローカルで数秒で終わるものだけを置き、以降のフェーズを軽くする
- PR時：SAST（差分ファイルのみを対象に短時間で実行）＋ SCA（依存ライブラリの新規CVEチェック）。Critical/Highの検出でPRブロック、Medium以下はコメント表示のみ
- マージ後のメインブランチ：フルSAST（差分ではなく全体を対象）とフルSCA。時間がかかるスキャンはここに寄せて開発者を止めない
- ステージング環境デプロイ後：DAST（動的解析）。ステージングURLを対象にAI/RPAクロールで自動診断。SPAサイトはクロール可能なツールを選ぶ
- 本番デプロイ前／後：CSPM（クラウド設定監視）とASM（Attack Surface Management、公開資産の棚卸）。IASTを入れる場合は実行時計装として本番相当環境に
PRブロックの閾値は、最初から厳しく設定すると開発チームが疲弊して抜け穴（skip flagの乱発）が生まれます。運用開始時はCritical/Highのみブロック、Medium以下はワーニング（コメント表示のみ）から始め、四半期ごとに閾値を段階的に厳格化していくと段階アプローチとして機能します。
誤検知の除外ルールは、リポジトリに設定ファイル（例：`.security.yml`）を置いてバージョン管理し、誰がいつ何を除外したかを記録に残します。これがないと、除外理由が忘れられて「なぜかその指摘が出ない」状態が慢性化します。
サイボウズの実装事例は、開発者を止めない運用設計の参考になります。
AWS上に構築した中間サーバがWebhookをトリガーとしてAeyeScanから結果を取得し、自動でkintoneアプリへ登録される仕組み
出典：自動脆弱性診断ツールの導入と効率化の取り組み（2025-05-30）｜Cybozu Inside Out
検出結果を直接開発チームに投げるのではなく、いったんkintone（自社製品を活用）に登録してPSIRTがトリアージした上で必要なものだけを開発チームに差し戻す設計です。開発者は「精査済みの本物の脆弱性」だけを受け取ることになり、アラート疲れを構造的に防ぎます。読者の次の一手として、開発チームリーダーと立てるPoCは、まずSCA（依存ライブラリの既知CVEスキャン）から始めるのが低リスクです。
SCAは誤検知が少なく、CIへの組込が数日で完了し、成果（CVE検出件数と修正PR）が経営にも説明しやすいためです。
本番デプロイ前後で挙げた CSPM（クラウド設定監視）は、内製化を進めるほど「S3の公開設定」「IAMの過剰権限」「セキュリティグループの全開放」といった構成起因のリスクが日次で積み上がるため、パイプラインの終盤に必ず組み込みたい類型です。
AWS Config／Azure Policy／GCP Security Command Centerといったクラウド標準機能でも一次対応は可能で、有償SaaS（Aikido Security・Wiz・Prisma Cloudなど）と組み合わせると、複数クラウド横断の可視化とアラート統合が進みます。
クラウド環境の脆弱性は、本節で扱った CSPM（設定不備の検出）だけに閉じず、インスタンス上の OS・ミドルウェア脆弱性、コンテナイメージ、マネージドサービスの権限設計まで診断領域が横に広がります。オンプレ／Web アプリ前提の内製化フレームでは取りこぼしやすい領域なので、クラウド固有の診断の全体像は下記の記事にまとめています。
社内運用体制の現実——トリアージ・誤検知除去・修正優先度付け・開発者への差戻し
ツールを入れれば脆弱性診断が回る、という前提は現場では成り立ちません。検出結果のトリアージ・誤検知除外・修正優先度付け・開発者への差戻しを、誰かが継続的にやる必要があります。IPAガイド第4章「組織構造・人材」とユービーセキュア「推進体制の2パターン」を土台に、実務で選択できる体制を整理します。
誰が回すか——専任 vs 兼任、一元管理 vs 部門分散の選び方
回し手は大きく2軸で決まります。担当の稼働形態（専任か兼任か）と、組織上の位置（PSIRT/情シスに一元集中か、各開発部門に分散か）です。
診断対象システムが3〜5本規模なら兼任1〜2名でも回せますが、扱う情報の機密度が高い（金融周辺・EC・個人情報大量保有）か、開発部門が3〜4部門以上に分散している場合は、PSIRT相当の専任1名を置き、各部門にセキュリティ担当を兼任で置く「ハブ＆スポーク型」という分業が定着形です。
サイボウズのように部門横断でトリアージを引き受けるチームを持つと、開発チームが受け取るのは「精査済みで対応要のものだけ」になり、開発生産性を犠牲にしません。
トリアージと誤検知除外のフロー（CVSS判断・除外ルールの文書化）
ツールが返した検出結果は、まずCVSSスコア（3.0または4.0）と、自社での実質的な影響度（インターネットに公開されているか・認証の内側か・扱うデータの機密度）を掛け合わせて優先度を決めます。誤検知と判断したものは、判断理由を必ず記録に残し、リポジトリの除外ルールファイルに追記します。「前任者が消したが理由が分からない」の状況を防ぐためです。
前掲サイボウズの運用事例に沿えば、有効な指摘か対応が必要かの判断と判断基準の明文化は、トリアージの中核ルールとして担当者交代時にも継承すべき資産になります。基準の明文化がないと担当者が変わるたびに判断が揺れ、除外の再現性が失われます。
修正優先度付けと開発者への差戻しフォーマット
修正の期限（SLA：Service Level Agreement、期限順守のサービスレベル合意）は、優先度3段階で設計するのが実務的です——Critical（例：認証回避・任意コード実行）は即日〜3営業日／High（例：SQLインジェクション既知）はスプリント内（1〜2週間）／Mediumは次スプリント（4週以内）／Lowは四半期リリースに合わせて。
開発者への差戻しフォーマットは、「脆弱性の概要／再現手順／CVSSスコア／影響度（自社での実質）／推奨修正方針／期限」の6項目を固定し、Slack・GitHub Issue・Jira等の既存ツールに載せます。フォーマットを揃えることで、開発者側も「この形で来たら何をすればいいか」を学習し、応答速度が上がります。
読者の中長期の次の一手は、開発部門に「セキュリティチャンピオン」——開発者でありつつセキュリティに詳しい役割——を各部門1名置き、PSIRTと各開発部門の橋渡しを担ってもらう体制設計です。既存開発者から選任し兼任比率20%前後で最初の90日は診断結果トリアージと開発チームへのフィードバックに絞ると、負荷過多で失速せずに定着させやすくなります。
専任のセキュリティ人材を各部門に配置するのは採用面で困難です。既存開発者から社内で育成し兼任してもらう形なら業務ルーチンに組み込みやすい設計になり、AeyeScanのMoney Forward事例（約60のプロダクトを対象に順次定期脆弱性診断を実施）のようなスケールにも耐えられます。
出典・参考資料（1件）
内製化でつまずく失敗パターンと回避のコツ
成功事例より、失敗パターンを先に知る方が実務では役立ちます。IPAガイド第5章の段階的導入の順序と、実装記事から抽出した典型的な4パターンを症状→原因→回避策の順に整理します。
パターン(1) ツール入れたが誰も見なくなった
症状：導入直後は担当者が結果を見ていたが、3か月経つとダッシュボードを開かなくなり、検出結果が溜まる一方になります。原因：見る「時間」と「場」が業務ルーチンに組み込まれていないため、忙しい週から順に後回しになります。回避策：週次で30〜60分の「脆弱性レビュー会議」を開発チームリーダーと合同で固定し、その週の検出結果を必ず1件ずつ棚卸しする運用にします。
会議枠を設けるだけで担当が確保され、「見なかった」の状況が構造的に消えます。
パターン(2) アラート疲れで結果を無視するようになった
症状：Slackに脆弱性通知が毎日流れ、開発者が「またか」と読み飛ばすようになります。実質的な脆弱性が埋もれてしまいます。原因：初期の閾値設定がゆるく、Medium以下も全部通知に流れているため、シグナル対ノイズ比が下がります。回避策：導入直後はCritical/Highのみを通知に載せ、Medium/Lowはダッシュボードに留めます。
運用が定着した3〜6か月後に段階的にMediumも通知に含める閾値の段階的厳格化で、ノイズを構造的に抑えます。加えて、誤検知除外を担当がまとめて実行し、通知に「本物」だけが流れる状態を維持します。
パターン(3) 経営説明で「見落としのリスクは？」に答えられず信用失う
症状：経営会議で「ツール導入で内製化しました」と報告したが、「ツールで見落としは無いのか？」の問いに答えられず、以降の投資判断で信頼を失います。原因：内製化の範囲（ツールで検出可の項目）と、範囲外（原理的に手動診断が要る項目）の切り分けを、経営に説明できる形で整理していないためです。
回避策：本記事の冒頭マトリクスと同型の「ツール検出可の項目 × 診断頻度 × 修正SLA」の3列表を経営報告のフォーマットに固定します。「ツールでは検出できない領域は年1〜2回の外部手動診断でカバーしている」と併記することで、内製化と外注の分業を可視化し、見落としリスクへの回答を用意しておきます。
パターン(4) スコープを一気に広げて頓挫
症状：全社の全プロダクトを対象に一斉導入したが、部門ごとの温度差・技術スタックの差でトリアージが回らず、半年で運用停止に至ります。原因：PoCの成功確認を経ずに本番スコープまで広げたため、部門ごとの調整コストが想定を上回りました。回避策：IPAガイドが明示するとおり「まずは小規模で影響度の低いシステムから段階的に運用を開始」します。
単一プロダクトでのPoCを3か月完了させ、トリアージフローと除外ルールと修正SLAが定常化してから、四半期ごとに2〜3プロダクトずつスコープを広げます。AeyeScanが紹介するMoney Forwardの事例で「導入初年度は約60のプロダクトを対象に、順次定期脆弱性診断を実施」と語られているのも、順次だからこそスケールできた実例として読めます。
前掲IPA『脆弱性診断内製化ガイド』5.3節「スモールスタートによる段階的な運用開始」でも、まずは小規模で影響度の低いシステムから段階的に運用を開始し、内製と外部発注を併用して診断品質を確保しつつノウハウを段階的に蓄積することが望ましいと明記されています。
ハイブリッド運用の推奨形——日次〜週次のツール自動診断＋年1〜2回の手動診断
ここまでの節を突き合わせると、中規模事業会社に当てはまる標準形はツール自動診断（日次〜週次）＋手動診断（年1〜2回）のハイブリッドに収束します。IPAガイドは、このモデルを内製化の理論的根拠として明示しています。
定期的に外部の専門企業を活用するハイブリッド運用という選択肢もある。この運用方式では、日常的な脆弱性診断は自社で実施しつつ、定期的に外部の専門企業による診断を組み合わせる（中略）結果と比較・検証を行うことで、自社の診断精度やスキルの向上と、誤検知や検知漏れの傾向まで把握できている状態を指す。
出典：脆弱性診断内製化ガイド 3.7 ハイブリッド運用という選択肢｜IPA
このモデルの実装は、次のようになります。日常運用はSCA（毎コミット・毎PR）＋SAST（PRとマージ後）＋DAST（ステージング環境で日次〜週次）で自動化し、開発チームがリリースサイクルに沿って脆弱性を潰す。
年1〜2回、外部の専門診断ベンダーにペネトレーションテスト・ビジネスロジック診断・認可設計レビューを依頼し、ツールで検出できない領域と、ツール自身のカバレッジ精度を第三者視点で検証してもらう。PCI DSSカード会員データ環境がある場合はASVによる四半期外部スキャンを別枠で走らせます。
外注として残す年1〜2回のペネトレーションテストは、対象範囲（外部・内部・シナリオ型・TLPT）と検証の深さで見積もりの桁が変わります。本節のコスト表では 1 本 150 万円前後を目安に置きましたが、自社の対象・種類でどのゾーンに落ちるかを見積もる材料は、下記の記事に対象別の実額レンジ早見表としてまとめています。
これが唯一の正解ではなく、判定チャートで「診断対象3本未満・リリース年1〜2回」の企業は外注のみで足り、「診断対象10本以上・専任セキュリティ人材が3名以上」の企業は完全内製に振り切れる余地があります。
3〜9本の中規模帯は、本節のハイブリッド標準形が最も当てはまるゾーンです。ハイブリッドは多くの中規模事業会社に当てはまる標準形の一つとして位置づけ、自社の判定結果に合わせた変奏形を組み立ててください。
内製化を支える主要ツール——SAST／DAST／SCA／IASTの概念と代表例
内製化に使えるツールは、対象と検出の仕組みによって4類型に分かれます。各類型の役割と代表例を並列で紹介します。詳細な機能比較や料金比較は下記の記事に譲り、ここでは概念と代表例で「何を選ぶ候補があるか」の見取り図を作ります。診断方法別・費用相場別の全体像を横並びで比較検討したい場合は、下記の記事を参照してください。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
SAST（静的アプリケーションセキュリティテスト）
ソースコードを実行せずに解析し、危険なパターン（SQLインジェクションを起こしうる文字列連結など）を検出する類型です。開発の早い段階（コミット時・PR時）で検出できるため、修正コストが最も低い。代表例はSonarQube・GitHub CodeQL・Semgrepなど。オープンソースの選択肢が豊富で、CI組込のドキュメントも公式に揃っています。
DAST（動的アプリケーションセキュリティテスト）
稼働中のアプリケーションに対して疑似攻撃リクエストを送り、応答から脆弱性を推定する類型です。ソースコード無しでも診断できるため、SaaSやサードパーティAPIも対象にできます。代表例はOWASP ZAP（無償）、AeyeScan、Securify、SCT SECUREクラウドスキャンなど。SPA（Single Page Application）に対応するには自動クロール性能が要ります。
SCA（ソフトウェアコンポジション解析）
依存ライブラリの既知の脆弱性（CVE）を、パッケージのバージョン情報から突き合わせて検出する類型です。SBOM（ソフトウェア部品表）生成にも使えます。誤検知が少なくCI組込も容易なため、内製化のPoCの第一歩として最適。代表例はSnyk、Dependabot（GitHub標準）、Aikido Securityなど。
IAST（対話型アプリケーションセキュリティテスト）
実行時にアプリケーションに計装（instrumentation）を差し込み、SASTとDASTの中間で検出精度と検出範囲を両立させる類型です。テスト自動化と組み合わせて使うと効果的ですが、導入負荷は他類型より高い。代表例はContrast Securityなど。SAST/SCA/DASTが定常化した後のオプションとして検討する順序に無理がありません。
統合型SaaS——上記類型を1つのダッシュボードで扱う
SAST・DAST・SCA・CSPM・Secretsスキャン等の複数機能を、単一のプラットフォームに統合したSaaSも増えています。個別ツールを組み合わせるとダッシュボードが分散するのに対し、統合型はダッシュボードが1つに集約されます。代表例はAikido Security、Snyk（Enterpriseプラン）、GitHub Advanced Securityなど。
判定チャートで「トリアージ担当を確保しにくい」に該当する組織は、統合型から始めると運用が回りやすい傾向があります。
【比較表】主要な自動診断ツール／内製化支援サービスのスポット比較
| サービス名 | Aikido Security | AeyeScan | VAddy | Securify | SCT SECURE クラウドスキャン | GMOサイバーセキュリティ byイエラエ |
|---|---|---|---|---|---|---|
| 提供形態 | SaaS（オールインワン統合型） | SaaS（DAST・AI/RPAクローラ） | SaaS（DAST・CI/CD連携型） | SaaS（DAST＋ASM／CSPM／SBOM統合） | SaaS（外部スキャン型・毎日自動） | 専門家常駐＋ASMツール（SaaS） |
| 対応診断範囲 | SAST／DAST／SCA／CSPM コンテナ／IaC／Secrets／Malware 等11種 | Webアプリ／SPA API（オプション） | Webアプリ （プラン別5〜18項目・SQLi／XSS ほか） | Webアプリ／API／ASM WordPress／SaaS／CSPM／SBOM | Webサイト ネットワーク機器（ルータ／FW／DNS） | Web／スマホアプリ／クラウド／IoT ネットワーク／NFT・ブロックチェーン／AI |
| CI/CD組込 | ● | ● | ◎（CI連携を前提設計） | × | × | × |
| 手動診断オプション | × | × | △（有償スポット40万円） | × | △（別ライン「SCT SECURE セキュリティ診断」で提供） | ◎（中核・ホワイトハッカー200名以上） |
| 料金 | 月額50,000円台〜 （AndGo経由・要見積） | 要問い合わせ （One Shot／Business／カスタム） | 月額19,800円〜 （初期0円・1ヶ月単位） | 月額50,000円〜 （STARTER・1IP/FQDN・年額60万円） | 年額383,000円〜 （初年度・3IP/FQDNまで・税別） | 手動診断: 要お問い合わせ ASM: 月額40,000円〜 |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
※上記は一般的な傾向です。実際の機能搭載の有無については各社情報をご確認ください。
サービス個別紹介
ここまで整理した「内製化の分業」に沿って、内製化を支える国内で導入実績のある代表的なツール／サービスを紹介します。判定チャートの結果とマトリクスを突き合わせながら、自社に合う候補を絞り込む材料にしてください。
Aikido Security（アイキド セキュリティ）
Aikido Securityは、SAST・DAST・SCA・CSPM・Secretsスキャン・コンテナスキャン・IaCスキャン等、脆弱性診断に必要な11種類のスキャナを1つのプラットフォームに統合したオールインワンのSaaSです。
開発元はベルギーのAikido Security BV、日本市場では株式会社AndGoが正規代理店として提供しており、月額5万円台から導入可能・日本語での導入支援・請求書払いに対応しています。
自動トリアージ（AutoTriage）でノイズを削減し、修正のプルリクエストを自動生成するAutoFixも備えるため、判定チャートで「トリアージ担当を確保しにくい」に該当する組織でも運用を回しやすい構成です。
IDE拡張により開発者はエディタ上でリアルタイムに脆弱性を確認でき、ISO 27001:2022とSOC 2 Type II に準拠するAikido Security BV本体のコンプライアンス基盤を活用できます。「個別ツールを積み上げるとダッシュボードが増えて運用が崩れる」ケースでは、統合型SaaSの候補として検討しやすい構成です。
AeyeScan（エーアイスキャン）
AIとRPAを組み合わせた自動クローリング技術で、ブラウザのログイン操作からテストシナリオを自動生成するDAST型脆弱性診断SaaSです。株式会社エーアイセキュリティラボが提供し、SPA（Single Page Application）を含む動的サイトの画面遷移にも対応します。
OWASP TOP10・IPA・ASVS 5.0（OWASP Application Security Verification Standard、Webアプリのセキュリティ検証項目を体系化した国際規格）に準拠しており、API診断はOWASP API Security Top 10 2023にも対応します。有償契約300社以上の実績があり、生成AI活用の脆弱性診断機能で複数の特許を取得しています。
サイボウズが本ツールをCI/CDに組み込み、AWS中間サーバ経由でkintoneに検出結果を集約する運用事例をブログで開示しているため、実装イメージが具体的に掴めます。DAST類型で「専門知識のない開発者でもブラウザ操作から診断を回したい」組織に適しています。
VAddy（バディ）
CI/CDパイプラインへの組込みを前提設計したクラウド型のWebアプリケーション脆弱性診断SaaSです。株式会社ビットフォレストが月額サブスクリプション（初期費用0円・Professional 19,800円／Enterprise 59,800円／Advanced 99,800円）で提供し、1ヶ月単位でのプラン変更が可能です。
集英社の事例では「CIと連携した脆弱性診断の自動化を2時間で実現」と紹介されており、CI組込の敷居の低さが強みです。
プラン別の診断項目数はProfessional 5項目・Enterprise 11項目・Advanced 18項目で、Advancedは IPA「安全なウェブサイトの作り方」チェックリストに標準対応しています。開発チームがCI/CDを日常運用しており、まずはSQLインジェクション・XSS中心の継続診断から入りたい組織に向きます。
Securify（セキュリファイ）
Securifyは、株式会社スリーシェイクが提供するクラウド型の自動脆弱性診断・ASMプラットフォームです。中核のWebアプリケーション診断（DAST）に加え、ASM（Attack Surface Management）・WordPress診断・SaaS診断（Google ドライブ／OneDriveの公開設定可視化）・CSPM・SBOMを1シリーズに統合しています。
DASTのSTARTERプランは月額5万円〜で開始でき、スケジュール実行による継続診断を特徴とします。
SaaS診断の基本機能は無料提供のため、公開設定の把握から段階的にセキュリティ運用を組み立てたい組織にとって、入口として使いやすい構成です。SREやインフラ運用と組み合わせやすいため、開発・運用が横断する体制で内製化を進める場合の候補になります。
SCT SECURE クラウドスキャン
SCT SECURE クラウドスキャンは、三和コムテック株式会社が2004年から提供する外部スキャン型の自動脆弱性診断サービスです。Webサイト・ルーター・ファイアウォール・DNS等のネットワーク機器を、インターネット経由で外部から毎日自動診断します。
300社以上に1,500万回以上の診断を提供した実績があり、契約期間中は何度でも診断を実行できる年額料金体系（初年度383,000円／3IP・FQDNまで、税別）で、月額プランはありません。
診断対象に脆弱性が検出されなければ「セキュリティマーク」をサイト掲示できるため、対外的にセキュリティ運用の証跡を示したい組織にも向きます。PCI DSSのASVスキャン用途には別商品の「SCT SECURE ASVスキャン」が用意されているため、要件が該当する場合は別途検討します。
GMOサイバーセキュリティ byイエラエ／GMOサイバー攻撃ネットde診断 ASM
GMOサイバーセキュリティ byイエラエは、国内のホワイトハッカーを多数擁するサイバーセキュリティ専門企業（従業員341名、2026年4月時点）です。専門家による手動主体の脆弱性診断・ペネトレーションテストと、月額課金のASMツール「GMOサイバー攻撃ネットde診断 ASM」の2系統を持ちます。
ハイブリッド運用で「年1〜2回の手動診断」を担う外部パートナーとして、認可設計・ビジネスロジック欠陥・複合連鎖攻撃といったツール診断の対象外領域をカバーする候補になります。
ツール型のASMは、内製化のツール診断と並行して、社外に公開されている資産の棚卸しと継続監視を回す用途に使えます。ハイブリッド運用の「日常＝ツール／年1〜2回＝手動」の分業を、同一ベンダー内で組み立てたい場合の選択肢です。
内製化ロードマップと社内提案書に転記できる要点
ここまでの節を、上司決裁に持っていく1枚提案書にそのまま転記できる要点として構造化します。判定チャートの結果・診断項目マトリクス・コスト表・PCI DSS等コンプラ切り分けを、順に埋めていけば1枚が完成する形にしています。
下の6行の枠に自社の情報を書き込んでいけば、そのまま1枚提案書として使えます。右列に本記事のどこから転記するかを示しました。
| 提案書項目 | 記入内容（あなたの会社） | 本記事のどこから転記 |
|---|---|---|
| 判定結果 | Q1 リリース頻度: ______／Q2 診断対象本数: ______／Q3 人材投資継続: Yes/No／Q4 コンプラ第三者診断必須: Yes/No／Q5 トリアージ担当: ______ | §「内製化に向く企業／外注を残すべき企業の判定チャート」（Q1〜Q5） |
| 内製化スコープ | SQLi／XSS／依存CVE／クラウド設定／シークレット埋込／CSRF／ポート・TLS 等（自社で該当するものに丸） | §「診断項目 × 内製可否マトリクス」の◯行 |
| 外注継続スコープ | 認可設計／ビジネスロジック／IDOR／ペネトレーション／PCI DSS要件11.3.2のASVスキャン 等 | §マトリクス表の要手動行＋§「PCI DSS・ISMS等でツール診断だけでは要件を満たせないケース」 |
| 年間コスト（現行→想定） | 現行 ¥______／年 → 想定 ¥______／年（差分 ¥______）※前提: 診断対象 ___本／リリース ___回/月／人月単価 ___万円 | §「コスト比較」のハイブリッド行と規模別表 |
| 段階導入計画 | Q1: SCAをCIへ／Q2: SASTをPRブロック（Critical/Highのみ）／Q3: DASTをステージング日次／Y2: IAST検討＋セキュリティチャンピオン設計 | §「段階的導入」（本節末尾の順序） |
| コンプラ確認 | ☐ PCI DSS該当（要件11.3.2の四半期ASVスキャンを認定業者に継続外注） ☐ ISMS該当（年次外部診断を継続） ☐ 該当なし | §「PCI DSS・ISMS等でツール診断だけでは要件を満たせないケース」 |
各行の右列に本記事の該当節を示しているので、必要に応じて元の節を開いて具体的な数値や表現を差し替えてください。段階導入の順序は、IPAガイドが示す「まずは小規模で影響度の低いシステムから」に沿った設計で、PoCの成功確認を経ずに全社スコープへ広げないことが重要です。コンプラ確認は該当がある場合は必ず併記し、経営から「監査対応は？」と問われた際の答えを提案書内に用意しておきます。
まとめ
脆弱性診断の内製化は、「全部ツールで置き換える」か「これまでどおり全部外注する」かの二択で決めるものではありません。診断項目のレベルで切り分ければ、SQLインジェクション・XSS・依存ライブラリCVE・クラウド設定不備といったパターン化された既知の脆弱性は、ツールで自動化して内製化できます。
一方、認可設計の欠陥・ビジネスロジックの穴・複合連鎖攻撃は原理的に手動診断が要り、外注として残すのが妥当です。
PCI DSS要件11の外部ASVスキャンやISMS向けの年次外部診断のように、コンプラ要件で第三者診断が必須の領域も外注として残ります。これらを踏まえたハイブリッド運用——日次〜週次のツール自動診断＋年1〜2回の外部手動診断——が、多くの中規模事業会社に当てはまる標準形です。
読者の会社の判定チャート結果に応じて変奏形を設計し、まずはSCAをCIに組み込むPoCから小さく始める方針が、失敗パターンを回避しながら内製化を定着させる進め方として扱いやすいでしょう。
よくある質問（FAQ）
Q. 脆弱性診断の内製化とは何ですか？
脆弱性診断の内製化とは、これまで外部業者に依頼していた脆弱性診断のうち、ツールで自動化できる領域を自社の担当者とSaaS型診断ツールで継続的に回す運用形態を指します。全ての診断を自社に取り込む「完全内製」を意味するわけではなく、多くの企業は「日常的な脆弱性診断はツールで内製・ビジネスロジック診断や年次外部診断は外注」というハイブリッド運用に落とし込みます。
Q. 脆弱性診断の内製化はPCI DSS対応でも実施できますか？
脆弱性診断の内製化は、PCI DSSカード会員データ環境では、内製ツールに加えてASV外部スキャン（3か月に1回）が別途必要になります。認定業者（ASV：Approved Scanning Vendors）による少なくとも3か月に1回の外部スキャンを別途外注する必要があるためです。
認定ASVはPCI SSC（PCI Security Standards Council）が認定する外部業者に限られ、自社の内製診断では代替できません。
したがって内製化とPCI DSS対応は排他ではなく、「日常的な脆弱性診断はツールで内製化・PCI DSS要件11のASVスキャンとISMS向けの年次外部診断は認定業者に外注」という分業で両立させるのが実務解です。ISMS（ISO/IEC 27001）認証を維持している場合も、年次の外部監査に対応するため、年1回の第三者診断を継続する設計にします。
出典・参考資料（2件）
Q. 脆弱性診断の内製化は無料ツールだけでも大丈夫ですか？
脆弱性診断の内製化を無料ツールだけで完結させるのは現実的ではなく、SCA（依存ライブラリの既知CVE検出）など誤検知が少ない領域から無料ツールで着手し、DASTや統合型ダッシュボードは有償SaaSに切り替える構成が現実的です。
OWASP ZAPやDependabotなどの無料ツールは学習コストと導入コストが低い一方、SPA（Single Page Application）への自動クロール性能・ダッシュボード統合・トリアージ支援・国内サポートに限界があります。
PoC（試験導入）の第一歩として無料ツールでSCAをCIに組み込み、検出履歴・トリアージフロー・除外ルールが定常化した段階で有償SaaSへ移行する順序であれば、初期投資を抑えつつ内製化の成果を経営に説明しやすくなります。移行時に検出履歴を継続できる設計にしておくとスムーズです。
Q. 脆弱性診断の内製化は兼任担当者でも回せますか、専任が必要ですか？
脆弱性診断の内製化は、3〜5本規模なら兼任1〜2名で回せますが、機密度が高い or 部門分散時はハブ＆スポーク型が現実解です。
診断対象システムが3〜5本規模なら兼任1〜2名でも回せますが、機密度が高い（金融周辺・EC・個人情報大量保有）か開発部門が3〜4部門以上に分散する場合は、PSIRT相当の専任1名を置き各部門にセキュリティ担当を兼任で置く「ハブ＆スポーク型」に切り替える必要があります。
兼任で回す場合でも、週次30〜60分の「脆弱性レビュー会議」を業務ルーチンに固定することが最低条件です。その時間を確保できない体制で始めると、失敗パターン(1)「ツール入れたが誰も見なくなった」に陥り、検出結果が溜まる一方の状態になります。
中長期では、開発部門に「セキュリティチャンピオン」——開発者でありつつセキュリティに詳しい役割——を各部門1名置き、PSIRTと開発部門の橋渡しを担ってもらう体制設計が、採用面の制約下でもスケールさせられる現実的な形です。
Q. 脆弱性診断の内製化で診断結果が誤検知（false positive）だらけで運用が回らない場合、どう対処すればよいですか？
脆弱性診断の内製化で誤検知が運用を圧迫する場合、通知はCritical/Highのみに絞り、除外ルールをリポジトリで版管理する運用が有効です。導入直後は通知閾値をCritical/Highのみに絞り（Medium以下はダッシュボード表示のみに留める）、誤検知の除外ルールをリポジトリの設定ファイル（例：.security.yml）でバージョン管理し、四半期ごとに閾値を段階的に厳格化していきます。
誤検知（false positive）はツール診断に原理的に付随するもので、IPAガイドも「誤検知や未検出が発生する場合があるため、最終的な結果の妥当性評価を人が行う必要がある」と明記しています。誤検知除外を担当がまとめて実行し、通知チャネルには「本物」だけが流れる状態を維持すれば、アラート疲れで開発者が通知を読み飛ばす失敗パターン(2)を構造的に防げます。
誰がいつ何を除外したかを設定ファイルで記録に残すことで、「前任者が消したが理由が分からない」の状況も回避できます。
出典・参考資料（1件）
Q. 脆弱性診断を内製化した場合、経営への報告はどう変える必要がありますか？
脆弱性診断を内製化した場合の経営報告は、「検出可の項目 × 診断頻度 × 修正SLA」の3列表を固定し、外注カバー領域を併記する形式に変えます。「ツール検出可の項目 × 診断頻度 × 修正SLA」の3列表を報告フォーマットに固定し、「ツールでは検出できない領域は年1〜2回の外部手動診断でカバー」と併記することで、内製化と外注の分業を可視化するのが要点です。
「ツール導入で内製化しました」とだけ報告すると、経営から「ツールで見落としは無いのか？」と問われて答えられず、以降の投資判断で信用を失うパターンに陥ります。診断項目マトリクスで「原理的に不可（要手動）」に振り分けた項目を外注で継続的にカバーしている事実を併記すれば、内製化の範囲と限界の両方に責任を持っている報告になります。
PCI DSSやISMS等でコンプラ要件の第三者診断が必須の領域がある場合は、その外注継続も明記し、監査対応の連続性を示します。
Q. 脆弱性診断の内製化に使うツールにはどのような種類がありますか？
脆弱性診断の内製化に使うツールは、SAST／DAST／SCA／IASTの4類型と、それらを統合したSaaS型に分かれます。SAST（静的解析・ソースコード対象）／DAST（動的解析・稼働中アプリ対象）／SCA（依存ライブラリのCVE検出）／IAST（実行時計装でSAST・DASTの中間）を、単一のプラットフォームに束ねる統合型SaaSも増えています。
CI/CDへの組込みやすさと運用負荷が異なるため、内製化のPoC第一歩には誤検知が少なく成果を経営に説明しやすいSCAが最適で、その後にSAST・DASTへと段階的に広げるのが現実的な順序です。個別ツールを組み合わせるとダッシュボードが分散してトリアージ担当の負荷が上がるため、判定チャートで「トリアージ担当を確保しにくい」に該当する組織は、統合型SaaSから始めると運用が回りやすくなります。
各類型の代表例と特徴は本記事の「内製化を支える主要ツール」節で詳しく扱っています。
脆弱性・セキュリティ診断サービスの料金・手数料を一括チェック
MCB FinTechカタログでは、脆弱性・セキュリティ診断サービスの最新資料をワンクリックで一括入手できます。各サービスの診断対象・料金体系・SaaS/自社設置別・CI組込対応・国内サポート体制など、比較に必要な情報をすばやく把握でき、社内提案書に添付する候補ツールの資料も同時に揃います。
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修者は記事の内容について監修しています。
