AI SOCとは何か──29分の攻撃に、人間のトリアージは間に合うのか

攻撃側で何が起きているか

CrowdStrikeの2026 Global Threat Reportによれば、2025年の平均ブレイクアウトタイムは29分で、2024年の48分から4割短縮されました。最速事例では27秒となっており、初期アクセスから攻撃侵攻、データの持ち出しまでの時間短縮が急速に進んでいます。

背景は攻撃者によるAI悪用であり、攻撃のかなりの工程がAIにより武器化されています。防御側が重視すべきは、次の2つの数字です。

検知イベントの82%がマルウェアに依存しない

攻撃者は盗んだ認証情報と標準の管理ツールでログインしてきます。悪意あるコードが使われない以上、シグネチャやIoCに基づく検知から、どの権限によりどのような操作が行われているかを評価する必要があります。正規の操作と侵害の操作を見分けるには、その操作が業務上どういう意味を持つかという文脈判断が必要であり、ルール化が難しくなります。

悪用された脆弱性の42%は公開前に攻撃されていた

フロンティアAIモデルによる脆弱性発見の高速化は、防御側にも同じ恩恵をもたらすものです。しかしながら攻撃側が時間軸やコストの面で優位であるという非対称性は引き続き存在します。ゼロデイ攻撃の増加は、防衛側にとってパッチが公開されてから対応するという考え方を根底から変えるものになります。

マシンスピードの防御を、時間軸で3つに分ける

攻撃がマシンスピードになった以上、防御もマシンスピードにする必要があります。問題は、「防御側のマシンスピード」が単一の製品導入では解決できないことです。

図1　マシンスピードの防御：対策を時間軸で考える

侵入前：サイバーハイジーン　IT資産の把握、脆弱性管理、パッチ適用の自律化です。攻撃対象領域そのものを減らす、最も費用対効果の高い技術領域です。ただし、パッチ公開より先に脆弱性悪用攻撃が増えていることを踏まえて、後続の対策を充実させる必要があります。

侵入から「29分」の間：検知・調査・初動　AI SOCが担う段階です。検知の82%がマルウェアレスであるということは、正規の操作と攻撃を区分することの重要性を示していますが、同時にその判断を人手で29分に収めることの難しさも示しています。

侵害後：サイバーレジリエンス　マイクロセグメンテーションによる横展開の封じ込め、万が一に備えたイミュータブルバックアップとリカバリによる事業継続。侵害を前提に、被害範囲の局所化と復旧時間を重視した技術領域です。この領域は別記事「『防ぐ』『信頼しない』では足りない──サイバーレジリエンスという第三のアーキテクチャ」（過去の記事にリンク）で詳述しました。

3つの組み合わせが重要

重要なのは、この3つの技術領域は相互に代替不能である点です。

サイバーハイジーンをどれだけ強固にしても、ゼロデイで侵入された後の29分は埋まりません。サイバーレジリエンスも同様で、封じ込めが発動する前の検知と判断は速くなりません。AI SOCを導入しても、パッチ未適用の資産への侵入は防げず、封じ込めに失敗したときの復旧時間も短くなりません。担当する領域や時間軸が違うため、3つは組み合わせが重要です。

多くの国内企業ではサイバーハイジーンへの投資が進み、現在はサイバーレジリエンスへの投資が急速に進む状況にありますが、ブレイクアウトタイムの29分を埋める対策は十分ではありません。これら3つがセットで検討されていないため、対策の強弱が可視化されないまま個別に検討している、というのが実情ではないでしょうか。

OpenAI／Hugging Face事案：検知の成功、トリアージの失敗

2026年7月、OpenAIの評価環境で稼動するAIエージェントがサンドボックスを逸脱し、最終的にHugging Faceの環境を侵害しました。これは一般企業がすぐに同じ攻撃を受けるという話ではありませんが、検知・対応の変化の必要性を示す題材となります。

攻撃元：アラートは上がっていた

事象の初期において、OpenAIの監視ツールはネットワーク活動を検知しアラートを発報しました。対応担当者は調査を行い、それが実施中の評価活動のものだと突き止めましたが、評価を停止する必要はないと判断し、上位者への報告も行いませんでした。

被害側：膨大な調査対象

一方、被害を受けたHugging Faceでは別の問題がおきます。攻撃による操作は数日で17,000件を超え、この規模のログを人手で解析することは現実的ではなく、AIを使って解析しています。その過程でAI利用の課題を突きつけられます。攻撃コマンドなどを解析させたところ、フロンティアAIモデルのセーフガード（安全機構）に阻まれて解析が行えなかったのです。結果的に中国製オープンウェイトモデルを使い解析したと報告されています。AI SOCによる大量データの解析の必要性を表すと同時に、その選定において攻撃コマンドを含むデータの解析をAIモデルが拒否しないかを確認することの重要性を示す事例です。

防御側の制約：人材不足

防御側ではもうひとつ重要な視点があります。構造的なサイバーセキュリティ人材の課題です。サイバーセキュリティにおいて人数とスキルの不足があることは経済産業省の資料でも大きく触れられています。

24時間365日のセキュリティ監視や検知に基づく対応を実現するためには人手に依存しない自動化の実装が不可欠です。調査と判断の処理速度を大きく短縮する必要があり、それを実現するためにAI SOCが注目されています。

実行の自動化から判断の自動化へ

セキュリティ運用の自動化という発想自体はSOAR（Security Orchestration, Automation and Response）が登場した10年以上前から存在しますが、2026年に改めて注目される理由は以下2条件の成立と考えられます。

条件①：判断をAIに任せられるように

アラートのトリアージとは「発生している挙動が組織にとって正常かどうか」です。これは単純なチェックリストや判断表では決められません。そのため判断根拠や手順を定める必要のあるSOARでは自動化できませんでした。これをAIの推論能力が解決します。コンテキストによる解釈が可能になり、人間のアナリストが行うような判断をAIに任せられるようになりました。

条件②：必要な情報にツール／AIがアクセス可能に

人間のアナリストは調査の過程で別の情報を加え、調査することがあります。例えば「イベント時刻のプロセス一覧」「近似時間帯の通信先」といった情報です。従来のSOARでは、どのような調査が必要か網羅的に記述することが難しく、作り込みにはコスト増の懸念がありました。現在は多くのシステムでAPIなど接続プロトコルの標準化が進み、またAIエージェントの進化によって実装が簡単になりました。

AI SOCとその構成要件

AI SOCとは、アラートのトリアージ・調査・判断をAIが自律的に実行し、その根拠を人間が検証できるように残すものであると言えます。AI SOCは無人化を目指すものというより、限られた人手を本当に判断が必要な場面に集中させるための仕組みです。

対応判断をAIで下せるか

人間が定めた実施対象と条件式に従って動作する従来型SOARのプレイブックではなく、証拠と状況に応じて調査対象が変わること、AIが文脈によって対応を変えられるものがAI SOCといえます。

自社の環境や状態を文脈として理解できるか

ログ分析では長らく正規化が課題でした。機器ごとに異なるログ形式を共通フォーマットに揃えることで、横断的な分析が可能になります。しかし正規化では、その操作が業務上どんな意味を持つのか、その環境では日常的に発生していることなのかはわかりません。冒頭で触れたように、検知イベントの82%はマルウェアを使いません。攻撃者は正規の認証情報、正規のツールを使って侵入します。正常か異常かの判断には組織固有の状態や環境を踏まえた文脈による判断が欠かせません。

判断を人間が検証できるか

AIが判断を担うようになれば大きな時間短縮が期待できますが、過剰検出や見逃しの可能性は残るため、後から追いかけることが必要になる場面もあります。セキュリティ調査の確認以外にも、監査の目的でも必要になる場面も出てきます。AIエージェントが行った行動について、どのデータソースを根拠として、どのようなアクションを行ったのか、推論ステップを経てどう結論づけたのか、それを追跡できなければなりません。

AIにどこまで任せるか

AI SOCでは、AIにどこまでを任せ、人がどこから判断するか、その線引きには「時間からの逆算」と「アクションの不可逆性」という2つの観点が必要です。

封じ込め完了までの目標を15分に置くとします。トリアージに5分、調査と裏取りに5分を割けば、承認と実行に残るのは5分です。人の承認が必要であれば、それを最後の5分に収めなければなりません。判断の軸は不可逆性、つまりそのアクションを戻せるかどうかです。

戻せるもの＝AIに任せる。 業務端末の隔離、単一アカウントのセッション失効、チケットの起票、追加ログの収集。誤判定があっても影響が限定的で、元に戻せるものは待たずにアクションします。

戻せないが、待てないもの＝条件を事前に決めて自動化し、事後にレビューする。 ネットワーク単位の通信遮断、テナント全体の認証セッション一斉失効など。人の承認を待てば手遅れになり、かといって無条件に実行するわけにもいかないものです。発動条件を事前に定義しておき、実行後には必ず評価・検証します。

戻せず、待てるもの＝人が承認する。 侵害された端末・サーバの初期化、本番システムのサービス停止など。業務への影響が大きいものは人の判断を待って実行します。

AI SOCのアーキテクチャ

AI SOCの製品・ソリューションは調査対象のデータをどのように取得するかでいくつかに分類されます。

SIEM前提型

SIEMに集約されたログを読みに行く方式です。既存のデータ基盤やログ収集フローを活用できるため導入しやすいのが特徴です。ただし、既存SIEMにおいて取り込みを絞ったログはそのまま調査対象から外れることが課題となる場合があります。

直接連携型

調査対象（セキュリティサービス、クラウドなど）のAPIを直接呼び出し、必要なイベントを都度取得する方式です。ログの事前集約を前提としないため、データ保管の考え方、コスト構造が根本から変わります。現在はAPIでイベント取得する製品が多くなってきましたが、既存システムとの接続性の確認が必要です。

ハイブリッド型

データ保管はSIEMまたはデータレイクソリューション、リアルタイムの調査はAPI連携、という役割分担・組み合わせで実現する方式です。今後主流になる方式だと考えられますが、製品選定の際に自社のITシステムとの親和性を検討・検証することが重要になってきます。

今が検討をはじめるタイミング

AI SOCは立ち上がったばかりの領域で、今後も技術・機能の急速な進化が予想されます。だからこそ今、調査と検討を始めるべき段階に来ています。

既存のSIEMやSOARへの投資を無駄にする必要はありません。これまで積み上げてきたログ基盤や検知ロジック、運用ノウハウ、そしてサイバーハイジーンやサイバーレジリエンスへの取り組みこそが、AI SOCの効果を最大に引き出す前提条件となります。

本稿タイトルにも挙げた「29分」という数字は、人手に依存した運用の限界と、自動化へのシフトの必要性を明確に示しています。既存資産を活かしながらセキュリティ防御力・対応力を根本から強化するために、まずはベンダー動向や技術調査から、今すぐ一歩を踏み出すことをお勧めします。