SOCとCSIRTの違い｜役割・体制・立ち上げ手順を実務目線で整理

2026年5月29日

＠SOHO編集部

この記事のポイント

✓SOCとCSIRTの違いを
✓監視と対応という役割の軸から整理しました
✓自社に必要なのはどちらかを判断する3つのパターンまで

社内でセキュリティ体制の話が出るたびに、SOCとCSIRTという二つの言葉が並んで登場します。どちらもセキュリティの組織なのに名前が違う。似た説明が並んでいて、読めば読むほど境界が曖昧になる。皆さんがこの言葉を調べている背景には、たいていそういう混乱があります。

まず、安心してください。この二つは対立する概念でもなければ、どちらかを選ぶものでもありません。役割の担当範囲が違うだけです。結論から言えば、SOCは「攻撃に気づく」ための組織、CSIRTは「気づいたあとに動く」ための組織です。この一行が腹に落ちれば、あとの細かい違いはすべて枝葉として整理できます。

この記事では、二つの組織の役割と業務内容、5つの観点での比較、なぜ今どちらも必要とされているのか、そして実際に立ち上げるときの手順と失敗しやすい落とし穴までを書きます。私自身、メーカーで品質管理の仕事をしていたころに社内のインシデント対応フローの整備に関わり、独立してからも技術文書の作成を通じてセキュリティ部門の現場を見てきました。その経験から、教科書的な説明では伝わりにくい部分を補足していきます。

SOCとCSIRTの違いを一行で言うと

SOCは Security Operation Center の略で、「ソック」と読みます。ネットワークやサーバ、端末から上がってくるログを常時監視し、攻撃の兆候を検知して分析する組織です。役割の軸は「監視と検知」にあります。

CSIRT は Computer Security Incident Response Team の略で、「シーサート」と読みます。インシデントが発生したとき、被害を止め、原因を調べ、関係者に報告し、再発防止まで持っていく組織です。役割の軸は「対応と統制」にあります。

つまり、SOCはセンサーであり、CSIRTは司令塔です。火災報知器と消防隊の関係に近いと考えると分かりやすいでしょう。報知器が鳴らなければ消防隊は動けませんし、消防隊がいなければ報知器が鳴っても誰も消しに行きません。どちらか一方だけでは、セキュリティ体制は完成しません。

もう少し踏み込むと、SOCは技術的な領域に軸足があり、CSIRTは技術に加えて組織的な領域まで扱います。CSIRTの仕事には、経営層への報告、個人情報保護委員会への届出、取引先への連絡、報道対応の調整といった、技術者だけでは完結しない業務が含まれます。ここがSOCとの決定的な差です。SOCの成果物は「この通信は攻撃です」という分析結果であり、CSIRTの成果物は「被害をここで止め、こう報告し、こう直しました」という一連の意思決定です。

外部の専門事業者による解説でも、SOCの定義は次のように整理されています。

SOCとはシステム・ネットワークの状態を監視し、サイバー攻撃の検知や分析・対策を行うことで企業の情報資産を守るための組織です。「Security Operation Center」の頭文字をとった略語であり、「ソック」と読みます。セキュリティ専門の部署またはサービスとして、24時間365日体制で以下のような対応を行います。出典: group.gmo

ここで注目すべきは「24時間365日体制」という部分です。攻撃者は日本の営業時間に合わせて動いてはくれません。むしろ、連休の初日や深夜帯を狙う傾向があります。この常時性こそがSOCという組織形態を必要とする最大の理由であり、後述する内製と外部委託の判断にも直結します。

SOCが実際に担当する業務の中身

SOCの業務は、大きく四つに分けられます。順に見ていきます。

一つ目は、ログの収集と一元化です。ファイアウォール、IDS/IPS、プロキシ、サーバのOSログ、クラウドの監査ログ、端末のEDRログ。これらは放っておけばバラバラの場所に散らばっています。SOCはこれらを SIEM と呼ばれる基盤に集約し、横断的に見られる状態を作ります。地味な作業ですが、ここが甘いと後の工程がすべて崩れます。実際、私が見てきた現場で一番多かったつまずきは、高度な検知エンジンの選定ではなく、「肝心のサーバのログが取得設定されていなかった」という初歩的な穴でした。

二つ目は、アラートの監視と一次分析です。SIEM は相関ルールに従ってアラートを上げますが、その大半は誤検知です。正常な業務通信が攻撃パターンに似ているだけ、という事例が日常的に発生します。SOCのアナリストは、上がってきたアラートを順に見て、無視してよいものと調査が必要なものを仕分けします。この仕分けの精度が、組織全体の負荷を決めます。誤検知が多すぎると現場が麻痺し、本物のアラートを見落とすようになる。これをアラート疲れと呼びます。

三つ目は、脅威の深掘り分析です。怪しい通信が見つかったとき、その接続先が既知の攻撃インフラかどうか、送られたファイルがマルウェアかどうかを調べます。外部の脅威情報と突き合わせ、攻撃手法を特定し、影響範囲を推定します。ここまで来ると、単なるルールマッチングではなく、調査する人間の知見が成果を左右します。

四つ目は、検知ルールの改善です。一度作ったルールは放置すると劣化します。業務システムが変われば通信パターンも変わり、誤検知の傾向も変わります。新しい攻撃手法が出れば、それを拾うルールを追加する必要があります。SOCの品質は、この継続的なチューニングによって決まると言っても過言ではありません。

SOCの重要な性質として、SOCは原則として「止める判断」をしない、という点があります。ある端末をネットワークから隔離するか、あるサービスを一時停止するか。こうした業務影響のある判断は、CSIRTや経営層の領域です。SOCは事実を提供し、判断材料を揃えるところまでを担います。この線引きを曖昧にすると、現場のアナリストが業務を止める責任まで背負うことになり、組織として持ちません。

CSIRTが実際に担当する業務の中身

CSIRTの業務は、時間軸に沿って三つの局面に分かれます。

発生前の局面では、体制の整備が仕事です。インシデント対応手順書を作り、連絡体制を決め、訓練を実施します。誰が第一報を受け、誰が判断し、誰が外部に連絡するのか。これを平時に文書化しておかないと、有事に必ず混乱します。実際に起きた事故で被害が拡大する理由は、技術的な失敗よりも「誰も決められなかった」という組織的な失敗であることが多い。ここは強調しておきたい部分です。

発生中の局面では、指揮と封じ込めが仕事です。SOCから報告を受けたら、まず被害の範囲を見積もります。どの端末が侵害されたか、どこまで横展開されたか、情報が外部に送信された形跡があるか。そのうえで、隔離するか、パスワードを一斉に変えるか、外部への通信を遮断するかを決めます。同時並行で、経営層への報告と、必要であれば法令に基づく届出の準備を進めます。個人情報の漏えいが疑われる場合、報告義務の期限があるため、技術調査の完了を待っていると間に合いません。

発生後の局面では、原因究明と再発防止が仕事です。どの脆弱性から入られたのか、なぜ検知が遅れたのか、どの手順が機能しなかったのかを洗い出します。そして、技術的な対策だけでなく、手順やルールの改訂まで踏み込みます。ここで「担当者に注意喚起した」で終わらせてしまうと、同じことが必ず再発します。品質管理の世界では常識ですが、人の注意力に頼る対策は対策として数えません。仕組みで止めるか、仕組みで気づけるようにするか、そのどちらかまで持っていく必要があります。

CSIRT特有の業務として、外部組織との連携もあります。業界のCSIRTコミュニティ、警察のサイバー犯罪相談窓口、取引先のCSIRT。攻撃はサプライチェーンを経由して広がるため、自社だけを見ていても全体像がつかめません。平時から窓口を持っておくかどうかで、有事の初動速度が大きく変わります。

5つの観点で比較して整理する

二つの組織の違いを、実務で判断に使う観点から表にまとめます。

観点	SOC	CSIRT
主目的	攻撃の検知と分析	事故対応と収束
稼働時間	24時間365日の常時監視	平時は兼任、有事に招集
主な成果物	検知レポート、分析結果	対応方針、報告書、再発防止策
求められる技能	ログ解析、マルウェア解析、SIEM運用	判断力、調整力、法令知識、技術的理解
外部委託のしやすさ	委託しやすい	中核は内製が原則

最後の行が、実務上もっとも重要です。SOCは業務の標準化が進んでいるため、外部の専門事業者に委託しやすい領域です。監視という業務は、対象と条件を定義できれば他社でも実行できます。一方、CSIRTの中核である「自社の業務をどこまで止めるか」という判断は、自社の事情を知らない外部に任せられません。技術的な調査部分を外部の専門家に依頼することはあっても、意思決定そのものは社内に残す必要があります。

もう一つ、組織の形態にも差があります。SOCは専任の部署として設置されるか、外部サービスとして契約されるのが一般的です。対してCSIRTは、平時は各部門の担当者が本業と兼任し、有事に招集される仮想的なチームとして設計されることが多い。情報システム部門、法務、広報、人事、経営企画から一人ずつ出して構成する形です。この兼任型は、中堅規模の企業にとって現実的な選択肢になります。

なぜ今、この二つが注目されているのか

背景には、攻撃の質が変わったという事実があります。かつてのマルウェアは、感染すれば画面に症状が出るものが中心でした。今の標的型攻撃は、侵入してから数か月にわたって潜伏し、静かに情報を抜き続けます。症状が出ないため、監視していなければ気づけません。

実際の被害事例として、次のような指摘があります。

実際に2位の「標的型攻撃による機密情報の窃取」による被害で、日本年金機構は2015年5月、年金加入者約125万件の情報が流出する被害にあっています。これらのサイバー攻撃はインシデント後の迅速な対応が必要なだけでなく、最新の情報や機器のログなどから脆弱性を検証し、侵入経路などの対策が不可欠です。出典: group.gmo

この事例が示しているのは、「迅速な対応」と「ログからの検証」という二つの要素が同時に必要だということです。前者がCSIRT、後者がSOCの守備範囲にあたります。どちらか一方だけでは、被害の把握も再発防止も成立しません。

もう一つの背景は、境界防御という考え方が通用しなくなったことです。社内ネットワークの入口にファイアウォールを置き、内側は安全とみなす。この前提は、クラウド利用とリモートワークの普及によって崩れました。社員の端末は社外にあり、データはクラウドにあり、取引先のシステムと直接つながっている。守るべき境界が消えた以上、「侵入されている前提で、異常を見つけて対応する」という運用型の防御に移行せざるを得ません。これがSOCとCSIRTの必要性を押し上げた構造的な要因です。

加えて、取引先からの要求も無視できません。大企業と取引する中堅・中小企業に対して、セキュリティ体制のチェックシートが送られてくるケースが増えています。インシデント対応体制の有無を問う項目は、ほぼ必ず含まれます。自社を守るためだけでなく、取引を継続するための条件としても、体制の整備が求められる時代になりました。

サイバーセキュリティ対策を進めるうえで使える公的支援については、中小企業向けの補助制度を扱った記事にまとめています。中小企業のサイバーセキュリティ対策2026｜IT導入補助金で防御力を強化する方法では、対象となるツールと申請の流れを整理しているので、予算の裏付けを探している方は参考になるはずです。

SOCを立ち上げる方法と流れ

SOCの立ち上げは、次の五つのステップで進みます。

第一に、守る対象を決めます。すべてを監視しようとすると必ず頓挫します。事業の継続に直結するシステムはどれか、止まったら売上が立たないのはどれか、漏れたら取引が止まる情報はどこにあるか。この優先順位づけを先に済ませます。ここを飛ばして機器の選定から入るのが、典型的な失敗パターンです。

第二に、ログの取得設計を行います。対象システムから、どのログを、どの粒度で、どれだけの期間保存するかを決めます。保存期間は重要です。侵入から発覚まで数か月かかる攻撃に対して、ログを30日しか保存していなければ、原因の追跡が不可能になります。最低でも6か月、可能なら1年以上を確保したいところです。

第三に、基盤を構築します。SIEM やログ管理基盤を導入し、収集経路を作ります。ここでクラウド型を選ぶか、オンプレミス型を選ぶかは、扱うデータの性質と予算で決まります。

第四に、検知ルールを作り、運用を始めます。最初から精緻なルールは作れません。まず広めに検知し、誤検知を潰しながら絞り込んでいく。この試行錯誤の期間を最初から工程に織り込んでおくことが、現実的な計画の条件です。

第五に、運用体制を決めます。ここで24時間365日という要件が効いてきます。自社で3交代の体制を組むには、最低でも相当数の専任人員が必要です。この人数を確保できる企業は限られます。だからこそ、外部委託という選択肢が現実的になります。

サイバー攻撃が多様化していることやセキュリティ人材が社内に確保できないこと、また24時間365日体制が必要なことから、外部のSOCサービスを利用する企業が多くなっています。出典: group.gmo

外部委託を選ぶ場合、事業者選定のポイントは三つです。対応範囲がどこまでか（検知までか、初動の封じ込めまでか）、報告の形式と頻度がどうか、そして緊急時の連絡が何分以内につながるか。この三点を契約前に文書で確認しておくと、後のトラブルを避けられます。

CSIRTを立ち上げる方法と流れ

CSIRTの立ち上げは、技術よりも組織設計の色が濃くなります。

最初に決めるのは、権限の範囲です。CSIRTが「業務システムを停止してよい」と決められるのか、それとも経営層の承認が要るのか。承認が要るなら、深夜にその承認を誰がどうやって出すのか。この一点が曖昧なまま体制を作ると、有事に必ず止まります。実際、対応が遅れた事例の多くは、技術的に難しかったからではなく、決裁が回らなかったからです。

次に、構成メンバーを決めます。技術担当だけで組まないことが重要です。法務は届出と契約上の責任を、広報は外部説明を、人事は内部不正が絡む場合の処分を、経営企画は事業影響の見積もりを担当します。この横断性がCSIRTの本質です。

続いて、手順書を作ります。分厚いマニュアルではなく、最初の1時間で何をするかを1枚にまとめたものが実用的です。第一報を受けたら誰に連絡し、どの情報を集め、どのタイミングで招集をかけるか。慌てている人間が読めるのは、1枚だけです。

そして、訓練を実施します。机上演習で構いません。「ランサムウェアで基幹システムが暗号化された」という想定で、関係者を集めて2時間だけ議論する。それだけで、手順書の穴が必ず見つかります。訓練をやらないCSIRTは、存在していないのとほぼ同じです。

最後に、平時の活動を決めます。CSIRTは事故が起きるまで暇なわけではありません。脆弱性情報の収集と社内展開、対応手順の見直し、SOCからの定期報告のレビュー。この平時の活動があるからこそ、有事に機能します。

立ち上げと運用でよくある失敗

現場を見てきて、繰り返し目にした失敗を挙げておきます。

一つ目は、ツールを買えば体制ができると考えてしまうことです。高機能な検知製品を導入しても、アラートを見て判断する人がいなければ、ただの通知装置で終わります。予算配分で言えば、製品費と運用人件費はおおよそ同等かそれ以上の比率で見積もるのが現実的です。

二つ目は、アラートを絞りすぎることです。誤検知の多さに耐えかねて閾値を上げていくと、いつの間にか本物も拾わなくなります。絞るのではなく、仕分けの手順を作って処理速度を上げる方向で解決すべきです。

三つ目は、SOCとCSIRTの間の受け渡しを定義していないことです。SOCがどのレベルの検知でCSIRTに上げるのか、上げる際にどの情報を添えるのか。ここを決めていないと、SOCは「報告済み」、CSIRTは「聞いていない」という食い違いが起きます。私が関わった現場でも、外部委託のSOCから来たメールが担当者の受信箱で埋もれ、3日間気づかれなかったという事例がありました。技術の問題ではなく、受け渡しの設計の問題です。

四つ目は、訓練をやらないことです。前章で書いたとおり、手順書は訓練しなければ機能を保証できません。年1回で構わないので、必ず実施する計画に組み込んでください。

五つ目は、経営層への説明を技術用語で行ってしまうことです。「EDRのアラートが上がり、C2通信の疑いがあります」では判断できません。「情報が外部に送られている可能性があり、確認のために基幹システムを2時間止める必要があります。売上への影響は概算でこの程度です」と翻訳して伝える。この翻訳ができる人がCSIRTにいるかどうかが、初動の速度を決めます。

フィッシングメールを入口とする侵入が依然として多いことを踏まえると、従業員教育も体制の一部と考えるべきです。訓練の設計と効果測定については、社員のセキュリティ意識を向上させるフィッシングメール模擬訓練の効果｜2026年最新の従業員教育ガイドで具体的な実施手順を扱っています。

連携を機能させるために決めておく4つの取り決め

SOCとCSIRTは、それぞれが優秀でも、あいだの受け渡しが設計されていなければ成果が出ません。ここを機能させるために、具体的に何を決めておけばよいかを書きます。

一つ目は、エスカレーションの基準です。どのレベルの検知でSOCからCSIRTへ連絡が入るのかを、段階で定義します。たとえば、レベル1は情報共有のみで定期報告にまとめる、レベル2は担当者へメールで連絡、レベル3は電話で即時連絡し招集を検討する、といった具合です。段階の数は三つから四つが扱いやすく、それ以上に細かくすると現場が覚えきれません。重要なのは、基準を「重大な場合」といった曖昧な言葉で書かないことです。「業務システムの認証基盤に対する異常な認証試行」のように、観測できる事象で書きます。

二つ目は、連絡手段の冗長化です。メール1本に頼ると、前章で書いたように受信箱で埋もれます。メールに加えて、電話、チャットツールの専用チャンネル、この三つを併用し、レベル3では電話を必須にする。そして、電話がつながらなかった場合の次の連絡先まで決めておきます。深夜と休日の連絡先を明記していない体制は、実質的に平日日中しか機能しません。

三つ目は、引き渡す情報の型です。SOCからCSIRTへ連絡するとき、何を添えるかを定型化します。検知の時刻、対象の資産名と管理部門、観測された事象、影響が疑われる範囲、SOC側の暫定評価、そして推奨する初動。この六項目がテンプレートとして決まっていれば、CSIRT側は受け取った瞬間に判断に入れます。毎回自由記述だと、情報を追加で聞き直すやり取りで30分から1時間が失われます。

四つ目は、対応後の振り返りの場です。インシデントが収束したあと、SOCとCSIRTが同席して経緯を洗う会議を必ず設定します。検知は適切だったか、連絡は速かったか、判断に必要な情報は揃っていたか。この振り返りから出てくる改善点が、検知ルールと手順書の両方に反映されていく。この循環を回している組織は、1年で見違えるほど対応が速くなります。逆に、振り返りをやらない組織は、3年経っても初動の混乱が同じままです。

この四つは、どれも技術ではなく取り決めです。費用はかかりません。それでも、ここを整えているかどうかで体制の実効性は大きく変わります。予算の制約で監視の高度化に手が回らない組織こそ、まずここから着手する価値があります。

自社に必要なのはどちらか、3つのパターン

ここまでを踏まえて、自社にどう当てはめるかを考えます。組織の規模と状況によって、現実的な解は三つに分かれます。

パターン1は、CSIRT機能だけを先に作る形です。従業員規模が数十名から百名程度で、専任のセキュリティ担当を置けない企業に適しています。監視はクラウドサービスや端末のEDRに任せ、何か起きたときに誰がどう動くかだけを決めておく。費用対効果で言えば、ここが最初の一歩として最も合理的です。手順書1枚と連絡体制だけでも、あるのとないのでは初動が決定的に変わります。

パターン2は、SOCを外部委託し、CSIRTを内製する形です。中堅規模の企業で最も多い構成です。常時監視という人手のかかる部分を専門事業者に任せ、判断と対応を社内に残します。外部委託の費用は監視対象の台数や範囲によって幅がありますが、自社で3交代の常時体制を組むより安く収まるケースがほとんどです。この構成を選ぶ場合、前章で書いた受け渡しの定義を契約書と運用手順の両方に明記しておいてください。

パターン3は、両方を内製する形です。金融機関や大規模なサービス事業者など、扱う情報の性質上、外部に監視を委ねにくい組織が選びます。人材の確保と育成に継続的な投資が必要で、組織としての体力が前提になります。

判断の軸は、「止める判断を外に出せるか」と「常時体制のコストを自社で負担できるか」の二つです。この二軸で整理すれば、自社がどのパターンに該当するかはすぐに決まります。

多要素認証のような基礎的な防御を固めることも、検知すべきアラートの母数を減らすという意味で有効です。導入の判断材料はMFA（多要素認証）導入のメリットと製品比較｜2026年の認証セキュリティ決定版にまとめています。

人材から見たセキュリティ体制の現実

ここからは、フリーランスと在宅ワークの市場を20年にわたって運営してきた立場からの観察を書きます。

セキュリティ体制の議論は、どうしても組織と製品の話になりがちです。しかし運営者として見てきた限りでは、実際に体制が回るかどうかを決めているのは、ほとんどの場合「人が確保できるか」の一点でした。SIEM を入れても、ルールを書ける人がいなければ空回りします。手順書を作っても、それを更新し続ける担当がいなければ1年で形骸化します。

興味深いのは、この領域で長く仕事が続いている人ほど、高度な解析技術を売りにしていないことです。むしろ、「この人に任せておけば、アラートの仕分けから報告書の作成まで一通り面倒を見てくれる」という信頼で継続している。単発の解析作業ではなく、運用を丸ごと受け持つ関係のほうが、発注側にとっても受け手にとっても安定するからです。長く続く人ほど、この関係づくりに時間を使っています。

もう一つ、体制の外側で効いてくるのが取引の構造です。セキュリティ運用を外部の人材に頼むとき、仲介手数料が二重三重に乗る経路を通ると、同じ予算でも実際に手を動かす人に届く額が目減りします。逆に中間マージンが乗らない直接の取引であれば、依頼する側は同じ予算でより多くの工数を確保でき、受け手の手取りも厚くなる。手数料0%という条件が意味を持つのは、金額の多寡そのものではなく、この「手取りが厚いから継続してもらえる」という質の部分です。運用型のセキュリティ業務は継続性がすべてなので、この構造は成果に直結します。

業務の相場感を把握したい方のために、関連する職種のデータも挙げておきます。システム開発や運用の実務を担う人材の報酬水準はソフトウェア作成者の年収・単価相場にまとまっており、インシデント報告書や手順書の作成といった文書業務の相場は著述家，記者，編集者の年収・単価相場が参考になります。体制の予算を組むとき、この二つの水準を押さえておくと、外部委託と内製のどちらが現実的かを数字で比較できます。

仕事の内容から体制づくりを考えたい方には、AI・マーケティング・セキュリティのお仕事が参考になります。セキュリティ領域でどのような業務が業務委託として流通しているかを一覧できるので、自社のどの工程を外に出せるかを検討する材料になります。ネットワークの基礎を押さえた人材を評価したい場合は、CCNA（シスコ技術者認定）の出題範囲を見ておくと、候補者のスキルを測る目安になります。

最後に、私自身の失敗を書いておきます。前職で社内のインシデント対応フローを整備したとき、私は完璧な手順書を作ることに時間をかけすぎました。結果として、50ページを超える文書ができあがり、誰も読まないまま棚に置かれました。実際に役立ったのは、その後に作り直した「最初の1時間にやること」を書いた1枚の紙でした。体制づくりで大事なのは網羅性ではなく、慌てている人が読める形になっているかどうかです。皆さんが立ち上げに取りかかるときは、まず1枚から始めることをおすすめします。