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

脆弱性管理システム開発は、要件整理と方式選定から始めます。その後、設計・開発、テスト、段階稼働を経て、定着へ進みます。この流れで進めると、脆弱性の発見から修正後の再確認までを継続して回せます。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

下の資産把握から上の連携先まで、管理機能が積み重なります。

脆弱性管理システムは、IT資産の脆弱性を継続して管理する仕組みです。管理の対象は、サーバーやPCなどの端末とネットワーク機器のほか、クラウドにも及びます。コンテナ、Webアプリ、OSSも含まれます。

脆弱性管理では、担当部署への依頼から修正後の確認まで、一貫して管理します。診断結果を保存するだけでは、資産の増減や新しいCVEへの対応を追いきれないためです。

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

脆弱性診断は、決められた対象を一時点で検査し、脆弱性の有無や深刻度を報告する活動です。一方で、脆弱性管理では、診断後の対応まで含めて資産を継続的に管理します。

管理の流れ：登録、検出、評価、対応、例外承認、再確認、証跡保存の繰り返し
開発の目的：診断結果の収集を超えて、事業リスクを期限内に下げること
優先順位の根拠：業務重要度、公開範囲、悪用実績、機密性、代替策

優先順位は、業務への影響も合わせて決めます。たとえば、CVSS 9.8でも閉域で補完策がある資産より、CVSS 7.5でも公開された決済基盤を先に対応する場合があります。

最初に決める機能と対象資産

機能要件では、検出から修正後の確認までの業務を四つの領域に分けて、連携先も含めた初期範囲を決めます。

資産と検出：自動検出、台帳化、エージェントまたは認証付きスキャン
評価と対応：CVE・CWE・CVSSの取込、優先順位付け、チケット、期限管理
継続管理：例外承認、再スキャン、レポート
外部連携：AWS・Azure・GCP、EDR・MDM、CMDB、Jira・ServiceNow、Slack・メール

対象資産には、リモート端末、ネットワーク機器、クラウドが含まれます。コンテナ、Webアプリ、OSS、SBOMも、対象に含めます。台帳には、資産の種類や台数、ネットワーク区分に加えて、所有者、重要度、廃止予定日を記録します。

古いOSや保守終了したミドルウェア、所有部署や公開状況が不明な機器も、リスクになります。そのため、要件整理の段階で洗い出します。

2026年の評価軸は検出数より対応の一貫性

2025年から2026年にかけ、脆弱性の検出から対応までを一つの仕組みでつなぐ方向が強まっています。経済産業省も2025年9月、SBOM活用の重要性を示す国際ガイダンスに共同署名しました。構成要素と脆弱性を照合する仕組みは、選定基準になりやすいです（出典：経済産業省「SBOMの共有ビジョンに関する国際ガイダンス」、2025年）。

製品や開発会社は、検出後も対応が続くかどうかで比べます。その見方は、基盤、製品の中身、連携と支援、可視化の四つに分けて整理できます。

運用基盤：ASM、クラウド設定評価、SCA・SBOM、リスク優先順位付け、チケット連携
製品比較：資産カバレッジ、誤検知、悪用実績を含む優先順位、期限管理
連携と支援：データ出力、API、サポートSLA、現場向けワークフロー
可視化：専任者が少ない企業で重視したい、月次報告を作りやすい機能

ポイント

資産の増減を追いながら、業務影響の大きい脆弱性を期限内に下げられる構成かどうかが、判断の目安になります。事業リスクを基準に比べると、迷いにくくなります。

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

各工程の成果物と合否条件が、次へ進む判断の目印になります。

開発は6つのフェーズに分けて進めます。前半は要件整理と選定です。後半は設計・開発から始め、テストと稼働を経て定着へ至ります。

各フェーズでは成果物と合否条件を決め、次の工程へ進む前に、資産や責任の抜けがないかを確かめます。

フェーズ1：要件整理で決める資産と運用ルール

最初に、資産台帳、ネットワーク、クラウドアカウントを洗い出します。既存の診断、EDR、MDM、SIEM、CMDB、ITSMも、対象に含めます。

台帳には、IPやホスト名、所有部署、業務名を記録します。重要度と公開状況も残します。さらに、OS・ミドルウェア、データ区分、保守期限、パッチ可否も台帳に持たせます。台帳が不完全な場合は、未知資産の検出を優先要件にします。

要件整理では、資産をどこまで把握できるか、検知と認証情報の扱いを確かめます。

資産台帳：資産の所有者とインターネット公開範囲の把握
検知：EOLと未知資産を見つけられるか
認証情報：認証付きスキャンの資格情報の安全な保管
リスク受容：修正できない資産の判断の記録

運用ルールでは、重大度別のSLAと例外承認者を決めます。そのうえで、暫定策の期限、再スキャン条件、通知方法も定めます。加えて、要件はMUSTとWANTに分け、初期リリースで必須にする範囲を絞ります。

フェーズ2：選定とPoCで確かめる本番に近い条件

方式は、SaaS、オンプレミスやプライベートクラウド、フルスクラッチのほか、SaaSを基盤にした連携開発から選びます。どの方式が合うかは、何を優先するかで変わるため、方式ごとの向き不向きを並べて比べます。

SaaS・パッケージ：最新の脆弱性情報へ短期間で追随したい場合
オンプレミス・追加開発：閉域、データ保管、独自承認、資産DB統合が重要な場合
フルスクラッチ：固有要件と長期の保守体制が明確な場合

フルスクラッチでは、脆弱性データベースや検出ルールも自社で保守します。選定前のPoCでは、代表的な資産を試し、検出率や誤検知、本番負荷を確かめます。さらに、認証情報の保護、チケット起票、修正後の再確認も検証します。

検出から修正完了、証跡保存までの流れは、実演で示してもらいます。また、エージェントを入れられない資産も、PoCの対象に含めます。

フェーズ3：設計・開発で決めるデータと連携の境界

設計では、重複登録や連携停止に備えて、データを結ぶIDと連携の優先順位を決めます。対象は、名寄せ、資産識別、優先連携、段階導入の四つです。

IDと名寄せ：資産、脆弱性、検出結果、チケット、例外、再確認結果をIDで結び、重複登録を防ぎます。
資産識別：ホスト名、IP、クラウドID、エージェントIDを使い、所有部署の変更履歴や退役の記録
優先連携：SSO・MFA、クラウドAPI、CI/CD、SCA、SBOM、Jira・ServiceNow、メール・Slackから選ぶ連携先
段階導入と障害対策：重大脆弱性の通知・依頼を先行させ、API制限、再送、手動経路の設計

経営レポートや高度な分析は、運用を見ながら後から広げます。

フェーズ4：テストで確かめる検出精度と安全な運用

テストでは、資産登録から修正後の再スキャンまでを一連の流れとして確かめます。その中では、重大脆弱性の検出、チケット発行、期限超過、例外承認を見ます。重複検出や誤検知を、担当者が直せるかどうかも合否条件にします。

本番影響を避けるため、スキャンの時間帯、同時実行数、対象外ポートを決めます。加えて、負荷上限と緊急停止方法も定めます。

認証情報が平文でログに残らないことや、最小権限、期限切れの検知も確かめます。権限テストでは、閲覧と操作の範囲を担当ごとに分けます。対象は、セキュリティ担当、システム所有者、開発者、監査担当です。

フェーズ5：稼働での対象範囲の段階的な拡大

稼働開始時は、全社一斉ではなく、重要業務システムや公開資産から対象を広げます。初期対象では、資産カバレッジやスキャン完了率、重大脆弱性の期限内修正率、チケット担当の設定率を見ます。

問題があれば、検出ルールや通知先を直してから、次の部署へ展開します。手順書には、CVEスキャン（定期と緊急）から、トリアージ、通知、例外、再確認までの流れを載せます。さらに、月次報告と障害時の連絡先も記載します。

資産所有者、開発、インフラ運用、監査、経営層の役割は、RACIなどで明示します。脆弱性対応を、セキュリティ部門だけの仕事にしないことが欠かせません。

フェーズ6：定着のためのKPIと改善会議

定着の度合いは、月次で確認するKPIで測ります。

資産管理：資産カバレッジ
修正状況：重大脆弱性の期限内修正率、平均修正日数、期限超過件数
継続対応：例外残高、再発率、再スキャン完了率

検出件数が一時的に増えても、原因が未知資産の発見や台帳精度の向上であれば、改善として評価できます。

月次会議では、期限超過の理由を分類します。分類の区分は、パッチ待ち、業務停止の困難、所有者不明、誤検知、例外承認済みです。

修正できないレガシーOSや装置は、理由と影響範囲、責任者を記録します。さらに、代替策と期限、再評価日も残します。

代替策には、仮想パッチ、ネットワーク隔離、監視強化、利用停止計画があります。KPIが悪化したときは、原因を製品、台帳、担当ルールに分けて改善します。

ポイント

次の工程へ進むかどうかは、台帳の精度と、本番に近い条件で得た検出結果がそろっているかで判断します。成果物と合否条件を、その判断の目安にします。

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

規模が上がるにつれて、初期費用の推定幅も大きくなります。

費用は、ライセンス、初期設計・設定、台帳整理、連携開発に分けて見積もります。診断・再診断、教育、運用代行も、別の費目として扱います。ここに示す金額は、導入規模や公開価格、連携工数から算出した推定レンジで、確定価格ではありません。

金額は、資産数やサポート範囲によって変わります。そのため、社内稟議ではレンジと前提条件を併記します。

比較の基準としての公開価格

公開価格は比較の基準として使います。ただし、契約条件は別に確かめる必要があります。

Rapid7 InsightVM：500資産で1資産あたり月額1.62米ドルから。月額810米ドル、年額9,720米ドルです。
Rapid7の円換算：1米ドル150円で年額約146万円。条件で変わるため参考値です（出典：Rapid7 Product Pricing、2026年8月確認）。
Tenable Nessus Professional：1年4,790米ドルです。
Tenableの円換算：1米ドル150円で約72万円です（出典：Tenable「料金設定と購入オプション」、2026年8月確認）。
価格の範囲：Nessusは主に脆弱性評価用で、管理基盤全体の総額には含まれない。

Rapid7の金額は、契約期間、販売形態、サポート、追加機能、税、為替で変わります。そのため、予算のベンチマークとして扱います。

導入規模別の初期費用の推定レンジ

導入規模ごとの推定レンジを見比べ、対象資産と実施内容を前提に予算を組みます。

小規模PoC：100〜300資産で台帳・スキャン・基本レポート・通知を確認。初期50万〜200万円程度、1〜2か月程度。
年間利用料：製品・オプションにより60万〜200万円程度。
標準導入：300〜2,000資産、初期300万〜1,000万円程度、3〜6か月程度。
大規模導入：2,000資産超で複数会社、海外拠点、OT・IoT、CMDB、SBOM、独自フローを含む場合。
大規模導入の目安：初期1,000万〜3,000万円超、期間6〜12か月程度。自社開発が多いと上振れします。

PoCでは、代表的なサーバー、端末、クラウド、Webアプリを対象に、効果と本番影響を見極めます。一方で、標準導入には、エージェント、クラウド・SSO・ITSM連携、運用設計、教育を含めます。

初期費用と分けた運用費と診断費

初期費用とは分けて、診断の範囲と運用代行の内容を見積もります。

Securifyの月額：STARTERは5万円、BASICは10万円からです。
対象範囲：Webアプリ継続診断の価格で、サーバー、端末、ネットワーク、クラウドを含むVMDR製品とは異なります。
運用代行：一次トリアージ、パッチ依頼、月次報告、緊急CVE対応、監査資料のどこまで任せるかで変わります。
運用費の推定：小規模は月額10万〜50万円程度、中堅以上は月額50万〜200万円程度です。

Securifyの年間料金はSTARTERが60万円、BASICが120万円からです（出典：Securify「脆弱性診断料金プラン」、2026年8月確認）。

夜間対応やパッチ適用を含む場合は、個別に見積もります。診断、再診断、運用代行、ライセンスは、別行に分けて記載します。

ポイント

費用は公開価格を比較の基準にしつつ、資産数やサポート範囲、運用代行の範囲をそろえたうえで、レンジとして読むのが判断の目安です。

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

見積もりの精度は、対象範囲と運用ルールの具体性で決まります。そのため、資産数やネットワーク、検出方式をRFPや要件メモに記載します。連携先やSLA、成果物、保守範囲も、あわせて書いておきます。

「脆弱性を管理できるシステム」といった書き方だと、製品、開発、診断、運用の費用が混ざり、会社ごとの金額を比べにくくなります。

見積依頼書に書く対象資産と合否条件

資産は、種類別の台数や増加予定、クラウドアカウント数を記載します。公開状況、閉域ネットワーク、エージェント可否も書き添えます。検出方式、対象外資産、代替手段は、それぞれ分けて明示します。

検出方式には、エージェント、ネットワーク・認証付きスキャン、クラウドAPI、Webアプリ診断があります。さらに、SAST・DAST・SCA、SBOMもあります。利用する方式は、見積依頼で指定します。

合否条件は、資産捕捉率、重大脆弱性の通知時間、チケット発行条件、再スキャンの証跡で定めます。月次成果には、期限内修正率や平均修正日数、期限超過理由も含めます。

同じ前提と内訳で比べる複数社の見積もり

各社には、同じ資産数、対象環境、連携先、導入期間を前提として示します。比較表では費目を分け、対象範囲や不要な機能の差も確かめます。

導入・移行：初期設定、台帳移行、名寄せ、連携開発、テスト
継続費：ライセンス、保守、運用代行
診断・教育：診断、再診断、利用者教育

製品ベンダーには、検出能力と更新頻度を確かめます。導入会社には、台帳整理やネットワーク許可、チケット運用、教育、社内調整への支援を確かめます。

候補企業には、同規模での導入実績や誤検知・例外の運用、日本語サポートと緊急SLAを質問します。契約終了時のデータ返却や不在時の引き継ぎも、聞いておきます。

見積もりに含まれないリスク

見落としやすい作業を洗い出し、発注側と受注側の責任を作業ごとに確かめます。発注側の作業として一括で外すと、期間延長や追加費用につながります。

環境準備：台帳整理、クラウド権限、ネットワーク許可
既存環境対応：古いOSの例外、データ移行、チケット項目の調整
運用準備：教育、監査資料、検出後の修正担当

導入後も、パッチ適用が自動で完了するとは限りません。停止の調整や検証、変更承認、バックアウト、再起動は、資産所有者や運用チームが判断します。

夜間対応の要否と、重大CVEの公開時に臨時で対応するかどうかも、見積もりに明記します。

ポイント

見積もりは、資産数や対象環境、合否条件を同じ前提にそろえて比べられるかで判断します。含まれない作業の責任が明記されているかも、確かめる目安になります。

よくある質問（FAQ）

導入前に確かめておきたい、開発方法、製品選び、スキャンの安全性、古い資産への対応について、よくある疑問への答えを示します。

脆弱性管理システムはパッケージとスクラッチのどちらがよいですか？

多くの企業では、SaaSやパッケージを基盤に、独自の承認やチケット連携だけを追加開発する方法が現実的です。脆弱性情報と検出ルールの更新負担を抑えられるからです。

製品では満たせない閉域やデータ保管、独自の業務フローがあり、長期の保守体制も明確な場合は、オンプレミスやスクラッチを検討します。

自動スキャンで本番システムが停止することはありますか？

方式や設定、対象システムの性能によっては、負荷や通信の影響が出る可能性があります。そのため、PoCとテストで条件を確認し、本番導入は段階的に行います。

実行条件：時間帯、同時実行数、対象外設定、負荷上限
停止と方式：緊急停止方法、高負荷資産へのエージェントや低負荷スキャン

CVSSの点数が高い順に対応すればよいですか？

CVSSは判断材料の一つですが、点数だけで順番を決めるのは不十分です。事業影響の大きいリスクを優先し、その理由を担当者に説明できるようにします。

判断では、公開状況や悪用コードの実績、業務重要度を組み合わせます。さらに、機密情報や攻撃経路、補完策、パッチ適用の難しさも材料にします。

パッチを適用できない古いOSや機器はどう管理しますか？

パッチを適用できない資産は、例外として放置せず、代替策と期限を管理します。あわせて、理由や影響範囲、責任者、再評価日をシステムに記録します。

代替策：仮想パッチ、ネットワーク隔離、アクセス制限、監視強化
期限付き管理：利用停止や更改を計画し、リスクオーナーが期限付きで承認

無期限の例外承認は、担当者しか内容を把握できない状態になりやすいため、再評価日を設けます。

まとめ

開発は6フェーズで考え、最初は要件整理と選定、PoCで進めます。続く設計・開発から、テスト、稼働を経て定着へ進みます。優先順位は、資産の種類、所有者、公開範囲、EOL、重要度を把握してから決めます。

CVSSに加えて業務影響や悪用実績も使い、担当者への依頼から期限、例外、再確認、証跡までを一つの流れにします。

重要資産から始める小規模な導入

費用は、ライセンス、初期設定、連携、診断、教育、運用代行に分けて考えます。そのうえで、PoCと標準導入の規模別の費用を比べます。

100〜300資産のPoCは初期50万〜200万円程度、300〜2,000資産の標準導入は初期300万〜1,000万円程度が推定の目安です。ただし、範囲と契約条件によって変わります。

全社導入の前に、公開資産や重要業務で、検出精度と修正完了までの時間を測ります。

定着まで含めた発注範囲

運用の定着と発注範囲は、次のとおりに整理します。

運用：台帳の更新、期限内の修正、例外期限の管理、再スキャンによる確認を定着させます。
責任分界：発注側・導入会社・製品ベンダーの作業の分け方と、終了時のデータ返却や移行条件
支援：専門担当者が少ない場合の、教育や月次レビューによる個人依存の抑制
継続改善：発見、評価、対応、再確認の繰り返しと、KPIを見ながらの対象・連携の拡大

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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