SOC構築にいくらかかり、何から始めるべきか。人件費・ツール・運用という費用の構成要素、24時間365日シフトに必要な人数の算出ロジック、Microsoft Sentinelの課金モデルを例にしたログ量課金の考え方、構築の6ステップと中堅企業がつまずく点、AIエージェントで変わる費用構造を解説します。
「来期までにSOCを立ち上げてほしい」。取引先からのセキュリティ調査票、監査での指摘、同業他社のランサムウェア被害の報道をきっかけに、情報システム部門がこう指示される場面が増えています。しかし、指示を受けた側の実情は厳しいものです。数名の兼務体制で日中の運用を回すのが精一杯で、夜間や休日にアラートを見ている人はいない。SIEMを入れるにしてもログ量に応じた費用の見通しが立たず、監視要員を何人採ればよいのかも分からない。「SOC構築にいくらかかるのか」「何から手を付けるのか」に社内で答えられる人がいないことが、最初の壁になります。
背景にあるのは、脅威が企業規模を選ばなくなったことです。IPAが2026年1月に公開した「情報セキュリティ10大脅威 2026」の組織向けランキングでは、「ランサム攻撃による被害」が11年連続で選出され、2026年版で1位、「サプライチェーンや委託先を狙った攻撃」が2位となりました（IPA, 2026）。警察庁の報告では、令和7年のランサムウェア被害報告件数は226件で、被害組織の約6割を中小企業が占め、復旧に総額1,000万円以上を要した組織は全体の5割を超えています（警察庁, 2026）。中堅企業そのものが標的であり、被害を早く見つけて止める機能を持たない代償は小さくありません。
本記事では、SOC（Security Operations Center：セキュリティの監視・分析・対応を担う組織や機能）を中堅企業が構築する際の費用の構成要素、24時間365日体制に必要な人数の算出ロジック、構築の6ステップを整理します。金額は、公開資料で確認できる課金モデルと計算式を示すにとどめ、環境によって大きく変わる具体的な金額は提示しません。SOCの役割やTier体制の基本は、ピラー記事「SOCとは？役割・Tier体制・24時間365日運用の基本と限界」をご参照ください。
SOC構築の3つの形：内製・外部委託・ハイブリッド、そしてAI活用
SOCの構築方法は大きく3つに分かれます。自社で人員とツールを揃える内製、MSS（Managed Security Service：監視・運用を請け負うサービス）やMDR（Managed Detection and Response：検知後の調査・対応支援まで含むサービス）に監視を委ねる外部委託、一次監視は外部に委ねて判断と対処、環境知識の整備は社内に残すハイブリッドです。多くの中堅企業が現実的に選ぶのはハイブリッドですが、どの形でも「アラートを受けた後に、誰が調査し、判断し、対処するか」という工程が自社に残る点は共通しています。三者の費用・人材・品質・スピードの比較は「SOCの内製と外部委託（MSS/MDR）を徹底比較」で扱っているため、本記事では費用の構成と構築手順に焦点を絞ります。
近年はこの3つに加え、調査・判断の工程をAIエージェントに担わせる「AI活用」が、いずれの形にも横串で入る第4の要素になっています。形態を問わず費用構造に影響するため、本記事の最後で改めて取り上げます。
SOC構築費用の構成要素：人件費・ツール・運用
SOCの費用は「人件費」「ツール費用」「運用費用」の3つに分解すると見通しが立ちやすくなります。見積書に表れやすいのはツール費用ですが、24時間365日体制を人で維持する場合、総額の大部分を占めるのは人件費です。
人件費：24時間365日シフトに必要な人数の算出ロジック
「SOCの人員は何人必要か」は最も多く受ける質問ですが、答えは4つの変数で決まります。①同時に何人がアラートを見るか（席数）、②何時間カバーするか（平日日中のみか、24時間365日か）、③一次監視だけか、深い調査や検知ルール保守を担う上位アナリスト（Tier2・Tier3）まで自社で持つか、④専任か兼務か、です。
一般的な算出ロジックを、24時間365日・1席の場合で示します。1週間は168時間ですから、1席を途切れなく埋めるには週168時間分の勤務が必要です。アナリスト1人の所定労働時間を週40時間とすると、168÷40＝4.2人分が「休みなく働き続けた場合」の必要人数です。しかし実際には有給休暇、病欠、研修、引き継ぎがあり、席に着ける時間は所定労働時間より少なくなります。実働可能時間の比率（稼働率）を8割と置けば4.2÷0.8＝5.25となり、切り上げて6名が1席の目安です。深夜帯に判断を1人に委ねない相互確認の体制を取るなら席数は2となり、人数は倍になります。そのうえで、Tier2以上の調査担当、SIEMの検知ルールを保守するエンジニア、全体を統括するマネージャーは、この計算の外側に別途必要です。
この人数に掛ける単価は、給与だけで見積もると過小になります。給与に法定福利費、深夜・交代勤務の手当、採用費、育成費を加えた「フルコスト」を年額で置くのが実務上の目安です。特に育成と定着の費用は見落とされがちです。ISC2の調査では、世界のサイバーセキュリティ人材の不足数は約476万人と前年から19.1%増え、回答者の26%が需要の高いスキルを持つ人材の定着に困難を感じ、半数超が新しいスキルを学ぶ時間が足りないと答えています（ISC2 Cybersecurity Workforce Study, 2024）。採用できたとしても、育成の時間と、離職を前提にした引き継ぎのコストを織り込む必要があります。
ツール費用：SIEMのログ量課金、EDRライセンス、SOAR
ツール費用の中心は、SIEM（Security Information and Event Management：ログを集約して相関分析する基盤）、EDR（Endpoint Detection and Response：端末の挙動を監視し検知・隔離する製品）、自動化を担うSOAR（Security Orchestration, Automation and Response）です。このうち費用の見通しが最も立てにくいのがSIEMで、多くのクラウド型SIEMは取り込むログ量に応じた課金を採用しています。
公開資料で課金モデルを確認できる例として、Microsoft Sentinelを挙げます。Microsoft Learnの課金ページによれば、Sentinelは取り込んだデータ量をGB単位で課金し、「価格は、データが取り込まれるレベルに基づいています」とされています。支払い方式には、実際のデータ量に基づく従量課金制と、「1日あたり100GBから始まる」コミットメント レベルがあり、後者は従量課金より割安になる一方、レベルの引き下げは31日ごとにのみ可能です。取り込んだデータは最初の90日間は無料で保持され、90日を超える保持は別途課金されます。Azureアクティビティ ログやOffice 365の監査ログ、Microsoft Defender各製品のセキュリティ アラートなど、無料で取り込めるデータ ソースも定められています（Microsoft Learn, 2026年閲覧）。つまりSIEMの費用は「1日あたりのログ量（GB）×単価×365日」を基本とし、保持期間の延長分と、長期保存向けの低コスト層（データ レイク）への振り分けで増減する、と理解できます。
EDRは一般に、保護対象の端末数に応じたライセンス課金で、台数が分かれば見積もりやすい費目です。SOARは製品ライセンスに加えて、プレイブック（自動処理の手順）を設計・実装・保守する工数が継続的に発生します。ツール費用は、ライセンス価格だけでなく、それを動かし続ける人の工数まで含めて比較する必要があります。
運用費用：プレイブック整備、教育、監査対応
3つ目の運用費用は、体制を「回し続ける」ための費用です。アラートの種類ごとに調査・判断・対処の手順を定めたプレイブックの整備と更新、アナリストの教育・訓練、監査や取引先調査への対応が含まれます。IPAの「サイバーセキュリティ経営ガイドライン Ver3.0実践のためのプラクティス集」は、「無理なく実践するインシデント対応演習」や「CSIRT業務の属人化回避も兼ねたインシデントや脅威に関する情報の共有・蓄積」を実践例として挙げており（IPA, 2023）、演習と知識の蓄積を続ける工数が体制の実効性を左右します。監査対応では、ログの保持期間や「誰がいつ何を判断したか」の記録を求められることが多く、SIEMの保持費用に跳ね返る点も見込んでおくべきでしょう。
概算の考え方：「人数×単価」「ログ量×単価」で見積もる
以上を踏まえると、SOC構築費用の概算は次の4つの式の合計として組み立てられます。金額は環境で大きく異なるため、ここでは式と変数のみを示します。
人件費＝席数×1席あたり必要人数（24時間365日なら稼働率を織り込んで5〜6名）×年間人件費単価（フルコスト）＋上位アナリスト・エンジニア・マネージャーの人件費
SIEM費用＝1日あたりログ量（GB）×GB単価×365日＋保持期間の延長分＋長期保存層の費用
EDR費用＝端末数×端末あたり年額ライセンス
運用費用＝プレイブック整備・更新の工数＋教育・演習＋監査対応＋外部委託費（委託する場合）
この式で最初に確定させるべき変数は「ログ量」です。Microsoft Learnのデプロイ ガイドも、計画段階で「デプロイの予算とタイムラインを正確に予測するのに役立つ、必要なデータ ソースとデータ サイズの要件を決定します」とし、データ インジェストとプレイブック双方のコストが予算でカバーされていることを確認するよう求めています。Sentinelには最初の10GB/日を31日間無料で取り込める試用枠と費用見積もりツールが用意されており（Microsoft Learn, 2026年閲覧）、「まず1か月、実ログを流して量を測る」ことが、机上の見積もりよりも確実な出発点になります。
また、費用は単年ではなく3〜5年の総額で比較してください。人件費は体制を維持する限り続く固定費であり、ログ量は監視対象の拡大とともに増える傾向にあります。初年度が安く見えても、数年後に人員の離職とログ量の増加が重なって費用が跳ね上がる例は少なくありません。
SOC構築の6ステップ
ここからは、構築の進め方を6つのステップに分けて示します。順番には意味があり、最初のステップを飛ばしてツール選定から始めると、後の全工程で手戻りが発生します。
ステップ1：現状把握と守るべき対象の定義
最初に、何を守るのかを決めます。基幹系システム、顧客データ、取引先との接続点、特権アカウントなど、停止や漏えいが事業に直結する資産を洗い出し、優先順位を付けます。あわせて、現在どのログが取れていてどこに空白があるのか、既存のEDRやファイアウォールのアラートは誰が見ているのかを棚卸しします。この段階で監視対象の範囲を絞ることが、以降のログ量、人数、費用のすべてを決めます。まず重要資産に集中し、段階的に広げる計画のほうが、全社一律に始めるより現実的です。
ステップ2：ログ収集基盤の整備
守る対象が決まれば、そこに関わるログを集める基盤、すなわちSIEMを整備します。設計の要点は、どのログを常時分析の対象にし、どのログを長期保存のみにするかの振り分けです。Microsoft Learnのデプロイ ガイドは、SOCアーキテクトが担う「計画と準備」の段階でワークスペースの設計、データ コネクタの優先順位付け、ロールとアクセス許可、コストの計画を行い、その後にSOCアナリストが担う「展開」、SOCエンジニアが担う「微調整とレビュー」へ進む流れを示しています（Microsoft Learn, 2026年閲覧）。ここで前述の「まず流して量を測る」を実施し、費用見積もりの前提を固めます。
ステップ3：検知ルールとユースケースの定義
ログが集まっても、何を「異常」として検知するかを定義しなければアラートは上がりません。「特権アカウントの深夜ログイン」「VPN経由の初回接続に続く大量のファイルアクセス」のように、守るべき対象と想定する攻撃シナリオ（ユースケース）を対応づけ、検知ルールに落とします。攻撃者の戦術・技術を体系化したMITRE ATT&CKに検知ルールを対応づけると、どの攻撃段階が見えていてどこが盲点かを可視化でき、Sentinelのデプロイ後チェックリストにも「MITRE フレームワークに対する分析ルールの確認」が含まれています（Microsoft Learn, 2026年閲覧）。最初から網羅を目指すより、重要資産に直結する少数のユースケースから始め、誤検知の状況を見ながら育てていくのが実務的です。
ステップ4：体制と当番表の設計
検知の仕組みができたら、アラートを誰が見るかを決めます。前述の算出ロジックで人数を確認し、自社で埋められない時間帯を特定します。多くの中堅企業では、平日日中は社内、夜間・休日は外部サービスまたはAIという分担になりますが、重要なのは当番表に「通知を受けた後に判断する人」を必ず置くことです。夜間に通知が届いても判断者に連絡がつかない体制は、監視をしていないのと結果は変わりません。夜間・休日体制が人に依存すると回らなくなる構造は「夜間・休日のセキュリティ体制はなぜ回らないのか」で詳しく解説しています。
ステップ5：プレイブックの整備
当番に就いた人が、深夜に1人でも同じ品質の初動を取れるようにするのがプレイブックです。ユースケースごとに、確認するログ、判断の基準、エスカレーション先、端末隔離やアカウント無効化といった対処の権限範囲を文書化します。NISTのインシデント対応ガイドラインSP 800-61 Rev.3は、組織がインシデント対応に備え、インシデントの件数と影響を減らし、検知・対応・復旧の効率と有効性を高めることを目的に、インシデント対応をサイバーセキュリティ リスク管理全体に統合する考え方を示しています（NIST SP 800-61 Rev.3, 2025）。プレイブックは検知ルールの追加や環境の変更にあわせて更新し続ける前提で、保守の工数を運用費用に見込んでおきます。
ステップ6：KPIとレビューの仕組み
最後に、体制が機能しているかを測る指標と見直しの周期を決めます。代表的なKPIは、検知までの時間（MTTD）、復旧までの時間（MTTR）、アラートのうち実際に調査できた割合、誤検知率などです。Sentinelのデプロイ後チェックリストが、分析ルールとプレイブックの動作確認、インジェスト コストの追跡、コミットメント レベルの見直しを継続的な確認項目としているように（Microsoft Learn, 2026年閲覧）、検知の品質と費用の両方を定期的にレビューする仕組みが必要です。KPIの設計と改善の実務は「MTTR・MTTDとは？SOCのKPI設計と改善の実務」で取り上げています。
中堅企業がつまずく4つの点
ステップを踏んでも、中堅企業のSOC構築は特定の箇所で行き詰まることが多いものです。事前に知っておけば、計画段階から手当てできます。
1. 人が採れない
24時間365日を人で埋めるには1席でも6名前後が必要ですが、ISC2の調査が示すように人材の不足は世界的に拡大しており、不足とスキルギャップの主因は予算不足とされています（ISC2, 2024）。中堅企業が専任アナリストを複数名採用し定着させることは容易ではなく、計画段階で「採れる前提」を置くこと自体がリスクです。採用できる人数を先に見積もり、埋まらない時間帯と工程を外部やAIで補う設計にするほうが、破綻しにくい計画になります。アナリスト不足と「アラート疲れ」の構造は「SOCアナリスト不足と「アラート疲れ」」で分析しています。
2. 夜間が回らない
日中の体制はできても、夜間・休日は情報システム部門のオンコール（呼び出し待機）に頼る例が多く見られます。しかし、呼び出された担当者が調査に必要な権限や知識を持たず、翌朝まで判断が持ち越されるのであれば、24時間監視は名目上のものです。短時間で被害が広がるランサムウェアに対しては、通知の受け手ではなく「夜間に調査と一次対処を完了できる主体」を置く必要があります。
3. ログ費用が膨らむ
SIEMの費用は「取り込めば取り込むほど増える」構造のため、監視対象を広げた途端に予算を超過することが起こりがちです。対策は設計段階で決まります。Microsoft Learnのコスト削減ガイドは、セキュリティ以外の運用データは別のワークスペースに分けてSentinelの課金対象にしないこと、リアルタイムの脅威検出に必要のない二次的なセキュリティ データはデータ レイクへ振り分けること、データ収集ルールで取り込むイベントを選別すること、取り込み量に見合ったコミットメント レベルを選ぶことを推奨しています（Microsoft Learn, 2026年閲覧）。「全部取る」ではなく、検知に使うログ、監査のために保存するログ、取り込まないログを最初に分けることが、費用を制御する現実的な方法です。
4. 外部委託の「通知まで」
外部委託で夜間を埋めたつもりでも、契約範囲が「アラートの通知まで」であれば、調査・判断・対処は自社に残ります。IPAのプラクティス集が「サイバーセキュリティ対策において委託すべき範囲の明確化とその管理」「ITサービスの委託におけるセキュリティ対策を契約と第三者検証で担保」を実践例として挙げているのは（IPA, 2023）、委託の境界が曖昧なまま運用に入る組織が多いことの裏返しでもあります。契約前に、通知の後に誰が何分以内に何をするのかを、時間帯ごとに書き出して確認することをお勧めします。
AIエージェントで変わる費用構造
ここまでの費用構造は、「アラートを人が1件ずつ確認する」ことを前提にしています。席数と人数、人数に掛かる単価が費用の中心にあり、24時間365日を目指すほど人件費が積み上がる構造です。この前提を変えるのが、EDRやSIEMのアラートをAIエージェントが自律的に調査・対処するAI SOCです。AIエージェントが関連ログの収集、脅威情報との照合、影響範囲の特定、対処案の提示までを担うため、「席を人で埋める」必要がなくなり、費用が人数に比例しなくなります。
ヤグラAI SOCは、AIによるアラート調査で担当者の負担軽減を支援します。費用対効果は、調査率、手動分析時間、追加調査の工数を自社環境で測定し、サービス利用料や連携・運用に必要な費用と合わせて評価してください。EDR・SIEM・ID管理製品など100以上のセキュリティ製品と接続できるため、ステップ2で整備したログ収集基盤や既存のEDRをそのまま活かせます。コンテキストメモリが組織固有の知識（Wiki、過去の対応履歴、チケット管理システム）を学習するため、プレイブックの属人化という運用費用の課題にも対応します。ヤグラAI SOCは自社開発のサービスで、Microsoft Sentinelなど既存のセキュリティ製品と連携できるため、Sentinelを軸にSIEMを整備する企業にとっては既存投資を無駄にしない選択肢です。詳しくは「Microsoft Sentinelを活かすAI SOC：既存SIEM投資を無駄にしない運用自律化」をご覧ください。
費用構造の観点で整理すると、AI SOCは前述の式のうち「席数×人数×単価」の項を大きく縮め、運用費用のうちプレイブック保守と教育の一部を置き換えます。一方で、対処の最終承認、経営層や取引先への報告、AIの調査結果を評価・監督する担当者は引き続き必要であり、ログ量に応じたSIEM費用も残ります。AI SOCは人件費をゼロにするものではなく、「人数に比例して増える費用」を「監視対象に応じて決まる費用」へ変えるものだと理解しておくと、見積もりの比較がしやすくなります。
まとめ
SOC構築の費用は人件費・ツール費用・運用費用に分解でき、24時間365日を人で維持する場合は「席数×人数×単価」の人件費が中心になります。1席を埋めるには稼働率を織り込んで5〜6名が目安であり、上位アナリストやエンジニアはその外側に必要です。SIEMは取り込むログ量に応じた課金が一般的で、ログ量の実測と振り分け設計が費用を左右します。構築は、守る対象の定義、ログ収集基盤、検知ルール、体制と当番表、プレイブック、KPIとレビューの6ステップで進め、人材確保、夜間体制、ログ費用、委託範囲というつまずきやすい点を計画段階で手当てします。人数に比例する費用構造そのものを見直す選択肢としてAIエージェントを検討に加えれば、限られた予算と人員でも24時間監視体制は現実的な目標になります。まずは自社のログ量の実測と、夜間に通知を受けた後に誰が何をするかの確認から始めてみてください。
関連サービス：EDR・SIEMのアラートをAIエージェントが24時間365日自律的に調査・対処し、人数に依存しない監視体制を実現する「ヤグラAI SOC」の詳細はこちら。
参考・出典
IPA「情報セキュリティ10大脅威 2026」（2026）: https://www.ipa.go.jp/security/10threats/10threats2026.html
警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（2026）: https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf
ISC2「2024 ISC2 Cybersecurity Workforce Study」（2024）: https://www.isc2.org/Insights/2024/10/ISC2-2024-Cybersecurity-Workforce-Study
Microsoft Learn「コストを計画し、価格と課金を理解する - Microsoft Sentinel」（2026年閲覧）: https://learn.microsoft.com/ja-jp/azure/sentinel/billing
Microsoft Learn「Microsoft Sentinel のコストを削減する」（2026年閲覧）: https://learn.microsoft.com/ja-jp/azure/sentinel/billing-reduce-costs
Microsoft Learn「Microsoft Sentinel のデプロイ ガイド」（2026年閲覧）: https://learn.microsoft.com/ja-jp/azure/sentinel/deploy-overview
IPA「サイバーセキュリティ経営ガイドライン Ver3.0実践のためのプラクティス集 第4版」（2023）: https://www.ipa.go.jp/security/economics/csm-practice.html
NIST SP 800-61 Rev.3 "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile"（2025）: https://csrc.nist.gov/pubs/sp/800/61/r3/final
株式会社ヤグラ「ヤグラAI SOC」: https://yagurasec.com/ai-soc
