ChatGPTでMicrosoft Sentinelのアラートを要約・トリアージする方法

結論から言うと： 生ログではなく、インシデントそのもの——表題、重大度、関係するエンティティ、束ねられたアラート——を書き出し、「人が先に見るべき順」に並べ替え、各件に平易な要約と次に行う確認を付けさせます。読み切れない待ち行列が、十分で読める朝の資料に変わります。ただし、クローズも隔離も「無害」の判定も、AIにさせてはいけません。

SIEMは、買ったときに期待したとおりの働きをします。そして問題はまさにそこにあります。ID基盤、エンドポイント、ファイアウォール、クラウドのサブスクリプションをつないで一か月も経てば、Microsoft Sentinelが生むインシデントは一人が読み切れる量を超えます。調査どころではありません。検知は動いています。壊れているのは「読む」ところです。

中堅企業がこの壁に当たる形はどこも同じです。SIEMがあり、他の業務も抱えたIT管理者かセキュリティ担当が一人いて、18時から翌9時までは誰もいない。待ち行列は夜のあいだに伸び、朝はそれを流し読みして終わる。正直に言えば、低・中の重大度は調査ではなく「見覚え」でクローズされています。

AIによる要約の層が解けるのは、その中の狭い一部分です。人が着手する前に、待ち行列を読める形に、順序のある形にすること。誰かを分析官にはしませんし、午前三時を覆いもしません。「どちらの半分を解いたのか」をはっきりさせておくことが、この取り組みを危険ではなく有用に保ちます。

SIEMがアラート疲れをまず悪化させる理由

SIEMを稼働させた直後の数週間は、その一生でいちばん騒がしい時期です。これは不具合ではなく想定どおりです。

既定のルールはあなたの環境を知りません。 毎晩2時にサーバーから認証するバックアップ処理、海外のVPN出口を使う開発者、正規の一括操作を実行する管理者——どれも何かを鳴らします。ルールは一般論として正しく、あなたの環境については間違っています。

判断に必要な文脈が付いてきません。 Sentinelは関連するアラートをインシデントにまとめ、アカウント、ホスト、IP、ファイルといったエンティティを添えます。しかし「そのアカウントが重要かどうか」は組織側の問いで、SIEMからは見えません。

件数そのものが優先順位を壊します。 重大度は鳴ったルールが決めるもので、結果が決めるものではありません。中重大度が四十件並べば見分けはつかず、特権を持つ経理アカウントが絡む一件も、残り三十九件と同じ顔をしています。

夜は誰も読んでいません。 これが本当の穴で、「読む」側の道具をいくら足しても塞がりません。以降の内容がこの問題の解決策と誤解されないよう、先に書いておきます。

ここで手が伸びるのはルールの調整とノイズの抑制で、それは正しく、実際にやるべきことです。ただ調整は進みの遅い仕事で、他のすべてと時間を奪い合います。その間も待ち行列は毎朝読まれなければなりません。

AI要約はトリアージのどこに入るのか

入る場所はひとつだけです。SIEMがインシデントを出したあと、人がどれを開くか決める前。上流はそのまま、下流は人のままです。

モデルに渡すのはインシデントか、生ログか

インシデントです。そしてそれ以上は多く要りません。Sentinelのインシデント記録には要約に必要なものがすでに揃っています。表題と説明、重大度と状態、検知が対応づく戦術と手法、時刻、束ねられたアラート、そして関係するエンティティ。ひとまとまりの構造化された対象です。

生ログの表は入力として適しません。理由は三つ。量が大きく、その量に課金され、モデルの注意も肝心なところから散ります。この分析に必要な以上の機微情報を含みます。そして要約の価値はログの中にはなく、「このアラートの束は何を意味しているように見えるか」を言葉にすることの中にあります。

インシデント記録にないものをひとつ足してください。あなたの環境の「平常」です。バックアップ処理が何をするか、社員が正当に接続してくる場所はどこか、無人で動くサービスアカウントはどれか、本当に機微な人とシステムはどれか——この短い文脈が、どんなプロンプトの工夫よりも出力を変えます。これがないとモデルは一般論で推論し、毎晩あなた自身の定期処理を指摘します。

インシデントはSentinelのAPIか、インシデント関連テーブルへのKQLクエリで取り出します。項目名やクエリの仕様は、断片的なコード例ではなくマイクロソフトの最新ドキュメントで確認してください。この基盤は変わります。

Sentinelの自動化の中で動かすか、外部スクリプトにするか

どちらも妥当で、向いている出発点が違うだけです。

Sentinelのオートメーションルールとプレイブック（Azure Logic Apps上に構築）は、インシデント作成を契機に外部APIを呼べます。これが本来の経路で、権限も監査証跡もすでにあるAzureの中に処理を留められます。長期的な置き場所としては優れており、立ち上げる手間は大きくなります。

一方、直近24時間のインシデントを問い合わせ、まとめて一度モデルに渡し、要約をメールやチャットに投げる定期実行のスクリプトは、「そもそも役に立つのか」を早く確かめる手段です。意図して残すべき性質もあります。読み取り専用のIDで動き、Sentinelには何も書き戻しません。

まずスクリプトから始めてください。プロンプトが数日おきに変わらなくなり、要約が実際に読まれるようになってからプレイブックへ移せば十分です。

なお、マイクロソフト自身もセキュリティ運用向けのAI機能を提供しています。そのライセンス体系に深く入っているなら、まずそれ自体の条件で評価する価値があります。本稿の方法にかかるのは午後半日です。

実例——騒がしい待ち行列から、順序のついた朝の資料へ

社員400人規模、Entra ID・Defender・ファイアウォール・クラウドサブスクリプション二つをつないだSentinelワークスペース、そしてセキュリティに明るいIT管理者が一人、という会社を考えます。

一晩でワークスペースは38件の新規インシデントを出します。多くは低・中重大度です。7時半の定期処理が直近24時間に作成されたインシデントを問い合わせ、各件の表題、重大度、戦術、内包するアラート名、エンティティを取り出します。数百行の構造化テキスト——一度の要求に収まります。

プロンプトはモデルに三つを渡します。インシデントの束、先ほどの環境文脈、そして明示的な出力形式です。効くのは形式です。各件について、順位、そのアラート群が何を描いているように見えるかの二文、最もあり得る無害な説明、人が次に行う確認を一つ、そして確信度。同じ活動だと思われるものはまとめさせる。そして、与えられたデータでは判断できない件を明示的に挙げさせる。

8時に届くその資料は、38件をおおよそ「注意に値する四つのまとまり」「理由つきで既知の活動と説明できる十数件」「判断不能と明示された数件」に畳みます。IT管理者は十分で読み終え、どこから手を付けるか分かった状態でSentinelを開きます。トリアージの順序は以前と同じで、通読の一時間だけが消えます。

この例について、正直に言うべきことが二つあります。「既知の活動」の組も抜き取り確認は要ります。本物の侵入をモデルが自信たっぷりに説明しきってしまうことこそ、いちばん重い失敗だからです。そして38件はSentinelの中では依然38件です。何もクローズされておらず、待ち行列は読みやすくなっただけで短くはなっていません。短くするのはルール調整の仕事で、この方法はそれを置き換えません。同じ形の「トリアージ補助」はサービスデスク全般にも当てはまり、社内ITヘルプデスクの振り分けボットを作る回で扱いました。

AI補助トリアージ vs 検知ルール調整 vs 24時間SOC

• 価値が出るまでの速さ — AI補助トリアージが明確に有利。読み取り専用の書き出しとプロンプトと午後半日で済みます。
• アラートそのものを減らす — 検知ルール調整の完勝。三つの中で、待ち行列を読みやすくするだけでなく実際に短くできるのはこれだけです。
• インシデントの意味を説明する — AI補助トリアージが有利。技術的なアラートの束を、多忙なIT管理者が動ける一文にすることは、言語モデルの得意分野です。
• 午前三時の対応 — 24時間SOCが勝ち、他は比較になりません。資料は読まれて初めて意味を持ちます。
• 判断して手を打つ — SOCが勝ちます。進行中の侵入における封じ込めは、要約ではなく判断と行動です。
• 監査や保険会社に出す証跡 — SOCか、記録の残る調整プログラムが勝ちます。チャットの履歴は監視の証拠になりません。
• 継続コスト — AI補助トリアージが大きく安い。安いのは、いちばん少ししかやらないからです。

三者は代替ではなく層です。中堅企業にとって現実的な順序は、まずAI要約で目の前の待ち行列を凌ぎ、そこで浮いた時間をルール調整に回して行列を短くし、誰も起きていない時間帯には人による監視を買う、という順です。

これだけはさせてはいけないこと

三つの線引きで、交渉の余地はありません。

インシデントを自動でクローズさせない。 「ほぼ確実にバックアップ処理です」というモデルの言葉は、通信もチケットも先週の経緯も見ていない仮説です。それでクローズすれば、きれいな待ち行列と偽の安心が残ります。散らかった行列より悪い状態です。

ホストの隔離、アカウントの無効化、アドレスの遮断をさせない。 対応処置は人の判断の後ろに置きます。モデルの読みでマシンを隔離できる自動化は、新たな障害の源であり、そして起動できてしまう以上は攻撃面でもあります。

「おそらく無害」を結論として扱わない。 それは「どこから見るか」の説明文です。細かい言葉の違いに見えますが、それが効く週が必ず来ます。

そして三つの根にある姿勢。モデルはあなたが渡したものしか見ていません。抑制されたルール、取り込みが止まったデータソース、そもそも接続していないログ——書き出しに含まれないものは見えず、しかも「足りない」とは言ってくれません。

ここを外さない——ログデータの扱い、APIキー、そしてITに相談すべき時

既定で流さず、意識して決めるべきことが三つあります。

何がテナントの外へ出るのか。 セキュリティのテレメトリは、社内で扱うデータの中でも機微な部類です。利用者名、ホスト名、内部のアドレス設計、検知の範囲、そして裏返せばその穴。外部APIへ送るのは実質的な意思決定です。意識して決めてください。実際に使う製品の階層について、データの取り扱いと学習に関する条件を「たぶんこうだろう」で済ませず読むこと。ビジネス版・エンタープライズ版は消費者向けと異なることが多く、条件も変わります。書き出し前にアカウント名やホスト名を仮名化する手もあり、分析価値はほとんど落ちません。それでも許容できない場合は自社設置のモデルでも同じ手順が成り立ちます。AIの処理を準拠したインフラの内側に置く考え方は、データ所在の制約がある市場と同じです。

認証情報。 書き出しに使うIDはSentinelに対して読み取り専用、それ以上を持たせない。モデルのAPIキーは、請求と上限を持つ会社のアカウントに属するべきで、最初に作った担当者個人のものであってはいけません。どちらも秘密情報の保管場所に置き、更新期限を決め、作った本人以外もその存在を知っている状態にしてください。退職した担当者の個人APIキーが本番処理を静かに回している——繰り返し見つかり、そして完全に避けられる指摘です。

誰も起きていない時間を誰が持つのか。 本稿では解けない部分です。検知の設計、ルール調整、人による監視の提供こそ、SIEMとセキュリティ監視のサービスが存在する理由であり、待ち行列を読みやすくするだけでなく短くする調整作業もそこに含まれます。AI+サポートではこの種の自動化を統制された認証情報と会社アカウントの上に構築し、マネージドITサポートがその周りのアクセス権の管理を担います。Brocentは2007年の北京での創業以来アジアでマネージドITとセキュリティを提供しており、本社はシンガポール、2016年から香港にも拠点があります。

よくある質問

セキュリティログをAIに送ること自体にリスクはありますか

あります。習慣ではなく判断として決めるべき事項です。インシデントの書き出しは、利用者、システム、検知範囲を描き出します。送る内容はインシデント階層の項目に絞り、アカウント名とホスト名の仮名化を検討し、実際に使う階層のデータ取り扱い条件を確認してください。規制や顧客との契約が許さないなら自社設置のモデルを使います。この流れは、答えるモデルが何かに依存しません。

誤検知をAIが自動でクローズできますか

できません。どれが既知の活動に見えるかを理由つきで提示することはでき、読む順序としては有用です。しかしクローズは監査証跡にも実際の防御状態にも影響する判断で、人の側に残ります。

Sentinelの取り込み費用は下がりますか

下がりません。これは取り込みより後ろに位置し、何を集めるかを変えません。取り込み費用はデータ収集とログ階層の問題です。どのデータソースをつなぎ、どのテーブルを分析階層に置き、どれだけ保持するか。見直す価値はありますが、トリアージとは別の作業です。

午前三時に上がったインシデントはどうなりますか

誰かが資料を読むまで待ち行列に残ります。これが正直な答えで、だからこそこれは「覆う」ことではなく「読みやすくする」ことなのです。時間外の対応が本当にリスク上重要なら——顧客データを扱う多くの会社では重要です——必要なのは人による監視であって、より良い要約ではありません。

検知ルールの調整の代わりになりますか

なりません。代わりだと考えることが、この取り組みが失敗する主な道筋です。要約は騒がしすぎる行列を凌げるようにし、調整はそれを短くします。前者で後者を先送りするのは、そもそも鳴るべきでなかったアラートの説明にお金を払い続けることです。

要約が正確だとどう確かめますか

抜き取りで確かめます。最初の数週間は、モデルが説明しきった件を決まった数だけ開き、その筋道が成り立つか確認します。資料は保存し、調査の結果と突き合わせます。環境について自信を持って間違えているなら、直すべきはたいていプロンプトではなく環境文脈のほうです。

Sentinel以外のSIEMでも使えますか

使えます。書き出しの手順を除けば、本稿にSentinel固有の要素はありません。インシデントとエンティティをAPIで出せるSIEMなら同じ流れに乗ります。Sentinelを例にしたのは、この問題を抱える中堅企業がいちばん多く使っている基盤だからです。

まずどこから

すでにトリアージ済みの一週間分のインシデントを書き出し、環境の文脈を平易な十文で書いてください。順位づけされた資料を出させ、その週に実際に判明したことと比べます。すぐに二つ分かります。並び順があなたの判断と一致するか、そしてモデルが自社環境のどこを知らないか。後者はそれ自体が有用な不足リストです。「行列は読めるようになったが、夜は誰も読んでいない」という結論なら、それは道具の問題ではなく体制の問題です。お問い合わせください。