AI SOC Agent と SIEM ルール：それぞれの役割
SIEMルールは決定的な検知を、AI SOC Agentはコンテキスト収集と調査を担います。それぞれの役割の違いと現場での使い分けを整理します。
AI SOC Agent と SIEM ルール：それぞれの役割
SIEM ルールと AI SOC Agent は別の問題を解決します。ルールは決定的な検知を行い、agent はコンテキスト収集、調査、次の手順の説明を支援します。
再現可能な検知にはルール
条件が明確な impossible travel、無効化アカウントのログイン、異常な親プロセスなどは、テストと監査がしやすいルールが適しています。
コンテキストと調査には agent
アラート発生後、関連イベントの検索、資産と ID の照合、レビュー可能なクエリへの変換、根拠付き要約の下書きを支援します。
実務での境界
明確に書ける検知を agent に置き換えず、複数データソースの説明をルールに任せないことです。アナリストが証拠を確認できる workflow で接続します。
モデルだけに「悪意あり」の判定を任せてはいけない理由
ルールは関数です。同じイベントなら同じアラートが出るので、ルールを変えるたびに先月のログでリプレイ検証でき、バージョン管理でき、発報の理由も説明できます。モデルの判定はプロンプト、コンテキスト、モデルのバージョンにも左右され、同じインシデントでも実行ごとに結論が変わりえます。モデルだけで判定すると、見逃したときに調べる手がかりが残りません。一致しなかったルールはなく、もっともらしい文章が残るだけです。
agent にはもう一つ問題があります。SIEM に届くフィールドには、攻撃者が中身を決められるテキストが数多くあります。User-Agent、URL、ファイル名、コマンドライン、メールの件名、ログイン画面に入力されたユーザー名などです。OWASP は、モデルが Web サイトやファイルなど外部の入力を取り込み、その内容がモデルの挙動を変えうることを間接プロンプトインジェクションと説明しています。定義が挙げるのは Web サイトとファイルなので、ログのフィールドへの当てはめはこの記事の推論です。ルールはこれらのフィールドをデータとして照合し、agent は文章として読みます。
実例：ログオン失敗が続いたあとの成功
Microsoft の資料では、イベント ID 4625 はログオンに失敗するたびに記録され、4624 はログオンセッションが作られたときに生成されます。4625 の監視上の注意は、重要なアカウントやサービスアカウントについてステータス 0xC000006A（パスワード誤り）を挙げています。
検知は、リプレイして検証できる形で書くのが推奨パターンです。以下は疑似ロジックで、zcrSIEM の記法ではありません。
A: count of 4625 (status or sub status 0xC000006A)
by (target account, source address) >= N within T
B: distinct target accounts in 4625 by source address >= M within T
C: (A or B), then a 4624 for a targeted account within T2,
from the same source address when 4624 has one -> alert
N、M、T、T2 は自社のベースラインから決めるお客様側の設定です。A と B が読むのは 4625 だけです。Microsoft は 4771（Kerberos 事前認証の失敗。ドメインコントローラーのみ）と 4776（NTLM の資格情報検証。検証を担当するコンピューターが記録）も記載しています。環境で生成される失敗イベントも加えてください。
C が発報したあと、agent の仕事は範囲が決まっています。そのアカウントの前後のログオンを集め、各文がイベント ID を引用する要約を下書きします。成功したログオンが本人のものか、封じ込めが妥当かは、アナリストが判断します。
送信元アドレスでの結合には注意が必要です。Microsoft の説明では、4624 の NTLM ログオンには TCP/IP の情報がありません。送信元がなければ C はアカウントだけを根拠に一致するため、agent はその旨を報告し、推測で埋めません。
作業ごとの分担：誰が何を持つか
| SOC の作業 | SIEM のルール・クエリの持ち分 | AI agent が支援できること | 人に残すこと | 役割を入れ替えた場合の失敗 |
|---|
| 既知の挙動の検知とチューニング | バージョン管理したルール、担当者と期限つきの例外 | ルール案の下書き、例外が隠すアラートの一覧化 | ルールと各例外の承認 | 実行のたびに判定が変わり、見逃しても調べるルールがない |
| アラートをインシデントにまとめる | 共通のホスト・ユーザー・IP と順序による相関 | インシデントの読み込み、結合できなかった点の報告 | どのアカウント、ホスト、日付を含めるかの確認 | 名前が似ているだけで結びつく。本当の関連が黙って抜ける |
| 対応キューの優先順位づけ | 明示した要素から計算し、要素を併記するリスクスコア（重大度、確信度、資産の重要度、権限、ATT&CK） | それらの項目を引用して順位の理由を説明 | 順序の上書きとエスカレーションの責任 | 再現できない、もっともらしい順位づけ |
| 封じ込め（アカウント無効化、ホスト隔離） | SIEM ではない（zcrSIEM に SOAR はない）。Autonomous、Approval、Blocked を設定した zcrSOAR の playbook ステップが持つ | 根拠つきで手順を提案 | zcrSOAR の Approval ステップで承認 | 自由形式のツール呼び出しが誤った対象に届き、承認の記録もない |
この分担は推奨パターンで、zcrSIEM の画面の説明ではありません。zcrSIEM のドキュメントにあるのは、定義済み・カスタム・Sigma ベースのルール、リスクスコアリングを備えた UEBA、相関によるインシデント化、AI 要約、自然言語の質問をレビュー可能なクエリに変換する機能です。ルールのバージョン管理、例外の担当者と期限、ルール案の下書き、各文へのイベント ID の引用、過去ログでのルールのリプレイは、お客様側の運用で行うことで、zcrSIEM の機能として記載されているものではありません。最終行は zcrSOAR の役割で、実行ごとに記録を残します。どのステップで承認を求め、誰が承認できるかはお客様側の設定です。
限界、失敗のパターン、エスカレーションの条件
ルールは、届いていないものには反応できません。パーサーの変更やログソースの停止でルールが一致しなくなると、画面は静かになります。モデルも「何もないこと」には気づけないため、ログソースの健全性は検知と別に監視してください。また、ルールが発報したアラートを agent に閉じさせたり抑制させたりしてはいけません。そうして生じた見逃しは誰にも見えないからです。抑制は、担当者と期限つきの例外として明示します。
次のいずれかなら、agent を止めて人に引き継ぎます。要約に生イベントにない記述がある、引用したイベント ID がインシデントにない、特権アカウントやドメインコントローラーが関わる、または agent が封じ込めを提案する場合です。封じ込めは、推奨パターンとして、Approval に設定した zcrSOAR のステップに渡します。
よくある質問
AI SOC Agent は SIEM の検知ルールを置き換えられますか？
置き換えられません。検知は再現とテストができる必要があり、ルールはそれを満たします。agent は、ルールが発報済みのイベントに文脈、要約、クエリの下書きを加える使い方が向いています。agent が下書きしたルール案は、本番適用の前に人がレビューし、過去ログでリプレイして検証します。
zcrSIEM に SOAR がないなら、自動対応はどこで動きますか？
zcrSOAR です。zcrSIEM がなくても利用できます。Autonomous のステップはすぐに実行され、Approval のステップは役割に応じた承認者の承認を待ち、Blocked のステップは設定を変更するまで実行されません。
agent の出力はどう検証し、ログが agent を操ろうとしたらどうしますか？
要約の各文がインシデントに実在するイベント ID を引用しているかを確認し、アナリストが抜き取りで読みます。下書きをアナリストが修正・却下した頻度も記録してください。これは観測できる行動で、別のモデルがつけた点数とは違います。操られた場合の被害を抑えるには、フィールドを信頼できないデータとして扱い、承認なしに状態を変えるツールを持たせず、検知はルール側に置いて、悪意の有無の判断はアナリストが行うのが推奨パターンです。
出典
続き: Human-in-the-Loop SOC、AI Agent で証拠を隠さず Alert Fatigue を減らす方法、AI SOC Agent ガイド
zcrSIEM を見る · 料金を見る · zcr に相談
自社の環境についてのご相談は、こちらへどうぞ。
