脆弱性診断の外部委託｜開発会社と専門会社どちらに頼む？選び方と依頼の流れ

「脆弱性診断はやることになった。でも、どこに頼めばいいのか分からない」——そんな状態で手が止まっていないでしょうか。開発を委託した会社から「うちでも診断できますよ」と言われたものの、自社サービスを作った当事者が自分でチェックして本当に客観的な結果が出るのか、疑問が拭えない。かといって診断専門の会社に別途頼むと、手間もコストも増えそうで判断がつかない。

脆弱性診断の委託がやっかいなのは、発注者側にセキュリティの専門知識がないまま、委託先選びと進行を自分で主導しなければならない点です。ツール診断と手動診断の違い、報告書の読み方、再診断の要否といった判断材料を持たないまま、見積もりを並べても「どこが信頼できるのか」が見分けられません。間違った委託先を選んでしまえば、せっかくの費用と時間が無駄になります。

この不安の正体は、実は3つの分岐に分けて整理できます。「誰に頼むか（開発会社か専門会社か）」「どの会社を選ぶか（複数候補の見極め）」「どう進めるか（依頼から報告書まで）」です。この3つを順に押さえていけば、専門知識がなくても自社の状況に合った判断ができるようになります。

本記事では、脆弱性診断を外部委託する発注者の視点に立ち、開発会社と専門会社のどちらに頼むべきかの判断軸、委託先を比較するときの物差し、そして依頼の準備から報告書受領・再診断までの流れを、特定のサービスを勧めることなく中立的に解説します。読み終えるころには、次の打ち合わせで委託先候補に的確な質問ができ、報告書を受け取った後の動き方まで見通せる状態になっているはずです。

脆弱性診断を外部委託する前に｜発注者がまず押さえる全体像

外部委託で発注者が頼むのは「攻撃者視点の客観チェック」業務

脆弱性診断を外部委託するというのは、ひとことで言えば「自社のWebサービスや業務システムに、攻撃者に悪用されかねない弱点（脆弱性）が残っていないかを、外部の専門家に攻撃者と同じ視点で点検してもらう」業務を頼むことです。診断員は、実際の攻撃で使われる手法を用いてシステムの入口や設定を確認し、SQLインジェクションやクロスサイトスクリプティングといった代表的な弱点が存在しないかを洗い出します。

ここで発注者が押さえておきたいのは、診断は「やって終わり」ではなく、見つかった弱点を一覧化した報告書を受け取り、優先度をつけて修正し、必要なら修正後に再診断する、という一連の流れになるという点です。つまり委託先を選ぶときも、「診断そのものの腕前」だけでなく「報告書の分かりやすさ」や「修正・再診断までのサポート」まで含めて見ておく必要があります。

なお、脆弱性診断そのものの基礎知識、費用相場、そして「そもそも自社でやるべきか」という判断については本記事では深追いしません。その部分を整理したい場合は、脆弱性診断とは（費用相場・やるべきか）を先に読んでおくと、本記事の内容がより腑に落ちるはずです。

委託でつまずく3つの分岐（誰に・どこに・どう進めるか）

脆弱性診断の委託を進めようとすると、発注者は次の3つの場面で必ず立ち止まります。これが「何から考えればいいか分からない」という迷いの正体です。

• 誰に頼むか: 開発を委託した会社にそのまま診断もまとめて頼むのか、それとも開発とは別の独立した診断会社に頼むのか。第三者性（客観性）をどこまで重視するかという最初の分岐です。
• どこを選ぶか: 複数の委託先候補が出てきたとき、何を物差しに比較すればよいのか。実績・資格・診断手法・報告書の質・サポート・費用など、見るべき軸が分からないと比較になりません。
• どう進めるか: 依頼を決めたあと、何を準備し、どんな順番で進み、報告書をどう受け取り、見つかった弱点にどう対処すればよいのか。進行のイメージが持てないと、打ち合わせを主導できません。

本記事はこのあと、この3つの分岐を順番に解きほぐしていきます。まずは多くの発注者が最初に迷う「誰に頼むか」、つまり開発会社と専門会社の選択から見ていきましょう。

開発会社に頼むか、独立した診断会社に頼むか｜第三者性で迷わないために

脆弱性診断の委託で発注者が最初にぶつかるのが、「システムを作ってくれた開発会社に診断もまとめて頼んでよいのか」という問いです。開発会社から「うちでも診断できます」と提案されると、窓口が一本化されて楽そうに見えます。一方で、「自分が作ったものを自分でチェックして、本当に客観的な結果になるのか」という直感的な引っかかりも生まれます。この引っかかりは、実は的を射ています。

開発会社にまとめて頼む場合のメリット・デメリット

開発を委託した会社に診断もまとめて依頼する方法には、進めやすさの面で確かな利点があります。一方で、客観性という面では構造的な弱点を抱えます。両面を整理しておきましょう。

最大の論点は「客観性（第三者性）」と「利益相反」です。作った本人は、設計段階で前提とした考え方の枠内でシステムを見てしまうため、その前提自体に潜む弱点に気づきにくくなります。さらに、自分たちの納品物の欠陥を自ら厳しく指摘するのは、心理的にも商業的にもハードルがあります。これは個々の開発会社の誠実さの問題というより、「作り手が自ら診断する」という構造そのものに内在する限界です。

独立した診断会社に頼む場合のメリット・デメリット

開発とは切り離された専門会社に依頼する方法は、客観性と専門性で勝りますが、その分の手間が発生します。

独立した診断会社の最大の価値は、「忖度のない客観的な指摘が得られる」点にあります。診断結果が取引先・監査・投資家といった社外の第三者に示される場面では、この客観性が信頼性を大きく左右します。

第三者性が重要になるケースと自社の選び方

どちらが正解ということではなく、自社の状況によって向き不向きが変わります。次のような場合は、第三者性を重視して独立した診断会社（または少なくとも開発とは別チームによる診断）を選ぶ判断が合理的です。

• 取引先や顧客から診断結果の提出を求められている: 大企業との取引や入札の条件として、第三者による診断レポートの提示を求められるケースが増えています。作り手自身の診断では客観性を疑われかねません。
• 監査・認証への対応が必要: ISMS（ISO 27001）などの認証取得・維持や、各種監査の文脈では、独立した立場での点検が説得力を持ちます。
• 上場準備・資金調達のデューデリジェンス: 投資家や監査法人に対して、セキュリティ体制を客観的に示す必要がある場面です。
• 過去に開発会社の品質に不安を感じたことがある: 作り手とは別の目で確かめたいという動機が明確な場合。

逆に、社内の小規模な業務システムで外部公開もなく、まずは大まかに弱点の有無を把握したいという段階であれば、仕様を熟知した開発会社に手早く頼む選択にも合理性があります。

判断のコツは、「この診断結果を、誰に見せる必要があるか」を起点に考えることです。社外の誰かに客観性を示す必要があるなら第三者性を優先し、あくまで社内の自己点検が目的なら進めやすさを優先する。この基準で考えると、開発会社か専門会社かの迷いはかなり整理されます。

なお、開発会社にまとめて頼む場合でも、「開発チームとは別の診断専門チームが担当する」体制が社内に分かれている会社なら、一定の客観性は確保できます。打ち合わせの際に「診断は開発担当とは別のチームが行うのか」を確認しておくとよいでしょう。

脆弱性診断の委託先の選び方｜失敗しない比較の判断軸

「誰に頼むか」の方向が定まったら、次は複数の委託先候補を比較する段階です。専門知識がないと「どこも同じように見える」状態に陥りがちですが、見るべき物差しを持っていれば見極められます。ここでは発注者がそのまま使える7つの判断軸と、打ち合わせで投げかける質問例をセットで紹介します。

実績・診断員の専門性・資格を確認する

まず確認したいのは、自社のシステムと近いものを診断した実績があるかです。Webアプリケーションの診断、スマートフォンアプリの診断、ネットワーク機器の診断では必要なノウハウが異なります。自社が診断してほしい対象と同種の実績があるかを尋ねましょう。

診断員のスキルを推し量る客観的な材料として、保有資格も参考になります。代表的なものに、攻撃手法の実践力を問う「OSCP（Offensive Security Certified Professional）」や、情報セキュリティ全般の知識を問う「CISSP」、国家資格の「情報処理安全確保支援士（登録セキスペ）」などがあります。資格がすべてではありませんが、「どんな資格を持つ診断員が担当するのか」は確認しておく価値があります。

• 打ち合わせでの質問例: 「当社と同じような（Webサービス／業務システム）の診断実績はどのくらいありますか」「実際に診断を担当するのはどういう経験・資格を持った方ですか」

ツール診断と手動診断の対応範囲を確認する

脆弱性診断には、大きく分けて「ツール診断（自動診断）」と「手動診断」があります。ツール診断は専用ソフトで機械的に既知の弱点をスキャンする方法で、広い範囲を低コスト・短時間で確認できます。一方、手動診断は熟練の診断員が実際に手を動かして、ツールでは見つけにくい複雑な弱点やビジネスロジックの欠陥（例: 本来アクセスできないはずの他人のデータが閲覧できてしまう、といった仕様上の穴）を探します。

どちらが優れているという話ではなく、対象や目的によって組み合わせが変わります。重要な決済機能や個人情報を扱う画面は手動診断を厚くする、というように、自社のリスクに応じた配分が必要です。候補の会社が「どの範囲をツールで、どの範囲を手動で診断するのか」を明確に説明できるかを見極めましょう。

なお、より攻撃者の視点に踏み込んで「実際に侵入できるか」を検証するペネトレーションテストという手法もあります。通常の脆弱性診断との違いや、どちらが自社に必要かを掘り下げたい場合は、ペネトレーションテストとセキュリティ診断の違いも参考になります。

• 打ち合わせでの質問例: 「診断はツールと手動のどちらが中心ですか。対象画面のうち、どこを手動で見てもらえますか」

公的な客観材料（IPA適合サービスリスト）を活用する

委託先の信頼性を、自社の主観だけでなく公的な基準で確認する方法があります。それが、独立行政法人 情報処理推進機構（IPA）が公開している「情報セキュリティサービス基準適合サービスリスト」です。これは経済産業省が定めた「情報セキュリティサービス基準」に適合していると審査されたサービスを、IPAが取りまとめて公開しているもので、脆弱性診断サービスもカテゴリのひとつとして掲載されています（IPA 情報セキュリティサービス基準適合サービスリスト）。

このリストに掲載されているということは、品質管理体制や診断員の技術力について第三者の審査を通過している、という客観的な目安になります。候補の会社の名前がリストにあるかを確認し、なければ「掲載状況はどうか」を尋ねてみるとよいでしょう。ただし、掲載がないことが直ちに品質の低さを意味するわけではない点には注意が必要です。あくまで判断材料のひとつとして活用するのが適切です。

• 打ち合わせでの質問例: 「御社のサービスはIPAの情報セキュリティサービス基準適合サービスリストに掲載されていますか」

報告書サンプル・サポート・費用の内訳を比較する

最後に、診断後に手元に残る「報告書」と、その後の「サポート」、そして「費用」を比較します。発注者にとって、報告書は診断の成果物そのものです。サンプルを見せてもらい、専門知識がない自分でも「何が・どれくらい危険で・どう直せばよいか」が読み取れるかを確認しましょう。深刻度のランク付けがあるか、修正の具体的なアドバイスが書かれているかが見極めのポイントです。

サポート面では、見つかった弱点について質問できる窓口があるか、修正後の再診断が含まれるか（または追加費用でどの程度の範囲をカバーできるか）を確認します。費用については総額だけでなく、「何が含まれていて、何が追加になるのか」の内訳の明瞭さを比べましょう。極端に安い見積もりは、診断範囲が狭かったり手動診断が含まれていなかったりすることがあります。

• 打ち合わせでの質問例: 「報告書のサンプルを見せてもらえますか」「再診断は費用に含まれますか、別料金の場合いくらですか」「見積もりに含まれる範囲と、追加になる項目を教えてください」

ここまでの7つの軸を整理すると、次のようになります。

脆弱性診断を依頼する流れ｜準備から報告書・再診断まで

委託先の見極め方が分かったら、最後は「依頼してから何が起きるのか」の全体像です。流れが見通せていれば、打ち合わせを主導し、各段階で自社がやるべきことを先回りで準備できます。脆弱性診断の依頼は、おおむね次の順序で進みます。

依頼前の準備｜目的・対象範囲・自社が用意する情報

最初にやるべきは、「何のために・どこを診断するか」を自社側で言語化することです。ここが曖昧だと、見積もりも各社バラバラになり比較できません。具体的には次の情報を整理しておくと、見積もり依頼がスムーズになります。

• 診断の目的: リリース前の点検なのか、定期的な健康診断なのか、取引先への提出が目的なのか
• 診断の対象範囲: 診断してほしいシステムのURL、画面数や機能の数、診断対象に含める範囲と含めない範囲
• 環境: 本番環境を診断するのか、テスト環境（検証環境）を用意できるのか。テスト用のログインアカウントを発行できるか
• タイミングの制約: 診断を実施してよい時間帯（アクセスが集中する時間を避けたい等）、希望する完了時期

これらをまとめておくと、複数社に同じ条件で見積もりを依頼でき、提案内容を横並びで比較できます。範囲を伝えるのが難しい場合は、画面遷移図やシステム構成のメモを用意し、打ち合わせで委託先候補と一緒に範囲を詰めていく形でも構いません。

見積・提案の比較と契約時の確認観点

整理した条件をもとに、複数社から見積もりと提案を取得します。先ほどの7つの判断軸を物差しに、費用だけでなく診断範囲・手法・報告書・サポートを総合的に比較しましょう。

契約段階では、委託契約ならではの確認観点があります。診断作業では委託先が自社システムの内部情報に触れるため、秘密保持（NDA）の取り決め、取得したデータの取り扱いと作業後の廃棄、再委託（孫請け）の可否などを契約書で確認しておくと安心です。本記事では契約条項の詳細までは踏み込みませんが、システム開発を外注する際のセキュリティ条項全般についてはシステム開発の外注契約で押さえる情報セキュリティ条項に整理がありますので、契約書を読み込む前に目を通しておくとよいでしょう。

診断実施中の発注者の役割

契約とスケジュール調整が済むと、診断が始まります。実施中の発注者の役割は、診断を「滞りなく進められる状態」に保つことです。診断員からテスト用アカウントの追加発行や仕様の確認を求められたら速やかに対応する、診断中にシステムの動作に異変があれば連携する、といったやり取りが発生します。社内の開発・運用担当者に診断期間をあらかじめ共有しておくと、診断による一時的なアクセス増加などに慌てずに済みます。

報告書の読み方｜サマリ・深刻度ランク・改善の優先順位

診断が終わると、結果をまとめた報告書を受け取ります。良い報告書はたいてい二層構造になっています。ひとつは経営層や発注担当向けの「サマリ（総評）」で、全体としてどの程度のリスクがあるかを平易にまとめた部分。もうひとつは開発・運用担当向けの「詳細」で、見つかった個々の弱点と再現手順・修正方法が技術的に記述された部分です。

発注者がまず見るべきはサマリと、各弱点に付けられた「深刻度のランク」です。深刻度は「緊急（Critical）／高（High）／中（Medium）／低（Low）」のように段階で示されるのが一般的で、これが修正の優先順位を決める判断材料になります。すべての弱点を一度に直す必要はなく、深刻度が高く悪用されやすいものから対処するのが現実的です。報告書を読むときは、「どの弱点が、どれくらい危険で、どう直せばよいか」が読み取れるかを確認し、分からない箇所は遠慮なく委託先に質問しましょう。報告会（説明会）を設けてくれる会社であれば、その場で疑問を解消できます。

修正対応と再診断の判断

報告書を受け取ったら、深刻度の高い弱点から修正に着手します。修正は、開発を担当した会社が行うのが一般的です（診断と開発を別会社に分けている場合は、診断会社の報告書を開発会社に渡して修正を依頼する形になります）。

修正が完了したら、「本当に直っているか」を確かめる再診断を検討します。特に深刻度の高い弱点については、修正によって新たな問題が生じていないかも含めて再確認する価値があります。再診断が当初の費用に含まれているか、別料金かは委託前に確認しておくべきポイントです。すべての弱点に再診断が必須というわけではなく、リスクの大きさと費用のバランスで判断します。この一連の流れ——準備・依頼・診断・報告書・修正・再診断——を一度経験すると、次回以降の定期診断はずっとスムーズに進められるようになります。

委託前のチェックリスト｜失敗しない発注のために

ここまでの判断軸と流れを、打ち合わせにそのまま持ち込めるチェックリストにまとめます。3つのグループに分けてあるので、委託先選定・依頼準備・報告書受領の各段階で活用してください。

委託先候補に確認するチェック項目

• 自社と同種のシステム（Webサービス／業務システム／アプリ等）の診断実績があるか
• 実際に診断を担当する診断員の経験・保有資格を確認したか
• ツール診断と手動診断の対応範囲を、自社のリスクに応じて説明してもらえるか
• IPAの情報セキュリティサービス基準適合サービスリストへの掲載状況を確認したか
• 報告書のサンプルを見せてもらい、専門知識がなくても読めるか確認したか
• 再診断の有無と範囲（含まれるか／別料金か）を確認したか
• 見積もりに含まれる範囲と追加になる項目が明瞭か
• （開発会社にまとめて頼む場合）診断は開発担当とは別のチームが行うか
• 秘密保持・取得データの取り扱い・再委託の可否を契約で確認できるか

依頼前に自社が準備するチェック項目

• 診断の目的を言語化したか（リリース前点検／定期診断／取引先提出 等）
• 診断対象の範囲（URL・画面数・含める範囲と含めない範囲）を整理したか
• 本番環境かテスト環境か、テスト用アカウントを発行できるか決めたか
• 診断を実施してよい時間帯・希望する完了時期を整理したか
• 社内の開発・運用担当者に診断期間を共有する段取りをつけたか

報告書を受け取った後のチェック項目

• サマリ（総評）で全体のリスク水準を把握したか
• 各弱点の深刻度ランクを確認し、修正の優先順位を決めたか
• 分からない箇所を委託先に質問・確認したか
• 深刻度の高い弱点から修正に着手する計画を立てたか
• 修正後の再診断の要否を、リスクと費用のバランスで判断したか

まとめ｜自社に合った委託先を選び、自信を持って依頼を進める

脆弱性診断の外部委託でつまずく原因は、「誰に・どこに・どう進めるか」という3つの分岐が整理できていないことにありました。本記事の要点を振り返ります。

• 誰に頼むか: 開発会社にまとめて頼むと進めやすい一方、作り手が自ら診断する構造には客観性の限界があります。診断結果を社外（取引先・監査・投資家）に示す必要があるなら、第三者性を重視して独立した診断会社を選ぶのが合理的です。「この診断結果を誰に見せるか」を起点に判断しましょう。
• どこを選ぶか: 実績・診断員の専門性・ツールと手動の対応範囲・IPA適合サービスリスト・報告書の質・サポート・費用の内訳という7つの軸で比較します。各軸に対応する質問を打ち合わせで投げかければ、専門知識がなくても見極められます。
• どう進めるか: 目的と対象範囲の整理から始め、見積比較・契約・診断・報告書受領・修正・再診断へと進みます。各段階で自社がやることを把握しておけば、進行を主導できます。

専門知識がなくても、判断軸とチェックリストという物差しさえあれば、委託先選びと依頼の進行は十分に自分でコントロールできます。次の打ち合わせでは、本記事のチェックリストを手元に置き、候補の会社に的確な質問を投げかけてみてください。

脆弱性診断そのものの費用相場や「自社が今やるべきか」という判断に立ち返りたい場合は脆弱性診断とは（費用相場・やるべきか）を、委託契約で押さえるセキュリティ条項を確認したい場合はシステム開発の外注契約で押さえる情報セキュリティ条項をあわせてご覧ください。