Microsoft Defender環境でAIエージェントを活用するなら、まず押さえるべき結論は「Microsoft FoundryのエージェントにMicrosoft Sentinel MCP toolを接続すると、Sentinel data lakeやDefenderのセキュリティデータを自然言語で扱えるようになる」という点です。標準のツールコレクションを追加するだけなら手順は比較的シンプルですが、実運用ではライセンス、ロール、ワークスペース、OAuth認証、データレイクの課金・リージョン・権限設計まで確認が必要です。なお、Microsoft Learn上ではFoundryでの追加手順ページはプレビュー扱いで最終更新日が2026年4月27日、関連するカスタムMCPツール、ツールコレクション、データレイク前提条件のページは2026年5月14日更新として公開されています。本記事では、それらの公式情報を合わせてMicrosoft Defender管理者・開発者向けに整理します。(Microsoft Learn)
Microsoft Sentinel MCP tool in Microsoft Foundryとは
Microsoft Sentinel MCP tool in Microsoft Foundryは、Microsoft Foundryで作成するAIエージェントに、Microsoft SentinelのModel Context Protocol（MCP）ツールを接続して使うための仕組みです。
MCPは、AIモデルが外部ツールやコンテキストに構造化された形でアクセスするためのプロトコルです。Microsoft SentinelのMCPサポートでは、セキュリティデータの探索、エンティティ分析、インシデントトリアージ、脅威ハンティングなどに使えるツール群が提供されます。Microsoftの公式説明では、Sentinel MCP ServerはMicrosoft EntraによるIDを使い、互換クライアントから接続できるホスト型の統合インターフェイスとして位置づけられています。(Microsoft Learn)
Microsoft Foundry側では、エージェント作成画面からSentinelのツールコレクションを追加できます。たとえば「Microsoft Sentinel – Data exploration」のようなコレクションを選ぶと、エージェントがSentinel data lake内のデータ探索や分析に必要なツールを呼び出せるようになります。(Microsoft Learn)
重要なのは、これは単なるチャット補助ではないという点です。AIエージェントが、組織のセキュリティデータを参照し、状況に応じてツールを呼び出し、調査・要約・トリアージを支援する仕組みです。そのため、便利さと同時に「どのデータへアクセスできるのか」「誰がツールを作成・実行できるのか」「どのワークスペースを対象にするのか」を管理する必要があります。
2026年5月更新情報で押さえるべき変更点
今回の公式情報で管理者が見るべきポイントは、Microsoft Sentinel MCP toolをMicrosoft Foundry、Security Copilot、Copilot Studio、Visual Studio Codeなど複数のエージェント環境で使う流れが整理され、特にカスタムMCPツールの作成・利用手順が明確化された点です。カスタムMCPツールは、Microsoft DefenderポータルのAdvanced huntingやSentinel data lakeのKQLクエリをもとに作成でき、エージェントが参照できるデータを細かく制御できます。(Microsoft Learn)
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| プレビュー扱い | Foundryでの利用手順はプレビュー情報として公開されています | 本番展開前に仕様変更リスクを織り込む必要があります |
| 標準ツールコレクション | Data exploration、Security Copilot agent creation、Triageなどのコレクションが用意されています | まずは標準コレクションでPoCを始めやすくなります |
| カスタムMCPツール | DefenderのAdvanced huntingやSentinel data lakeのKQLクエリをツール化できます | エージェントが扱うデータ範囲を業務目的に合わせて絞れます |
| ロール要件 | 作成・更新・削除にはSecurity Operator、Security Admin、Global Adminなどが必要です | 開発者だけで完結せず、セキュリティ管理者との連携が必要です |
| データレイク前提 | 多くのMCPツールではMicrosoft Sentinel data lakeへのオンボードが必要です | Defender、Sentinel、Azureサブスクリプション、ワークスペース設計を事前確認する必要があります |
| OAuth設定 | カスタムツールではアプリ登録、APIアクセス許可、リダイレクトURI、シークレットが必要です | Entra ID管理者やAzure管理者が関与する可能性があります |
影響範囲はMicrosoft Defender管理者だけに限られない
Microsoft Sentinel MCP tool in Microsoft Foundryの導入は、Microsoft Defender管理者だけの作業ではありません。AIエージェント、Sentinel data lake、Microsoft Entra ID、Azureサブスクリプション、ワークスペース権限が関係するため、複数の担当者で影響範囲を確認する必要があります。
| 関係者 | 主な確認事項 |
|---|---|
| Microsoft Defender管理者 | Advanced hunting、Defenderポータル、Sentinel data lake連携、対象データの範囲 |
| Sentinel管理者 | ワークスペース、データレイク、テーブル、KQL、ロール、課金影響 |
| Entra ID管理者 | アプリ登録、APIアクセス許可、OAuth同意、リダイレクトURI、シークレット管理 |
| Azure管理者 | サブスクリプション、リソースグループ、Azure Policy、マネージドID、リージョン |
| SOCアナリスト | 調査プロンプト、トリアージ手順、ハンティング用途、誤回答時の確認フロー |
| AI・開発担当者 | Foundryエージェント設計、ツール選択、カスタムツールの説明文、テスト設計 |
| コンプライアンス担当 | データ所在地、Microsoft 365データの取り扱い、権限最小化、監査証跡 |
特に注意したいのは、Microsoft Sentinel data lakeにオンボードすると、接続済みワークスペースやデータ階層、課金、補助ログテーブルの扱いに影響が出る場合がある点です。公式情報では、同一リージョンのDefender接続済みワークスペースがデータレイクに自動的に関連付けられること、補助ログテーブルがDefender Advanced huntingではなくデータレイク探索KQLクエリから利用されるようになること、既存のSentinel SIEM利用状況によっては課金メーターが変わりコストが増える可能性があることが説明されています。(Microsoft Learn)
導入前に確認すべき前提条件
Microsoft FoundryでSentinel MCP toolを使う前に、次の条件を確認します。ここを飛ばすと、接続できてもツールが呼び出されない、結果が返らない、権限エラーになる、といった問題が起きやすくなります。
| 確認項目 | 判断基準 |
|---|---|
| Microsoft Sentinel data lake | 多くのMCPツールで前提となるため、オンボード済みか確認します |
| Microsoft Defenderポータル | DefenderポータルとMicrosoft Sentinelが構成済みか確認します |
| ライセンス | カスタムMCPツールではMicrosoft Sentinel data lakeとMicrosoft Defenderライセンスが前提です |
| ロール | ツール作成・更新・削除はSecurity Operator、Security Admin、Global Adminなど。実行・一覧取得はSecurity reader、Global readerなどを確認します |
| ワークスペース | 対象ワークスペースがDefenderに接続され、データレイク対象リージョンにあるか確認します |
| Azureサブスクリプション | データレイクの課金設定に使うサブスクリプションとリソースグループを確認します |
| Azure Policy | データレイクに必要なリソース作成をブロックするポリシーがないか確認します |
| データ保護方針 | Customer-Managed Keys（CMK）を使う組織では、Sentinel data lakeのCMK非対応に注意します |
| リージョン | Microsoft 365データとデータレイクのリージョンが異なる場合のデータ所在地を確認します |
Microsoft Sentinel data lakeのオンボードはDefenderポータルから開始します。オンボード時にはサブスクリプションとリソースグループを選び、データレイクはプライマリSentinelワークスペースと同じリージョンにプロビジョニングされます。公式情報では、オンボード処理に最大60分かかること、テーブルや階層を新しく有効化したデータが利用可能になるまで90〜120分かかる場合があることも説明されています。(Microsoft Learn)
Microsoft Foundryで標準のSentinelツールコレクションを追加する手順
標準のMicrosoft Sentinelツールコレクションを使う場合、Microsoft Foundry側の作業は比較的シンプルです。まずは標準コレクションで小さく検証し、効果とリスクを確認してからカスタムツールへ進むのが現実的です。
| 手順 | 作業内容 |
|---|---|
| 1 | Microsoft Foundryのagent builderを開き、BuildからAgentを選択します |
| 2 | エージェント名を入力します |
| 3 | ToolsパネルでAdd a new toolを選びます |
| 4 | ツール選択画面でSentinelを検索します |
| 5 | 利用目的に合うコレクションを選択します。例：Microsoft Sentinel – Data exploration |
| 6 | Connectを選び、エージェントに接続します |
| 7 | テストプロンプトを実行し、対象データ・ワークスペース・権限が期待通りか確認します |
接続後は、エージェントがSentinelのツールを呼び出してセキュリティデータを扱えるようになります。ただし、エージェントに曖昧な指示を出すと、ツールが呼び出されなかったり、期待したワークスペースとは別のデータを参照したりする可能性があります。初期検証では、対象ユーザー、期間、ワークスペースID、調査目的を明示したプロンプトを使うのが安全です。(Microsoft Learn)
たとえば、次のようなプロンプトから始めると検証しやすくなります。
過去24時間のサインイン失敗を確認し、件数が多いユーザー、送信元IP、通常と異なる傾向を要約してください。workspaceIdは<対象ワークスペースID>を使用してください。ユーザー<UPN>について、過去7日間のサインイン、デバイス、アラート、リスク情報を確認し、侵害の可能性を判断する材料を整理してください。パスワードスプレーに関連するアラートが出ているユーザーを調査し、優先的に確認すべきユーザーと理由を説明してください。カスタムMCPツールを使う場合の構成ポイント
標準コレクションは便利ですが、実務では「このKQLだけを使わせたい」「特定の調査フローだけを自動化したい」「エージェントが参照するデータを最小限にしたい」という要件がよくあります。その場合は、カスタムMCPツールを使います。
カスタムMCPツールは、Microsoft DefenderポータルのAdvanced huntingやSentinel data lakeのKQLクエリをもとに作成できます。公式情報では、検証済みのKQLクエリをSave as toolで保存し、ツール名、説明、コレクション、既定ワークスペース、必要に応じたパラメーターを設定する流れが示されています。(Microsoft Learn)
DefenderのKQLクエリをツール化する
カスタムツール化するKQLは、エージェントに渡してよいデータ範囲に絞ることが重要です。たとえば、SOCアナリストがユーザー調査に使うツールであれば、期間、対象ユーザー、返す列、件数上限を明確にします。
避けたい例は、全期間・全列・全ユーザーを広く返すKQLです。AIエージェントの回答品質が落ちるだけでなく、不要な情報露出や処理負荷につながります。
実務では、次のような設計にすると扱いやすくなります。
| 設計項目 | 推奨される考え方 |
|---|---|
| ツール名 | get_user_signin_risk_summaryのように用途が分かる名前にします |
| 説明文 | 「指定ユーザーのサインイン失敗とリスクイベントを取得する」のように短く行動ベースで書きます |
| パラメーター | UPN、TimeRange、workspaceIdなど、調査に必要な値だけを渡します |
| 返却データ | 調査判断に必要な列だけ返します |
| 期間 | 既定値を24時間、7日間、30日間など用途別に決めます |
| ワークスペース | 既定ワークスペースを設定し、必要に応じてプロンプトで明示します |
公式のベストプラクティスでも、ツール説明は短く、目的が分かり、AIモデルが選びやすい表現にすることが推奨されています。パラメーターの詳細は説明文に詰め込みすぎず、スキーマ側で扱うのが基本です。(Microsoft Learn)
Azureアプリ登録とOAuth設定を行う
Microsoft FoundryでカスタムMCPツールを使うには、Azure portalでアプリ登録を作成し、Sentinel Platform ServicesのSentinelPlatform.DelegatedAccessを追加します。その後、クライアントシークレットを作成し、Application（client）ID、Directory（tenant）ID、シークレット値を控えます。(Microsoft Learn)
Microsoft Foundry側では、エージェントのToolsからCustom、Model Context Protocol（MCP）を選び、リモートMCPサーバーのエンドポイントやOAuth情報を入力します。公式手順では、カスタムコレクションのエンドポイント形式は次のように示されています。(Microsoft Learn)
https://sentinel.microsoft.com/mcp/custom/<name of your custom collection>OAuth関連の入力では、次の形式を使います。
Token URL:
https://login.microsoftonline.com/<tenant ID>/oauth2/v2.0/token
Authorization URL:
https://login.microsoftonline.com/<tenant ID>/oauth2/v2.0/authorize
Scope:
4500ebfb-89b6-4b14-a480-7f749797bfcd/.default,offline_access接続後、Microsoft Foundryで生成されるリダイレクトURLをAzureアプリ登録のWebプラットフォームに追加します。その後、初回実行時にユーザーが同意することで、エージェントがカスタムMCPツールの返すデータを使って推論できるようになります。(Microsoft Learn)
管理者が注意すべき設定ミスと対策
Microsoft Sentinel MCP toolは、設定項目が多いため、接続エラーよりも「つながっているように見えるが期待通り動かない」問題が起きやすいです。特に、ツール選択、ワークスペース、権限、テナント、プロンプトの曖昧さに注意します。
| 症状 | よくある原因 | 対策 |
|---|---|---|
| ツールが呼び出されない | ツールの意味が重複している、ツール数が多い、会話コンテキストが優先されている | 目的に合うコレクションだけを選び、新しい会話で検証します |
| 回答が根拠データに乏しい | プロンプトが曖昧、対象期間やユーザーが不明 | ユーザー、期間、ワークスペース、調査目的を明示します |
| 別ワークスペースのデータが使われる | 複数ワークスペースにアクセスできる | list_workspacesで確認し、プロンプトにworkspace IDを明記します |
| 結果が返らない | テーブルが存在しない、クエリが絞り込みすぎ、権限不足 | テーブルの存在、KQL条件、ユーザー権限を確認します |
| HTTP 403が出る | MCPクライアントが認証仕様に対応していない可能性 | クライアントを最新化し、認証方式を確認します |
| HTTP 404が出る | テナント未登録、データレイク未接続、ワークスペース権限不足など | データレイクへのオンボード、ワークスペース接続、アクセス権を確認します |
| ゲストユーザーで認証テナントがずれる | ホームテナントのトークンが使われる | 必要に応じてx-mcp-client-tenant-idヘッダーやホームテナント所属アカウントの利用を検討します |
| 既定ワークスペースが見えない | System tablesに有効なworkspace IDがない場合がある | プロンプトでdefaultをworkspaceIdとして使う旨を明示します |
Microsoftのトラブルシューティング情報では、MCPクライアントを最新に保つこと、プロンプトを具体化すること、複数ワークスペースを扱う場合はworkspace IDを明示することが推奨されています。(Microsoft Learn)
移行・展開時に確認すべき実務ポイント
Microsoft DefenderやMicrosoft Sentinelをすでに運用している組織では、MCPツールの追加だけを見て導入判断をしないことが重要です。特にSentinel data lakeのオンボードは、ワークスペース、課金、ログの見え方、リージョン、Azure Policyに影響します。
データレイクのサブスクリプションとリソースグループは慎重に選ぶ
DefenderポータルからSentinel data lakeをオンボードする際、課金に使うAzureサブスクリプションとリソースグループを選びます。公式手順では、一度データレイクが特定のサブスクリプションとリソースグループにプロビジョニングされると、別のサブスクリプションやリソースグループへ移行できないと説明されています。(Microsoft Learn)
本番導入前に、次の点を確認してください。
- 既存のSentinel課金管理と整合しているか
- セキュリティ運用チームがコストを追跡できるか
- 将来のデータ量増加を見込んだ予算管理ができるか
- Azure Policyが必要なリソース作成を妨げないか
- リソースグループに対するポリシー例外が必要か
Customer-Managed Keysを使う組織はデータ保護方針を確認する
公式情報では、Microsoft Sentinel data lakeに保存されるデータについてCustomer-Managed Keys（CMK）がサポートされないと説明されています。CMKを前提にした暗号化ポリシーを持つ組織では、オンボード前にセキュリティ基準や監査要件との整合を確認する必要があります。(Microsoft Learn)
補助ログテーブルの参照場所が変わる可能性を確認する
Sentinel data lakeを有効化すると、Microsoft Defender接続済みワークスペースの補助ログテーブルはデータレイクの一部として扱われ、Defender Advanced huntingからはアクセスできなくなると説明されています。代わりに、Defenderポータルのデータレイク探索KQLクエリから利用します。(Microsoft Learn)
既存のSOC手順書やハンティング手順でAdvanced huntingを前提にしている場合は、次の見直しが必要です。
| 見直し対象 | 対応 |
|---|---|
| 既存KQL | Advanced hunting用とデータレイク探索用を分けて整理します |
| 手順書 | 補助ログテーブルの参照先を更新します |
| 教育 | SOCアナリストにデータレイク探索の使い方を共有します |
| 自動化 | 既存スクリプトやブックが影響を受けないか確認します |
権限は最小権限で設計する
カスタムMCPツールを作るには強い権限が必要です。便利だからといってGlobal Adminで常用すると、運用リスクが高くなります。作成者、承認者、利用者を分け、日常運用ではSecurity OperatorやSecurity Adminなど必要なロールに絞る設計が望ましいです。
また、アプリ登録のクライアントシークレットは漏えいリスクがあります。公式手順では、1つのアプリを複数のカスタムツール用に使い、カスタムコレクションごとに別のクライアントシークレットを作成するヒントが示されています。実務では、シークレットの有効期限、保管場所、ローテーション、削除手順も合わせて決めておきましょう。(Microsoft Learn)
開発者がカスタムツール設計で意識すべきこと
開発者にとってのポイントは、「AIに何でも聞けるようにする」ことではなく、「AIが安全に呼び出せる業務用ツールを設計する」ことです。Microsoft Sentinel MCP toolは、エージェントがツールを選んで実行するため、ツール名や説明文が曖昧だと誤ったツールが選ばれる可能性があります。
ツール説明は短く、用途を明確にする
悪い説明の例です。
ユーザーに関するいろいろなセキュリティ情報を確認するツールです。この説明では、サインインを調べるのか、アラートを調べるのか、デバイスを調べるのかが分かりません。
改善例です。
指定したユーザーの過去7日間のサインイン失敗、リスクイベント、関連アラートを取得し、侵害調査の初期判断に使う情報を返します。このように、対象、期間、返す情報、利用目的を明確にすると、エージェントが適切な場面でツールを選びやすくなります。
KQLは「人間が読むクエリ」ではなく「ツールとして安定するクエリ」にする
人間の調査では、途中で条件を変えながら探索できます。しかし、MCPツールとして保存するKQLは、入力と出力が安定していることが重要です。
チェックすべき観点は次の通りです。
| 観点 | 確認内容 |
|---|---|
| 入力 | UPN、deviceId、IP、期間など必要なパラメーターが明確か |
| 出力 | AIが要約しやすい列だけを返しているか |
| 件数 | 大量データを返しすぎないよう制限しているか |
| 時間条件 | 既定の期間が業務目的に合っているか |
| エラー時 | データがない場合でも解釈しやすい結果になるか |
| 権限 | 利用者が参照できないテーブルを前提にしていないか |
プロンプトではワークスペースと判断基準を明示する
「このユーザーは危険ですか？」という聞き方では、AIの判断が曖昧になります。代わりに、何を確認し、どの基準で判断するかを指定します。
workspaceId <対象ID> を使い、ユーザー <UPN> の過去7日間のサインイン失敗、リスクイベント、関連アラートを確認してください。通常と異なる国・IP・デバイスがある場合は、根拠となるイベントと優先度を示してください。このように指定すると、エージェントがツールを呼び出す条件が明確になり、SOCアナリストが次の対応を判断しやすくなります。
本番展開の進め方
Microsoft Sentinel MCP tool in Microsoft Foundryは、いきなり全社展開するよりも、対象を絞って検証する方が安全です。おすすめの進め方は次の通りです。
| フェーズ | やること | 成功基準 |
|---|---|---|
| 事前確認 | ライセンス、ロール、データレイク、ワークスペース、リージョンを確認 | 接続前提に不足がない |
| 小規模PoC | 標準のData explorationコレクションをFoundryエージェントに追加 | 指定ワークスペースのデータを期待通り参照できる |
| 業務シナリオ化 | サインイン失敗、パスワードスプレー、URL IOC分析など用途を決める | SOC担当者が調査時間短縮を実感できる |
| カスタムツール化 | よく使うKQLをMCPツールとして保存 | 返却データが必要最小限で安定している |
| ガバナンス整備 | 権限、シークレット、監査、手順書、プロンプト例を整備 | 本番利用時の責任範囲が明確 |
| 段階展開 | 対象チーム、ワークスペース、ユースケースを広げる | 誤用や権限過多を避けながら利用を拡大できる |
最初のユースケースは、複雑な自動対応よりも「調査の初期要約」にすると失敗しにくいです。たとえば、サインイン失敗の傾向確認、リスクユーザーの上位抽出、パスワードスプレー関連アラートの一次整理などです。公式のサンプルプロンプトでも、危険なユーザーの抽出、過去24時間のサインイン失敗、異常なアウトバウンド接続、パスワードスプレー調査などが例として示されています。(Microsoft Learn)
Microsoft Defender管理者が今日確認すべきこと
Microsoft Sentinel MCP tool in Microsoft Foundryは、Microsoft DefenderとSentinel data lakeのデータをAIエージェントで活用するための有力な選択肢です。一方で、導入の成否はAI機能そのものよりも、データ、権限、ワークスペース、KQL、OAuth、運用ルールの設計に左右されます。
まずは、次の順番で確認してください。
- Microsoft Sentinel data lakeにオンボード済みか
- DefenderポータルとSentinelワークスペースが正しく接続されているか
- 利用者・作成者・承認者のロールが過不足なく割り当てられているか
- 対象ワークスペースとリージョン、データ所在地に問題がないか
- 標準ツールコレクションで小規模PoCを実施できるか
- カスタムMCPツール化したいKQLが、必要最小限のデータを返す設計になっているか
- OAuthアプリ登録、シークレット管理、リダイレクトURI、同意フローを運用できるか
- SOC手順書や既存のAdvanced hunting運用に影響がないか
最初にやるべきことは、Microsoft Foundryで標準のSentinelツールコレクションを接続し、限定されたワークスペースと明確なプロンプトで検証することです。その結果を見て、効果が大きい調査シナリオだけをカスタムMCPツール化すれば、過度な権限付与やデータ露出を避けながら、Microsoft Defender運用にAIエージェントを実用的に取り込めます。
コメント