メインコンテンツに移動する
デロイトへようこそ

もし想定していない内容が表示されている場合は、上記で変更してください。

検知の速さを、経営判断の速さにつなげる

シリーズ:フロンティアAI時代のサイバー経営 第3回

サイバーインシデントが発生したとき、経営に求められるのは、全容が見えるまで待つことではなく、限られた情報をもとに判断を重ねていくことです。検知の高速化や初動対応の迅速化が進むほど、経営への報告、公表・開示、事業継続に関する意思決定までに要する時間は短くなります。

第3回では、検知した情報を迅速な経営判断につなげるために、企業が平時から整えておくべき仕組みを考えます。エスカレーション基準、部門を横断した情報集約、不確実な状況でも判断を止めない報告のあり方、AIと人の役割分担を通じて、経営が迅速かつ説明可能な判断を行うための具体的な備えを探ります。

第3回:検知の速さを、経営判断の速さにつなげる

―― 検知の高速化を、経営判断と公表・開示にどうつなぐか ――

AIの進化によって、サイバー攻撃の検知やトリアージ、初動対応はマシンスピードに近づきつつあります。しかし、検知が速くなっても、経営判断や公表・開示まで速くなるわけではありません。むしろ検知が速くなるほど「いつ把握し、いつ判断し、どのように対応したのか」がこれまで以上に問われます。第3回では、Splunk Services Japanの仲間力氏を迎え、デロイト トーマツでサイバーインテリジェンスセンター長を務める佐藤功陛とともに、検知の速さを経営判断の速さにつなげるため、企業が平時から備えるべき仕組みを考えます。(本文敬称略)

※ 本稿は2026年8月20日開催のWebinar「対応の速さを、経営の強さに変える」の内容をもとに、再構成したものです。 

佐藤 功陛と仲間 力氏

仲間 力/Chikara Nakama(写真右)
Splunk Services Japan合同会社
National Security Director/国家安全保障事業本部長
陸上自衛隊、内閣サイバーセキュリティセンター(NISC)、総務省で、IT・サイバーセキュリティに関する戦略・計画、システム開発、人材育成などに従事。その後、Cisco Japanの最高セキュリティ責任者として、製品・サービス・サプライチェーンと安全保障の整合を図る業務を担当し、Splunkに入社。現在はデータの分析・利活用を通じて、政府・重要インフラを含む組織のサイバーセキュリティ高度化を支援している。

佐藤 功陛/Kohei Sato(写真左)
執行役員/サイバーインテリジェンスセンター長
外資系SIerでセキュリティオペレーションセンター(SOC)のセンター長を務めた後、2015年にデロイト トーマツ リスクサービス(現 合同会社デロイト トーマツ)に入社。2016年には、セキュリティ監視と脅威インテリジェンス分析を24時間体制で提供するサイバーインテリジェンスセンター(CIC)を設立し、責任者を務める。現在は、クラウドやWebアプリケーションの監視、重要インフラ企業への脅威インテリジェンス提供、SOC構築支援などを手がける。

検知・対応の高速化に伴い、経営判断や対外説明に使える時間も短くなっています。しかし、インシデントが起きてから判断の仕方を考えていたのでは間に合いません。マシンスピードの検知を経営判断と対外説明につなげるために、企業は何を平時から設計しておくべきでしょうか。今回の議論の出発点となるのが、次の三つの問いです。

企業は、悪い知らせは、すぐ上がってくるか、誰が、いつ、公表を決めるか、全容がわかる前に、何を語るかを平時から設計しておくべきである。

この中でも「悪い知らせは、すぐ上がってくるか」は、危機対応の根本に関わる問いです。危機対応の世界には、古くから「Bad News First」という言葉があります。良い知らせは後でよい、まず悪い知らせを上げることが重要になります。

検知だけが高速化しても、エスカレーションや公表・開示の判断、対外説明の基準が曖昧なままでは、経営判断は速くなりません。全容の解明を待っていては間に合わない場面が増える今、こうした判断の仕組みを平時から設計しておく必要があります。

第一章ではSplunkの知見をもとに、検知の高速化を経営判断や報告の迅速化につなげるための具体策について解説します。

第一章  検知の高速化を、経営判断と公表・開示にどうつなぐか

迅速な経営判断を支える、平時の準備と合意形成

本章で解説するポイントは、以下の三つです。

  • 判断の迅速化
  • 平時からの準備
  • ダッシュボードを活用した合意形成

判断の迅速化

前述のとおり、検知自体は高速化しています。例えばSplunkでは「Volt Typhoon(※)」に関する攻撃レポートが公開された際、翌日には対応する検知の仕組みを提供しました。

※ Volt Typhoon:特定国家の支援を受けるとされるサイバー攻撃グループ。米国の重要インフラなどを標的とした活動で知られる。

しかし、検知しただけでは報告には至りません。その後、調査・トリアージを行い、「認知」を経て、速報、詳報へと進む必要があります。2026年10月には、「サイバー対処能力強化法(※)」の官民連携に関する規定が施行されました。対象となる基幹インフラ事業者には、一定のサイバーインシデントなどを認知した場合、政府への報告が求められます。

※ サイバー対処能力強化法:基幹インフラなどへのサイバー攻撃に対する官民連携や情報共有、対処能力の強化を目的とする法律。

この「報告」で重要なのが「いつ認知したか」です。アラートが鳴った時点が認知になるわけではなく、内容を調査し、「報告対象に当たる」と合理的に判断できた段階が「認知」となります。企業は「誰が技術的な事実を確認し、誰が報告対象に当たるかを判断するのか」という基準と役割分担を、平時から定めておく必要があります。

次に報告の期限です。「速報」は認知後速やかに、「詳報」は認知日から30日以内が基本とされています。ランサムウェア被害などの場合は、認知日から3日から5日以内という、より短い目安も示されています。対象となる範囲も広く、攻撃が成功していなくても一定の重要な機器への攻撃であれば、報告対象になり得ます。是正命令に従わない場合には、200万円以下の罰金も定められています。

こうした報告要件に対応するには、平時からの準備が欠かせません。資産管理を徹底し、対象となる機器や構成を把握して、インシデント発生時に報告対象を迅速に特定できるようにしておくことが重要です。


平時からの準備

平時からの準備で鍵になるのが、脅威インテリジェンスの活用です。サイバー対処能力強化法に基づいて新たに設けられた協議会を通じ、政府からIoC(※)などが提供されていますが、受け取るだけでは十分ではありません。IoCを自社のログと突合し、実際に攻撃を受けているのかを判断できる体制が必要です。政府もログや監視体制が十分でなく、IoCやTTP(※)情報を調査できない企業があることを課題として挙げています。

※ IoC(Indicator of Compromise): 攻撃の痕跡を示す情報
※ TTP(Tactics, Techniques, and Procedures): 攻撃者の戦術・技術・手順

また、報告内容の事前調整も重要です。インシデント発生後に「何を報告するのか」「誰が判断するのか」「どこまで情報を出すのか」を議論するようでは、迅速な報告はできません。


ダッシュボードを活用した合意形成

平時の事前調整を具体化する手段の一つが、ダッシュボードの活用です。ここで気をつけたいのは、ダッシュボードの作成自体を目的にしないことです。どの段階で「認知」と判断するのか、誰がエスカレーションを判断するのか、何を速報で伝え、どの情報を詳報の段階で報告するのか。こうした基準を、作成過程で関係部門がすり合わせることに意味があります。

SOC(Security Operation Centers)とIT部門は取得できる情報や管理対象を確認し、法務・広報は報告や開示のタイミングと内容を整理します。経営層とは「どの事象をいつ報告し、誰が判断するのか」を共有します。つまり、ダッシュボードを作る過程そのものが部門横断の合意形成となり、検知した情報を迅速な経営判断と報告につなげる基盤になるのです。

自動化を進めても、最終判断は人が担う

一方で、自社の資産状況や外部公開システムを人手で継続的に把握するには限界があります。同様に、判断に必要な情報の収集や分析も、人手だけでは追いつきません。そこで重要になるのが、資産把握やSOC業務の自動化です。Splunkでは、資産把握の一部を自動化するとともに、「Agentic SOC」によってトリアージや分析などのSOC業務をAIで自動化し、判断に必要な情報を迅速に整理できるようにしています。

ただし、すべてをAIに任せるわけではありません。AIは判断に必要な情報を収集し、整理するところまでを担い、最終的な判断や重要な対応の承認は人が行います。検知の速さを経営判断の速さにつなげるには、「Human-in-the-loop」のアプローチが重要です。これを実際に機能させるには、「誰が何を承認するのか」を平時から決めておく必要があります。

第二章  検知の速さに、経営はどう追いつくか

検知・対応の高速化で、経営判断に使える時間は短くなる

第2章ではデロイト トーマツから「その速さに経営がどう追いつくか」という視点で、平時に決めておくべき判断基準と体制を整理します。

まず押さえておきたいのは、二つの変化です。

一つは「技術の変化」です。先述したとおり、AIの進化によって検知、トリアージ、初動対応はマシンスピードに近づいています。

もう一つは「制度・要請の変化」です。脆弱性の外部露出や悪用状況、技術的影響など、リスクに応じて対応期限を定める動きが進んでいます。例えば、米国の連邦政府機関を対象としたCISA(米国サイバーセキュリティ・インフラセキュリティ庁)の指令「CISA BOD 26-04(※)」では、最もリスクの高い脆弱性について3日以内の対応を求めています。日本企業に一律適用される期限ではありませんが、対応や判断に使える時間が短くなっていることを象徴する動きです。

※ CISA BOD 26-04:米国の連邦政府機関を対象に、脆弱性の外部露出、実際の悪用、自動化可能性、技術的影響などに基づいて対応期限を定める指令。

では、実際に対応期限が3日しかないときを想定してください。経営層は当局や顧客、市場から何を問われ、どこまで説明できるでしょうか。

興味深い調査があります。デロイトが実施したグローバル調査(※)では、85%が自社のサイバー戦略に自信を持つ一方、各種のサイバー施策を「大きく」または「非常に大きく」実施している割合は平均70%でした。さらに、サイバーを法務部門の日々の計画や意思決定に完全に組み込み、共通KPIを設けている組織は27%にとどまります。

※ Deloitte Global Future of Cyber Survey, 5th Edition(2026)/世界43カ国、1,058名の経営・技術リーダーを対象に、2025年後期に実施

この数字からも、サイバー戦略への自信と、それを日々の意思決定に組み込むことは別だと分かります。検知の速さを経営の速さに変えるには、何を基準に判断し、関係部門がどう連携するのかを仕組みとして実装する必要があります。

経営判断を速めるために、平時から備える三つの設計

では、その仕組みを具体的にどう設計すればよいのでしょうか。ポイントは大きく三つあります。

一つ目は「経営へのエスカレーション基準」です。CVSSスコア(※)やアラート件数だけを基準にすると重要な事案が埋もれ、技術調査の完了を待てば経営判断が遅れます。基準にすべきは「経営判断が必要になり得るか」です。具体的には公表・開示や規制当への報告、事業・サービス停止の判断、顧客・市場への影響など、経営判断が必要になり得る事象が生じた時点で経営層へエスカレーションします。こうした基準は現場任せにせず、経営層が平時から関与して決めておくことが重要です。これが「Bad News First」を実務に落とし込むための基本です。

※ CVSSスコア(Common Vulnerability Scoring System):ソフトウェアやシステムが持つセキュリティ脆弱性の深刻度を0.0から10.0までの数値で表す国際的な指標。

二つ目は「不確実な状況でも判断を止めない仕組み」です。

インシデントの全容が判明してから判断・報告しようとすれば、対応が遅れます。かといって、分からないことを分かったものとして扱うこともできません。そこで、第一報・中間報・最終報という三段階で、分かっていることと分からないことを明示しながら、判断を更新していきます。ここでいう第一報・中間報・最終報は、社内で判断を段階的に更新するための型です。

個人情報保護法に基づく漏えいなどの報告も、全容が判明してから一度だけ報告する仕組みではありません。発覚から3日から5日以内の速報と、原則30日以内(不正目的のおそれがある場合は60日以内)の確報が求められており、確報の時点でも不明な点が残れば、その時点で把握している内容を報告し、判明後に追加する必要があります。最初から完璧な答えを出そうとせず、不確実性を明示しながら判断を更新し、その経緯と根拠を残すことが重要です。

三つ目は「判断を社外への報告、通知、開示につなげる体制」です。二重恐喝ランサムウェアでは、企業の準備が整う前に攻撃者が情報を公開することもあり、公表の主導権を企業が握れるとは限りません。

こうした状況では、技術的な調査と並行して、当局への報告、適時開示、本人・顧客への通知など、複数の対外対応を検討する必要があります。これらは法務、広報、事業部門、セキュリティ、監査などの関係部門が、インシデントの初期段階から連携して動かなければ実現できません。

AI活用では「実行」と「説明」の両方を統制する

さらに、AIを活用するうえでは、「実行」と「説明」の両方を統制する必要があります。事業停止やアクセス遮断など影響の大きい対応は人が承認し、誰が何を判断し、どのような行動を取ったのかを後から確認できる状態にしておかなければなりません。同時に、検知から対応までの経緯を、当局や監査、顧客、市場にも説明できる必要があります。

インシデント調査にAIを利用するケースは増えていますが、AIが参照するデータにも、欠落や信頼性の問題が生じる可能性があります。デロイト トーマツの技術検証では、EDRが参照するテレメトリーが妨害され、調査が困難になる手法も確認しています。AIを利用する際には、その結論を盲信するのではなく、「何を根拠に、どこまで信頼できるデータで判断したのか」まで確認し、説明できるようにしておく必要があります。

そのために残すべきなのが、「根拠」「時系列」「記録」です。

AI活用では、実行と説明を統制し、なぜその判断、対応に至ったのかという根拠、いつ検知、判断、対応したかという時系列、承認を含む経緯が後から再構成できる記録を残すことが重要。

つまり、どのデータを基に、いつ検知・報告し、誰が判断・承認して何を実行したのかを、後から再構成できる状態にしておく必要があります。AIを活用することと、AIに説明責任まで委ねることは同じではありません。AIによる検知・対応を活用するには、実行と説明の両方を統制することが重要なのです。

第三章 経営判断を阻むボトルネックと、AI活用について

経営判断を遅らせる、情報精査と部門間の分断

佐藤:では、これまでの説明を踏まえ、こうした設計を現場で機能させる際に留意すべき点を掘り下げていきます。

AIによって検知や初動対応が高速化しても、経営判断まで同じ速さで進むとは限りません。仲間さんからご覧になって、検知から経営判断までのプロセスで、どこがボトルネックになりやすいでしょうか。

仲間:検知はすでに機械化が進んでいるため、そこは大きな問題にはならないと思います。むしろボトルネックになりやすいのは、誤検知を見極め、情報の正確性を確認し、それを経営層に届けるプロセスです。

佐藤:情報の精査に加えて、経営に上げる基準や招集する範囲、決定権限、部門間の役割が曖昧なことも、判断を遅らせる要因になると思います。この点はいかがでしょうか。

仲間:ご指摘のとおりです。

もう一つのボトルネックが、部門をまたぐ情報の集約です。組織全体では必要な情報を持っていても、それが各部門に分散していて、必要なときに集められないことがあります。「平時から情報を集約する仕組みが重要だ」というのは、佐藤さんも私もこれまで繰り返し力説してきましたが、その実践として、例えば国への報告項目に沿ってダッシュボードを設計すれば、収集すべき情報が明確になります。作成の過程で、どの部門からどの情報を集めるのかをあらかじめすり合わせておく。ダッシュボードづくりそのものを、組織間調整の機会として活用するのが有効だと思います。

AIに任せる領域と、人が担うべき判断

佐藤:次に、AIと人の役割分担について伺います。Agentic SOCでは、検知・分析・対応の自動化が進んでいます。こうした中で、どこまでをAIに任せ、どのような判断を人が担うべきだとお考えでしょうか。

仲間:情報を収集し、判断できる状態まで整理するところは、AIや自動化に任せられると思います。ただし、最終的な判断まで任せるには慎重さが必要です。

例えば金融機関では、パッチ適用をどこまで自動化できるかという議論がよくあります。パッチ適用そのものを自動化できても、その後にアプリケーションがどう動くかまでは保証できません。業務への影響が大きい場合、人の判断を介さず自動的に適用するのはリスクがあります。

そのため、情報収集や分析、判断材料の整理はAIで高速化し、最終的な判断は人が担う。まずはそうした役割分担から、段階的に自動化を進めていくことが重要だと思います。

佐藤:少し視点を変えます。7月31日に国家サイバー統括室(NCO)が「脅威ハンティングの普及促進・実施等に係る基本方針」を公表し、能動的な脅威探索の重要性を示しています。SIEMやEDR、XDRも挙げられており、Splunkの技術を活用できる領域だと思います。実際に脅威ハンティングを実践するうえでは、技術面・人材面にどのような課題があるのでしょうか。

仲間:脅威ハンティングはSplunkが以前から得意としてきた領域です。ログを収集し、仮説を立てて分析することで、従来の検知では捉えられなかった攻撃を探し出すことができます。

ただ、課題は技術よりも人材です。脅威ハンティングを実践するには、ログから仮説を立て、分析できる高度なスキルが求められます。Splunkにはそれを支える機能がありますが、企業からは「(Splunkのような)技術基盤はあっても、脅威ハンティングを実践できる人材が社内にいない」という声をよく聞きます。

佐藤:そこは重要なポイントですね。デロイト トーマツでも、重要インフラ企業などを対象に脅威ハンティングの実施や支援を手がけています。技術基盤だけでなく、それを運用できる人材や体制まで含めて整えることが重要だと考えています。

最初の30日・90日で、何から着手するか

佐藤:では最後に、ここまでの議論を実際の取り組みに落とし込むには、何から始めるべきか伺います。最初の30日・90日という時間軸で考えた場合、それぞれ何を進めるべきでしょうか。

仲間:組織の状況によりますが、最初の30日で取り組むべきは資産管理だと考えています。表計算ソフトなどで管理している情報も含め、できるだけリアルタイムに資産を把握し、事実に基づいて経営が判断できる基盤を整えることが重要です。管理できていないPCやソフトウェアには、そもそも適切にパッチを適用できません。まず資産を正確に把握することが出発点になります。

90日では、その情報を基に自動化を進めていきます。具体的には、脆弱性のリスクを評価してパッチ適用の優先順位を決めたり、パッチを適用できない資産については監視・検知を強化したりします。さらに、こうした作業の自動化に向けて、Agentic SOCの活用も検討していきます。

佐藤:90日でAgentic SOCまで導入するのは簡単ではないと思いますが、検討を始めること自体に意味がありますね。デロイト トーマツの立場から、経営・組織面での30日・90日についても補足させてください。

最初の30日では、どの事案を経営に上げるのかという基準に加え、関係するステークホルダー、決定権限、代行順位まで明確にしておくことが重要です。一方、90日では、経営層を交えたマーダーボード演習(※)に進みます。経営層を含む演習は日程調整もあるため、必ずしも90日以内に実施できるとは限りません。重要なのは90日という期限そのものではなく、実践的な演習を行い、実際に仕組みが機能するかを確認することです。デロイト トーマツでも、こうした経営層を含む演習を支援しています。

※ マーダーボード演習:サイバーインシデントの発生を想定し、経営層や関係部門が第一報から判断の更新、公表・開示までを模擬し、意思決定や連携上の課題を検証する演習。

仲間:演習は非常に重要だと思います。実際に動かしてみることで、「ここがうまく機能しない」「この情報が足りない」といった課題が具体的に見えてきます。机上で「ここを変えた方がいい」と言われるだけでは、なかなか組織は動きません。しかし、演習を通じて課題を実感できれば、「本当に変えなければならない」という共通認識が生まれます。そこで明らかになった課題を手順の見直しだけで終わらせず、必要であれば組織体制の変更にまでつなげていくことが大切だと思います。

佐藤:おっしゃる通りですね。技術や仕組みを整えるだけでなく、実際に動かして課題を見つけ、改善につなげるところまでが重要だと思います。本日はありがとうございました。