脆弱性管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

脆弱性管理システム開発は、脆弱性を検出するツールを作るだけではなく、資産の把握、リスクの優先順位付け、修正依頼、再確認までを継続して回せる業務基盤を設計することです。

「脆弱性診断の結果をExcelに転記している」「重大度の高い項目が多すぎて、どれから直すべきかわからない」「クラウドやリモート端末を含む資産台帳を維持できない」と悩む企業に向けて、要件整理から定着までの進め方を解説します。SaaS・パッケージを活用する場合と、既存システムとの連携を開発する場合を分け、実務で使える判断基準、チェック項目、費用の考え方まで整理します。

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

脆弱性管理システム開発の全体像

脆弱性管理システムは、サーバー、PC、ネットワーク機器、クラウド、コンテナ、Webアプリ、OSSなどのIT資産を継続的に管理する仕組みです。単発の診断結果を保存するだけでは、資産の増減や新しいCVEへの対応、担当部署への依頼、修正後の確認までを一貫して追跡できません。

脆弱性診断は、決められた対象をある時点で検査し、脆弱性の有無や深刻度を報告する活動です。一方、脆弱性管理は、資産の登録、検出、評価、対応、例外承認、再スキャン、証跡保存を繰り返す業務プロセスです。診断ツールを導入しても、誰がいつまでに何を直すかが決まらなければ、脆弱性管理は完了しません。

開発の起点では「診断結果を集めること」ではなく、「事業に影響するリスクを期限内に下げること」を目的にします。たとえば、CVSSが9.8でも閉域で補完対策がある資産と、CVSSが7.5でもインターネットに公開された決済基盤では、後者を先に対応する場合があります。優先順位を業務重要度、公開範囲、悪用実績、データの機密性、代替策で説明できることが重要です。

最低限必要な機能は、資産の自動検出と台帳化、エージェントまたは認証付きスキャン、CVE・CWE・CVSSなどの情報取り込み、リスクの優先順位付け、担当部署へのチケット発行、期限管理、例外承認、再スキャン、レポートです。AWS・Azure・GCPのAPI、EDRやMDM、CMDB、JiraやServiceNowなどのITSM、Slackやメールとの連携をどこまで行うかも要件に含めます。

対象資産は、サーバーだけでなく、リモート端末、ネットワーク機器、クラウドリソース、コンテナ、Webアプリ、OSS、SBOMまで洗い出します。古いOS、保守終了したミドルウェア、所有部署が不明な機器、インターネット公開の有無が不明な資産は、脆弱性管理を始める前からリスクになっています。要件書には資産の種類、台数、ネットワーク区分、所有者、重要度、廃止予定日を記載します。

2025年から2026年にかけては、ネットワークスキャナー単体ではなく、ASMによる未知資産の発見、クラウド設定評価、SCAやSBOMによるソフトウェア部品管理、リスクベースの優先順位付け、チケット連携までを一つの運用基盤にまとめる方向が強まっています。経済産業省は2025年9月、SBOMを脆弱性管理などに活用する重要性を示す国際ガイダンスに共同署名しており、ソフトウェアの構成要素と脆弱性を照合できる仕組みは、今後の選定基準になりやすいです。出典は経済産業省「SBOMの共有ビジョンに関する国際ガイダンス」（2025年）です。

製品や開発会社を比べるときは、検出できる脆弱性の件数だけでなく、資産カバレッジ、誤検知の扱いやすさ、悪用実績を含む優先順位、修正期限の管理、データ出力、API、サポートSLAを確認します。専任者が少ない企業ほど、検出後に現場が動けるワークフローと、月次報告を作りやすい可視化機能を重視します。

脆弱性管理システム開発の進め方・流れ

脆弱性管理システム開発は、要件整理、製品・方式の選定、設計開発、テスト、稼働、定着の6フェーズで進めると判断漏れを抑えられます。各フェーズで成果物と合否条件を決め、次の工程へ進む前に、対象資産と運用責任の抜けを確認します。

最初に、資産台帳、ネットワーク構成、クラウドアカウント、既存の診断・EDR・MDM・SIEM・CMDB・ITSMを棚卸しします。資産台帳には、IPアドレスやホスト名だけでなく、所有部署、業務名、重要度、外部公開の有無、OSとミドルウェア、データ区分、保守期限、パッチ適用可否を持たせます。台帳が不完全な場合は、未知資産の検出を要件の上位に置きます。

次に、重大度別の修正SLA、例外承認者、暫定対策の期限、再スキャンの条件、担当部署への通知方法を決めます。チェック項目は「全資産の所有者がわかるか」「インターネット公開資産を識別できるか」「EOLを検知できるか」「認証付きスキャンの資格情報を安全に保管できるか」「修正できない資産のリスク受容を記録できるか」です。MUST要件とWANT要件を分け、初期リリースで必須の範囲を絞ります。

方式は、クラウドSaaS、オンプレミスやプライベートクラウド、SaaSを基盤にした連携開発、フルスクラッチから比較します。短期間で最新の脆弱性情報に追随したい場合はSaaSやパッケージが第一候補です。閉域、データ保管場所、独自の承認フロー、既存資産DBとの統合が強い場合は、オンプレミスまたはSaaS＋追加開発を検討します。脆弱性データベースや検出ルールまで自社で保守するフルスクラッチは、固有要件と長期運用体制が明確な場合に限定します。

選定前のPoCでは、代表的なサーバー、端末、クラウド、Webアプリ、コンテナを含め、少なくとも異なる性質の資産を試します。確認するのは、検出率、誤検知、本番負荷、エージェントを入れられない資産への対応、認証情報の保護、チケットの自動起票、修正後の再確認です。デモ画面だけでなく、検出から担当者が修正を完了し、証跡が残るまでの一連の操作を実演してもらいます。

設計では、資産、脆弱性、検出結果、対応チケット、例外、再確認結果をどのIDで紐づけるかを決めます。同じサーバーが複数回スキャンされても別資産として重複登録されないよう、ホスト名、IP、クラウドID、エージェントIDなどの名寄せルールを定義します。所有部署が変わったときの履歴や、退役した資産の扱いもデータモデルに含めます。

連携開発では、SSO・MFA、クラウドAPI、CI/CD、SCA、SBOM、JiraやServiceNow、メール・Slackを優先順位に沿って実装します。すべてを初回に連携するのではなく、重大脆弱性の通知と担当者への依頼を先に自動化し、経営レポートや高度な分析は運用を見ながら拡張します。APIのレート制限、障害時の再送、連携先の停止時に手動で処理できる経路も設計します。

テストは、機能テストだけでなく、脆弱性管理の業務シナリオで行います。新しい資産が登録される、重大な脆弱性が検出される、担当部署にチケットが発行される、期限を超過する、例外が承認される、修正後の再スキャンで解消を確認する、という流れを通しで検証します。重複検出や誤検知を担当者が修正できるかも合否条件にします。

本番影響を避けるため、スキャン時間帯、同時実行数、対象外ポート、負荷上限、緊急停止方法を決めます。認証情報は平文でログに残らないか、権限を最小化できるか、期限切れを検知できるかを確認します。権限テストでは、セキュリティ担当者、システム所有者、開発者、監査担当者が見られる情報と操作できる範囲を分けます。

稼働開始時は、全社の資産を一度に対象にするのではなく、重要な業務システムやインターネット公開資産から段階的に広げます。最初の対象で、資産カバレッジ、スキャンの完了率、重大脆弱性の期限内修正率、チケットの担当設定率を確認します。問題があれば、検出ルールや通知先を修正してから次の部署へ展開します。

稼働手順書には、定期スキャン、緊急CVEの臨時スキャン、結果のトリアージ、担当部署への通知、例外申請、再確認、月次報告、障害時の連絡先を記載します。脆弱性の発見をセキュリティ部門だけの仕事にせず、資産所有者、開発チーム、インフラ運用、監査、経営層の役割をRACIなどで明示することが重要です。

定着の評価は、検出件数が増えたか減ったかだけでは不十分です。資産カバレッジ、重大脆弱性の期限内修正率、平均修正日数、期限超過件数、例外の残高、再発率、再スキャン完了率を月次で確認します。検出件数が一時的に増えても、未知資産の発見や台帳の精度向上が原因なら、管理の改善として評価できます。

月次会議では、期限超過の理由を「パッチ適用待ち」「業務停止が困難」「所有者不明」「誤検知」「例外承認済み」に分類します。修正できないレガシーOSや装置は、仮想パッチ、ネットワーク隔離、監視強化、利用停止計画などの代替策と期限を記録します。KPIが悪化したときに、製品の問題なのか、資産台帳や担当ルールの問題なのかを切り分けることが、継続的な改善につながります。

脆弱性管理システム開発の費用相場

脆弱性管理システムの費用は、製品ライセンス、初期設計・設定、資産台帳の整理、連携開発、診断・再診断、教育、運用代行に分けて見積もります。以下の金額は確定価格ではなく、リサーチノートに記載された導入規模、公開価格、一般的な連携工数から組み立てた予算計画用の推定レンジです。資産数やサポート範囲で変わるため、社内稟議ではレンジと前提条件を併記します。

Rapid7の公式価格ページでは、InsightVMの脆弱性リスク管理が500資産の場合、1資産あたり月額1.62米ドルからと表示されています。500資産で単純計算すると月額810米ドル、年額9,720米ドルです。1米ドル150円で試算すると年額約146万円になりますが、契約期間、販売形態、サポート、追加機能、税、為替で変わるため、予算のベンチマークとして扱います。Rapid7 Product Pricingを2026年8月に確認した情報です。

Tenableの公式購入ページでは、Nessus Professionalの1年ライセンスが4,790米ドルと表示されています。1米ドル150円で換算すると約72万円ですが、これは主に脆弱性評価用スキャナーの価格です。資産台帳、組織横断の優先順位、チケット連携、例外管理、再確認まで含む脆弱性管理プラットフォームの総額とは分けて比較します。Tenable「料金設定と購入オプション」を2026年8月に確認した情報です。

100〜300資産を対象に、資産台帳、スキャン、基本レポート、通知を確認する小規模PoCは、初期50万〜200万円程度、期間1〜2か月程度が一つの推定目安です。年間利用料は製品とオプションにより、60万〜200万円程度を別途想定します。ここでは、代表的なサーバー、端末、クラウド、Webアプリを対象にして、導入効果と本番影響を見極めます。

300〜2,000資産を対象に、エージェントやクラウド連携、SSO、ITSM連携、運用設計、教育まで行う標準導入は、初期300万〜1,000万円程度、期間3〜6か月程度が推定目安です。2,000資産を超え、複数会社、海外拠点、OT・IoT、CMDB、SBOM、独自ワークフローを含む場合は、初期1,000万〜3,000万円超、期間6〜12か月程度を想定します。自社開発部分が多い場合は、さらに上振れする可能性があります。

Securifyの公式料金ページでは、Webアプリケーション診断のSTARTERが月額5万円、年間60万円、BASICが月額10万円から、年間120万円からと表示されています。これはWebアプリの継続診断の比較材料であり、サーバー、端末、ネットワーク機器、クラウドを含むVMDR製品の総額とは異なります。Securify「脆弱性診断料金プラン」を2026年8月に確認した情報です。対象範囲の違いを説明せずに単純比較しないことが重要です。

運用代行を含める場合は、一次トリアージ、パッチ適用依頼、月次報告、緊急CVE対応、監査資料作成のどこまでを任せるかで変わります。小規模では月額10万〜50万円程度、中堅以上では月額50万〜200万円程度を予算検討の推定レンジにできますが、夜間対応やパッチ適用そのものを含める場合は個別見積もりになります。診断、再診断、運用代行、ライセンスを別行にした見積書を取得します。

見積もりを取る際のポイントとチェックリスト

見積もりの精度は、依頼時に対象範囲と運用ルールをどこまで具体化できるかで決まります。「脆弱性を管理できるシステム」という依頼だけでは、製品費、開発費、診断費、運用費が混ざり、会社ごとの金額を比較できません。RFPや要件メモには、資産数、ネットワーク、検出方式、連携先、SLA、成果物、保守範囲を記載します。

対象資産は、種類ごとの台数、増加予定、クラウドアカウント数、外部公開の有無、閉域ネットワーク、エージェントの可否まで記載します。検出方式は、エージェント、ネットワークスキャン、認証付きスキャン、クラウドAPI、Webアプリ診断、SAST・DAST・SCA、SBOMのどれを使うかを分けます。対象外の資産と、その場合の代替手段も見積書に明示してもらいます。

合否条件は、資産を何パーセント捕捉できればよいか、重大脆弱性の通知を何分以内に行うか、チケットをどの条件で発行するか、再スキャンでどの証跡を残すかで定義します。特に「対応件数を減らす」だけではなく、重大脆弱性の期限内修正率、平均修正日数、期限超過の理由が月次で確認できることを成果条件にします。

複数社へ見積もりを依頼するときは、同じ資産数、同じ対象環境、同じ連携先、同じ導入期間を提示します。比較表には、ライセンス、初期設定、資産台帳の移行、名寄せ、連携開発、テスト、教育、保守、運用代行、診断・再診断を分けて記載します。安い提案が対象範囲を狭くしていないか、逆に高い提案が不要なカスタム機能を含めていないかを確認します。

製品ベンダーと導入支援会社は役割が異なります。製品の検出能力や更新頻度はベンダーに確認し、資産台帳の整理、ネットワーク許可、チケット運用、教育、社内調整まで支援できるかは導入会社に確認します。候補企業には「同規模の資産での導入実績」「誤検知や例外の運用方法」「日本語サポートと緊急時SLA」「契約終了時のデータ返却」「担当者が不在のときの引き継ぎ」を質問します。

見落とされやすいのは、資産台帳のクレンジング、古いOSの例外設計、クラウド権限の準備、ネットワーク許可、既存ツールからのデータ移行、チケット項目の調整、教育、監査資料の作成です。これらを「発注側の作業」として一括で除外すると、導入期間が延びたり、追加費用が発生したりします。発注側と受注側の責任分界を、作業単位で確認します。

また、脆弱性管理システムが導入されても、パッチ適用そのものが自動で完了するとは限りません。業務停止の調整、検証環境での確認、変更承認、バックアウト、再起動の判断は、資産所有者や運用チームが担います。見積もりでは、検出後の修正作業を誰が行うか、夜間対応が必要か、重大CVEが公開されたときの臨時対応を含むかまで明記します。

よくある質問（FAQ）

脆弱性管理システムの導入では、開発方法、製品の選び方、スキャンの安全性、古い資産への対応について質問が多く寄せられます。ここでは、導入前に社内で確認しておきたい質問へ、結論から回答します。

多くの企業では、SaaSやパッケージを基盤にし、社内固有の承認フローやチケット連携だけを追加開発する方法が現実的です。脆弱性情報や検出ルールを継続更新する負担を抑えられるためです。閉域、データ保管、独自の業務フローなど、製品で満たせない要件と長期の保守体制が明確な場合に、オンプレミスやスクラッチを検討します。

スキャン方式、設定、対象システムの性能によっては負荷や通信影響が出る可能性があります。PoCとテストで、実行時間帯、同時実行数、対象外設定、負荷上限、緊急停止方法を確認し、本番導入は段階的に行います。高負荷が懸念される資産には、エージェント方式や認証付きの低負荷スキャンなど、環境に合う方式を選びます。

CVSSは重要な判断材料ですが、点数だけで対応順を決めるのは不十分です。インターネット公開、悪用コードや実際の悪用実績、業務の重要度、機密情報、攻撃経路、補完対策、パッチ適用の難しさを組み合わせ、事業影響の大きいリスクから対応します。ルールをシステムに実装し、なぜその順位になったかを担当者へ説明できる状態にします。

パッチ適用ができない場合は、例外として放置せず、仮想パッチ、ネットワーク隔離、アクセス制限、監視強化、利用停止や更改の計画を組み合わせます。例外の理由、影響範囲、代替策、責任者、期限、再評価日をシステムに記録します。例外承認を無期限にすると、担当者依存のブラックボックスになるため、経営層やリスクオーナーが期限付きで承認する運用にします。

まとめ

脆弱性管理システム開発の進め方は、要件整理、選定とPoC、設計開発、テスト、稼働、定着の6フェーズで考えると整理しやすくなります。最初に資産の種類と所有者、公開範囲、EOL、重要度を把握し、CVSSだけでなく業務影響や悪用実績を使って優先順位を決めます。検出だけで終わらせず、担当者への依頼、期限、例外、再確認、証跡までを一つの流れにします。

費用は、製品ライセンス、初期設定、連携、診断、教育、運用代行を分けて考えます。100〜300資産のPoCでは初期50万〜200万円程度、300〜2,000資産の標準導入では初期300万〜1,000万円程度が推定目安ですが、対象範囲と契約条件で変わります。全社導入を前提にする前に、インターネット公開資産や重要業務を対象に、検出精度と修正完了までの時間を測定します。

成功のポイントは、システムを導入することではなく、資産台帳が更新され、重大脆弱性が期限内に修正され、例外の期限が管理され、再スキャンで結果を確認できる状態を定着させることです。見積もりでは、発注側の作業、導入会社の作業、製品ベンダーのサポートを分け、契約終了時のデータ返却や移行条件まで確認します。社内に専門担当者が少ない場合は、教育や月次レビューを含む支援を選ぶと、運用が担当者個人に依存しにくくなります。

脆弱性管理は、導入して終わる開発案件ではなく、発見、評価、対応、再確認を繰り返す改善活動です。自社の資産と業務リスクを基準に、最小限のMUST要件から始め、KPIを見ながら対象範囲と連携を広げることが、費用とセキュリティ効果の両方をコントロールしやすい進め方です。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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