Microsoft Purviewの「Purview SDK embedded in Agent Framework SDK」は、AIエージェントにMicrosoft Purviewのデータ保護、コンプライアンス、ガバナンス機能を組み込みやすくする開発者向けの更新です。結論から言うと、既存のMicrosoft 365画面が急に変わる更新ではなく、自社でAIエージェントを開発・展開している組織が、Agent Framework SDKへのPurview連携、Entra IDアプリ登録、Graph権限、Purviewポリシーの設定を確認すべき変更です。
Microsoft 365 Roadmap ID 534609の公式APIでは、この項目は「Microsoft Purview: Purview SDK embedded in Agent Framework SDK」として掲載され、ステータスはIn development、対象クラウドはWorldwide Standard Multi-Tenant、プラットフォームはWeb、プレビューは2025年11月、一般提供は2026年9月予定とされています。更新日時はUTCで2026-05-29T22:30:02のため、日本時間では2026年5月30日朝に相当します。ロードマップ情報は予定であり、Microsoft自身も公開日や内容は変更される可能性があると説明しています。(Microsoft) (Microsoft)
Purview SDK embedded in Agent Framework SDKで何が変わるのか
今回のポイントは、AIエージェントの実行経路にMicrosoft Purviewの保護機能を組み込めるようになることです。
Microsoft Learnでは、Agent Framework SDK内でPurview APIを統合することで、プロンプトや応答に含まれる機密データを組織のポリシーに沿って保護し、セキュアなAIエージェントを構築できると説明されています。さらに、DLPポリシーに基づく機密コンテンツのインラインブロック、AIインタラクションのPurviewへの記録、Audit、Communication Compliance、Insider Risk Management、eDiscovery、Data Lifecycle Managementでの活用が想定されています。(Microsoft Learn)
分かりやすく言えば、これまでAIエージェント側で個別に考える必要があった「この情報を渡してよいか」「応答に機密情報が含まれていないか」「監査ログに残せるか」といった制御を、Microsoft Purviewの既存ポリシーと接続しやすくする更新です。
ただし、SDKがあるだけで自動的に全AIエージェントが保護されるわけではありません。公式ドキュメントでは、エージェントのワークフローミドルウェアパイプラインにMicrosoft Purview policy middlewareを追加し、プロンプトや応答をインターセプトしてポリシーに適合するか判定する流れが示されています。(Microsoft Learn)
影響を受ける範囲
この更新の中心は、Microsoft Purviewの管理者だけではありません。AIエージェントを作る開発者、Entra IDの管理者、セキュリティ・コンプライアンス担当者が一緒に確認すべき内容です。
| 対象 | 影響 | 最初に確認すること |
|---|---|---|
| AIエージェント開発者 | Agent Framework SDKにPurview連携を実装する必要がある | ミドルウェア追加、SDK依存関係、認証方式、例外処理 |
| Microsoft Purview管理者 | AIエージェントのプロンプト・応答をどのポリシーで制御するか決める | DLP、DSPM for AI、Audit、Communication Compliance、Insider Risk Management |
| Entra ID管理者 | エージェント用アプリ登録とGraph権限の管理が必要 | アプリ登録、管理者同意、最小権限、証明書・シークレット管理 |
| セキュリティ運用担当 | AIエージェント経由の情報漏えい検知・調査対象が増える | ログ確認、アラート設計、Activity Explorerでの追跡 |
| 一般ユーザー | 直接的な画面変更よりも、エージェント利用時のブロックや警告として影響する可能性がある | 業務フロー上、どの操作が制限されるか |
特に確認すべきなのは、社内ナレッジ検索、営業支援、問い合わせ対応、契約書レビュー、社内文書要約など、機密データを扱うAIエージェントです。これらのエージェントは、ユーザーの入力だけでなく、検索結果、外部API、ファイル、他エージェントから受け取った情報を応答に混ぜることがあります。プロンプトだけを見ていても、応答側やツール呼び出し側で情報漏えいが起きる点に注意が必要です。
管理者が確認すべき前提条件
Microsoft Learnでは、Purview SDKをAgent Frameworkで使う前提として、Microsoft Purviewが構成されたAzureサブスクリプション、E5ライセンスを含むMicrosoft 365サブスクリプション、従量課金の設定、Agent Framework SDKの導入が挙げられています。Pythonではpip install agent-framework、.NETではNuGetからのインストールが案内されています。(Microsoft Learn)
ここで重要なのは、ライセンスや課金の有無だけを見ないことです。実務では、次の3点をあわせて確認しないとPoCで止まりやすくなります。
| 確認項目 | 見落としやすいポイント |
|---|---|
| ライセンス | E5相当の機能が必要な範囲、テストテナントと本番テナントの差 |
| 課金 | 従量課金が必要な機能を使う場合の費用管理、検証時の上限設定 |
| 権限 | 開発者に過剰権限を与えず、Entra ID管理者が承認フローを持つこと |
検証環境では動いたのに本番で失敗する典型例は、開発者の個人権限では呼び出せたAPIが、本番のサービスプリンシパルでは許可されていないケースです。PoCの段階から、本番と同じ認証方式、同じ権限モデル、同じPurviewポリシーの縮小版で試す方が安全です。
Entra IDアプリ登録とGraph権限の確認
Agent Framework SDKにPurviewを組み込む場合、エージェントをEntra IDにアプリ登録し、必要なMicrosoft Graph権限をサービスプリンシパルに付与する流れになります。Microsoft Learnでは、次の権限例が示されています。
| 権限 | 用途のイメージ |
|---|---|
ProtectionScopes.Compute.All | ユーザーやアプリに適用される保護スコープの計算 |
ContentActivity.Write | コンテンツ操作のアクティビティ記録 |
Content.Process.All | コンテンツをデータ保護ポリシーに照らして処理 |
公式手順でも、エージェントをEntraに登録し、Microsoft Graph権限を追加したうえで、EntraアプリIDを使ってPurviewポリシーを構成することが次のステップとして示されています。(Microsoft Learn)
実務では、最初からAll系の権限を本番アプリに付けるのではなく、検証範囲、対象ユーザー、対象データを絞って設計してください。Graphの関連APIでは、ProtectionScopesやContent.Processに対してUser単位とAll単位の権限が示されているため、アプリの用途に対して最小権限を選ぶことが重要です。(Microsoft Learn) (Microsoft Learn)
本番展開前には、少なくとも次の管理ルールを決めておきます。
- アプリ登録の所有者を個人ではなく管理グループにする
- クライアントシークレットではなく証明書またはマネージドIDを優先する
- 管理者同意の申請理由を記録する
- 権限変更時にセキュリティレビューを通す
- エージェントごとにアプリ登録を分けるか、用途別に共通化するかを決める
特に複数のAIエージェントを同じアプリ登録で動かすと、監査や権限分離が難しくなります。営業支援エージェント、法務レビューエージェント、社内ヘルプデスクエージェントのように扱うデータが異なる場合は、アプリ登録やPurviewポリシーのスコープを分けた方が後から調査しやすくなります。
Purview側で確認すべきポリシー
Purview SDK連携は、コードだけで完結する話ではありません。Microsoft Purview側で、AIアプリのプロンプトや応答をどのように収集、検出、制御、監査するかを設定する必要があります。
Microsoft Learnでは、DSPM for AIで各Purviewソリューションの構成とポリシーを有効化する必要があると説明されています。例として、Microsoft Purview Audit、DSPM for AIの「Secure interactions from enterprise apps」、Communication Complianceの「Control Unethical Behavior in AI」、Insider Risk Managementの「Detect risky AI usage」が挙げられ、eDiscoveryについては追加手順なしとされています。(Microsoft Learn)
| Purview機能 | 確認する設定 | 実務上の判断基準 |
|---|---|---|
| Audit | 監査が有効か | 誰が、いつ、どのエージェントで、どの操作をしたか追えるか |
| DSPM for AI | KYDポリシー、AIアプリの収集設定 | プロンプト・応答を可視化する範囲を決める |
| DLP | 機密情報の検出、ブロック、監査 | クレジットカード番号、個人番号、顧客情報などの扱いを定義する |
| Communication Compliance | 不適切・リスクのあるAI利用の検出 | レビュー担当者とエスカレーション手順を決める |
| Insider Risk Management | 危険なプロンプトや応答のリスク検出 | 退職予定者、特権ユーザー、外部共有が絡むシナリオを評価する |
| eDiscovery | 調査対象として扱えるか | 法務・監査対応でAIインタラクションを検索できるか |
注意したいのは、プロンプトと応答の保存です。公式ドキュメントでは、Ingestion ONの場合はMicrosoft Purview APIsがプロンプトと応答をMicrosoft Purview AI Interactionsに保存し、Ingestion OFFの場合は保存しないと説明されています。(Microsoft Learn)
つまり、監査や調査のために保存したい組織と、機密性の高いプロンプトを保存したくない組織では、最適な設定が異なります。セキュリティ部門だけで決めず、法務、個人情報保護、労務、現場責任者を含めて、保存対象・保存期間・閲覧権限を決めてください。
開発者が実装時に確認すべきポイント
開発者側の中心作業は、Agent Framework SDKのエージェント処理にPurview middlewareを追加することです。Microsoft Learnのサンプルでは、.NETでは.WithPurview(...)、PythonではPurviewPolicyMiddlewareを使い、エージェントのミドルウェアとしてPurview連携を組み込む例が示されています。(Microsoft Learn)
実装時は、次の観点でレビューしてください。
| 実装ポイント | 確認内容 |
|---|---|
| 入力チェック | ユーザーのプロンプトをPurview評価に通しているか |
| 応答チェック | LLMの生成結果をユーザーへ返す前に評価しているか |
| ツール結果 | 検索、RAG、外部API、DBから得た情報も評価対象に含めているか |
| agent-to-agent通信 | 他エージェントから受け取る内容、他エージェントへ渡す内容も対象か |
| 例外処理 | Purview API障害時に許可するのか、ブロックするのか |
| ログ | 機密本文をアプリログにそのまま出力していないか |
| 性能 | インライン評価による遅延を許容できるか |
Microsoft Learnでは、Agent Framework SDKがエンドユーザーのチャットクライアントとagent-to-agentのプロンプト・応答をインターセプトできると説明されています。(Microsoft Learn) そのため、単体のチャット画面だけでなく、複数エージェントが連携する業務フローでも設計が必要です。
また、サンプルにはDefaultAzureCredentialが登場しますが、公式ドキュメントでは本番環境での利用には注意が必要で、意図しない資格情報探索やフォールバックのリスクを避けるため、ManagedIdentityCredentialなど特定の資格情報を検討するよう警告されています。(Microsoft Learn)
PoCではDefaultAzureCredentialが便利ですが、本番では「どのIDでPurviewを呼んでいるか」が曖昧になる構成は避けるべきです。障害調査や監査時に説明できるよう、エージェントごとの実行IDを明確にしてください。
展開前の実務チェックリスト
本番展開は、SDKを入れて終わりではありません。次の順番で進めると、管理者と開発者の認識ズレを減らせます。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 1 | AIエージェントの棚卸し | どのエージェントが誰のどのデータにアクセスするか一覧化する |
| 2 | 高リスクシナリオの選定 | 顧客情報、契約情報、人事情報、財務情報を扱うフローを優先する |
| 3 | テスト用Purviewポリシー作成 | 本番より狭いユーザー・アプリ範囲で検証できる |
| 4 | Entraアプリ登録 | アプリID、所有者、権限、同意状態が記録されている |
| 5 | SDK実装 | 入力、応答、ツール結果、agent-to-agent通信を評価できる |
| 6 | 擬似データでテスト | 実在の個人情報ではなく、テスト用の機密パターンで検証する |
| 7 | ログ・レポート確認 | DSPM for AI、Activity Explorer、監査ログで追跡できる |
| 8 | 段階展開 | 部門単位、エージェント単位、データ種類単位で広げる |
公式ドキュメントでは、ポリシー作成後、生成AIアプリのプロンプト・応答アクティビティ、機密検出、分析結果がDSPM for AIに表示されるようになると説明されています。また、レポート反映には少なくとも1日待つ必要があるとされています。(Microsoft Learn)
検証時は「ブロックされたか」だけでなく、「なぜブロックされたかを管理者が説明できるか」まで確認してください。現場から問い合わせが来たときに、ポリシー名、検出された機密情報の種類、対象ユーザー、対象エージェントを追えないと、運用負荷が一気に上がります。
移行時に失敗しやすいポイント
Purview SDK embedded in Agent Framework SDKは、AIエージェントの安全性を高める有効な仕組みですが、導入の仕方を誤ると現場の混乱につながります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| SDKを入れただけで保護されると思い込む | 実際にはミドルウェア未設定で評価されない | コードレビューでPurview middlewareの有無を確認する |
| 全社一斉に強いDLPを適用する | 正常業務までブロックされる | 最初は対象ユーザーとアプリを絞る |
| プロンプトだけ評価する | LLM応答や検索結果から漏えいする | 入力、出力、ツール結果をまとめて評価する |
| 実データでテストする | テストログに個人情報や機密情報が残る | ダミーデータ、合成データを使う |
| 開発者の個人資格情報でPoCを続ける | 本番移行時に認証・監査が破綻する | サービスプリンシパルまたはマネージドIDへ移行する |
| 保存設定を法務確認なしで有効化する | プロンプト・応答の保管が社内規程と衝突する | Ingestion ON/OFF、閲覧権限、保存期間を合意する |
| agent-to-agent通信を見落とす | エージェント間で機密情報が広がる | エージェント間メッセージも評価対象にする |
もう1つ注意したいのが、既存スクリプトや自動化の設定値です。Purviewの構成ドキュメントでは、Entra enforcement planeは非推奨で、DLPや収集ポリシーの作成・更新ではApplicationを使うよう案内されています。既存ポリシーはそのまま動作するとされていますが、カスタムスクリプトやAPI連携でEntraを渡している場合は更新が必要です。(Microsoft Learn)
管理者と開発者の役割分担
この更新は、どちらか一方のチームだけでは完結しません。管理者がポリシーを作っても、開発者がエージェントに組み込まなければ効きません。逆に、開発者がSDKを実装しても、Purview側のポリシーや監査設定が整っていなければ、期待した保護や可視化は得られません。
| 役割 | 主な責任 |
|---|---|
| Purview管理者 | DLP、DSPM for AI、Audit、Communication Compliance、Insider Riskの設定 |
| Entra ID管理者 | アプリ登録、Graph権限、管理者同意、資格情報管理 |
| 開発者 | Agent Framework SDKへのPurview連携、例外処理、ログ設計 |
| セキュリティ運用 | アラート確認、調査手順、インシデント対応 |
| 法務・コンプライアンス | プロンプト・応答の保存、調査、監査要件の確認 |
| 業務部門 | どのAIエージェントでどのデータを使うかの判断 |
おすすめは、最初に「AIエージェント審査シート」を作ることです。エージェント名、所有部門、利用者、アクセスするデータ、外部連携、Purview評価ポイント、ログ保存方針、リリース可否を1枚で確認できるようにすると、PoCから本番化するときの判断が速くなります。
よくある疑問
既存のDLPポリシーは不要になるのか
不要にはなりません。今回の更新は、AIエージェント側からMicrosoft Purviewの保護・コンプライアンス機能を使いやすくするものです。DLP、DSPM for AI、Auditなどの設計は引き続き必要です。Microsoft Learnでも、Purviewポリシーを構成してプロンプトや応答がポリシーに適合するか判断する流れが示されています。(Microsoft Learn)
すべてのAIエージェントにすぐ影響するのか
いいえ。公式ドキュメントの実装例を見る限り、エージェントのミドルウェアパイプラインにPurview連携を追加する開発作業が前提です。既存のMicrosoft 365アプリの見た目が変わる更新というより、カスタムAIエージェントを安全に展開するための開発・管理機能と捉えるべきです。(Microsoft Learn)
どの環境が対象か
Microsoft 365 Roadmapの該当項目では、対象クラウドはWorldwide Standard Multi-Tenant、プラットフォームはWeb、製品はMicrosoft Purviewとされています。政府機関向けクラウドや国別クラウドでの可用性は、該当環境の公式案内を別途確認してください。(Microsoft)
本番展開前に最低限やるべきことは何か
最低限、次の5つは確認してください。
- 自社で開発・利用しているAIエージェントの一覧化
- Purviewポリシーの対象ユーザー、対象アプリ、対象データの整理
- Entra IDアプリ登録とGraph権限のレビュー
- Agent Framework SDKへのPurview middleware実装
- テストデータを使った入力・応答・ツール結果の検証
特に、LLMの応答だけでなく、RAG検索結果や外部システムから取得したデータも確認対象に含めることが重要です。AIエージェントは「ユーザーが入力した情報」だけでなく、「エージェントが探してきた情報」からも情報漏えいを起こします。
今回の更新で最初にやるべきこと
Microsoft PurviewのPurview SDK embedded in Agent Framework SDKは、AIエージェントを本番業務に広げる組織にとって重要な更新です。特に、社内文書、顧客情報、契約情報、財務情報、人事情報を扱うAIエージェントでは、導入前にPurview連携を検討する価値があります。
最初の一歩は、SDKのコードを読むことではなく、自社のAIエージェントがどのデータを読み、誰に何を返すのかを棚卸しすることです。そのうえで、Purview管理者、Entra ID管理者、開発者、セキュリティ運用担当が同じ表を見ながら、ポリシー、権限、ログ、例外処理を決めてください。
ロードマップ上の一般提供予定は2026年9月ですが、Microsoft 365 Roadmapの予定は変更される可能性があります。管理者はロードマップID 534609とMicrosoft 365管理センターのメッセージセンターを継続的に確認し、開発チームは早めにPoC環境でPurview middleware、Graph権限、DSPM for AIの見え方を検証しておくと、本番展開時の手戻りを減らせます。(Microsoft) (Microsoft)
コメント