2026年6月3日公開・更新の公式情報で押さえるべき結論は、Microsoft Agent 365が「AIエージェントを作る機能」ではなく、企業内のAIエージェントを見つけ、承認し、所有者を持たせ、権限とリスクを管理するためのコントロールプレーンとして位置づけられた点です。特にMicrosoft 365管理者は、Agents > Overviewで全体像を確認し、未承認・所有者なし・リスクあり・例外発生中のエージェントから優先的に対応する必要があります。MicrosoftはAgent 365を、組織内で増えるエージェントをobserve、govern、secureするための仕組みとして説明しています。(Microsoft Learn)
AIエージェントは、Copilot StudioやSharePointだけでなく、開発者が作る業務エージェント、外部パートナー製エージェント、将来的には複数クラウド上のエージェントまで含めて増えていきます。放置すると「誰が作ったのか」「どのデータに触れるのか」「退職者が所有したままになっていないか」が見えなくなります。今回のAgent 365 overviewは、その“エージェントの野良化”を防ぐための管理者向け入口と考えると理解しやすいです。
Microsoft Agent 365のAI/Copilot更新で何が変わるのか
今回のポイントは、Microsoft 365管理センター内のAgent workloadが、組織内のエージェントを管理・展開・監視するための起点になることです。公式情報では、Agent workloadからテナント内のエージェントを発見し、発行者や所有者を確認し、可用性やアクセスを制御し、チャネルをまたいだガバナンス方針を適用できると説明されています。(Microsoft Learn)
実務上は、次のような変化として捉えると分かりやすいです。
| 観点 | これまで起きがちな課題 | Agent 365 overviewで確認すること |
|---|---|---|
| インベントリ | Copilot Studio、SharePoint、外部ツールなどにエージェント情報が分散する | テナント内の総数、プラットフォーム別の分布、Registryでの一覧 |
| 所有者管理 | 作成者の異動・退職後に放置される | Agents without ownersを確認し、責任者を再設定 |
| 承認フロー | 部門ごとに公開判断がばらつく | Pending Requestsを確認し、データソース・ツール・権限を見て承認 |
| セキュリティ | 何のデータに触るか、どの操作を実行するかが見えにくい | Data & tools、Permissions、Securityタブで確認 |
| 利用状況 | 作ったが使われない、または例外が多いエージェントに気づきにくい | Active users、Agent run-time、Exceptionsなどの指標を見る |
つまり、Microsoft Agent 365の価値は「AIエージェントを増やすこと」ではなく、「増えたAIエージェントを企業のID、権限、監査、セキュリティのルールに乗せること」にあります。
Microsoft Agent 365はエージェント管理のためのコントロールプレーン
Microsoft Agent 365は、AIエージェントを監視・統制・保護するためのサービスです。Microsoft 365管理センター、Microsoft Entra、Microsoft Purview、Microsoft Defenderと連携し、エージェントの可視化、ライフサイクル管理、アクセス制御、データ保護、脅威対策をまとめて扱う構成になっています。(Microsoft Learn)
ここで重要なのは、Agent 365をCopilot Studioの代替として見ないことです。Copilot StudioやAzure AI Foundryはエージェントを作る側のツールであり、Agent 365はそれらを含むエージェント群を管理する側の仕組みです。開発者向けのAgent 365 SDKも、エージェントを新規にホストするフレームワークではなく、既存のエージェントにID、観測性、通知、ガバナンス、Microsoft 365データへの管理されたアクセスを追加するものとして説明されています。(Microsoft Learn)
利用開始前に確認すべきライセンスと前提条件
Microsoft Agent 365は、2026年5月1日時点でCommercial segment向けに一般提供されており、ユーザー単位のライセンスとして説明されています。公式情報では、Agent 365を有効にするには少なくとも1人のユーザーに対象ライセンスが必要で、Microsoft E5を前提に使うと最適とされています。(Microsoft Learn)
管理者が最初に確認すべきなのは、次の3点です。
| 確認項目 | 確認場所・判断基準 |
|---|---|
| ライセンス | Microsoft 365管理センターのBilling > Licenses > Subscriptionsで対象ライセンスを確認 |
| 管理ロール | 承認・所有者変更などを行う担当者にAI AdministratorまたはGlobal Administratorが必要か確認 |
| 既存のCopilot/Agent利用状況 | Copilot Studio、SharePoint、Agent Builder、Foundry、Teams連携など、どこでエージェントが作られているか棚卸し |
価格や提供条件は国、契約形態、ボリュームライセンス、Microsoft 365 E7の利用有無で変わる可能性があるため、実際の導入時は管理センターまたは契約窓口で確認するのが安全です。
影響範囲：管理者、セキュリティ担当、開発者に何が関係するか
Agent 365 overviewの影響は、Microsoft 365管理者だけに閉じません。AIエージェントがユーザーの代わりにファイル、メール、予定表、Teams、SharePoint、外部APIへアクセスする可能性があるため、ID管理、データ保護、アプリ審査、開発プロセスまで関係します。
| 対象者 | 影響 | まず見るべきポイント |
|---|---|---|
| Microsoft 365管理者 | エージェント全体の棚卸し、公開範囲、インストール、ピン留め、ブロックを管理 | Agents > Overview、All agents、Requests |
| AI Administrator | 承認、所有者割り当て、ガバナンス対応の中心 | Pending requests、Agents without owners、Agents at risk |
| Global Administrator | 全体管理は可能だが、常用は避けるべき高権限ロール | 緊急時・初期設定時のみ利用を検討 |
| Security Administrator / Security Reader | リスクやセキュリティ状況の監視 | Agent Map、Securityタブ、Defender連携 |
| Purview担当 | 機密情報、DLP、監査、コンプライアンス観点を確認 | Data & tools、Security、Activity explorer |
| 開発者 | 公開前にデータソース、ツール、権限、メタデータを整備 | Agent definition、permissions、SDK/CLI、blueprint |
| 部門責任者 | 業務利用の妥当性と所有者責任を持つ | 利用目的、対象ユーザー、廃止判断 |
ロールについては、Global AdministratorとAI Administratorがインサイト閲覧、Registry情報閲覧、インストール・変更・承認・構成管理を行える一方、Reader系やSecurity系の一部ロールは主に監視・閲覧用途に限られます。Microsoftは最小権限の原則を推奨しており、Global Administratorの常用は避けるべきです。(Microsoft Learn)
管理者が最初に見るべき画面と指標
Agent overviewは、Microsoft 365管理センターにサインインし、Agents > Overviewから確認します。この画面では、過去30日を中心にエージェント活動のスナップショット、利用傾向、リスクやガバナンス上のギャップ、承認待ち、所有者なし、テナント内の総エージェント数などを確認できます。(Microsoft Learn)
特に初回確認では、次の順番で見ると実務に落とし込みやすくなります。
| 優先度 | 確認するもの | 判断基準 |
|---|---|---|
| 高 | Pending Requests | 未承認のまま業務公開待ちになっていないか |
| 高 | Agents at risk | 高いセキュリティリスクが検出されたエージェントがないか |
| 高 | Agents without owners | 退職者・異動者が所有したままのエージェントがないか |
| 中 | Agent with exceptions | エラーが多く、業務影響や信頼性低下につながっていないか |
| 中 | Active users / Trending agents | 実際に使われているエージェントを優先的に監査できるか |
| 中 | Agent run-time | エージェントがどれだけ作業しているかを把握できるか |
注意したいのは、Agent 365ライセンスを有効化した直後は、30日分のデータがそろっていない場合があることです。公式情報では、Active usersやAgent run-timeなど一部の指標はライセンス有効化後にデータ収集が始まるため、初期表示では30日未満のデータになることがあると説明されています。(Microsoft Learn)
Agent RegistryとAgent Mapの使い分け
エージェントを一覧で精査するならAgent Registry、全体の分布や偏りを視覚的に把握するならAgent Mapを使います。Agent Mapは、プラットフォームごとにエージェントをグループ化し、所有者なし、リスクあり、アンマネージドなどの状態を見つけやすくする画面です。Microsoft 365管理センターのAgents > All Agents > Mapからアクセスできます。(Microsoft Learn)
Agent overviewのカードだけで判断しないことも重要です。公式情報では、Overview上のプラットフォーム表示はカードに収めるため利用上位5件に限定され、すべてのプラットフォームと関連エージェントを見るにはRegistryタブへ移動すると説明されています。(Microsoft Learn)
また、下書きエージェントの見え方にも制限があります。現時点では、Draft agentとして見えるのはCopilot Studio由来のものに限られ、Agent Builder、Foundry、SharePoint由来の下書きについては表示対象外とされています。つまり「Overviewに下書きが少ない」ことは「社内に未公開エージェントが存在しない」ことを意味しません。(Microsoft Learn)
承認・公開・展開で管理者が確認すべきこと
エージェントが組織内に公開される前に、管理者はRequestsで申請内容を確認します。公式情報では、申請されたエージェントについて、説明、所有者、データ、ツールなどの詳細を確認し、公開または却下できるとされています。公開時には、対象ユーザーやグループを絞って段階的に展開できます。(Microsoft Learn)
承認時は、次の順番で見ると失敗を減らせます。
| 手順 | 確認内容 | よくある失敗 |
|---|---|---|
| 申請内容の確認 | エージェント名、説明、所有者、用途が業務に合っているか | 名前だけで承認し、実際の利用範囲を見落とす |
| データソース確認 | SharePoint、ファイル、URL、Graph connectorなどの参照先が適切か | 外部URLや不要なサイトを知識ソースに含めたまま公開する |
| ツール確認 | メール送信、外部API更新、MCPサーバーなど実行系の操作があるか | 「読むだけ」と思い込み、書き込み操作を見逃す |
| 権限確認 | Application permissionsかDelegated permissionsかを確認 | 組織全体に広く作用する権限を安易に承認する |
| 対象範囲設定 | Available toとInstalled forを分けて設計 | パイロット前に全社へ自動インストールする |
| ポリシー適用 | 既定またはカスタムのポリシーテンプレートを選ぶ | 部門ごとに承認基準がばらつく |
| 公開後監視 | Active users、Exceptions、Securityを確認 | 公開後の利用実態を見ず、放置する |
更新申請にも注意が必要です。開発者が既存エージェントの更新を公開するとPending updateとして表示され、管理者が承認するまでは以前のバージョンがユーザーに提供され続けると説明されています。(Microsoft Learn)
Data & toolsとPermissionsで見るべきポイント
Agent detailsでは、Details、Users、Data & tools、Security、Permissions、Certification、Activityなどのタブを確認できます。ただし表示されるタブはエージェントの機能に依存し、すべてのエージェントに同じ情報が出るわけではありません。(Microsoft Learn)
Data & toolsタブでは、エージェントが何を読めるか、どの知識ソースを使うか、どのツールやアクションを実行できるかを確認します。たとえば、組織ファイル、メール、予定表、SharePointサイト、Web URL、Graph connectors、Microsoft 365 connectors、MCP servers、custom actionsなどが確認対象になります。Data & toolsは読み取り専用で、データソースやツールを変更するには、Copilot StudioやFoundryなど作成元のプラットフォームで開発者が設定を更新する必要があります。(Microsoft Learn)
Permissionsでは、Application permissionsとDelegated permissionsを分けて考える必要があります。Application permissionsはユーザーのサインインなしに組織レベルでデータアクセスや操作を行えるため、影響範囲が広く、管理者の同意が必要になるケースがあります。一方、Delegated permissionsはサインイン中のユーザーの文脈で動作するため、ユーザー単位の操作に向いています。(Microsoft Learn)
実務では、次のように判断すると安全です。
| 権限・機能 | 承認前の判断基準 |
|---|---|
| メール・予定表を読む | 利用目的が明確で、対象ユーザーが必要最小限か |
| SharePointやOneDriveを読む | 機密サイトや全社共有領域まで参照していないか |
| 外部URLを知識ソースにする | 信頼できるURLか、外部情報混入のリスクを説明できるか |
| 外部APIやMCPサーバーを使う | 書き込み、削除、送信など副作用のある操作がないか |
| Application permissionsを要求する | ユーザー単位ではなく組織単位の権限が本当に必要か |
| 自動インストール | 事前検証済みのユーザーグループに限定しているか |
外部プラットフォーム連携はRegistry syncの扱いに注意
Agent 365はMicrosoft 365内のエージェントだけを見る仕組みではありません。Registry syncを使うと、外部AIエージェント環境をMicrosoft 365管理センターに接続し、Agent 365 agent registryへ同期して一元的な可視化とガバナンスにつなげられます。ただし、Registry syncはプレビュー機能であり、本番利用を前提にした扱いではない点に注意が必要です。(Microsoft Learn)
公式情報では、Registry syncの対応プラットフォームとしてAmazon Bedrock、Google Vertex AI、Salesforce Agentforce、Databricks Genieが挙げられています。接続では外部環境の認証情報を登録し、同期状態、最終同期、エラー、同期されたエージェント数などを確認できます。将来の同期スケジュール設定については、今後のリリースで構成可能になると説明されています。(Microsoft Learn)
この機能を試す場合は、いきなり全社の外部AI基盤を接続するのではなく、次の条件で小さく始めるのが現実的です。
| 観点 | 推奨する進め方 |
|---|---|
| 対象環境 | 検証用または限定部門の環境から始める |
| 認証情報 | 専用アカウントやサービスプリンシパルを使い、権限を最小化する |
| 同期後レビュー | 同期されたエージェント名、所有者、データソース、削除・ブロック可能性を確認 |
| 契約・規約 | 外部サービス側の利用規約、ログ、データ転送、監査要件を確認 |
| 本番移行 | プレビュー機能であることを前提に、運用手順と責任分界を明文化する |
開発者が対応すべき設定・移行ポイント
開発者にとってのポイントは、「動くエージェント」から「管理できるエージェント」へ設計を変えることです。Agent 365 SDKを使うと、既存の任意のSDKやプラットフォームで構築したエージェントに、Entra-backed Agent Identity、通知、OpenTelemetryによる観測性、管理されたMCPサーバー経由のMicrosoft 365ワークロードアクセス、IT承認済みblueprintを追加できます。(Microsoft Learn)
移行時にすべてのエージェントを書き直す必要があるとは限りません。公式情報では、Google Vertex AIやAmazon Bedrockのエージェント登録について、まずはAPI経由で取り込まれ、SDK統合やblueprint、コード変更なしに登録できるパスも示されています。その後、必要に応じてAgent 365 SDKで観測性やWork IQ tool accessなどを段階的に追加する考え方です。(Microsoft Learn)
開発チームは、公開前チェックリストを次のように整えると管理者レビューが進みやすくなります。
| 開発者が用意する情報 | 管理者が見たい理由 |
|---|---|
| エージェントの目的と対象業務 | 不要・重複・高リスクなエージェントを避けるため |
| 所有者と運用担当 | 変更、障害、廃止、監査時の責任者を明確にするため |
| 知識ソース一覧 | 参照してよいデータか判断するため |
| 実行可能なツール・アクション | 読み取り専用か、書き込み・送信・削除を行うか判断するため |
| 要求する権限 | Application permissionsとDelegated permissionsの妥当性を確認するため |
| ログ・トレース設計 | 例外、利用状況、監査対応を可能にするため |
| バージョン管理と更新手順 | 更新申請時に差分を説明できるようにするため |
展開時に避けたい失敗パターン
Agent 365 overviewを導入しても、運用設計が弱いと「見えるようになっただけ」で終わります。特に以下の失敗は起こりやすいため、初期ルールとして明文化しておくべきです。
| 失敗パターン | なぜ危険か | 対策 |
|---|---|---|
| 全社公開を初期値にする | 誤った権限や未検証の応答が広範囲に影響する | まず特定ユーザー・特定グループへ限定展開 |
| 所有者を作成者任せにする | 異動・退職後に責任者不在になる | 部門責任者と技術責任者を分けて登録 |
| Data & toolsが空なので安全と判断する | 未設定、未同期、非対応タイプの可能性がある | 作成元プラットフォーム側の設定も確認 |
| 利用が少ないエージェントを放置する | 古い権限や外部接続が残り続ける | 四半期ごとに低利用・所有者なしを廃止候補にする |
| Application permissionsを安易に承認する | 組織全体のデータや操作に影響し得る | Delegated permissionsで足りるか先に検討 |
| Registry syncを本番前提で設計する | プレビュー機能の仕様変更や制限に影響される | 検証環境から開始し、運用手順を分離 |
| 管理ロールをGlobal Administratorに集中させる | 過剰権限と監査リスクが高まる | AI Administratorなど最小権限ロールを優先 |
管理者が今日やるべき初動チェック
Microsoft Agent 365を導入済み、または導入予定の組織では、まず大きな設計資料を作るよりも、現状のエージェント棚卸しから始めるのが効果的です。
最初の確認は次の順番で進めます。
- Microsoft 365管理センターでAgent 365関連ライセンスと管理ロールを確認する。
- Agents > Overviewを開き、総エージェント数、承認待ち、所有者なし、リスクあり、例外ありを確認する。
- All agentsのRegistryまたはMapで、プラットフォーム別、発行者別、チャネル別に分布を見る。
- 利用頻度の高いエージェントからData & tools、Permissions、Security、Activityを確認する。
- Pending Requestsは、データソース、ツール、権限、対象ユーザーを見て、限定公開または却下を判断する。
- 所有者なしのエージェントは、部門責任者を決めるまで新規展開や拡張を止める。
- 開発者に、今後の申請時に提出すべき情報テンプレートを配布する。
- 外部AI基盤がある場合は、Registry syncを検証扱いで評価し、認証情報と責任分界を整理する。
最終的に目指すべき状態は、「AIエージェントを禁止すること」ではありません。誰が所有し、どのデータに触れ、どの権限で動き、どのユーザーに展開され、問題が起きた時に誰が止めるのかを説明できる状態にすることです。
Microsoft Agent 365 overviewは、そのための入口です。まずはAgents > Overviewで現状を見える化し、承認待ち、所有者なし、リスクありのエージェントから順に処理してください。そのうえで、開発者にはAgent 365 SDKやメタデータ整備を求め、管理者は最小権限、段階展開、定期レビューを運用ルールに組み込むのが現実的な進め方です。
コメント