まず発注形態と社内の責任範囲を決め、RFPで依頼条件をそろえ、PoCで検証してから本契約に進みます。この順番で進めると、費用と運用品質のミスマッチを防げます。
発注形態の選び方から委託先の比べ方まで、順に見ていきます。全体像はSOC運用システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・SOC運用システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SOC運用システムの発注形態の種類
SOC運用システムの発注は、既製のMDR・SOCaaSを契約する方式と、クラウドSIEMと外部運用会社を組み合わせる方式に大きく分けられます。さらに、SIEMパッケージをSIerに構築・運用してもらう方式や、スクラッチで内製SOCを新設する方式を含めると、4通りになります。
発注形態によって、費用や社内に残る責任範囲、カスタマイズ性が異なります。そのため、自社の優先順位を先に決めておく必要があります。
発注形態を選ぶ判断基準
発注形態は、24時間監視の早期整備、複雑な既存環境への対応、データ管理やノウハウ蓄積のうち、どれを優先するかで選びます。
- MDR・SOCaaS：専門人材が不足していて、24時間365日の監視を最短で整えたい場合に向きます。
- クラウドSIEMと運用会社：監視の仕組みと外部会社の運用を組み合わせる方式です。
- SIEMパッケージとSIer：複雑な既存環境があり、国内サポートを重視する場合に候補になります。
- スクラッチ内製SOC：特殊なOT環境、厳格なデータ管理、高度なノウハウ蓄積を優先する場合に検討します。
実際には、クラウドSIEMやMDRを先に導入し、必要な差分だけをカスタム開発する段階導入も多く選ばれています。
LASSICの解説記事も、外注する範囲と社内に残す責任を先に分けることの重要性を示しています（出典: LASSIC「SOCによるセキュリティ監視運用を外注する進め方」、2026年確認）。こうした考え方を参考に、対応範囲の境界を具体的に決めます。
社内に残す責任範囲の決め方
委託先が検知後に自動または半自動で操作できる範囲と、業務停止や顧客通知の最終判断者は、事前に決めておく必要があります。
委託しても、事業者側の説明責任はなくなりません。そのため、検知から法定報告までの各段階について、社内の責任者を明確にしておきます。
段階導入で対象範囲を広げていく進め方
発注形態を一度に確定させず、段階的に接続を広げていく方法があります。段階を踏む場合は、次の順に進めます。
- 認証基盤、EDR、公開サーバーなど、攻撃を受けやすい領域から接続します。
- 重要度の高い数系統のログを使ってアラートの質を確かめ、誤検知率や連絡フローに問題がないかを見ます。
- 運用が安定したら、クラウド環境、子会社、OT機器へと監視対象を広げます。
全社のログを一括で取り込むと、初期費用と月額費用が想定より膨らみやすくなります。さらに、アラートの量に運用体制が追いつかず、重要な検知が埋もれる原因にもなります。そのため、段階的に監視対象を広げる方が、発注後のトラブルを抑えられます。
RFPと要件整理で押さえるべき項目
RFPの完成度は、見積もりを比べやすいかどうかに直結します。「SOCを作りたい」といった依頼だけでは、各社が前提にする条件がばらばらになり、金額だけで誤った判断を招きます。
そこで、可能な範囲で数値を具体化し、依頼条件をそろえます。記載する内容は、項目ごとに整理しておきます。
対象資産とユースケースの明記
監視対象と検知条件を同じ粒度で伝えると、各社の提案内容を比べやすくなります。RFPには、次の情報を盛り込みます。
- 対象資産・ログ：端末数、ネットワーク機器、クラウド、OT機器のほか、委託先の対象有無やログ種別。
- 監視時間・SLA：24時間365日か営業時間中心か、重大度別のSLA。
- 検知ユースケース：不正ログイン、ランサムウェア、特権ID悪用、異常なデータ転送など。
- 連絡条件：通知手段とエスカレーション条件。
ユースケースに優先順位を付けておくと、各社が提案する検知ルールの妥当性を判断する材料になります。また、各社のルールがMITRE ATT&CKのどの戦術・技術に対応するかも確かめておくと、想定する攻撃手口を具体的に比べられます。
封じ込め権限と法定報告の境界の明記
契約後に追加費用やデータ管理の認識違いが生じないよう、対応条件をRFPで明確にしておきます。
- 操作権限：端末隔離や認証失効を、委託先が実行できるか。
- データ管理：国内保管の要否と再委託の可否。
- 契約終了時：ログの返却方法と移行方法。
- 追加費用：インシデント1件あたりの費用の有無。
個人情報保護委員会への報告が必要になる漏えい等の要件も、RFPの段階から確認しておきます。要配慮情報を含む場合や、財産的被害のおそれがある場合が該当します。また、不正目的による場合や、1,000人超の場合も該当します（出典: 個人情報保護委員会「漏えい等の対応とお役立ち資料」、2026年確認）。
該当する事態が起きたときの連絡フローと役割分担も、RFPの段階で検討しておきます。
机上演習によるフローの検証
書面で整えた連絡フローや封じ込め権限も、緊急時に機能するとは限りません。
そこで、契約の開始前後に模擬インシデントの机上演習を行います。検知、通知、責任者への連絡、封じ込め判断、必要な法定報告までの一連の流れで、双方が同じ手順で動けるかを確かめます。さらに、通信の遮断や端末の隔離も試しておくと、想定した対応時間と実際の所要時間のずれを把握できます。
契約形態と費用相場
SOC運用は、月額固定のサブスクリプション型が中心です。また、初期構築を請負、月次運用を準委任とする段階契約も一般的です。
接続開発やダッシュボード構築は、要件と成果物が明確であれば、請負契約が適する場合があります。一方、継続監視や分析、改善は、作業範囲と体制を定めた準委任やサブスクリプション契約が向いています。
規模別の費用相場
監視対象の規模と構成が違えば、同じSOCでも費用の水準は大きく変わります。下の4区分は、規模と構成ごとに、初期費用、月額費用、導入期間の目安を並べたものです。
- 小規模：EDR＋MDR、数十〜300端末、既存製品中心。初期費用50万〜300万円、月額10万〜60万円、期間2週間〜2か月。
- 標準：SIEM＋複数ログソース、300〜1,000端末、24時間監視。初期費用200万〜1,000万円、月額30万〜150万円、期間1〜3か月。
- 中堅〜大規模：クラウド・拠点・子会社・複数EDRを統合。初期費用500万〜2,000万円、月額100万〜300万円、期間3〜6か月。
- OT・重要インフラ：専用構築では、初期費用1,000万〜5,000万円以上、月額200万〜500万円以上、期間6〜12か月になる場合もあります。
情シス365の2026年版では、セキュリティ監視の外注費の目安が、初期30万〜200万円、月額10万〜150万円とされています（出典: 情シス365「セキュリティ対策の外注費用相場」、2026年版）。
同資料では、50〜300名規模の企業でログ監視が月額5万〜15万円です。また、EDR運用は月額10万〜25万円、フルマネージドセキュリティは月額30万〜50万円です。
契約書に明記すべき条件
契約書では、月額に含まれる対応範囲と、追加費用が発生する条件を明確にしておきます。
- 追加料金：監視対象外のSaaS、ログの超過、追加端末、夜間対応、重大インシデント対応費。
- 品質・体制：SLA未達時の扱いと再委託先の管理体制。
- 契約終了時：ログ返却とデータ消去の方法。
特に、重大インシデント1件あたりの対応費用が定額か都度見積もりかは、契約時に必ず確認します。
費用を4区分に分けた比較
総額だけを見ると、各社の見積もり前提を見落とします。そこで、費用を次の4区分に分けて確認します。
- 端末課金：端末数に応じた費用。
- GB/日課金：ログの取り込み量に応じた費用。
- 人月課金：アナリストの稼働に応じた費用。
- 従量課金：インシデントの発生に応じた費用。
クラウドログが多い環境では、GB/日課金が費用を大きく左右します。一方、拠点が分散して端末が多い環境では、端末課金と人月課金の比重が高まります。
見積もりでは、各区分の単価と変動のしやすさも確認しておくと、契約後の想定外の増額を防ぎやすくなります。
委託先選定と見積比較のポイント
製品名の知名度より、監視対象の実績や、検知から復旧までの境界、重大度別のSLAを優先して、同じ表で比べます。そのうえで、日本語での連絡と国内保管の可否を確認します。
再委託や認証、ログ返却の条件も、契約前に確かめておきます。さらに、既存のEDR・SIEMからの移行性や、演習と改善レポートの頻度も比較項目に含めます。
PoCの合否基準の事前設定
本契約の前に、重要度の高い2〜4ソースだけをつなぐPoCを行い、誤検知率や分析時間、連絡フローの実態を確かめます。
誤検知率の許容水準、通知までの目標時間、レポートの分かりやすさは、数値で定めておきます。そうすると、候補ベンダーを同じ基準で客観的に比べられます。
月次レビューの質問例
月次レビューでは、確認する指標と質問例をあらかじめ用意しておきます。
- 確認指標：重大度別件数、MTTD、MTTR、誤検知率、未対応アラート件数、資産カバレッジ、SLA達成率。
- 重大アラート：「今月検知した重大アラートのうち、実際にインシデントだったものは何件か」と尋ねます。
- 誤検知：「誤検知として除外したルールは何件あり、どう改善したか」も質問します。
こうした質問を用意しておくと、委託先の実務対応力を継続して評価できます。
セキュリティ体制と再委託先の確認
委託先自身の体制と、再委託先が扱う範囲を、次の観点で確認します。
- アクセス管理：監視基盤や分析ツールへのアクセス制御、担当アナリストの権限管理。
- 監査情報：脅威インテリジェンスの取得元と、監査ログの保存期間。
- 再委託先：委託先名、作業範囲、アクセス可能なデータ、事故時の連絡経路を開示してもらいます。
説明が曖昧なままだと、自社のログや検知ルールが想定外の第三者に扱われるおそれがあります。そのため、この確認は契約前の質問リストに含めておきます。
よくある質問（FAQ）
SOC運用システムの発注前に、特によく質問される論点を取り上げます。
発注形態や契約条件は、対象業種、既存システムの状態、社内のセキュリティ人材によって異なります。そのため、下の回答は、自社の条件に置き換えて検討してください。
RFPに最低限書くべき項目は何ですか？
RFPには、対象資産とログ種別、監視時間、SLA、通知手段を記載します。あわせて、封じ込め権限、データ保管地域、再委託の可否も書いておきます。
インシデント対応費用の有無や、契約終了時のデータ返却・移行方法も含めて、最低限10項目は必要です。項目がそろわないと、各社の提案前提がばらばらになり、金額を単純には比べられません。
請負契約と準委任契約はどう使い分ければよいですか？
初期構築のように、ゴールと成果物が明確な作業には、完成条件を定めた請負契約が適します。
継続監視や分析、改善は成果を固定しにくいため、作業範囲と体制を決めた準委任やサブスクリプションが向いています。また、初期構築を請負、月次運用を準委任とする段階契約も一般的です。
委託先を変更する場合、どのような点に注意すればよいですか？
ログや検知ルール、過去のインシデント記録を、どの形式で返してもらうかを確認します。あわせて、移行期間中の並行監視と、新旧ベンダーの引き継ぎ体制も決めます。
移行期間中に監視が手薄になると、その隙を突かれるリスクが高まります。そのため、切り替え時には並行稼働期間を設け、段階的に移行することが望まれます。
監視のみの契約とMDR（検知・対応込み）の契約はどう違いますか？
監視のみの契約は、検知と通知が中心です。一方で、端末隔離や認証失効、フォレンジック調査は、自社で対応するか別料金になります。
MDRは、検知後の初動対応まで含む場合が多く、その分、月額費用は高くなります。ただし、専門人材が不足する企業でも、初動の遅れを防ぎやすくなります。
自社にインシデント対応チームがあるかどうかで、契約形態を判断してください。
AIやSOARを導入すれば、監視は完全に自動化できますか？
完全な自動化はできません。そのうえで、効率化できる作業と、人が担う判断、発注前に確認すべき点を分けて整理します。
- 効率化：AIの異常検知やSOARの自動対応は、アラートの一次仕分けや定型的な通知、チケット発行の省力化に有効です。
- 最終判断：業務停止や顧客通知を伴う判断は、自社の責任者が担う体制を前提に発注することが望まれます。完全に任せられる段階にはまだありません。
- AIの役割：AIやSOARは、アナリストの負荷を減らし、トリアージの精度を高める補助として位置づけます。
- 自動隔離・AIの判定：誤作動が業務に影響するリスクや、AIがその判定に至った理由を説明できるかを確かめます。
- 発注前の確認：再委託先を含むサプライチェーン全体の管理と、ログの保管地域。
まとめ
SOC運用システムの発注では、価格の比較に加えて、自社の人材や環境に合う形態を選び、条件をそろえて委託先を比べることが欠かせません。
特に、対応範囲や契約形態、SLAを明確にしておくことが、導入後の運用品質を左右します。
発注で優先する3つのポイント
発注準備では、責任分担、RFP、契約後の品質確認の順に整えます。
- 責任範囲：発注形態を決める前に、社内の責任を明確にしておきます。
- RFP：対象資産、監視時間、対応範囲、データ保管地域を具体化します。
- 品質確認：PoCの合否基準と、月次レビューの質問を準備します。
対応範囲の境界を一枚にまとめる進め方
発注前の準備は、社内の責任の整理から契約前の検証まで、次の順に進めます。
- 検知、通知、封じ込め、復旧、法定報告のそれぞれについて、社内と委託先の担当範囲を一枚にまとめます。
- その資料をもとにRFPを作成し、複数社から同じ条件で提案を受けて、価格と対応範囲を比べます。
- 本番監視の前に限定範囲のPoCやトライアルで通知の質や連絡の速さを体感し、その結果を踏まえて本契約に進めば、発注後のギャップを最小限に抑えられます。
▼全体ガイドの記事
・SOC運用システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。