JAZUG16周年イベント登壇資料 Sentinel x Foundryで挑んだSOCトリアージ自動化の話 Viaロホマン シャヒン

Jap a n A zure Us er Gro up 1 6 周年 イベント ｜ 20 26 /1 0/ 3 アラートを減らすのではなく、 判断を速くする 学生インターンが Sentinel × Microsoft Foundry で挑んだ SOCトリアージ自動化 ロホマン シャヒン Microsoft Student Ambassador ・ Gh-CUG運営 Japan Azure User Group 16周年イベント 1

ロホマン シャヒン ２０歳/情報学部二年/AI専攻/クラウドエンジニア Microsoft Student Ambassador ・ Gh-CUG運営 ▎ 大学1〜2年 ▎ 高校時代 Portfolio ・情報処理学会 全国大会で講演 ・技育CAMPハッカソン参加 ・Google × Zenn ハッカソン参加・受賞 ・Google Cloud Innovator Dev / TEC ・技育展 学生審査員 ・技育祭 春 学生アンバサダー ・業務委託にてシステム開発 ・42Tokyo Piscine（インターン参加のため辞退） ・Chrome拡張機能リリース ・SaaS スタートアップにてインターン ・ AIスタートアップでインターン ・外資ハッカソン EGH 決勝進出 ・学内コンテストにてRAGシステム構築 ・プログラミング講師を経験 ・技育祭秋学生アンバサダー就任 ・現在はMicrosoftパートナー企業にてインターン中 ・Microsoft 学生アンバサダー ・複数の登壇/ブログ執筆 ・GitHubCopilot User Group Japan運営 AI-900 Japan Azure User Group 16周年イベント AI-901

今日紹介するのは、無人化ではなく「判断の準備」 SOCでは検知を増やすほど調べるべきアラートも増えるが、アナリストの人数と時間は増えない。結果、判断よりも画面を開 き・情報を集め・過去事例を探し・報告を書く作業に時間を使う 今日紹介するのは、SOC全体の無人化ではありません 対象は、Sentinelが検知したインシデント。Agentが、次の3つの準備作業を担います 1 集める 2 Agentが必要な情報を集める まとめる 人が判断できる状態 3 根拠付きの優先度と次のアクション をまとめる 人が安全に判断できる状態を早く作 る 1件のインシデントが通る流れ 1 Sentinelで 検知 2 Logic Apps で連携 Japan Azure User Group 16周年イベント 3 Foundry Hosted Agent で正規化・ 追加調査 4 根拠付きの トリアージ結果を 生成 5 Teamsで人が 確認・承認 6 Sentinelへ 証跡を書き戻す 7 承認済みの判断を 次回へ活かす 3

今日持ち帰ってほしい問い AIに 最終判断を任せるには、何が足りないのか。 人の判断を残したまま、 どこまで準備作業を自動化できるのか。 Japan Azure User Group 16周年イベント 4

本日の発表の流れ 1 SOCの課題と二次トリアージの役割 まず、SOCの課題と二次トリアージの役 割を確認します 2 Sentinel・Logic Apps・Foundry Hosted Agentの構成 次に、Sentinel、Logic Apps、Foundry Hosted Agentの構成を見ます 3 1件のインシデントがどう処理されるか 1件のインシデントがどう処理されるかを デモで追います 4 Human-in-the-Loop・失敗時設計・Feedback学習 Human-in-the-Loop、失敗時設計、 Feedback学習を説明します 5 実装の優位性・残課題・次の一手 最後に、実装の優位性、残課題、次の一 手をまとめます Japan Azure User Group 16周年イベント 5

01 SOCとトリアージの基礎 Japan Azure User Group 16周年イベント 6

SOCは、アラートを見るだけの部署ではない SOC（Security Operation Center）は、組織のセキュリティ上の異常を継続的に監視し、脅威を調査し、必要な対応へつなげ る運用機能です。 監視 ログ、アラート、インシデントを継続的に確 認する 判断 True Positive、False Positive、Data Insufficientなどに分類する 検知 不審な挙動をルールや分析で見つける 対応 通知、チケット化、封じ込め、復旧を行う トリアージ 多数のアラートから優先して調べるものを選 ぶ 学習 対応結果をルール、手順書、ナレッジ、評価 データへ反映する 調査 関連ログ、ユーザー、端末、IP、過去事例を 確認する Japan Azure User Group 16周年イベント このプロジェクトの中心は、SOC全体の無人化ではなく、定型 化しやすく時間を消費しやすい「二次トリアージ」の支援 7

トリアージは、アナリストの時間を「どこに使うか」を決める作業 トリアージは、すべてのアラートを同じ深さで調べるのではなく、限られたアナリスト時間をどこに使うべきかを決める作業 です。 トリアージが答える7つの問い 1 これは本当に脅威ら しいか 5 追加調査が必要か 2 重大度はどの程度か 6 3 誰、どの端末、どの IPが関係しているか すぐに人が判断すべきか 7 4 過去の事例や既存の Playbookに似てい るか 自動処理してよい範囲か このプロジェクトでいう「二次トリアージ」は、Sentinelの検知ルールが作ったアラートを受け取り、関連情報 を追加収集して、アナリストが判断しやすい形に整える工程です。 Japan Azure User Group 16周年イベント 8

一次検知は残し、二次トリアージを自動化する 本プロジェクト 一次検知 二次トリアージ 最終判断 対応実行 異常の候補を見つける 調べる価値・緊急度・ 根拠を整理する 対応方針を決める 隔離・無効化・ブロッ ク・復旧などを行う 主な担当 主な担当 主な担当 主な担当 Sentinel Analytics Rule Defender XDR 各種コネクタ Foundry Hosted Agent SOCアナリスト インシデント責任者 承認済みの運用フロー Sentinelは検知と記録の中心のまま。 置き換えない Japan Azure User Group 16周年イベント その上に二次トリアージの自動化を追加します 9

良いSOCは、速く、正確である 良いSOCは、単に多くのアラートを処理するSOCではありません。 速い 重要なインシデントを見つけてから、適切な人へ届くまで の時間が短いこと 見るべき指標の例 • MTTA（Mean Time to Acknowledge）: 認知までの平均時 間 • MTTR（Mean Time to Resolve）: 解決までの平均時間 • アラート発生から最初の根拠付き要約までの時間 • 承認待ちの滞留時間 本プロジェクトは、ログを探し、過去事例を検索し、要約を書 く時間を短縮することで、判断開始までの時間を短くします 正確である 「それらしい文章」では不十分。根拠が追跡できること 必要な要素 • どのインシデントを見たか • どのログやエンティティを参照したか • どのルールやシグナルがスコアに影響したか • どの過去事例やPlaybookを参照したか • どの条件で優先度を上げ下げしたか • どこに不確実性があるか 本プロジェクトが結果に残す項目 triageResult.evidence confidence Japan Azure User Group 16周年イベント knowledgeReferences externalEvidence 10

良いSOCは、説明でき、安全である 説明可能である アナリストが「なぜHighなのか」「なぜFalse Positiveら しいのか」を理解できること 安全である 誤判定時の被害が大きい操作は慎重に扱う 初期段階では、無条件に自動実行しない操作 良い説明は、結論だけでなく次の形を持つ アカウント無効化 端末隔離 IPブロック 結論 High セッション失効 理由 短時間に認証失敗が集中し、通常利用地域外 のIPと特権アカウントが関与 Agent 人 不足情報 対象ユーザーの正規出張予定は未確認 調査と提案を担当する 次の行動 ユーザーの正規利用か確認し、IPの関連イン シデントを調査 Human-in-the-Loopで、 高リスク操作の承認を必 要とする Japan Azure User Group 16周年イベント インシデントの自動クローズ 11

良いSOCは、失敗しても黙らず、学習できる 失敗しても黙らない 学習できる 連携が失敗したときに、成功したように見せない 同じ調査を、毎回ゼロから繰り返さない 失敗の例 学習のためにやること • Sentinel参照に失敗した • 過去の確定事例を再利用する • RAG検索が使えなかった • アナリストの判断を記録する • Code Interpreter相当分析がタイムアウトした • False Positiveのパターンを蓄積する • Teams通知に失敗した • 検知ルールやPlaybookを改善する • Sentinel書き戻しに失敗した • Agentの評価結果をベースラインと比較する これらを個別のステータスとして記録し、アナリストに「どこ まで確認できたか」を知らせます。本プロジェクトでは、次の フィールドをこの目的で使用します 本プロジェクトでは、Feedbackを承認済みナレッジとして保存 し、類似インシデントの次回判定に限定的に反映するループを 実装しています operations.*.status Japan Azure User Group 16周年イベント 12

02 課題と設計の考え方 Japan Azure User Group 16周年イベント 13

アナリストの時間は、判断ではなく「情報集め」に溶けている 時間が溶ける作業 • Sentinelを開く • 関連エンティティを確認 • SigninLogsやAuditLogsを検索 • IPやユーザーを過去7日間で横断検索 • 過去のPlaybookを探す • 調査結果を要約 • Teamsへ報告 • Sentinelへコメントを戻す 判断そのものではなく、判断のための情報整理が中心 Japan Azure User Group 16周年イベント 14

情報は散らばり、結果は運用に戻らない 情報が複数の場所に散らばる 判断結果が運用へ戻らない 一つのインシデントを理解するために、次の情報源を横断 する必要がある Sentinel Incident / Alert Log Analyticsの SecurityIncident SigninLogs AuditLogs SecurityAlert ARM Incidents API のEntities 過去の対応事例 TeamsやITSMの対 応履歴 社内Playbook 人が毎回手作業で行うと、見落としや確認漏れが起きる 分析結果をAgentのレスポンスだけで返しても、SOCの記 録や後続作業にはつながらない そのため、結果を複数の出口へ配信する Sentinel コメントやタグとして監査証跡を残す Teams アナリストが読める通知を送る 承認記録 人の判断を残す ナレッジ 承認済みのレビュー結果を保存する 将来のITSM チケットへつなぐ Agentは、これらを一つのトリアージ結果へ集約する Japan Azure User Group 16周年イベント 15

入力は揺れ、検知だけでは判断できない 入力形式が安定しない 検知結果だけでは判断できない Logic Appsへ渡るペイロードは、Alert起点かIncident起 点か、Automation Ruleの種類で形が揺れる Analytics Ruleが「不審なログイン」を検知しても、それ だけでは最終判断できない 同じ意味の値が異なる場所に入る例 追加で知りたい情報 • incidentId と alertId • 失敗回数はどの程度か • incidentUrl と properties.incidentUrl • どの時間帯に集中しているか • severity の大文字・小文字 • 通常とは異なる地域か • entities の配列形式 • 特権アカウントが関係するか • Logic App由来の • 同じIPやユーザーが他のインシデントにも出ているか • 既知のIOCと一致するか そのまま判定ロジックへ渡すと、同じイベントでも結果が変わ る • 過去に正規利用と確定したパターンか そこで、最初にpayloadを正規化する ルールベースのシグナルに加えて、Sentinel / Log Analytics参 照、相関分析、RAG根拠を組み合わせる body Japan Azure User Group 16周年イベント ラッパー 16

1件のインシデントが、Teamsと Sentinelへ戻るまで 検知 Logic Appsで 連携 Japan Azure User Group 16周年イベント Agentが 正規化・追加調査 根拠付き結果 Teamsで 人が承認 Sentinelへ 書き戻し・ 次回へ活用 17

役割を分ける：SentinelはSoR、Logic Appsは入口 Microsoft Sentinel：記録の中心（SoR） Logic Apps：イベント連携の入口 既存のSOC運用と監査の中心を変えないため SentinelとAgentの間のイベント連携を担当する • 検知ルールとインシデントの管理場所を維持できる • SentinelのIncident作成・更新をトリガーにできる • 既存のAutomation RuleやLogic Appと接続できる • ペイロードの変換や後方互換フィールド追加ができる • Foundry InvocationsへのHTTP呼び出しを構成できる • Managed Identityで認証できる • Run historyで連携の成否を確認できる • インシデントの履歴とAgentのコメントを同じ場所で確認で きる • SOCアナリストが新しい画面を常時監視しなくてよい • 監査や引き継ぎ時に、元のインシデントと判断結果を追跡 できる AgentをSoRにしない Agentは判断を補助する実行コンポーネントであり、組織 の正式な記録そのものではない Japan Azure User Group 16周年イベント イベント連携とトリアージ処理を分離 Agent側にSentinelのイベント購読処理まで詰め込まない 18

役割を分ける：Foundry Hosted Agentは実行基盤 Foundry Hosted Agentを使う理由は、モデルを呼ぶためだけではありません。運用可能な実行基盤を使うためです。 1 コンテナ化したPython実装を デプロイできる 4 InvocationsプロトコルでLogic Appsから構造化入力を渡せる 2 Foundryがエンドポイント、認 証、スケーリング、ライフサ イクルを管理する 3 Agent Identityで下流Azureサ ービスへアクセスできる 5 Application Insightsなどの可 観測性を組み込みやすい 6 バージョン単位でデプロイと 検証を行える ただし、通常の意味でのカナリア配信はできません 1つのエンドポイントは1バージョンへ100%ルーティングされます。運用は、次の形になります 新バージョンを検証 Japan Azure User Group 16周年イベント 一括切り替え 問題時は安定版を再デプロイ 19

Teamsは、通知と意思決定の場 Teamsを通知と意思決定の場にする理由は、SOC担当者が普段使う場所へ結果を届けるためです。 Adaptive Cardにまとめる情報 重大度に応じたヘッ ダー 分類 インシデントタイト ルと重大度 要約 「要承認」と「承認状態」は別物 推奨優先度 要承認 承認が必要かどうか 承認状態 現在 pending / approved / rejected のどれか 主な根拠 これを分けることで、承認要否と処理状況の読み 違いを防ぐ 推奨アクション 関与対象 Sentinelへのリンク 通知に失敗しても、黙らない 自動調査の状態 「要承認」と「承認 状態」 Feedbackボタン（条 件設定時） 処理全体が黙って落ちないように、 operations.teamsNotification に状態を残す teams_notifier.py が、構造化された判定結果をAdaptive Cardへ変換します Japan Azure User Group 16周年イベント 20

一つのAgentに、検知・連携・判断・通知・監査を詰め込まない 各コンポーネントの役割分担 このアーキテクチャは、各サービスに異なる責務を持たせます。一つのAgentに検知、連携、判断、通知、監査をすべて詰め込まないことが、 変更しやすさと失敗箇所の特定しやすさにつながります。 コンポーネント 担当すること 担当しないこと Microsoft Sentinel 検知、インシデント管理、監査のSoR Agentの推論やTeams UIの生成 Automation Rule 対象インシデントの選別、起動条件 複雑なトリアージ判定 Logic Apps イベント変換、認証付き呼び出し、再実行、Run history 根拠の評価や最終判断 Microsoft Foundry Hosted Agent 入力正規化、追加調査、判定、結果JSON生成 無条件の高リスク操作 Pythonモジュール ルール、権限境界、失敗時処理、Feedback制御 監査記録の唯一の保管場所 Microsoft Teams アナリストへの通知、承認、Feedback入力 Sentinelの正式記録 Knowledge / 評価基盤 承認済み事例の再利用、回帰検証 未承認情報の無条件な学習 この分離により、Teams通知が失敗しても判定結果とSentinel書き戻しの状態を失わず、判定ルールを変更してもイベント連携の認証 処理を作り直さずに済みます。 Japan Azure User Group 16周年イベント 21

Security Copilotは対話の支援、本プロジェクトはイベント駆動の実行 Security Copilotなど他製品との違い Microsoft Security Copilotのような製品は、アナリストが対話しながらインシデントを調査し、要約、推奨、クエリ作成などを行うための汎 用的な支援レイヤーです。一方、このプロジェクトは特定のSOC運用に合わせたイベント駆動の実行パイプラインです。 観点 Security Copilot 本プロジェクト：Sentinel × Foundry Hosted Agent 主な入口 アナリストの対話、製品連携、調査コンテキスト SentinelのAlert/Incidentイベント、Logic Apps 主な価値 対話的な調査支援、要約、探索の加速 定型トリアージの自動実行と結果配送 判断の形 会話の中で質問しながら深掘り 固定スキーマのtriageResult 組織固有ロジッ ク プラグインや設定で拡張 Pythonコード、ルール、RAG、Feedbackで明示的に実装 Japan Azure User Group 16周年イベント とoperations 22

代替ではなく、組み合わせられる Security Copilotなど他製品との違い（続き） 観点 Security Copilot 本プロジェクト：Sentinel × Foundry Hosted Agent 出力先 Copilotの対話・連携先 Teams通知、Sentinelコメント、監査JSON、ナレッジ 人の関与 対話しながら調査・判断 高リスク操作の承認ゲートとして明示 評価方法 製品の利用体験や設定した評価 JSONフィールド、分類、配送状態のベースライン比較 適した場面 初見の調査、自由度の高い分析、アナリストの質 問対応 毎回同じ形式で走らせる一次整理、通知、証跡、再現可能 な運用 これはSecurity Copilotの代替を主張する比較ではありません。両者は組み合わせられます。 Hosted Agentが定型的な一次整理と証跡化を行い、Security Copilotを追加調査や例外ケースの対話的な深掘りに使う構成も可能です 。 Japan Azure User Group 16周年イベント 23

優位性は、運用フローをコードとデータ契約として固定できること この実装方式の優位性とトレードオフ 本実装の優位性は、モデルの賢さだけではなく、運用フローをコードとデータ契約として固定できる点にあります。 再現性 同じ入力JSONから同じ 正規化、ルール判定、状 態出力を再実行できる 監査性 根拠、参照元、承認者、 配送状態を構造化して残 せる 疎結合性 Sentinel、Teams、Logic Appsの一 部が失敗しても、判定結果全体を失 わない Japan Azure User Group 16周年イベント 組織適合性 安全性 独自のSeverity、Entity、 Playbook、Feedbackル ールをPythonで管理でき る 評価可能性 Golden Setとベースラインで、変更 による分類回帰を検知できる 高リスク操作をAgentの 提案と人の承認の間で止 められる 拡張性 将来のITSM、Workbook、限定的な 対応自動化を既存の結果契約へ接続 できる 24

その代わり、実装・運用責任は自分たちで持つ この実装方式の優位性とトレードオフ（続き） その代わり、専用製品を導入する場合よりも、次の実装・運用責任を自分たちで持ちます。 1 Prompt、ルール、スキーマ、テストデータの維持 2 RBAC、Managed Identity、Secret、Logic Appsの運用 3 再送、重複排除、タイムアウト、監視、ロールバック 4 ナレッジのレビュー、有効期限、誤学習の防止 5 モデルやFoundryの更新に対する回帰評価 この方式が適するのは『自社の入力・承認 ・監査・通知の流れを細かく制御したい』 場合です。 Japan Azure User Group 16周年イベント 自由な対話調査をすぐ使いたい場合 はSecurity Copilot 単純な通知や定型連携だけなら、 Sentinel Automation RuleとLogic Appsだけで十分な場合があります。 25

書き戻しは分離して、失敗しても結果を失わない トリアージの判定と外部連携を分離すると、TeamsやSentinelの一方が失敗しても、分析結果全体を失わずに済みます。 現在の主な配送モード off 連携しない mock 送信をシミュレートする local ローカル監査ファイルへ保存する機能で使用 webhook TeamsなどへHTTP送信する arm Sentinel ARM APIへ書き戻す delivery 環境変数だけでなく、リクエスト単位のdeliveryフ ィールドでも検証用に上書きできる arm 本番想定：対象インシデントのGUIDを解決してか ら、コメントを書き込む 実装抜粋: sentinel_writeback.py 書き戻しに失敗しても、判定結果と失敗理由はレスポンスに残ります Japan Azure User Group 16周年イベント 26

全体の処理フロー Sentinel Alert/Incident Automation Rule Logic App Foundry Hosted Agent Payload normalize 検知 対象の選別・起動条件 イベント連携 実行基盤 入力の正規化 Sentinel/Log Analytics enrich File Search grounding Code Interpreter analysis Rule-based triage Feedback learning 追加情報の取得 根拠の付与 集計・相関分析 優先度・分類・信頼度 類似ケースの補正 Sentinel ARM writeback 証跡の書き戻し 実装上の中心 Human approval Teams Adaptive Card src/agent/triage_runtime.py 通知 人の承認 execute_triage_flow Knowledge accumulation ナレッジの保存 Japan Azure User Group 16周年イベント 27

処理の順番は12ステップ 1 入力を受け取る 7 承認済みFeedbackがあれば類似ケースに限定して判 定を補正する 2 Sentinel/Logic Apps由来の形式を正規化する 8 Human-in-the-Loopの状態を評価する 3 SentinelとLog Analyticsから追加情報を取得する 9 Sentinelへ書き戻す 4 File Search相当の根拠を付与する 10 Teamsへ通知する 5 Code Interpreter相当の集計・相関分析を行う 11 承認済みFeedbackやナレッジを保存する 6 ルールベースで優先度・分類・信頼度を決める 12 各処理の成功・失敗・スキップ状態をレスポンスへま とめる Japan Azure User Group 16周年イベント 28

execute_triage_flow が、全部をつなぐ 各処理を順番に呼び、1つのJSONへ 判定結果と配送状態を、最後に一つのJSONへまとめる 返すのは、この2つ triageResult operations operations に入る、抜粋内の7つの状態 sentinelReference fileSearch feedbackLearning humanApproval sentinelWriteback codeInterpreter teamsNotification 実際のコードでは、同じレスポンスへさらに追加 fallback knowledgeAccumulation aiAssist executionContext 実装抜粋: triage_runtime.py Japan Azure User Group 16周年イベント 29

03 実装：集める・揃える・判定する Japan Azure User Group 16周年イベント 30

最初から生ログを渡さない 渡す情報の例 Agent起動時には、原則として生ログを全部渡しません Incident ID / Alert ID 詳細ログは、Agentが必要な範囲だけLog AnalyticsやSentinelから 取得します Incident URL この設計の効果 Sentinel Workspace情報 Entities 機微情報を必要以上に転送しない プロンプトサイズとコストを抑える 対象時間範囲 同じIncident IDから再実行しやすい Correlation ID 参照元を説明しやすい 処理ポリシー 取得失敗を明示できる Japan Azure User Group 16周年イベント 31

入力を正規化する：揺れるpayloadを1つの形へ sentinel_payload_mapper.py の主な仕事 • Alert形式とIncident形式を吸収する • incidentIdやalertIdを補完する • sourceTypeを設定する • severityを正規化する • entitiesを内部形式へ揃える • bodyラッパーやネストした値を展開する • correlation IDを保持する normalize_triage_payload は、この候補リストから incidentId・ severity・entities・incidentUrl・sourceType などを内部形式へ変換 します 実装抜粋: sentinel_payload_mapper.py この層を分けることで、判定ロジックは「Logic AppのJSONがどういう形だったか」を意識しなくて済む Japan Azure User Group 16周年イベント 32

Sentinelの見え方は、条件で変わる なぜ複数経路が必要か Sentinelのインシデント情報は、次の ような条件で見え方が変わります このプロジェクトでは、主に次の情報を確認します SecurityIncident の スナップショット Incidentのタイトル 、重大度、状態 関連Alert SigninLogs AuditLogs IOC横断結果 ユーザー・ホストの タイムライン ARM Incidents API のEntities マージ先インシデン ト 作成直後 マージ済み 外部製品由来 だから、1つの経路に頼らず、複数の経 路で確認します Japan Azure User Group 16周年イベント 33

根拠を集める：複数の経路を独立に参照する sentinel_log_analytics.py の設計上の工夫 実装抜粋: sentinel_log_analytics.py 外部参照は、取得できた情報だけを使って処理を続けられる よう、payloadと状態を返します。 実装ではLog AnalyticsとARMの取得を独立させ、片方が空で ももう片方を試します。 Japan Azure User Group 16周年イベント • Log Analytics参照とARM参照を独立させる • インシデントが作成直後でLog Analyticsに未反映でも、 ARM参照を試す • Defender XDR等によるインシデントマージを追跡する • ARM Entitiesが一時的に空の場合に再取得する • IOC調査のtimeoutやnetwork errorをbest effortで扱う • 重い横断クエリに失敗した場合、SigninLogs中心のquick modeへフォールバックする • アプリやシステムが実行者の場合、AuditLogsのCustom Detailsから実行者名を補完する 34

File Search / RAGで、組織の知識を根拠に足す 現在の実装上の特徴 実装抜粋: file_search_grounding.py（元payloadを壊さず、コピーへ追加） File Searchは、Playbookや過去事例を検索し、判定を組織固有 の知識で補強する仕組みです。 このリポジトリでは、file_search_grounding.py がローカルまた はモックの検索経路を提供します。 Japan Azure User Group 16周年イベント • payloadから検索語を抽出する • knowledge/templates配下の文書を検索する • 単語境界を考慮してノイズを減らす • READMEなどの一般文書を除外する • 一致した文書をevidenceとknowledgeReferencesへ反映 する • 関連度が低すぎる文書は採用しない RAGの注意点 検索結果が「正しい」とは限りません。ナレッジが古い、検索語 が弱い、別のインシデントの文書が混ざる、といった問題がある ため、参照元と更新日、レビュー状態を管理する必要があります 。 35

Code Interpreter相当の分析は、補助信号を作る 構造化されたシグナルを集計・相関し、追加のリスクスコアや根 拠を作ります 分析例 実装抜粋: code_interpreter_analysis.py • エンティティごとの出現回数 • IOCの重複排除 • ユーザー、ホスト、IPの分布 • タイムラインの整理 • 関連情報の件数集計 • 0から100のリスクスコア スコアは、結論そのものにしない アナリストが見るべき候補を整理するための補助信号 モードを off、mock、local で分け、分析できない場合も状態 を返します。 機密ログを扱う場合は、次の4点を事前に決める必要があります _enrich_local は、失敗ログ数、IOC数、エンティティ数、タイムラ イン、特権アカウントを使い、codeInterpreterAnalysis と externalEvidence へ記録します。 Japan Azure User Group 16周年イベント データ分類 保持期間 リージョン 利用可能なツール範囲 36

判定は、ルールで構造化する 主なシグナル（ルールベース） Severity Failed login count Privileged account involvement 外部根拠の有無 Unusual geolocation IOC match Code Interpreter相当分析のリスクスコア 類似ナレッジやFeedbackパターン run_triage は、severityを初期スコアに変換し、failed login、地理異 常、特権アカウント、IOC、外部根拠を加点します。 情報がほとんどない場合は、優先度をMedium、分類をData Insufficient、状態をon_holdにします。 実装抜粋: triage_workflow.py（スコア → 優先度・分類） recommendedPriority classification confidence summary evidence 代表的な出力 recommendedActions Japan Azure User Group 16周年イベント knowledgeReferences requiresHumanApproval 37

優先度は、「侵害を断定できたか」だけでは決まらない 優先度は、「本当に侵害だと断定できたか」だけでは決まりません。次のような組み合わせで、優先して人が見るべきかを判 断します。 重大度が高い 特権アカウントが関係 する IOCが一致している 低い優先度 危険性が低い 短時間に失敗が集中し ている 関連インシデントが複数存在する 根拠が不足していて保留が必要で ある データ不足 ≠ 危険性が低いのではなく、判断材料が足りない状態 情報がほとんどない場合の出力 Japan Azure User Group 16周年イベント 通常と異なる地域から アクセスしている Medium Data Insufficient on_hold 38

DEMO 1 入力JSON → 根拠付きトリアージ結果 3層で確認する 判定 内部状態 外部結果 triageResult operations / executionContext Teams・Sentinel・Run history Japan Azure User Group 16周年イベント 39

結果JSONは3つの領域で読む triageResult Agentが判断した内容 triageResult Agentが判断した内容 優先度・分類・信頼度・要約・根拠・推奨アクション・参照ナレッ ジ・承認要否 operations 各外部連携の結果 status は sent・skipped・failed・mocked の意味で読む executionContext 実際に解釈された実行条件 出力例: triageResult（JSON） Japan Azure User Group 16周年イベント Incident URL・各モード・承認状態・Correlation ID など 40

operations は連携の結果、executionContext は解釈の結果 operations executionContext 各外部連携の結果 実際に解釈された実行条件 主な項目 解析したIncident URL sentinelReference codeInterpreter fileSearch 日本語化されたタイトル feedbackLearning teamsNotification humanApproval sentinelWriteback knowledgeAccumulation fallback 適用された各モード Human-in-the-Loopの状態 status の意味 実行または保存に成功 Teamsカード形式 skipped 設定されていない、または適用対象がない Correlation ID failed 実行したが失敗 mocked モックで成功をシミュレート sent Japan Azure User Group 16周年イベント 「入力に何を書いたか」ではなく、「Agentが 最終的にどう解釈して何を実行したか」を確 認する場所です。 41

04 安全性と学習 Japan Azure User Group 16周年イベント 42

最も危険なのは、誤判定による高影響操作 誤判定の例 正規ユーザーのアクセス 攻撃と誤認 アカウントを無効化 業務影響が出る 誤判定の被害が大きい操作 アカウント無効化 端末隔離 IPブロック セッション失効 インシデントの自動 クローズ 本プロジェクトでは、初期段階でこれらを無条件に自動実行しません Agent アナリスト 自動実行系 調査、根拠整理、優先度提案、通知 最終判断、承認、例外判断 承認済みの場合だけ将来拡張 Japan Azure User Group 16周年イベント 43

高リスク操作は、承認されるまで止まる Agent＝調査・根拠整理・提案 Japan Azure User Group 16周年イベント アナリスト＝最終判断・承認 自動実行＝承認済みのみ（将来拡張） 44

承認は、3つのモードと6つの状態で記録する 承認モード 承認状態 off 承認機能を使わない pending 承認待ち mock 承認をシミュレートする approved 承認済み local 監査JSONを保存する rejected 却下 not_required 承認不要 invalid 入力不備 error 記録失敗 ローカルモードでは、監査レコードを保存 pending approved 承認情報の反映先 rejected operations.humanApproval Japan Azure User Group 16周年イベント ・ executionContext.humanApproval 45

「誰が承認したか」が分からない状態を許容しない approved・rejected には approver が必須 誰の判断か分からない状態を許容しない Teams上では、3つを分けて表示 要承認 この処理に人の承認が必要か 承認状態 実装抜粋: human_approval.py 現在の承認状態は何か 承認者 承認不要な場合は、not_required と明示 approvedまたはrejectedの場合の担当者 小さなUI上の違いですが、実運用では誤操作防止に直結します Japan Azure User Group 16周年イベント 46

DEMO 2 ｜ Teamsで人が判断する 1 1 優先度・判定・確信度・要承認・承認状態を最上段にまとめる 例: MEDIUM・確信度0.85・分析スコア20/100 2 「最初にやること」と「やってはいけないこと」を分けて提示 3 Sentinel Incidentへのリンクから証跡を確認 2 3 Japan Azure User Group 16周年イベント 実行結果のスクリーンショット（一部マスク済み） 47

Feedbackを学習へ戻す 承認済み記録のみ アナリストが承認したレビュー結果だけを保存 類似度のしきい値つき min_match_score を満たす記録だけが対象 無条件上書きなし 過去の一件を無条件に全インシデントへ適用しな い モデルの自己学習ではない。アナリストが承認した記録を、条件付きで再利用する Japan Azure User Group 16周年イベント 48

FeedbackはLogic Appを経由して、Agentへ届く SOC Analyst Teams Card Logic App HTTP trigger Foundry Agent Knowledge Store benign / maliciousを選択 1 query parameters 2 feedbackAction + knowledgeFeedback 3 pending record 4 5 capture result approved record/template 6 flow result 7 単なるクリック記録ではない Japan Azure User Group 16周年イベント Feedback付きのトリアージを再実行し、承認済みのレビュー結果をナレッジとして残す 49

ボタン1つが、承認済みナレッジになる Feedbackボタンは2つ benign 正規/問題なし malicious 要調査/疑わしい クエリで送る6項目 label incidentUrl sourceType correlationId alertId Capture endpointへ、クエリとして送る 実装抜粋: teams_notifier.py TEAMS_FEEDBACK_CAPTURE_BASE_URL incidentId が設定されている場合だけ、ボタンを追加します 未設定なら、カードに壊れたボタンを追加しません Japan Azure User Group 16周年イベント 50

承認済みとみなす4つの条件と、3つの保存先 保存先（localモード） knowledge/feedback/pending/ 未承認、またはレビュー待ち knowledge/feedback/approved/ 承認済みレコード knowledge/templates/ 検索対象テンプレート 承認済みとみなす条件の例 実装抜粋: knowledge_accumulation.py approved=true 入力は knowledgeFeedback または feedbackAction 両方を、同じ保存処理へ統合します Japan Azure User Group 16周年イベント isApproved=true reviewStatus=approved label=benign または label=malicious 51

過去の記録は、似ているものだけを使う FEEDBACK_LEARNING_MODE=local 承認済みレコードから、現在のインシデントに似た記録を探す 類似度に使う情報（4つ） source type min_match_score 一定の値を満たすものだけが対象 Japan Azure User Group 16周年イベント Analytics Rule名 エンティティ インシデントタイトルの トークン 過去の一件を、無条件に全インシデントへ適用する 設計ではない 52

類似度と重みで、補正の強さを制限する benign優勢 優先度を一段下げる False Positive寄りの分類 正規利用確認の推奨 malicious優勢 優先度を一段上げる アナリスト即時確認寄りの分類 追加調査の推奨 実装抜粋: feedback_learning.py 類似度の下限と重みの上限で、弱い一致一件だけでは判定が大 きく変わらない 補正理由は証拠へ追加され、次の参照も残る FEEDBACK_PATTERN:benign:* FEEDBACK_PATTERN:malicious:* これはモデルの自己学習ではありません。 承認済みの過去記録を、類似度の条件付きで再利用する、限定的な学習ループです Japan Azure User Group 16周年イベント 53

失敗は6つの形で起きる。どれも個別に残す 1 Sentinel参照失敗 判定を成功に見せず、データ不足または 参照失敗として、根拠と推奨アクション へ反映する 4 IOC調査のtimeout timeoutやネットワークエラーは一度再 試行し、それでも失敗ならSigninLogs 中心のquick modeへフォールバック。 未完了の調査は、通知内の自動調査ステ ータスと根拠に残す Japan Azure User Group 16周年イベント 2 Log Analyticsの反映遅延 作成直後のIncidentは反映が遅れる場合 がある。Log Analytics参照が空でも、 ARM Incidents API経路を独立して試す 5 Teams通知失敗 Teams通知が失敗しても、トリアージ 結果やSentinel書き戻しまで失敗したと は限らない。 operations.teamsNotification.statusを 確認する 3 インシデントマージ Defender XDR等との統合環境では、元 のインシデントが空の抜け殻になる場合 がある。mergedIncidentUrlを追跡し、 最終インシデントのEntitiesを参照する 6 Sentinel書き戻し失敗 現在の本番想定はARM APIによる書き 戻し。Responder権限がない場合も、分 析結果を失わずに失敗状態を記録する 54

失敗しても、黙らない 失敗時の基本原則（5つ） 個別のステータスとして記録 連携が失敗したときに、成功したように見せない 1 失敗を隠さない 2 処理全体を不必要に止めない 3 Sentinel参照に失敗した RAG検索が使えなかった 不足情報を明示する Code Interpreter相当分析がタイムアウトした 4 5 人へエスカレーションする Teams通知に失敗した あとから再現できる状態を残す Sentinel書き戻しに失敗した アナリストに「どこまで確認できたか」を知らせる operations.*.status Japan Azure User Group 16周年イベント sent skipped off・mock でも、同じ failed mocked DeliveryStatus の形で返す 55

権限は、機能単位で最小に分ける Agent Identityに付ける代表的な権限 Log Analytics Reader Log Analyticsクエリ Microsoft Sentinel Reader Sentinel ARM参照 Microsoft Sentinel Responder 最小権限の考え方 参照だけならReader コメント書き戻しが必要ならResponder相 当 Logic AppからFoundryを呼ぶ場合は、 Foundry側の実リソースへ権限 Sentinelコメント書き戻し SecretはKey Vaultなどで管理 FoundryやAIサービスの実行権限 コードやプロンプトにトークンを埋め込ま ない Agent自身やLogic Appの呼び出しに必要 Agent Identityと、Foundryプロジェクト管理用のIdentityは、別の責務です Japan Azure User Group 16周年イベント 56

権限は、実際にAPIを呼ぶIdentityへ 混同しやすいIdentity（4つ） 入力データの最小化 Hosted AgentのInstance Identity 起動時に、生ログを丸ごと渡さない Foundryプロジェクトの管理用Identity Incident IDや時間範囲を渡し、Agent側で必要な情報だけ 取得する Logic AppのManaged Identity コストだけでなく、機微情報の露出面積を減らす設計でも ある 開発者のAzure CLIユーザー 「自分のAzure CLIでは読める」≠「Hosted Agentが読める」 実際にAPIを呼ぶIdentityへ、RBACを付与する必要があります Japan Azure User Group 16周年イベント 57

05 検証と次の一手 Japan Azure User Group 16周年イベント 58

小さく作り、毎回JSONで確かめる 基本サイクル JSONはファイル入力 1 要件を小さくする 2 小さく実装する 3 単体テストする PowerShellのインラインJSONは、クォートやエンコー ディングで壊れやすい -f <json-file> を基本にする 例 4 azd deploy する 5 invoke -f で再現する 6 operations と外部結果を確認する 7 開発メモを更新する Japan Azure User Group 16周年イベント azd ai agent invoke yjk-secops-foundry --protocol invocations -f tmp\hitl-approved-teams-live.json 59

実際に使った Goal-loop Skill による開発プロセス Goal-loop Skill の紹介 触ってみた＆解説 Goal-loop Skill を使って、このプロジェクトを実装しま した SKILLの作者：やまぱん！さん SKILLのリンク https://github.com/aktsmm/Agent-Skills/tree/master/goal-loop 触ってみた＆解説（Qiita記事） GitHub Copilot は、コード補完ではなく、Goal-loop Skill のオーケストレーターとして使いました Japan Azure User Group 16周年イベント 60

• https://github.com/aktsmm/Agent-Skills/tree/master/goal-loop

Goal-loopの実装サイクル 開発の流れ 1 2 Scopeと成功条件を 固定する 6 → 3 へ戻る 未達なら再試行（回数に上 限） 検証可能な サブゴールへ分解する 7 成果物と証拠を まとめて完了報告する 3 workerへ実装や 調査を委譲する 6 未達なら原因を更新して、 回数を制限して再試行する 4 外部シグナルで 検証する 5 evaluatorが 受け入れ条件を評価する 実装が終わっただけでは完了とみなさない。実際の invoke 結果や外部画面への反映まで確認します Hosted Agent・Logic Apps・RBAC・通知・書き戻し・評価をまたぐ作業で特に重要 Japan Azure User Group 16周年イベント 61

Goal-loop で伝えたい6つのポイント ポイント 1 Scopeと成功条件を先に固定す る 何を作るか、何をもって成功とするか、 触らない範囲を最初に決める 4 外部シグナルで判定する 2 作業を検証可能な単位へ分ける コード、インフラ、E2E、評価を別々の サブゴールにする 5 evaluatorで受け入れ条件を照合 する テスト成功だけでなく、deploy、invoke 、Teams、Sentinel、Logic Appの実体 を確認する 自己判断で「できた」とせず、条件ごと に証拠を確認する 確認する3層 内部状態 判定 3 workerと役割を分ける 調査・実装・検証を一つの視点だけで進 めず、必要な作業を委譲する 6 再試行に上限を持たせる 失敗理由を更新してから再計画し、同じ 失敗を無制限に繰り返さない 外部結果（Teams・Sentinel・Run history） レスポンスが成功でも、Teams Workflowの下流マッピング不備などで投稿されない場合があるので、外部画面やRun historyも確認します Japan Azure User Group 16周年イベント 62

Foundry Toolkit：VS Code で Agent の開発を一つにまとめる VS Code の拡張機能 Foundry Toolkit とは VS Code の中で、AI アプリや Agent を作る・テスト・デプロイ ・評価できる拡張機能です。ローカルでも Foundry に接続して も使え、旧 AI Toolkit の新しい名前です できること Model Catalog Agent Builder Tool Catalog Agent Inspector Hosted Agent のデプロイ 評価・トレース 利点 VS Code を離れず、作成から評価まで 出典：Microsoft Learn「Foundry Toolkit for Visual Studio Code overview 」ほか ローカル検証から Foundry へつながる Agent Inspector でツール呼び出しも追える GitHub Copilot が Agent 作成を支援 実装には VS Code の Foundry Toolkit を使い、Agent の構成や開発環境を確認します Japan Azure User Group 16周年イベント 63

ここまでできていること 実装済み 1 受け取る 2 Sentinelの入力を揃え、Logic AppsからFoundry Hosted Agentを呼べる 4 通知・承認する Teamsのカードで通知し、「 要承認」と「承認状態」を分 けて管理できる 調べる 3 Sentinel・Log Analytics・ ARMから、ログやエンティテ ィを追加調査できる 5 記録する Sentinelへコメントで証跡を 書き戻せる 判定する ルールで優先度・分類・信頼 度と、根拠・推奨アクション を出せる 6 学ぶ・確かめる 承認済みFeedbackを保存して 次回に反映（ローカル）。単 体テストと評価で確認 File Search相当の根拠づけとCode Interpreter相当の分析は、いまはローカル／モックの形で動いています Japan Azure User Group 16周年イベント 64

これからのこと 未実装・設定待ち 1 Feedbackボタンの本番接続 Teamsのボタンからナレッジ保存まで、実環境で通す 2 権限と設定の確認 使う権限（Managed Identity / RBAC）と接続先を整える 3 運用の仕組み 再送・重複の防止・監視・失敗時の手順を整える 4 評価の自動化 評価をCI（自動テスト）に組み込む 5 本番ダッシュボード 本番のWorkbookを継続運用する 実装はできていて、残っているのは“実環境で通して運用に乗せる”部分です Japan Azure User Group 16周年イベント 65

将来構想：自動封じ込めは、最後に進める 短期 中期 • Feedback captureの本番運用化 • 評価ランナーのCI統合 • writebackの再送制御、失敗監視 、Runbook整備 • Incident更新時の再評価戦略 • 隔離、無効化、ブロックなどの自 動実行候補 • 二段階承認、例外承認ポリシー RAGナレッジのレビュー、有効 期限、オーナー管理 • ロールバック可能な対応自動化 • ITSM連携 • 複数AgentやA2A連携 • アナリストoverride率や誤判定是 正率の可視化 • • • 長期 Teams BotまたはApproval Flow による承認の本番化 失敗監視ダッシュボード 自動封じ込めは最後に進めます。 先に、根拠、承認、監査、ロールバック、評価が整っている必要があります。 Japan Azure User Group 16周年イベント 66

本質は、この流れを再現可能にしたこと このプロジェクトの価値は、AIが人間より賢く判断することだけではありません。 本質は、次の流れを再現可能にしたことです。 1 2 3 4 5 6 Sentinelが検知 する Agentが必要な 根拠を集める 根拠付きで優 先度を提案す る Teamsで人が 判断できる形 にする Sentinelへ証跡 を戻す 承認済みの判 断を次回へ活 かす SOC改善の5つの速度 つまり、SOCの改善を次の5つの速度で考えられるようにします。 検知から把握まで の速度 把握から判断まで の速度 Japan Azure User Group 16周年イベント 判断から通知まで の速度 通知から対応まで の速度 対応から次回改善 までの速度 67

良いSOCは、AIを入れたSOCではない 良いSOCの6つの性質 1 重要なものを早く見つける 4 高影響操作に人の判断を残す 2 なぜそう判断したか説明できる 5 過去の判断を次回へ活かす 3 失敗や不足情報を隠さない 6 運用指標を見て改善できる このプロジェクトは、その状態へ向かうための実装基盤です。 Japan Azure User Group 16周年イベント 68

自動化の対象は「判断」ではなく「判断の準備」 単にLLMへアラートを渡して要約させることではなく、次の5つを一つの運用フローとして接続しています 集める 揃える 説明する 戻す 学ぶ Sentinel、Log Analytics、ARM API 、過去ナレッジから 判断に必要な情報を 集める Alert/Incidentや Logic Appsの入力差 異を正規化し、同じ ルールで扱う 優先度、分類、信頼 度、根拠、不足情報 、推奨アクションを 構造化する Teamsへ通知し、承 認状態を管理し、 Sentinelへ監査証跡 を書き戻す アナリストが承認し たFeedbackだけを 次回の類似ケースへ 限定的に反映する 一方で、人の承認は残す 自動化の成熟度の測り方 アカウント無効化や端末隔離など、誤操作の影響が大きい 処理は、人の承認を残します 「どれだけ人を排除したか」ではなく、「アナリストが高 い価値の判断へ集中できるようになったか」で測ります Japan Azure User Group 16周年イベント 69

運用へ進める順番：根拠と監査が先 1 まず 根拠と監査を安定させ る 2 次に 承認・Feedback・評価 を本番化する 3 その後に 限定的な対応自動化を 検討する 最初から自動封じ込めへ進まない 失敗しても黙らない仕組みと、ロールバック可能性を先に作ることが重要です Japan Azure User Group 16周年イベント 70

講演の最後に確認したい3点 1 AIは結論を出すだけでなく、根拠と不足情報を示す必要がある 2 人の承認は自動化の妨げではなく、高リスク操作を安全に進める制 御点である 3 SOCの継続改善には、通知、証跡、Feedback、評価を同じループへ 戻す設計が必要である Japan Azure User Group 16周年イベント 71

自動化するのは、判断の準備。 Japan Azure User Group 16周年イベント 72

Thank you ご清聴ありがとうございました ロホマン シャヒン Microsoft Student Ambassador Gh-CUG運営 Portfolio Japan Azure User Group 16周年イベント JAZUG１６周年イベント ｜ 2026/10/3 73

GitHub Copilot Night YonaYona Azure Club × Gh-CUG 10月22日（木）21:00〜22:00 オンライン開催 ｜ 参加無料 GitHub CopilotでAzureアプリ開発が変わる？ Azure Toolsの新機能を検証 登壇：ロホマン シャヒン 参加登録はこちら yonayona.connpass.com/event/407635/ Japan Azure User Group 16周年イベント GitHub Copilot Night ｜ 2026/10/22 イベント詳細 イベント詳細 74

• https://gh-cug.connpass.com/event/407716/