Microsoft PurviewでMicrosoft Agent 365を管理する最大のポイントは、AIエージェントを「人と同じように監査・DLP・リスク管理・eDiscovery・保持ポリシーの対象に入れる」ことです。Agent 365のエージェントインスタンスを作成すると、監査、データ分類による機密データ検出、Compliance ManagerのAI規制評価は自動的に有効になります。一方で、DLPやインサイダーリスク管理などは、管理者がエージェントインスタンスまたはエージェントを含むセキュリティグループをポリシーに明示的に含める必要があります。(Microsoft Learn)
この記事では、Microsoft Purviewの「Use Microsoft Purview to manage data security & compliance for Microsoft Agent 365」をもとに、影響範囲、設定変更、移行期限の有無、管理者が確認すべきポイントを整理します。なお、対象のPurviewページの最終更新表示は2026年5月1日で、Agent 365とMicrosoft Foundry統合に関する関連公式ページは2026年6月25日更新です。本稿では、2026年6月25日時点で実務上あわせて確認すべき公式情報として整理します。(Microsoft Learn)
Microsoft PurviewでAgent 365を管理する意味
Microsoft Agent 365は、組織内のAIエージェントを監視、管理、保護するためのコントロールプレーンです。エージェントをMicrosoft EntraのIDとして扱い、認証、承認、ライフサイクルガバナンスを適用できる点が特徴です。Microsoft Purviewは、その中でデータ保護、DLP、監査、eDiscovery、保持、コンプライアンス評価を担います。(Microsoft Learn)
従来のアプリ管理では、「誰がファイルにアクセスしたか」「どのユーザーが機密情報を送信したか」を中心に管理していました。Agent 365では、そこに「どのエージェントが、どのデータを使い、誰とやり取りしたか」という観点が加わります。
特に重要なのは、エージェントが自律的に処理を進める場合でも、セキュリティとコンプライアンスの管理対象から外してはいけないという点です。人間のユーザーだけでなく、エージェントも監査、DLP、リスク管理、保持、調査の対象として扱う必要があります。
今回の更新ポイントを一言で整理
Microsoft PurviewのAgent 365対応は、「AIエージェントの利用状況を見える化する機能」だけではありません。データ分類、秘密度ラベル、DLP、インサイダーリスク管理、通信コンプライアンス、eDiscovery、データライフサイクル管理、Compliance Managerまで含めて、AIエージェントのデータ利用を統制するための実務的な枠組みです。(Microsoft Learn)
| 確認ポイント | 管理者が見るべき内容 |
|---|---|
| 自動で有効になるもの | 監査、データ分類による機密データ検出、Compliance ManagerのAI規制評価 |
| 手動設定が必要なもの | DLP、インサイダーリスク管理、通信コンプライアンス、eDiscovery、保持ポリシーなどへのエージェント追加 |
| 最初に見る画面 | Microsoft PurviewポータルのDSPM > AI observability |
| 注意すべき制限 | Agent 365では「秘密度ラベルなしの暗号化」はサポート対象外 |
| グローバル運用の注意 | FoundryとAgent 365でデータ所在地モデルが異なる場合がある |
影響範囲：どのデータと操作が対象になるのか
影響を受けるのは、Microsoft Agent 365を利用する管理者だけではありません。Microsoft 365、Microsoft Foundry、Copilot Studio、SharePoint、OneDrive、Teams、Exchange、Microsoft Entra、Microsoft Defender XDR、法務・監査部門まで関係します。
Agent 365のエージェントインスタンスでは、人間とエージェント、エージェントとツール、エージェント同士のやり取りなど、複数のAIインタラクションが監査対象として扱われます。監査イベントには、AIアプリとの対話の方法やタイミング、関連するMicrosoft 365サービス、アクセスされたファイル参照、秘密度ラベルの情報などが含まれる場合があります。(Microsoft Learn)
| 影響範囲 | 具体例 | 管理者の確認ポイント |
|---|---|---|
| エージェントインスタンス | Agent 365上で作成・登録されたエージェント | 所有者、エージェントユーザーID、作成日、リスクレベルを確認する |
| AIインタラクション | 人間からエージェント、エージェントから人間、エージェントからツール、エージェント間の操作 | 監査ログとDSPMのAIアクティビティで追跡できるか確認する |
| Microsoft 365データ | Teams、SharePoint、OneDrive、メールなど | DLP、保持、eDiscoveryの対象に含める |
| 機密情報 | 個人情報、財務情報、知的財産、契約情報など | データ分類と秘密度ラベルの設計を見直す |
| Foundryエージェント | Foundryで作成・公開されたエージェント | Agent 365への同期、データ収集、オプトアウト設定を確認する |
| グローバルテナント | 複数国・複数リージョンで運用する環境 | データ所在地と監査要件を確認する |
サポートされるMicrosoft Purview機能
Agent 365では、Microsoft Purviewの主要なデータセキュリティ・コンプライアンス機能がAIインタラクション向けにサポートされています。公式ページでは、DSPM、監査、データ分類、秘密度ラベル、DLP、インサイダーリスク管理、通信コンプライアンス、eDiscovery、データライフサイクル管理、Compliance Managerがサポート対象として示されています。一方で、Agent 365固有の表では「秘密度ラベルなしの暗号化」はサポート対象外です。(Microsoft Learn)
| Microsoft Purview機能 | Agent 365での意味 | 実務での確認ポイント |
|---|---|---|
| DSPM | AIエージェントの利用状況、リスク、推奨修復策を確認する入口 | DSPM > AI observabilityを最初に確認する |
| 監査 | プロンプト、応答、AI操作を統合監査ログで追跡 | Agent 365 activitiesを検索できるか確認する |
| データ分類 | プロンプトや応答内の機密情報を検出 | 組み込みSITだけで足りるか、カスタム分類が必要か確認する |
| 秘密度ラベル | ラベル付きデータの利用制御をAIにも反映 | SharePointとOneDriveでラベルが有効か確認する |
| DLP | 機密情報の送信・共有を監査またはブロック | エージェントインスタンスをDLPポリシーに含める |
| インサイダーリスク管理 | データ流出、危険なAI利用、プロンプトインジェクションなどを検出 | Risky AI usageテンプレートの利用を検討する |
| 通信コンプライアンス | Teamsやメール上の不適切なAI対話を検出 | 対象チャネルとレビュー体制を決める |
| eDiscovery | AI対話データを訴訟・監査対応で検索・保持・エクスポート | ユーザーやエージェントを検索対象として扱えるか確認する |
| データライフサイクル管理 | プロンプトと応答の保持・削除を制御 | Teams、SharePoint、OneDrive、メールの保持要件を整理する |
| Compliance Manager | AI規制への対応状況を評価 | AI規制評価テンプレートを確認する |
管理者が最初に確認すべき設定
Agent 365の管理では、まずMicrosoft PurviewポータルでDSPMのAI observabilityを確認します。公式情報では、Agent 365のデータセキュリティとコンプライアンス管理を開始するには、Entra Compliance Administratorロール、またはMicrosoft Purview Compliance Administratorロールグループなど、適切な権限を持つアカウントが必要です。画面遷移は、Microsoft PurviewポータルからDSPM > AI observabilityです。(Microsoft Learn)
ここで注意したいのは、現在のDSPMと「Data Security Posture Management for AI（classic）」を混同しないことです。公式ページでは、classic版はAgent 365をサポートしないと明記されています。(Microsoft Learn)
AI observabilityで確認する項目
AI observabilityでは、過去30日間にアクティビティがあるエージェントの概要、リスクの高いアクティビティ、特定エージェントの詳細、修復推奨事項を確認できます。エージェントの詳細には、Entra有効状態、作成日、所有者、エージェントユーザーID、どのエージェントのインスタンスかといった情報が含まれます。(Microsoft Learn)
実務では、次の順番で確認すると抜け漏れを減らせます。
| 確認順 | 作業 | 判断基準 |
|---|---|---|
| 1 | 過去30日間に動作したエージェントを一覧化 | 所有者不明、用途不明、リスク高のエージェントを優先 |
| 2 | エージェントごとの所有者を確認 | 所有者が退職者、共有アカウント、未設定なら是正対象 |
| 3 | 参照しているデータを確認 | SharePoint、OneDrive、メール、Teamsの機密データに触れていないか |
| 4 | リスク活動を確認 | 過剰共有、データ流出、非倫理的な挙動を重点確認 |
| 5 | Purviewの推奨修復策を確認 | DLP、ラベル、保持、リスク管理のどれで対処するか決める |
DLPポリシーではエージェントを明示的に対象化する
DLPは、Agent 365対応で特に誤解しやすい機能です。ユーザー向けDLPを設定済みでも、エージェントインスタンスが自動的にすべての既存ポリシー対象になるとは限りません。公式情報では、DLPポリシーでエージェントインスタンスをユーザーと同様に明示的に指定するか、エージェントインスタンスを含むセキュリティグループを指定する形でサポートされると説明されています。(Microsoft Learn)
DLPでサポートされる操作として、Microsoft Teams、OneDrive、SharePoint、メールにおけるエージェントと人間のやり取りのブロックまたは監査が示されています。ただし、エージェントインスタンスはブロックアクションを認識しないため、エージェント所有者がDLPポリシーを積極的に監視し、後続ワークフローへの影響を理解する必要があります。(Microsoft Learn)
DLP設定で失敗しやすい例
| 失敗例 | なぜ問題か | 対策 |
|---|---|---|
| 人間ユーザー向けDLPだけで十分だと思い込む | エージェントがポリシー対象外になる可能性がある | エージェントインスタンスまたは専用グループを対象に追加する |
| いきなりブロックにする | 業務ワークフローが止まってもエージェント側で適切に説明できない場合がある | まず監査モードで影響を確認する |
| エージェント所有者に通知しない | DLPによる停止を障害と誤認する | 所有者、運用担当、セキュリティ担当の連絡経路を決める |
| Teamsだけ確認する | OneDrive、SharePoint、メールでの漏えいを見落とす | 利用チャネルごとにDLP対象を確認する |
秘密度ラベルと暗号化で確認すべきポイント
Agent 365で機密データを扱う場合、秘密度ラベルの設計が重要です。Microsoft PurviewがサポートするAIアプリでは、ユーザーがアクセス権を持たないテナント内データがAIから返されないよう、既存のアクセス制御が使われます。さらに、秘密度ラベルが適用されている場合は追加の保護レイヤーとして扱われます。(Microsoft Learn)
特に重要なのは、暗号化されたラベルをAIアプリで扱うには、VIEWだけでなくEXTRACTの使用権限も必要になる点です。Agent 365固有の情報として、エージェントインスタンスがファイルへアクセスするにはファイルを明示的に共有する必要があり、暗号化ラベルではエージェントインスタンスにVIEWとEXTRACTの使用権限を明示的に付与する必要があります。(Microsoft Learn)
また、Agent 365から新しく作成されたコンテンツは、ソース項目から秘密度ラベルを継承しません。そのため、エージェントが機密情報を参照して生成した新規ファイルや出力物については、自動ラベル付け、保存先の制御、DLP、レビュー運用を組み合わせて設計する必要があります。(Microsoft Learn)
ラベル設計で見直すべき項目
| 見直し項目 | 確認内容 |
|---|---|
| SharePointとOneDriveの秘密度ラベル | Officeファイルのラベル処理が有効になっているか |
| 暗号化ラベル | エージェントにVIEWとEXTRACTを明示的に付与しているか |
| 共有設定 | エージェントインスタンスに必要なファイルだけを明示的に共有しているか |
| 新規生成コンテンツ | ソースのラベルを自動継承しない前提で分類・保護できているか |
| 「組織内全員」設定 | エージェント権限として十分かを検証しているか |
eDiscoveryと保持ポリシーの考え方
AIエージェントの利用が広がると、法務・監査対応でも「プロンプトや応答を後から追えるか」が重要になります。Microsoft Purviewでは、AIアプリのユーザープロンプトと応答がユーザーのメールボックスに保存されるため、eDiscoveryでケースを作成し、検索条件としてCopilot activityを使って対象データを取得できます。検索後は、結果のエクスポートやレビューセットへの追加が可能です。(Microsoft Learn)
保持については、Data Lifecycle Managementの保持ポリシーを使って、AIアプリのプロンプトと応答を自動的に保持または削除できます。複数の保持ポリシーやeDiscoveryホールドが同じ場所に適用される場合は、保持の原則に従って競合が解決されます。(Microsoft Learn)
実務では、AIデータを「通常のチャットログ」と軽く扱わないことが大切です。顧客情報、契約情報、ソースコード、設計資料、人事情報などがプロンプトに含まれる場合、監査・訴訟・規制対応の対象になり得ます。
Microsoft Foundry連携で変わるポイント
2026年6月25日に更新されたMicrosoft Agent 365とFoundryの統合ページでは、Agent 365がAIエージェントのエンタープライズコントロールプレーンであり、FoundryエージェントをAgent 365と統合することで、一貫したID、セキュリティ、ライフサイクル管理ポリシーを適用できると説明されています。(Microsoft Learn)
FoundryとAgent 365の接続方法は、大きく2つあります。1つは、公開されたFoundryエージェントをAgent 365レジストリに自動的に表示する「自動レジストリ同期」です。もう1つは、Foundry HostedエージェントをAutopilotとしてAgent 365に公開する方法です。Autopilotとして公開されたエージェントは、独自のMicrosoft EntraエージェントIDを受け取り、管理者承認後にAgent 365レジストリへ表示されます。(Microsoft Learn)
| Foundry連携の項目 | 管理者が確認すること |
|---|---|
| 自動レジストリ同期 | 公開済みFoundryエージェントがAgent 365側に表示されるか |
| Autopilot公開 | 管理者承認フロー、所有者、利用チャネルを確認する |
| プロンプトエージェント | レジストリ同期、Autopilot公開、アクティビティデータ収集の対象になるか |
| ホスト型エージェント | A365 SDK構成や追加権限が必要か |
| データ収集 | テナントのライセンス、同意、リソース単位のログ設定を確認する |
データ収集とグローバル運用の注意点
FoundryがエージェントアクティビティデータをAgent 365に送信するには、組織側でライセンス条件を満たし、Agent 365の有効化と同意を完了する必要があります。FoundryリソースのAzure Resource ManagerプロパティがA365向けに有効でも、これらの条件が満たされるまでデータは取り込まれません。(Microsoft Learn)
Foundryリソースのデータ収集は、a365LoggingEnabledとa365Statusというプロパティで管理されます。Agent 365がEntraテナントで有効な場合、同じAzureテナント内のFoundryリソースでは既定でa365LoggingEnabledがtrueになり、データ収集を止めたい場合はリソース単位で明示的にオプトアウトする必要があります。(Microsoft Learn)
グローバル企業では、データ所在地も重要です。公式情報では、Microsoft Foundryのデータ所在地はFoundryリソース作成時に選択したAzureリージョンに従い、Agent 365のデータ所在地はMicrosoft Entraテナントのストレージ場所に従うと説明されています。つまり、FoundryからAgent 365へアクティビティデータが流れると、Azureリージョンベースの常駐モデルからEntraテナント常駐モデルへ移動する可能性があります。(Microsoft Learn)
グローバル環境での確認リスト
| 確認項目 | 理由 |
|---|---|
| Foundryリソースのリージョン | エージェントデータやログの保存先に影響する |
| Entraテナントの所在地 | Agent 365側のインベントリ、分析、ガバナンスデータの保存先に影響する |
| データ収集のオプトアウト要件 | 特定リージョンの規制要件に対応するため |
| Azure Policyの利用 | サブスクリプションや管理グループ単位で設定を統制するため |
| プロジェクト単位の例外可否 | a365LoggingEnabledはFoundryリソースレベルで適用され、プロジェクト単位・エージェント単位の上書きはないため |
移行期限はあるのか
Microsoft PurviewのAgent 365管理ページには、特定日までに設定変更や移行を完了しなければならないという移行期限は示されていません。したがって、今回の情報は「期限付きの強制移行」ではなく、「Agent 365を使う組織が早めに統制設計を見直すべき更新」と捉えるのが現実的です。(Microsoft Learn)
ただし、Microsoft Agent 365は2026年5月1日時点で商用セグメント向けに一般提供されており、利用には少なくとも1人のユーザーにMicrosoft Agent 365ライセンスを付与する必要があると説明されています。導入を検討中の組織では、ライセンス、管理権限、エージェントID、Purviewポリシーの整備を並行して進める必要があります。(Microsoft Learn)
既存のカスタムエージェントで標準のMicrosoft Entraアプリ登録やサービスプリンシパルを使っている場合は、Microsoft Entra Agent IDへの移行も別途検討対象になります。公式の移行ガイドでは、既存のアプリ登録やサービスプリンシパルをそのままAgent IDへ変換するインプレース変換はなく、新しいAgent IDを作成してアプリケーションコードを更新し、旧IDを段階的に廃止する流れが示されています。(Microsoft Learn)
管理者向けの現実的な移行・確認スケジュール
| フェーズ | 作業内容 | 目安 |
|---|---|---|
| 棚卸し | Agent 365、Foundry、Copilot Studio、独自エージェントを一覧化 | まず着手 |
| 分類 | 本番利用、検証利用、所有者不明、不要エージェントに分ける | 早期に実施 |
| Purview設定 | DLP、監査、ラベル、保持、eDiscovery対象を確認 | 棚卸し後すぐ |
| ID移行検討 | 既存アプリ登録・サービスプリンシパルのAgent ID移行要否を判断 | カスタムエージェントがある場合 |
| 検証 | 監査ログ、DLP動作、ラベル権限、eDiscovery検索をテスト | 本番適用前 |
| 運用化 | 所有者レビュー、定期監査、例外承認フローを整備 | 継続運用 |
実務で優先すべき設定変更
Agent 365対応で最初から完璧な統制を作る必要はありません。重要なのは、リスクの高いエージェントから順に、見える化、保護、監査、保持の順で整備することです。
まず行うべき作業
- Microsoft PurviewポータルでDSPM > AI observabilityを開く
- 過去30日間に活動したエージェントを確認する
- 所有者不明または高リスクのエージェントを優先的に確認する
- DLPポリシーにエージェントインスタンスまたは専用セキュリティグループを追加する
- SharePointとOneDriveの秘密度ラベル設定を確認する
- 暗号化ラベルにVIEWとEXTRACT権限が必要なケースを確認する
- eDiscoveryと保持ポリシーでAI対話データを扱えるか確認する
- Foundry利用環境では
a365LoggingEnabledとデータ所在地を確認する
優先順位を付ける判断基準
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | 顧客情報、財務情報、人事情報、契約情報を扱うエージェント | 漏えい・監査・法務リスクが高い |
| 高 | 外部共有可能なSharePointやOneDriveにアクセスするエージェント | 過剰共有の影響が大きい |
| 高 | 所有者不明のエージェント | 障害・漏えい時の責任者が不明になる |
| 中 | 社内FAQやナレッジ検索エージェント | データ範囲次第でリスクが変わる |
| 低 | 検証環境で限定データだけを扱うエージェント | 本番データに触れない場合は優先度を下げられる |
よくある誤解と注意点
「既存のユーザー向けDLPがあるから十分」は危険
Agent 365では、エージェントインスタンスをDLPポリシーに含める設計が必要です。既存のユーザー向けDLPだけを見て「AIエージェントも保護済み」と判断すると、対象漏れが起きる可能性があります。
「暗号化していればAIでも安全」とは限らない
Agent 365固有の対応表では、秘密度ラベルなしの暗号化はサポート対象外です。暗号化の有無だけでなく、秘密度ラベル、使用権限、SharePointとOneDriveでのラベル処理を確認する必要があります。(Microsoft Learn)
「エージェントの出力物も元ファイルのラベルを引き継ぐ」は誤り
Agent 365から新しく作成されたコンテンツは、ソース項目から秘密度ラベルを継承しません。重要データをもとに生成されるレポート、メール案、要約ファイルなどは、別途ラベル付けやDLPで保護する必要があります。(Microsoft Learn)
「classic版のDSPMで確認できる」は誤り
Agent 365の確認では、現在のDSPMのAI observabilityを使います。classic版のDSPMはAgent 365をサポートしないため、運用手順書や社内教育資料が古い画面を前提にしていないか見直しましょう。(Microsoft Learn)
「Foundryリソース側で有効なら必ずデータが流れる」は誤り
FoundryからAgent 365へデータを送るには、Agent 365ライセンスとテナントレベルの同意が必要です。a365LoggingEnabledがtrueでも、ライセンスと同意がなければデータ収集は始まりません。(Microsoft Learn)
まとめ：Agent 365時代のPurview管理は「人とエージェントの両方」を見る
Microsoft PurviewによるAgent 365管理では、AIエージェントを単なるアプリや自動化ツールとして扱うのではなく、データにアクセスし、判断し、出力する主体として管理する必要があります。
最初に行うべきことは、DSPMのAI observabilityでエージェントを棚卸しし、リスクの高いものからDLP、秘密度ラベル、監査、eDiscovery、保持ポリシーの対象に入れることです。Foundryを使っている場合は、Agent 365へのデータ収集、オプトアウト、データ所在地も確認しましょう。
移行期限が明記された強制対応ではありませんが、Agent 365の本格利用が進むほど、後からの棚卸しやポリシー修正は難しくなります。まずは「どのエージェントが、どのデータにアクセスし、誰が責任を持つのか」を可視化し、Microsoft Purviewの既存ポリシーにエージェントを組み込むところから始めるのが現実的です。
コメント