AI SOC for Splunk|SPLを活かすAIアラート調査

既存のSplunkに、根拠を集めるAI調査を。

INVESTIGATION USE CASES

この製品で、何をどう調べるか

Splunkのアラート・ログを使った調査例です。確認する証拠と、担当者の判断につなげる情報をご紹介します。

Splunkのアラート製品APIで関連データを参照AI SOCの調査

連携状況:開発中・先行相談 · 3件の調査例

SplunkID・認証開発中・先行相談

認証失敗の後に成功したログインを調べる

01 検知・ログ
Splunkに保存した認証異常のアラート
02 AIの調査例
対象ユーザー・送信元・前後の時刻をSPLで検索し、失敗から成功までの経緯を確認。
03 判断材料
正規の再試行か、侵害の疑いとして追加確認するかの判断材料を整理。
調査業務を詳しく読む →
Splunk端末・プロセス開発中・先行相談

不審なPowerShell実行の前後を調べる

01 検知・ログ
Splunkに保存したスクリプト実行のアラート
02 AIの調査例
ホスト・ユーザー・時刻を起点に、収集済みのプロセス記録をSPLで確認。
03 判断材料
管理作業との整合性、追加で必要な端末調査を整理。
Splunk通信・DNS開発中・先行相談

不審な外部通信の繰り返しを調べる

01 検知・ログ
Splunkに保存した通信先・通信頻度のアラート
02 AIの調査例
対象IP・ドメイン・期間でネットワークログを絞り、通信元と継続性を確認。
03 判断材料
影響を調べる端末と、通信の許可・拒否を確認する範囲を整理。

連携製品一覧に戻る

開発中・先行相談受付中

Splunkで検知したアラートを、対応判断に使える情報へ。ヤグラは、既存のSplunkに保存したアラートを取得し、AIがSPLで関連イベントを追加検索する連携を開発しています。現在の索引と検知ルールを活かしながら、一次調査の進め方を整える構成です。

Splunk環境でのAI SOC導入を相談する

Splunkを活かして、アラートの次の調査へ

「検知ルールは整備できたが、通知後にログを調べる時間が足りない」「SPLに詳しい担当者へ調査が集中する」。こうした運用を想定しています。

アラートには、異常を検知した条件が記録されています。一方で、対象ユーザーの前後の操作、同じ端末からの接続、影響を受けた資産まで分かるとは限りません。AI SOCでは、取得したアラートを出発点に検索対象と期間を絞り、関連イベントを調べます。担当者は証拠と未確認事項を見て、追加調査や対応の必要性を判断します。

連携の流れ

Splunkのアラート索引 → ヤグラ AI SOC → SPLによる追加検索 → 証拠の整理 → 担当者による対応判断

Splunk側では既存のログ収集と検索を継続します。本連携はアラート取得と必要なイベントの照会を目的としており、ログ全量をヤグラへ継続転送する構成ではありません。

1. アラートを調査の入口にする

取得対象の索引と検索式を指定します。開発中の連携では、初期値として search index=notable を用意しています。実際のアラート保存先に合わせて変更する構成です。

2. SPLで関連イベントを確認する

アラート内のユーザー、端末、IPアドレス、時刻を手がかりに、権限のある索引を検索します。取得できる情報は、Splunkに保存されたデータと接続ユーザーの検索権限によって変わります。

3. 判断の根拠をそろえる

関連イベントと時系列を整理します。検索結果が得られなかった場合も、対象期間・権限・保持期間を確認し、情報不足のまま安全と結論づけない運用を設計します。

調査例:認証アラートから、その後の操作を追う

以下は提供開始後の活用を想定した例です。対象ログが索引に保存され、必要なフィールドで検索できることが前提です。

  1. アラートから、認証失敗が発生したユーザー、接続元、時間帯を確認します。

  2. 同じユーザーの成功ログインをSPLで検索し、失敗の直後に認証が成功していないか調べます。

  3. 関連する操作ログがある場合は、権限変更や管理操作を別の検索で確認します。

  4. 確認できたイベントを時系列で整理し、本人確認やアカウント対応の要否を担当者が判断します。

評価では「検索できたか」に加え、「判断に必要なイベントへたどり着けたか」を確認します。検索漏れ、フィールド名の違い、取り込み遅延も検証対象です。

Splunk標準機能・SOAR・外部SOCとの併用

検知、通知、検索、既存の自動化をどこまでSplunk側で担っているかを確認し、その後に人が行っている調査を切り出します。Splunk Enterprise Securityの運用やSOARのプレイブックがある場合も、アラートの所有者、調査結果の確認者、対処の実行者を決めて併用を検討します。

既存機能だけで十分に対応できている業務は、そのまま活用します。AI SOCを評価する対象は、追加検索、根拠整理、引き継ぎなど、現在負担になっている工程です。

導入前に確認すること

  • Splunk Enterprise / Splunk Cloudの利用形態、アラートの保存先、検索対象の索引。

  • 管理APIの接続先と許可ネットワーク。Splunk Cloudでは管理APIの利用条件も確認します。

  • 検索専用のトークンまたは認証情報と、対象索引への読み取り権限。

  • データの保持期間、取り込み遅延、検索負荷、既存の検索ジョブとの兼ね合い。

  • 調査結果を確認する担当者と、エスカレーション先。

PoCで確かめる4つの項目

取得の一致:選んだアラートが取得され、元のID・時刻・対象と一致するか。

調査の質:必要な索引を検索し、判断に必要な証拠がそろうか。取得できない情報も明確になるか。

運用負荷:同じ評価対象について、現在の手作業とAI SOCを利用した場合の確認時間・修正回数を比較します。

業務への接続:誰が内容を確認し、既存SOCや社内担当者へ何を引き継ぐかを確かめます。削減率や所要時間は、実環境での評価後に判断します。

よくある質問

Splunk Enterprise Securityは必須ですか?

開発中の構成では、ES以外でもアラートが検索可能な形で保存されていれば取得対象にできます。保存形式と検索式を個別に確認します。

Splunkのログをすべて移す必要はありますか?

本連携ではアラート取得と追加検索を行います。ログ全量の継続転送は、この連携の対象に含まれません。

自動で設定変更や端末隔離まで行いますか?

ここで説明しているSplunk連携は読み取りと検索が対象です。対処は既存の権限・承認フローを確認し、別途設計します。

いつから利用できますか?

現在は開発中です。対象環境、必要な検索範囲、導入希望時期を伺い、提供時期と検証方法をご案内します。

Splunkの運用に合うAI調査を、一緒に具体化する

Splunkの利用形態、代表的なアラート、調査に時間がかかる工程をお知らせください。取得する情報と評価対象を整理します。

Splunk連携の先行相談をする

技術仕様の参考

SplunkのREST APIによる検索結果の取得については、Splunk公式ドキュメントをご参照ください。ベンダーAPIの仕様と、上記のヤグラ連携の提供範囲は分けてご確認ください。

関連するAI SOC連携

ヤグラ AI SOC · AI SOCとは

更新:2026年9月12日