2026年5月14日に公開・更新された公式情報で、Microsoft Sentinel の Model Context Protocol（MCP）tools を Azure Logic Apps に組み込み、インシデント内のユーザーやURLを自動分析する方法が示されました。Microsoft Defenderを中心にSOC運用をしている管理者にとってのポイントは、Defenderポータル上のMicrosoft Sentinel運用で、Entity Analyzerをプレイブックに組み込みやすくなったことです。これは単なる機能追加ではなく、インシデント調査、SOAR自動化、権限設計、Logic Appsの同時実行、コスト管理に影響します。まずは「Microsoft Sentinel data lakeの利用状況」「Sentinel SOAR Essentialsの更新」「接続IDの権限」「同時実行数」「プレビュー機能としての扱い」を確認してください。(Microsoft Learn)
Microsoft Defender運用で今回確認すべき変更点
今回の公式情報は、Microsoft Defenderそのもののマルウェア対策エンジン更新ではありません。中心は、Microsoft Defenderポータルで利用するMicrosoft Sentinelの自動化機能です。Microsoftは、Microsoft Sentinel MCP toolsをAzure Logic Appsから利用できるようにし、最初の対象としてEntity Analyzer toolを示しています。Entity AnalyzerはMicrosoft Sentinel data lakeのデータを使い、ユーザーやURLエンティティについて複数のデータポイントをまとめ、判定や根拠を返す機能です。(Microsoft Learn)
従来、SOC担当者や自動化エンジニアは、ユーザーのサインイン履歴、アラート証跡、脅威インテリジェンス、URLクリック履歴などを個別に集め、KQLや外部連携でエンリッチメント処理を作り込む必要がありました。今回のLogic Apps連携では、その一部を「Entity Analyzer」アクションとしてプレイブックに組み込み、インシデントのコメントとして分析結果を残せます。(Microsoft Learn)
| 確認項目 | 変更・追加された内容 | 管理者が見るべきポイント |
|---|---|---|
| Logic Apps連携 | Microsoft Sentinel MCP tools connectorからEntity Analyzerを呼び出せる | 既存プレイブックに追加するか、テンプレートから新規作成するかを判断する |
| 対象エンティティ | Logic Appsの手順ではユーザーとURLの分析が示されている | フィッシングURL、侵害疑いユーザーの初期トリアージに向く |
| テンプレート | Incident Trigger Entity Analyzer、Url Trigger Entity Analyzer、HTTP Trigger Entity Analyzerが用意されている | まずテンプレートで検証し、必要に応じて既存フローへ組み込む |
| 認証 | Microsoft Entra ID、サービスプリンシパル、マネージドIDをサポート | 本番ではマネージドIDまたはサービスプリンシパルを使い、最小権限を徹底する |
| 同時実行 | 複数分析を同時に走らせると遅延やタイムアウトの原因になる | For eachのConcurrency controlを有効化し、並列度5から調整する |
影響範囲はMicrosoft DefenderポータルのSentinel運用が中心
影響を受けるのは、Microsoft DefenderポータルでMicrosoft Sentinelを使い、インシデント対応やプレイブック自動化を行っている組織です。Microsoft SentinelはMicrosoft Defenderポータルでも利用でき、Azure portalでのMicrosoft Sentinelサポートは2027年3月31日以降終了し、Defenderポータルのみで提供される予定です。既にAzure portal中心でSentinelを運用している場合、今回のような新しい自動化・AI連携を検証する前に、Defenderポータルへの移行計画も合わせて確認しておくべきです。(Microsoft Learn)
特に影響が大きいのは、次のようなチームです。
- Microsoft SentinelのインシデントをMicrosoft Defenderポータルで確認しているSOC
- フィッシングURL、アカウント侵害、パスワードスプレーなどの調査を自動化したい管理者
- Azure Logic AppsでMicrosoft Sentinelプレイブックを作成・保守している開発者
- Defender XDR、Defender for Endpoint、Defender for Identity、Defender for Cloud AppsなどのデータをSentinelに集約している組織
- 複数ワークスペース、複数テナントでインシデント対応を標準化したいMSSPや大規模SOC
一方で、Microsoft Sentinel data lakeを使っていない、Logic Appsのプレイブックを使っていない、またはDefenderポータルでSentinelを運用していない環境では、すぐに設定変更が必要になる可能性は高くありません。ただし、将来的にSentinelのAI活用やSOAR自動化を進める予定があるなら、今回の更新は早めに検証する価値があります。
Entity Analyzerでできること
Entity Analyzerは、Microsoft Sentinel data lake内の組織データを使い、ユーザーやURLなどのエンティティについてリスク判定と詳細な分析を返します。ユーザー分析では認証パターン、行動異常、組織内アクティビティなどを参照し、URL分析ではMicrosoftの脅威インテリジェンス、Microsoft Sentinel Threat Intelligence Platform、クリック、メール、通信アクティビティ、ウォッチリストなどを使って分析します。(Microsoft Learn)
たとえば、Microsoft Defenderでフィッシング関連のインシデントが作成された場合、プレイブックでインシデント内のURLを取り出し、Entity Analyzerに渡します。分析結果に「組織内で誰がクリックしたか」「脅威インテリジェンス上の評価」「関連する証跡」が含まれれば、アナリストは最初の判断を短時間で行えます。
ユーザー侵害の疑いがある場合も同様です。対象ユーザーのMicrosoft EntraオブジェクトIDまたはUPNを渡し、サインイン、アラート、クラウドアプリ利用、ID情報などをもとに判定を受け取れます。公式情報では、Logic AppsからEntity Analyzerを実行すると、分析結果をインシデントのコメントとして残せる例が示されています。(Microsoft Learn)
ただし、Entity Analyzerの結果は「自動判断の材料」として扱うべきです。侵害ユーザーの無効化、端末隔離、メール削除などの強い是正アクションに直結させる場合は、少なくとも初期導入時は承認ステップを入れることをおすすめします。AIによる判定を完全自動化するより、まずは「分析結果をインシデントに追記する」「アナリストに通知する」「高リスク時だけ承認付きで対応する」という段階導入が安全です。
導入前に確認すべき前提条件
Microsoft Sentinel MCP toolsの多くは、Microsoft Sentinel data lakeへのオンボードが前提です。また、MCP toolsの利用にはSecurity readerロールが必要とされています。Logic Appsコネクタの認証では、Microsoft Entra ID、サービスプリンシパル、マネージドIDがサポートされ、Logic AppのIDにもSecurity readerが必要と明記されています。(Microsoft Learn)
さらに、Entity AnalyzerはSecurity Compute Units（SCUs）を消費してリスク分析を行うため、関連する権限や利用状況の確認も必要です。MicrosoftのEntity Analyzer説明では、Security Copilot Contributorが必要で、SCU使用量の確認にはSecurity Copilot Ownerが必要とされています。Logic Appsコネクタ側でSecurity readerを設定していても実行時に権限エラーが出る場合は、MCP tools側、Security Copilot側、ワークスペース側の権限を切り分けて確認してください。(Microsoft Learn)
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| Microsoft Sentinel data lake | 対象ワークスペースがdata lakeにオンボード済みか | ワークスペースIDを指定しても、必要なデータがdata lakeにない |
| Sentinel SOAR Essentials | Content hubでインストール・更新済みか | テンプレートが見つからない、古いテンプレートを使う |
| 権限 | Security reader、Logic Apps関連ロール、必要に応じてSecurity Copilot関連ロールを確認 | 接続は作れても実行時に失敗する |
| データテーブル | AlertEvidence、SigninLogs、CloudAppEvents、IdentityInfoなどがあるか | 分析精度が落ちる、またはエラーメッセージが返る |
| リージョン | 利用リージョンとコネクタの提供範囲を確認 | Government、China、DoD環境では対象外になる場合がある |
| コスト | Logic Apps、KQLクエリ、SCU消費を確認 | 検証環境で大量実行し、想定外の利用量になる |
既存テンプレートからLogic Appを作成する手順
最短で試すなら、既存テンプレートを使う方法が現実的です。公式手順では、Entity Analyzer向けの既存テンプレートを使う前に、Microsoft Defenderポータルの「Microsoft Sentinel > Content management > Content hub」からSentinel SOAR Essentialsソリューションがインストール済みか、最新状態かを確認するよう案内されています。(Microsoft Learn)
手順は次の流れです。
| 手順 | 操作 |
|---|---|
| 1 | Microsoft Defenderポータルを開く |
| 2 | 「Microsoft Sentinel > Content management > Content hub」でSentinel SOAR Essentialsをインストールまたは更新する |
| 3 | 「Microsoft Sentinel > Configuration > Automation」に移動する |
| 4 | 「Playbook templates」を選択し、Entity Analyzerで検索する |
| 5 | Incident Trigger Entity Analyzer、Url Trigger Entity Analyzer、HTTP Trigger Entity Analyzerのいずれかを選ぶ |
| 6 | Create playbookで作成し、接続、権限、対象ワークスペースを確認する |
| 7 | テスト用インシデントで実行し、コメントに分析結果が追記されるか確認する |
テンプレートを使うメリットは、設計ミスを減らせることです。特に初回検証では、いきなり既存の本番プレイブックへ追加するより、テンプレートで入力・出力・実行時間・コメント形式を確認してから、既存フローに移植する方が安全です。
既存のLogic AppにEntity Analyzerを追加する手順
既存のプレイブックに組み込む場合は、Logic Appを開き、新しいアクションとしてEntity Analyzerを追加します。公式手順では、「Add a new action」からentity analyzerを検索し、Microsoft Sentinel MCP tools connector配下のアクションを選択します。入力にはWorkspace ID、Look Back Days、Propertiesが必要です。(Microsoft Learn)
URLを分析する場合のProperties例は次のとおりです。
{
"entityType": "Url",
"url": "https://example.com/suspicious-path"
}ユーザーを分析する場合は、Microsoft EntraオブジェクトIDまたはUser Principal Nameを指定します。
{
"entityType": "User",
"userId": "[email protected]"
}Look Back Daysは、分析対象期間を指定する重要な値です。短すぎると根拠が不足し、長すぎると処理時間やコストが増えやすくなります。たとえば、フィッシングURLの初期調査なら直近1〜3日、アカウント侵害の疑いなら直近7日程度から検証し、実際のインシデント量や分析結果に応じて調整するとよいでしょう。
複数ワークスペースを運用している場合は、Workspace IDの指定ミスにも注意してください。インシデントが発生したワークスペースと、Entity Analyzerに渡すワークスペースがずれると、期待した証跡が見つからない可能性があります。動的値を使う場合も、実行履歴で実際に渡された値を必ず確認しましょう。
データ不足で分析精度が落ちるケース
Entity Analyzerは、参照できるデータが多いほど有用な判断材料を返しやすくなります。ユーザー分析では、AlertEvidence、SigninLogs、CloudAppEvents、IdentityInfoが重要です。IdentityInfoは、Microsoft Defender for Identity、Microsoft Defender for Cloud Apps、Microsoft Defender for Endpoint P2などのライセンス条件に関係する場合があります。オンプレミスActive Directoryのみのユーザーは、analyze_user_entityの対象外とされています。(Microsoft Learn)
URL分析では、EmailUrlInfo、UrlClickEvents、ThreatIntelIndicators、Watchlist、DeviceNetworkEventsがあると効果的です。これらがない場合でもリスク評価が続行されることはありますが、不足テーブルに関する免責や案内が返る可能性があります。(Microsoft Learn)
実務では、導入前に次のような確認をしておくと、検証がスムーズです。
| 分析対象 | 確認したいデータ | 代表的な確認ポイント |
|---|---|---|
| ユーザー | サインイン、アラート証跡、クラウドアプリ操作、ID情報 | Entra IDサインインログが入っているか、Defender系データが連携されているか |
| URL | メール内URL、クリック履歴、脅威インテリジェンス、端末通信 | Defender for Office 365やEndpointの関連データがSentinel側で使えるか |
| インシデント | インシデント内のユーザー・URLエンティティ | プレイブックのトリガーで必要なエンティティを取り出せるか |
| ワークスペース | Workspace ID、data lakeオンボード状態 | 複数環境で開発・本番のIDを取り違えていないか |
同時実行とタイムアウトの設計が重要
Entity AnalyzerをFor eachループで複数ユーザーや複数URLに対して実行すると、同時分析が増え、各実行の遅延やタイムアウトにつながる可能性があります。Microsoftは、For eachアクションでConcurrency controlを有効化し、Degree of parallelismをまず5に設定して、組織のトリガー頻度に応じて調整することを案内しています。(Microsoft Learn)
また、Entity Analyzer MCP toolには、テナントごとに1時間あたり200回、1日あたり500回、5分あたり約15同時実行というプレビュー段階の制限が示されています。分析結果は1時間利用可能で、それ以降は再実行が必要です。(Microsoft Learn)
本番展開では、単に「全エンティティを分析する」設計にしないことが重要です。たとえば、1つのインシデントにURLが50件含まれている場合、すべてを無条件に分析すると、制限やコストにすぐ近づきます。次のように絞り込むと安定します。
- 重複URLを除外する
- 社内ドメインや既知の安全なドメインを除外する
- 高重大度インシデントだけEntity Analyzerを実行する
- 1インシデントあたりの分析件数に上限を設ける
- 分析済みエンティティは再実行せず、既存コメントやキャッシュを参照する
コストとライセンスで見落としやすい点
Microsoft Sentinel MCP toolsのdata lake系機能では、KQLクエリでデータを検索・取得する呼び出しに対して課金が発生します。Entity Analyzerでは、Microsoft Sentinel data lake上で実行されるKQLクエリに加え、リスク分析に必要なSecurity Compute Units（SCUs）も課金対象として説明されています。さらに、Microsoft SentinelプレイブックはAzure Logic Appsを使うため、Logic Apps側の追加料金も発生する可能性があります。(Microsoft Learn)
検証時は、次の3つを分けて見積もると判断しやすくなります。
| コスト要素 | 発生しやすい場面 | 抑制策 |
|---|---|---|
| Logic Apps実行 | インシデントごとにプレイブックを自動実行する | 高重大度のみ、または特定カテゴリのみでトリガーする |
| KQLクエリ | Entity Analyzerがdata lakeから証跡を取得する | Look Back Daysを必要最小限にする |
| SCU | Entity Analyzerがリスク分析を行う | 大量のURL・ユーザーに無条件実行しない |
特に開発者が検証環境でループ処理を作る場合、テストインシデントを何度も再実行して想定以上に消費することがあります。実行履歴、分析対象件数、失敗時のリトライ回数をログとして残し、最初は少数のインシデントで確認してください。
リージョン、提供範囲、プレビュー機能の注意点
Microsoft Sentinel MCP toolsはプレビュー情報を含むため、正式リリース前に仕様が変わる可能性があります。公式ページでも、プレビュー製品に関する情報はリリース前に大きく変更される可能性があると説明されています。(Microsoft Learn)
コネクタの提供範囲にも注意が必要です。Microsoft Sentinel MCP connectorはプレビューで、Logic Apps StandardではAzure Government、Azure China、US Department of Defense（DoD）を除くLogic Appsリージョンで利用可能とされています。Power AutomateやCopilot Studioなどの提供範囲は別扱いです。(Microsoft Learn)
また、Microsoft Sentinel MCP toolsの言語・地域可用性では、日本を含む複数地域が示されていますが、プロンプトは英語のみサポートされています。Logic Appsで固定アクションとして使う場合でも、MCP toolsやカスタムツール、エージェント連携まで広げるなら、英語プロンプト前提の運用設計にしておくと混乱を避けられます。(Microsoft Learn)
Azure portalからDefenderポータルへの移行も同時に確認する
Microsoft SentinelをまだAzure portal中心で運用している場合、今回の更新だけを見るのではなく、Defenderポータルへの移行をセットで確認してください。Microsoft SentinelはDefenderポータルで利用でき、Azure portalでのMicrosoft Sentinelサポートは2027年3月31日以降終了予定です。(Microsoft Learn)
移行時に特に確認したいのは、データ収集、コネクタ表示、権限、データ保持・処理ポリシーです。Microsoftの移行ガイドでは、Defender統合後も基本的なデータ収集とテレメトリの流れは維持され、Log Analyticsの取り込みパイプラインやデータスキーマにも変更はないと説明されています。一方で、Defenderポータル利用時にはMicrosoft Defender XDRのデータ保存・処理・共有ポリシーが適用される点も示されています。(Microsoft Learn)
つまり、既存のプレイブックがすぐ壊れるとは限りませんが、運用画面、権限、コネクタの見え方、ポリシーの適用範囲は変わります。Entity Analyzerのような新しい自動化を追加する前に、Defenderポータル側で次を確認しておきましょう。
- Microsoft SentinelワークスペースがDefenderポータルにオンボードされているか
- Microsoft Defender XDR connectorでインシデントとアラートが有効か
- 既存の分析ルール、オートメーションルール、プレイブックが見えるか
- Microsoft Sentinel Automation Contributorなど、プレイブック実行に必要な権限が付与されているか
- Azure portalとDefenderポータルで、運用手順書の画面遷移がずれていないか
本番展開でおすすめの設計パターン
最初から完全自動対応にするより、段階的に自動化レベルを上げる設計が安全です。おすすめは次の3段階です。
| 段階 | 自動化内容 | 判断基準 |
|---|---|---|
| 検証段階 | Entity Analyzerの結果をインシデントコメントに追記するだけ | 出力内容、処理時間、失敗率、コストを確認する |
| 半自動段階 | 高リスク判定時にTeams通知やチケット起票を行う | アナリストが結果を確認して対応する |
| 制御付き自動化 | 一定条件を満たす場合のみアカウント無効化や隔離を実行する | 承認ステップ、例外リスト、ロールバック手順を用意する |
実務で特に有効なのは、フィッシング対応です。インシデントが作成されたら、URLを抽出し、重複を除外し、Entity Analyzerで分析し、結果をインシデントコメントに残します。そのうえで、高リスクURLだけをアナリストに通知し、必要に応じてメール追跡や端末通信調査へ進みます。
アカウント侵害対応では、対象ユーザーをEntity Analyzerに渡し、サインイン異常や関連アラートを確認します。ただし、ユーザー無効化やセッション取り消しを自動化する場合は、役員、サービスアカウント、緊急アクセスアカウントなどを例外リストに入れる必要があります。Entity Analyzerの判定だけで一律に強制対応すると、業務影響が大きくなる恐れがあります。
管理者と開発者が今日確認すべきチェックリスト
今回のMicrosoft Defender関連更新に対応するなら、まず次の順で確認してください。
| 優先度 | 確認すること | 完了の目安 |
|---|---|---|
| 高 | Microsoft Sentinel data lakeが対象ワークスペースで使えるか | MCP toolsの前提を満たしている |
| 高 | Sentinel SOAR EssentialsがContent hubで最新か | Entity Analyzerテンプレートが表示される |
| 高 | Logic Appの接続IDにSecurity readerなど必要権限があるか | テスト実行で権限エラーが出ない |
| 高 | For eachの同時実行制御を設定しているか | Degree of parallelismを5から開始している |
| 中 | ユーザー・URL分析に必要なテーブルが揃っているか | 不足テーブルによるエラーや免責が少ない |
| 中 | Logic Apps、KQL、SCUのコストを分けて監視しているか | 検証実行の利用量を把握できる |
| 中 | Azure portalからDefenderポータルへの移行計画があるか | 2027年3月31日を見据えた運用手順がある |
| 低 | 自動是正アクションに承認や例外リストを入れているか | 誤検知時の業務影響を抑えられる |
今回の更新は、Microsoft DefenderポータルでのMicrosoft Sentinel運用を、よりAI支援型のSOARへ進めるための重要な一歩です。まずはテンプレートで小さく検証し、分析結果の品質、必要な権限、実行時間、コストを確認してください。そのうえで、フィッシングURL調査やユーザー侵害調査など、手作業の負荷が大きい領域から段階的にLogic Appsへ組み込むのが現実的です。
コメント