アラート検知後の「最初の1時間」に何をすべきか。SOCとCSIRTの役割分担、NIST SP 800-61 Rev.3の考え方、確度判定から封じ込め・証拠保全・報告・復旧までの7ステップ、個人情報保護委員会への報告期限や警察相談など日本企業の実務、ランサムウェア初動、AIエージェント活用時の承認設計を解説します。
セキュリティインシデントの被害の大きさは、攻撃の巧妙さそのものより、検知から最初の対処までの時間と、その対処の質で決まることが多いものです。EDR（Endpoint Detection and Response：端末の挙動を監視する製品）やSIEM（Security Information and Event Management：ログを集約・相関分析する基盤）が不審な挙動を検知しても、「本物か」「どこまで広がっているか」「端末を止めてよいか」「誰に報告するか」という判断が滞れば、攻撃者はその間に横展開やデータの持ち出しを進めます。多くの組織の課題は検知そのものではなく、検知した後の「最初の1時間」に誰が判断し、誰が手を動かすかが決まっていないことです。
この課題はランサムウェアで最も鮮明に表れます。IPAの「情報セキュリティ10大脅威 2026」では、「ランサム攻撃による被害」が11年連続で選出され、2026年版の組織向け脅威で1位となりました（IPA, 2026）。警察庁が2026年3月に公表した報告書によると、2025年（令和7年）のランサムウェア被害報告件数は226件と依然として高い水準で、復旧に総額1,000万円以上を要した組織が全体の5割を超え、1か月未満で復旧できた組織は5割強にとどまっています（警察庁, 2026）。初動の遅れは、そのまま復旧期間と費用に跳ね返ります。
本記事では、SOCとCSIRTの役割分担を整理し、2025年4月に改訂されたNIST SP 800-61 Rev.3の考え方を確認したうえで、検知の確度判定から封じ込め、証拠保全、報告、復旧、事後レビューまでの初動ランブックを示します。あわせて、個人情報保護委員会への報告や警察への相談といった日本企業に固有の実務、ランサムウェア初動の注意点、そしてSOCの一次調査をAIエージェントが担う場合に初動がどう変わるかを解説します。
SOCとCSIRTの役割分担——「気づいて確かめる」と「決めて動かし、伝える」
SOC（Security Operations Center）は、ログとアラートを監視し、不審な事象を検知・分析する組織です。インシデント検知はSOCの中心的な工程であり、EDRやSIEMのアラートを受けて真偽を判定し、影響範囲の初期的な見立てを行い、対応が必要と判断したものを次の担当者へ引き渡します。24時間365日の監視を外部委託（MSS）で実現している組織も多く、その場合、SOCの実体は社外にあります。
一方のCSIRT（Computer Security Incident Response Team）は、JPCERT/CCの定義では「組織内の情報セキュリティ問題を専門に扱う、インシデント対応チーム」です（JPCERT/CC）。JPCERT/CCは組織内CSIRTの構築を支援する「CSIRTマテリアル」を、構想・構築・運用の3つのフェーズに分けて公開しています。実務上のCSIRTの役割は、インシデントの宣言と対応全体の指揮、封じ込め措置の承認、経営層・法務・広報・事業部門との調整、そして当局・警察・取引先・JPCERT/CCなど社外に対する窓口です。SOCが「気づいて確かめる」組織であるのに対し、CSIRTは「決めて動かし、伝える」組織だと整理できます。
重要なのは、両者の境界で何が起きるかです。多くの日本企業では、CSIRTは情報システム部門や総務・法務部門の兼務による仮想的な組織で、SOCは外部委託先という組み合わせが一般的です。この構成では、SOCからCSIRTへの引き渡し（ハンドオフ）が最も遅延しやすい箇所になります。委託先から「不審な通信を検知しました。確認してください」というメールが届き、担当者が翌朝それを読み、社内で確認に回している間に半日が過ぎる、という構図です。引き渡しを速くするには、どの重大度でどの時間内に、どの手段で、どの形式の情報を渡すかを事前に定義しておく必要があります。SOCがCSIRTに渡すべき情報は、一般に次の5点です。
検知内容と時刻、確度：何を検知し、真陽性である確からしさがどの程度か。判定の根拠を添えます。
影響範囲の初期見立て：関与が確認された端末・アカウント・サーバーと、まだ確認できていない範囲。
実施済みの封じ込め：既に隔離した端末や無効化したアカウントなど、SOCの権限内で行った措置。
推奨する次の対処：CSIRTの承認が必要な措置と、その理由。
証跡の所在：判定に用いたログやアラートがどこに保存され、どう参照できるか。
この5点が揃っていれば、CSIRTは受け取った瞬間から判断を始められます。「アラートが出た」という事実だけが渡されると、CSIRT側で一次調査をやり直すことになり、初動は二重に遅れます。
NIST SP 800-61 Rev.3——インシデント対応はリスク管理の一部になった
インシデント対応の標準として長く参照されてきたのがNIST SP 800-61です。2012年8月のRev.2は、「準備」「検知と分析」「封じ込め・根絶・復旧」「事後活動」の4フェーズからなるライフサイクルを示し、日本でも多くの組織の手順書の骨格になってきました。2025年4月、NISTはこれを改訂したRev.3「Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile」を公開し、Rev.2を置き換えました（NIST, 2025）。
Rev.3の最大の変更点は、インシデント対応をサイバーセキュリティフレームワーク（CSF 2.0）の6つの機能——統治（Govern）、識別（Identify）、防御（Protect）、検知（Detect）、対応（Respond）、復旧（Recover）——に沿って再構成したことです。NISTはその理由を、インシデントが頻発し被害も大きくなった現在、インシデント対応はサイバーセキュリティリスク管理の重要な一部であり、組織の運営全体に統合されるべきものになったからだと説明しています（NIST, 2025）。旧モデルとの対応関係も示されており、「準備」はGovern・Identify・Protectに、「検知と分析」はDetectとIdentifyの改善（Improvement）カテゴリに、「封じ込め・根絶・復旧」はRespond・RecoverとIdentifyの改善に、「事後活動」はIdentifyの改善に対応づけられています（NIST, 2025）。
実務上の含意は二つあります。第一に、「事後活動」が最後の工程ではなくなったことです。旧モデルでは教訓を得る活動はインシデントが終わった後に置かれていましたが、Rev.3では検知・対応・復旧のすべての工程から改善へフィードバックする構造になっています。第二に、対応（Respond）機能が「インシデント管理（RS.MA）」「インシデント分析（RS.AN）」「報告とコミュニケーション（RS.CO）」「緩和（RS.MI）」の4カテゴリに、復旧（Recover）が「復旧計画の実行（RC.RP）」として整理されたことです。たとえばRS.MA-01では検知技術がインシデントを自動的に報告すべきことが推奨され、RS.MA-04では必要に応じたエスカレーションが求められています（NIST, 2025）。次章のランブックは、この区分に沿って組み立てます。
初動ランブック——検知から事後レビューまでの7ステップ
ランブック（runbook）とは、インシデントの種別ごとに「誰が、何を、どの順序で、どの権限で」行うかを定めた実行手順書です。ここでは種別を問わず共通する骨格を7つのステップで示します。各ステップの時間目標は組織のリスク許容度で決めるべきものですが、封じ込めまでを分単位から数時間の単位で完了させることを目指す設計が一般的です。
ステップ1：検知の確度判定（SOC）
アラートを受け取ったSOCは、まず真陽性か誤検知かを見極めます。重複を排除し、資産情報やユーザー属性、脅威インテリジェンスを紐付けて判定するこの工程は、アラートトリアージの自動化で詳しく分解しています。初動の観点で重要なのは、「インシデント宣言」の基準を事前に定めておくことです。「真陽性で、かつ重要資産または特権アカウントが関与している」「複数ホストへの横展開の兆候がある」といった条件を満たしたら宣言してCSIRTを起動する、という取り決めがあれば、担当者が迷う時間をなくせます。宣言の遅れは、それ以降のすべての工程の遅れになります。
ステップ2：影響範囲の特定
宣言と並行して、影響範囲を端末からユーザー、サーバー、データへと広げて確認します。「同じハッシュ値やC2（指令サーバー）通信先が他のホストにもないか」「そのアカウントが同時刻に別拠点からサインインしていないか」「当該端末から共有サーバーやクラウドへのアクセスが増えていないか」を、EDRとSIEMを横断して調べます。NIST SP 800-61 Rev.3はRS.AN-08として、インシデントの規模を見積もり検証することを求め、過小評価を避けるべきだとしています（NIST, 2025）。初動時点の範囲は暫定でよく、封じ込めの進行に合わせて更新し続ける前提で記録します。
ステップ3：封じ込め——端末隔離・アカウント無効化・ネットワーク遮断
封じ込めの基本操作は三つです。第一に端末隔離で、EDRのネットワーク隔離機能を使い、当該端末の通信をEDR管理サーバーとの間だけに制限します。調査に必要な接続を維持しながら横展開を止められるため、初動で最も使われる手段です。第二にアカウント無効化で、侵害が疑われるアカウントの無効化、パスワードリセット、既存セッションやトークンの失効、多要素認証の再登録を行います。特権アカウントが関与している場合は最優先です。第三にネットワーク遮断で、セグメント単位の遮断、判明したC2通信先のブロック、侵入経路と疑われるVPN機器の一時停止などを行います。
NIST SP 800-61 Rev.3はRS.MI-01として「インシデントを封じ込める」ことを求め、封じ込め策の選択にあたっては、インシデントの種別とリスク評価要因を踏まえること、また措置の持続期間——緊急回避策か、暫定的な回避策か、恒久的な解決策か——を考慮することを挙げています（NIST, 2025）。実務では、封じ込めは常に「業務を止めるリスク」と「被害が広がるリスク」のトレードオフです。この判断を毎回ゼロから行わないために、「単一の業務端末の隔離はSOCが即時実行できる」「複数端末やサーバーの隔離、特権アカウントの無効化はCSIRT責任者の承認を要する」「基幹系ネットワークの遮断は情報システム部門長と事業部門長の合意を要する」といった権限のマトリクスを事前に定めます。承認者に連絡がつかない場合に何分で代行者へ切り替えるかまで定めておくことが、夜間・休日の初動を止めないための鍵です。
ステップ4：証拠保全
封じ込めと同時に、後の調査と報告の根拠となる証拠を保全します。警察庁は、ランサムウェア感染時にパソコンやネットワーク機器の電源を落とさないよう注意を促し、ネットワーク機器や端末のログが調査の重要な手がかりになるため日頃から各種ログを取得しておくことを推奨しています（警察庁）。電源を落とすとメモリ上の情報が失われるためで、隔離は「ネットワークから切る」のであって「電源を切る」のではないという原則をランブックに明記します。そのうえで、必要に応じてメモリやディスクのイメージを取得し、EDR・SIEM・認証基盤・VPN・プロキシのログが上書きや保持期限で消えないよう保全します。
NIST SP 800-61 Rev.3は、RS.AN-06として調査中に実施した行為を記録し、記録の完全性と出所を保持すること、RS.AN-07としてインシデントのデータとメタデータを組織の証拠保全手順に沿って収集し、その完全性と出所を保持することを求めています。同文書は、正式な証拠収集や管理の連鎖（chain of custody）の手続きがすべてのインシデントで実施されるとは限らないとしつつ、収集したデータは証拠として扱うべきだとしています（NIST, 2025）。警察への相談や当局報告の段階で「いつ、誰が、何をしたか」を示せるかどうかは、この時点の記録で決まります。
ステップ5：エスカレーションと報告
封じ込めの進行と並行して、社内外への報告を開始します。NIST SP 800-61 Rev.3は、RS.CO-02として確立された手順に沿って内部・外部の関係者にインシデントを通知すること、RS.CO-03として指定された内外の関係者（業界のISACなど情報共有組織を含む）と情報を共有することを求めています（NIST, 2025）。社内の報告先は、経営層、法務、広報、人事、影響を受ける事業部門、取引先を担当する営業部門です。報告はテンプレート化し、発生と検知の時刻、事象の概要、判定の確度、影響範囲（確認済みと未確認の区別）、実施済みの対処、未決事項と次の判断期限を必ず含めます。初動の報告では「まだわからないこと」を正直に書くことが、後の信頼を左右します。外部への報告義務は次章で扱います。
ステップ6：根絶と復旧
封じ込めが完了し、侵入経路と攻撃の全体像が見えてきた段階で、根絶と復旧に移ります。NIST SP 800-61 Rev.3はRS.MI-02として、攻撃者が残した永続化の仕組みや悪用された脆弱性を取り除く「根絶」を求めています。復旧については、RC.RP-03としてバックアップなど復旧に用いる資産の完全性を復元前に検証すること、RC.RP-05として復元した資産の完全性を検証し通常の運用状態を確認すること、RC.RP-06として基準に基づいて復旧の終了を宣言し、事後報告書を含む文書を完成させることが挙げられています（NIST, 2025）。攻撃者が復旧後の環境に再侵入を試みることは珍しくないため、復旧の直後は同じ侵入経路と手口に対する検知を一時的に強化する運用が一般的です。
ステップ7：事後レビュー
NIST SP 800-61 Rev.3は、改善点はインシデントのフォローアップ報告書を作成する際や、復旧が終わりに近づいた段階で「教訓（lessons learned）」の会議を開く際に見つかることが多いとし、特に重大インシデントではそれが重要だとしています（NIST, 2025）。レビューでは、検知、着手、判断、実行のどの工程で時間を要したかを分解し、対策を検知ルール、ランブック、自動化、権限設計のいずれかに反映します。「開催して終わり」を防ぐには改善アクションの完了率を追う必要があり、その指標設計はMTTR・MTTDとは？SOCのKPI設計と改善の実務で整理しています。
日本企業に固有の実務——当局への報告、警察への相談、取引先、夜間・休日
個人情報保護委員会への漏えい等報告と本人への通知
個人情報保護法は、一定の漏えい等が生じた場合に、個人情報保護委員会への報告と本人への通知を求めています。個人情報保護委員会のサイトでは、報告が必要な事態として、要配慮個人情報が含まれる個人データの漏えい等、不正に利用されることにより財産的被害が生じるおそれがある個人データの漏えい等、不正の目的をもって行われたおそれがある個人データの漏えい等、個人データに係る本人の数が1,000人を超える漏えい等の4類型が示され、いずれも「（又はそのおそれ）」が付されています（個人情報保護委員会）。漏えいが確定していなくても、そのおそれがある段階で報告の時計が動き始めるということです。外部からの不正アクセスやランサムウェアによる事案は、一般に「不正の目的をもって行われたおそれ」の類型に該当し、本人の数にかかわらず報告対象になり得ると理解しておくべきです。
報告の期限は二段階です。同サイトは、まず速報を発覚日から3〜5日以内に、次に確報を発覚日から30日以内（不正な目的で行われたおそれがある場合は60日以内）に行うよう案内しています。報告先は原則として個人情報保護委員会ですが、委員会の権限が事業所管大臣に委任されている分野の事業者は委任先の省庁に報告します（個人情報保護委員会）。金融機関のように監督当局への報告が別途求められる業種では、その手順も併せて確認が必要です（金融機関に求められるセキュリティ運用を参照）。本人への通知については、個人情報保護委員会のQ&Aで、口頭による通知の扱いや、通知が困難な場合の代替措置——問合せ窓口を用意して連絡先を公表し、本人が自らの個人データが対象かを確認できるようにすること、事案の公表など——が整理されています（個人情報保護委員会 Q&A）。
ランブックへの落とし込みとしては、ステップ2に「個人データを扱うシステムやファイルサーバーが範囲に含まれるか」の確認項目を置き、含まれる場合はステップ5の時点で法務と個人情報保護の担当部門へ即時に連絡する流れを組み込みます。3〜5日という速報期限は技術調査の完了を待てる長さではないため、「わかっている範囲で速報し、確報で補う」ことを前提に、速報のひな形を平時に用意しておくことが現実的です。
警察への通報・相談
警察庁は「サイバー事案に関する通報等のオンライン受付窓口」を設け、都道府県警察に対する通報、相談（サイバー事案に関するアドバイスを求めるもの）、情報提供をオンラインで受け付けています（警察庁）。ランサムウェアについては、警察庁の報告書が、被害が発覚した際は早期に警察や関係機関へ通報することが求められるとし、警察は被害組織の状況に応じて初動対応に対する助言や復号ツールの提供等の支援を行うことが可能だと述べています（警察庁, 2026）。相談の窓口があることを平時に把握し、誰が連絡するかをランブックに定めておくことで、初動の段階で選択肢として検討できるようになります。
JPCERT/CCと取引先への連絡
JPCERT/CCはインシデント報告を受け付け、インシデントに関係している可能性のあるサイト（アクセス元のネットワーク管理者や、改ざんされたサイトの管理者など）への連絡を行い、状況に応じて海外のNational CSIRTにも連絡する調整機能を担っており、年間約10,000件を取り扱っています（JPCERT/CC）。攻撃元や踏み台が社外にある場合の連絡経路として、平時に窓口を把握しておく価値があります。
取引先への連絡は、日本企業にとって法令報告と同じ重みを持ちます。IPAの「情報セキュリティ10大脅威 2026」では「サプライチェーンや委託先を狙った攻撃」が8年連続で選出され、2026年版の組織向け脅威で2位に入っており（IPA, 2026）、自社のインシデントが取引先への侵入経路になり得ることを前提にしなければなりません。契約上の通知義務の有無と期限、連絡先、連絡すべき情報の範囲を平時に整理し、ステップ5に取引先連絡の判断項目を含めておきます。委託先で発生した漏えいについても委託元の対応が問われ得るため、委託先からの連絡経路も双方向で確認しておくことが望まれます。
夜間・休日の連絡網
手順がすべて整っていても、夜間・休日に承認者へ連絡がつかなければ初動は止まります。連絡網は「順番」だけでなく「タイムアウト」で設計します。第一連絡先が10分応答しなければ第二連絡先へ、CSIRT責任者に30分つかなければ代行者が封じ込めを承認できる、というように、応答がない場合の権限移譲を明文化します。前述の権限マトリクスで「承認なしに実行できる封じ込め」の範囲を広げておくほど、夜間の初動は速くなります。夜間・休日の体制が構造的に回らない理由は「夜間・休日のセキュリティ体制はなぜ回らないのか」で詳しく述べています。
ランサムウェア初動の注意点
警察庁の報告書は、2025年のランサムウェア被害の実態を次のように示しています。被害報告件数は226件で高水準が続き、規模別では前年と同様に中小企業が約6割、業種別では製造業が約4割を占めています。被害組織へのアンケートでは、侵入経路はVPN機器が6割以上を占め、事業継続計画（BCP）を策定済みだった組織は約18%にとどまりました。手口としては、データを窃取したうえで「対価を支払わなければ公開する」と要求する二重恐喝が被害の多くを占め、データを暗号化せずに窃取して公開を予告する手口も発生しています（警察庁, 2026）。これらの事実は、ランサムウェアの初動ランブックに次の注意点を求めます。
隔離を最優先し、電源は落とさない：警察庁は、感染した端末のLANケーブルを抜く、無線をオフにするなどしてネットワークから隔離すること、その際に電源は落とさないことを求めています（警察庁）。暗号化の進行と横展開を止めつつ、メモリ上の証拠を保全するためです。
侵入経路の遮断を封じ込めに含める：侵入経路の6割以上がVPN機器である以上、端末の隔離だけでは不十分です。VPN機器の一時停止や認証情報の一斉リセット、当該機器の脆弱性対応を初動の封じ込めに組み込みます。
二重恐喝を前提に「持ち出し」を確認する：暗号化の阻止だけでなく、外部への大量通信の有無をプロキシやファイアウォールのログで確認し、個人データが持ち出された可能性があれば前章の漏えい等報告の判断を同時に進めます。
バックアップの完全性を復元前に検証する：NIST SP 800-61 Rev.3がRC.RP-03で求めるとおり、バックアップ自体が暗号化・削除・改ざんされていないかを確認してから復元します（NIST, 2025）。
身代金への対応方針を事前に決めておく：警察庁は、身代金の支払いが犯罪グループ等の活動資金となる懸念を指摘し、一部のランサムウェアについては「No More Ransom」プロジェクトのサイトで復号ツールが公開されていることを案内しています（警察庁）。支払いの是非は初動の現場ではなく、経営と法務が平時に方針を定めておくべき事項です。
復旧の優先順位を平時に決めておく：BCPを策定済みの組織が約18%という数字は、多くの組織が「何から復旧するか」を被害後に議論していることを示します。基幹業務の優先順位と代替手段を事前に定めておくことが、復旧期間を左右します。
SOCの一次調査をAIエージェントが担うと、初動はどう変わるか
ここまでの7ステップのうち、ステップ1の確度判定、ステップ2の影響範囲の特定、ステップ4の証拠収集の大部分は、SOCが担う「一次調査」です。この一次調査が終わらなければCSIRTの判断は始まらず、封じ込めも報告も動き出しません。人手のSOCでは、アラートの待ち行列と夜間・休日の要員不足がこの工程を遅らせる構造的な要因になっています。
AIエージェントがSOCの一次調査を担うAI SOCは、この工程に直接働きかけます。ヤグラAI SOCは、一流アナリストの調査手法を再現したAIエージェントがEDR・SIEMのアラートを24時間365日、自律的に調査・対処する自社開発のサービスで、Microsoft Sentinelを含むEDR・SIEM・ID管理製品など100以上のセキュリティ製品と連携し、コンテキストメモリで自社環境を学習して調査精度を高める設計を採っています。初動の観点では、AIがアラートに関連する情報を調査・整理し、CSIRTが確度や影響範囲、証跡、推奨対処を確認する作業を支援します。前述した引き渡しの5点をどこまでそろえられるかは、連携先や取得できる情報によって変わります。調査にかかる時間と人による追加確認の工数を自社環境で測定し、初動の負担軽減につながるかを検証してください。連携したログを横断して同じ侵害指標の有無を確認することは、横展開の兆候を調べるうえでも重要です。
ただし、速さは統制の設計があって初めて価値になります。AIエージェントに何を任せ、何を人間の承認に残すかは、次の観点で明文化する必要があります。
読み取りと変更の分離：ログの照会や証跡の収集といった調査（読み取り）は自律的に行わせ、端末隔離・アカウント無効化・ネットワーク遮断といった変更操作は前述の権限マトリクスに従わせます。単一端末の隔離のように影響が限定的で元に戻せる操作は事前承認のもとで自動実行を許可し、サーバーや特権アカウント、ネットワーク単位の遮断は人間の承認を必須にする段階設計が一般的です。NIST SP 800-61 Rev.3も、封じ込めの一部を自動的に実行する選択肢に触れつつ、その範囲は組織のリスク評価に基づいて決める事項としています（NIST, 2025）。
承認者と承認のSLA：エージェントが承認を求めたとき、誰が何分以内に応答するか、応答がない場合にどう扱うかを、夜間・休日を含めて定めます。
監査証跡：エージェントが発行したクエリ、得た結果、判定の根拠、実行した操作と承認者を一件ごとに記録します。RS.AN-06が求める調査中の行為の記録を、機械の行為にも同様に適用する考え方です。
ロールバック手順：誤って隔離・無効化した場合に、誰がどう解除するかを定めておきます。
責任の所在：インシデントの宣言、封じ込めの最終判断、当局・警察・取引先への報告、身代金に関する判断は、引き続きCSIRTと経営層の責任です。AIエージェントが変えるのは初動の「速さ」であり、「責任」の所在ではありません。
この設計を前提にすれば、AIエージェントは「人が来るまで待つ」時間をなくし、CSIRTが判断に使える時間を増やす存在になります。導入を検討する際は、自社のランブックの権限マトリクスにエージェントの操作範囲を書き込むことから始めると、技術の話が組織の話として整理できます。
まとめ
インシデント対応の成否は、検知した後の最初の1時間に、誰が確度を判定し、誰が封じ込めを承認し、誰が報告するかが決まっているかどうかで大きく左右されます。SOCは「気づいて確かめる」、CSIRTは「決めて動かし、伝える」という分担を明確にし、その境界での引き渡しに必要な5つの情報を定義することが出発点です。NIST SP 800-61 Rev.3は、インシデント対応をCSF 2.0の6機能に沿ってリスク管理全体に統合し、あらゆる工程から改善へフィードバックする構造を示しました。本記事の7ステップは、その区分に沿って確度判定から事後レビューまでを整理したものです。
日本企業では、個人情報保護委員会への速報（発覚から3〜5日以内）と確報、警察への通報・相談、JPCERT/CCや取引先への連絡、夜間・休日の連絡網が、技術的な手順と同じ重さで初動を左右します。ランサムウェアについては、隔離しても電源を落とさない、侵入経路の遮断を封じ込めに含める、二重恐喝を前提に持ち出しを確認する、といった注意点を手順に織り込んでください。SOCの一次調査をAIエージェントが担う体制は、CSIRTへの引き渡しを「アラート」から「調査結果」に変え、初動を分単位に近づけますが、その価値は読み取りと変更の分離、承認者とSLA、監査証跡、ロールバック、責任の所在という統制の設計があって初めて成立します。まずは自社のランブックに、封じ込めの権限マトリクスと夜間・休日の連絡網を書き出すことから始めてみてください。
関連サービス：本記事で述べたSOCの一次調査——確度判定、影響範囲の特定、証跡の収集——を、EDR・SIEMのアラートに対してAIエージェントが24時間365日自律的に調査・対処する形で提供する「ヤグラAI SOC」の詳細はこちら。
参考・出典
NIST「SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile」（2025年4月）: https://csrc.nist.gov/pubs/sp/800/61/r3/final
NIST「SP 800-61 Rev. 3」本文PDF（2025年4月）: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf
個人情報保護委員会「漏えい等の対応とお役立ち資料」（2026年9月閲覧）: https://www.ppc.go.jp/personalinfo/legal/leakAction/
個人情報保護委員会「『個人情報の保護に関する法律についてのガイドライン』に関するQ&A」（2026年9月閲覧）: https://www.ppc.go.jp/personalinfo/faq/APPI_QA/
警察庁「令和７年におけるサイバー空間をめぐる脅威の情勢等について」（2026年3月）: https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf
警察庁「ランサムウェア被害防止対策」（2026年9月閲覧）: https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html
警察庁「サイバー事案に関する相談窓口」（2026年9月閲覧）: https://www.npa.go.jp/bureau/cyber/soudan.html
IPA「情報セキュリティ10大脅威 2026」（2026年1月29日公開）: https://www.ipa.go.jp/security/10threats/10threats2026.html
JPCERT/CC「CSIRTマテリアル」（2026年9月閲覧）: https://www.jpcert.or.jp/csirt_material/
JPCERT/CC「インシデント対応とは」（2026年9月閲覧）: https://www.jpcert.or.jp/ir/
