SOC運用システムの発注では、監視対象・監視時間・検知後の対応範囲・データ保管地域・SLAをRFPに明記し、複数社へ同じ条件で見積もりを依頼することが、費用と品質のミスマッチを避ける最短の方法です。
「SOCを外注したいが、何から手を付ければよいかわからない」という相談は少なくありません。発注形態の選び方、RFPに書くべき項目、契約形態、費用相場、委託先を比較する視点を最初に押さえておかないと、契約後に「検知はしてくれるが対応はしてくれない」といった認識のずれが生じやすくなります。本記事では、SOC運用システムの発注・外注・委託方法について、発注前の準備からRFPの書き方、契約形態、委託先の選び方、よくある質問まで順に解説します。
▼全体ガイドの記事
・SOC運用システム開発の完全ガイド
SOC運用システムの発注形態にはどのような選択肢がありますか?

SOC運用システムの発注形態は、既製のMDR・SOCaaSを契約する方式、クラウドSIEMと外部運用会社を組み合わせる方式、SIEMパッケージをSIerに構築・運用してもらう方式、スクラッチで内製SOCを新設する方式の4通りに大別されます。それぞれ、初期費用、月額費用、社内に残る責任範囲、カスタマイズ性が異なるため、発注前に自社の優先順位を明確にしておく必要があります。
発注形態を選ぶ判断軸
専門人材が不足しており、最短で24時間365日の監視体制を整えたい場合は、既製のMDR・SOCaaSが最も導入しやすい選択肢です。複雑な既存環境があり、国内サポートを重視する場合はSIEMパッケージ+SIer構築が候補になり、特殊なOT環境や厳格なデータ管理要件、高度な自社ノウハウの蓄積を優先する場合はスクラッチによる内製SOCが検討対象になります。現実的には、クラウドSIEMまたはMDRを先行させ、必要な差分だけカスタム開発する段階導入が多く選ばれています。
発注形態を決める段階では、コンサルティング会社に相談する「LASSIC」のような外部の解説記事でも、外注する範囲と社内に残す責任をあらかじめ切り分けることが強調されています(出典: LASSIC「SOCによるセキュリティ監視運用を外注する進め方」、2026年確認)。発注前に自社だけで判断せず、外部の知見も参考にしながら、対応範囲の境界を具体化しておくことが有効です。
社内に残す責任範囲を先に決めます
発注形態によらず共通して重要なのは、検知後にベンダーがどこまで自動または半自動で操作できるのか、業務停止や顧客通知などの最終判断を誰が下すのかを最初に決めておくことです。委託先に丸投げしても、事業者側の説明責任が消えるわけではないため、検知・通知・封じ込め・復旧・法定報告の各段階について、社内の責任者を明確にしたうえで発注形態を選定します。
段階導入で対象範囲を広げていく進め方
発注形態を一度に確定させず、認証基盤とEDR、インターネットに公開しているサーバーなど、攻撃を受けやすい領域から先に接続し、運用が安定してからクラウド環境、子会社、OT機器へと対象範囲を広げていく進め方も有効です。全社のログを一括で取り込もうとすると、初期費用と月額費用が想定より膨らみやすいだけでなく、アラートの量に運用体制が追いつかず、重要な検知が埋もれる原因にもなります。まずは重要度の高い数系統のログでアラートの質を確認し、誤検知率や連絡フローに問題がないことを確かめたうえで、段階的に監視対象を拡大する方が、発注後のトラブルを抑えやすくなります。
RFPと要件整理で押さえるべき項目

RFPの完成度が、そのまま見積もりの比較しやすさに直結します。「SOCを作りたい」という曖昧な依頼のまま発注先を探すと、各社の提案前提がばらばらになり、金額だけを見た誤った判断につながります。以下の項目を、可能な範囲で数値まで具体化してRFPに落とし込みます。
対象資産とユースケースを明記します
RFPには、対象資産(端末数、ネットワーク機器、クラウド環境、OT機器、委託先を含むか)、対象ログ種別、監視時間(24時間365日か営業時間中心か)、優先して検知したいユースケース(不正ログイン、ランサムウェア、特権ID悪用、異常なデータ転送など)、重大度別のSLA、通知手段、エスカレーション条件を記載します。ユースケースの優先順位を明確にしておくと、各社が提案する検知ルールの妥当性を判断しやすくなります。検知ルールの説明を受ける際は、MITRE ATT&CKのどの戦術・技術に対応しているかを合わせて確認すると、「検知できます」という抽象的な回答ではなく、具体的にどの攻撃手口を想定したルールなのかを比較しやすくなります。
封じ込め権限と法定報告の分界を明記します
検知後の対応範囲についても、封じ込め権限(端末隔離や認証失効をベンダーが実行できるか)、データ保管地域(国内保管の要否)、再委託の可否、契約終了時のログ返却・移行方法、インシデント発生時1件あたりの追加費用の有無を明記します。個人情報保護委員会への報告が必要になる漏えい等の要件(要配慮情報を含む場合、財産的被害のおそれがある場合、不正目的による場合、1,000人超の場合)に該当する事態が起きた際の連絡フローと役割分担も、RFPの段階から検討しておくことが望まれます(出典: 個人情報保護委員会「漏えい等の対応とお役立ち資料」、2026年確認)。
机上演習でフローを検証してから本番監視に入ります
RFPに記載した連絡フローや封じ込め権限は、書面上は整っていても、実際の緊急時に機能するとは限りません。契約開始前後には、模擬的なインシデントを想定した机上演習を実施し、検知から通知、責任者への連絡、封じ込め判断、必要に応じた法定報告までの一連の流れを、委託先と自社の双方が同じ手順で動けるかを確認しておきます。通信遮断や端末隔離を実際に試すテストも合わせて実施すると、想定していた対応時間と実際にかかる時間のずれを事前に把握できます。
契約形態と費用相場

SOC運用の委託契約は、月額固定のサブスクリプション型が中心ですが、初期構築を請負契約、月次の運用を準委任契約に分ける段階契約も一般的です。要件と成果物が明確な接続開発やダッシュボード構築は、完成条件を定めた請負契約が適する場合があり、継続的な監視・分析・改善は、作業範囲と体制を定めた準委任やサブスクリプション契約が適しています。
規模別の費用相場
小規模(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万円が目安とされ、50〜300名規模の企業ではログ監視が月額5万〜15万円、EDR運用が月額10万〜25万円、フルマネージドセキュリティが月額30万〜50万円という水準が示されています(出典: 情シス365「セキュリティ対策の外注費用相場」、2026年版)。
契約書に明記すべき条件
契約書には、月額費用に含まれる対応範囲、追加費用が発生する条件(監視対象外のSaaS、ログの超過、追加端末、夜間対応、重大インシデント対応費)、SLA未達時の取り扱い、再委託先の管理体制、契約終了時のログ返却・データ消去の方法を明記します。特に、重大インシデント1件あたりの対応費用が定額なのか都度見積もりなのかは、契約時に必ず確認しておくべき項目です。
費用は4つの軸に分解して比較します
見積もりを総額だけで比較すると、各社の前提の違いを見落としやすくなります。SOC運用の費用は、端末数に応じた端末課金、ログの取り込み量に応じたGB/日課金、アナリストの稼働に応じた人月課金、インシデント発生時の従量課金という4つの軸に分解して考えると、自社の環境でどの費目が膨らみやすいかを把握しやすくなります。クラウドのログ取り込み量が多い環境ではGB/日課金が費用を左右しやすく、拠点が分散して端末数が多い環境では端末課金と人月課金の比重が大きくなる傾向があります。見積もりを依頼する際は、この4区分ごとの単価と、どの区分が変動しやすいかを合わせて確認しておくと、契約後の想定外の増額を防ぎやすくなります。
委託先選定と見積比較のポイント

委託先選定は、製品名の知名度ではなく、監視対象の実績、検知・通知・封じ込め・復旧の境界、重大度別のSLA、日本語での連絡と国内保管の可否、再委託・認証・ログ返却の条件、既存EDR/SIEMからの移行性、演習と改善レポートの頻度という同じ表で比較することが重要です。
PoCの合否基準を事前に決めます
本格契約の前に、重要度の高い2〜4ソースだけを接続したPoCを実施し、誤検知率、分析時間、連絡フローの実態を検証します。PoCの合否基準(誤検知率の許容水準、通知までの目標時間、レポートの分かりやすさなど)を事前に数値で決めておくことで、複数の候補ベンダーを同じ基準で客観的に比較できます。
月次レビューの質問例を用意します
契約後は、重大度別件数、MTTD、MTTR、誤検知率、未対応アラート件数、資産カバレッジ、SLA達成率を月次レビューで確認します。「今月検知した重大アラートのうち、実際にインシデントだったものは何件か」「誤検知として除外したルールは何件あり、どう改善したか」といった具体的な質問例を事前に用意しておくと、委託先の実務対応力を継続的に評価できます。
セキュリティ体制と再委託先まで確認します
委託先自身のセキュリティ体制も評価対象です。監視基盤や分析ツールへのアクセス制御、担当アナリストの権限管理、脅威インテリジェンスの取得元、監査ログの保存期間を確認し、委託先が別のベンダーへ一部業務を再委託している場合は、再委託先の名称、作業範囲、アクセス可能なデータ、事故発生時の連絡経路まで開示してもらいます。委託先の説明が曖昧な場合、自社のログや検知ルールが想定外の第三者に扱われるリスクが残るため、契約前の質問リストに必ず含めておくべき項目です。
よくある質問(FAQ)

ここでは、SOC運用システムを発注する前に特に質問されやすい論点をまとめます。発注形態や契約条件は、対象業種、既存システムの状態、社内のセキュリティ人材によって最適解が変わるため、自社の条件に置き換えて検討してください。
RFPに最低限書くべき項目は何ですか?
対象資産、ログ種別、監視時間、SLA、通知手段、封じ込め権限の有無、データ保管地域、再委託の可否、インシデント対応費用の有無、契約終了時のデータ返却・移行方法の10項目は最低限記載してください。これらが揃っていないと、各社の提案前提がばらばらになり、金額の単純比較ができなくなります。
請負契約と準委任契約はどう使い分ければよいですか?
初期構築のようにゴールと成果物が明確な作業は、完成条件を定めた請負契約が適します。継続的な監視・分析・改善のように、発注時点で成果の形を固定しにくい業務は、作業範囲と体制を定めた準委任契約やサブスクリプション型の契約が進めやすくなります。段階契約として、初期構築を請負、月次運用を準委任に分ける方法も一般的です。
委託先を変更する場合、どのような点に注意すればよいですか?
契約終了時のログ・検知ルール・過去のインシデント記録の返却形式、移行期間中の並行監視の可否、新旧ベンダー間の引き継ぎ体制を事前に確認します。移行期間中に監視が手薄になると、その隙を突かれるリスクが高まるため、切り替え時には必ず並行稼働期間を設け、段階的に移行することが望まれます。
監視のみの契約とMDR(検知・対応込み)の契約はどう違いますか?
監視のみの契約は、アラートの検知と通知が中心で、実際の端末隔離や認証失効、フォレンジック調査は自社対応か別料金の追加契約になります。MDRの契約は、検知後の初動対応まで含む場合が多く、月額費用は高くなりますが、専門人材が不足している企業でも初動の遅れを防ぎやすくなります。自社にインシデント対応チームがあるかどうかを基準に、どちらの契約形態が適しているかを判断してください。
AIやSOARを導入すれば、監視は完全に自動化できますか?
AIによる異常検知やSOARによる自動対応は、アラートの一次仕分けや定型的な通知・チケット発行を効率化するうえで有効ですが、業務停止や顧客通知を伴う最終判断を完全に任せられる段階には至っていません。自動隔離の誤作動が業務に影響するリスク、AIがなぜその判定を下したのかを説明できるかどうか、委託先の再委託先を含めたサプライチェーン全体の管理、ログの保管地域といった論点は、発注前に確認しておく必要があります。AIやSOARは、アナリストの負荷を減らしトリアージの精度を高めるための補助として位置づけ、最終判断は自社の責任者が担う体制を前提に発注することが望まれます。
まとめ

SOC運用システムの発注は、価格だけを比較して決めるものではありません。発注形態を自社の人材・環境に合わせて選び、対象資産や対応範囲をRFPに具体化し、契約形態とSLAを明確にしたうえで、委託先を同じ基準で比較することが、導入後の運用品質を左右します。
発注で優先する3つのポイント
第一に、発注形態を決める前に社内に残す責任範囲を明確にすることです。第二に、対象資産、監視時間、対応範囲、データ保管地域をRFPに具体的に書き出し、複数社を同じ条件で比較することです。第三に、PoCの合否基準と月次レビューの質問例をあらかじめ用意し、契約後も継続的に品質を検証できる体制を作ることです。
まずは対応範囲の境界を一枚の資料にまとめます
次の一歩は、検知・通知・封じ込め・復旧・法定報告のそれぞれについて、社内が担う範囲と委託先に任せたい範囲を一枚の資料にまとめることです。その資料をもとにRFPを作成し、複数社から同じ条件で提案を受けることで、価格だけでなく対応範囲まで含めた実質的な比較ができるようになります。あわせて、契約開始後すぐに本番監視へ移行するのではなく、限定範囲でのPoCやトライアル運用を挟むことで、実際の通知の質や連絡の速さを体感してから本契約に進めると、発注後のギャップを最小限に抑えられます。
▼全体ガイドの記事
・SOC運用システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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