セキュリティ診断（脆弱性診断）の発注ガイド｜種類・費用・会社選びの全体像

セキュリティ診断の発注は、診断の目的と対象範囲を定め、同じ仕様で見積条件を揃えてから確認先を選ぶと進めやすくなります。最初に金額や診断名だけを比べるのではなく、何を守りたいのか、どの資産をどこまで確認するのかを社内で言語化することが出発点です。

Webサイト、SaaS、ECなどを運営していると、取引先からの確認、サービス変更、事故後の再発防止といったきっかけで診断の検討が始まります。この記事では、発注者が仕様を整理し、確認材料を集め、依頼の準備へ進むための順番を説明します。

発注前に決めること

発注前に決めることは、診断の目的、管理下にある資産、実施期限、社内で確認する担当を先に揃えることです。ここが曖昧なまま依頼すると、見積書ごとに対象や成果物が変わり、総額の違いを読み取りにくくなります。

発注の目的を取引先要請・制度対応・再発防止に分ける

発注目的は、一つの言葉にまとめず、背景ごとに分けて記録します。たとえば取引先から確認を受けた場合は、質問項目のどこに診断や報告が関係するかを確認します。制度や民間の基準への対応を背景にする場合も、診断自体が当然に必要なのか、対象範囲の説明が必要なのかを切り分けます。

再発防止が目的なら、過去に起きた事象の再現手順を依頼内容に書くのではなく、影響を受けた機能、扱うデータ、変更済みの箇所を整理します。目的が明確になると、依頼先に必要な成果物や説明の深さを伝えやすくなり、関係者が同じ判断軸で見積を確認できます。

目的ごとに、発注の完了を何で確認するかも決めておきます。取引先への説明が必要なら、対象範囲と報告書に記す事項を確認します。再発防止を重視するなら、改修後にどの範囲を確認するか、報告会で誰が説明を受けるかまでを仕様に含めます。目的と成果物の関係が見えると、依頼先への質問も具体的になります。

社内の決裁や契約更新の時期がある場合は、目的に加えて判断が必要になる日も記録します。期限だけを先に置くのではなく、その日までに対象確認、承諾、見積比較のどこまでを終えるかに分けると、準備の遅れを見つけやすくなります。

管理下の資産と依頼範囲を先に整理する

診断対象には、自社が運営する画面やサーバだけでなく、認証後の機能、連携に関わる入口、委託先が管理する領域が含まれることがあります。資産名だけを列挙するのではなく、誰が管理し、対象に含めるかを決められる立場にあるかまで確認します。利用しているだけの外部サービスを、自社の判断だけで対象へ入れないことも大切です。

依頼範囲は、対象にする資産、対象外にする資産、実施できる時間帯、連絡方法を文書で残します。こうしておくと、依頼先が作業を始める前に前提を確認でき、稼働中のサービスへの影響を避けるための調整にもつながります。後から対象を追加する必要が出た場合も、当初の仕様との差分として扱えます。

資産の一覧は、運用担当だけが理解できる名称ではなく、業務上の役割も併記すると共有しやすくなります。たとえば申込み、決済、管理、外部連携といった機能の位置づけが分かれば、事業部門と技術担当が同じ対象を指しているかを確認できます。対象外にした領域も理由とともに残し、将来の変更時に見直せるようにします。

対象の管理者が複数いる場合は、誰が範囲の確認を担うかを先に決めます。連携先を含む場合は、入口と接続先を一つの対象として扱わず、それぞれの管理範囲を分けて記録することで、承諾確認の漏れを防げます。

診断の種類と対象範囲を分ける

診断の種類と対象範囲は別々に決めるべき項目です。種類は何を確かめたいかの整理に役立ち、対象範囲はどの資産、機能、境界まで確認するかを定めるため、片方だけでは発注仕様になりません。

Webアプリとプラットフォームの対象単位を混同しない

Webアプリケーションの診断では、画面や機能、認証後に利用する領域、連携する機能などが対象条件になります。一方、プラットフォームの診断では、IP、ホスト、ネットワークの境界、外部公開の有無といった条件を整理します。どちらもセキュリティを確認する依頼ですが、対象の数え方と必要な資料は同じではありません。

同じ案件で両方を検討する場合も、画面数とIP数を一つの数値にまとめず、別の欄に分けます。Webアプリの画面が多いことと、ネットワーク上のホストが多いことは異なる条件だからです。対象単位を分けておけば、どの範囲にどの確認を求めるのかを、見積書と成果物で追えるようになります。

対象を数える前には、公開中か、認証後に使うか、運用を停止できるかといった状態も確認します。同じ画面でも利用者区分や扱う情報が異なれば、発注時に確認したい内容が変わる場合があります。数だけを先に確定させるより、対象の定義と根拠資料をそろえてから数えることで、依頼後の追加や除外を説明しやすくなります。

見積書に使う単位と社内の資産台帳の単位が異なる場合は、対応関係を別表に残します。画面、機能、IP、ホストのどれがどの範囲を指すのかを追える状態にすれば、依頼先からの確認にも一貫して答えられます。

ペネトレーションテストは目的で検討する

ペネトレーションテストは、名称だけでWebアプリやプラットフォームの診断と置き換えるものではありません。想定した目的に対して、どの範囲をどの条件で検証したいかを先に定めます。確認したいのが弱点の把握なのか、特定の業務や経路に関する検証なのかで、依頼範囲や成果物の確認点が変わります。

IPA「情報セキュリティサービス基準適合サービスリスト」では、ペネトレーションテスト（侵入試験）サービスは脆弱性診断サービスのオプションとして扱われています。二者択一と決めつけず、対象資産、検証目的、承諾の範囲を整理し、必要な組み合わせを検討します。掲載状況は確認材料の一つであり、個別の発注判断そのものではありません。2026-09-11確認。

依頼時には、検証したい目的を短い文で示したうえで、対象となる資産、実施できない範囲、想定する成果物を対応付けます。目的が広すぎると対象範囲も広がり、関係者の承諾や調整に時間がかかります。反対に目的が狭すぎると、必要な説明が成果物に残らないことがあります。社内の利用場面から必要な検証を言語化することが重要です。

検討段階で実施方法の細部まで決める必要はありませんが、目的と対象の組み合わせは曖昧にしません。依頼先との会話では、何を確認したいかを共有し、管理下にない領域へ範囲が及ばないように前提を確かめます。

同一仕様で見積を比較する

同一仕様で見積を比較するとは、総額の前に対象数から報告会までの条件を同じ欄に記録することです。依頼先ごとに対象や成果物が違う状態では、金額の差が診断範囲の差なのか、作業方法の差なのかを判断できません。

対象数から報告会までの6軸を記録する

同一仕様シートでは、対象数、診断深度、手動比率、認証後画面、再診断条件、報告会の有無を、すべての依頼先について同じ順番で記録します。各欄に「含む」「含まない」だけを書くのではなく、対象の定義、回数、期限、成果物との関係が分かる表現にします。空欄は条件がないことを示すのではなく、未確認である可能性があるためです。

確認途中で条件が変わったときは、元の内容を消すよりも、変更した日と理由を社内の比較表に残すと役立ちます。見積を依頼する前にこのシートを共有すれば、条件に関する質問を早めに集められます。受け取った後も、総額を見る前に六つの欄を順に読み、差分がある場合は回答を確認してから比較します。

六つの軸は、どの依頼先にも同じ作業を求めるための定型文ではありません。自社の対象に照らして不要な欄がある場合も、その欄を不要とした理由を残します。逆に、重要な条件が六つの軸に収まらない場合は、追加の確認欄を作ります。比較表の目的は選択肢を機械的に順位付けすることではなく、条件差を可視化することです。

比較表を社内で共有する際は、記入した内容と未確認の内容を見分けられるようにします。未確認の欄を仮の条件で埋めると、後の判断で事実と推測が混ざります。質問事項として残すことも、比較の精度を保つための作業です。

発注先の確認から実施準備まで進める

発注先の確認から実施準備までは、公的リストの区分を確認し、仕様を渡せる状態にしてから依頼範囲と連絡方法を確定する流れです。リストを見つけることと、実施条件を整えることは別の作業として進めます。

公的リストの区分と見積依頼前の資料を確認する

発注先を探す際は、IPAが公表する情報セキュリティサービス基準適合サービスリストで、脆弱性診断サービスやペネトレーションテスト（侵入試験）サービスなどの区分を確認できます。リストは、どのようなサービス区分があるかを把握する入口です。リストへの掲載は「IPAによるいかなる保証等をも意味するものではありません」と明記されているため、掲載だけを発注の結論にせず、依頼範囲と見積条件を別途確認します。2026-09-11確認。

見積依頼前には、対象一覧、利用者区分、連携の有無、希望する成果物、実施上の制約を準備します。相手に渡す資料は必要な範囲に絞り、管理者の確認が必要な情報は社内の決め方に従います。依頼後の質問に答えられる担当と、対象変更を判断する担当を分けておくと、準備中の連絡が滞りにくくなります。

実施準備では、通常時の連絡先だけでなく、予定外の影響が疑われる場合に誰が判断するかも確認します。これは診断の手順を依頼先に任せるためではなく、発注者側が対象と制約を管理するための準備です。資料の更新版を渡す場合は、どの一覧が最新かを関係者で共有し、以前の条件と混ざらないようにします。

準備が整った後も、対象変更や新しい連携が生じたときは、見積時の仕様に戻って差分を確認します。変更点を早めに共有すれば、対象外のまま進めるのか、条件を見直すのかを、関係者と同じ資料で判断できます。

よくある質問

どの診断から検討すればよいか

まず診断したい資産と目的を整理し、Webアプリケーション、プラットフォーム、ペネトレーションテストの役割を分けて検討します。ペネトレーションテストはIPAのリストで脆弱性診断サービスのオプションとして扱われているため、対象と検証目的を確認して組み合わせを決めます（出典: IPA「情報セキュリティサービス基準適合サービスリスト」、2026-09-11確認）。

複数の見積で確認する項目は何か

対象数、診断深度、手動比率、認証後画面、再診断条件、報告会の有無を同じ条件で並べて確認します。社数を先に決めるより、比較するすべての見積で六つの軸を揃えることが前提です。条件が異なる場合は、総額を比べる前に対象外や追加条件を質問して記録します。

相見積は何社から取ればよいか

相見積の社数だけで比較の精度は決まりません。同じ仕様の六つの軸が揃っていなければ、複数の見積があっても条件差を見落とします。社内で確認できる範囲と調達の手順に合わせ、対象、深度、手動比率、認証後画面、再診断、報告会を同じ書式で確認できる状態を作ります。

まとめ

セキュリティ診断の発注では、目的、管理下の資産、対象範囲を先に整理し、診断の種類と計量単位を分けて考えます。そのうえで、対象数から報告会までの六つの条件を同じ仕様シートに残すと、見積の差分を確認しやすくなります。公的リストは区分を確認する入口として使い、掲載だけで判断せず、実施範囲と成果物を具体化して準備を進めます。

発注準備に関する記事は発注・選び方の記事一覧で確認できます。ほかのテーマを含めて読む場合はブログ一覧をご覧ください。掲載内容の訂正、ご意見、ご質問、取材・引用についてはお問い合わせで受け付けています。