Microsoft DefenderのLocal AI agent discoveryは、端末上で動くAIコーディング支援ツール、デスクトップAIアプリ、IDE拡張、MCPサーバー設定を棚卸しするためのプレビュー機能です。結論から言うと、管理者がまず確認すべきことは、Microsoft Defender for Endpointのオンボード状況、対象ライセンス、Defender Antivirusの有効状態、そしてDefenderポータルの「Assets > AI Agents > Local agents」に表示されるエージェント一覧です。
特に重要なのは、この機能が「AIエージェントを自動で止める機能」ではなく、まず見えていなかったローカルAIエージェントを資産として可視化する機能だという点です。シャドーAIエージェントの把握、MCP経由の接続先確認、特権ユーザー端末での利用状況の洗い出しに使うことで、セキュリティチームはエンドポイント上の新しい攻撃面を現実的に管理しやすくなります。Microsoft Learnでは、AI AssetsページとAdvanced HuntingでAIエージェントを確認する流れが2026年6月3日に更新され、ローカルAIエージェントもインベントリ対象に含まれることが示されています。(Microsoft Learn)
Microsoft Defenderのセキュリティ更新で何が変わったのか
今回のポイントは、Microsoft DefenderがローカルAIエージェントを単なるプロセスではなく、セキュリティ上の「資産」として扱い始めたことです。
これまで、開発者がClaude Code、Codex CLI、GitHub Copilot CLI、Cursor、Windsurf、ChatGPT Desktopなどを各自の端末に導入しても、セキュリティチームからは「誰が、どの端末で、どのAIエージェントを使っているか」が見えにくい状態でした。ローカルAIエージェントはユーザー権限で動作し、ファイル、ツール、サービスにアクセスできるため、可視性がないまま運用すると、機密情報やソースコード、クラウドリソースへの到達経路を見落とすリスクがあります。(Microsoft Learn)
Local AI agent discoveryでは、Microsoft Defenderがオンボード済みデバイス上のサポート対象ローカルAIエージェントとMCPサーバー構成を自動検出し、Defenderポータルに表示します。確認できる主な情報は、ローカルAIエージェントのインベントリ、エージェント・端末・ID・到達可能リソースの関係を示すExposure map、Advanced Huntingでの調査データです。(Microsoft Learn)
ただし、公式ドキュメントではLocal AI agent discoveryは発見と調査のための機能であり、エンドポイント上のAIエージェントに対するセキュリティ態勢評価やアラートは含まれないと説明されています。ブロックやアラートを期待する場合は、別機能であるAI agent runtime protectionやAI agent protectionの適用範囲を分けて確認する必要があります。(Microsoft Learn)
対象範囲と前提条件
Local AI agent discoveryの導入で最初に見るべきなのは、「機能があるか」ではなく「自社の端末が検出対象になる条件を満たしているか」です。公式ドキュメントでは、Microsoft Defender for Endpoint Plan 2、オンボード済みデバイス、サポート対象Windows、最新の月次プラットフォームおよびエンジン更新を適用したMicrosoft Defender Antivirus、Defender Antivirusのアクティブモード、商用クラウド環境が前提条件として示されています。(Microsoft Learn)
| 確認項目 | 管理者が見るべきポイント | 実務上の注意点 |
|---|---|---|
| ライセンス | Microsoft Defender for Endpoint Plan 2の対象か | 一部ユーザーだけが対象ライセンスの場合、棚卸し結果に偏りが出る |
| デバイス | Defender for Endpointにオンボード済みか | 開発者PC、検証端末、VDI、持ち出し端末を漏らしやすい |
| OSと更新状態 | サポート対象Windowsか、Defender Antivirusが最新か | 古い端末や更新停止端末は検出対象外になる可能性がある |
| AVの状態 | Microsoft Defender Antivirusがアクティブモードか | 他社EDR・AV併用時にパッシブモードになっていないか確認する |
| クラウド環境 | 商用クラウドか | Sovereign cloudやnational cloudはサポート外とされている |
| 展開作業 | 追加スクリプトや個別構成が必要か | 前提条件を満たせば、追加の展開やスクリプトなしで検出が始まる |
Microsoftの発表ブログでは、管理対象のWindowsおよびmacOSデバイスにまたがる20種類以上のローカルAIエージェント検出が説明されています。一方、Microsoft Learnの手順ページではWindowsエンドポイントの前提条件が明記されています。実運用では、ブログ発表だけで判断せず、自社テナントのDefenderポータル表示と最新のLearnドキュメントで対象OSを確認するのが安全です。(TECHCOMMUNITY.MICROSOFT.COM)
検出対象になるローカルAIエージェントの例
Local AI agent discoveryが実務で有効なのは、AIエージェントが「アプリ一覧」だけでは把握しづらい形で広がっているためです。CLIツール、デスクトップアプリ、IDE、VS Code拡張、MCPサーバー設定など、導入経路がばらばらになりがちです。
公式ドキュメントでは、サポート対象の例として、Claude Code、Codex CLI、Gemini CLI、GitHub Copilot CLI、OpenCode、Antigravity CLI、ChatGPT Desktop、Claude Desktop、Codex Desktop、Ollama Desktop、Poe Desktop、Cursor、Windsurf、GitHub Copilot、Cline、Roo Code、OpenClaw、Clawpilot、Claw/Nanobotなどが挙げられています。(Microsoft Learn)
| 種類 | 例 | セキュリティチームが見るべき観点 |
|---|---|---|
| CLI型エージェント | Claude Code、Codex CLI、GitHub Copilot CLIなど | ターミナルから実行され、リポジトリ、.env、ローカルスクリプトに触れる可能性 |
| デスクトップAIアプリ | ChatGPT Desktop、Claude Desktop、Poe Desktopなど | クリップボード、ローカルファイル、ユーザー作業領域との関係 |
| Agentic IDE | Cursor、Windsurf、Antigravity IDEなど | ソースコード、依存関係、CI/CD設定、開発用シークレットへの接触 |
| VS Code拡張 | GitHub Copilot、Cline、Roo Codeなど | 個人単位で追加されやすく、標準ソフトウェア管理から漏れやすい |
| MCPサーバー構成 | ローカルMCP、リモートMCP | エージェントが外部ツールや業務システムへ到達する経路になり得る |
見落としやすいのは、Defenderがエージェントを「ユーザー、デバイス、エージェント種別」の組み合わせとして扱う点です。たとえば同じユーザーが同じ端末でClaude Codeを複数のプロジェクトフォルダーから使っていても、インベントリ上は1つのエージェントとして表示される例が説明されています。棚卸し件数をそのまま「利用プロジェクト数」と解釈しないようにしましょう。(Microsoft Learn)
管理者が最初に確認すべきDefenderポータルの場所
Local AI agent discoveryを確認する基本ルートは、Microsoft DefenderポータルのAI Agents画面です。公式手順では、Defenderポータルにサインインし、左ナビゲーションから「Assets > AI Agents」を開き、「Local agents」を選択して、エンドポイント上で検出されたローカルAIエージェントを確認する流れが示されています。(Microsoft Learn)
エージェントの詳細画面では、次の情報を優先して確認します。
| 確認する情報 | 見る理由 |
|---|---|
| Agent name、version、related process | どのツールが、どの実行プロセスとして動いているかを把握する |
| Associated device、user | 利用者と端末を特定し、管理対象・例外端末を切り分ける |
| First seen、last updated | 一時利用か、継続的に使われているかを判断する |
| Integrity level | 高い権限で動いていないかを確認する |
| Auto-approve status | エージェントが確認なしに操作を進める設定になっていないかを見る |
| Trust indicator | 信頼できるエージェントとして扱えるかの判断材料にする |
| Configured MCP servers | エージェントが接続できるツールやサービスの範囲を確認する |
特に優先度が高いのは、auto-approveが有効なエージェントと、MCPサーバーが設定されているエージェントです。auto-approveは、ユーザー確認を省いて操作が進む可能性があるため、ソースコード、クラウド認証情報、本番環境に触れる端末ではリスクが上がります。MCPサーバーは、AIエージェントが外部ツールや社内サービスにアクセスするための接続口になり得るため、接続先と権限をセットで確認する必要があります。公式手順でも、エージェント詳細としてauto-approve statusやconfigured MCP serversの確認が示されています。(Microsoft Learn)
Advanced Huntingで棚卸しを実務に落とし込む
ポータル画面で一覧を見るだけでは、リスクの優先順位は決めにくいものです。Local AI agent discoveryを実務で使うなら、Advanced Huntingで「どの端末に何があるか」「どのユーザーと関係しているか」「重要資産に到達し得るか」を調べます。
公式ドキュメントでは、ローカルAIエージェントのセキュリティグラフを表すテーブルとしてExposureGraphNodesとExposureGraphEdgesが説明されています。これらを使うことで、エージェント、端末、ID、リソースの関係をクエリできます。(Microsoft Learn)
まずは、エンドポイント全体のAIエージェント棚卸しから始めます。
ExposureGraphEdges
| where SourceNodeLabel == "endpointAiAgent"
| where EdgeLabel =~ "runs on"
| summarize Devices = make_set(TargetNodeName),
DeviceCount = dcount(TargetNodeName)
by AIAgent = SourceNodeName
| sort by DeviceCount descこのクエリは、検出されたローカルAIエージェントと、それが実行されているデバイス数を確認するための出発点になります。次に、特権ユーザーの端末、重要なソースコードを扱う端末、本番クラウドへアクセスできる端末に絞って、優先的に調査します。公式ドキュメントでも、ユーザーとの関連付け、広範なアクセス権を持つユーザー端末上のAIエージェント、重要または機密資産へのパスを調べるAdvanced Hunting例が示されています。(Microsoft Learn)
実務では、次の3つの問いに答える形でクエリを整理すると運用しやすくなります。
| 問い | 目的 | 優先対応の例 |
|---|---|---|
| どのAIエージェントが、どの端末で使われているか | シャドーAIエージェントの棚卸し | 未承認ツールを開発部門と確認する |
| 特権ユーザーや広範なアクセス権を持つユーザー端末で動いていないか | 影響範囲の大きい利用を見つける | 管理者権限ユーザーの端末ではauto-approveを避ける |
| 重要資産や機密データに到達する経路がないか | 侵害時のblast radiusを把握する | 本番環境・シークレット・重要リポジトリへの到達経路を減らす |
影響範囲：SOC、IT管理者、開発者で見るポイントが違う
Local AI agent discoveryの影響は、セキュリティ部門だけに閉じません。開発者のAI活用を止めずに、組織としてリスクを把握するための共通基盤として考えるべきです。
| 役割 | 主な影響 | 具体的な対応 |
|---|---|---|
| SOC・CSIRT | AIエージェントを調査対象として扱えるようになる | Advanced Huntingで端末、ID、クラウドリソースとの関係を見る |
| IT管理者 | 対象端末のオンボード、AV状態、ライセンス不備が可視性に直結する | 開発者PC、検証端末、VDIのオンボード漏れを確認する |
| 開発部門 | 個人導入のAIツールがセキュリティレビュー対象になりやすくなる | 承認済みツール、MCP設定、auto-approveの基準を決める |
| ID・クラウド管理者 | エージェントそのものではなく、ユーザー権限を通じた到達範囲が問題になる | 過剰権限、永続的な認証情報、共有管理者アカウントを見直す |
| ガバナンス担当 | シャドーAI利用の実態を把握しやすくなる | 利用禁止ではなく、許可条件と監査手順を定義する |
Microsoftの説明では、ローカルAIエージェントはユーザー権限で動き、そのユーザーがアクセスできるファイル、ツール、サービスに到達できるとされています。つまり、エージェント単体の名前だけで危険度を判断するのではなく、「どのユーザーの権限で」「どの端末上で」「どのリソースに届くか」を見ることが重要です。(Microsoft Learn)
Runtime protectionとLocal AI agent discoveryを混同しない
Local AI agent discoveryは、ローカルAIエージェントを見つけ、調査するための機能です。一方、AI agent runtime protectionは、サポート対象エージェントの実行ループ内でユーザープロンプト、ツール呼び出し前、ツール応答後を検査し、プロンプトインジェクションや危険な操作を監査またはブロックする機能です。(Microsoft Learn)
| 機能 | 目的 | 管理者が期待すべきこと | 注意点 |
|---|---|---|---|
| Local AI agent discovery | ローカルAIエージェントとMCP構成の発見 | 誰がどの端末で何を使っているかを把握する | 発見・調査が中心で、姿勢評価やアラートは含まれない |
| AI agent runtime protection | 実行時の危険な指示や操作の監査・ブロック | プロンプトインジェクションなどをAuditまたはBlockで制御する | 対象エージェントや対応範囲が限定される |
| AI Assets / Agent inventory | クラウド型・ローカル型を含むAI資産の一元把握 | 組織内のAIエージェント全体を確認する | 一部機能はプレビュー機能の有効化が必要 |
Runtime protectionでは、Block、Audit、Disabledのモードが説明されています。Microsoftは、最初からBlockにするのではなく、まずAuditモードで検出内容と精度を確認してからBlockモードへ移行することを推奨しています。現時点でLearnに記載されているRuntime protectionのサポート対象エージェントはClaude CodeとGitHub Copilot CLIです。(Microsoft Learn)
実務上は、次の順番が安全です。
- Local AI agent discoveryで利用実態を棚卸しする
- 特権ユーザー、重要リポジトリ、本番環境に近い端末を優先度高に分類する
- 対象エージェントがRuntime protectionに対応しているか確認する
- Auditモードで検出状況を確認する
- 誤検知や業務影響を見たうえでBlockモードを検討する
移行・設定見直しで注意すべきポイント
AIエージェント関連のDefender機能は、Microsoft Agent 365やAI Assetsページとの関係もあるため、既存のクエリや運用手順を見直す必要があります。
特に注意したいのは、Advanced Huntingで使うテーブルです。AI agent inventoryの公式ページでは、Agent 365管理対象エージェントのインベントリにAgentsInfoテーブルを使う説明があり、以前のAIAgentsInfoテーブルはMicrosoft Agent 365への移行に伴って置き換えられるとされています。一方、ローカルAIエージェントの調査ではExposureGraphNodesとExposureGraphEdgesを使う例が示されています。既存の自作KQL、SIEM連携、カスタム検知ルールが古いテーブル名やクラウドエージェント前提のロジックに依存していないか確認しましょう。(Microsoft Learn)
| 見直し対象 | 起きやすい問題 | 対応ポイント |
|---|---|---|
| 既存KQL | AIAgentsInfo前提のまま残る | AgentsInfoやExposure Graph系テーブルとの使い分けを整理する |
| 資産管理台帳 | インストール済みアプリだけをAI利用状況として扱う | CLI、IDE拡張、MCP構成も確認対象に入れる |
| EDR運用手順 | AIエージェントを通常プロセスとしてだけ扱う | エージェント、ユーザー、端末、到達可能リソースの関係で見る |
| 開発者向けルール | 「AIツール禁止」か「自由利用」の二択になる | 承認済みツール、許可条件、MCP利用基準を明文化する |
| ブロックポリシー | いきなりBlockにして開発作業を止める | まず棚卸し、次にAudit、最後に高リスク領域からBlockを検討する |
開発者が確認すべき設定と運用ルール
Local AI agent discoveryは管理者向けの可視化機能ですが、実際のリスクを下げるには開発者側の運用ルールが欠かせません。AIコーディングエージェントは、ソースコード、環境変数、ローカル設定ファイル、クラウドCLIの認証情報、リポジトリのIssueやドキュメントを横断して作業することがあります。
開発チームでは、少なくとも次の基準を決めておくべきです。
| ルール | 具体例 |
|---|---|
| 承認済みAIエージェントを定義する | 利用可能なCLI、IDE拡張、デスクトップアプリを一覧化する |
| auto-approveの利用条件を制限する | 本番コード、シークレット、クラウド操作を含む作業では無効化する |
| MCPサーバー設定をレビューする | 接続先、認証方式、アクセスできるツール、外部送信先を確認する |
| シークレットをローカルファイルに置きっぱなしにしない | .env、APIキー、個人アクセストークンを棚卸しし、必要に応じてVaultへ移す |
| 本番権限と開発用AI利用を分離する | 管理者アカウントや本番クラウド権限を持つ端末でのAIエージェント利用を制限する |
| リポジトリ単位で利用可否を決める | 公開OSS、社内業務システム、顧客データを含むコードで基準を分ける |
ここで重要なのは、AIツールを一律に止めることではありません。開発効率を上げるツールほど現場で広がりやすいため、見えないまま禁止するより、Defenderで実態を把握し、リスクの高い設定から順に是正するほうが現実的です。
失敗しやすいポイント
Local AI agent discoveryを導入しても、運用の仕方を間違えると効果は限定的です。特に次の誤解には注意してください。
「検出されていないから存在しない」と判断する
Local AI agent discoveryは、サポート対象のローカルAIエージェントとMCP構成を検出する機能です。独自スクリプト、未対応ツール、社内ラッパー、名前を変えて配布された実行ファイルまで万能に把握できると決めつけるのは危険です。未検出端末については、ソフトウェア資産管理、EDRのプロセス実行履歴、開発者ヒアリングも併用しましょう。
インベントリ件数だけでリスクを判断する
AIエージェントの数が多い部署より、少数でも本番クラウドや機密リポジトリに到達できるユーザー端末のほうがリスクが高い場合があります。件数ではなく、権限、到達可能リソース、MCP設定、auto-approveの有無で優先順位を決めるべきです。
Discoveryにブロック機能まで期待する
Local AI agent discoveryは、発見と調査が中心です。ブロックや監査を行うには、AI agent runtime protectionなど別の保護機能の対応範囲と設定を確認する必要があります。MicrosoftのRuntime protectionでは、監査・ブロック・無効化のモードが用意され、検出時にはDefenderにアラートが送られる流れが説明されています。(Microsoft Learn)
MCPサーバーを単なる開発者設定として見逃す
MCPサーバー設定は、AIエージェントにツールやサービスへの接続口を与える重要な要素です。ローカルで完結しているように見えるAIエージェントでも、MCP経由でファイルシステム、社内API、クラウドリソース、外部サービスへ広がる可能性があります。検出されたMCP構成は、接続先、認証情報、操作可能な範囲を必ず確認しましょう。
管理者が取るべき対応ステップ
最初の対応は、大規模なポリシー変更ではなく、可視化と優先順位付けから始めるのが現実的です。
| タイミング | 対応 | 成果物 |
|---|---|---|
| まず実施 | Defender for Endpointのオンボード率、Plan 2ライセンス、Defender Antivirus active modeを確認する | 検出対象端末リスト |
| 次に実施 | 「Assets > AI Agents > Local agents」で検出状況を確認する | ローカルAIエージェント一覧 |
| 1週間以内 | Advanced Huntingで特権ユーザー端末、重要資産への到達経路を調べる | 高リスク端末・高リスクユーザー一覧 |
| 2〜4週間以内 | 開発部門と承認済みAIツール、MCP利用基準、auto-approve基準を合意する | AIエージェント利用ポリシー |
| 検証後 | Runtime protectionのAuditモードを検討し、必要に応じてBlockへ移行する | 監査・ブロック運用手順 |
| 継続運用 | 月次またはリリース前に棚卸しクエリを実行する | 定期レポートと例外管理台帳 |
AIエージェントの利用は、今後も開発現場や業務部門で増えていきます。Microsoft DefenderのLocal AI agent discoveryは、その流れを止めるための機能ではなく、見えない利用を見える状態にし、危険な組み合わせから順に管理するための機能です。
まずはDefenderポータルでLocal agentsを確認し、次にAdvanced Huntingで「誰の権限で、どの端末から、どの重要資産に届くのか」を洗い出しましょう。そのうえで、開発者の生産性を損なわない範囲で、承認済みツール、MCP設定、auto-approve、Runtime protectionのAudit/Block方針を決めることが、現実的な第一歩です。
コメント