AI SOC for Microsoft Sentinel｜KQLを活かすAI調査

連携製品一覧に戻る

開発中・先行相談受付中

Microsoft SentinelのSecurityAlertを取り込み、Log Analyticsの関連イベントをKQLで調べる連携を開発しています。既存ワークスペースに蓄積した情報を活用し、アラートの確認から証拠をそろえる工程を支援する構成です。

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

ワークスペースにある情報を、アラート調査に使う

Sentinelの運用では、アラートを確認した後に、対象ユーザーや端末の前後のイベントをKQLで調べる場面があります。必要なテーブルと期間を選び、得られた結果を整理する作業をAI SOCの評価対象にします。

連携では、対象ワークスペースと調査するテーブルを明確にします。AIが検索結果を参照し、担当者が判断に必要な証拠と、まだ確認できていない範囲を把握できる運用を目指します。

連携の流れ

SentinelのSecurityAlert → ヤグラ AI SOC → 指定テーブルをKQLで検索 → 関連イベントの整理 → 担当者による判断

SecurityAlertを取得する

Log Analyticsワークスペースのアラートを調査の入口にします。接続テストではSecurityAlertを検索できることを確認する構成です。

対象テーブルを絞って追加調査する

アラート内のユーザー、端末、IPアドレス、時刻を手がかりに、指定テーブルを単位として検索します。APIの認証・権限だけでなく、対象のログが実際に格納されていることも必要です。

取得範囲を意識して証拠を整理する

現在開発中の追加調査は、単一テーブルごとに最大500行です。APIの失敗や不完全な応答を「0件」と扱わず、必要に応じて時間帯と検索条件を絞ります。

調査例：不審なサインインの前後を確認する

以下は提供開始後の活用例です。サインインログが対象ワークスペースにあり、必要なテーブルを調査対象として設定していることが前提です。

1. SecurityAlertから対象ユーザー、接続元、発生時刻を確認します。

2. サインインログのテーブルをKQLで検索し、同じユーザーの前後の認証結果や接続元を調べます。

3. 関連する操作ログも確認する場合は、対応するテーブルを別途検索します。

4. 結果を時系列で整理し、本人確認や追加調査の要否を担当者が判断します。

複数テーブルを一つのクエリで結合する構成ではありません。どのテーブルを確認したか、確認できなかった情報は何かも評価します。

Sentinel連携とMicrosoft Defender連携の違い

Sentinel連携は、Log AnalyticsワークスペースのSecurityAlertと、指定テーブルのKQL検索を対象とします。

Microsoft Defender連携は、Defenderのアラート・インシデント、Advanced Hunting、端末情報の参照を対象とします。同じKQLを使う場合でも、接続先、認証、対象テーブル、必要な契約は異なります。

両方を使う場合は、同じ事象が二重に調査されないよう、どちらのアラートを起点にするかを設計します。

既存の自動化・調査機能との併用

現在の分析ルール、既存の自動化、担当者による追加検索を確認します。そのうえで、AI SOCに任せる検索・証拠整理と、人が確認する判断を決めます。Sentinel側のインシデント更新やクローズまで、この参照連携に含まれるわけではありません。

PoCでは既存の運用手順と同じ対象を評価し、どの確認作業が減り、どこに追加確認が残るかを測ります。

接続条件と対応範囲

• Public AzureのLog Analytics APIが対象です。

• ワークスペースID、Entraテナント、アプリ認証、対象ワークスペースのログ読み取り権限が必要です。

• 調査対象テーブルと保持期間、ログの取り込み状態を確認します。

• 複数文、テーブル結合、外部ワークスペース・外部データへの照会は開発中の連携範囲に含まれません。

• テーブル一覧の自動取得は未対応です。検索が0件でも、そのテーブルと全範囲を確認できたことにはなりません。

これらはヤグラの連携範囲です。SentinelやLog Analytics自体が持つ機能の上限とは異なります。

PoCで確認すること

接続と取得：SecurityAlertが取得でき、元のアラートのID・時刻・対象と一致するか。

検索の妥当性：必要なテーブル、期間、対象識別子で検索できるか。行数上限や権限不足が結果にどう影響するか。

担当者の判断：結果の修正回数、未確認事項、対応判断までの時間を、現在の運用と同じ評価対象で比較します。

役割分担：既存のSentinel運用と重複せず、調査開始から完了確認まで担当が明確になるか。

よくある質問

Sentinelのインシデントをすべて同期しますか？

ここで説明している構成はSecurityAlertの取得とKQLによる追加調査です。インシデントの双方向同期や状態更新を含む説明ではありません。

複数ワークスペースを横断できますか？

開発中の構成では接続先ワークスペースを指定します。外部ワークスペースへの照会は対象外のため、複数環境は接続・調査の分担を個別に確認します。

DefenderがあればSentinel連携も使えますか？

別の接続先と権限が必要です。利用しているワークスペース、格納データ、必要なライセンスを確認します。

利用開始の時期は決まっていますか？

現在は開発中・先行相談の段階です。対象テーブルと必要な調査範囲を確認し、提供時期と検証方法をご案内します。

Sentinelのワークスペースで、調査できる範囲を確認する

対象ワークスペース、調査したいアラート、関連するテーブル、現在の確認手順をお知らせください。

Sentinel連携の先行相談をする

技術仕様の参考

接続先と認証の概要は、MicrosoftのAzure Monitor Logs Query API公式資料をご参照ください。

関連するAI SOC連携

• AI SOC for Splunk

• AI SOC for Palo Alto XSIAM

• AI SOC for CrowdStrike

• AI SOC for Microsoft Defender

ヤグラ AI SOC · AI SOCとは

更新：2026年9月12日