脆弱性管理システム開発の発注/外注/依頼/委託方法について

脆弱性管理システムの発注は、資産と運用責任の整理、要件と委託先の比較、PoC、段階導入の順に進めると、導入後も継続してリスクを下げやすくなります。発注形態や契約、費用の考え方から導入後の運用まで、委託先と話すときに迷いやすい点を取り上げます。

▼全体ガイドの記事
・脆弱性管理システム開発の完全ガイド

脆弱性管理システムの発注前に押さえる全体像

発注は、製品の選定と業務プロセスの整備に分けて考えると整理しやすくなります。検出対象に加えて、誰がいつまでに対応し、どの証跡を残すかを決めておかないと、導入後に使われない状態になりかねません。そのため、対応の担当と期限、証跡の残し方も、発注前に決めておきます。

脆弱性診断と脆弱性管理の目的の違い

脆弱性診断は、Webアプリやネットワークを特定の時点で検査し、弱点を報告するサービスです。

一方で、脆弱性管理は、サーバー、PC、クラウド、コンテナ、OSSなどを台帳に登録し、発見、評価、対応依頼、修正後の確認を続ける業務です。診断だけを頼むか、基盤の導入や運用まで頼むかで、委託先も契約も費用も変わります。

システムだけではない発注成果物の範囲

納品物には、システムだけでなく、運用に必要な資料や仕組みも含まれます。発注の範囲には、次の三つも入れておきます。

  • 資産と評価:対象資産一覧、検出ルール、リスク評価基準
  • 対応ルール:重大度別の対応期限、例外承認の手順
  • 運用と引継ぎ:チケット連携、月次レポート、操作マニュアル、引き継ぎ資料

重大な脆弱性を検知しても、対応の期限や担当が決まっていなければ、担当部署は動かない場合があります。たとえば、「インターネット公開かつ悪用実績がある資産は24時間以内に一次判定する」と決めておきます。さらに、7日以内に暫定対策か例外承認を記録する取り決めを加えると、運用と検収の基準がはっきりします。

ポイント

検出対象だけでなく、対応の担当と期限、証跡の残し方まで決めてから、製品や委託先を比べます。診断か管理かによって委託先も費用も変わるため、この切り分けを先に確認するのが判断の目安です。

発注形態の選び方:SaaS導入・導入支援・自社開発

多くの企業では、中核の機能をSaaSまたはパッケージで導入し、足りない連携や業務画面だけを外注で開発する形が現実的です。

ただし、規制や閉域網、データ保管、既存CMDBやITSMとの統合要件が強い場合は、専用環境も候補になります。SaaS、導入支援、自社開発のそれぞれについて、保守の責任とアップデートの費用も含めて比べてください。

早期の可視化を目指す場合のSaaS導入

SaaSは、脆弱性データベースの更新、検出ルールの追加、可用性の維持を任せやすい方式です。専任者が少なくても、100〜500資産程度の規模から、カバレッジと重大脆弱性の対応時間を測れます。

契約前には、資産数の定義、対象外の機器、クラウドアカウントを確認します。さらに、ログの保持期間、データの保管地域、APIの利用範囲も詰めておきます。

要件と運用を一緒に整える導入支援の外注

資産台帳や認証付きスキャン、部署ごとの担当、例外承認が整っていないと、検出件数だけが増えて現場が疲弊します。そのため、要件と運用を一緒に整えたい企業には、導入支援の外注が向いています。依頼内容と見積もりは、次の三つに分けて考えます。

  • 導入と運用:初期設計、ネットワーク許可、エージェント配布、SSO、教育、運用開始後の定例会
  • 連携:JiraやServiceNowなどのチケット連携
  • 見積もり:対象資産数、連携本数、会議回数、納品資料、検収条件ごとの内訳

固有業務が競争力になる場合のスクラッチ開発

独自業務や製品への組み込み要件がある場合は、自社開発も選択肢になります。自社で作る対象には、資産台帳、CVE情報、リスクスコアのほか、ワークフロー、通知、監査証跡が含まれます。

ただし、脆弱性情報の更新と検出精度の検証は自社の責任になります。認証情報の保管や、更新時の互換性確認も自社が担います。

自社の負担が大きいぶん、市販サービスで標準業務を検証し、不足する機能だけを追加開発すれば、初期リスクと保守負担を抑えやすくなります。

ポイント

中核はSaaSかパッケージで導入し、外注は不足する連携や画面に絞るのが基本です。規制や閉域網などの要件が強い場合は、専用環境も候補に加えて比べます。

RFPと要件整理で発注先に伝える内容

RFPの要件を対象資産と検出方式、優先順位と対応フロー、連携・認証・データ保護に分けた図
3つの領域を同じ条件で各社へ伝える構成です。

RFPは、自社のリスクと目指す運用を候補会社へ同じ条件で伝えるための資料です。記載するのは、現状の課題、対象範囲、連携先です。さらに、制約と納期、予算の考え方、回答形式も書き添えます。

MUST要件とWANT要件に分けておくと、最初から全機能を必須にせずに済みます。

対象資産と検出方式の一覧

対象資産と検出方式を整理しておくと、各社の提案の範囲をそろえられます。対象となる資産には、サーバーやPC、ネットワーク機器、クラウド(AWS・Azure・GCP)があります。さらに、Webアプリやコンテナ、OSSのほか、リモート端末やOT・IoTも含まれます。

  • 資産情報:台数またはアカウント数、所有部署、重要度、インターネット公開状況、EOLや保守期限
  • 運用条件:認証付きスキャンの可否、停止可能な時間帯
  • 検出方式:エージェント、ネットワークスキャン、クラウドAPI、SAST、DAST、SCA、SBOM

資産ごとに情報をそろえると、検出方式の対象漏れも見つけやすくなります。

優先順位と対応フローの発注要件

CVSSだけで重大度を決めず、インターネット露出や悪用実績、業務の重要度と機密情報の有無、補完対策を組み合わせて優先順位を付けます。

公開サーバーで悪用が確認された脆弱性、重要データを扱う基盤の高リスク脆弱性、社内端末の低リスク脆弱性では、期限や承認者が異なります。

RFPには、検出から経営報告までの状態の移り変わりを書きます。検出後の流れは、通知や一次判定、暫定対策、恒久対応から、再スキャン、例外承認、経営報告へと進みます。

連携・認証・データ保護の要件

発注時には、認証、連携、データ保護の条件を分けて、要件に書きます。

  • 認証と保護:SSO、MFA、権限分離、認証情報、API認証、暗号化、バックアップ
  • ログと連携:操作ログ、保持期間、保管地域。Jira、ServiceNow、Slack、メール、CMDB、EDR、SIEMとの通知のみか、チケット状態の相互同期か
  • SBOM:CycloneDX・SPDXなどの形式、識別子、CVE照合、VEX、委託先の提出・更新履歴

経済産業省は2025年9月、SBOMを脆弱性管理やサプライチェーンリスク管理に活用する国際ガイダンスに共同署名しました(出典:経済産業省、2025年)。そのうえで、SBOMの受け渡し条件も確認しておきます。

請負・準委任・ライセンスの組み合わせ

利用契約と初期導入、個別開発、継続運用は、責任範囲を分けて契約すると管理しやすくなります。

成果物と完成条件を定める部分は請負に、作業時間と専門性を提供してもらう部分は準委任になります。SaaSの利用は、サービス利用契約として別に扱います。

請負契約の成果物と検収条件

初期環境や台帳移行、ダッシュボードは、完成の状態を合意できるため請負に向いています。チケット連携やマニュアルも、請負の対象にしやすい項目です。一方で、「脆弱性ゼロ」や「全資産の自動検出」は、外部環境や所有者の協力に左右されるため、検収基準にはなりません。

契約書と仕様書では、対象資産数、連携、テストケースを明記します。さらに、重大不具合の定義、修正期限、検収後の保証範囲も記載します。

要件定義と運用伴走に向く準委任契約

現状調査や台帳整理、RFP作成、製品比較は、途中で前提が変わる可能性があります。PoCや運用設計、月次トリアージも、進めるうちに前提が変わることがあります。そのため、準委任が適しています。稼働時間や担当者、会議体、作業範囲、報告物を定めておけば、前提が変わったときに、その場で話し合えます。

委託先に任せる判断と、自社の承認が必要な判断は分けておきます。そのうえで、作業時間の上限と追加作業の承認を明記します。加えて、情報管理と秘密保持、事故時の連絡時間も定めておきます。

契約終了時のデータ返却と移行

検出履歴と対応状況、例外承認、再スキャン結果は、監査や事故対応に欠かせません。そのため、データをどの形で受け取れるかを契約前に確認します。CSV・JSON出力やAPI、添付資料の扱いに加えて、返却費用や削除証明、移行単価、保持期間も押さえておきます。

データを取り出しにくいサービスは、将来のベンダー変更やM&A、監査対応の場面で、高い移行コストを招く可能性があります。

ポイント

完成条件を書けるかどうかを基準に、請負と準委任を分けると迷いにくくなります。途中で前提が変わる作業は、準委任として稼働時間や担当者を決めておくと扱いやすくなります。

脆弱性管理システムの発注・外注費用の相場

100〜300資産、300〜2,000資産、2,000資産超の初期費用目安を横棒で比べた図
統合範囲が広がるほど初期費用の目安も上がります。

費用は、製品利用料、初期設計・連携、診断・再診断に分けて考えます。さらに、パッチ・改修、運用代行、教育・監査対応も別に見ておきます。

ただし、金額は資産数やクラウドの利用、連携数で変わります。サポート時間や為替、税、契約期間でも変わるため、以下の金額は目安です。

公開価格の見方と製品比較

次の2製品は、料金の単位も機能の範囲も異なります。

  • InsightVM:500資産、1資産あたり月額1.62米ドルから
  • Nessus Professional:1年ライセンス4,790米ドル

Rapid7の単純計算では月額810米ドルになります。ただし、契約期間やサポート、追加機能によって金額が変わります。販売形態や為替、税も影響します(出典:Rapid7公式料金ページ、2026年確認)。

円換算額を、そのまま発注額とみなさないようにします。

Nessus Professionalは脆弱性評価用のスキャナーで、資産台帳やチケット連携を含む管理基盤の総額とは異なります(出典:Tenable公式購入ページ、2026年確認)。

資産規模別の導入・追加開発費の目安

資産数の規模で分けると、初期費用と期間の目安は次のようになります。

  • 100〜300資産:小規模PoCは初期50万〜200万円程度、1〜2か月程度。年間利用料は別枠で60万〜200万円程度
  • 300〜2,000資産:標準導入は初期300万〜1,000万円程度、3〜6か月程度
  • 2,000資産超:統合する場合、初期1,000万〜3,000万円超、期間6〜12か月程度の計画になる可能性

小規模PoCには、台帳やスキャン、基本レポート、最小限の教育が含まれます。標準導入は、エージェント、クラウド連携、SSO、ITSM連携、運用設計までを含む想定です。

2,000資産超では、複数会社や海外拠点、OT・IoTまでの統合を見込みます。さらに、CMDB、SBOM、独自ワークフローまでの統合も見込みます。自社開発の比率が高い場合は、2,000万〜5,000万円以上になるケースも想定されます。

この金額は、機能と体制をもとに置いた推定の幅で、公開された定価ではありません。見積もるときは、製品、設計、連携を分けて見ます。移行、テスト、教育も、別の項目として切り分けます。

ライセンスとは別枠の運用代行と診断費

運用代行や診断の費用は、ライセンスとは別に見積もります。

  • 診断サービス:Securifyは月額5万円から。ASM、CSPM、SBOMなどは機能構成に応じた問い合わせ
  • 運用代行:小規模は月額10万〜50万円、中堅以上は月額50万〜200万円が推定の目安
  • 契約総額:年間と3年間の総額を比較

Securifyの金額は、Webアプリや外部公開資産を継続して確認する場合の価格例です。サーバーや端末、クラウド、チケット運用を含む総合管理の料金ではありません(出典:Securify公式料金ページ、2026年確認)。

国内の診断でも、一回のネットワーク診断やWebアプリ診断の料金と、継続管理の月額を分けて提示するのが一般的です。

一次トリアージだけを頼むのか、担当部署への催促やパッチ適用代行まで含むのかで、費用は変わります。さらに、再スキャンや月次報告、緊急時の休日対応を含むかどうかも、金額を左右します。

初期費用を低く見せ、運用契約に作業が集まるような提案もあります。そのため、年間総額と3年総額で比べます。

ポイント

費用は資産数や連携数で変わるため、規模別の目安は出発点として扱い、資産数と連携の範囲をそろえて年間と3年の総額で比べます。

委託先の選定と見積比較の観点

委託先は、製品ベンダー、導入支援会社、診断会社、MSPやSOC事業者に分けて比べます。候補には同じRFPを渡したうえで、価格や対象範囲、体制を評価します。さらに、成果物、運用性、契約終了時の移行性も見ます。

ただし、製品ベンダーが業務設計まで担えるかは、会社ごとに確かめる必要があります。診断会社については、台帳やチケット運用を担えるかを見ます。

導入社数より自社に近い運用事例

自社に近い運用事例かを見るため、次の三つの観点をそろえて確認します。

  • 環境と規模:資産数、クラウド比率、拠点、OS、Webアプリ・コンテナ
  • 運用と成果:担当者数、導入後の改善指標、棚卸しから対応完了までの自動化範囲
  • 実施体制:責任者、評価専門家、クラウド・開発・運用担当、再委託、海外アクセス、認証情報、引き継ぎ、緊急連絡

リサーチノートでは、Rapid7 InsightVMを導入したソフトバンクの例を紹介しています。数十万を超える機器を一元管理し、継続診断と優先順位付けを自動化した事例です(出典:ソフトバンク導入事例、2026年確認)。

自社では、大規模な事例をそのまま当てはめず、棚卸しから対応完了までの自動化の範囲を委託先に質問します。

PoCでは、営業担当のデモよりも、実作業者から誤検知の扱いと修正確認画面を見せてもらうほうが確かめやすくなります。

同じ粒度で揃える見積書の比較

見積もりは、含む項目と含まない項目をそろえて比べます。連携費が一式で示されていると、API本数やデータ項目が増えたときの追加費用が見えにくくなります。

  • 製品と範囲:利用料、資産数、初期構築、台帳移行、エージェント展開
  • 連携と検証:ネットワーク、クラウド、SSO、ITSM、PoC、テスト
  • 定着と支援:教育、マニュアル、運用、再診断、サポート、税

価格だけでなく、検出対象の広さと、対応完了までの工数も比べます。対象漏れがあると、追加診断や手作業が増えます。また、高機能な製品でも、現場で使えなければ効果は下がります。

提案書には、初月から12か月までの到達状態を時点ごとに書いてもらいます。さらに、KPIの初期値と目標、顧客側の作業時間も記載してもらいます。

最終候補に確認する運用と移行の質問

最終候補には、運用と評価、移行、社内体制について具体的に質問します。

  • 運用対応:未知資産の発見方法、誤検知を誰が判定するか、パッチできないレガシーOSへの代替策
  • 評価方法:悪用実績や公開範囲の情報源、CVEの重複、SBOMと本番資産の紐付け
  • 成果指標:件数削減だけでなく、重大リスクの期限内修正率や平均修正日数を改善する提案
  • 移行条件:会社統合やクラウド移行に備えたデータ出力、API制限、設計書の著作権、設定返却、終了後支援
  • 運用定着:半年後に備えた教育対象・回数・操作演習、管理者手順、障害時の切り分け資料、自社責任者と各資産の所有部署

ポイント

同じRFPを渡した各社の提案を、価格だけでなく、対象範囲や体制、契約終了時の移行性まで並べて見ると、判断がぶれにくくなります。

脆弱性管理システムの発注から運用開始までの進め方

PoCで確認する資産確認、検出確認、対応確認の3項目を並べたチェックリスト
資産の把握から修正後の再確認までを評価できます。

発注は、現状把握、要件整理、候補選定、PoCの順に進めます。そのうえで、契約、段階導入、運用評価へと進めると安全です。

まずは全社展開をせず、代表的な資産と担当部署で、検出から再確認までを実証します。見つかった課題は、本番計画に反映します。本番スキャンには負荷や停止のリスクがあるため、実施時間と緊急停止の手順を事前に合意しておきます。

PoCで確認する検出精度と対応完了まで

PoCには、代表的なサーバーやクラウドアカウント、端末、ネットワーク機器、Webアプリを含めます。評価項目と合格ラインは、契約前に決めておきます。

  • 資産確認:重複排除が正しく行われるか
  • 検出確認:認証付きスキャンが安全に動き、誤検知を保留できるか
  • 対応確認:担当へのチケット作成と修正後の再確認ができるか

合格ラインを決めておくと、導入の判断が担当者の感覚だけに左右されずに済みます。

対象範囲と責任部署を広げる段階導入

PoCの後は、インターネット公開資産、重要サーバー、クラウド、社内端末のように、リスクの異なる単位で展開します。

各段階では、カバレッジや期限内修正率、平均修正日数を確認します。さらに、再発率や例外残高、スキャン失敗率も見ていきます。

検出が増えたときは、可視化が進んだためか、設定ミスや誤検知かを分析します。件数の増加だけで失敗とは判断しないことが大切です。

運用開始後の月次レビュー

月次では、重大脆弱性の残件や期限超過、対応時間を確認します。さらに、例外承認の期限や資産の新規・退役、スキャン失敗も見ます。

四半期ごとには、対象の見直しやクラウドの追加、SBOMの更新を評価します。加えて、CI/CDのSCAやコンテナスキャン、契約容量も見直します。

責任は、ITや開発、インフラの各部門で分担します。事業部門、調達、監査も、役割を決めておきます。

発注・外注で起こりやすい失敗と回避策

失敗は、製品の性能より、対象範囲や責任、優先順位、契約条件があいまいなまま発注されたときに起こりやすくなります。そのため、発注時には、導入後に誰が何をするかを合意しておき、自社側の作業も計画に入れます。費用の比較だけでは判断できない運用負荷を把握することが、外注を成功させる近道です。

検出件数だけをKPIにする偏り

資産の発見や新しい情報の取り込みで、脆弱性の検出件数は一時的に増えることがあります。ただし、件数の目標だけを追うと、低リスクの項目の処理に偏り、公開サーバーや重要業務のリスクが残る可能性があります。

KPIには、カバレッジや重要脆弱性の期限内修正率、平均修正日数を組み合わせます。加えて、例外の期限切れや再発率も入れます。そのうえで、経営層には、残存リスクと事業への影響を説明します。

丸投げを避ける自社の意思決定者

委託先は、検出結果の整理や運用を支援できます。一方で、業務停止やリスク受容、改修予算は自社が決めます。

情報システム部門だけで抱えず、事業部門や開発責任者、監査、調達を含む承認ルートを作ります。

ネットワーク隔離や仮想パッチを代替策にする場合も、期限と責任者を記録して、放置とは区別します。

よくある質問(FAQ)

発注の検討では、費用だけでなく、導入範囲や運用責任についても質問が寄せられます。検討の初期によくある疑問を、順に取り上げます。

脆弱性管理システムの発注費用は一律いくらですか?

費用は、資産数や連携の範囲によって変わります。たとえば、100〜300資産の小規模PoCは、初期50万〜200万円程度です。

さらに、300〜2,000資産の標準導入は、初期300万〜1,000万円程度が目安です。

製品利用料や連携、運用支援は別途かかります。公開価格は製品や診断の一部のため、資産数と作業範囲をそろえた年間総額で比べます。

製品ベンダーとシステム開発会社はどちらに依頼すべきですか?

製品機能やライセンスは製品ベンダーに、業務の整理や既存連携は導入支援会社や開発会社に相談するのが基本です。ただし、両方を一社に任せる方法もあります。

一社に任せる場合は、台帳整備やチケット連携、教育、契約終了時のデータ返却を確認します。固有業務が少なければSaaSを優先し、固有連携が大きい場合は、追加開発の経験を見ます。

最初から全資産を対象にして発注したほうがよいですか?

代表的な資産でPoCを行い、段階的に広げるのが基本です。まずは、公開資産や重要サーバーなど、事業リスクが高く関係部署を巻き込みやすい範囲を選びます。

PoCでは、検出精度やスキャンの負荷、担当への通知、再確認、例外承認を確かめます。PoCで把握した作業量を、本番の見積もりに反映してください。

まとめ:発注範囲と運用責任を先に決める進め方

SaaS、パッケージ、スクラッチの選択は後にして、まず対象資産と検出方式、優先順位、期限、担当部署を整理します。さらに、チケット連携と監査証跡も決めておきます。

多くの企業では、中核をSaaSやパッケージで導入し、不足する連携や画面だけを追加で開発します。そうすると、速度と柔軟性のバランスを取りやすくなります。

発注前に確認する項目

発注前には、100〜500資産のPoCにするか全社導入にするか、ライセンスと導入範囲、初期費用と年間費用を確認します。

契約区分や検収条件、SLAに加えて、データ返却、教育、運用代行の有無も、確かめておきます。

同じ資産数と連携条件で、3社程度から提案を受け、価格差の理由を聞きます。また、安い提案でも、対象外の資産や手作業、追加ライセンス、終了時の移行費を把握します。

導入後のKPIと追加投資の判断

追加投資を判断する材料として、導入後に追う項目と将来の対象範囲を決めておきます。

2025年以降は、SBOMやクラウド、コンテナ、外部公開資産を含めた管理も重視されています。

  • 月次KPI:カバレッジ、重大脆弱性の期限内修正率、平均修正日数、再発率、例外残高
  • 将来の対象:SBOM、クラウド、コンテナ、外部公開資産をRFPに含め、APIとデータ出力の余地を確保
  • 報告期限:EU向けデジタル製品の報告開始日は2026年9月11日
  • 証跡管理:受付、影響判定、報告、修正、通知の記録

EU向けデジタル製品を提供する企業は、積極的に悪用された脆弱性や重大インシデントを報告します。具体的には、早期警告は24時間、完全な通知は72時間などの期限が示されています。

この報告期限はEUサイバーレジリエンス法に基づきます(出典:欧州委員会、2026年確認)。そのため、自社が制度の適用対象かを確認しておきます。

脆弱性管理システムは、導入後も続けて運用し、事業リスクを下げ続けるための仕組みです。

導入後の評価と追加投資は、自社の意思決定者と資産の所有部署を置いて判断します。そのため、委託先には、技術の導入だけでなく運用の定着まで含めた提案を求めます。

▼全体ガイドの記事
・脆弱性管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。