Microsoft Agent 365は、AIエージェントを「作って使う」段階から、「見つける・管理する・守る」段階へ進めるための管理基盤です。今回の一般提供で重要なのは、Microsoft Securityの既存領域であるMicrosoft Defender、Microsoft Entra、Microsoft Intune、Microsoft Purviewと連携し、社内に広がるAIエージェントやシャドーAIを可視化・制御しやすくなった点です。(Microsoft)
特に確認すべきなのは、すでにCopilot Studio、Microsoft 365 Copilot、Teams、SaaSエージェント、ローカルAIエージェント、クラウド上のAIエージェントを使っている組織です。一般提供された機能とプレビュー段階の機能が混在しているため、「Agent 365がGAになったから全機能が本番利用可能」と考えず、ライセンス、対象エージェント、管理画面、IntuneやDefenderでの検出範囲を切り分けて確認する必要があります。(Microsoft)
Microsoft Agent 365とは何か
Microsoft Agent 365は、組織内のAIエージェントを一元的に観察、統制、保護するためのコントロールプレーンです。Microsoftの説明では、Microsoft製エージェントだけでなく、パートナー製エージェントや外部プラットフォームで作成されたエージェントも管理対象に含める構想が示されています。(Microsoft Learn)
従来のAI管理では、Copilot Studioで作ったエージェント、Teamsで使うエージェント、開発者がローカル端末で動かすコーディングエージェント、SaaSに組み込まれたAI機能が別々に存在しがちでした。これでは、誰が作ったのか、どのデータにアクセスできるのか、停止すべきエージェントが残っていないかを把握しにくくなります。
Agent 365の狙いは、この分断を減らし、次のような問いに管理者が答えられるようにすることです。
| 確認したいこと | Agent 365で重視される観点 |
|---|---|
| 社内にどのAIエージェントが存在するか | Agent registry、Registry sync、Microsoft 365管理センターでの可視化 |
| 誰が所有・承認しているか | 所有者、スポンサー、承認フロー、ライフサイクル管理 |
| どのユーザーやデータにアクセスできるか | Microsoft Entra、Purview、DLP、最小権限 |
| 不審な動作や過剰な権限がないか | Microsoft Defenderによるリスク検出、調査、ブロック |
| ローカル端末や外部クラウドに潜むエージェントを把握できるか | Intune、Defender、AWS Bedrock、Google Cloud接続など |
今回の一般提供で変わった主なポイント
Microsoft Security Blogでは、Agent 365の一般提供開始に加えて、シャドーAIエージェントの検出、ローカルエージェント管理、Windows 365 for Agents、SaaSエージェント連携、ネットワーク制御などの拡張が発表されています。(Microsoft)
商用顧客向けにAgent 365が一般提供
Agent 365は、商用顧客向けに一般提供されています。Microsoft Learnの概要ページでも、2026年5月1日時点でCommercial segment向けにユーザー単位で一般提供されたと説明されています。(Microsoft Learn)
ライセンス面では、Microsoft 365 E7に含まれる形、または単体で月額15米ドルのユーザー単位ライセンスとして案内されています。ライセンス対象は、エージェントを管理する人、スポンサーする人、または自分の代わりにエージェントを使う人という考え方です。(Microsoft)
ただし、Microsoft Learnでは、Agent 365自体に特定の製品前提条件はない一方で、十分に活用するにはMicrosoft Entra P1、Entra P2、Entra Suite、Purview Data Loss Preventionなどの利用が推奨されています。既存のMicrosoft 365環境で導入する場合は、ライセンスの有無だけでなく、Entra、Purview、Defender、Intuneの契約状況も確認しておくべきです。(Microsoft Learn)
ユーザー代理型だけでなく、独自権限で動くエージェントも対象に拡大
AIエージェントには、ユーザーの代理として動くものと、独自の資格情報や権限を持って裏側で動くものがあります。Agent 365では、ユーザー代理型のエージェントに加え、独自アクセス権を持ってバックグラウンドで動作するエージェントも一般提供の対象として説明されています。一方、チームワークフローに参加する独自アクセス型エージェントはPublic Previewとされています。(Microsoft)
実務上の影響は大きく、これまで「ユーザーの権限範囲で動くから大丈夫」と考えていたAI利用だけでなく、サービスアカウントのように独立して動くエージェントの権限管理が必要になります。
特に次のようなエージェントは、早めに棚卸しすべきです。
| エージェントの種類 | リスクの例 | 確認すべき項目 |
|---|---|---|
| 問い合わせを自動分類するサポートエージェント | 顧客情報への過剰アクセス | アクセス先、ログ、所有者、停止条件 |
| コード修正を行うローカルエージェント | ソースコード改変、秘密情報の読み取り | 端末、リポジトリ権限、MCPサーバー、ネットワーク接続 |
| 経理・人事データを参照する業務エージェント | 機微情報の漏えい、監査不備 | Purviewラベル、DLP、承認フロー |
| SaaS内のAIエージェント | 外部サービス経由のデータ共有 | ベンダー、利用者、連携範囲、契約条件 |
シャドーAI対策として重要なローカルエージェント検出
今回の発表で特に注目すべきなのが、シャドーAIエージェントの検出と管理です。Microsoftは、OpenClawやClaude Codeのようなローカルエージェント、また新興プラットフォーム上で作られるSaaSエージェントが、従来のガバナンス外で動作するリスクを指摘しています。(Microsoft)
Microsoft DefenderとIntuneを使うことで、Windowsデバイス上で動作するローカルAIエージェントの検出と管理が可能になると説明されています。初期対象としてOpenClawが挙げられ、今後GitHub Copilot CLIやClaude Codeのような広く使われるエージェントにも拡大予定とされています。(Microsoft)
ここで注意したいのは、発表時点で一部機能はFrontier program参加組織やPublic Previewの文脈で説明されている点です。たとえば、Defenderによるエージェントごとの資産コンテキストマッピング、MCPサーバー、関連ID、到達可能なクラウドリソースの把握などは、2026年6月にPublic Previewとして提供予定とされています。(Microsoft)
管理者は、次の順で確認すると現実的です。
| 優先度 | 確認内容 | 見るべき観点 |
|---|---|---|
| 高 | 管理対象Windows端末でローカルAIエージェントが使われているか | Intune、Defender、Shadow AIページ |
| 高 | コード、顧客情報、社内文書にアクセスしていないか | ファイルアクセス、ネットワーク挙動、リポジトリ権限 |
| 中 | MCPサーバーや外部APIと接続していないか | 接続先、資格情報、データ送信先 |
| 中 | ブロックや制限のポリシーを適用できるか | Intuneポリシー、例外申請、検証環境 |
| 低 | すべてを一律禁止していないか | 業務価値、代替手段、承認済み利用ルール |
ローカルエージェント対策では、「使ってはいけない」と通知するだけでは不十分です。開発者や業務部門は、生産性向上のためにAIエージェントを導入します。禁止だけに寄せると、個人端末や未承認SaaSに利用が流れ、かえって見えにくくなります。承認済みツール、利用可能なデータ、禁止する操作、例外申請のルートを明文化することが重要です。
Microsoft Security製品との連携で確認すべき影響範囲
Agent 365は単独の管理画面としてだけでなく、Microsoft Securityの既存製品にエージェント管理の視点を広げる役割を持ちます。Microsoft Learnでは、Defender、Entra、PurviewがAgent 365の一部としてエージェント向けの制御を提供し、セキュリティ担当者は既存のポータルでエージェントに関するインサイトや推奨事項を扱えると説明されています。(Microsoft Learn)
Microsoft Entraで確認すること
Microsoft Entraでは、エージェントID、条件付きアクセス、Identity Protection、SASE、ライフサイクル管理などが重要になります。特に、エージェントが過剰な権限を持ったまま放置されると、攻撃者に悪用された場合の影響範囲が大きくなります。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 確認項目 | 実務での判断基準 |
|---|---|
| エージェントごとのIDが把握できているか | 共有アカウントや個人アカウントで動かしていない |
| 所有者・スポンサーが明確か | 退職者や異動者が所有者のまま残っていない |
| 最小権限になっているか | 業務に不要なメール、SharePoint、Teams、外部APIへのアクセスがない |
| アクセス期限があるか | PoC用エージェントが本番権限を持ったまま残っていない |
| 条件付きアクセスを適用できるか | リスク、リソース感度、エージェント文脈に応じて制御できる |
Microsoft Purviewで確認すること
Microsoft Purviewは、エージェントが扱うデータの過剰共有や情報漏えいを抑えるうえで重要です。Microsoft Learnでは、感度ラベル、DLP、監査、データライフサイクル管理、eDiscovery、Compliance ManagerなどがAgent 365のデータセキュリティとコンプライアンスに関わる機能として挙げられています。(Microsoft Learn)
AIエージェントは、人間より速く大量のデータを処理できます。便利な一方で、権限が広すぎると、機密ファイルの要約、外部チャットへの貼り付け、不要な共有リンクの生成などが短時間で起きる可能性があります。
特に次のデータを扱うエージェントは、Purview側のポリシー確認を優先してください。
| データの種類 | 確認すべき制御 |
|---|---|
| 顧客情報 | DLP、監査ログ、外部共有制限 |
| 人事・評価情報 | 感度ラベル、アクセス制御、保持ポリシー |
| 財務・契約情報 | eDiscovery、監査、承認フロー |
| ソースコード・設計情報 | 外部送信制限、秘密情報検出、リポジトリアクセス |
| 社内ナレッジ | SharePoint権限、ラベル継承、検索範囲 |
Microsoft Defenderで確認すること
Microsoft Defenderでは、エージェントの設定不備、危険な動作、攻撃経路、脅威検出、リアルタイム保護などが重要になります。Microsoft Learnでは、エージェントのセキュリティ態勢管理、脅威検出とブロック、調査とハンティングが挙げられています。(Microsoft Learn)
セキュリティ担当者は、従来のユーザーやデバイス中心の監視に加えて、次のような「エージェント特有の兆候」を見る必要があります。
| 兆候 | 想定されるリスク | 対応例 |
|---|---|---|
| 短時間に大量のファイルへアクセス | 情報収集、漏えい準備 | アラート確認、DLP連携、アクセス停止 |
| 未承認の外部APIへ接続 | データ持ち出し、外部AI利用 | ネットワーク制御、接続先制限 |
| 通常業務と異なるコード変更 | サプライチェーンリスク | リポジトリ権限確認、変更レビュー |
| MCPサーバー経由の不審な操作 | ツール悪用、権限拡大 | 接続マップ確認、不要なサーバー無効化 |
| 所有者不明のエージェントが稼働 | 責任不明、監査不備 | 所有者割り当て、停止判断 |
Microsoft Intuneで確認すること
Intuneは、ローカルエージェントやWindows 365 for Agentsの管理で重要になります。発表では、Intuneポリシーを使ってOpenClawの一般的な実行方法をブロックする例が示されています。(Microsoft)
端末管理チームは、次の観点で確認してください。
| 確認項目 | 実務上の意味 |
|---|---|
| 対象端末が管理下にあるか | 未管理端末では検出・制御が不完全になる可能性がある |
| ローカルAIエージェントの実行経路を把握しているか | CLI、デスクトップアプリ、スクリプト、開発環境などを確認 |
| ブロック対象と許可対象を分けているか | 開発業務を止めずに危険な利用だけを抑える |
| 例外申請の仕組みがあるか | 業務上必要な利用をシャドー化させない |
| Defenderの検出と連携できるか | インシデント対応時に端末・ID・クラウド資産を関連付ける |
ネットワーク制御の一般提供で何が変わるか
今回の発表では、Agent 365がMicrosoft Entraのネットワーク制御をMicrosoft Copilot Studioエージェントやユーザー端末上で動作するエージェントに拡張したことも説明されています。対象にはOpenClawのようなローカルエージェントも含まれます。(Microsoft)
これは、AIエージェントがインターネット、SaaS、外部AIサービスへ接続する経路を制御するうえで重要です。人間のユーザーであれば不審な画面に気づいて止まる場面でも、エージェントは高速に処理を続ける可能性があります。
ネットワーク制御で検討すべき設定例は次の通りです。
| 制御対象 | 設定の考え方 |
|---|---|
| 承認済みWeb宛先 | 業務に必要なSaaS、社内サービス、開発基盤に限定する |
| 未承認AIサービス | 機密データを扱う端末・エージェントからの接続を制限する |
| ファイル移動 | 感度ラベル付きファイルの外部送信をブロックまたは警告する |
| プロンプトベース攻撃 | 悪意ある指示や誘導による不正操作を防ぐ制御を検討する |
| 例外ルール | PoC、検証、特定部署向けに期限付きで許可する |
重要なのは、ネットワーク制御を「全面遮断」にしないことです。AIエージェントは外部ツールやSaaSと連携して価値を出すケースが多いため、業務上必要な接続と危険な接続を分ける設計が求められます。
AWS BedrockやGoogle Cloudのエージェントも確認対象にする
Agent 365はMicrosoft環境内だけを見るものではありません。発表では、AWS BedrockやGoogle Cloud接続とのAgent 365 registry syncがPublic Previewとして案内され、外部プラットフォーム上のエージェントを検出・棚卸しできる方向性が示されています。(Microsoft)
Microsoft Learnのパートナー統合ページでも、Google Vertex AIやAmazon Bedrock上に既存のエージェントがある場合、Agent 365からMicrosoft 365管理センター上で可視化できる旨が説明されています。(Microsoft Learn)
マルチクラウド環境では、次のような見落としが起こりやすくなります。
| 見落としやすい場所 | よくある問題 |
|---|---|
| AWS Bedrock | PoCで作ったエージェントが残り、権限やログの管理が曖昧になる |
| Google Cloud | 部門主導のAI実験が中央管理に載っていない |
| SaaS内AI機能 | ベンダー側エージェントが社内データへアクセスしている |
| 開発者端末 | ローカルAIツールがコードや秘密情報にアクセスしている |
| 業務自動化ツール | ワークフロー自動化がAIエージェント化しても管理ルールが変わっていない |
すでにAWS、Google Cloud、SaaS、Microsoft 365を併用している組織では、Agent 365の導入をMicrosoft 365管理だけの話に閉じないほうがよいでしょう。クラウド管理者、セキュリティ担当、業務システム担当、開発チームを巻き込んで、どこにエージェントが存在するかを横断的に確認する必要があります。
Windows 365 for Agentsは本番導入前にプレビュー条件を確認する
Windows 365 for Agentsは、エージェントが作業するための管理されたCloud PC環境を提供する機能です。Microsoft LearnではPublic Previewであり、一般提供前に変更される可能性があると明記されています。また、Public Preview時点では米国のみで利用可能とされています。(Microsoft Learn)
この機能の価値は、AIエージェントの作業環境をユーザー端末や個人環境に散らばらせず、Intune管理されたCloud PC上で動かせる点にあります。Cloud PC for Agentsは、プロビジョニングポリシーやCloud PC agent poolsを通じて管理され、エージェントは作業時にCloud PCをチェックアウトし、完了後にチェックインするモデルとして説明されています。(Microsoft Learn)
ただし、日本企業がすぐに本番利用を前提に計画する場合は注意が必要です。Public Preview、地域制限、価格、既存のWindows 365契約、Intune運用、監査要件を確認したうえで、検証対象として扱うのが安全です。
パートナー製SaaSエージェントは「利用可否」だけでなくステータスを確認する
Microsoftは、Agent 365で管理可能なエコシステムパートナーの拡大も発表しています。発表では、Genspark、Zensai、Egnyte、Zendesk、Kasisto、Kore、n8nなどが例として挙げられています。(Microsoft)
一方で、Microsoft Learnの統合一覧を見ると、各パートナーには「Registered」「Observable」「Work IQ」などの対応状況があり、一部にはComing soonやFrontier program参加者向けの注記もあります。たとえば、AI teammateはFrontier program参加者向けと記載されています。(Microsoft Learn)
そのため、SaaSエージェントを評価する際は、単に「Agent 365対応」と聞いて判断しないことが大切です。
| 確認項目 | 質問例 |
|---|---|
| 登録できるか | Microsoft 365管理センターのAgent registryに表示されるか |
| 観察できるか | 利用状況、アクセス、操作ログを確認できるか |
| 統制できるか | 管理者が承認、停止、所有者設定、ポリシー適用を行えるか |
| データ保護できるか | Purview、DLP、監査ログと連携できるか |
| 提供状態は何か | GA、Public Preview、Coming soon、Frontier限定のどれか |
SaaSエージェントは業務部門が先に使い始めることが多いため、IT部門だけでなく、マーケティング、営業、人事、カスタマーサポートなどの利用実態も確認してください。
まず実施すべき設定確認チェックリスト
Agent 365への対応は、いきなり全社展開するよりも、棚卸し、権限、データ、端末、ネットワークの順に整理すると進めやすくなります。
| 確認領域 | 最初にやること | 失敗しやすいポイント |
|---|---|---|
| ライセンス | Microsoft 365 E7またはAgent 365単体ライセンスの対象者を確認する | 管理者だけに割り当て、実際の利用者やスポンサーを漏らす |
| 管理画面 | Microsoft 365管理センターのAgents > Overviewを確認する | 表示されない機能を不具合と決めつけ、ライセンスやロールを確認しない |
| ロール | AI AdministratorまたはGlobal Administratorの権限を確認する | 監視できるが承認・所有者変更ができない担当者に任せる |
| 棚卸し | Agent registryでエージェント、所有者、作成元、利用状況を確認する | 部門作成、SaaS、外部クラウド、ローカル端末を除外する |
| 権限 | EntraでエージェントID、条件付きアクセス、最小権限を確認する | PoC用の広い権限が本番運用に残る |
| データ保護 | Purviewの感度ラベル、DLP、監査、保持を確認する | エージェント生成物や会話ログの扱いを決めていない |
| 端末管理 | IntuneとDefenderでローカルエージェント検出・制御を確認する | 開発者端末や管理外端末を見落とす |
| ネットワーク | Entraネットワーク制御で接続先とファイル移動を確認する | 未承認AIサービスへの接続を放置する |
| 外部クラウド | AWS Bedrock、Google Cloud、SaaSエージェントの有無を確認する | Microsoft 365内だけを見て完了とする |
| 運用 | 例外申請、停止基準、所有者変更、定期レビューを決める | 導入時だけ整理して、その後の増殖を管理しない |
Microsoft 365管理センターのAgent overviewでは、過去30日間の利用状況、エージェント数、所有者不明、リスク、例外などの把握が可能とされています。ただし、ライセンス有効化直後はデータが十分に蓄積されていない場合があり、メトリクスがすぐに完全な30日分を反映するとは限りません。(Microsoft Learn)
また、重要なガバナンス操作はAI AdministratorまたはGlobal Administratorロールが必要とされています。監視担当者と実際に承認・修正できる担当者が別の場合、運用フローを事前に決めておかないと、検出しても対応が止まります。(Microsoft Learn)
移行・導入時の実践ステップ
既存エージェントの棚卸しから始める
最初にやるべきことは、新しいエージェントを作ることではなく、既存エージェントの棚卸しです。Microsoft 365管理センター、Copilot Studio、SharePoint、Microsoft Foundry、Teams、SaaS管理画面、開発者端末、クラウド環境を横断して、次の情報を集めます。
| 棚卸し項目 | 記録する内容 |
|---|---|
| エージェント名 | 管理画面上の名称、別名、利用部門 |
| 所有者 | 業務責任者、技術責任者、承認者 |
| 用途 | 問い合わせ対応、文書作成、コード修正、分析など |
| 実行場所 | Teams、Copilot、端末、Cloud PC、SaaS、クラウド |
| アクセス先 | SharePoint、メール、CRM、コード、外部API |
| 扱うデータ | 個人情報、顧客情報、財務情報、公開情報など |
| 権限 | ユーザー代理、独自資格情報、管理者権限の有無 |
| ログ | 監査ログ、会話履歴、操作履歴、保持期間 |
| 状態 | 本番、検証、停止予定、所有者不明 |
この棚卸しがないままAgent 365を導入すると、管理画面に表示された項目を眺めるだけで終わりがちです。どのエージェントを残し、どれを制限し、どれを停止するかを決めるための判断材料をそろえることが重要です。
リスクの高いエージェントから優先順位を付ける
すべてのエージェントを同じ優先度で管理しようとすると、初期対応が重くなります。まずは、影響が大きいものから着手してください。
優先度が高いのは、次の条件に当てはまるエージェントです。
| 条件 | 理由 |
|---|---|
| 機密データにアクセスする | 漏えい時の影響が大きい |
| 独自権限で動作する | ユーザー退職や権限変更と連動しない可能性がある |
| 外部サービスへ接続する | データの送信先が複雑になりやすい |
| コードや設定を変更する | システム障害やサプライチェーンリスクにつながる |
| 所有者が不明 | 停止判断や監査対応ができない |
| 利用者が急増している | 小さな設定ミスが大きな影響になる |
逆に、公開情報の要約や限定された社内FAQの回答など、権限とデータ範囲が狭いエージェントは、標準ポリシーを適用したうえで後回しにできます。
ポリシーを3段階に分ける
AIエージェント管理でありがちな失敗は、全社一律で「許可」か「禁止」かを決めてしまうことです。実務では、次のように段階を分けると運用しやすくなります。
| 区分 | 対象 | ルール例 |
|---|---|---|
| 承認済み本番利用 | 業務部門で正式運用するエージェント | 所有者必須、DLP適用、監査ログ保持、定期レビュー |
| 制限付き検証 | PoC、開発、部門試行 | 機密データ禁止、期間限定、外部接続制限 |
| 禁止・ブロック | 未承認ローカルエージェント、個人アカウント利用、危険な外部AI接続 | Intune、Defender、ネットワーク制御で制限 |
この区分を明文化しておくと、管理者が検出したエージェントに対して「承認する」「制限する」「停止する」の判断をしやすくなります。
対応が必要な担当者
Agent 365は、単独のIT管理者だけで完結するテーマではありません。Microsoft Security、Microsoft 365、開発、業務部門が関わる横断的な管理対象です。
| 担当者 | 主な対応 |
|---|---|
| Microsoft 365管理者 | Agent registry、承認、所有者設定、ライセンス確認 |
| セキュリティ担当者 | Defenderでのリスク検出、攻撃経路分析、インシデント対応 |
| ID管理担当者 | Entra Agent ID、条件付きアクセス、最小権限、ライフサイクル管理 |
| 端末管理担当者 | Intuneでのローカルエージェント検出・制御 |
| データ保護担当者 | Purview、DLP、感度ラベル、監査、保持ポリシー |
| クラウド管理者 | AWS Bedrock、Google Cloud、外部AI基盤の棚卸し |
| 開発チーム | コーディングエージェント、MCPサーバー、APIキー、リポジトリ権限の管理 |
| 業務部門 | 利用目的、所有者、業務価値、停止時の影響を説明する |
特に重要なのは、所有者の定義です。AIエージェントは「誰かが作った便利ツール」として残りやすく、異動や退職後に責任者不明になることがあります。所有者が不明なエージェントは、セキュリティリスクだけでなく、コストや監査対応の面でも問題になります。
導入時に避けたい失敗
「一般提供」を全機能の本番提供と誤解する
Agent 365自体は一般提供されていますが、発表されたすべての拡張機能が同じ状態ではありません。ローカルエージェントの一部機能、Windows 365 for Agents、外部クラウド接続、パートナー統合にはPublic Preview、Frontier program、Coming soonが含まれます。(Microsoft)
本番計画を立てる際は、機能ごとに次のラベルを付けて管理してください。
| 状態 | 扱い方 |
|---|---|
| GA | 本番適用候補として設計・運用に組み込む |
| Public Preview | 検証対象として扱い、変更可能性を前提にする |
| Frontier限定 | 参加条件と利用範囲を確認する |
| Coming soon | ロードマップとして把握し、依存した運用設計を避ける |
端末上のAIエージェントを見落とす
Copilot StudioやMicrosoft 365 Copilotだけを見ていると、開発者端末や部門端末で動くローカルエージェントを見落とします。今回の発表では、OpenClaw、Claude Code、GitHub Copilot CLIのようなローカルエージェントが明示的に扱われています。(Microsoft)
ローカルエージェントは、ソースコード、設定ファイル、認証情報、社内文書にアクセスできる場合があります。管理対象端末での検出、実行制限、例外申請、開発者向けガイドラインをセットで整備する必要があります。
所有者と停止基準を決めない
エージェントは、作成よりも停止のほうが難しい場合があります。業務に組み込まれた後で停止すると、問い合わせ対応、文書作成、データ分析、自動処理が止まる可能性があるからです。
そのため、導入時点で次の条件を決めておくべきです。
| 項目 | 決めておく内容 |
|---|---|
| 所有者 | 業務責任者と技術責任者 |
| レビュー周期 | 月次、四半期、またはリスクに応じた頻度 |
| 停止条件 | 所有者不明、過剰権限、未承認データアクセス、利用実績なし |
| 例外処理 | 誰が承認し、いつ見直すか |
| 監査対応 | ログの保存先、保持期間、調査手順 |
AI活用の価値を無視してブロックだけに寄せる
シャドーAI対策では、ブロックだけでなく安全な利用ルートの整備が欠かせません。現場がAIエージェントを使う理由は、作業時間の短縮、問い合わせ対応の効率化、コードレビュー、文書作成、業務自動化など明確です。
安全な選択肢を用意せずに禁止だけを強めると、個人アカウント、未承認SaaS、管理外端末へ利用が移ります。Agent 365を導入するなら、「承認済みエージェントをどう増やすか」と「危険なエージェントをどう抑えるか」を同時に設計してください。
今すぐ取るべきアクション
Microsoft Agent 365の一般提供は、AIエージェントを本格運用する企業にとって、管理とセキュリティを見直すタイミングです。最初にやるべきことは、全社展開や追加開発ではなく、現状把握です。
まず、Microsoft 365管理センターでAgent overviewとAgent registryを確認し、表示されるエージェント、所有者不明のエージェント、リスクのあるエージェント、利用状況を把握します。次に、Entraで権限とID、Purviewでデータ保護、Defenderで脅威検出、Intuneで端末上のローカルエージェントを確認します。さらに、AWS Bedrock、Google Cloud、SaaS、開発者端末まで範囲を広げ、Microsoft 365内だけで完結させないことが重要です。
Agent 365対応の第一歩は、次の5つに絞ると進めやすくなります。
| 順番 | アクション |
|---|---|
| 1 | Agent 365のライセンスと管理者ロールを確認する |
| 2 | Agent registryで既存エージェントを棚卸しする |
| 3 | 所有者不明、過剰権限、機密データアクセスのあるエージェントを優先対応する |
| 4 | Entra、Purview、Defender、Intuneの既存ポリシーをエージェント向けに見直す |
| 5 | GA、Public Preview、Frontier、Coming soonを分けて導入計画を作る |
AIエージェントは、今後さらに増える前提で管理する必要があります。Microsoft Agent 365は、その増加を止めるための製品ではなく、見える状態にして、安全に使うための基盤です。まずは自社のエージェント一覧を作り、誰が責任を持ち、どのデータにアクセスし、どの条件で停止するのかを決めるところから始めましょう。
コメント