CSIRTとSOCの違いとは？役割・業務・連携方法をNIST・NCSC・JPCERT/CCから解説|セキュリティ対策Lab

投稿日時: 2026年09月10日更新日時: 2026年09月10日

CSIRTとSOCの違いは、組織名ではなく「どの業務を中心に担うか」で整理すると分かりやすくなります。

SOC（Security Operations Center）は、ログやアラートを継続的に監視し、サイバー攻撃や侵害の兆候を検知・分析する機能を中心に担います。

CSIRT（Computer Security Incident Response Team）は、インシデントを認知した後の調査、封じ込め、復旧、再発防止、社内外との調整などを進める機能を中心に担います。

ただし、両者の境界は固定ではありません。

JPCERT/CCの「CSIRTガイド」は、CSIRTのインシデント対応について、インシデントの検知または報告受領、情報収集・分析、復旧、再発防止までを一連の活動として説明しています。英国National Cyber Security Centre（NCSC）も、MonitoringとIncident Managementが同じ人員で構成される場合があるとしています。

そのため、「SOCは検知だけ」「CSIRTは対応だけ」と完全に切り分けるのではなく、監視から対応、復旧、改善までの責任分界を決めることが実務上のポイントです。

CSIRTとSOCの違い

項目	SOC	CSIRT
主な目的	攻撃・侵害の兆候を検知し、分析する	インシデントによる被害を抑え、復旧まで進める
平常時の中心業務	ログ監視、アラート分析、トリアージ、検知改善、Threat Hunting	対応手順整備、連絡体制、演習、外部連携、対応能力の維持
インシデント時	追加調査、影響範囲の確認、技術情報提供、初動対応	対応統括、封じ込め、復旧、証拠保全、社内外調整
主に扱う情報	ログ、アラート、通信、IOC、TTP、資産情報	SOC分析結果、事業影響、顧客影響、法務・規制・広報上の情報
主な関係者	SOCアナリスト、セキュリティエンジニア、情シス	IT、セキュリティ、経営、法務、広報、人事、事業部門など
稼働	継続監視が中心	平時も準備活動を行い、インシデント時に活動が拡大
外部委託	監視・一次分析を委託しやすい	技術支援は委託可能。事業判断や社内調整は自社に残る
両者の接点	インシデント候補を分析し、必要な情報を引き渡す	引き継いだ事象を組織として対応する

この表は典型的な役割分担です。

SOCが端末隔離やアカウント停止まで実施する企業もあれば、CSIRTがフォレンジックやログ分析、Threat Huntingを担当する企業もあります。

NCSCはSOCについて「one-size-fits-all」のモデルはないとし、組織が直面する脅威、守る資産、利用可能なリソースに応じて設計するよう案内しています。

SOCは監視・検知・トリアージを中心に担当する

NCSCはSOCの目的について、予防策をすり抜けたサイバー攻撃を検知し、対応することで組織への被害を抑えることと説明しています。

代表的な業務は次のとおりです。

ログ収集
アラート監視
一次トリアージ
関連ログを使った追加調査
検知ルール開発
脅威インテリジェンスの活用
Threat Hunting
インシデント候補のエスカレーション
検知ルールやRunbookの改善

SOCの仕事は「アラートを見る」だけではありません。

アラートが誤検知なのか、攻撃の兆候なのか、すでに侵害が成立しているのかを確認し、次の判断に必要な技術情報をそろえます。

NCSCのCyber Assessment Framework（CAF）v4.0では、Monitoring and Detectionの担当者について、ログやアラートを分析・調査する能力だけでなく、監視対象システムの運用上の文脈を理解することも求めています。

CSIRTはインシデント対応を組織横断で進める

JPCERT/CCはCSIRTを「コンピューターセキュリティインシデントに対応するチーム」と説明しています。

CSIRTはインシデント対応を組織横断で進める

同ガイドでは、CSIRTによるインシデント対応を次の一連の活動として整理しています。

インシデントを検知する、または報告を受けて発生を認知する
影響の拡大を防ぐ
情報を収集・分析し、全体像や原因を把握する
復旧措置を行う
再発防止策を検討・実施する

CSIRTは単なる技術対応チームではありません。

NCSCは、CSIRTの中核をIT・Cyber Security担当としつつ、インシデントの内容に応じて経営層、Incident Manager、Technical Lead、IT・インフラ、フォレンジック、事業継続、法務、広報、人事、顧客対応、外部IR事業者、政府・法執行機関などが参加するとしています。

顧客情報への不正アクセスが疑われる場合、技術調査だけでは対応は完了しません。システム停止、顧客通知、規制当局への報告、対外公表、サービス再開などの判断が発生します。

NIST SP 800-61 Rev.3で見るSOCとCSIRTの関係

NISTは2025年4月、インシデント対応ガイド「SP 800-61 Rev.3」を最終版として公開しました。

Rev.3は2012年のRev.2を置き換え、NIST Cybersecurity Framework（CSF）2.0に沿ってインシデント対応を整理しています。

NISTは、インシデント対応をDetect、Respond、Recoverだけの作業とはしていません。CSF 2.0の6機能すべてが関係するとしています。

NIST CSF 2.0	インシデント対応との関係
Govern	方針、役割、権限、リスク管理
Identify	資産・リスク・依存関係の把握
Protect	予防策と被害軽減
Detect	攻撃・侵害の兆候を発見し分析
Respond	インシデントを管理し、優先順位付け・封じ込め等を実施
Recover	影響を受けた資産・業務を復旧

SOCは主にDetectに深く関わり、CSIRTはRespondとRecoverの調整に深く関わるとなります。

ただし、NISTが「SOC＝Detect」「CSIRT＝Respond」と組織名を一対一で定義しているわけではありません。

NCSC CAF v4.0では監視とIncident Managementの連携を明示

NCSCのCAF v4.0は2025年8月に公開されています。

CAFのSecurity Monitoringでは、監視・検知機能について、何を監視するか、誰が分析・調査するか、どの事象をエスカレーションするか、誰へ何の情報を渡すかを明確にする考え方が示されています。

さらにNCSCは、Monitoring capabilityがIncident Managementとシームレスに連携すべきだとし、両機能が同じ人員で構成される場合もあると明記しています。

公的ガイドが求めているのは「SOC部署」と「CSIRT部署」を必ず二つ作ることではありません。検知から対応までを切れ目なく動かせることです。

FIRSTのCSIRT Services FrameworkではCSIRTの業務範囲を固定していない

FIRSTは「CSIRT Services Framework v2.1」を公開しています。

同フレームワークはCSIRTが提供し得るサービスと機能を体系化したもので、すべてのCSIRTが掲載された全サービスを提供する必要はないとしています。

2026年5月には「Metrics for the CSIRT Services Framework v1.1」も公開され、CSIRTサービスを定量・定性指標で評価し改善する考え方が示されました。

CSIRTを設置した後は、チーム名や人数だけではなく、インシデント認知までの時間、対応開始までの時間、エスカレーション品質、対応記録の完全性、復旧や改善の実施状況など、自社のサービス内容に合った指標を設定できます。

アラートとインシデントは同じではない

SOCが受け取るアラートのすべてがインシデントになるわけではありません。

NCSCもSOCガイドで「Not every alert will be an incident」と説明し、トリアージを求めています。

SOCでは次を確認します。

誤検知ではないか
対象端末やアカウントは何か
対象資産の重要度は高いか
攻撃が成功した証拠はあるか
他の端末・アカウントへ広がっていないか
外部通信が発生していないか
認証情報へのアクセスがないか
自社のインシデント認定基準を満たすか

「インシデントと認定する権限」をSOCに置くか、CSIRT責任者に置くかは企業ごとに異なります。誰が認定するかを事前に決めます。

SOCからCSIRTへ何を渡すか

SOCからCSIRTへ「Critical Alertが出ました」とだけ伝えても、CSIRTは対応方針を判断しにくくなります。

情報	内容
発生日時	最初のイベント、直近のイベント
対象	端末、アカウント、IP、システム
資産重要度	基幹、顧客情報、認証基盤、検証環境など
検知内容	何を根拠にアラートが発生したか
調査結果	SOCが確認した事実
関連ログ	EDR、認証、DNS、Proxy、クラウドなど
影響	横展開、外部通信、情報アクセスの有無
未確認事項	まだ確認できていない点
実施済み措置	隔離、セッション失効など
推奨初動	次に取るべき技術措置
緊急度	いつまでに判断が必要か

NCSCは、アラート設計について5W1Hを意識し、アナリストが迅速に内容を理解してトリアージ・エスカレーションできる情報を含めるよう推奨しています。

CSIRTからSOCへ戻す情報

連携はSOCからCSIRTへの一方向ではありません。

インシデント対応後は、次の情報をSOCへ戻します。

実際の侵入経路
悪用されたアカウント
IOC
攻撃者のTTP
有効だったログ
欠けていたログ
見逃していた挙動
誤検知だった条件
追加すべき監視対象
再発防止策

NIST SP 800-61 Rev.3は、インシデント対応で得た知見をGovern、Identify、Protectなどへ戻し、継続的に改善する考え方を採っています。

NCSC CAFも、インシデントや演習のLessons LearnedをSecurity MonitoringやInvestigation、Containment、Governanceへ反映するよう案内しています。

SOCとCSIRTはどちらが上なのか

SOCとCSIRTに一般的な上下関係はありません。

企業では次のような構成が考えられます。

SOCとCSIRTを別部署にする
CSIRTの中にSOC機能を置く
SOC組織の中にIncident Response機能を置く
情報システム部門がSOCとCSIRTの機能を兼務する
SOCを外部委託し、CSIRT機能を社内に置く
MDRへ監視・調査・一部初動を委託し、社内CSIRTが意思決定する

組織図よりも、監視、分析、インシデント認定、封じ込め、復旧、公表などの担当と権限を決める方が先です。

SOCだけあればCSIRTは不要か

SOCの分析能力が高くても、企業としての意思決定は残ります。

たとえばランサムウェアが重要サーバーで確認された場合、ネットワーク遮断、基幹システム停止、復旧、顧客・取引先への連絡、規制当局への報告、公表などの判断が発生します。

外部SOCやMDRが技術的な推奨を出しても、事業停止や対外公表の最終判断は企業側に残ります。

NCSCも、インシデント対応を外部委託する場合でも、社内に事業への影響を判断し、外部専門家の助言を受けて意思決定する人員を置くよう案内しています。

CSIRTだけあればSOCは不要か

CSIRTが存在していても、攻撃を発見できなければ対応開始は遅れます。

専任SOCを設置しない場合でも、EDRやクラウドのアラート監視、認証ログの異常検知、メール・Web・DNSの監視、利用者からの通報、委託先や外部機関からの通知、脅威情報との照合、必要に応じたThreat HuntingといったDetect機能は必要です。

監視を外部SOCやMDRへ委託する場合も、どの条件で社内へ連絡するか、夜間に誰が受けるか、誰が隔離やアカウント停止を承認するかを契約と社内手順の両方で決めます。

関連記事：MDRとEDRの違いとそれぞれの特徴を解説

SOCとCSIRTは24時間365日必要なのか

SOCもCSIRTも、名称だけで24時間365日が必須になるわけではありません。

NCSCはSOCの規模・能力を脅威、資産、利用可能なリソースに応じて設計するよう案内しています。CSIRTについても、必要な対応時間は事業特性とリスク許容度によって決めるとしています。

確認すべきなのは次の4点です。

重大アラートを何分・何時間以内に確認するか
誰がトリアージするか
誰が夜間・休日の初動を実行するか
どの重大度でCSIRT・経営へエスカレーションするか

SOCが24時間監視していても、深夜の端末隔離やアカウント停止を実行できる担当者がいなければ、検知から対応までに空白が生じます。

SOCとCSIRTの役割分担チェック表

業務	SOC	CSIRT	情シス	経営・法務・広報等
アラート監視
トリアージ
追加調査
インシデント認定
端末隔離
アカウント停止
証拠保全
事業影響判断
顧客通知
規制当局対応
対外公表
復旧判断
検知改善