この記事は、M365 CopilotまたはCopilot Studioの展開を担当するIT管理者と情シスリーダーが、エージェント乱立（Agent Sprawl）を「禁止」ではなく「統制」する運用モデルを設計するためのガイドです。SharePoint権限の整理手順については姉妹記事「Copilot導入前にやるSharePoint権限クリーンアップ実務」で詳しく扱っています。本記事は組織レベルの管理モデルに絞ります。

Agent Sprawlとは何か：Microsoftが確認している問題

Microsoft Build 2026（2026年6月2日）でMicrosoftが発表したAgent 365（2026年5月1日GA）の発表文には、「エージェントが増えるほど、IT管理者は統一したIDポリシー・同意・ログ・データアクセス・失効の管理モデルを必要とする」という問題意識が明記されています。

企業で実際に起きることは次のようなパターンです。

問題具体的な状態
所有者不明Copilot Studioで作られたエージェントの担当者が退職しており誰も保守できない
接続先不明どのSharePointサイト・どのSFAにアクセスしているか一覧がない
権限不明全社員が機密文書を要約できるエージェントが稼働している
重複エージェント営業部・マーケ部・CSがそれぞれ類似の問い合わせ分類エージェントを作成している
廃止漏れPoCで作ったまま本番に移行されず稼働しているエージェントが残存している
品質格差部署ごとにシステムプロンプトの精度が異なり、回答品質にばらつきがある

Agent 365のDefender Agent SPM（セキュリティ姿勢管理）は2026年6月以降、エージェントが動作するデバイス・MCP接続先・関連IDのアセットコンテキストマッピングを提供し、ブラスト半径（侵害時の影響範囲）の見積もりを可能にします。しかし、検出された後の対処には運用ルールが不可欠です。

管理モデルの骨格：禁止ではなく登録・承認・廃止

エージェントの作成を全面禁止すると、現場は情シスに隠れて作り続けます。オープンにして登録・審査を通すことで、シャドーエージェントを減らしながら現場のAI活用を守ります。

ライフサイクルごとのルール設計

フェーズルール確認者
作成所有者・利用目的・接続先を台帳に登録責任者
部署内公開所有者・ログ・停止条件を確認責任者 + 情シス
全社公開セキュリティ・法務・費用・運用責任を確認情シス + 法務 or 経営
接続先変更変更前の状態で再審査情シス
廃止90日未使用または責任者不在で廃止候補化情シス

M365管理者が確認する5つのリスクポイント

CopilotやAIエージェントを展開している環境で、管理者が月次で確認すべき項目です。

確認項目ツールリスクが高い状態
エージェント一覧と所有者M365管理センター・Agent 365レジストリ所有者空欄または退職者
SharePoint外部共有設定SharePoint管理センター「全員」または「外部ゲスト含む」が多数
Copilot Studioエージェントの接続先Copilot Studio管理者画面本番機密データに接続している非承認エージェント
Defender Agent SPMのリスクスコアDefender XDR高リスクスコアのエージェントへの未対処
退職者アカウントの残存Entra ID退職後もエージェントオーナーとして残っているID

Copilot Studio管理者が今すぐできる3つの設定

大規模な制度整備の前に、M365管理者が設定できる即効措置があります。

  1. Copilot Studio環境の制限：テナント全体の設定でCopilot Studioの環境作成を「承認制」に変更し、新規エージェント作成時に情シスへの通知を設定します（M365管理センター → Copilot Studio設定 → 環境作成ポリシー）。
  1. DLPポリシーの適用：Copilot Studioエージェントに対してPower Platform DLPポリシーを設定し、機密情報ラベルが付いたデータへのコネクタ接続をブロックします。
  1. エージェントレビューパイプラインの設定：Copilot StudioのApproval機能（2026年4月更新のAgentOps機能）を使い、全社公開エージェントは情シスの承認なしに公開できない状態にします。

現場のAI活用を残しながら管理する考え方

エージェント乱立の本質的な解決は「ツールの制限」ではなく「現場が登録したくなる仕組み」です。登録することで承認が得られ、本番利用できるようになるという正規ルートを整備します。

「シャドーAI申告期間（例：初月は遡及なし）」を設けて既存エージェントの自発的な登録を促し、期間後は棚卸しで検出・是正するという段階的な導入が実務的です。

生成AIガバナンスの整備とあわせて、AIエージェントの作成ルールを業務規程または社内ガイドラインに明記することで、運用の属人化を防ぎます。

GXOの支援

GXOでは、M365 Copilot・Copilot Studioのガバナンス設計から、エージェント台帳の整備・DLPポリシー設計・退職者ID棚卸しまで一体で支援します。すでにエージェントが増えすぎて現状把握ができていない場合は、LLMセキュリティreadiness診断とAIエージェント本番稼働readiness診断を使って優先度付きで現状整理から入ります。

よくある質問

Q1. エージェント乱立はどの規模の企業で起きますか

M365ライセンスとCopilot Studioへのアクセスがある環境であれば、社員50名規模でも起きます。部門横断の管理体制がなければ、規模に関係なく所有者不明エージェントは増えます。

Q2. Defender Agent SPMを使えば乱立は自動解決しますか

Defender Agent SPMは検出と可視化を担います。検出された後の「誰が止めるか・どう是正するか」は人間とプロセスが必要です。検出ツールと運用ルールはセットです。

Q3. 最初に棚卸しすべきものはどれですか

Copilot Studioで作成されたエージェント一覧、SharePointとTeamsの外部共有設定、Entraで管理されていない個人アカウントのエージェント利用の3点を先に確認します。

参考情報

  • Microsoft Security Blog「Microsoft Agent 365, now generally available, expands capabilities and integrations」（2026年5月1日）：https://www.microsoft.com/en-us/security/blog/2026/05/01/microsoft-agent-365-now-generally-available-expands-capabilities-and-integrations/
  • Microsoft Copilot Blog「New and improved agent governance, intelligent workflows, and connected app experiences」（Copilot Studio April 2026 update）：https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/new-and-improved-agent-governance-intelligent-workflows-and-connected-app-experiences/
  • Microsoft Security Blog「Microsoft Build 2026: Securing code, agents, and models across the development lifecycle」：https://www.microsoft.com/en-us/security/blog/2026/06/02/microsoft-build-2026-securing-code-agents-and-models-across-the-development-lifecycle/

M365 Copilot/エージェントの管理モデルを整備しませんか

GXOでは、エージェント台帳の設計・DLPポリシー設定・承認フロー構築・退職者ID棚卸しをまとめて支援します。Agent 365の導入可否も含めて最適な構成を提案します。

エージェント乱立対策を相談する