CSIRTとSOCの違いは検知と対応の役割分担

CSIRTとSOCは、どちらもサイバー攻撃から企業を守る組織ですが、担う役割が異なります。攻撃の兆候を見つけ出すのがSOC、見つかった問題への対応を指揮するのがCSIRTです。両者は対立するものではなく、検知と対応を互いに補い合っています。

主な違いを、下の表にまとめました。

SOCは攻撃の検知と分析を担う

SOC（Security Operation Center）は「ソック」と読み、セキュリティ機器やサーバーから集めたログを常に監視する組織です。

ツールが出したアラートを受け取り、それが本当に脅威かどうかを分析し、影響の及ぶ範囲を特定したうえでCSIRTへ報告するという流れで動きます。監視の対象はパソコンなどの端末からサーバー、社内外のネットワークにまで広がるため、24時間365日の体制が欠かせません。

CSIRTはインシデント対応を指揮する

CSIRT（Computer Security Incident Response Team）は「シーサート」と読み、インシデント発生時に組織全体の対応を指揮する組織です。

平常時は脆弱性情報の収集や社内規程の整備、従業員教育を担い、有事にはインシデントの受付から、対応の優先度を決めるトリアージ、被害の封じ込め、復旧、報告までを引き受けます。メンバーは技術部門だけにとどまらず、経営層や法務、広報を含む部門横断のチームになる点も見逃せません。

違いが生まれるのは担当フェーズと視点

両者の役割が分かれる理由は、担当するフェーズと物事を見る視点の違いにあります。SOCは攻撃の発生前から直後までを受け持ち、個々の事象を技術的な目線で細かく追う役割です。

これに対してCSIRTは発生後を引き継ぎ、事業へどれだけ影響するかという広い視点で全社の対応を指揮します。どちらが上位で優れているという関係ではなく、受け持つ範囲が異なるだけの、互いを補い合う補完関係です。

CSIRTとSOCが必要とされる背景

境界型防御で守るだけでは、巧妙化する攻撃を防ぎきれなくなりました。そこで近年は、侵入を前提として検知と対応で被害を最小限に抑える考え方が主流になっています。

実際、独立行政法人 情報処理推進機構（Information-technology Promotion Agency, Japan：IPA）の情報セキュリティ10大脅威2026では、ランサム攻撃による被害が組織向け脅威の1位を占めます。警察庁の資料でも、令和7年のサイバー犯罪の検挙件数は1万5,108件と過去最高に達しました。

経済産業省のガイドラインは緊急対応体制の整備を経営者がCISO等へ指示すべき重要項目に掲げ、取引先からセキュリティ水準を問われる場面も目立ちます。こうした状況が、検知を担うSOCと対応を担うCSIRTを備える動きを後押ししているのです。

参照元：IPA｜情報セキュリティ10大脅威 2026

参照元：警察庁｜令和7年におけるサイバー空間をめぐる脅威の情勢等について

参照元：経済産業省｜サイバーセキュリティ経営ガイドライン Ver3.0

混同しやすいPSIRT・MDR・NOCとの違い

CSIRTやSOCと並べて語られる用語に、PSIRT・MDR・NOCがあります。対象範囲・主な役割・設置形態の3つの軸で、下表にまとめました。

このうちPSIRT（Product Security Incident Response Team）は、自社が開発・販売する製品の脆弱性に対応するチームで、守る対象が社内ではなく製品を使う顧客側にある点がCSIRTと異なります。

一方のMDR（Managed Detection and Response）は組織の名称ではなく、検知から初動対応の支援までを外部ベンダーが提供するサービス形態を指す言葉です。

NOC（Network Operation Center）については、ネットワークや機器の安定稼働を保つ組織であり、監視の目的がセキュリティではない点で区別できます。

提案書にこれらの用語が並んだときは、求めているのが社内に置く組織なのか、外部から借りるサービスなのかを見極めると、選択を誤りません。あわせて押さえておきたいのが、組織とツールの層の違いです。EDRやXDRは端末や複数の領域から記録を集めて脅威を見つける仕組み、SIEMはそれらのログを突き合わせて異常を洗い出す仕組みであり、いずれも組織ではありません。SOCはこうしたツールを使いこなす組織、CSIRTはその報告を受けて動く組織という関係になります。

インシデント発生時の連携の流れ

SOCとCSIRTの役割分担は、実際のインシデント対応でこそはっきりします。攻撃の兆候を最初につかむのはSOCで、その報告を受けて全社の対応を動かすのがCSIRTです。

両者は検知から報告、対応へと情報をつなぎ、場面によってはCSIRTからSOCへ追加の調査を求めることもあります。そして対応は収束して終わりではなく、次に備えるための見直しまでが一続きの流れです。

以降では、この流れを検知・対応・見直しの3つの段階に分けて解説します。

SOCが異常を検知して優先度を判断する

連携の起点になるのはSOCです。SOCは複数の機器から集めたログやアラートを突き合わせ、不審な挙動を拾い上げたうえで、それが本物の脅威か誤検知かを見きわめます。日々大量に届くアラートのすべてに同じ手間はかけられないため、深刻度と影響範囲をものさしに優先度を決めるトリアージが欠かせません。

優先度が高いと判断したものは、分析結果に、いつ起きたのか、どのシステムが影響を受けているのかという情報を添えて、CSIRTへ引き渡します。

CSIRTが対応方針を決めて各部門に指示する

報告を受け取ったCSIRTの最初の仕事は、被害をどこまで封じ込めるか、業務を止めるべきかどうかを見定め、全社の対応方針を固めることです。

この方針にもとづき、事業継続への影響を評価しながら経営層へ状況を報告し、法務部門とは法的対応を検討し、広報部門とは公表内容を調整するというように、部門をまたいだ動きを同時に進めます。

現場には技術的な復旧作業を指示しますが、止めるか続けるかといった判断そのものは、事業への影響を見ながら下さなければなりません。

収束後に原因を分析して監視ルールに反映する

インシデントが収束しても、対応はそこで終わりません。SOCとCSIRTは共同で、攻撃者がどこから侵入したのか、対応のどこに遅れが出たのかを一つずつ振り返り、根本の原因を突き止めます。

そこで判明した攻撃の手口を、SOCが持つ監視ルールへ反映するのが次の一手です。検知ルールを見直しておけば、同じ手口ならば次回は早い段階でとらえられ、手順書に不備が見つかった場合には文書を更新して、次のインシデントに備えます。

自社に必要な体制を見極めるパターン

SOCとCSIRTは両方そろえるのが理想ですが、費用と人材の制約から、多くの企業は段階を踏んで整えるのが現実的です。そこで、いま自社に何が足りないかを見きわめ、着手する順番を決めることが出発点になります。

対応の窓口が定まっていないならCSIRTから、常時監視がないならSOC機能から、体力があるなら両方からという3つが代表的な道筋です。以降では、下表の型に沿って向き不向きと落とし穴を解説します。

CSIRTから設置して連絡窓口を一本化する

CSIRTから着手するときは、専任チームをいきなり用意する必要はありません。既存の情報システム部門の兼任からスタートし、インシデントの報告先を1か所にまとめて、発生時に誰へ連絡するかで迷わない体制づくりが出発点です。

この段階では高度な調査機能を追い求めず、まず報告が確実に集まる状態をつくることを優先します。あわせて、従業員が異常や不審な点に気づいたときにすぐ報告できる導線を全社へ知らせ、周知を徹底しておくことも欠かせません。

SOCサービスで監視機能だけを外部に確保する

監視をSOCサービスに委ねる場合は、契約を結ぶ前の取り決めが何より肝心です。監視してもらう対象の範囲と、どのようなときに通知を出すのかという条件を、あらかじめすり合わせておかなければなりません。

受け取ったアラートに社内で対応する担当を決めておかないと、通知が滞留し、せっかくの早期検知が活かせなくなります。検知までを任せるのか、初動対応の支援まで含めるのかは、サービスの範囲と費用を左右する分かれ目です。費用は監視する対象の台数やログの量、対応する時間帯によって変わるため、複数の事業者から同じ条件で見積もりを取り、範囲あたりの金額として見比べると判断しやすくなります。

両方を自社で構築して維持体制まで見込む

検知から対応までを自社で担うのであれば、監視の基盤をそろえるだけでは足りません。24時間365日の監視を止めずに回すには交代勤務を組める人員が要るため、その確保ができるかを先に見きわめておく必要があります。

採用した人材が定型的なアラート対応にばかり追われて疲弊しないよう、業務の割り振りをあらかじめ設計しておくことも大切です。そして立ち上げたあとも、手順書と監視ルールを継続して更新する担当を決めておかなければなりません。

CSIRT・SOCを立ち上げる手順

体制を立ち上げるとき、忘れてはならないのは、体制図をつくること自体が目的ではないという点です。めざすべきは、有事に関係者が迷わず動ける状態をつくることであり、形だけの体制では意味がありません。システム障害や災害に備える事業継続の計画とあわせて設計しておくと、対応の手順が重ならず、いざというときにも混乱を抑えられます。

JPCERT/CCが公開する構築の手引きなどを踏まえた、立ち上げの流れが次の5つの段階です。

• ●経営層の承認を得て、体制の目的を決める
• ●守る情報資産と現状の対策を洗い出す
• ●監視する対象と運用の形を決める
• ●役割と権限と対応フローを文書にする
• ●訓練と見直しを年間計画に組み込む

参照元：JPCERT/CC｜CSIRTマテリアル

経営層の承認を得て目的を決める

立ち上げの第一歩は、経営層の承認を得ることです。インシデント対応にはサービスの一時停止や外部への調査費用といった経営判断が伴うため、現場の担当者だけでは決めきれず、経営層の関与が欠かせません。

あわせて、何を守るための体制なのかという目的を先に定め、その範囲について関係部門と合意しておく必要があります。そのうえで、必要な予算と、緊急時にCSIRTが各部門へ対応を指示できる権限を、あわせて確保しておくことが土台になります。

守る情報資産と現状の対策を洗い出す

目的が定まったら、次は何をどこまで守るのかという対象を見きわめる番です。顧客情報や技術情報といった優先して守るべき資産を特定し、それがどこに保管されているのかを一つずつ棚卸しします。

あわせて、既存のセキュリティ製品とログの取得状況を洗い出し、いまは検知できていない範囲がどこかを明らかにしておかなければなりません。すべてを一度に守ろうとせず、資産の重要度に応じて優先順位をつけたうえで、対象範囲を無理なく絞り込みます。

監視する対象と運用の形を決める

続いて、先に洗い出した資産のうち、どの機器とどのログを常時監視の対象に含めるのかを決めていきます。監視を自社で担うか、外部のSOCサービスに委託するかは、24時間365日の体制を維持できるかどうかが判断の分かれ目です。

そして、アラートを受け取ったあとは誰が一次判断を行い、どの基準でCSIRTへ引き渡すのかまで、あらかじめ決めておきます。この引き渡しの基準があいまいなままだと、通知を受け取っても対応が動き出しません。

役割と権限と対応フローを文書にする

運用の形が見えてきたら、次は誰が何を担うのかを文書に落とし込む段階です。受付を担うのは誰か、判断を下すのは誰か、どこへ報告するのかを一つずつ定義し、一連の対応フローとして書き出します。

夜間や休日に発生した場合に備え、連絡の手段と、担当者が対応できないときの代行者もあらかじめ決めておかなければなりません。属人化を避けるため、手順書は担当者が交代しても同じように使える粒度で書いておくことが何よりも大切です。

訓練と見直しを年間計画に組み込む

文書ができあがったら、それが実際に使えるかどうかを訓練で確かめる番です。大がかりな演習でなくても、関係者が集まって机上で手順を追うだけの訓練で、手順書の抜けや漏れは十分に見つけられます。

そこで見つかった課題と、実際のインシデント対応から得た教訓は、そのつど手順書へ反映していかなければなりません。体制は一度つくって終わりではないため、年間計画にあらかじめ見直しの時期を組み込み、継続して整えていきます。

体制が機能する前提となるログと権限

SOCもCSIRTも、そもそも記録が残っていなければ、脅威の検知も、起きたあとの原因の究明も成り立ちません。たとえば共通アカウントのまま運用していると、操作を個人まで特定できず、有事の追跡が難しくなってしまいます。

そこで、SOCやCSIRTの設置に踏み切る前からでも着手できるのが、記録・権限・復旧という3つの整備です。誰が何をしたかを追える記録を残し、アクセス権を棚卸しし、ランサムウェアなどの被害を受けても戻せる時点を用意しておきます。

SIEM（Security Information and Event Management）のようなログ分析の基盤を入れる前に、必要なログがそもそも取得できているかを確かめておかなければなりません。SOCが最終的に必要とするログは、認証やネットワーク、エンドポイント、サーバーまで広がります。ただし、一度にすべてをそろえるのは難しいため、ここでは機密情報が集まり、漏えいの経路にもなりやすいファイル操作の記録に範囲を絞って点検します。自社がどこまで備えられているかは、下のリストで点検ができます

• ●ファイルの閲覧・ダウンロード・共有・削除が利用者単位で記録されている
• ●共通アカウントを使わず、操作を個人まで特定できる
• ●ログの保存期間が調査に必要な長さを満たしている
• ●誰がどのフォルダにアクセスできるかを一覧で確認できる
• ●異動と退職のたびに権限を見直す運用が決まっている
• ●暗号化や削除の被害を受けても戻せる時点が分かっている
• ●復旧の手順を実際に試したことがある

誰が何をしたかを追える記録があるか

まず確かめたいのは、日々のファイル操作が誰の行為として残っているかです。閲覧やダウンロード、共有、削除といった操作が、いつ誰の手で行われたのかが利用者ごとに記録されていれば、あとから経緯を正確にたどれます。

反対に、共通アカウントで運用していると、操作した人を個人まで絞り込めず、事後の追跡そのものが成り立ちません。あわせて、ログの保存期間が調査に必要な長さを満たしているかどうかも、点検しておきたいところです。

アクセス権が棚卸しされているか

アクセス権が棚卸しされているかどうかも、見逃せない確認項目です。部署異動や退職のたびに権限を見直す運用がないと、本人にはもう必要のない範囲のフォルダまで見えたままになりがちです。

経緯が分からないまま権限がブラックボックス化していると、いざというとき影響範囲の特定が後手に回りかねません。誰がどのフォルダにアクセスできるのかを、一覧でいつでも確認できる状態にしておくことが、迅速な対応の土台になります。

被害を受けても戻せるデータがあるか

被害を受けても元に戻せるデータがあるかどうかも、見過ごせないポイントです。暗号化や誤削除に見舞われたとき、どの時点の状態まで戻せるのかを、あらかじめ把握しておく必要があります。

注意したいのは、バックアップそのものが攻撃の標的になる場合があることで、保管場所を本番とは分けておく考え方が有効です。そして、復旧の手順は書いておくだけでなく、実際に試したことがあるかどうかまで確かめておかなければなりません。

DirectCloudで整える追跡と統制の基盤

ここまで挙げてきた記録・権限・復旧の3つの前提は、専任のセキュリティ担当を置けない組織にとって、負担の大きい課題です。それでも、ファイルを日々扱う基盤の側にこれらの仕組みがあらかじめ備わっていれば、専門人材がいなくても追跡と統制を無理なく確保できます。

DirectCloudは、操作ログの取得やアクセス権の管理、バージョン管理を標準で備えている基盤です。下表のとおり、3つの前提のそれぞれに、対応する機能と得られる状態を結びつけられます。前の章のチェックリストで印が付かなかった項目があれば、下表の同じ区分の行が、その穴を埋める機能にあたります。

ファイル操作を250種類以上のログで追える

DirectCloudは、ファイルに対する操作を250種類以上のログとして記録できる基盤です。利用者ごとに閲覧やダウンロード、共有、削除の記録が残るため、インシデントが起きたときに、誰がどのファイルを扱ったのかをさかのぼって追跡できます。

記録の対象は一般の利用者だけにとどまらず、管理者の操作や、ログインした日時と場所を示すログイン履歴まで含まれる点も見逃せません（管理者の操作ログの記録は、ご契約のプランによって利用できる範囲が異なります）。こうした記録がそろっていれば、事後の原因究明を確かな証跡にもとづいて進められます。

参照元：DirectCloud｜DirectCloud 監査

アクセス権と共有範囲を集中管理できる

アクセス権の管理も、DirectCloudの管理ページ上で一元的に行えます。フォルダごとに7種類のアクセスレベルから権限を設定でき、誰にどの範囲を許可しているのかを一覧で見渡せる仕組みです。

社外とのやり取りについては、リンクの使用制限によって、共有できる相手や範囲を細かく制御できます。権限がどこまで広がっているのかを部門単位で把握し直せるため、アクセス権の棚卸しにかかる手間も大きく抑えられる点が強みです。

参照元：DirectCloud｜セキュリティ（ユーザー機能）

ランサムウェアの被害から復元できる

復旧の備えとして頼りになるのが、DirectCloudのバージョン管理機能です。万が一ランサムウェアに感染してファイルが暗号化されてしまっても、バージョン管理によって、感染する前の状態までさかのぼって復元できます。この機能は一部の上位プランに限らず、全プランへ標準で提供される点も見逃せません。

そのため、高額な追加投資をしなくても、暗号化や誤削除といった被害から、業務に欠かせないデータを取り戻せます。なお、DirectCloudが担うのは、ファイルを保管する基盤側での記録と統制です。端末での攻撃の検知や、持ち出しそのものの制御は受け持つ範囲が異なるため、エンドポイント向けのランサムウェア対策や情報漏えい対策の製品と組み合わせると、検知から復旧までの隙間を埋められます。

参照元：DirectCloud｜ランサムウェア対策

ログと権限の整備で統制を強化した事例

ここまで説明してきた機能が実務でどう役立つのかは、実際に導入した企業の例を見るとよくわかるかと思います。取り上げるのは、システム開発・不動産管理・酒造という、業種も規模も異なる3社です。いずれも、操作の記録が残らない、アクセス権が見えない、復旧に手間がかかるといった課題を抱えていました。

それぞれがDirectCloudの導入によって、追跡と統制、そして復旧への備えをどのように整えたのかを、紹介します。

追跡できない状態からインシデント時に追える体制へ

システム開発やネットワーク構築を手がける東ソー情報システム株式会社様の例です。以前のオンラインストレージでは、ユーザーの操作ログを取得できず、内部統制の強化が図られていませんでした。共通アカウントを使っていたことから、有事の際に操作を個人まで特定できず、追跡性にも課題を抱えていたといいます。

DirectCloudの導入後は、250種類以上の操作ログ取得機能により、インシデントが発生した際の追跡性を確保できました。

権限のブラックボックス化を解消し統制を強化

次は、ビルメンテナンスや不動産管理を幅広く手がけるトーセイ・コミュニティ株式会社様の例です。ファイルサーバー管理の前任者がすでに退職しており、権限設定がブラックボックス化していました。Windows Server標準のログ取得機能には限界があり、詳細な操作ログまでは残せていなかったそうです。

移行後は、アクセス権やファイル操作の権限をユーザーごとに把握でき、250種類以上の操作ログによって内部統制を大幅に強化できました。

ランサムウェア対策と復旧工数の削減を両立

最後は、清酒や焼酎、リキュールを製造・販売する菊正宗酒造株式会社様の例です。オンプレミスのファイルサーバーではランサムウェアなどのサイバー攻撃への対策に苦慮し、対策を自力で行う負担が大きくなっていました。万一に備えてバックアップは取っていたものの、個々のファイルを戻すリストア対応が煩雑でした。

導入後はウイルス対策が容易になり、DirectCloudへデータを集約したことで、リストア対応にかかる工数も削減できました。

CSIRTとSOCに関するよくある質問

ここでは、CSIRTやSOCの体制づくりを進めるうえで、実務の担当者からよく寄せられる質問にお答えします。特に迷いやすいのは、担当者に資格は必要なのか、運用を外部にどこまで委託できるのか、メンバーをどの部門から集めるのかという3点です。

いずれも、体制の導入を判断する前に押さえておきたい現実的な論点になります。

資格は必須ではなく調整力が問われる

「CSIRTの担当者に専門資格は必要か」という質問をよく受けます。結論から言えば、特定の資格の保有を要件とする決まりは、特にありません。

日本シーサート協議会が公開する人材の定義でも、担当する役割ごとに必要なスキルが示されており、資格そのものよりも役割への適性が問われます。実務では、ログ分析などの技術的なスキルだけでなく、経営層や他部門と足並みをそろえる調整力やコミュニケーション能力が重視されるのです。

参照元：日本シーサート協議会｜CSIRT人材の定義と確保 Ver.2.1

委託できるのは支援まで判断は自社に残る

「CSIRTの構築や運用は外部に委託できるのか」も、よくいただく質問です。規程の整備や手順書の作成、訓練の実施、発生時の初動調査といった支援は、専門のベンダーに委託できます。

ただし、システムを止めるかどうか、顧客にどのように説明するかといった判断まで手放すことはできません。CSIRTは組織の司令塔にあたるため、外部の支援は借りられても、機能を丸ごと委ねられるものではない点に注意が必要です。

情報システム部門に法務と広報を加える

「CSIRTのメンバーはどの部門から集めるか」という質問も多く寄せられます。中心になるのは情報システム部門で、そこに全体を指揮する責任者、技術的な調査を担う担当、そして社内外の調整を担う担当を置く構成が基本になります。

専任を置くのが難しい場合は、兼任から始めても差し支えありません。法務や広報については、常設が難しくても、有事にすぐ連絡できる体制を決めておくだけで、部門横断のチームとして十分に機能します。人数の目安としては、指揮を執る役、技術的な調査を担う役、社内外の調整を担う役という3つの役割を兼任で割り当てるところから始められます。

まとめ

CSIRTとSOCの違いを正しく理解することは、自社に本当に必要なセキュリティ体制を見極めるための最初の一歩になります。サイバー攻撃が高度化し、侵入を前提とせざるを得ない今、検知を担うSOCと対応を指揮するCSIRTの役割分担を押さえることが欠かせません。両者の違いをふまえ、自社に足りない機能から段階的に体制を整えていくことが、限られた人材やコストのなかでも現実的な進め方です。

そして、記録・権限・復旧という土台を先に固めておけば、体制は形だけで終わらず、いざというときに迷わず動ける組織へと近づきます。まずは自社の現状を点検し、足りない部分を一つずつ整えていくことが、確かな備えへの近道です。

DirectCloudは、ファイル操作を250種類以上のログとして記録し、アクセス権の一元管理やバージョン管理による復元まで標準で備えた法人向けクラウドストレージです。専任のセキュリティ担当を置きにくい組織でも、追跡と統制の土台をファイルの基盤側から確保できます。記録・権限・復旧の備えを固めたい企業のご担当者様は、ぜひ導入をご検討ください。