脆弱性診断の外注｜依頼範囲とベンダー選定の勘所

2026 8/05

2026年8月5日 2026年8月5日

クライアントから「リリース前にセキュリティ診断の結果を出してほしい」と求められ、社内に専門家がいないまま対応に追われた経験はないでしょうか。決済や個人情報を扱う受託案件では、セキュリティの担保が契約条件になることも珍しくありません。開発とスケジュール管理に追われるなかで、攻撃者視点の診断まで自前でこなすのは現実的に困難です。そこで有力な選択肢になるのが脆弱性診断の外注です。

本記事では、なぜセキュリティテストは外に任せやすいのか、何をどこまで依頼できるのか、診断ベンダーをどう選び、結果をどう社内対応につなげるのかを、開発の合間でも判断できる粒度で整理します。診断手法そのものの技術解説ではなく、あくまで「外注の判断・依頼設計・ベンダー選定・結果対応」に軸を置いて解説します。手法の詳細は本文中で関連記事へ誘導しますので、必要に応じてそちらもご覧ください。

なぜセキュリティテストは外注が向くのか

機能テストと違い、セキュリティテストは「攻撃者の視点」「専門ツール」「資格・経験」がそろって初めて成立します。開発を兼任するエンジニアが片手間で行うには、習得コストも運用負荷も高すぎるのが実情です。テストをエンジニアに兼任させている体制では、通常の機能検証だけでも手一杯で、セキュリティ観点まで踏み込む余力は残りにくいでしょう。

リリース直前になって「診断が終わっていない」と気づき、品質を妥協して出してしまう。そんな綱渡りを避けたいと考えるPMは少なくありません。セキュリティは、いったん本番で問題が起きるとクライアントの信頼を大きく損なう領域です。だからこそ、専門チームの力を計画的に借りる判断が重要になります。

セキュリティ診断は、専門性・独立性・ツールと資格という3つの理由から、外部の専門チームに任せる合理性が高い領域です。

外注が向く理由を分解すると、内製との向き不向きが見えてきます。

専門性: 最新の攻撃手法やCVE（既知の脆弱性情報）を追い続ける必要があり、片手間では知識が陳腐化する
独立性: 開発者自身が診断すると、自分の実装の思い込みがそのまま盲点になりやすい
ツール・資格: 商用の診断ツールや、有資格者による手動診断は、単発案件のために内製化しづらい
繁閑差: 診断はリリース前など特定のタイミングに集中し、常時稼働の専任を置きにくい

内製と外注を、セキュリティテストの特性で比較すると次のようになります。

観点	内製（開発者兼任）	専門ベンダーへ外注
攻撃者視点の網羅性	限定的	高い
独立した第三者性	なし	あり
商用診断ツールの活用	導入負担が大きい	標準装備
有資格者による手動診断	該当なし	対応可能
クライアントへの説明力	弱い	診断報告書で担保
繁閑差への対応	難しい	スポット依頼で吸収

高橋寿一『知識ゼロから学ぶソフトウェアテスト』でも、セキュリティテストはファジングやペネトレーションテストなど専用のアプローチと視点を要する領域として扱われています。開発の延長で片手間に済ませられるものではなく、独立した専門性が求められる分野だと位置づけられているわけです。第三者による診断は、クライアントへ品質を客観的に示す証跡にもなります。

外注しても発注側に残る役割

外注するからといって、社内が丸投げでよいわけではありません。何を守りたいのか（診断対象と守るべき資産）を決めるのは発注側の役割です。ここが曖昧なままだと、どんなに優秀なベンダーでも的外れな診断になってしまいます。

発注側が最低限担うべき役割は次のとおりです。

診断対象システムと、守るべきデータ・資産を特定する
クライアントや業界が求めるセキュリティ要件を整理する
診断で見つかった指摘を、修正へつなげる社内体制を用意する

つまり外注で肩代わりできるのは「診断そのもの」であり、「何を守り、どう直すか」の意思決定は社内に残ります。この線引きを理解しておくと、ベンダーとの役割分担がスムーズになります。

脆弱性診断の外注で任せられる範囲

ひとくちにセキュリティ診断と言っても、対象と手法によって複数の種類に分かれます。外注を検討する前に、まず「何を外に出せるのか」を把握しておきましょう。

外注できる診断は、脆弱性診断・ペネトレーションテスト・SAST/DASTの運用・診断結果のトリアージの大きく4系統に整理できます。

代表的な外注メニューを整理すると次のとおりです。

診断の種類	主な対象	手法の性質	外注適性
Webアプリケーション脆弱性診断	画面・API・入力処理	ツール＋手動の組み合わせ	高い
プラットフォーム診断	サーバ・ネットワーク・ミドルウェア	ツール中心	高い
ペネトレーションテスト	システム全体の突破可否	手動中心・シナリオ型	高い
SAST（静的解析）運用	ソースコード	ツール導入・チューニング	中程度
DAST（動的解析）運用	稼働中アプリ	ツール導入・CI連携	中程度
診断結果のトリアージ	検出結果の精査	専門家の判断	高い

それぞれの診断が担う役割

各メニューの位置づけを、混同しないように補足します。

脆弱性診断: 既知の脆弱性が存在するかを網羅的に洗い出す診断です。画面やAPIを対象にするWebアプリ診断と、サーバやミドルウェアを対象にするプラットフォーム診断に分かれます
ペネトレーションテスト: 「実際に侵入できるか」を攻撃者の視点で試すテストです。脆弱性診断より目的が絞られ、複数の弱点を組み合わせて深く掘り下げます
SAST/DAST: 開発工程に組み込む自動診断の仕組みです。ツール選定・初期設定・誤検知の抑制まで含めて委託でき、継続的に品質を底上げできます
トリアージ: 検出された多数の指摘を、深刻度と対応要否で仕分ける作業です。ここを専門家に任せると社内対応が一気に楽になります

脆弱性診断とペネトレーションテストは目的が異なるため、区別しておくことが大切です。前者は「穴の網羅的な棚卸し」、後者は「その穴から本当に侵入できるかの検証」と考えると整理しやすいでしょう。多くの受託案件では、まず網羅的な脆弱性診断を土台に据え、機密性の高いシステムでのみペネトレーションテストを追加する、という組み立てが現実的です。

トリアージを外注メニューに含める価値も見落とせません。自動診断ツールは多数の指摘を出しますが、その中には誤検知や、自社の運用では実害の小さいものも混ざります。これらを深刻度と対応要否で仕分けるには専門的な判断が要り、ここを任せられると、開発チームは「本当に直すべき指摘」だけに集中できます。診断そのものと同じくらい、結果の解釈を支援してくれるかどうかが、外注の実務的な価値を左右します。

手法の詳細は関連記事で補強する

依頼範囲を決めるには、各手法の中身をある程度理解しておく必要があります。とはいえ本記事は外注判断が主軸ですので、手法そのものを詳しく知りたい場合は関連記事を活用してください。

診断の全体像は脆弱性診断の基本と実践を体系的に確認することで、依頼範囲の解像度が上がります。侵入検証の中身についてはペネトレーションテストの実践手順を学ぶが参考になります。SAST/DASTを開発工程に組み込んで継続運用したい場合は、SASTを開発工程に組み込む方法を確認するで、ツール導入の勘所をつかんでおくと発注時の会話がスムーズになります。

依頼範囲とタイミングの決め方

外注で失敗しやすいのは「とりあえず全部見てほしい」と丸投げすることです。診断対象・診断深度・実施タイミングの3点を発注側で決めることが、費用と成果のバランスを取る鍵になります。すべてを最高深度で診断すれば安心ですが、費用も期間も膨らみ、現実の予算とスケジュールに収まりません。

依頼範囲は「守るべき資産」から逆算し、扱うデータの重要度が高い機能に診断を厚く配分するのが基本です。

診断対象と深度を決める判断軸

どこを、どこまで診断するかは、次の判断軸で決めていきます。

扱うデータの重要度: 決済情報・個人情報・認証情報を扱う機能は優先的に厚く診断する
公開範囲: インターネットに公開されるシステムは、内部システムより攻撃面が広い
変更の大きさ: 新規開発や大規模改修は、軽微な修正より診断価値が高い
契約・法令要件: クライアントの業界基準や委託契約で診断が明示されている範囲を満たす

たとえば決済機能とログイン機能を持つWebサービスであれば、その2機能とAPIを重点対象に据え、静的な情報ページは軽めの診断にとどめる、といったメリハリが有効です。限られた予算を、リスクの高い箇所へ集中させる発想が大切になります。

逆に、優先度づけをせずに全画面を一律の深度で診断しようとすると、費用が跳ね上がるわりに、本当に守るべき箇所への注力が薄まります。「守るべき資産は何か」をクライアントと合意しておくと、診断範囲の妥当性を後から説明しやすくなり、費用の根拠も明確になります。

タイミングは工程に分散させる

診断は開発の最後にまとめて行うより、工程に分散させたほうが手戻りを抑えられます。実施タイミングごとの狙いを整理します。

タイミング	適した診断	ねらい
設計・要件定義時	セキュリティ要件の確認	作り込み前に方針を固める
開発中（継続的）	SAST/DAST運用	早期に欠陥を検出する
結合〜総合テスト時	脆弱性診断	網羅的に穴を洗い出す
リリース直前	最終確認・再診断	修正済みを確定させる
運用開始後（定期）	定期診断	新たな脅威に追随する

リリース直前にすべてを詰め込むと、重大な指摘が出たときにスケジュールを守れなくなります。深刻な脆弱性ほど修正に時間がかかるため、診断は前倒しで計画するのが安全です。

依頼書に盛り込むべき項目

ベンダーに見積もりを依頼する際は、次の情報を整理して渡すと、精度の高い提案が返ってきます。

診断対象（URL・画面・API・IPの一覧と概数）
システムの概要（利用技術・認証方式・扱うデータ）
求める診断深度（ツール中心か、手動を含むか）
希望する実施時期と、リリース予定日
報告書の提出形式と、再診断の要否

テストの外注全般に共通する事前準備の考え方は、テスト代行を依頼する前の準備を確認するにまとまっており、診断依頼にもそのまま応用できます。準備が整っているほど、見積もりのばらつきが減り、比較検討が楽になります。

診断ベンダー選定で見るべき観点

診断の品質はベンダーによって差が出ます。価格だけで選ぶと、報告書が形式的で「結局どう直せばいいのか分からない」という事態になりがちです。選定は、診断力・報告品質・支援体制・信頼性の4軸で見ていきましょう。

ベンダー選定では、脆弱性を「見つける力」だけでなく「直し方まで示してくれる報告品質」を重視すべきです。

4軸で評価する

具体的な評価軸を整理します。

評価軸	確認するポイント	良い兆候
診断力	手動診断の比率・有資格者の在籍	ツール頼みでなく手動を併用
診断範囲の妥当性	見積もりの前提と対象の明確さ	対象と深度を文書で提示
報告品質	再現手順・深刻度・修正案の有無	開発者が直せる粒度で記載
支援体制	報告後の質疑・再診断の対応	修正後の確認までフォロー
信頼性・守秘	秘密保持・データ取り扱い	NDAと情報管理体制が明確
実績	類似システムの診断経験	同種案件の対応実績あり

見積もり受領時に確認すること

見積もりを受け取ったら、次の点を必ず確認してください。

診断対象（URL数・画面数・IP数など）の数え方が明示されているか
ツール診断と手動診断のどちらが中心か
報告書のサンプルを事前に見せてもらえるか
再診断（修正後の確認）が費用に含まれるか、別料金か
発見された脆弱性情報の管理・破棄の方法が定められているか

とくに報告書のサンプル確認は必須です。深刻度の判定基準（CVSSなどの指標）と、修正の優先度・具体的な対策まで書かれているかで、その後の社内対応の負荷が大きく変わります。指摘だけが並ぶ報告書と、再現手順と修正案が添えられた報告書とでは、開発チームの動きやすさがまるで違います。

契約の形態や責任範囲については、テスト外注の契約形態の違いを理解するが判断材料になります。準委任か請負かで、成果物や瑕疵の扱いが変わる点は診断でも同様です。診断は「実施すること」自体を約束する準委任型が多い一方、成果の定義をどう契約に落とすかは事前に確認しておきましょう。

選定でありがちな失敗

選定を急ぐと、次のような失敗に陥りやすくなります。事前に知っておけば回避できるものばかりです。

価格だけで決める: 安さの裏でツール診断のみになっており、手動でしか見つからない脆弱性を見逃す
報告書を見ずに契約する: 納品後に「指摘の羅列だけで直し方が分からない」と気づく
再診断を見落とす: 修正後の確認が別料金と後から判明し、予算とスケジュールが崩れる
守秘の取り決めを軽視する: 診断で得た脆弱性情報の管理・破棄の条件が曖昧なまま進める

これらは、見積もり段階で「報告書サンプルの確認」「手動診断の比率」「再診断の扱い」「情報管理の条件」を質問すれば、ほぼ防げます。質問への回答が具体的で明快なベンダーほど、実務でも安心して任せられる傾向があります。

第三者の物差しを持つ

ベンダーの提案を評価するには、発注側にも判断の物差しが必要です。IPAが公開する「安全なウェブサイトの作り方」は、診断で確認すべき代表的な脆弱性の考え方を押さえるうえで有用な公的資料です。SQLインジェクションやクロスサイトスクリプティングといった典型的な脆弱性が、提案の診断範囲にきちんと含まれているかを確かめる基準として活用できます。ベンダーがどこまでの脅威を想定しているかを見極めれば、提案の厚みを客観的に比較できます。

脆弱性診断の外注にかかる費用の考え方

費用は診断対象の規模と深度で大きく変動します。ここでは正確な相場を断定するのではなく、見積もりの構造を理解して比較できるようになることを目的に、あくまで試算の考え方を示します。実際の金額は対象や条件で変わるため、以下は考え方の例として捉えてください。

費用は「対象の量（画面数・IP数）×診断の深さ（ツールか手動か）」で決まると理解すると、見積もりの妥当性を判断しやすくなります。

費用を左右する要素

費用を左右する主な要素は次のとおりです。

費用要素	内容	費用への影響
診断対象の量	画面数・API数・IP数	量に比例して増える
診断の深度	ツール中心か手動中心か	手動が増えるほど高い
診断の種類	脆弱性診断かペネトレーションか	シナリオ型は工数大
再診断の要否	修正後の再確認を含むか	含むと総額が上がる
報告の詳細度	概要のみか詳細な対策込みか	詳細なほど工数増

見積もりを比較するときは、総額だけでなく「1画面あたり」「1IPあたり」の単価に分解すると、各社の前提の違いが見えてきます。たとえばA社とB社で総額が近くても、対象画面数が倍違えば実質単価は大きく異なります。極端に安い見積もりは、ツール自動診断のみで手動診断を含まない可能性があるため、内訳の確認が欠かせません。

上長・クライアントへの費用説明

上長や経営者に費用を説明する際は、「診断しない場合のリスク」との対比で語ると納得を得やすくなります。個人情報の漏えいやサービス停止が起きた場合、復旧費用・損害賠償・信用の毀損まで含めれば、影響は診断費用とは比較にならない規模になり得ます。

事前診断の費用は「保険」ではなく「事故を未然に防ぐ投資」と位置づける
クライアントが診断を契約条件にしている場合は、受注継続の前提コストとして説明する
定期診断は、一度きりの出費ではなく運用コストとして予算化する

過去に本番障害でクライアントの信頼を損なった経験があるなら、その再発防止という文脈で説明すると、費用対効果が伝わりやすくなります。

なお、費用を抑えたいなら対象を絞る、深度を段階的にする、といった調整が可能です。すべてを一度に最高深度で診断するのではなく、リスクの高い機能から着手し、次の改修に合わせて対象を広げていく進め方もあります。予算とリスクのバランスは、ベンダーに相談すれば診断範囲の調整案を提示してくれるはずです。丸ごと諦めるのではなく、優先順位をつけて着実に始めることが大切です。

診断結果を受け取った後の社内対応

外注は「診断報告書を受け取って終わり」ではありません。受け取った指摘を、いかに修正へつなげるかが本当の勝負です。ここが弱いと、せっかくの診断が「指摘リストを眺めるだけ」で終わってしまいます。

診断結果は、トリアージ→修正→再診断のサイクルで初めて価値に変わります。報告書の受領はゴールではなくスタートです。

受領後の対応ステップ

受領後の対応は、次のステップで進めるのが基本です。

STEP1 トリアージ: 指摘を深刻度と対応要否で仕分ける。誤検知や許容リスクを見極める
STEP2 優先順位づけ: 深刻度が高く、悪用されやすいものから着手する
STEP3 修正計画: 誰が・いつ・どう直すかを決め、スケジュールに組み込む
STEP4 修正実施: 開発チームが対策を実装する
STEP5 再診断: 修正が有効かをベンダーに再確認してもらう

深刻度の判断に迷ったら、公的な情報源を参照しましょう。「OWASP Top Ten」は代表的なWebアプリの重大リスクを体系化しており、優先度づけの共通言語になります。個別の脆弱性情報は「JVN（Japan Vulnerability Notes）」で公開情報を確認でき、自社が使うライブラリやミドルウェアに関わる情報の追跡にも役立ちます。

トリアージも外注できる

トリアージをベンダーに任せる選択も有効です。社内に判断できる人材がいない場合、報告書に「対応必須・推奨・任意」の区分と修正案が付いていれば、開発チームは実装に集中できます。再診断まで含めて契約しておくと、「直したつもりが直っていない」というリリース直前の事故を防げます。

再診断のタイミングも計画に織り込んでおきましょう。修正には想定以上の時間がかかることがあり、再診断とその後の是正まで見込むと、初回診断からリリースまでに一定の余裕が必要です。リリース日から逆算して、初回診断・修正・再診断のスケジュールを引いておけば、指摘が出ても慌てずに対応できます。ここを詰めておくことが、納期を守りながら品質も担保する現実的な進め方になります。

診断結果を継続的な品質向上につなげる

修正の一部は、開発チームの通常のテスト工程に統合できます。診断で見つかった観点をテストケース化しておけば、次の改修時にも同種の脆弱性の再発を防げます。たとえば入力値の検証漏れが指摘されたなら、その観点を結合テストのチェック項目に加える、といった具合です。

一度の診断で終わらせず、見つかった弱点のパターンを社内の知見として蓄積していくことで、外注コストを将来の内製品質の底上げに変えられます。外注チームとの連携を単発で終わらせない姿勢が、長期的な品質改善につながります。

たとえば、複数案件で同じ種類の指摘が繰り返されるなら、それは設計や実装の標準に組み込むべきサインです。診断結果を「その案件限りの是正」で終わらせず、社内のコーディング規約やレビュー観点へ反映すれば、次の案件では最初から同じ穴を作らずに済みます。こうして診断への投資を、案件をまたいだ品質資産に育てていくのが理想的な向き合い方です。

外注を検討する際のよくある疑問

最後に、依頼を検討する段階でよく挙がる疑問を整理します。多くのPMが同じ迷いにぶつかるポイントです。

小規模な案件でも診断は必要か
脆弱性診断とペネトレーションテストのどちらを頼むか
重大な指摘が出たらリリースを延期すべきか
一度診断すれば当面は安心か

診断の要否は案件の規模ではなく「扱うデータの重要度」で判断するのが、費用と安心のバランスを取る出発点です。

Q. 小規模な受託案件でも診断は必要ですか。 規模の大小より「扱うデータの重要度」で判断します。個人情報や決済情報を扱うなら、規模が小さくても診断の価値は高いといえます。対象を重要機能に絞れば、費用も現実的な範囲に収められます。

Q. 脆弱性診断とペネトレーションテストはどちらを頼めばよいですか。 まずは網羅的な脆弱性診断を土台にするのが一般的です。機密性が特に高いシステムや、実際の侵入耐性を確認したい場合に、ペネトレーションテストを追加で検討します。

Q. 診断で重大な指摘が出たらリリースは延期すべきですか。 深刻度と悪用のされやすさで判断します。悪用が容易な重大脆弱性は、修正・再診断を経てからのリリースが原則です。判断基準を事前にクライアントと合意しておくと、いざというときに揉めません。

Q. 一度診断すれば当面は安心ですか。 新たな脆弱性は日々公開されるため、システムを変更したときや、一定期間ごとの定期診断を検討するのが安全です。利用しているライブラリやミドルウェアに新たな脆弱性が見つかることもあり、一度の診断結果が永続的に有効なわけではありません。

Q. 社内にセキュリティの知識がなくても依頼できますか。 可能です。むしろ社内に専門家がいないからこそ外注する意義があります。ただし「守るべき資産は何か」「クライアントが求める要件は何か」を整理して伝える役割は残ります。この部分をベンダーと一緒に言語化していけば、知識がなくても適切な診断範囲にたどり着けます。