見つける力より、直す力が問われる時代へ

企業の競争力を高めるフロンティアAIは、同時にサイバーセキュリティ対策の前提そのものを変えつつあります。高度な専門知識を持たない攻撃者でもマシンスピードで脆弱性を発見するともに、その脆弱性を悪用する攻撃コードを開発することで、高速かつ容易にサイバー攻撃を仕掛けられるようになります。さらに、AIエージェントが業務やシステムに深く入り込むことで、企業が守るべき対象や管理すべき権限も拡大します。

本連載では、デロイト トーマツのサイバーセキュリティ専門家と、各領域のテクノロジー企業の実務家が、フロンティアAIによって変わる脅威と対策のあり方を多角的に検討します。脆弱性対応の優先順位付けから修復速度の向上、Human-in-the-loopによる統制、検知から経営判断への接続、AIエージェントのアクセス管理、非人間IDのガバナンスまで、企業が備えるべき論点と具体的なアクションを全6回で探ります。

―― 「直すべきリスク」の優先順位を、経営はどう決めるか ――

フロンティアAIの台頭で、脆弱性が発見されてから悪用されるまでの時間は、かつての数週間～数か月単位から時間単位へと圧縮されました。このため「攻撃を受けてはならない重要資産は何か」を予め見極めた上で、続々と発見される脆弱性について「何を、いつまでに対策するか」を迅速に判断・実行することがこれまで以上のスピードで求められます。第1回では、クラウドストライク合同会社の藤岡正浩氏を迎え、限られた人員と時間を、真に危険なリスクへの対応に振り向けるための優先順位付けと、フロンティアAI時代に求められる脆弱性管理のあり方を考えます。（本文敬称略）

※　本稿は2026年7月23日開催の主催Webinar「見つける力より、直す力が問われる時代へ」の内容をもとに、再構成したものです。

藤岡 正浩／Masahiro Fujioka（写真右）
クラウドストライク合同会社　Horizon営業本部　本部長
中小ソフトウェアハウス、外資系ハードウェアメーカー、外資系セキュリティサービスベンダーを経てクラウドストライクに入社。CrowdStrike Falcon® Complete managed detection and response (MDR)の営業責任者として参画後、プロフェッショナルサービスやアイデンティティ製品の責任者を兼務。現在はMDR、プロフェッショナルサービス、ITDR、SIEM、クラウド、AIDRなど同社のHorizonビジネスを統括する。

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

第一章 　企業が直面する最大の変化とは

フロンティアAIが変える、脆弱性対応の前提

第一章では、フロンティアAIの台頭によってサイバーリスクがどのように変化しているのか、また企業にはどのような対応が求められるのかについて、デロイト トーマツが整理した主要な論点を俯瞰的に紹介します。

2026年春に生成AI企業が新たなAIモデルを発表しました。このモデルは、高度なセキュリティエンジニアの関与がなくても多数のゼロデイ脆弱性を発見できる能力を有するもので、そのリスクを指摘する声が多数上がりました。その結果、当該企業は新たなAIモデルの提供を停止し、主要なIT企業等と共同でチームを組成し、ソフトウェアの脆弱性発見と修正に取り組んでいます。

こうしたリスクは、この新たなAIモデルに限りません。フロンティアAIと呼ばれる他の高機能AIモデルにも同様のリスクがあると指摘されています。

フロンティアAIの台頭によるセキュリティリスクの変化は、次の3つに大別できます。

1. 脆弱性の発見量と発見速度の増大
   専門家の関与がなくても、多数のゼロデイ脆弱性を短期間で発見できる。
2. 攻撃の容易化
   従来は脆弱性の発見からエクスプロイトコードの開発までに一定の時間を要したが、フロンティアAIによってコード生成が高速化し、脆弱性が悪用されるまでの猶予は大幅に短縮された。
3. 修復期間のギャップ
   脆弱性の公表やパッチの提供後、数日から数週間かけて対応する従来の前提が崩壊した。企業は脆弱性管理やパッチ管理のプロセスを見直し、より迅速に優先順位を判断して修正できる体制を構築する必要に迫られている。

こうしたセキュリティリスクの変化に対し、デロイト トーマツでは対応の枠組みを「ピープル」「プロセス」「テクノロジー」の3つの観点から整理しています。

ピープル……セキュリティチームには迅速な判断力が求められます。脆弱性への対応を検討する猶予が縮まるなか、技術的な深刻度だけでなく、事業への影響も踏まえて優先順位を判断する能力が必要です。

プロセス……これまでの四半期ごと等の周期的なパッチ適用から、継続的かつ迅速な対応への転換が必須です。そのためには、意思決定やエスカレーションを含む一連の手順を見直さなければなりません。

テクノロジー……脆弱性スキャナー、CMDB（構成管理データベース）、パッチ管理など、これまで個別に導入され、分断されてしまった仕組みを連携させる必要があります。脆弱性の発見から資産の特定、優先順位付け、修正までの一連の流れをひとつながりに連携させる（オーケストレーションする）ことで、対応を一元的に管理し、高速化することが求められます。
 

ただし留意したいのは、「フロンティアAI時代ではこれまでの多層防御やゼロトラストが無駄になる」わけではないことです。セキュリティ対策の基本原則は維持しつつAIエージェントなど新たに生まれる攻撃対象への対策を追加し、評価・意思決定・是正のスピードを上げていくことが重要なのです。

企業が取り組むべき6つの優先事項と金融庁・日本銀行の要請に見る具体策

こうしたピープル・プロセス・テクノロジーの変化を、より具体的な行動レベルに落とし込んだのが、次の6つの優先事項です。デロイト トーマツでは以下のように整理しています。

1. 可視性とインベントリ
   アタックサーフェスとそれを構成するIT資産を網羅的かつ最新の状態で把握する。
2. 意思決定の速度
   脆弱性の発見後、対応の要否や優先順位を迅速に判断する。
3. 是正速度
   修正が必要と判断してから、対応を完了するまでの時間を短縮する。
4. セグメンテーションとハードニング
   パッチ適用だけに頼らず、ゼロトラストや多層防御によって侵害時の影響を抑える。
5. パイプライン統合
   脆弱性の評価と修正をソフトウェア開発・展開プロセスに組み込み、継続的に実施する。
6. 取締役会および規制対応
   サイバーリスクを経営課題として扱い、取締役会への説明責任と規制対応を徹底する。

ここで求められるのは、すべての対応を最速で実行する「スピード（Speed）」ではありません。事業への影響や悪用可能性を踏まえて重要なリスクを見極め、限られた人員や予算を適切に配分しながら、判断と是正を着実に前へ進める「対応能力（Velocity）」です。そのためには、何を優先し、誰が判断し、どの期限で是正するのかを平時から確認し、継続的に実行できる体制の構築が重要です。

具体的にはIT資産の可視化、明確な意思決定権限、迅速なエスカレーション、継続的な是正プロセス、パッチを適用できない場合の代替策、取締役会への説明責任などです。

では、この対応能力を実務に落とし込むために、企業は具体的に何をすべきでしょうか。参考になるのが、2026年5月に金融庁と日本銀行が金融機関向けに示した要請（「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請）です。これは金融業界以外に直接適用されるものではありませんが、優先すべきサービスやITシステムを特定し、平時から対応基盤を整える考え方は、他業界においても参考にできます。

この中で特に重要なのは、優先的に対応すべきサービス・ITシステムを特定した上で、「技術負債」を解消しておく考え方です。技術負債とは、サポートが切れパッチが提供されないソフトウェアやサポート期間内であっても長期間パッチを当てていないもの、特権アカウントが適切に管理されていない状態など、システムが脆弱な状態を指します。パッチを迅速に当てる以前の問題として、こうした負債は解消しておかなければなりません。

技術負債を解消に加えて取り組むべきはパッチ適用に必要な人員の確保やベンダーとの契約の見直し、脆弱性のリスクに応じた優先順位付け、セグメンテーションやハードニングなどパッチ以外の対策強化です。

対応を優先すべきサービスやITシステムは、「攻撃を受ける蓋然性」と「事業上の重要度」の二軸で判断します。前者はインターネットへの接続をはじめとする外部への露出状況などから評価し、後者は保有する情報の機密性・完全性や業務継続への影響で評価します。金融機関では、この二軸で優先度を分類し、優先度の高いシステムから技術負債やパッチ以外の対策を点検・是正しています。

同要請でもう一つ特徴的なのは、リスクを十分に低減できない場合の能動的停止も選択肢に含めている点です。能動的停止の判断基準と手順の整備に加え、その際に事業を止めたままにしないよう、代替システムや手作業による処理を含むBCPを平時から点検・整備することも求められています。
 

CISA「BOD 26-04」に学ぶ、修正期限の決め方

対応を優先すべきシステムを特定した後は、個々の脆弱性の修正期限を判断します。その際に参考になるのが、米国のCISA（Cybersecurity and Infrastructure Security Agency）が示したリスクベースの考え方です。なお、BOD 26-04は米国連邦政府機関に向けた拘束力のある指令であり、民間企業に直接適用されるものではありませんが、リスクベースで対応期限を定める考え方は業種を問わず参考になります。

CISAは米国国土安全保障省の傘下で、サイバーセキュリティと重要インフラの防護を担う機関です。同機関が公表した「BOD 26-04（リスクに基づくセキュリティ更新の優先付け）」では、脆弱性の修正優先度を次の4つの観点から判断しています。

• 資産がインターネットなど外部に露出しているか
• 実際に悪用された脆弱性を収載するKEV（Known Exploited Vulnerabilities）カタログに掲載されているか
• 攻撃を自動化できるか
• 悪用された場合、攻撃者が資産をどこまで掌握できるか

これらの組み合わせに応じて修正期限が定められ、最もリスクが高い脆弱性には3日以内の対応を求める一方、リスクが低いものは次回のシステム更新時を修正期限としています。

第二章　「直すべきリスク」の優先順位付けとは

脆弱性の公表から悪用まで、残された時間は10時間

第二章では、実際に脅威を観測しているクラウドストライクが蓄積してきた脅威インテリジェンスとセキュリティ運用の知見をもとに、攻撃者側で何が起きているのか、企業にはどのような対応が求められるのかを、より実務的な観点から見ていきます。

まず押さえるべきは、「フロンティアAIは攻撃者にとって強力な武器になり得る」ということです。

攻撃者はすでに、偵察や攻撃対象領域の把握、脆弱性の探索、認証情報の収集、侵入後の横展開など、攻撃プロセスの複数の段階でAIを活用しています。これは将来起こり得る脅威ではなく、現在起きている事実です。さらに、高度な推論能力と自律性を備えたフロンティアAIが利用されることで、攻撃の自動化と高度化は一段と進み、さらなる高速化・大規模化は避けられません。

そもそも、防御側に残された時間は、すでに短くなっています。クラウドストライクが公開した「2026年版グローバル脅威レポート」によると、2025年のサイバー犯罪における平均ブレイクアウトタイムは29分でした。これは、攻撃者が最初の侵入に成功してから、ネットワーク内の別のシステムへ横展開するまでの平均時間です。

もう一つは、脆弱性の公表から攻撃への悪用が確認されるまでの時間が、大幅に短くなっていることです。米国土安全保障省（DHS）傘下のCISA KEVをはじめ、VulnCheck KEVやXDBなどが公開した脆弱性と悪用実績を基にした集計によると、CVEの公表から悪用が確認されるまでの平均時間は、2018年の2.3年から2026年には10時間へと短縮しています。

ただし、実際に悪用される脆弱性の件数自体が、この数年で急増しているわけではありません。問われているのは脆弱性の「数」ではなく、限られた人員と時間を、どの脆弱性の修正に振り向けるかという「処理の質とスピード」です。では、具体的にどのような基準で、実際の侵害につながる可能性を見極めるべきかを見ていきます。
 

「数」で守るか、「悪用可能性」で守るか――5つの実務原則

フロンティアAIへの備えとレジリエンスを高めるための考え方は、以下の5つの実務原則に整理できます。

• ステップ1……ボリュームよりも悪用可能性
  実際の悪用可能性と事業影響を基準に、修正の優先順位を決定する。
• ステップ2……継続的検証
  年1回や月1回のスキャンだけでは、急速に変化する攻撃環境に対応できない。外部にさらされている資産や脆弱性など、攻撃者に狙われうる露出点（エクスポージャー）を継続的に把握し、新たな攻撃手法や悪用状況の変化に応じてリスク評価を更新する。
• ステップ3……アイデンティティ保護と侵害範囲の隔離
  攻撃者は端末だけでなく、ユーザー、サービスアカウント、AIエージェントなどの認証情報も狙い、攻撃対象にする。そのためIDを適切に保護するとともに、万一侵害された事態を想定し、過剰な権限の利用や組織内での横展開を防止するアクセス制御と隔離体制を構築する。
• ステップ4……マシンスピードの運用
  攻撃者がフロンティアAIを用いて攻撃を自動化する以上、防御側も人手だけでは限界がある。検知後の情報収集や一次トリアージ、調査や対応の一部を自動化し、攻撃の速度に追随できる運用へ転換する。
• ステップ5……AIを含む攻撃対象領域の管理
  エンドポイント、クラウド、ID、SaaSに加え、AIシステムやAIエージェントも新たな保護対象として明示的に管理する。「どの部門が」「どのAIサービスを利用し」「どのデータやシステムへ接続しているか」を把握し、リスクに応じた保護策を講じる。

優先順位を実際の対応につなげる、AIエージェントと人が協働するSOC

ただし、ステップ1で修正すべき脆弱性を特定できても、その後の対応を実行できる運用体制がなければ、優先順位付けを実際の防御につなげられません。そこで注目したいのが、ステップ4の「マシンスピードの運用」です。

これを実現する具体策として注目されているのが、AIエージェントをSOC（Security Operations Center）の業務プロセスに組み込み、人間とAIエージェントで役割を分担する新たな運用モデルです。これは一般に「エージェント型SOC」と呼ばれます。下図のとおり、従来型の手動フローと、AIエージェントを組み込んだフローを比較すると、その違いが分かりやすいでしょう。

従来のSOCではアラートの発生後、担当者が情報収集や優先度の判断、調査、脅威の判定、端末の隔離・修復、記録までを手作業で進めていました。そのため、アラートが増えるほど対応が滞りやすくなります。

これに対しエージェント型SOCでは情報収集や関連データの付加、一次トリアージなどの定型作業を自律的に実行します。アナリストはその結果を確認し、誤検知であればケースを終了します。真陽性の可能性があるものや判断が難しいものは調査に特化したAIエージェントが追加調査を行い、確度が高いものはインシデント対応を担うAIエージェントが封じ込めや修復を支援します。

これにより、検知から対応までの時間を短縮するとともに、経験や知見を、アナリストの判断が特に重要な事案へ振り向けられるようになります。

ただし、実運用に当たっては、AIエージェントに与える権限、自動化する範囲、アナリストへ引き継ぐ条件を明確にし、影響の大きい操作にはアナリストの承認を求めるなどの統制が必要です。AIエージェントが参照した情報や判定、実行した操作を記録し、後から検証できる仕組みも欠かせません。SOCの自動化とは、AIエージェントを既存業務に追加することではなく、AIとアナリストの判断責任の境界を明確にし、対応の流れそのものを再設計する取り組みです。

 第三章　示唆を振り返り、次の一手へ

防御側の尺度に、攻撃者の視点を重ねる

野見山：ここからは、ここまでの議論を踏まえ、企業が取るべき次の一手を伺います。「直すべきリスク」を見極めるうえで、従来の資産の重要度やCVSSスコアだけでは何が足りず、今後はどのような視点を加えて優先順位を判断すべきでしょうか。

藤岡：企業が取るべき次の一手は、防御側の尺度に攻撃者の視点を重ねることです。資産の重要度やCVSSスコアは、引き続き重要な判断材料です。ただし、それだけでは、実際の侵害につながるリスクを十分に見極められません。スコアがそれほど高くなくても、攻撃者にとって悪用しやすく、特権の取得や重要システムへの侵入につながる脆弱性があるためです。今後は、悪用可能性や重要資産への攻撃経路まで含めて、修正の優先順位を判断する必要があります。

野見山：つまり、これからは「自社にとって何が重要か」という防御側の視点に、「攻撃者がどの脆弱性を、どのように利用するのか」という視点を重ねる必要があるということですね。では、その攻撃者視点を具体的な優先順位付けに反映するには、どのようなアプローチが必要でしょうか。

藤岡：鍵になるのは、攻撃者が侵入口から重要資産にたどり着くまでの経路となる「アタックパス」を把握することです。

例えば、ある脆弱性が悪用されても影響が一台の端末の停止にとどまり、重要システムに及ばないとします。この場合、対応の緊急度は相対的に低いと言えるでしょう。一方、深刻度スコア自体はそれほど高くなくても、認証を回避したり特権を取得したりできる脆弱性は、重要資産への侵入経路になり得るため、優先的に対応する必要があります。

野見山：個々の脆弱性の深刻度だけでなく、「その先に何があるか」までを平時から可視化しておくことが重要なのですね。

藤岡：そのとおりです。アタックパスの分析自体は、専門家やAIを活用した製品・サービスの力を借りることができます。ただし、「自社にとって何が重要資産か」という判断は、ツールや専門家に委ねられるものではありません。この判断とアタックパスの分析を掛け合わせてはじめて、自社にとって本当に対策を優先すべきリスクが見えてきます。

野見山：最後に、こうした優先順位付けを具体的な取り組みに移すうえで、企業は何から着手すべきでしょうか。

藤岡：個別の対策を追加する前に重要なのは、経営層が自社のサイバーセキュリティについて「どのような状態を目指すのか」を明確にすることです。インシデントや新しい規制が生じるたびにその場限りの対策を追加していると、全体がパッチワーク化してしまいます。まず目指す姿を定め、そこから逆算して、短期・中長期で取り組むべきことをロードマップに落とし込む必要があります。

その際に大切なのは「防御」と「予防」を分けて考えることです。防御ではインシデント対応やSOCの高速化、脆弱性の点検と修正など、現在の脅威に速やかに対処するための取り組みを整理します。一方、予防では教育や人材育成、ルールやプロセスの整備など、中長期的に組織を強くする施策を立案します。重要なのは、どちらか一方を選ぶことではなく、足元の防御を強化しながら、将来に向けた予防にも継続して取り組むことです。

さらにガイドラインへの対応や製品・サービスの導入についても、それが自社の目指す姿にどうつながるのかを確認しなければなりません。将来像との関係を考えずに個別対策を重ねると、機能の重複や二重投資が生じる可能性があります。

攻撃者視点を、経営のロードマップへ

野見山：ありがとうございます。これまで伺ってきたとおり、フロンティアAIによって、企業が評価すべき脆弱性の候補は増え、悪用までの時間は短縮しています。一方、事業への影響と悪用可能性を踏まえて優先順位を定め、平時からリスクを低減するという基本は変わりません。こうした変化に追随するために、テクノロジーと脅威インテリジェンスを活用し、判断と是正を継続できる体制へ移行することが重要だと改めて認識しました。

藤岡さん、本日はありがとうございました。