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

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

対応の速さを、経営の強さに変える

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

フロンティアAIの普及により、攻撃者が脆弱性を発見し、悪用するまでの時間は急速に短くなっています。一方、企業側では、資産や構成情報の把握、対応の優先順位付け、パッチの適用と検証に時間を要し、攻撃と修復の速度の差が経営上のリスクとなりつつあります。

第2回では、修復速度を高めるうえで企業が直面する課題を整理し、エンドポイントの実態を継続的に把握する「動的な管理」を起点に、修復を迅速化する仕組みを考えます。さらに、対応状況を数値で捉えて経営判断につなげる方法や、自動化と人の判断を適切に組み合わせるためのポイントを探ります。

第2回:対応の速さを、経営の強さに変える

―― Autonomous ITで、修復速度を経営の指標に変えられるか ――

フロンティアAIによって脆弱性の発見や悪用が高速化するなか、企業には「何を直すか」だけでなく、「いかに早く直すか」が問われています。しかし、資産・構成情報の把握から対応の優先順位付け、パッチ適用から検証に至るまで、修復の迅速化を阻む課題は多岐にわたります。第2回ではタニウム合同会社の楢原盛史氏を迎え、エンドポイントの実態を継続的に把握する「動的な管理」を起点に、修復を迅速化する仕組みを考えます。(本文敬称略)

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

野見山 雅史と楢原 盛史氏

楢原 盛史/Morifumi Narahara(写真右)
タニウム合同会社 Security Solutions Principal Strategist
国内外の大手IT・セキュリティ企業でセキュリティ営業・コンサルタント・アーキテクトを歴任し、タニウムに入社。エンドポイント、ネットワーク、仮想基盤・クラウドなど幅広い領域のセキュリティに携わり、大規模組織のエンドポイントセキュリティの高度化・最適化を支援。デジタル庁の次世代セキュリティ・アーキテクチャ検討会委員やIPA「情報セキュリティ10大脅威」の選考メンバーも歴任。CISSP(公認情報システムセキュリティ専門家)、CISA(公認情報システム監査人)。

野見山 雅史/Masafumi Nomiyama(写真左)
デロイト トーマツ サイバー合同会社 パートナー
大手システムインテグレーターを経てデロイト トーマツに入社。25年以上にわたりサイバーセキュリティ分野に従事。現在は金融機関や重要インフラを中心に、戦略策定から組織・プロセスの整備、ペネトレーションテスト、フォレンジックまで幅広い支援を手がける。CISSP(公認情報システムセキュリティ専門家)。

第一章  フロンティアAI時代に問われる「修復速度」の重要性

攻撃は分単位、修復は月単位

フロンティアAIの普及により、攻撃者による脆弱性の悪用速度は劇的に短縮しています。一方で企業の修復には依然として数カ月を要するケースもあり、このギャップが新たな経営課題になりつつあります。

企業側の「修復速度」を考えるうえで、象徴的なデータがあります。ある主要ソフトウェアベンダーが公開した重要なセキュリティ修正の件数は、2025年7月は127件だったのに対し、2026年7月には566件へと約4.5倍に増加しました。一方、クラウド セキュリティ アライアンス(以下、CSA)が2026年4月25日に公開した報告書(※)によると、公開された脆弱性情報をもとに、その脆弱性を悪用できるかを検証するPoCコードを作成するまでの時間は、10~15分程度だと報告されています。

※ 「The Collapsing Exploit Window: AI-Speed Vulnerability Weaponization」
https://labs.cloudsecurityalliance.org/research/csa-whitepaper-collapsing-exploit-window-ai-speed-vulnerabil/

これに対し、脆弱性が公開されたソフトウェアを利用する企業側は、配布された修正プログラム(以下、パッチ)を適用するだけで、必ずしも「修復完了」とはなりません。同じCSAの報告書では、複雑なエンタープライズアプリケーションの修復に平均5カ月10日を要すると報告されています。これは修復に時間を要する複雑なアプリケーションを対象とした数字であり、すべての脆弱性に当てはまるものではありません。しかし、脆弱性の増加と攻撃の高速化によって、修復をいかに迅速化するかが極めて重要になっていることは明らかです。

脆弱性対応を阻む6つの壁

では、なぜ企業側の修復にはこれほど時間がかかるのでしょうか。修復を迅速化しようとしても、実務上はいくつもの壁にぶつかります。主な課題は、以下の6つに整理できます。

  1. 資産・構成情報の可視化と一元管理の不足
    現在でも、表計算ソフトを使った手作業に依存する資産・構成情報管理から脱却できていないケースがあります。また、管理主体ごとに情報が分散し、一元化されていないケースも少なくありません。その結果、脆弱性が発見されても修復対象となる資産の特定に時間を要してしまうのです。
  2. 修復の優先順位を判断する基準・プロセス・組織間連携の不足
    脆弱性修復はシステム上のリスクだけでなく、障害が発生した場合の事業影響まで踏まえて優先順位を判断する必要があります。しかし、そのための判断基準やプロセス、関係組織の連携体制を整備している企業は少数です。そのため、どの脆弱性から修復すべきかを迅速に判断することが難しくなっています。
  3. パッチ適用可否判断の基準・プロセスなどの不備
    パッチを適用するには、障害リスクの評価やロールバック手順の検討、変更管理の承認など、さまざまなプロセスを経る必要があります。こうした既存のプロセスでは、現在求められる修復速度に対応できない場合もあります。「BOD 26-04(※)」では、最も高リスクと判断される脆弱性について72時間以内の修復が求められており、従来の進め方の見直しは必須です。

    ※ BOD 26-04:米国CISAが2026年6月に発行した、連邦政府の文民行政機関向けの拘束力のある運用指令。資産の外部公開状況、実際の悪用状況、悪用の自動化可能性、技術的影響などに基づき、脆弱性修復の優先順位を定めることを求めている。
  4. エンドポイントの状態と実行結果の可視性不足
    PCやサーバなどのエンドポイントは、常にオンラインになっているとは限りません。そのため、パッチを適用できる状態にあるのか、実際に適用できたのかを迅速かつ正確に把握することが難しくなります。
  5. 修復作業の分断
    システムや端末によって管理主体が異なり、修復を担う組織も分断されている企業は少なくありません。場合によっては社内だけで完結せず、委託先への作業依頼も必要になります。こうした複数の組織にまたがる修復作業を迅速化・自動化するには、IT管理の統合が不可欠です。
  6. 検証・報告プロセス・仕組みの不備
    パッチを配布しただけでは、修復が完了したとは限りません。対象となるエンドポイントに確実にパッチが適用され、一連の修復が完了したことを正確に検証し、その結果を報告できる仕組みの構築が急務です。

短期で守り、中長期で強くする

こうした課題を解消し、修復速度を高めるには、資産・構成情報を継続的かつ一元的に管理し、リスクベースで優先順位を定めたうえで、パッチの適用可否の判断から実行、検証まで、一連のプロセスと実施体制を高度化・自動化する必要があります。

また、脅威インテリジェンスを活用した判断の高度化や、KPIによる継続的な改善も重要です。さらに、すぐにパッチを適用できない場合に備え、セグメンテーションやハードニングなどによってリスクを低減し、修復までの時間を稼ぐ対策も必要になります。

ただし、こうした取り組みを実現するのは容易ではなく、相応の時間もかかります。だからといって、必要な体制や仕組みが整うまで、目の前の脆弱性への対応を待つことはできません。重要なのは、短期的な対応と中長期的な対応を分けて進めることです。

脆弱性対応は、足元の対策強化と中長期の高度化を並行して進めるべき。

短期的な取り組みでは、現在の資産・構成情報の管理や脆弱性対応を棚卸しし、大きな抜け漏れがないかを確認します。例えば、「脆弱性対応の対象外になっているシステムはないか」「委託先との契約は迅速な修復に対応できる内容になっているか」といった点です。

そのうえで、優先的に対応すべきシステムを特定し、脆弱性やパッチのトリアージ基準を見直します。月次などの周期的な対応から、必要な時に随時対応できるよう、運用体制を変更します。もちろん、そのためのプロセスとリソースの確保も必須です。

ただし、短期対応は人手に依存しやすく、持続には限界があります。そのため、中長期的な取り組みではフロンティアAI時代のマシンスピードに対応できるよう、既存の組織やプロセス、現在導入しているテクノロジーを構造的に見直し、高度化していく必要があります。

具体的にはAIを活用して検知・分析・対応を自動化するとともに、ゼロトラストアーキテクチャや統合プラットフォームを導入し、分断された管理を一元化します。さらに、こうした仕組みを運用する組織や人材を整備し、その効果をKPIで継続的に検証します。

では、こうした一連の管理と修復を高速化するには、具体的にどのようなアプローチが必要なのでしょうか。次章ではタニウムで顧客との議論や実環境での検証を通じて蓄積されたデータや知見をもとに、フロンティアAI時代に求められるエンドポイント管理の高度化について解説します。

第二章 経営判断を支える「動的なエンドポイント管理」

CXOが求めるのはIT環境の「正確な現実」

タニウムは、PCやサーバなどのエンドポイントを対象に、その状態をリアルタイムかつ網羅的に把握・管理するためのソリューションを提供しています。特に、大規模で分散したIT環境におけるエンドポイント管理に取り組んでいます。

お客様との議論を通じて感じるのは、「エンドポイント管理は非常に難易度の高い領域である」ことです。しかも、エンドポイントの状態を正確に把握することは、現場のシステム運用だけの問題ではありません。CXO(経営層)がそれぞれの責務を果たすうえでも、重要な前提となります。では、各CXOの視点から、エンドポイント管理がなぜ重要なのかを見ていきましょう。

まず、CEO(最高経営責任者)は、外部でインシデントが報じられたり、自社で何かが起きたりした際に、「自社は大丈夫なのか」「事業を継続できるのか」を迅速に把握し、説明責任を果たす必要があります。CIO(最高情報責任者)は、現在のIT投資が有効に機能しているのか、その投資対効果を数値で示すことが求められます。

また、CISO(最高情報セキュリティ責任者)は、組織内にどのような脆弱性やセキュリティリスクが存在するのかを、漏れなく正確に把握しなければなりません。さらにCRO(最高リスク責任者)には、組織が定めたポリシーを順守できているかを確認するとともに、全社のリスクを定量化することが求められます。

CXOが迅速かつ適切に意思決定を下すため、ITチームには、侵害の有無や影響範囲、ライセンスの利用状況、脆弱性、ポリシー違反、セキュリティ設定など、経営判断の根拠となる情報を正確に把握し、提供することが求められます。

しかし実際には、こうした情報を網羅的かつリアルタイムに把握することは容易ではありません。

その要因の一つが、エンドポイントの分散です。オンプレミスのパソコンやサーバだけでなく、在宅勤務や外出先で利用されるパソコン、クラウド上で稼働するサーバなど、エンドポイントはさまざまな環境に分散しており、管理の網羅性を確保することが難しくなっています。仮にこうしたエンドポイントを把握できたとしても、代表的な管理ツールでは、情報取得のクエリを発行してから収集が完了するまでに8時間程度かかる場合もあります。

また、M&Aなどを重ねて組織が大規模・複雑になるほどエンドポイントを管理するツールも増え、運用組織も縦割りになりがちです。その結果、ツールや運用のサイロ化が進み、全社的なガードレールを定めても、システムが適正な状態にあるかを共通の基準で評価することが難しくなります。こうした状況ではIT投資のROI(投資対効果)やTCO(総保有コスト)を全社横断で把握できません。

「管理しているつもり」が生む、台帳と実態の乖離

エンドポイントの実態を正確に把握するには、動的な管理が必要です。

これまで多くの組織では、資産台帳などを使った静的な管理が中心でした。しかし、ある時点の情報を記録した台帳だけでは、刻々と変化するエンドポイントの実態を捉えきれません。台帳と実態にどのような乖離が生じるのか、ある組織の調査結果を紹介します。

タニウムでグローバル組織の実環境を確認したところ、本来把握すべき端末のうち、約13%が管理外となっていたという調査結果を確認しております。さらに、管理対象となっている端末でも、セキュリティツールの未稼働やポリシー違反、未許可のLLMの存在など、さまざまな問題が確認されました。脆弱性管理の面でも課題があり、調査対象全体では253台中192台、約76%が高リスク脆弱性を抱える端末と判定されました。

こうした脆弱性が悪用されれば、特権IDの奪取や、組織のID・認証基盤全体の侵害につながるおそれがあります。さらに、動的なエンドポイント管理の対象は、本社だけではありません。CXOの責任範囲を考えれば、国内外の拠点や、連結子会社・持分法適用会社を含むグループ会社、クラウド、リモートワーク環境まで含めて捉える必要があります。

広範な環境に存在し、刻々と状態が変化するエンドポイントを、台帳だけで管理するのは現実的ではありません。エンドポイントの最新状態を漏れなく把握し、継続的に管理する「動的なエンドポイント管理」が必要になるのは、このためです。

「把握する、直す、測り続ける」――動的管理の3ステップ

動的なエンドポイント管理は、大きく3つのステップで捉えることができます。

  1. 資産・構成情報の把握
    管理外の端末も含め、エンドポイントの最新状態を継続的に把握します。
  2. 脆弱性の是正
    把握した資産に存在する脆弱性を可視化・識別し、優先順位を付けて是正します。
  3. 継続的な管理
    資産の把握状況や脆弱性への対応状況をKPIなどで測定し、継続的な改善につなげます。この「把握する→直す→測り続ける」というサイクルを回すことで、エンドポイントの状態を継続的に管理できるようになります。ただし、広範なエンドポイントを対象に、このサイクルを人手だけで回し続けることは容易ではありません。そこで重要になるのが、自動化です。

第三章 データが導く、経営と現場の対話

経営と現場をつなぐのは「数字」、自動化を支えるのは「人間の判断」

野見山:ここからは、これまでの議論を踏まえ、修復速度を高めるために企業が何を考えるべきか、楢原さんに伺います。

経営者の視点で考えれば、脆弱性の早期修復は必須事項ですが、そのためには現場には相応の負荷がかかり、投資も必要になります。この現状を経営層に理解してもらうのは、決して容易ではありません。こうした認識差を埋めるために、どのようなアプローチが必要でしょうか。

楢原:いちばん“効く”のは、自社のセキュリティ状況を徹底的にデータ化・数値化して示すことです。例えば、「パッチ適用は75%まで完了しており、残る25%も3日以内に対応する」と示せれば、現在地と対応の見通しを経営層と共有できます。定性的に「対応を進めています」と説明するのではなく、現状の残存リスクがどの程度あり、改善の進捗状況はどうなっているのかを数字で示す。そうすることで、経営と現場が同じ尺度で状況を判断できるようになるのです。

野見山:次に、自動化と人間による判断の使い分けについて伺います。近年、お客様から「パッチ適用を自動化して大丈夫か」と相談される機会が増えています。マシンスピードに対応するには自動化が欠かせない一方、パッチ適用には障害リスクがあります。どこまでを自動化し、どの段階で人間が判断すべきだとお考えでしょうか。

楢原:お客様の懸念はもっともで、何でも自動化すればよいわけではありません。日本の大手組織では、パッチのリリース後、業務システムなどに不具合が生じないかを確認し、問題がないことを確かめながら段階的に適用範囲を広げるケースが一般的です。その分、安全性を確認するための時間と手間がかかります。

だからこそ、自動化と人による判断を適切に組み合わせることが重要なのです。定型的な処理は自動化しつつ、影響が大きい判断やアクションは「Human-in-the-loop」の考え方に基づいて管理者が判断する必要があります。

また、パッチ適用後に不具合が生じた場合には、速やかにロールバックできる仕組みも欠かせません。さらに、パッチ適用の成功率などのデータを活用し、何をもって安全と判断するのか、その基準を数値化し、あらかじめ明確にしておくことが、自動化を進めるうえで重要です。

最初の一歩は、自社の「リアリティ」を知ること

野見山:最後に、ネクストアクションについて伺います。企業によって現在地や成熟度は異なりますが、何から始めるべきだとお考えでしょうか。

楢原:まずは、自社の実環境の「リアリティ」を把握することです。実現したいことがある程度明確になっていても、その前提となる現状を正確に把握できていなければ、適切なアクションを決めることはできません。実環境から得られる正確なデータをもとに、「何が起きているのか」「どこに課題があるのか」を確認する必要があります。

人間ドックで検査データを見て初めて、どこを治療すべきか判断できるのと同じです。現状を定量的に把握し、課題を特定したうえで優先順位を付けて次のアクションを考える。そこから始めることが重要だと考えています。

野見山:ありがとうございます。出発点となるのは、自社の今の実態を正確に把握することですね。修復の迅速化も、まずはそこから始まるのだと思います。楢原さん、本日はありがとうございました。