実運用で必要になる7つの設計ポイント
深夜2時。SOC担当者が一人で当番をしています。
SIEMのダッシュボードには、数百件の未処理アラート。
その多くは、
- 同じ送信元からのポートスキャン
- 短時間に繰り返されたログイン失敗
- 類似したファイアウォールイベント
といった、似たようなアラートの繰り返しです。
翌朝、
「昨日のアラート、結局どうだった？」
と聞かれても、すべてを確認できているとは限りません。
SIEMは大量のログから異常候補を検出するのは得意です。
一方で、
- どれから確認すべきか
- 複数のアラートが同じ事象なのか
- 本当に対応が必要なのか
- 次に何をすべきなのか
という判断は、人間側に残ります。
そこで自然に出てくるのが、
「SIEMの出力をAIに解釈させればいいのでは？」
という考え方です。
方向性としては合理的です。
ただし、実際に運用できるシステムとして考えると、
SIEMのアラートをそのままLLMへ渡すだけでは不十分です。
この記事では、その理由を7つに整理し、実運用向けのAIレイヤーをどう設計すべきかを考えます。
まず結論：重要なのはLLMの前後
SIEMの上にAIを載せる場合、重要なのはLLMそのものだけではありません。
実運用では、次のような処理が必要になります。
大きく分けると、
前処理 → コンテキスト付与 → LLM分析 → 検証 → アクション
という流れです。
つまり、
「SIEM → LLM」ではなく、「SIEM → データ処理 → LLM → 検証 → 実行」
として設計する必要があります。
ここから、それぞれの理由を見ていきます。
1. アラートをまたいだコンテキストが必要
単発のアラートだけなら、LLMでもかなり自然な説明ができます。
例えば、
User A logged in from IP 203.0.113.10 at 02:14
というイベントを渡せば、
深夜帯のログインであるため、不審なアクセスの可能性があります。
といった説明はできます。
しかし、本当に知りたいのは、
「このユーザーにとって、このログインは異常なのか？」
です。
例えば、過去30日間を確認した結果、
- 同じIPから何度もログインしている
- 普段から深夜帯に利用している
- 同じ端末を利用している
のであれば、今回のログインは正常かもしれません。
逆に、
- このIPは初観測
- 過去30日間に深夜ログインがない
- 直前に15回の認証失敗がある
のであれば、優先度を上げるべきでしょう。
必要なのは「LLMの記憶」ではない
ここで重要なのは、LLM自身にすべてを覚えさせることではありません。
ユーザー、IP、ホストなどのエンティティ単位で履歴を保持し、アラート分析時に必要な情報だけ取得して渡します。
例えばユーザーであれば、
- 過去のログイン
- 利用IP
- 利用端末
- 過去のアラート
- 過去のケース
といった履歴です。
LLMの外側に状態管理の仕組みを持つことがポイントになります。
2. 生ログをそのままLLMへ渡してはいけない
セキュリティログでは、1つの事象から大量のイベントが発生します。
例えばポートスキャンです。
数分間に、
02:13:04 DROP 203.0.113.5 → 10.0.0.10:21
02:13:04 DROP 203.0.113.5 → 10.0.0.10:22
02:13:04 DROP 203.0.113.5 → 10.0.0.10:23
...
というログが4,812件出たとします。
しかし、
4,812件のログ = 4,812件の脅威
ではありません。
実際には、
1つの送信元が、数分間で多数のポートをスキャンした
という1件の事象です。
そのため、LLMへ渡す前にログを圧縮します。
例えば、4,812件のログから次のようなケース情報を作ります。
{
"event_type": "port_scan",
"source_ip": "203.0.113.5",
"target_host": "10.0.0.10",
"first_seen": "02:13:04",
"last_seen": "02:17:51",
"event_count": 4812,
"unique_ports": 126,
"blocked_count": 4812,
"allowed_count": 0
}
LLMに読ませるのは4,812行のログではなく、このケース情報です。
そのため前処理では、
- 正規化
- 重複排除
- 時間窓による集約
- エンティティ単位の集約
- イベント種別によるグルーピング
などを行います。
これだけでも、トークン消費とノイズを大幅に減らせます。
3. 自由生成させたくない情報がある
LLMは文章生成には向いています。
しかし、すべての判断を自由回答にすると危険です。
特に注意したいのが、
コンプライアンスやセキュリティ統制へのマッピング
です。
例えば、
このインシデントはどの統制に該当するか？
と聞いた場合、自由生成だけに任せると、
- 存在しない統制番号
- 関係の薄い統制
- 根拠のない分類
が返る可能性があります。
監査資料に利用するのであれば、これは問題になります。
「生成」ではなく「分類」として使う
例えば、あらかじめ利用可能な統制を定義します。
{
"allowed_controls": [
"control_A",
"control_B",
"control_C"
]
}
LLMには、この候補の中から選択させます。
さらに出力後、
- その統制が本当に存在するか
- 許可された値か
- 必須項目が欠けていないか
をプログラム側で検証します。
つまり、
LLMが答えを作る → そのまま採用
ではなく、
LLMが候補を出す → システム側で検証
という流れにします。
4. アラートではなく「ケース」で考える
SOCで重要なのは、個別のアラートを見ることだけではありません。
複数のアラートをまとめて、
「1つの攻撃シナリオではないか？」
と考えることです。
例えば、次の6件が発生したとします。
- 02:01 Failed Login
- 02:02 Failed Login
- 02:03 Failed Login
- 02:04 Successful Login
- 02:05 Unusual IP
- 02:06 Privileged Action
1件ずつ処理すると、6件の別々のアラートです。
しかし時系列で見ると、
Brute Force → Successful Login → Suspicious Session → Privileged Action
という1つのシナリオに見えます。
そのため、
AIへ渡す前にケース化する
ことが重要です。
相関には例えば、
- 時間
- ユーザー
- IPアドレス
- ホスト
- イベント種別
といった軸を使います。
アラートを1件ずつLLMへ送るのではなく、
関連するアラートをまとめた後で、ケース単位で分析させる
方が全体像を捉えやすくなります。
5. 「異常」は組織によって違う
例えば、
深夜2時のログイン
は異常でしょうか。
一般的なオフィス勤務の会社なら怪しいかもしれません。
しかし、
- 24時間運用している
- 海外拠点がある
- 夜勤がある
- 海外時間で働くチームがある
のであれば、正常な可能性もあります。
つまり、
一般的なセキュリティ知識だけでは判断できません。
必要なのは、
- 一般的な脅威知識
- 組織固有のベースライン
- エンティティの過去履歴
- 現在発生しているイベント
を組み合わせることです。
ベースラインの例
ユーザーであれば、
- 通常のログイン時間
- 普段利用する国
- 普段利用するIP
- 利用端末
- 利用アプリケーション
などを持てます。
ホストであれば、
- 通常の通信先
- 普段利用するポート
- 通信量
- 通常実行されるプロセス
などです。
ここで重要なのは、
ベースラインをプロンプトに固定で書かないこと
です。
継続的に更新されるデータとして保持し、必要なときだけ取得します。
6. AIの説明と監査証跡は別物
LLMが、
同一IPから短時間に多数のポートへの接続が試みられています。すべてファイアウォールで遮断されているため、現時点では侵害の兆候は確認されていません。
と説明してくれれば、人間には分かりやすいです。
しかし、監査で必要になるのは文章だけではありません。
例えば、
- case_id
- created_at
- source_events
- rule_version
- model_version
- prompt_version
- decision
- reviewer
- actions
といった情報も必要になります。
つまり、
人間向けの説明
と、
機械的に追跡できる証跡
を分けて保存する必要があります。
特にAIを使う場合、
どの入力に対して、どのモデル・ルールを使い、どの結果が出たのか
を後から追えるようにしておくことが重要です。
7. 「提案」で終わると運用負荷はあまり減らない
AIが、
このユーザーのセッションを無効化してください。
と提案したとします。
しかし、その後にSOC担当者が、
- ID管理画面を開く
- ユーザーを検索する
- セッションを確認する
- 無効化する
- チケットを更新する
必要があるのであれば、まだかなりの作業が残っています。
そのため最終的には、
分析結果をアクションまで接続する
必要があります。
例えばLLMから次のような構造化データを受け取ります。
{
"action": "disable_session",
"target_user": "user@example.com",
"reason": "suspected account compromise",
"requires_approval": true
}
ただし、LLMから直接APIを実行させるのは危険です。
その間に、
- ポリシーチェック
- 対象の検証
- 人間による承認
- 権限制御
- 実行結果の確認
を挟みます。
つまり、
AIに強い権限を持たせるのではなく、AIには構造化されたアクション候補を出させる
という設計です。
AIに任せる処理と、任せない処理
ここまでを見ると、「全部AIで処理すればいい」という話ではないことが分かります。
むしろ重要なのは、
AIに任せる処理と、通常のプログラムに任せる処理を分けること
です。
通常のプログラムに任せたい処理
例えば、
- timestampの正規化
- IPアドレスの解析
- 重複排除
- 時間窓によるグルーピング
- allowlistとの照合
- 統制IDの検証
- threshold判定
などです。
これらは決定論的に処理できます。
わざわざLLMへ任せる必要はありません。
LLMが向いている処理
一方で、
- 複数イベントの意味を説明する
- ケースを要約する
- 調査ポイントを整理する
- 異なるログソース間の意味的な関連を説明する
- SOC担当者向けの文章に変換する
といった処理はLLMが得意です。
シンプルに分けると、
通常のソフトウェア：正確さ・再現性
LLM：意味解釈・要約・説明
という役割分担になります。
実運用で見るべきポイント
「SIEM + AI」のシステムを評価するときは、単に、
どのLLMを使っているか？
だけを見るのでは不十分です。
それよりも、
LLMへ渡す前
- 生ログをそのまま送っていないか
- 重複排除されているか
- ケース化されているか
- 過去履歴が付与されているか
LLMの出力後
- 出力を検証しているか
- 利用可能な値を制限しているか
- 監査ログが残るか
- モデルやプロンプトのバージョンを追えるか
アクション実行
- 承認フローがあるか
- AIから直接強い権限を実行していないか
- 実行結果まで追跡できるか
といった部分を見る方が、実際の運用品質を判断しやすくなります。
まとめ
「SIEMの上にAIを載せる」という考え方は、SOC運用を改善する有力なアプローチだと思います。
ただし、
SIEMのアラートをそのままLLMへ送る
だけでは、実運用に必要な要件を満たせません。
特に必要になるのは、
- エンティティ単位のコンテキスト保持
- 生ログの正規化と集約
- アラート間の相関
- ケース単位での分析
- 組織固有のベースライン
- 制約付きの出力
- 再現可能な監査ログ
- 実行系APIへの安全な接続
です。
実運用で差が出るのは、
どのLLMを使うかだけではありません。
それ以上に重要なのは、
何をLLMへ渡すのか
何をLLMには任せないのか
生成結果をどう検証するのか
その結果をどう実行につなげるのか
という設計です。
「SIEM + AI」を検討する際は、モデル単体の性能ではなく、
前処理・相関・状態管理・検証・アクション実行まで含めたパイプライン全体
を見ることが重要だと考えています。
※筆者は、本記事で扱った考え方を利用したセキュリティ関連システムの開発に携わっています。本記事では特定製品の紹介ではなく、開発・検証の過程で得られた設計上の知見を一般化してまとめています。