UEBAで異常を見つけた後、AI Assistantで調査から報告までを支援する
朝のアラート。「これ、大丈夫？」にどう答える？
朝、セキュリティアラートを確認すると、気になるアクセスの兆候が見つかりました。上司からは「不正アクセスなの？ 影響は？」と聞かれます。ところが、手元にあるのはログとアラートだけ。何を確認すべきか、急いで対応すべきか、どう報告するか。少人数の情シスでは、ほかの業務を進めながら判断材料をそろえなければなりません。
第1弾では、UEBA（User and Entity Behavior Analytics）で「いつもと違う」行動に気づく考え方を紹介しました。第2弾のテーマは、その後です。Energy Logserver（以下 ELS）のAI Assistantを使って、ログを読み解き、次に確認することを整理し、社内に伝えるまでの作業をどう支援できるのかを見ていきます。
| 第1弾：UEBA | 第2弾：AI Assistant | 第3弾：SOAR |
| 異常の兆候を見つける | ログを読み解き、調査と報告を整理する | 対応手順・状況管理を標準化する |
ここからは、異常を検知した後の調査業務を具体的に考えるため、検証環境で発生させたWindowsのログオン失敗（イベントID 4625）を例にします。これは第1弾のUEBAアラートから取得したログではなく、検知後に関連ログを調査する場面を想定した別の検証例です。
AI Assistantは「判断の代行」ではなく「調査の整理役」
ELSのDiscoverでは、対象ログを展開し、AssistantタブからLLMを利用した分析を実行できます。標準のExplain Log、MITRE、Priority、Recommendationなどは、ログの概要や調査の観点を整理する入口になります。
実機でイベントID 4625をExplain Logにかけると、ログオン失敗の概要と認証関連フィールドが文章や表で示されました。MITREの分析ではPassword Guessing（T1110.001）との関連が提示され、PriorityではSeverityがMedium、PriorityがP4（Low）と評価されました。これらはAIの分析結果であり、攻撃の発生や優先度を確定するものではありません。
AIの回答は、必ず元ログと照合します。単一のログから攻撃の有無や前後の認証状況を断定することはできません。
日本語の独自ボタンで「毎回同じ調査」を始めやすくする
ここで役立つのが、現場の調査手順に合わせた日本語の独自プロンプトと実行ボタンです。例えば「ログを日本語で解説」「次に確認すべき項目」「緊急度判定」「上司向け3行要約」。Discoverで選択したログを起点に、毎回ログをコピーして質問文を一から考える手間を減らし、同じ観点で調査・報告を進めやすくします。AIに任せるのは整理と下書きまで。元ログの確認と最終判断は担当者が行います。
以下では、このログオン失敗を調べ、上司へ一次報告するまでの流れを追います。日本語プロンプトは業務に合わせた設定例です。掲載するAI出力は検証環境で取得した結果を基にしており、識別情報を匿名化しています。実際の運用では設定と出力内容の確認が必要です。
実践① ログを日本語で解説 — まず事実をつかむ
まず、発生時刻・対象アカウント・端末・失敗理由を日本語で整理します。ログの読み解きにかかる手間を減らし、調査の出発点をそろえられます。
| ボタン名 | 登録するプロンプト例 |
| ログを日本語で解説 | 選択したログの事象・日時・対象・失敗理由を日本語で整理し、不明点を明記してください。 |
AIの解説でログの概要をつかんだら、元ログと照合して次の調査へ進みます。
単一の認証失敗だけで攻撃とは判断しません。
実践② 次に確認すべき項目 — 調査の抜け漏れを抑える
次に調べるべき関連ログや確認観点をAIが一覧化します。担当者が毎回チェック項目を考える負担を減らし、調査の抜け漏れ防止に役立ちます。
| ボタン名 | 登録するプロンプト例 |
| 次に確認すべき項目 | 追加で確認すべき認証ログや関連情報を、目的とともに優先順で示してください。未確認の事実は断定しないでください。 |
例えば成功イベント4624の確認が提案されても、存在が確認されたわけではありません。実際の検索と照合は担当者が行います。
図4-1 次に確認すべき項目（実機AI出力・識別情報を匿名化）
実践③ 緊急度判定 —「高・中・低」の根拠を明確に
AIに暫定的な優先度とその根拠、不足情報を整理させます。「今すぐ対応すべきか」という相談に対し、確認事項を明確にして判断しやすくします。最終判断は担当者が行います。
| ボタン名 | 登録するプロンプト例 |
| 緊急度判定 | 確認済みの事実に基づき、暫定優先度・根拠・不足情報・次の対応を示してください。判断できなければ保留としてください。 |
図4-2：緊急度判定（実機AI出力・識別情報を匿名化）
ここでのAIの役割は判断材料を並べることです。重大度の最終判断やエスカレーションは、社内の基準と確認済みの証拠に基づいて担当者が行います。
調査で分かったことを、上司とSOCに「伝わる形」で渡す
同じ調査結果でも、伝える相手によって必要な情報は異なります。上司には「何が起き、影響は確認できているか、次に何をするか」を簡潔に。SOCや引継ぎ担当者には、確認済みの証拠と未確認事項を具体的に残します。日本語ボタンを使えば、報告形式を毎回考え直す負担を抑えられます。
| 用途 | 日本語ボタンの例と出力内容 |
| 上司への一次報告 | 上司向け3行要約：①事象 ②影響の可能性 ③次の対応を各1行でまとめる。未確認は未確認と記す |
| SOCへの引き継ぎ | SOC引継ぎメモ作成：対象、時刻、確認済みのログ、未確認事項、次の調査を整理する |
| 記録の標準化 | インシデント報告書作成：発生日時、対象、調査結果、対応履歴、残課題の下書きを作る |
「例えば『上司向け3行要約』なら」
プロンプト例：「確認済みの事実だけを使い、事象・影響の確認状況・次の対応を上司向けに各1行でまとめてください。未確認事項は明記してください。」
例えば、確認済みの情報だけを使うと、次のように簡潔な一次報告をまとめられます。
| 項目 | 上司向けの表現例 |
| 事象 | Windows端末でログオン失敗イベントを確認しました。 |
| 影響 | 不正アクセスの有無と影響範囲は確認中です。 |
| 次の対応 | 同一アカウントの前後の認証ログを確認し、必要に応じて報告します。 |
図5：上司向け3行要約の出力例（識別情報を置き換えて掲載）
AI Assistantが選択中の1件のログを分析する場合、対応履歴や他システムの情報まで把握しているとは限りません。上司への報告や引継ぎメモに使う前に、担当者が調査済みの事実を補い、表現を確認します。
実務シナリオ：アラートを見つけてから一次報告するまで
朝、認証失敗のアラートを確認。まずAIの日本語解説で概要をつかみ、元ログの日時・アカウント・送信元・失敗理由を照合します。
次にAIが提示した確認項目を基に関連ログを検索し、結果を記録します。AIの提案は調査の道筋であり、検索済みの証拠ではありません。
確認結果を踏まえて緊急度の根拠を整理し、最後に上司向け3行要約を作成します。調査から報告までの定型作業を、同じ流れで進めやすくなります。
※上記は活用シナリオです。各ボタンの出力内容や所要時間の改善効果を実測した事例ではありません。
一般的な生成AIへの貼り付けと、何が違う？
一般的な生成AIでも、ログの説明や文章の下書きはできます。ELSで訴求したいのは「AIが文章を書けること」だけではありません。Discoverで選択したログを起点に、業務に合わせて登録したプロンプトを繰り返し実行できる点です。担当者が毎回ログをコピーして質問文を考える作業を減らし、同じ確認観点をチームで共有しやすくなります。
ただし、ボタンを押すだけで前後のログ検索やインシデントの確定判断まで自動的に完了するわけではありません。実際の検索、証拠の照合、対応判断は担当者が行います。また、LLMへの送信条件を確認したうえで利用する必要があります。
一人情シスでは、何が変わる？
| これまでの進め方 | AI Assistantを取り入れた進め方 |
| イベントIDやフィールドを一つずつ調べる | 日本語の説明を起点に、元ログで事実を確認する |
| 調査項目をその都度考える | 共通のチェック項目を出し、担当者が関連ログを調べる |
| 上司への報告文を毎回書き起こす | 3行要約の下書きを作り、確認後に共有する |
| 引継ぎ時に調査経緯を整理し直す | 事実・未確認事項・次の作業を定型形式でまとめる |
AI Assistantの価値は、ログの解説、調査項目の洗い出し、報告文の下書きを、選択したログから共通の手順で始められることです。判断や証拠の照合は担当者が行い、作業時間の短縮効果は実測していません。
導入前に押さえたい3つの注意点
第一に、AIの説明とログの事実を分けること。特に認証失敗の回数や攻撃手法は、関連ログを照合するまで確定しません。第二に、独自ボタンの利用条件やLLMの接続先を確認すること。AI Assistantでは、分析対象のログとプロンプトが設定されたLLMプロバイダーに送信されます。ユーザー名やIPアドレスなどを含むログについては、送信先やデータの取り扱いを事前に確認する必要があります。第三に、プロンプトは運用開始後も見直すこと。社内の緊急度基準や報告様式の変更に合わせて、登録したプロンプトも定期的に見直します。
最初から多くのボタンを作る必要はありません。例えば「次に確認すべき項目」を一つ用意し、同種のログで複数回試して、事実の取り違えがないか、必要な確認項目が漏れないかを評価するところから始められます。
まとめ：UEBAの「気づき」を、次の行動につなげる
UEBAは普段と異なる振る舞いを見つける入口です。その後、AI Assistantの日本語ボタンを使ってログを読み解き、次の調査項目や暫定的な緊急度を整理し、上司向けの報告文を下書きする。少人数の情シスでも、調査から報告までを共通の手順で進めやすくすることが、今回紹介した活用方法です。
ただし、ログの解釈と対応の決定は別です。次回の第3弾では、調査後に残る「誰が、どの手順で対応するか」という課題に注目し、ELSのPlaybookとインシデント管理を使ったSOARの考え方を紹介します。
ご不明な点がありましたら、お気軽にお問い合わせください。
参考資料
Energy Logserver 公式ドキュメント（ELS 8.1.0）：Discover / AI Assistant、SIEM Daily Operations
