Agentic AI × SOCワークフロー：プレイブックを超えた自律防御【2026年版ガイド】

あなたのSOCは、アラートの洪水に溺れていないだろうか。

企業のセキュリティオペレーションセンター（SOC）が1日に受信するアラートは平均4,484件、28種類以上のツールから届く。アナリストが1件のアラートを調査するのに平均70分かかり、誰かが最初に確認するまでに56分が経過する。Devo社の「2024 SOC Performance Report」によれば、アラートの53%がfalse positiveであり、約半数は一度も調査されない。

日本においても状況は同様だ。経済産業省の調査では、サイバーセキュリティ人材は2030年までに約80万人不足すると試算されており、SOCアナリストの採用・育成は多くの組織で深刻な課題となっている。これはプロセスの失敗ではなく、キャパシティの失敗だ。そして従来の自動化——SOAR、プレイブック、スクリプト化されたRunbook——はすでに限界に達している。

その解決策が Agentic AI × SOCワークフロー だ。タスクの自動化から推論の自動化への転換である。本ガイドでは、Agentic AIの実際の動作原理、従来のSOARが抱える限界、そしてWazuh + Shuffle SOAR + DFIR-IRISの既存スタックにどう自律的な能力を重ねるかを、各ステップのPseudocodeとともに解説する。

Agentic SOCとは何か

Agentic SOCとは、AIエージェントがアラートトリアージ・脅威調査・対応判断を自律的に処理するセキュリティオペレーションセンターのことだ。人間が各ステップを起動する必要がない。事前に書かれたプレイブックに従う従来のSOARとは異なり、Agentic SOCはtool-calling機能を持つLarge Language Models（LLMs）を活用して新種の脅威を推論し、セキュリティスタック全体にわたるシグナルを関連付け、ポリシーで定義されたガードレール内で行動する。結果として得られるのは、ヘッドカウントではなくアラート量に応じてスケールする調査能力だ。

変化の本質：スクリプトからエージェントへ

SOC自動化の進化を3つのフェーズで振り返ると、Agentic AIの重要性が明確になる。

フェーズ1 — セキュリティ自動化： 明確に定義された繰り返しタスクのスクリプト化。Detection rulesのチューニング、Enrichmentクエリの実行、重大アラートへの通知送信など。予測可能で信頼性が高いが、脆弱でもある。スクリプトの範囲外のロジックには常に人間が必要だった。

フェーズ2 — Generative AI Copilots： LLMが思考パートナーとして登場。アナリストは自然言語でセキュリティデータをクエリし、インシデントレポートの要約やEnrichmentの提案を受け取れるようになった。強力ではあるが、人間が依然として調査を起動し、すべての決定を下す必要があった。ボトルネックは残ったままだった。

フェーズ3 — Agentic AI： 程度ではなく、種類が異なる。インテリジェントなエージェントが多段階タスクを自律的に実行する。計画し、推論し、コンテキストを収集し、ツール間で証拠を関連付け、対応アクションを実行する——すべて人間のトリガーなしに。

EYの2026年CISO調査が明確に示している通り、目標は高量タスクを自動化し、より高度な役割を強化することだ。Detection ruleの開発、Threat intelligenceのマッピング、SOARプレイブックの生成、インシデントのクローズ——これらがターゲットとなる。アナリストを置き換えるのではなく、すべてのアナリストがシニアレベルで機能できるようにすることが目的だ。

従来のSOARではもはや不十分な理由

SOARは真の技術的跳躍だった。断片化したセキュリティツールを繋ぎ合わせ、対応ワークフローを標準化し、手動作業を大幅に削減した。多くの組織が今もSOARを使用しており、今後も使い続けるだろう。しかし2026年のAI加速型脅威環境において、その限界はもはや無視できない。

カバレッジのギャップ： ほとんどのSOAR導入では、アラートキューの30〜40%——プレイブックが対応しているもの——しか自動化できない。残りの60〜70%は依然として人間が調査を起動する必要がある。新種のTTP、多段階キャンペーン、曖昧な低fidelityアラートにはプレイブックが存在しない。

硬直性： プレイブックとは、前四半期の脅威環境向けに書かれたロジックだ。調査の途中で適応することも、未知の攻撃者の行動について推論することも、クエリするよう設計されていないツール間でシグナルを統合することもできない。

エンジニアリングオーバーヘッド： プレイブックの構築と維持には、Pythonスクリプティング、APIスキーマの配線、ベンダーがエンドポイントを変更するたびの継続的な更新が必要だ。これにより自動化は専門職化し——「SOARエンジニア」という役割が生まれ——本来Detection and Responseに使われるべき予算を消費することになった。

GartnerとForresterはともに2025年までに独立したSOARのMagic Quadrant評価を廃止した。スタンドアロンSOARカテゴリはアーキテクチャ上の天井に達したのだ。業界のシフトは明確だ：ワークフローのオーケストレーションから、調査を通じた推論へ。

Agentic SOCの実際の動作原理

Agentic SOCプラットフォームは、静的なプレイブックモデルを、調査を自律的に推論するAIエージェントで置き換える。アーキテクチャは順序立てて動作する3つの協調エージェントで構成される。

flowchart TD
    A["Raw Alert Stream\n(SIEM / EDR / NDR)"] --> B["Triage Agent\n(classify, deduplicate, prioritize)"]
    B --> C["Investigation Agent\n(gather context, correlate, enrich)"]
    C --> D{"Confidence Score"}
    D -->|"High confidence\nroutine threat"| E["Response Agent\n(auto-contain, block, isolate)"]
    D -->|"Novel / ambiguous\nscenario"| F["Human Analyst\nReview Queue"]
    E --> G["Case Documentation\n& Audit Trail"]
    F --> G
    G --> H["Feedback Loop\n(improve future agent decisions)"]

Triage Agent

Triage Agentは最初のパスを担当する。アラートの重複排除、脅威タイプの分類、重大度とコンテキストに基づく優先順位付けを行う。Radiant Securityなどのプラットフォームは、このレイヤーでfalse positiveを約90%削減すると報告しており、アナリストをアラートノイズから解放する。

AGENT: TriageAgent
INPUT: raw_alert

FUNCTION triage(alert):
    # ステップ1 — 重複排除
    fingerprint = hash(alert.rule_id + alert.agent_id + alert.source_ip)
    IF fingerprint IN recent_seen_window(last=5min):
        RETURN SKIP  # 重複アラートを抑制

    # ステップ2 — 基本コンテキストのエンリッチ
    alert.agent_hostname    = lookup_asset_inventory(alert.agent_id)
    alert.rule_mitre_tactic = map_rule_to_mitre(alert.rule_id)
    alert.src_ip_reputation = query_threat_intel(alert.source_ip)

    # ステップ3 — 重大度スコアリング
    score = base_score(alert.rule_level)                  # Wazuh level 1–15
    IF alert.src_ip_reputation == "MALICIOUS":            score += 30
    IF alert.rule_mitre_tactic IN HIGH_VALUE_TACTICS:     score += 20
    IF alert.agent_hostname IN CRITICAL_ASSETS:           score += 25

    # ステップ4 — 分類とルーティング
    IF score >= 80:
        RETURN route_to(InvestigationAgent, priority="HIGH")
    ELSE IF score >= 50:
        RETURN route_to(InvestigationAgent, priority="MEDIUM")
    ELSE:
        RETURN log_and_close(reason="Below investigation threshold")

Investigation Agent

Investigation Agentは、かつてTier 2アナリストが必要とした分析作業を担う。Threat intelligenceフィードからEnrichmentデータを収集し、IDとネットワークログ全体でLateral movementを追跡し、何が起きてなぜそれが起きたかについて構造的な仮説を構築する。Dropzone AIのプラットフォームは、業界平均の70分と比較して、約3分で一貫したトリアージ調査を提供すると報告している。

AGENT: InvestigationAgent
INPUT: triaged_alert, priority

FUNCTION investigate(alert):
    evidence    = []
    hypotheses  = []

    # ステップ1 — タイムライン再構築
    related_events = opensearch_query(
        filter  = { agent_id: alert.agent_id },
        range   = { last: 30min, before: alert.timestamp },
        sort_by = "timestamp ASC"
    )
    evidence.append(related_events)

    # ステップ2 — Lateral Movement チェック
    IF alert.rule_mitre_tactic IN ["Lateral Movement", "Credential Access"]:
        peer_events = opensearch_query(
            filter = { source_ip: alert.source_ip, event_type: "authentication" },
            range  = { last: 2hr }
        )
        IF peer_events.unique_destinations > 3:
            hypotheses.append("{n}台のホストにわたる横移動の可能性")

    # ステップ3 — IOCエンリッチメント
    FOR ioc IN extract_iocs(alert):  # IPs, hashes, domains
        ioc.vt_score    = virustotal_lookup(ioc)
        ioc.abuse_score = abuseipdb_lookup(ioc)
        ioc.misp_hit    = misp_lookup(ioc)
        evidence.append(ioc)

    # ステップ4 — LLM推論パス
    prompt = build_investigation_prompt(alert, evidence, hypotheses)
    llm_analysis = call_llm(
        system = "You are a Tier 2 SOC analyst. Reason step by step.",
        user   = prompt,
        tools  = [opensearch_tool, threat_intel_tool, asset_lookup_tool]
    )

    # ステップ5 — 信頼度スコアリング
    confidence = score_confidence(llm_analysis, evidence)

    RETURN InvestigationResult(
        summary    = llm_analysis.conclusion,
        hypotheses = hypotheses,
        evidence   = evidence,
        confidence = confidence,   # 0.0 – 1.0
        mitre_tags = llm_analysis.mitre_tags
    )

Response Agent

Response Agentは、セキュリティチームが定義したガードレール内で行動する。ホストの隔離、侵害されたアカウントの無効化、ファイアウォールでのC2 IPブロック、または既存のSOARレイヤー経由での設定更新のプッシュなど。すべてのアクションはログに記録され、説明可能で、監査可能だ。

AGENT: ResponseAgent
INPUT: investigation_result

# ポリシーテーブル — セキュリティチームが定義する（エージェントではなく）
RESPONSE_POLICY = {
    "block_ip"        : { auto_threshold: 0.85, scope: "edge_firewall" },
    "isolate_host"    : { auto_threshold: 0.90, scope: "edr_platform",
                          require_human_if: asset IN CRITICAL_ASSETS },
    "disable_account" : { auto_threshold: 0.95, require_human: TRUE },
    "create_iris_case": { auto_threshold: 0.00 },  # 常に自動
    "trigger_playbook": { auto_threshold: 0.70, playbook_id: "containment_v2" }
}

FUNCTION respond(result):
    actions_taken            = []
    actions_queued_for_human = []

    FOR action IN result.recommended_actions:
        policy = RESPONSE_POLICY[action.type]

        IF result.confidence >= policy.auto_threshold
           AND NOT requires_human_override(action, policy):
            execute_action(action)
            audit_log(action, agent="ResponseAgent", confidence=result.confidence)
            actions_taken.append(action)
        ELSE:
            queue_for_analyst(
                action      = action,
                reason      = "信頼度がthreshold未満、またはポリシーによる人間承認必須",
                evidence    = result.evidence,
                llm_summary = result.summary
            )
            actions_queued_for_human.append(action)

    # IRISケースは必ず作成する
    create_iris_case(
        title      = result.summary,
        severity   = map_confidence_to_severity(result.confidence),
        mitre_tags = result.mitre_tags,
        evidence   = result.evidence,
        actions    = actions_taken + actions_queued_for_human
    )

    RETURN ResponseReport(auto=actions_taken, pending=actions_queued_for_human)

このアーキテクチャ全体を通じた重要な原則が human-in-the-loop ガバナンス だ。新種または高影響のシナリオは自律的に処理されるのではなく、人間のアナリストにエスカレートされる。AIはすべてのステップで推論を説明し、アナリストのフィードバックは将来の意思決定を継続的に改善するために取り込まれる。

Wazuh + Shuffle SOARへのマッピング

オープンソースまたはミッドマーケットのSOCスタック——Wazuh + Shuffle SOAR + DFIR-IRIS——を運用しているチームにとって、プラットフォームの完全な置き換えは唯一の選択肢ではない。既存のインフラ上にAgentic能力を重ねる実践的なアプローチがある。

flowchart TD
    subgraph "Existing SOC Stack"
        W["Wazuh\n(Detection / SIEM)"]
        OS["OpenSearch\n(Log storage / KQL query)"]
        SH["Shuffle SOAR\n(Playbook automation)"]
        IRIS["DFIR-IRIS\n(Case management)"]
    end
    subgraph "Agentic AI Layer"
        MW["Custom Middleware\n(soc-integrator / FastAPI)"]
        AG["AI Investigation Agent\n(LLM + tool calls)"]
        TI["Threat Intel Feed\n(IOC enrichment)"]
    end

    W --> OS
    OS --> MW
    MW --> AG
    AG --> TI
    AG --> SH
    SH --> IRIS
    AG --> IRIS

soc-integrator FastAPIミドルウェアはDetection layerとAutomation layerの間に位置し、OpenSearchから正規化されたWazuhアラートデータを受け取り、3つのエージェントパイプラインを通じてルーティングする。完全なオーケストレーションループは以下の通りだ。

# soc-integrator / FastAPI — メインエージェントオーケストレーションループ

SERVICE: SocIntegrator

ON_EVENT: wazuh_alert_webhook(alert_payload):

    # 1 — WazuhアラートをInternalスキーマに正規化
    alert = normalize_wazuh_alert(alert_payload)
    # Maps: rule.id, rule.level, rule.mitre.*, agent.*, data.srcip → AlertSchema

    # 2 — トリアージ実行
    triage_result = TriageAgent.triage(alert)
    IF triage_result == SKIP:
        RETURN 200  # 重複アラートを抑制

    # 3 — 調査実行
    investigation = InvestigationAgent.investigate(
        alert    = alert,
        priority = triage_result.priority
    )

    # 4 — 対応判断実行
    response = ResponseAgent.respond(investigation)

    # 5 — DFIR-IRISへプッシュ
    iris_case_id = iris_client.create_case(
        title    = "[AUTO] " + investigation.summary[:80],
        severity = investigation.confidence_to_severity(),
        tags     = investigation.mitre_tags,
        assets   = investigation.affected_assets,
        iocs     = investigation.confirmed_iocs,
        timeline = investigation.evidence_timeline
    )

    # 6 — 自動対応が承認された場合、Shuffle SOARプレイブックをトリガー
    IF response.auto_actions:
        shuffle_client.trigger_workflow(
            workflow_id = CONTAINMENT_WORKFLOW_ID,
            inputs = {
                "iris_case_id" : iris_case_id,
                "actions"      : response.auto_actions,
                "alert_data"   : alert
            }
        )

    # 7 — 人間のレビューが必要な場合、アナリストキューに通知
    IF response.pending_actions:
        notify_analyst_queue(
            case_id  = iris_case_id,
            summary  = investigation.summary,
            pending  = response.pending_actions,
            channel  = "slack:#soc-review"
        )

    RETURN 200

これはシステムの全面刷新ではない。既存の動作しているものの上に知能レイヤーを追加し、スクリプト化されたプレイブックが対応するよう設計されていなかった推論のギャップを埋めるのだ。

導入効果と率直な注意点

組織が報告している成果

Agentic SOCアプローチを導入した組織は、一貫して測定可能な成果を報告している。

MTTRの大幅短縮： 通常の脅威クラスで、対応時間が数時間から数分へ
アラートカバレッジの拡大： SOARの典型的な30〜40%から100%の調査対象へ——Agentic AIがTier 1・Tier 2ワークロードを処理
アナリストの燃え尽き症候群軽減： 繰り返しのトリアージ作業がエージェントに移行し、シニアスタッフが脅威ハンティングと複雑なインシデント管理に集中できる
ヘッドカウントなしのスケーラビリティ： 北米のあるMSSPは、人員を比例的に増やすことなく月間3万件のアラートを自律的な調査で処理している

率直な注意点

LLMはハルシネーションを起こす可能性がある。 Agentic AIは絶対的に正確ではない。すべての自律対応アクションには明確に定義されたガードレールが必要であり、アカウントの終了や本番ホストの隔離などの高影響アクションは、信頼度スコアに関わらず常に人間の確認を必要とすべきだ。

スキル陳腐化は現実のリスクだ。 ジュニアアナリストがトリアージ調査を行わなくなると、エージェントがエスカレートしたものを処理するための推論スキルを養えなくなる。自動化のロールアウトと並行して、意図的なトレーニングプログラムを実施すること。

データ品質がエージェント品質を決定する。 調査エージェントの能力は、クエリできるログの質に依存する。不完全なIngestion、スキーマの不整合、不適切な正規化は、AIロジックが実行される前に調査品質を低下させる。WazuhデコーダーのクオリティとOpenSearchインデックスの規律は、オプションではなく基盤となるものだ。

ガバナンスはデプロイより先に来なければならない。 エージェントが自律的に行動できるものと人間の承認が必要なものを定義した文書化されたポリシーなしにAgentic能力を展開することは、単なる技術的問題ではなく、コンプライアンスと法的責任リスクだ。NISCのサイバーセキュリティ対策基準や個人情報保護法の観点からも、このガバナンス文書は重要な意味を持つ。

2026年に優先すべきこと

Agentic SOC能力を評価しているチームのための実践的な実装順序：

1. まずデータ基盤を整備する。 一貫したログIngest、フィールド正規化、WazuhルールでのMITRE ATT&CKタグ付け。Agentic AIはこのデータをクエリする——Garbage in、hallucination out。

2. ミドルウェアブリッジを構築する。 正規化されたアラートデータを消費し、構造化されたtool-callingでLLMに渡すFastAPIサービス。これがAgentic logicが既存のSOARとケース管理に接続される統合ポイントだ。

3. Responseではなくトリアージから始める。 エージェントがアクションを実行する前に、分類・エンリッチ・要約を行わせること。封じ込め権限を付与する前に、エージェントの推論に対するアナリストの信頼を構築する。

4. Human-in-the-loopの閾値を文書化する。 エージェントが自律的に処理できるアラートクラス、アナリストのレビューが必要なもの、常にシニアの承認が必要なものを文書化する。これらはポリシーの決定であり、技術的な決定ではない。

5. 初日からアナリストのフィードバックループを構築する。 アナリストがエージェントの評価に同意しないエスカレートされたすべてのアラートは、トレーニングシグナルだ。体系的にキャプチャすること。

おわりに

SOCの変革はもはや将来の計画事項ではない。脅威のランドスケープ——AI加速型攻撃自動化、大規模な認証情報悪用、エンタープライズAIシステムへのPrompt injection——は、従来のSIEM＋プレイブックアーキテクチャが対応できる速度を超えて進化している。

Agentic AIはアナリストを置き換えない。アナリストを増幅させる。シニアアナリストの推論を符号化し、アラートキューの100%にわたって機械速度で実行し、真に人間の判断を必要とするケースを浮かび上がらせる。

Wazuh、Shuffle、DFIR-IRISをすでに運用しているチームにとって、道はプラットフォームの置き換えではない。それは上に重ねられた推論レイヤー——FastAPIミドルウェアサービス1つ、構造化されたtool callsを持つLLM1つ、そして人間の監督がどこから始まるかを定義するガバナンス文書——だ。

それは構築可能なプロジェクトだ。そして2026年においては、必要不可欠なものだ。

既存のSOCスタック上にAgentic Layerを構築する準備はできていますか？ Simplicoに相談する →

Simplicoについて
Simplico Co., Ltd.は、バンコク拠点のソフトウェアエンジニアリング＆プロダクトスタジオです。10年以上のエンタープライズ向けデリバリー実績を持ち、AIインテグレードのセキュリティ運用ツール、ERPインテグレーション、Eコマースプラットフォーム、タイ・日本・中国・グローバル英語市場向けカスタムソフトウェアを開発しています。simplico.net

タグ：Agentic AI SOC, SOCワークフロー自動化, SOAR vs Agentic AI, Wazuh, DFIR-IRIS, Shuffle SOAR, AI脅威検知, 自律型SOCプラットフォーム, サイバーセキュリティ 2026, セキュリティオペレーションセンター AI