Microsoft Agent 365 documentationの要点は、AIエージェントを「作って使う」段階から、組織全体で「見える化し、権限を管理し、リスクを抑える」段階へ移行することです。特に管理者は、Microsoft 365管理センターのAgent Registry、所有者不在のエージェント、権限、データソース、リスクシグナルを確認する必要があります。開発者は、Agent 365 SDKやGraph APIの位置づけを理解し、既存エージェントをガバナンス対象に組み込む設計へ見直すことが重要です。
Microsoft Agent 365は、MicrosoftがAIエージェント向けの「コントロールプレーン」として位置づけるサービスです。公式ドキュメントでは、IT部門やセキュリティ部門が組織内のエージェントを監視、保護、管理するための基盤として説明されています。Microsoft 365 Copilot、Copilot Studio、SharePoint、Azure AI Foundry、外部パートナー製エージェントなど、発生元が異なるエージェントを一元的に把握することが狙いです。(Microsoft Learn)
Microsoft Agent 365 documentationで何が変わるのか
今回のMicrosoft Agent 365 documentationで押さえるべき変化は、AIエージェントが単なる便利機能ではなく、管理対象の「非人間アクター」として扱われる点です。
従来、多くの企業ではエージェント管理が部門単位、開発環境単位、アプリ単位に分散しがちでした。Copilot Studioで作ったエージェント、SharePointで作成されたエージェント、外部SaaSやローカル環境で使われるAIツールが混在すると、誰が作成し、どのデータにアクセスし、どのユーザーが使っているのかを把握しにくくなります。
Agent 365はこの課題に対して、次の3つを中心に整理されています。
| 変更点 | 実務上の意味 | 確認すべき担当 |
|---|---|---|
| Observe | エージェントの利用状況、アクティビティ、リスク、例外を可視化する | Microsoft 365管理者、AI管理者 |
| Govern | 所有者、公開範囲、インストール対象、承認、削除などを統制する | AI管理者、Global Administrator |
| Secure | Entra、Defender、Purviewと連携し、ID・権限・データ漏洩・脅威を管理する | セキュリティ管理者、コンプライアンス担当 |
特に重要なのは、Agent 365がMicrosoft 365管理センター内の管理体験と結びついていることです。公式情報では、Agent workloadが組織内のエージェントを管理、展開、監視するための概要ビューを提供し、利用状況やガバナンスのインサイトを確認できるとされています。(Microsoft Learn)
影響範囲はMicrosoft 365 Copilot利用企業だけに限られない
Microsoft Agent 365の影響は、Microsoft 365 Copilotをすでに全社導入している企業だけにとどまりません。AIエージェントを業務で使う可能性がある組織全体が対象になります。
影響が大きいのは、次のような環境です。
| 環境・利用状況 | 影響 |
|---|---|
| Copilot Studioで部門ごとにエージェントを作成している | 作成者、公開範囲、利用状況、権限の棚卸しが必要 |
| Microsoft 365 Copilot ChatやTeamsでエージェントを使っている | どのユーザーにどのエージェントを表示・インストールさせるかを管理する必要がある |
| SharePointやOneDrive上のファイルをナレッジとして使うエージェントがある | 機密情報、ラベル、アクセス権、情報バリアの扱いを確認する必要がある |
| 外部パートナー製エージェントを導入する | 認証、権限、認定情報、データの取り扱いを審査する必要がある |
| 開発者が独自エージェントやMCPサーバーを使っている | 未承認のローカルAIやシャドウAIの検出・制御が課題になる |
Microsoftは、Agent 365を2026年5月1日時点でCommercial向けに一般提供しており、少なくとも1人に対象ライセンスが割り当てられていることが有効化の条件として示されています。また、Entra P1/P2またはEntra Suite、Purview DLPなどを併用すると、より多くの保護機能を活用しやすいとされています。(Microsoft Learn)
管理者が最初に確認すべき設定
管理者が最初に行うべきことは、新機能をすぐ全社展開することではありません。まず、組織内のエージェントを棚卸しし、リスクの高いものから順に管理対象へ入れることです。
Agent Registryで全体像を確認する
Microsoft 365管理センターのAgent Registryは、組織で利用可能なエージェントを一覧で確認するための中心的な画面です。公式ドキュメントでは、Microsoft製、外部パートナー製、自社公開、作成者共有のエージェントが分類されると説明されています。(Microsoft Learn)
まず確認すべき項目は次の通りです。
| 確認項目 | 見るべき理由 |
|---|---|
| Total agents | 組織内にどれだけエージェントが存在するか把握する |
| Agents without owners | 退職者や異動者が作ったまま放置されたエージェントを見つける |
| Unmanaged agents | Agent 365の保護や可観測性の外にあるエージェントを把握する |
| Publisher Type | Microsoft製、外部製、自社製、ユーザー共有を分けてリスク評価する |
| Channel | Copilot、Teams、Outlook、SharePointなど利用面を確認する |
| Data source | 埋め込みナレッジやファインチューニング済みモデルの有無を確認する |
実務では、まずCSVエクスポートや一覧確認を使って、エージェント名、所有者、公開範囲、利用チャネル、権限、データソースを台帳化します。情報システム部門だけで判断せず、各部門の業務オーナーに「本当に必要なエージェントか」「機密情報に触れてよいか」を確認する運用が現実的です。
AI AdministratorとGlobal Administratorの使い分けを整理する
Agent 365の管理では、誰にどの権限を付与するかが重要です。Microsoft 365管理センターのエージェント管理では、閲覧できるロールと、承認・所有者割り当てなどのガバナンス操作ができるロールが分かれます。公式ドキュメントでは、Global AdministratorとAI Administratorがインサイト閲覧、レジストリ閲覧、構成管理の操作に対応するとされています。(Microsoft Learn)
| ロール | 主な使い方 |
|---|---|
| AI Administrator | エージェントの承認、構成管理、所有者割り当てなどの日常運用に使う |
| Global Administrator | 緊急時や初期設定など、最小限の場面に限定する |
| Security Administrator / Security Reader | リスクやセキュリティ観点の確認に使う |
| Global Reader / AI Reader | 監査・レポート確認など読み取り中心の用途に使う |
失敗しやすいのは、すべての作業をGlobal Administratorで行う運用です。権限が強すぎるため、日常運用はAI Administratorを中心にし、Global Administratorは例外的に使う設計にしておくべきです。
所有者不在のエージェントを優先的に処理する
Agent 365管理で最初に潰すべきリスクは、所有者不在のエージェントです。共有エージェントは、作成者が退職・削除されると所有者不在になる場合があります。Microsoft 365管理センターでは、所有者不在のエージェントを特定し、ブロックや削除などの対応ができると説明されています。(Microsoft Learn)
判断基準は次のようにすると実務で迷いにくくなります。
| 状態 | 推奨対応 |
|---|---|
| 業務で利用中、代替がない | 新しい所有者を割り当て、権限とデータソースを再確認する |
| 利用実績が少ない | 一時的にブロックし、利用部門へ確認する |
| 作成目的が不明 | 削除候補として扱い、一定期間後に削除する |
| 機密情報にアクセスする可能性がある | セキュリティ部門と確認し、必要に応じて即時ブロックする |
所有者不在のまま放置すると、誰も権限見直しやメンテナンスを行わない状態になります。AIエージェントはメール、ファイル、カレンダー、外部APIなどに触れる可能性があるため、通常のアプリよりも所有者管理を厳格にすべきです。
エージェントの展開・公開で注意すべきポイント
Agent 365では、エージェントのインストール、アンインストール、ブロック、削除、所有者割り当て、ストア公開、申請却下などのライフサイクル操作がMicrosoft 365管理センターから行えます。公式ドキュメントでは、管理者が組織全体または特定のユーザー・グループに対してエージェントをインストールできると説明されています。(Microsoft Learn)
「Available to」と「Installed for」を混同しない
展開時に特に間違えやすいのが、利用可能範囲と自動インストール範囲の違いです。
| 設定 | 意味 | 例 |
|---|---|---|
| Available to | ユーザーがそのエージェントを見つけてインストールできる範囲 | 営業部だけが営業支援エージェントを見つけられる |
| Installed for | 管理者が対象ユーザーへ事前インストールする範囲 | 新入社員全員にFAQエージェントを自動で入れる |
公式ドキュメントでは、この2つは独立した操作として説明されています。特定グループに公開したエージェントを、別のグループへ事前インストールすることもできます。(Microsoft Learn)
実務では、まず「Available to」を小さなパイロットグループに限定し、利用状況と問い合わせを確認してから「Installed for」を広げるのが安全です。最初から全社インストールすると、誤回答、権限不足、想定外のデータ参照が起きたときに影響範囲が大きくなります。
ブロックと削除の違いを理解する
不要なエージェントへの対応では、ブロックと削除を使い分けます。
| 操作 | 使う場面 | 注意点 |
|---|---|---|
| ブロック | 一時停止、調査、リスク確認中 | ユーザーは利用できなくなるが、調査・復旧の余地を残せる |
| アンインストール | 特定ユーザーや組織から外したい | Copilot、Outlook、Teamsなどホスト製品での利用に影響する |
| 削除 | 不要と確定したエージェントを消す | エージェントと関連データが永続的に削除される場合がある |
リスクが疑われる場合は、いきなり削除せず、まずブロックして利用状況・所有者・権限・ログを確認するのが安全です。
セキュリティ面で確認すべき設定
Microsoft Agent 365 documentationで重要なのは、セキュリティが後付けではなく、Entra、Defender、Purviewと連携する前提で設計されている点です。Microsoftは、Agent 365が既存のセキュリティ基盤をAIエージェントに拡張すると説明しています。(Microsoft Learn)
権限はアプリケーション権限と委任権限を分けて見る
エージェントの権限確認では、アプリケーション権限と委任権限を分けて評価する必要があります。
| 権限の種類 | 特徴 | リスク評価の観点 |
|---|---|---|
| Application Permissions | ユーザーのサインインなしで組織レベルのデータへアクセスできる | 影響範囲が広いため、管理者同意と最小権限の確認が必須 |
| Delegated Permissions | サインイン中のユーザーの権限で動作する | ユーザー権限を超えにくいが、実行内容の監査が必要 |
公式ドキュメントでは、Application Permissionsはユーザーコンテキストなしで動作し、組織レベルで広範なデータにアクセスできる可能性があるため、通常は管理者同意が必要と説明されています。(Microsoft Learn)
実務では、次のような権限を見つけたら慎重に審査してください。
User.Read.Allのように全ユーザープロファイルへアクセスする権限- Teamsやメールに通知・送信できる権限
- ディレクトリやロール管理情報を読む権限
- 外部APIやMCPサーバーを呼び出せるカスタムアクション
「便利そうだから許可する」ではなく、「このエージェントの目的に本当に必要か」「読み取りだけでよいのか」「特定グループに限定できるか」を確認します。
ナレッジソースとツールを必ず見る
エージェントは、回答に使うナレッジソースと、実行できるツールの両方を持ちます。ナレッジソースは「何を読めるか」、ツールは「何を実行できるか」です。
公式ドキュメントでは、Web URL、SharePointサイト、ファイル・フォルダー、Graph connectorsなどがナレッジソースとして示されています。また、Microsoft 365コネクタ、MCPサーバー、Work IQ tools、カスタムアクションなどがツールとして例示されています。(Microsoft Learn)
確認時のポイントは次の通りです。
| 対象 | 確認ポイント |
|---|---|
| Web URL | 承認済みの公式サイト・社内サイトか。不明な外部URLが含まれていないか |
| SharePointサイト | 機密情報や人事・財務情報を含むサイトが指定されていないか |
| アップロードファイル | 古い規程、個人情報、契約情報が混ざっていないか |
| MCPサーバー | 誰が管理し、どの操作が可能か |
| カスタムアクション | 書き込み、送信、更新、削除を行う処理がないか |
特に、ツールがメール送信、レコード更新、外部システム連携を行う場合は、単なる検索エージェントとはリスクが大きく異なります。利用部門の責任者、情報セキュリティ、開発者の3者でレビューする運用にしてください。
埋め込みファイルを使うエージェントはSharePoint Embeddedも確認する
Agent Builderでアップロードされたファイルは、SharePoint Embeddedコンテナーに保存され、エージェントの回答根拠として使われる場合があります。公式ドキュメントでは、対応ファイル形式やサイズ上限、1エージェントあたり最大20ファイルなどの制限が示されています。また、SharePoint Embeddedコンテナーを削除すると、対象ファイルに依存するエージェントの機能が壊れる可能性があるとされています。(Microsoft Learn)
注意すべき点は、アップロードファイルに対してMicrosoft Purview Information Barriersがサポートされないと明記されている点です。エージェントにアクセスできるユーザーは、埋め込みファイルを根拠にした回答を見られる可能性があります。(Microsoft Learn)
つまり、ファイル単体のアクセス権だけで安心してはいけません。エージェントの公開範囲が広すぎると、意図しないユーザーにファイル内容が要約・回答として伝わる可能性があります。
シャドウAIへの対応はプレビュー機能として慎重に扱う
Shadow AIは、IT部門が把握・承認していないAIツールやローカルエージェントの利用を指します。Microsoft 365管理センターのShadow AIページは、未管理のAIエージェントを検出・監視・統制するための機能として説明されていますが、現時点ではプレビュー扱いです。(Microsoft Learn)
公式ドキュメントでは、Shadow AIの例として、未承認のAIコーディングアシスタント、ローカルエージェント、MCPサーバー、AI機能を持つブラウザー拡張などが挙げられています。プレビュー中は、検出・ブロック対象や動作が変わる可能性があるため、本番運用では「補助的な検出手段」として扱うのが安全です。(Microsoft Learn)
特に注意すべき条件は次の通りです。
| 項目 | 注意点 |
|---|---|
| ライセンス | Shadow AI Agentsの表示にはMicrosoft 365 E3など条件がある |
| ロール | Security Administrator、AI Administrator、Global Readerなど対象ロールが必要 |
| デバイス | Microsoft Intuneに登録された管理対象Windowsデバイスが前提 |
| プレビュー | 対応エージェントや挙動は一般提供前に変わる可能性がある |
検出後にブロックする場合、Intuneポリシーを通じて管理対象Windowsデバイスへ反映されます。公式ドキュメントでは、Intune構成によってポリシー反映に15分から最大8時間かかる可能性があると説明されています。(Microsoft Learn)
開発者が確認すべき移行・実装ポイント
開発者にとってのMicrosoft Agent 365 documentationのポイントは、Agent 365 SDKがエージェントを「作る」ためのフレームワークではなく、既存エージェントに企業向けのID、可観測性、通知、セキュリティ、Microsoft 365データへの管理されたアクセスを追加するための層である点です。(Microsoft Learn)
Agent 365 SDKは既存エージェントを置き換えるものではない
Microsoft Agent Framework、Copilot Studio、OpenAI Agents SDK、LangChain SDKなどで作られたエージェントがある場合でも、Agent 365 SDKはそれらを置き換えるものではありません。公式ドキュメントでは、Agent 365 SDKは任意のSDKやプラットフォームで作成されたエージェントに、EntraベースのAgent Identity、OpenTelemetryベースの可観測性、通知、Work IQツールアクセス、ガバナンスを追加するものと説明されています。(Microsoft Learn)
開発者が確認すべき項目は次の通りです。
| 確認項目 | 実務上のチェック |
|---|---|
| Agent Identity | エージェント単位で誰が責任を持つか、どのIDで動くか |
| Telemetry | OpenTelemetryでトレース、メトリック、ログを出せるか |
| Permissions | アプリケーション権限と委任権限を分離して設計しているか |
| Tools | MCPサーバーや外部APIの操作範囲を最小化しているか |
| Blueprint | IT承認済みのテンプレートとして再利用できる設計か |
| Lifecycle | 作成、公開、更新、停止、削除の手順があるか |
エージェント開発では、プロンプトやモデルの精度だけに注目しがちです。しかし、Agent 365時代には「監査できるか」「所有者を追跡できるか」「権限を説明できるか」が本番投入の条件になります。
Graph API利用者はAgent 365ベースAPIへの移行を計画する
既存のAgent Registry APIを利用している開発者や管理者は、API移行にも注意が必要です。Microsoft Graph betaのagentRegistryリソースでは、2026年5月以降、Microsoft GraphのAgent Registry APIがMicrosoft Agent 365ベースのAPIに置き換えられる予定であり、新しいAgent 365ベースAPIへの移行計画が推奨されています。(Microsoft Learn)
また、Agent 365側のGraph APIドキュメントでは、エージェントレジストリデータへプログラムでアクセスし、一覧取得や個別詳細取得を通じて、バルク管理、オンボーディング、ガバナンス統合を自動化できるとされています。ただし、これらのAPIはプレビューであり、AI adminまたはGlobal adminロールが必要です。(Microsoft Learn)
既存システムでエージェント台帳、承認ワークフロー、監査レポートを自動化している場合は、次の観点で見直してください。
| 見直し対象 | 確認内容 |
|---|---|
| APIエンドポイント | 旧Agent Registry APIを前提にしていないか |
| 権限 | AI AdministratorまたはGlobal Administratorが必要な処理を最小化しているか |
| 台帳同期 | Microsoft 365管理センター上のAgent Registryと矛盾しないか |
| 監査ログ | いつ、誰が、どのエージェントを承認・変更したか残せるか |
| エラー処理 | プレビューAPIの仕様変更に備えた例外処理があるか |
プレビューAPIを本番の唯一の情報源にすると、仕様変更時に業務影響が出る可能性があります。まずはレポートや棚卸しなど、読み取り中心の用途から試すのが現実的です。
導入時に失敗しやすいポイント
Microsoft Agent 365は、AIエージェントの管理を楽にする仕組みですが、導入すれば自動的に安全になるわけではありません。失敗しやすいのは、機能を有効化しただけで運用ルールを作らないケースです。
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| 全社展開を急ぎすぎる | 誤ったエージェントが広範囲に使われる | パイロットグループから始める |
| 所有者を決めない | 退職・異動後に管理不能になる | 部門オーナーと技術オーナーを分けて登録する |
| 権限レビューを省略する | 過剰なGraph権限や外部連携が残る | 公開前に権限レビューを必須化する |
| ナレッジソースを確認しない | 古い情報や機密情報を根拠に回答する | SharePoint、ファイル、URLを棚卸しする |
| ブロックと削除を混同する | 復旧不能な削除や調査不能が起きる | 調査中はブロック、不要確定後に削除する |
| プレビュー機能を本番前提で扱う | 仕様変更や対象範囲変更に振り回される | Shadow AIやGraph APIは変更前提で運用する |
独自の判断基準としては、「このエージェントが誤動作した場合、どのデータが漏れるか」「誰の名前で操作されるか」「業務停止時に誰が止められるか」を答えられないものは、本番展開しない方が安全です。
まず実施すべきチェックリスト
Microsoft Agent 365 documentationを読んだ管理者・開発者が次に取るべき行動は、次の順番で整理すると進めやすくなります。
| 優先度 | 作業 | 担当 |
|---|---|---|
| 高 | Microsoft 365管理センターでAgents > OverviewとRegistryを確認する | Microsoft 365管理者 |
| 高 | 所有者不在、未管理、リスクありのエージェントを抽出する | AI管理者、セキュリティ担当 |
| 高 | AI Administrator、Security Readerなどロール設計を見直す | ID管理担当 |
| 高 | エージェントの権限、ナレッジソース、ツールを確認する | 管理者、開発者 |
| 中 | 公開範囲と自動インストール範囲をグループ単位で設計する | 情シス、業務部門 |
| 中 | Agent 365 SDKで可観測性やID連携を追加できるか確認する | 開発者 |
| 中 | Graph API利用箇所を洗い出し、Agent 365ベースAPIへの移行方針を作る | 開発者、運用担当 |
| 低〜中 | Shadow AIプレビューを試験導入し、Intune管理対象端末で検出・ブロックを検証する | セキュリティ、端末管理担当 |
最初のゴールは、すべてのエージェントを完璧に管理することではありません。まず「組織内に何があるか」「誰が責任を持つか」「危ないものを止められるか」を明確にすることです。
まとめ：Agent 365はAIエージェント時代の管理基盤として早めに棚卸しすべき
Microsoft Agent 365 documentationの実務上のポイントは、AIエージェントをアプリやチャットボットの延長ではなく、ID、権限、データアクセス、監査、ライフサイクルを持つ管理対象として扱うことです。
管理者は、Microsoft 365管理センターのAgent Registryでエージェントの全体像を把握し、所有者不在、過剰権限、機密データ参照、未管理エージェントを優先して確認してください。開発者は、Agent 365 SDKやGraph APIの位置づけを理解し、既存エージェントを可観測性とガバナンスに対応させる準備が必要です。
次に行うべきことは、Agent 365の機能を一気に全社展開することではありません。まずはエージェント台帳を作り、所有者・権限・データソース・公開範囲を棚卸しすることです。そのうえで、重要度の高い業務エージェントから、承認フロー、権限レビュー、監査、停止手順を整備していくと、安全にAI活用を広げられます。
コメント