SOC・CSIRTアナリストを業務委託で確保する方法｜任せる範囲と体制設計

EDR や SIEM は導入した。ダッシュボードにはアラートが並んでいる。けれども、そのアラートが本当に危険なものなのか、放置してよいものなのかを判断できる人が社内にいない。情報システム部門は1〜3名で、全員が別の本業を抱えている。そんな状態で、取引先のサプライチェーン監査で「セキュリティの運用体制を説明してください」と問われたり、経営層から「CSIRT を立ち上げろ」と指示が飛んできたりする。

正社員としてセキュリティ人材を採用しようとしても、求人を出して半年、応募はほとんど来ないか、来ても提示できる年収と折り合わない。そこで「まずは業務委託で、SOC アナリストを1人確保できないか」という発想に至ります。この流れ自体は自然で、方向としても間違っていません。

ただし、その先で多くの担当者が同じ場所でつまずきます。「1人確保すれば監視体制ができる」という前提が、24時間365日という要件と噛み合わないからです。そして、要件が固まらないまま求人票を書こうとして手が止まり、稟議の紙も白紙のまま時間だけが過ぎていきます。

この問題の本質は、スキル要件の書き方でも単価の相場観でもありません。「外部に出すべきなのは『人』なのか『サービス』なのか」「社内に絶対に残さなければならない責任は何か」を切り分けられていないことにあります。この2つが決まれば、募集要件も契約形態も予算額も、機械的に書き出せるようになります。

本記事では、SOC・CSIRT アナリストを業務委託で確保する方法を、SOC と CSIRT の役割の違い、24時間監視に必要な人数の現実、MSS・MDR との使い分け、単価相場、外部に出せる業務と社内に残す責任の線引き、契約形態とエスカレーション設計、そして具体的な進め方という順で解説します。読み終えたときに、要件書と稟議の骨子をご自身で書き出せる状態を目指します。

SOC・CSIRTアナリストを業務委託で確保しようとして最初につまずくこと

「アナリストを1人確保すれば監視できる」という前提が崩れる瞬間

SOC アナリストの業務委託を検討し始めた時点では、多くの場合「経験者を1人、週3日くらいで入れてもらえれば、たまったアラートを捌いてもらえる」というイメージを持っています。

このイメージが崩れるのは、たいてい社内で説明を求められた瞬間です。「その人が夜間にアラートが上がったらどうするのか」「その人が休んだ日は誰が見るのか」「隔離が必要なときに誰が判断して誰がボタンを押すのか」。これらの問いに答えようとすると、確保しようとしているのが「作業をする人」であって「24時間止まらない体制」ではないことに気づきます。

さらにややこしいのは、「アラートを捌く」という言葉のなかに、性質のまったく異なる2つの仕事が混ざっていることです。ログを見て「これは誤検知」「これは要調査」と切り分ける作業と、「この端末をネットワークから切り離す」「取引先に連絡する」と決める判断は、必要なスキルも、負うべき責任も、外部に委ねられる度合いも違います。この2つを分けないまま募集要件を書こうとするから、書けなくなるのです。

この切り分けの手がかりが、次に説明する SOC と CSIRT の役割の違いです。

正社員採用でSOC・CSIRT人材を確保できない構造的理由

そもそも、なぜ正社員での採用がうまくいかないのか。原因を「自社の知名度が低いから」だと考えている場合が多いのですが、構造はもう少し単純です。

第一に、母集団が絶対的に小さいという事情があります。経済産業省は2016年の調査で、セキュリティの専門性を持つ人材が国内で大幅に不足するという推計を示しており、その後も人材育成は国の政策課題として継続的に扱われています（出典: 経済産業省「サイバーセキュリティ人材の育成促進に向けた検討会 最終取りまとめ」2025年5月）。不足が長期にわたって解消されていない領域では、採用競争は知名度勝負ではなく報酬とキャリアパスの勝負になります。

第二に、提示できるポジションの魅力の問題があります。セキュリティ専任者がゼロの組織に1人目として入る場合、その人は相談相手も、レビューしてくれる上長も、引き継ぐ手順書もない状態から始めることになります。スキルを伸ばせる見通しが立ちにくいポジションは、市場価値の高い人材ほど選びません。

第三に、スキル維持のコストです。攻撃手法も検知製品も変わり続けるため、SOC・CSIRT のスキルは実務から離れると急速に陳腐化します。1人採用しても、その人が最新の脅威動向に触れ続けられる環境を社内で用意できるかというと、単独配置ではまず難しいのが実情です。

つまり、正社員採用がうまくいかないのは努力不足ではなく、1人目のセキュリティ専任者を正社員で採るという設計そのものが、市場と噛み合っていないということです。業務委託という選択肢が有力になるのは、この構造を迂回できるからです。すでにどこかで SOC 運用の実務に触れ続けている人に、必要な時間だけ関与してもらう形であれば、スキル維持のコストを自社が負わずに済みます。

SOCとCSIRTの違い｜業務委託で任せられる範囲が変わる境界線

SOCは検知まで、CSIRTは判断と対外対応まで

SOC（Security Operation Center）と CSIRT（Computer Security Incident Response Team）は混同されがちですが、担う機能はきれいに分かれています。

SOC は、監視・検知・一次分析を担う機能です。SIEM や EDR が出したアラートを見て、誤検知かどうかを切り分け、調査が必要なものにログ分析を加え、「何が起きている可能性があるか」を整理して次に渡します。日々の運用の継続性が求められる、フロー型の仕事です。

CSIRT は、インシデントとして扱うかどうかの判断、事業影響を踏まえた対応方針の決定、社内外の調整と対外報告を担う機能です。関連する社内部門や経営層との連携、必要に応じた外部専門機関との窓口も含みます（CSIRT（シーサート）とは？SOCとの違いや導入方法、運用のポイント）。発生頻度は低いものの、発生時には組織としての意思決定を伴う、イベント型の仕事です。

本記事で重要なのは、この違いを用語の整理として終わらせないことです。SOC と CSIRT の境界線は、そのまま「外部に出せる業務」と「社内に残さなければならない責任」の境界線とほぼ重なります。

SOC 側の業務は、手順と判断基準さえ定義できれば外部の専門家に委ねやすい性質を持っています。一方で CSIRT 側の中核、すなわち「事業を止めてでも封じ込めるか」「取引先にいつ何を伝えるか」「規制当局に報告するか」といった判断は、事業と法的責任を負う自社の側にしか下せません。ここを外部に投げようとすると、契約上も実務上も無理が生じます。

自社に足りないのはSOC機能かCSIRT機能か｜見分けるチェック観点

募集要件が書けない原因のひとつは、自社に足りない機能が特定できていないことです。次の観点で、どちら側が欠けているかを切り分けてみてください。

SOC 機能が足りていないサイン

• EDR / SIEM のアラートが未処理のまま積み上がっている
• 「このアラートは対応が必要か」を判断できる人が社内にいない
• 検知ルールが導入時のデフォルトのままで、自社環境に合わせた調整ができていない
• ログは取得しているが、平時に誰も見ていない

CSIRT 機能が足りていないサイン

• インシデント発生時の連絡先・報告経路・エスカレーション基準が文書化されていない
• 「誰が対応方針を決めるのか」が決まっておらず、実質的に情報システム部門の判断で止まっている
• 取引先や監督官庁への報告手順を誰も説明できない
• 過去のインシデントの記録が残っておらず、再発防止に接続していない

前者だけが該当するなら、探すべきは監視・分析の実務を担うアナリストです。後者も該当するなら、人材の確保より先に、社内の意思決定ルートと報告手順を定義する作業が必要になります。ここが未定義のまま外部アナリストを迎えると、アラートは処理されるものの「で、どうするのか」が誰にも決められず、結局アラートの滞留が意思決定の滞留に置き換わるだけになります。

24時間365日監視は業務委託の人材だけでは埋まらない｜必要人数から逆算する

3交代シフトを回すのに必要な人数の目安

「24時間365日の監視体制をつくりたい」という要件を、人数に換算してみます。

24時間を3交代（たとえば日勤8:00〜17:00、準夜勤16:00〜翌1:00、夜勤0:00〜9:00）でカバーする場合、単純計算でも1日3枠が毎日発生します。1枠を1人で埋めるとしても年間で延べ1,095人日、これを週休や有給、研修、離職リスクまで織り込んで維持するとなると、必要人数は一気に膨らみます。実務上の目安としては、1シフトを複数名で構成する前提で最低9名程度、休暇や研修の余裕を持たせるなら12名程度という水準が示されています（効果的なCSIRT/SOC構築と運用ガイド）。

さらに、24時間365日の体制を自社で維持する場合は、深夜・休日の割増手当により人件費が単純な人数比以上に膨らみます。システム運用一般の試算でも、24/365 体制の内製化は人員コストが大きな論点として扱われています（自社で24時間365日のシステム運用保守体制を組むコストを試算）。

ここから導かれる結論は明確です。業務委託で1〜2名のアナリストを確保しても、24時間365日のシフトは構造的に埋まりません。 1人あたりの稼働時間を増やす方向で解決しようとすれば、それは契約形態の観点でも（後述する偽装請負の論点で触れます）、人材の疲弊という観点でも破綻します。

これは業務委託という手段が劣っているという意味ではありません。「24/365 のシフトを人の頭数で埋める」という課題設定そのものが、中堅規模の事業会社には合っていないということです。

中堅企業で成立する現実的な稼働パターン（日中委託＋夜間はサービス／オンコール）

では、現実にはどう組むのか。中堅規模の事業会社で成立しやすいのは、時間帯ごとに手段を変える構成です。

平日日中は、人材の業務委託で「見る目」を確保する。 アラートの一次トリアージ、ログ分析、検知ルールのチューニング、運用手順書の整備といった、自社環境の理解が必要な業務を、週2〜3日稼働の外部アナリストに担ってもらいます。この時間帯は、自社の担当者と直接やりとりできるため、ナレッジも蓄積しやすくなります。

夜間・休日は、サービス（MDR / MSS）で「検知と一次対応」を確保する。 人の頭数では埋められない時間帯を、24時間体制をすでに持っているベンダーのサービスで補います。従来型の MSSP / SOC サービスが監視・通知・助言を提供するのに対し、MDR はエンドポイントの隔離やプロセス停止といった対応（Response）まで含む点が違いです（【比較検討】自社に最適なMDRサービスを導入するには？）。夜間に人を置けない組織ほど、対応まで含むサービスの価値が高くなります。

重大事象の意思決定は、社内のオンコールで受ける。 隔離や事業停止の承認、対外報告の判断は、時間帯に関係なく自社が引き取ります。ここは人数ではなく「誰が電話に出て、誰が決めるか」を決めておく問題です。

この3層構成にすると、「24時間の監視をどう埋めるか」という問いが、「どの時間帯に、どの機能を、どの手段で持つか」という設計の問題に変わります。ここまで整理できれば、稟議に書ける形になります。

人材の業務委託とMSS・MDRサービス委託の使い分け

3つの選択肢の比較（費用構造・立ち上がり・ナレッジ蓄積・チューニング）

セキュリティ運用を外部の力で回す場合、選択肢は大きく3つあります。それぞれの性質を並べて比較します。

この表で注目していただきたいのは、費用の多寡ではなく「チューニング」と「ナレッジ蓄積」の行です。ここが人材の業務委託が持つ固有の価値であり、サービス委託では代替しにくい部分です。逆に「対応時間帯」と「継続性リスク」は、サービス委託が構造的に強い部分です。

MDR・MSSと人材業務委託の違いを費用構造で比較する

費用の比較は、単純な月額の大小ではなく、費用が何に比例するかで捉えると判断しやすくなります。

人材の業務委託は、稼働日数に比例します。週2日なら週2日分、週4日なら週4日分です。監視対象のサーバーや端末が増えても、直ちに費用は増えません。逆に、対応時間帯を広げようとすると、人数を増やすしかないため費用が跳ね上がります。

一方の MSS・MDR は、監視対象の規模とサービスレベルに比例します。端末台数やログ量が増えれば費用も増える一方、24時間365日という時間帯のカバーは月額に織り込まれています。国内の相場感は、委託の深さによって次のように段階が分かれると整理されています（セキュリティ運用は外部に任せられる？MSS・SOC・MDRの違いと費用相場・選び方）。

同じ「SOC の外注」でも、フルマネージドと業務を絞った委託とでは月額が一桁変わります。中小企業向けの EDR + SOC パッケージに至っては端末単価での課金となり、監視対象が30台程度であれば月数万円台から始められる水準です。したがって、比較の際は「月額いくらか」ではなく、次の2点を揃えて見積もりを並べてください。

1. カバーする時間帯（平日日中のみか、24時間365日か）
2. 対応の深さ（検知して通知するまでか、隔離・遮断まで実行するか）

この2点を揃えて並べると、直感に反する結果が出ることがあります。たとえば、24時間365日をカバーするフルマネージド SOC・MSS の月額30万〜80万円に対し、後述する SOC 運用アナリストを週4〜5日で確保する場合の月額は60万〜90万円です。平日日中しかカバーしない人材のほうが、24/365 をカバーするサービスより高くつくという比較になります。人材の業務委託を選ぶ根拠は「安いから」ではなく、自社環境へのチューニングとナレッジ蓄積という、サービス委託では代替しにくい価値にあります。ここを取り違えたまま稟議を書くと、費用対効果の説明で行き詰まります。

現実解となるハイブリッド構成の典型例

多くの中堅企業にとって現実的な着地点は、機能ごとに手段を割り当てるハイブリッド構成です。典型例を挙げます。

• 検知の24時間カバー: MDR サービス。夜間・休日に発生した重大アラートは、ベンダー側で一次対応（端末隔離等）まで実施し、自社のオンコール窓口へ通知
• 日中の一次分析と環境チューニング: 業務委託アナリスト（週2〜3日）。日中のアラート精査、誤検知の削減、自社環境に合わせた検知ルールの調整、運用手順書の整備、月次レポート作成
• 対応方針の決定と対外調整: 社内 CSIRT（兼務可）。事業影響を踏まえた封じ込め範囲の決定、隔離・サービス停止の承認、取引先・監督官庁への報告判断

この構成であれば、「夜間に人がいない」問題をサービスで解き、「自社環境を誰も理解していない」問題を人材で解き、「誰も決められない」問題を社内の責任定義で解くことになります。3つの問題を1つの手段で解こうとしないのが要点です。

自社の状況から選ぶ判断フロー

自社がどの構成を取るべきかは、次の順で判断できます。

1. 足りない機能を特定する（SOC 機能か、CSIRT 機能か、両方か）
2. 24時間365日のカバーが本当に必要かを判定する（顧客データを常時扱う、製造ラインが止まると被害が大きい、取引先から要求されている等の要件があるか）
3. 24/365 が必要なら、その時間帯はサービス委託を前提に置く（人材の頭数では埋まらないため）
4. 自社環境のチューニングとナレッジ蓄積が必要なら、人材の業務委託を並行して置く
5. CSIRT 機能が未整備なら、人材確保より先に意思決定ルートと報告手順を定義する

ステップ2で「平日日中のみで足りる」と判定できる組織も少なくありません。その場合は、人材の業務委託だけで体制が成立します。ここを検証せずに 24/365 を要件に入れると、必要のないコストを抱えることになります。

業務委託SOC・CSIRTアナリストの単価相場と稼働形態

スキル階層別の月額単価レンジ

SOC・CSIRT 領域の業務委託単価は、担える業務の深さで階層が分かれます。フリーランス案件市場で示されている水準を、本記事のテーマに関係する領域に絞って整理すると次のようになります（セキュリティエンジニアのフリーランス単価相場｜案件動向とスキル別レンジ）。

隣接する領域では、クラウドセキュリティ設計が月90〜130万円、監査・GRC・セキュリティコンサルが月90〜140万円、セキュリティ PM・リードが月100〜150万円という水準も示されています（同上）。SIEM・EDR のチューニングや検知ルール設計まで担える人材は、SOC 運用のレンジ上限から CSIRT 支援のレンジにかけての帯に位置づくと考えると、見積もりの比較がしやすくなります。

なお、これらはいずれも週4〜5日稼働を前提とした水準です。週2〜3日など稼働量を絞る場合は、この金額を稼働日数で按分した水準が交渉の出発点になります。ただし、稼働日数を減らしても立ち上がりに必要なキャッチアップの手間は変わらないため、単純な日割りより割高になるケースがある点は見込んでおいてください。

セキュリティ職種全体の費用相場や、内製採用・MSS との比較を含めた包括的な判断材料については、セキュリティエンジニア外部委託の判断基準と費用相場もあわせてご覧ください。

週2〜3日稼働で成立する業務・しない業務

業務委託では、週5日フルコミットよりも週2〜3日の稼働で契約するケースが多くなります。この稼働量で成立する業務と、しない業務をあらかじめ把握しておくと、要件定義のブレを防げます。

週2〜3日で成立する業務

• アラートの一次トリアージ（当日中の判断でよい運用設計になっている場合）
• 検知ルールのチューニング、誤検知の削減
• ログ設計・保全方針の整備
• 運用手順書・エスカレーション基準の文書化
• 月次のレポート作成と傾向分析
• 社内担当者への技術指導・レビュー

週2〜3日では成立しない業務

• リアルタイムでのアラート即応（数分〜数十分以内の初動が求められるもの）
• 24時間の待機・オンコール（稼働日以外の常時待機は準委任の枠を超えます）
• インシデント発生時の全期間張り付き対応（発生タイミングを選べないため）
• 対外報告の主体としての対応

つまり、週2〜3日の稼働で確保できるのは「体制の即応性」ではなく「アラートを意味のある情報に変える力」と「運用を仕組みにする力」です。この理解のまま要件を書けば、期待値のずれによる早期離任を避けられます。

単価が上下する要因

同じ「SOC アナリスト」でも、次の要因で単価は上下します。見積もり比較の際の観点としてお使いください。

• 対象製品の習熟度: 自社が導入済みの EDR / SIEM 製品の運用経験があるかどうか。製品固有の知識は立ち上がり速度に直結するため、習熟している人材は単価が上がる代わりに、キャッチアップ期間のコストが不要になります
• 夜間・休日対応の有無: 稼働時間帯を平日日中の外に広げるほど単価は上がります。ここが上がるくらいならサービス委託のほうが安い、という分岐点が生じます
• 業界固有の規制対応: 金融、医療、公共など、業界ガイドラインへの適合が求められる領域は、対応経験のある人材の単価が上がります
• 文書化・説明責任の範囲: 監査対応資料の作成や経営層への説明まで含めると、コンサルティング寄りの単価帯に移ります
• 資格ではなく実務経験の裏づけ: CISSP や OSCP といった資格は目に付きやすい指標ですが、資格だけで単価が上がるケースは限定的で、実務と組み合わせて初めて評価されるとされています（セキュリティエンジニアのフリーランス単価相場）。候補者の比較では資格欄よりも、後述する候補選定の3つの確認観点を優先してください

外部に出せる業務と社内に残すべき責任｜役割定義の書き方

業務委託アナリストに任せやすい業務

外部のアナリストに任せやすいのは、判断基準を事前に定義でき、結果を検証できる業務です。具体的には次のものが該当します。

• アラートの一次トリアージ: 誤検知／要調査／エスカレーション対象の切り分け。判断基準を手順書として定義しておけば、外部でも一貫した運用が可能です
• ログ分析・侵害有無の技術的調査: 端末やサーバーのログから、何が起きたかを技術的に明らかにする作業
• 検知ルールのチューニング: 自社環境に合わせた閾値・除外条件の調整。誤検知の削減は運用負荷に直結するため、効果が測りやすい業務です
• 運用手順書・エスカレーション基準の整備: 属人化を防ぐための文書化。これ自体を成果物として依頼できます
• 月次レポートと傾向分析: 検知傾向、対応件数、改善提案。取引先監査や経営報告の材料にもなります
• 社内担当者への技術指導: 兼務担当者が一次判断できる範囲を広げるための伴走

これらに共通するのは、「その作業が正しく行われたかどうかを、自社が事後に検証できる」という性質です。逆に、事後検証が困難で、かつ誤った場合に事業や法的責任に直結する領域は、外部に出せません。

社内に残すべき意思決定と法的責任（対外報告義務・委託先管理責任）

次の3つは、外部委託の有無にかかわらず自社に残ります。ここを認識しないまま体制を組むと、インシデント発生時に「誰も決められない」「報告が遅れる」という事態を招きます。

1. 事業影響を踏まえた対応方針の決定

端末を隔離する、サービスを止める、業務システムを一時停止する。これらは技術的な正しさだけでは決められません。「止めた場合の売上影響」「顧客への影響」「復旧までの見通し」を天秤にかけた判断であり、事業責任を負う自社にしか下せません。外部アナリストが提供できるのは「技術的にはこの範囲を止めるべき」という選択肢の提示までです。

2. 対外報告義務

個人データの漏えい等が発生し、個人の権利利益を害するおそれがあるときは、個人情報保護委員会への報告と本人への通知が義務づけられています。報告は2段階で、速報を速やか（おおむね3〜5日以内）に、確報を原則30日以内に行う必要があります（漏えい等報告・本人への通知の義務化について｜個人情報保護委員会）。

注意すべきは、この報告義務の主体は個人データを取り扱う事業者、つまり自社であるという点です。個人データの取扱いを委託している場合、委託先が報告対象事態を知った後に速やかに委託元へ通知したときは委託先の報告義務が免除される仕組みになっており、報告の主体は委託元に集約されます（漏えい等の対応とお役立ち資料｜個人情報保護委員会）。外部にアナリストを置いても、この義務は移転しません。

3. 委託先管理責任

外部に業務を委託しても、委託先を適切に監督する責任は自社に残ります。アクセス権の付与範囲、取り扱えるデータの範囲、再委託の可否、契約終了時のデータ返却・削除といった管理項目は、委託契約の中で定義しておく必要があります。

委託先が関わるインシデントが起きた場合の発注者側の初動と報告義務の具体的な手順については、業務委託先で情報漏洩｜発注者の初動対応と報告義務で詳しく整理しています。

役割定義書に盛り込む項目

ここまでの線引きを、そのまま要件書に落とし込むための項目を挙げます。この形で書き出せば、募集要項にも契約書の別紙にも転用できます。

とくに「社内側の責任者」の行は、空欄のまま募集をかけないでください。ここが決まっていない状態は、外部アナリストにとっては「判断を仰ぐ相手がいない」状態であり、稼働開始後の最大のつまずきポイントになります。

契約形態とエスカレーション設計｜偽装請負と権限委任のリスクを避ける

準委任と請負のどちらを選ぶか

SOC 運用のような継続的な監視業務は、準委任契約が基本になります。理由は成果物の定義の困難さにあります。

請負契約は、仕事の完成に対して報酬を支払う契約です。「脆弱性診断を実施し、診断報告書を納品する」「CSIRT の運用規程を作成する」のように、成果物が明確に定義でき、完成の判定基準を置ける業務であれば請負が適します。

一方、SOC の監視業務は「アラートを適切に処理し続けること」が価値であり、何をもって完成とするかを定義できません。件数で定義しようとすると、アラートが少ない月は仕事をしていないことになってしまいます。このため、業務の遂行そのものに対して報酬を支払う準委任契約を選ぶのが自然です。

実務上は、この2つを組み合わせる形もよく取られます。継続的な監視・分析は準委任で、運用規程の策定や CSIRT 立ち上げ支援といった立ち上げフェーズの成果物は請負で、というように分けると、双方にとって責任範囲が明確になります。

シフト・オンコール指示が偽装請負リスクを高める理由と回避策

SOC 業務には、偽装請負のリスクを高めやすい固有の要素があります。シフト勤務の指定とオンコール待機の指示です。

偽装請負に当たるかどうかは契約書の形式ではなく実態で判断され、発注者と受託者の労働者の間に実質的な指揮命令関係があるかどうかが問われます。判断は、業務の遂行に関する指示・管理、労働時間等に関する指示・管理、企業秩序に関する指示・管理という観点から総合的に行われます（労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）の疑義応答集｜厚生労働省）。

SOC 業務で問題になりやすいのは、2つ目の「労働時間等に関する指示・管理」です。次のような運用は、リスクを高めます。

• 発注者がシフト表を作成し、受託者の稼働時間帯を一方的に割り当てる
• 「今夜は待機してください」と個別に指示し、待機時間を管理する
• 始業・終業の報告を求め、勤怠として管理する
• 社内チャットで、その場その場の作業指示を都度出す

回避のための考え方は次のとおりです。

稼働時間帯は「指示」ではなく「合意」にする。 契約時に「平日9:00〜18:00のうち週3日、具体的な曜日は双方協議で決定する」といった形で合意し、変更が必要な場合も協議によって行います。発注者が一方的に割り当てる形にしないことが要点です。

待機を求める場合は業務範囲として契約に定める。 オンコール対応が必要なら、「待機してほしい」と都度指示するのではなく、対象時間帯・待機時の応答条件・対価を契約上の業務範囲として定義します。定義できないのであれば、その時間帯はサービス委託でカバーすべき領域です。

指示の窓口を一本化し、内容を「業務単位」にする。 複数の社内メンバーが個別にチャットで作業指示を出す運用は避け、依頼は窓口を通して業務単位（「この期間のログ分析をお願いしたい」）で渡します。作業手順や作業順序の細かい指定は行いません。

判断基準を文書で共有する。 「どう判断するか」を都度口頭で指示するのではなく、手順書とエスカレーション基準として文書化し、受託者がそれを参照して自律的に判断できる形にします。文書化は偽装請負リスクの低減と、ナレッジの社内蓄積を同時に達成します。

オンコール体制そのものの設計と契約上の注意点については、外部エンジニアの障害対応・オンコール体制の作り方で、偽装請負の論点を含めて詳しく解説しています。

判断権限とエスカレーションフローの設計

外部アナリストにどこまでの判断を委ねるかは、行為の可逆性で線を引くと整理しやすくなります。

そのうえで、エスカレーションフローを次の要素で定義します。

1. 重大度の区分（例: 情報 / 注意 / 警戒 / 重大）と、それぞれの判定基準
2. 区分ごとの通知先（誰に、どの手段で、何分以内に）
3. 通知を受けた側の判断時限（承認するかどうかを何分以内に返すか）
4. 一次連絡先が応答しない場合の代替経路（副担当、その上位者）
5. 時間帯ごとの経路の違い（日中は委託アナリスト経由、夜間は MDR ベンダーから自社オンコールへ直接など）

このうち3番目、つまり自社側の判断時限を定義していないケースが非常に多く見られます。外部アナリストが5分でエスカレーションしても、社内の承認が翌朝までつかないなら、体制としての初動は翌朝になります。委託の効果を測る指標は、外部側の処理速度ではなく、通知から意思決定までの全体時間です。

SOC・CSIRTアナリストを業務委託で確保する進め方

確保チャネル別の特徴

要件が固まったら、どこで人材を探すかを決めます。チャネルごとに期待できる人材レンジと立ち上がり速度が異なります。

複数チャネルを併用する場合は、同じ役割定義書を各チャネルに渡してください。チャネルごとに要件の伝え方が変わると、候補者の比較ができなくなります。

要件確定からオンボーディングまでのステップ

進め方は次の5段階で整理できます。

ステップ1: 要件確定（1〜2週間）

自社に足りない機能（SOC / CSIRT）を特定し、24/365 の要否を判定します。そのうえで、先ほどの「役割定義書に盛り込む項目」の表を埋めます。とくに社内側の責任者と判断権限の範囲は、この段階で確定させてください。ここが曖昧なまま次に進むと、後工程のすべてが空回りします。

ステップ2: 候補選定（2〜4週間）

チャネルに要件を提示し、候補者の経験を確認します。確認すべきは資格の有無よりも、次の3点です。

• 自社が導入している EDR / SIEM 製品の運用経験があるか
• アラートの判断基準を「自分で作った」経験があるか（既存基準に沿って処理した経験だけか）
• インシデント発生時に、どこまでの範囲を担当した経験があるか

ステップ3: トライアル（1〜2ヶ月）

いきなり長期契約を結ばず、短期の契約から始めます。トライアル期間に依頼するとよいのは、「直近1ヶ月分の滞留アラートの棚卸しと、誤検知の分類レポート」といった、自社環境の理解度と説明能力の両方が見える業務です。この成果物の質で、継続の可否を判断できます。

ステップ4: オンボーディング（2〜4週間）

システム構成、業務システムの重要度、過去のインシデント履歴、社内の連絡経路を共有します。この期間はアウトプットが出にくいため、成果を求めすぎないことも大切です。同時に、エスカレーションフローを実際に一度テスト（模擬アラートで通知経路を確認）しておくと、稼働開始後の手戻りを防げます。

ステップ5: 定着とナレッジ残留設計

月次レビューの場を設定し、検知傾向・改善提案・手順書の更新状況を確認します。ここを設けないと、運用は回っているのに社内には何も蓄積されない状態になります。

委託者が抜けてもノウハウを残す仕組み

「その人が抜けたら元に戻るのではないか」という懸念は、業務委託を検討する際にもっとも多く挙がる不安のひとつです。これは契約の工夫ではなく、成果物の設計で解決します。

1. 運用手順書の更新を成果物に含める

判断基準の変更、新しい検知パターンへの対応、誤検知の除外条件。これらを個人の頭の中ではなく手順書に反映することを、契約上の成果物として定義します。「手順書の更新」は準委任の中でも明示的な成果物として扱いやすく、引き継ぎの土台になります。

2. 検知ルールを資産として管理する

チューニングの結果を、変更履歴とともに自社側で管理します。誰が、いつ、なぜそのルールを変更したのかが残っていれば、担当者が交代しても運用は継続できます。管理場所を委託者の作業環境ではなく自社の管理下に置くことが要点です。

3. 月次レビューで社内担当者が説明できる状態をつくる

月次レポートを受け取るだけでなく、その内容を社内担当者が経営層や取引先に説明できる状態まで持っていきます。説明できるということは、理解が社内に移っているということです。この場を継続すると、兼務担当者でも一次判断できる範囲が徐々に広がります。

4. 引き継ぎ期間を契約で先に決めておく

契約終了時に1ヶ月程度の引き継ぎ期間を設ける旨を、稼働開始時の契約に入れておきます。終了が決まってから交渉すると、条件面で不利になりがちです。

まとめ｜SOC・CSIRTは「人」と「サービス」のどちらを外に出すかで決まる

SOC・CSIRT アナリストの確保がうまく進まないとき、その原因はたいてい人材市場の側ではなく、要件の側にあります。「24時間365日の監視体制を、業務委託の人材で埋める」という課題設定は、必要人数の目安から見ても成立しません。費用面で見ても、24/365 をカバーするフルマネージド SOC・MSS の月額と、平日日中のみをカバーするアナリスト1名の月額は同等かそれ以上の水準になります。一方で、平日日中の一次分析・チューニング・仕組み化という領域では、業務委託の人材はサービス委託では代替しにくい価値を持ちます。問うべきは「人かサービスか」の二択ではなく、「どの機能を、どの時間帯に、どの手段で持つか」です。

判断の骨子を最後に整理します。まず、自社に足りないのが SOC 機能か CSIRT 機能かを特定します。次に、24時間365日のカバーが本当に必要かを検証し、必要ならその時間帯は MDR・MSS を前提に置きます。そのうえで、自社環境のチューニングとナレッジ蓄積のために人材の業務委託を並行して配置します。同時に、対応方針の決定・隔離の承認・対外報告という社内に残す責任を氏名または役職まで落として確定させ、最後に準委任を基本とする契約形態と、判断権限・エスカレーションフローを文書化します。

この5つが埋まれば、募集要件も、稟議に載せる金額も、体制図も、そのまま書き出せます。逆に、どこか1つでも空欄が残っているなら、人材を探し始めるより先に、その空欄を埋める作業のほうが確実に成果につながります。

外部人材を活用した体制づくりの進め方を、社内の検討資料としてまとめてご覧になりたい方は、お役立ち資料をご利用ください。要件整理から契約条件の確認まで、検討の各段階で使える内容をご用意しています。

セキュリティ運用の体制設計や、外部人材の役割定義についてご相談されたい場合は、お問い合わせフォームからご連絡ください。要件が固まっていない段階からのご相談にも対応しています。