Microsoft Purview の「Use Microsoft Purview SDK with Agent Framework」は、AI エージェントのプロンプトや応答に Microsoft Purview のデータ保護・DLP・監査・ガバナンスを組み込むための開発者向け更新です。結論から言うと、Microsoft 365 のユーザー画面が自動的に変わる機能ではなく、Agent Framework で作るカスタム AI エージェントに Purview ポリシー ミドルウェアを追加し、組織のポリシーに沿って入出力を評価できるようにする仕組みです。既存のエージェントが自動で保護されるわけではないため、管理者は Entra アプリ登録、Microsoft Graph 権限、Purview / DSPM for AI のポリシー、DLP テスト、監査ログの確認までをセットで見直す必要があります。(Microsoft Learn)
Microsoft Purview の新機能・変更点：「Use Microsoft Purview SDK with Agent Framework」で確認すべきポイント
今回の更新で押さえるべき本質は、AI エージェントの「実行時」に Purview の保護を差し込めるようになる点です。
従来の業務アプリでは、SharePoint、Exchange、OneDrive、Teams などの保存場所に対してラベル、DLP、監査、保持などを設計することが中心でした。しかし AI エージェントは、ユーザーのプロンプトを受け取り、社内データを参照し、応答を生成し、場合によっては別のエージェントや外部ツールに処理を渡します。つまり、保護すべきポイントが「ファイルの保存場所」だけでなく、「プロンプト」「応答」「エージェント間通信」「生成された出力」に広がります。
Microsoft Learn の説明では、Agent Framework SDK のワークフロー ミドルウェア パイプラインに Microsoft Purview ポリシー ミドルウェアを追加し、プロンプトと応答をインターセプトして、Purview で設定されたポリシーを満たしているかを判定できるとされています。対象は、エンドユーザーのチャット クライアントとのやり取りだけでなく、エージェント間のプロンプトと応答も含まれます。(Microsoft Learn)
何ができるようになるのか
実務上の価値は、次の3つに分けると理解しやすくなります。
| 観点 | できること | 実務での意味 |
|---|---|---|
| DLP | 機密情報を含むプロンプトや応答を、Purview の DLP ポリシーに基づいて評価・ブロックする | 顧客情報、契約条件、個人情報、機密コードなどが AI 応答に混入するリスクを下げる |
| 監査・可視化 | AI のやり取りを Purview 側に記録し、Audit、Communication Compliance、Insider Risk Management、eDiscovery、Data Lifecycle Management などの用途に活用する | 「誰が、どのアプリで、どのような AI 対話をしたか」を調査・証跡管理しやすくする |
| 導入審査 | カスタム AI エージェントにセキュリティとコンプライアンスの制御を組み込む | 社内のセキュリティレビューや法務・監査部門の承認を通しやすくする |
Microsoft Purview API の概要でも、アプリケーションが Microsoft Graph 経由で保護スコープを計算し、コンテンツをポリシー評価に送信し、返されたアクションをもとに許可・ブロックなどを判断する流れが説明されています。つまり、単なるログ転送ではなく、アプリやエージェントが実行時にポリシーを尊重するための設計が求められます。(Microsoft Learn)
影響範囲：対象は「AI エージェントを作る組織」
この更新の影響を受けるのは、Microsoft Purview を利用しているすべてのユーザーではありません。主な対象は、Microsoft Agent Framework を使って AI エージェントを開発している、または今後開発する組織です。
特に確認が必要なのは、次の担当者です。
| 担当 | 確認すべきこと |
|---|---|
| Microsoft 365 / Purview 管理者 | Purview、DLP、Audit、DSPM for AI、Communication Compliance、Insider Risk Management の設定状況 |
| Entra 管理者 | エージェント用アプリ登録、サービス プリンシパル、Graph 権限、認証方式 |
| 開発者 | Agent Framework SDK への Purview ミドルウェア追加、プロンプト・応答・ファイル処理の評価ポイント |
| セキュリティ担当 | DLP ポリシー、機密情報の検出、ブロック時のユーザー体験、インシデント対応 |
| 法務・監査担当 | AI 対話ログ、eDiscovery、保持、調査時の証跡要件 |
一方で、Microsoft 365 の標準アプリ利用者に対して、画面や操作がただちに変わるタイプの更新ではありません。重要なのは、カスタム AI エージェントを作る場合に、Purview SDK / Purview ミドルウェアを実装しなければ保護が自動的には入り込まないことです。
対象になりやすい利用シーン
たとえば、次のようなエージェントは優先的に確認すべきです。
| 利用シーン | 想定リスク | Purview 連携で見たいポイント |
|---|---|---|
| 営業提案エージェント | 別顧客の契約条件や割引率を応答に含める | 応答生成時の DLP、監査、機密情報検出 |
| 人事問い合わせエージェント | 人事評価、給与、個人情報を扱う | プロンプトと応答の記録、危険な利用の検出 |
| 社内ナレッジ検索エージェント | 権限外の文書内容を要約してしまう | ラベル、権限、検索結果のフィルタリング設計 |
| 開発支援エージェント | ソースコード、秘密鍵、接続文字列を送信する | 入力プロンプトの DLP、ブロック時の処理 |
| エージェント連携ワークフロー | 1つ目のエージェントが検出した機密情報を別エージェントへ渡す | エージェント間通信前のブロック判定 |
Microsoft Learn では、AI アプリの実行時データのガバナンスは Microsoft Foundry、Agent Framework、Microsoft Purview API のいずれでも対応可能とされています。一方で、データ漏えいやインサイダーリスク対策は Agent Framework または Purview API、過剰共有の防止は Purview API または Azure AI Search 側の設計が必要とされています。Agent Framework 連携だけで、すべての過剰共有対策が完結するわけではない点に注意が必要です。(Microsoft Learn)
前提条件：ライセンス、Azure、SDK、Entra 登録を先に確認する
公式ドキュメントでは、開始前の前提条件として、Microsoft Purview が構成された Azure サブスクリプション、E5 ライセンスと従量課金制セットアップを持つ Microsoft 365 サブスクリプション、Agent Framework SDK が挙げられています。Agent Framework SDK は Python では pip install agent-framework、.NET では NuGet からインストールする流れです。(Microsoft Learn)
実務では、いきなりコードを書き始めるより、次の順序で確認した方が失敗しにくくなります。
| 確認項目 | 見るべきポイント | 不備がある場合の影響 |
|---|---|---|
| Microsoft 365 ライセンス | E5 相当の Purview 機能が利用できるか | DLP、監査、DSPM for AI などの前提が満たせない |
| Azure サブスクリプション | AI アプリや関連リソースの管理単位が明確か | 開発環境と本番環境の分離が難しくなる |
| Purview 設定 | Audit、DLP、DSPM for AI、関連ポリシーが有効か | ミドルウェアを入れても期待した評価・可視化ができない |
| Entra アプリ登録 | エージェントを表すアプリ ID があるか | Purview 側で対象アプリとして扱えない |
| Graph 権限 | 必要な権限が付与・同意されているか | API 呼び出しやポリシー評価が失敗する |
| 開発言語 | .NET / Python のどちらで Agent Framework を使うか | 実装サンプル、認証方式、運用設計が変わる |
設定変更のポイント：エージェントに Purview ミドルウェアを追加する
Agent Framework への統合は、エージェントのワークフロー ミドルウェア パイプラインに Purview ポリシー ミドルウェアを追加する形で行います。公式サンプルでは、.NET では .WithPurview(...)、Python では PurviewPolicyMiddleware を使う例が示されています。(Microsoft Learn)
.NET の考え方は、次のような形です。
AIAgent agent = new AIProjectClient(
new Uri(endpoint),
new DefaultAzureCredential())
.AsAIAgent(
model: deploymentName,
instructions: "You are a secure assistant.")
.AsBuilder()
.WithPurview(browserCredential, new PurviewSettings("My Secure Agent"))
.Build();Python では、エージェント作成時にミドルウェアとして追加します。
purview_middleware = PurviewPolicyMiddleware(
credential=InteractiveBrowserCredential(
client_id="<clientId>",
),
settings=PurviewSettings(app_name="My Secure Agent")
)
agent = Agent(
client=chat_client,
instructions="You are a secure assistant.",
middleware=[purview_middleware]
)ここで重要なのは、app_name や PurviewSettings の名前を単なる表示名として雑に扱わないことです。運用時には、Purview 側のログや Activity Explorer、監査、インシデント調査でアプリを識別する手がかりになります。開発環境では「test-agent」でも動作するかもしれませんが、本番では「部門」「用途」「環境」を判別できる命名にしておくべきです。
例：
SalesProposalAgent-Prod
HRPolicyAgent-Test
SupportKnowledgeAgent-APAC-Prod本番環境では DefaultAzureCredential の扱いに注意する
公式ドキュメントでは、DefaultAzureCredential は開発には便利だが、本番環境ではレイテンシ、意図しない資格情報探索、フォールバック機構による潜在的なセキュリティリスクを避けるため、ManagedIdentityCredential など特定の資格情報の利用を検討するよう警告されています。(Microsoft Learn)
実務では、次のように整理すると判断しやすくなります。
| 環境 | 推奨方針 |
|---|---|
| ローカル開発 | AzureCliCredential や InteractiveBrowserCredential で検証してもよい |
| 検証環境 | 本番に近い認証方式に寄せる。過剰な権限を付けない |
| 本番環境 | マネージド ID や明示的な資格情報を検討し、意図しない認証フォールバックを避ける |
| CI/CD | シークレット直書きを避け、Key Vault やワークロード ID 連携を検討する |
Entra 登録と Microsoft Graph 権限で確認すべきこと
公式ドキュメントの次のステップでは、エージェントを Microsoft Entra に登録し、サービス プリンシパルに Microsoft Graph 権限を追加することが示されています。該当ページでは、ProtectionScopes.Compute.All、ContentActivity.Write、Content.Process.All が例示されています。さらに、Purview ポリシー側では Microsoft Entra アプリ ID を使って、エージェント通信データが Purview に流れるように構成します。(Microsoft Learn)
ただし、権限は「サンプルに書かれているから全部付ける」ではなく、エージェントの処理内容に合わせて最小権限で設計する必要があります。特に本番環境では、次の観点でレビューしてください。
| 観点 | 確認内容 |
|---|---|
| アプリ登録の所有者 | 個人ではなく、運用チームや管理グループで管理されているか |
| 権限の種類 | アプリケーション権限か委任権限か。不要に広い権限を付けていないか |
| 管理者同意 | 誰が、どの根拠で同意したかを記録しているか |
| シークレット管理 | クライアントシークレットをコードや設定ファイルに埋め込んでいないか |
| 環境分離 | 開発・検証・本番で同じアプリ ID を使い回していないか |
| 削除時の手順 | エージェント廃止時にアプリ登録、権限、Purview ポリシーを棚卸しできるか |
Purview / DSPM for AI 側で必要な設定
Agent Framework にミドルウェアを入れても、Purview 側のポリシーや DSPM for AI の設定が不足していると、期待した検出・記録・ブロックができません。
Microsoft Learn の DSPM for AI 構成ドキュメントでは、生成 AI アプリからプロンプトと応答を収集し、Purview の各機能でリスク分析を有効にするために、Audit、DSPM for AI の KYD ポリシー、Communication Compliance、Insider Risk Management などの構成が必要とされています。(Microsoft Learn)
| Purview 機能 | 管理者が確認すべきこと |
|---|---|
| Microsoft Purview Audit | 監査が有効か。AI アプリの活動が調査対象に入るか |
| DSPM for AI | 「Secure interactions from enterprise apps」系のポリシーが有効か |
| Communication Compliance | AI のプロンプトや応答に含まれる不適切・未承認コンテンツを検出できるか |
| Insider Risk Management | 危険な AI 利用や機密情報の扱いをリスクシグナルとして見られるか |
| eDiscovery | 追加設定が不要な場合でも、調査時に対象データを扱えるか確認する |
| DLP | Entra 登録アプリに対する DLP ルールをどう作るか |
特に DLP は注意が必要です。Microsoft Purview API のチュートリアルでは、Entra 登録アプリに適用する DLP ポリシーを作成するには New-DlpComplianceRule PowerShell コマンドレットを使う必要があり、Microsoft Purview ポータルではこのシナリオの DLP ポリシー作成を現在サポートしていないと説明されています。(Microsoft Learn)
つまり、管理者が Purview ポータル上で通常の DLP ポリシーを作っただけでは、カスタム AI エージェントに対する期待どおりのポリシー評価にならない可能性があります。開発チームと管理チームで、「どのアプリ ID に、どの DLP ルールを、どの活動に対して適用するか」を明確にしておく必要があります。
実装時の評価フロー：prompt と response の両方を見る
Purview API の説明では、アプリケーションは主に2つの処理を行います。1つ目は、ユーザーや活動にどの保護スコープが適用されるかを確認する protectionScopes/compute。2つ目は、対象コンテンツを評価して、必要なアクションを受け取る processContent です。(Microsoft Learn)
実務上は、次のように考えると分かりやすくなります。
| 活動 | 意味 | 例 |
|---|---|---|
uploadText | ユーザーがアプリに送るテキスト | AI へのプロンプト、チャット入力、フォーム入力 |
downloadText | アプリがユーザーに返すテキスト | AI の応答、生成された文書本文 |
uploadFile | ユーザーがアプリに渡すファイル | プロンプトに添付した PDF、Excel、Word |
downloadFile | アプリがユーザーに返すファイル | AI が生成したレポート、エクスポートファイル |
よくある失敗は、入力プロンプトだけをチェックして、AI の応答を評価しないことです。たとえば、ユーザーの入力には機密情報が含まれていなくても、エージェントが社内文書を参照して、応答に未公開価格や個人情報を含めてしまう可能性があります。uploadText と downloadText の両方を設計に入れることが重要です。
inline と offline の違いを理解する
Purview API のチュートリアルでは、保護スコープの executionMode として evaluateInline と evaluateOffline が説明されています。evaluateInline の場合は processContent の結果が返るまでメイン処理をブロックし、evaluateOffline の場合は非同期評価が可能です。(Microsoft Learn)
| モード | 実装上の意味 | 向いている処理 |
|---|---|---|
evaluateInline | 評価結果が返るまで処理を止める | 機密情報を含む可能性が高いプロンプト、外部送信前の応答 |
evaluateOffline | 非同期で評価する | 監査・分析目的の記録、ブロックより可視化を重視する処理 |
| 評価不要 | ポリシー対象外 | ただし監査目的で Content activity を記録する設計も検討する |
エージェント連携では、restrictAccess によるブロック判定が出た場合、別のエージェントを呼び出す前に止める必要があります。公式ドキュメントでも、エージェントを構築している場合、restrictAccess のアクションが設定されたら別のエージェントを呼び出す前にブロックする必要があると説明されています。(Microsoft Learn)
移行期限：強制移行ではなく「実装期限」を社内で決める更新
この更新は、既存機能の廃止や強制移行を伴うタイプの変更ではありません。Microsoft Learn の範囲では、「いつまでに既存エージェントを移行しなければならない」という期限は示されていません。
ただし、AI エージェントを本番運用する組織にとっては、事実上の準備期限を自社で決めるべきです。Microsoft 365 Roadmap は商用機能の見込み時期と説明を提供するものですが、Microsoft はロードマップ情報が変更される可能性があることを明示しています。したがって、公開情報だけで固定日を前提にせず、対象テナントの Message Center、Roadmap、Microsoft Learn を本番導入前に再確認してください。(Microsoft)
おすすめの社内スケジュールは次の通りです。
| タイミング | 実施すべきこと |
|---|---|
| 企画段階 | どのエージェントが機密データを扱うか棚卸しする |
| PoC 前 | Entra アプリ登録、権限、Purview ポリシー、テストデータを用意する |
| PoC 中 | プロンプト、応答、ファイル、エージェント間通信のブロック動作を検証する |
| 本番前 | 監査ログ、Activity Explorer、アラート運用、例外処理を確認する |
| 本番後 | ポリシー変更時の再評価、SDK 更新、権限棚卸しを定期運用に入れる |
「移行期限がないから後回し」ではなく、「本番投入するエージェントには Purview 連携の有無を審査項目に入れる」と考えるのが現実的です。
管理者が確認すべきチェックリスト
本番導入前に、少なくとも次のチェックを行ってください。
| チェック項目 | 確認内容 | 重要度 |
|---|---|---|
| 対象エージェントの棚卸し | Agent Framework を使う予定のエージェントを一覧化したか | 高 |
| データ分類 | 扱うデータに個人情報、財務情報、契約情報、営業秘密が含まれるか | 高 |
| Entra アプリ登録 | エージェントごと、または用途ごとに識別可能なアプリ登録があるか | 高 |
| Graph 権限 | 必要な Purview 関連権限が最小権限で付与されているか | 高 |
| Purview ポリシー | DLP、KYD、Audit、Communication Compliance、Insider Risk が要件に合っているか | 高 |
| ミドルウェア実装 | prompt と response の両方を評価できる設計か | 高 |
| ブロック時の UX | ユーザーに何を表示し、ログに何を残すか決めているか | 中 |
| エージェント間通信 | 別エージェントへ渡す前に評価・ブロックできるか | 高 |
| テストデータ | 実データではなく、安全な疑似データで DLP を検証しているか | 中 |
| 監査運用 | 誰が Purview の検出結果を確認し、どの手順で対応するか | 高 |
| SDK 更新管理 | Agent Framework SDK / Purview 関連パッケージの更新確認手順があるか | 中 |
失敗しやすいポイント
Purview ポリシーを作っただけで保護されると思い込む
この更新は、エージェント側の実装が必要です。Purview の管理画面でポリシーを作るだけでは、Agent Framework で作ったカスタムエージェントの実行時に自動で評価されるとは限りません。エージェントに Purview ミドルウェアを追加し、Entra アプリ ID と Purview ポリシーを紐づけ、テストで実際にブロックや記録が行われることを確認する必要があります。(Microsoft Learn)
プロンプトだけを評価して応答を見ない
AI エージェントのリスクは、ユーザーが入力した内容だけではありません。エージェントが検索・取得・推論した結果、応答に機密情報を含めることがあります。特に RAG 構成や社内ナレッジ検索エージェントでは、downloadText の評価を軽視しないでください。
DLP テストをポータルだけで完結させる
Entra 登録アプリ向けの DLP では、PowerShell コマンドレットが必要になる場面があります。テスト時に protectionScopes/compute が期待どおりの結果を返さない場合は、DLP ポリシーが対象アプリに正しく適用されているか、DSPM の Collection policies に表示され有効化されているかを確認してください。(Microsoft Learn)
ポリシー変更を反映しない
Purview API の説明では、protectionScopes/compute の呼び出しで返る ETag をキャッシュし、processContent 呼び出し時に利用する設計が示されています。また、最後の processContent から60分経過した場合は、ポリシー変更の有無を検出するために再度 protectionScopes/compute を呼び出すことが推奨されています。(Microsoft Learn)
つまり、初回ログイン時に一度だけポリシーを読んで終わり、という実装は避けるべきです。DLP やリスクポリシーは管理者が変更する可能性があるため、エージェントはポリシー変更を前提にした設計にする必要があります。
実務での導入手順
導入は、開発チームだけで進めるより、Purview 管理者、Entra 管理者、セキュリティ担当を巻き込んで進める方が安全です。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | 対象エージェントを棚卸しする | エージェント一覧、データフロー図 |
| 2 | 扱うデータを分類する | 機密情報、個人情報、契約情報などの分類表 |
| 3 | Entra アプリを登録する | アプリ ID、サービス プリンシパル、権限一覧 |
| 4 | Purview / DSPM for AI を構成する | Audit、KYD、DLP、Communication Compliance、IRM の設定 |
| 5 | Agent Framework に Purview ミドルウェアを追加する | .NET / Python の実装コード |
| 6 | テストケースを作る | 許可、検出、ブロック、ポリシー変更、エージェント間通信のテスト |
| 7 | 監査・運用を設計する | アラート対応手順、ログ確認手順、例外承認フロー |
| 8 | 本番リリース後に棚卸しを継続する | SDK 更新、権限レビュー、ポリシー見直し |
テストでは、実際の顧客情報や社員情報を使わず、クレジットカード番号形式、ダミーの個人番号、架空の契約条件など、安全な疑似データで検証してください。DLP が「検出できるか」だけでなく、「検出した後にエージェントが止まるか」「ユーザーに過剰な情報を返さないか」「監査に必要な情報が残るか」を確認することが重要です。
どの方式を選ぶべきか
Microsoft Purview と AI アプリの統合には、Agent Framework、Microsoft Purview API、Microsoft Foundry のネイティブ統合など複数の選択肢があります。用途に応じて選び分ける必要があります。(Microsoft Learn)
| 目的 | 向いている方式 | 判断基準 |
|---|---|---|
| Agent Framework で作るエージェントに DLP と監査を組み込みたい | Agent Framework + Purview SDK | まず検討すべき標準的な選択肢 |
| 独自フレームワークや既存業務アプリにも同じ制御を入れたい | Microsoft Purview APIs | API 呼び出しを自前で制御したい場合 |
| Microsoft Foundry 上の Azure AI アプリの監査・ガバナンスを有効化したい | Foundry の Purview ネイティブ統合 | 開発者のコード変更を最小化したい場合 |
| ラベルや権限を尊重して検索結果の過剰共有を防ぎたい | Purview API または Azure AI Search 連携 | RAG やナレッジ検索で特に重要 |
Agent Framework 連携は強力ですが、万能ではありません。特に「ユーザーが本来閲覧できない文書を AI が要約してしまう」タイプの過剰共有は、検索インデックス、秘密度ラベル、アクセス制御、RAG のフィルタリング設計まで含めて考える必要があります。
まとめ：管理者は「エージェントの実行時ガバナンス」を設計に入れる
「Use Microsoft Purview SDK with Agent Framework」は、Microsoft Purview を AI エージェントの実行時に近づける重要な更新です。ポイントは、Purview のポリシーを作るだけではなく、Agent Framework 側にミドルウェアを実装し、Entra アプリ登録、Graph 権限、DSPM for AI、DLP、監査、テストを一体で設計することです。
次に取るべき行動は明確です。まず、組織内で開発中または計画中の AI エージェントを棚卸しし、機密データを扱うものから優先順位を付けてください。そのうえで、Purview 管理者と開発チームが一緒に、プロンプト、応答、ファイル、エージェント間通信のどこで評価・ブロック・記録するかを決めることが重要です。AI エージェントを本番導入するなら、Purview 連携は後付けのセキュリティ対策ではなく、設計段階から入れるべき必須項目です。
コメント