Agentic SOC Platform を導入前に読む: アラート集約とエージェント調査の実際

アラートの洪水を Case に畳むという発想

このプロジェクトが解こうとしているのは、検知はできるが処理が追いつかないという状態である。README は「Modules stream SIEM / Webhook alerts, extract IOCs, correlate related signals」と説明しており、SIEM や Webhook から入ってくるアラートをモジュールが受け取り、IOC を抽出し、関連するシグナルを相関させたうえで Case、Alert、Artifact を生成する。狙いは README の表現を借りれば「massive log volumes converge into a small number of actionable cases」、つまり大量のログを少数の判断可能な案件に収束させることにある。

想定読者は SOC の一次担当者と、その上で働く検知エンジニアである。問い合わせの単位がアラートから Case に変わるため、同じ攻撃に属する複数の検知を一人がまとめて見られる。ただしこれは相関ロジックが正しく書かれている前提の話で、モジュール側の抽出と相関の品質がそのまま Case の品質になる。README はモジュールの具体例を本文では示しておらず、そこは公式サイトのドキュメントに委ねられている。

Case を起点に LLM と SOAR を同じ Playbook で回す

調査の流れは Case を中心に組み立てられている。README によれば、各 Case に対して LLM 調査、ナレッジ抽出、脅威インテリジェンスのエンリッチメント、CMDB のエンリッチメントをワンクリックで起動でき、従来型の SOAR ワークフローと AI 分析を同一の Playbook システム上でオーケストレーションする。出力として深刻度、確信度、影響範囲、優先度、判定、構造化された調査レポートが生成されると README は述べている。

ここで注目したいのは、AI 分析を SOAR の外に置かず同じ Playbook に載せている点である。別系統のツールとして足すのではなく、既存の自動化ステップと同じ実行基盤に混ぜている。そのぶん Playbook の書き方に習熟が必要になるが、判断の途中に人手の承認を挟むようなフローも同じ仕組みで表現できる。README は Playbook の記法そのものには触れていないため、実際の記述粒度は公式サイトの Workspace Features 側で確認する必要がある。

Harness Agent に CLI とプラグインで能力を渡す

特徴的なのは外部エージェントとの接続方法である。README は「Expose ASP capabilities to Claude Code / Codex / OpenCode and other Harness Agents through the CLI and plugins」と書き、エージェントが Case を操作し、ログを検索し、脅威インテリジェンスを照会し、モジュールや Playbook を直接書けるとしている。つまり ASP の側からエージェントを呼ぶだけでなく、エージェントの作業机として ASP の機能を差し出す方向の統合である。

この設計は、調査の主導権をどこに置くかという選択を含んでいる。ASP の UI から LLM 調査を起動する経路と、Claude Code 側から CLI 経由で ASP を叩く経路の二つが併存する。後者を選ぶと、調査の記録が ASP の Case に残るかどうかが運用上の争点になる。README はこの点、エージェントが Case を操作できると述べるにとどまり、すべての操作が監査ログに落ちるかまでは明記していない。監査要件が厳しい組織は、この経路の扱いを先に確認したほうがよい。

Splunk と ELK を同じ検索面に寄せる構成

データソース側は、README によれば Splunk と ELK の設定に対応し、統一されたログ検索と Webhook によるアラート取り込みを提供する。LLM、エージェント、アナリストが同一のセキュリティコンテキストを見る、というのが謳われている狙いである。SIEM を一本化できない組織にとって、検索の入口を一つに寄せられるのは実務上の利点になる。

一方で、この構成は ASP がログの二次的な検索面になることを意味する。Splunk 側のサーチと ASP 側の検索で結果が食い違えば、どちらを正とするかの判断が必要になる。README は統一検索の中身、つまりクエリの変換方法やフィールドの正規化については説明していない。SIEM ごとにフィールド名が異なる環境では、その吸収をモジュール側で行うのか、ASP のコアで行うのかで移植コストが変わる。ここは導入前に実データで確かめるべき部分である。

Python Modules と Playbook に寄せた拡張の設計

拡張の入口は二つに分かれている。新しい SIEM ルールやアラートソースへの適応は Python Modules で行い、LLM 分析と自動アクションの連携は Playbook で組む。README はこれを「Low-Cost Adaptation, Highly Flexible Customization」と表現している。バックエンドとフロントエンド、拡張スクリプトは Python と TypeScript で書かれており、内容を追える状態に保つことが意図されている。

拡張点が Python に寄っているのは、既存の検知資産が Python で書かれているチームには有利に働く。逆に、SOAR のノーコードな Playbook エディタに慣れた運用チームには、コードを書く前提が負担になる。README はモジュールのサンプルコードを本文に載せていないので、実際にどの程度の記述量で新しいアラートソースを追加できるかは、リポジトリ内のモジュール実装を読んで判断するしかない。ここは公式サイトの Quick Start より、ソースツリーのほうが情報量が多いはずである。

ナレッジ蓄積と、そこで生じる検証の問題

README は、クローズした Case の調査記録、対応プロセス、議論から再利用可能なナレッジを抽出し、対応のたびに組織の経験が積み上がると説明している。過去の類似案件を引き当てられるなら、一次判断のばらつきは小さくなる。

ただし LLM が抽出したナレッジをそのまま次の判断に使う運用には、検証の手当てが要る。誤った結論が Case に記録され、それがナレッジとして再利用されると、誤りが増幅する。README はナレッジ抽出の精度や、抽出結果を人が承認するフローについて触れていない。Collaboration, Audit, and Access Control の節でユーザーロールと監査ログに言及があるため、承認を役割で縛ることは可能と読めるが、ナレッジのレビュー工程が標準で用意されているかは不明である。ここは運用設計で埋める部分であり、ツールが解決する部分ではない。

導入時に確認するコマンドと設定の在りか

導入手順の一次情報は README ではなく公式サイトにある。README の冒頭は Quick Start、Learn More、Workspace Features の三つのリンクを提示しており、デプロイ手順は https://asp.viperrtp.com/asp/quick-start/deployment/ に置かれている。README 本文にはインストールコマンドも docker compose の記述も含まれていないため、この記事の材料だけでは具体的な起動コマンドを示せない。ここは推測で埋めず、公式サイトの該当ページを直接参照されたい。

設定項目として README から読み取れるのは、Splunk と ELK の接続設定、Webhook によるアラート取り込み、ローカルまたは LDAP によるログイン、ユーザーロール、API Keys、Inbox 通知、Audit Log の存在である。認証を LDAP に向けられる点は、既存のディレクトリ運用がある組織にとって導入の障壁を下げる。API Keys が用意されていることは、Harness Agent 側から CLI 経由で叩く経路と整合する。

デプロイ形態は完全なローカル配置が可能と README は述べており、セキュリティデータをネットワーク内に留められる。ただし LLM 推論をどこで動かすかは README の範囲では明示されていない。外部の LLM API を呼ぶ構成なら、データがネットワーク外に出る経路が生じる。ここは構成次第で結論が変わるため、実際の設定ファイルで確認する必要がある。

向かない場面と、代替となる考え方

このプラットフォームが力を発揮しないのは、そもそもアラート量が処理能力を超えていない組織である。一日に数件の検知しか出ない環境では、Case への集約も LLM 調査も、得られる削減効果より構築と維持の手間が上回る可能性が高い。検知ルール自体が未整備な段階では、まず SIEM 側のチューニングが先になる。

もう一つの失敗モードは、LLM 推論のコストと遅延である。README は調査を「Seconds Not Hours」と表現するが、これは推論環境が整っている場合の話で、モデルの選択やホスティング方法によって待ち時間は大きく変わる。すべての Case に LLM 調査を自動で走らせる設計にすると、誤検知一件ごとに推論コストが発生する。優先度の高い Case だけに絞るなどの制御が要る。

代替としては、Dify や LangGraph を使って調査フローだけを自前で組む方向が現実的である。ASP が Case 管理、権限、監査、SIEM 接続まで含むのに対し、これらはエージェントの実行基盤に特化しており、SOC 固有のデータモデルは自分で設計することになる。アラートの集約と権限管理を既製品に任せたいなら ASP、調査ロジックの試行錯誤を素早く回したいなら LangGraph 側、という住み分けになる。ASP 自身もトピックとして dify と langchain、langgraph を挙げており、これらを置き換えるというよりは、その上に SOC の運用面を載せる位置づけと読める。

編集部の結論

導入を検討すべきなのは、Splunk や ELK にアラートが溜まり、一次切り分けを人手で回しきれず、かつ LLM の推論環境を自前で用意できるチームである。逆に、アラート量が少ない、あるいは検知ルールそのものが未整備の組織には向かない。最初に確認すべきは README が挙げる Python Modules の実装例と Playbook の記法で、自組織の SIEM ルールをどれだけの工数で移植できるかを先に見積もる。ライセンスは README に MIT とあるがリポジトリのメタデータでは不明と記録されているため、LICENSE ファイルの実在を確認してから社内申請に進むこと。

公式情報源

1. FunnyWolf/agentic-soc-platform on GitHub
2. Issues
3. Project website
4. README
5. Releases