Microsoft Purviewの今回のポイントは、AIアプリやAIエージェントのセキュリティを「公開後に監査で見つける」ものではなく、開発段階から組み込む設計に寄せることです。特に、プロンプト、応答、ファイル、ツール呼び出しなどをMicrosoft PurviewのDLP、監査、コンプライアンス、インサイダーリスク管理の対象にできるため、管理者と開発者が同じポリシーを前提にAIアプリを展開しやすくなります。
結論として、管理者は PurviewのDLP・感度ラベル・監査・DSPMの設定状況 を確認し、開発者は Microsoft Graph API、Agent Framework、Microsoft Foundry、Purview SDKのどれで制御を組み込むか を早めに決める必要があります。特に本番展開前に、ユーザーコンテキスト、プロンプト評価、ブロック時の画面表示、ログ保存、ライセンス、プレビュー機能の扱いを確認しておくことが重要です。
Microsoft Purviewのセキュリティ更新で何が変わるのか
今回のMicrosoft Purview関連の公式情報で重要なのは、AIアプリやエージェントに対して、データ保護・監査・コンプライアンス制御を開発プロセスへ直接組み込む方向性が明確になった点です。Microsoftの公式コミュニティブログでは、開発者がエンタープライズデータに深く接続されたAIアプリやエージェントを構築する一方で、従来型のセキュリティだけでは自律的なデータ移動やローカル環境での動作を十分に扱いにくいことが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
これまでのAIセキュリティ対策は、アプリが動き始めた後にログを確認したり、利用ルールを周知したりする運用に偏りがちでした。今回の更新で注目すべきなのは、アプリがプロンプトや応答を処理する前後に、Microsoft Purviewのポリシー評価を挟み込む設計パターンが示されていることです。
たとえば、ユーザーがAIアプリに顧客情報やクレジットカード番号を含むプロンプトを入力した場合、アプリ側でPurviewのポリシーに照会し、必要に応じてブロック、記録、監査、後続調査につなげる構成を取れます。Microsoft Learnでも、PurviewのAPIとサービスにより、Microsoft Foundryやその他のAIプラットフォームで構築したカスタムAIアプリやエージェントに、エンタープライズ向けのデータセキュリティとガバナンス制御を統合できると説明されています。(Microsoft Learn)
変更点の中心は「ガバナンス済みAIアプリ」の標準パターン
今回のMicrosoft Purviewのセキュリティ更新は、単一機能の追加というより、AIアプリを安全に作るための標準的な構成パターンを示したものと見るべきです。
Microsoft Learnでは、AIアプリに対してPurviewを組み込む主なシナリオとして、実行時データのガバナンス、データ漏えい・内部リスク対策、過剰共有の防止が整理されています。既存のLearn上の整理では、実行時データのガバナンスはMicrosoft Foundry、Agent Framework、Purview APIのいずれでも対応可能とされ、データ漏えい・内部リスク対策はAgent FrameworkまたはPurview API、過剰共有防止はPurview APIを使う形で示されています。(Microsoft Learn)
| 実装パターン | 向いているケース | 主な確認ポイント |
|---|---|---|
| Microsoft Foundryのネイティブ統合 | Microsoft Foundry上のAIアプリを管理者主導でまとめて可視化したい場合 | Azureサブスクリプション単位の設定、Purviewライセンス、ユーザーコンテキスト |
| Agent Framework連携 | エージェントのプロンプト・応答をミドルウェアで制御したい場合 | Purview policy middleware、Graph権限、DLPポリシー |
| Microsoft GraphのPurview API | 独自AIアプリや既存業務アプリへ細かく組み込みたい場合 | protectionScopes/compute、processContent、ETag、ブロック時の実装 |
| Purview SDK for .NET | API連携の実装負荷を下げたい場合 | プレビュー提供状況、認証、リトライ、キャッシュ、テレメトリ |
| GitHub Copilot・ローカルエージェント連携 | 開発者が使うAIコーディング支援やローカルエージェントを監査したい場合 | 対応範囲、Entra SSO、プレビュー機能、監査ログ連携 |
実務上の意味は明確です。AIアプリを作るチームは、セキュリティ部門から後で指摘されるのを待つのではなく、最初から「この入力は評価する」「この出力は非同期で監査する」「このデータはラベルや権限で返さない」といった判断を設計に入れる必要があります。
影響範囲は管理者・開発者・セキュリティ担当の全員に及ぶ
今回のMicrosoft Purviewの更新は、Purview管理者だけの話ではありません。AIアプリの開発、Azureサブスクリプション管理、Microsoft 365のコンプライアンス運用、GitHub Copilotの利用管理、ローカルエージェントの統制まで関係します。
| 対象者 | 影響する作業 | すぐ確認すべきこと |
|---|---|---|
| Microsoft 365 / Purview管理者 | DLP、感度ラベル、監査、保持、eDiscovery、通信コンプライアンスの整備 | AIアプリ向けのポリシーが既存ポリシーと矛盾していないか |
| Azure管理者 | FoundryやDefender for Cloud側の設定 | 対象サブスクリプションでAI servicesとPurview連携をどう有効化するか |
| Entra管理者 | アプリ登録、サービスプリンシパル、Graph権限 | 最小権限でPurview APIを呼べる構成になっているか |
| AIアプリ開発者 | プロンプト・応答・ファイル処理時のポリシー評価 | API呼び出し、ETagキャッシュ、ブロック時UXを実装しているか |
| セキュリティ運用担当 | アラート、監査ログ、DSPM、Insider Risk Managementの確認 | AIアプリの操作が調査可能な形で記録されているか |
| 利用部門 | AIアプリの利用ルール変更 | ブロックや警告が出た場合の問い合わせ先と代替手順 |
特に注意したいのは、AIアプリの種類によって必要な設定が変わる点です。Microsoft 365 Copilot、Microsoft Foundry上のアプリ、Entra登録済みのカスタムAIアプリ、GitHub Copilot、ローカルエージェントでは、同じ「AI利用」でも統制ポイントが異なります。Microsoft Learnでは、AIアプリをCopilot系、Enterprise AI apps、その他のAI appsに分類し、それぞれに対応するPurviewの保護・コンプライアンス機能を確認する構成になっています。(Microsoft Learn)
管理者が確認すべきMicrosoft Purviewの設定
Microsoft Foundry連携を使う場合はAzure側の設定を確認する
Microsoft FoundryのAIアプリを対象にする場合、Azure管理者はDefender for Cloud側のAI services設定を確認する必要があります。Microsoft Learnでは、Defender for CloudのAI services設定から「Enable data security for AI interactions」を有効にすることで、Microsoft Foundryのプロンプト、応答、関連メタデータをMicrosoft Purviewが処理・保存し、SIT分類、DSPM for AI、Insider Risk Management、Communication Compliance、Audit、Data Lifecycle Management、eDiscoveryなどに利用できると説明されています。(Microsoft Learn)
ただし、この機能にはMicrosoft Purviewライセンスが必要で、Defender for CloudのDefender for AI Servicesプランには含まれないと明記されています。導入前に、対象テナントの契約、課金、対象ユーザー、保存されるデータの範囲を必ず確認してください。(Microsoft Learn)
確認手順の実務イメージは次のとおりです。
| 手順 | 確認内容 |
|---|---|
| Azureポータルで対象サブスクリプションを確認 | AIアプリがどのサブスクリプションで稼働しているかを棚卸しする |
| Microsoft Defender for Cloudを確認 | AI servicesプランと関連設定の状態を確認する |
| Data security for AI interactionsを確認 | Purview連携を有効化する対象を決める |
| Purview側でActivity ExplorerやDSPMを確認 | プロンプト・応答のイベントが想定どおり表示されるか検証する |
| ライセンスと課金を確認 | Purview機能、E5、従量課金の要否を整理する |
なお、Microsoft Learnの該当ページでは、Foundryエージェントのデータやコンテキストは当時の説明上、統合対象に含まれない旨も記載されています。一方、公式ブログではFoundry向けのPurview DLP runtime controls for prompt processingがPublic Previewとして案内されています。つまり、Foundry関連の機能は既存のLearn記載とプレビュー発表が混在しやすいため、本番設計ではテナントで実際に利用可能か、公式ドキュメントの最新状態と管理画面の表示を確認する必要があります。(Microsoft Learn) (TECHCOMMUNITY.MICROSOFT.COM)
DLPポリシーは「AIアプリ用」に再点検する
AIアプリでは、従来のファイル共有やメール送信とは違い、ユーザーが短いプロンプトに機密情報を直接貼り付けるケースが増えます。Microsoft Purview DLPは、Microsoft 365サービスやエンドポイント上の機密情報を識別・監視・保護する機能で、ブラウザー経由で第三者の生成AIサイトへ機密情報を貼り付ける操作に対して警告やブロックを行える例も示されています。(Microsoft Learn)
管理者は、既存のDLPポリシーをそのままAIアプリに流用するのではなく、少なくとも次の観点で見直すべきです。
| 見直し項目 | 判断基準 |
|---|---|
| 機密情報の種類 | 個人番号、クレジットカード、顧客ID、契約情報、ソースコード、APIキーなど、AI入力で漏れやすい情報を含める |
| 条件 | 感度ラベルだけでなく、Sensitive Information Typesやカスタム分類も使う |
| アクション | 監査のみ、警告、ユーザーによる上書き許可、完全ブロックを使い分ける |
| 対象 | Copilot、Foundry、Entra登録アプリ、ブラウザーAI、GitHub Copilotなどを分けて考える |
| 例外 | 開発・検証環境、セキュリティチーム、特定業務フローの例外を最小限にする |
特にカスタムAIアプリやEntra登録済みアプリでは、ポリシー作成方法に注意が必要です。Microsoft Learnでは、Entra登録アプリに適用するDLPポリシーを作成するには New-DlpComplianceRule PowerShellコマンドレットを使う必要があり、Microsoft PurviewポータルではこのシナリオのDLPポリシー作成を現時点でサポートしていないと説明されています。(Microsoft Learn)
感度ラベルとSharePoint / OneDrive設定を確認する
AIアプリの過剰共有を防ぐうえで、感度ラベルは重要です。Microsoft Learnでは、AIアプリがユーザーにデータを返す際、ユーザーがそのデータへアクセス権を持たない場合は返されないこと、感度ラベルで暗号化されている場合はVIEWに加えてEXTRACT使用権が必要になることが説明されています。(Microsoft Learn)
ここで見落としやすいのが、SharePointとOneDriveで感度ラベルが有効になっているかどうかです。Microsoft Learnでは、SharePointとOneDriveで感度ラベルを有効化しておくことが推奨されており、有効化されていない場合、Copilotやエージェントがアクセスできる暗号化ファイルはWindows上のOfficeアプリで開かれている「使用中のデータ」に限定されると説明されています。(Microsoft Learn)
管理者が確認すべき点は次のとおりです。
- SharePointとOneDriveでOfficeファイルの感度ラベルが有効か
- ラベルの暗号化設定と使用権がAIアプリの利用要件に合っているか
- 「機密」「社外秘」「顧客情報」などのラベルが実際にファイルへ適用されているか
- ラベル未適用の古いファイルや共有リンクが放置されていないか
- AIアプリが検索・要約・生成に使うデータソースがラベル運用の対象に入っているか
感度ラベルが整っていない状態でAIアプリだけを先に展開すると、「AIが悪い」のではなく「元データの分類が不十分」という問題が表面化します。AIアプリ導入前に、重要なSharePointサイト、OneDrive領域、Teamsファイル、業務データのラベル適用状況を確認しておくべきです。
開発者が確認すべき実装ポイント
基本は「保護範囲を計算してからコンテンツを処理する」
Microsoft GraphのPurview APIを使う場合、開発者が理解すべき基本フローは2段階です。Microsoft Learnでは、アプリがまず protectionScopes/compute を呼び出して、特定ユーザーの操作にどのポリシー評価が必要かを確認し、その後 processContent で入力や出力をポリシー評価に送る流れが説明されています。(Microsoft Learn)
| API | 役割 | 実装上の注意 |
|---|---|---|
protectionScopes/compute | ユーザーと操作に適用される保護範囲を計算する | サインイン直後など早い段階で呼び出し、対象アクティビティを判定する |
processContent | プロンプト、応答、ファイルなどをポリシー評価に送る | ブロック、監査、ポリシー変更などの応答をアプリ側で処理する |
対象アクティビティには、ユーザーがテキストを送信する uploadText、アプリがテキストを返す downloadText、ユーザーがファイルを送信する uploadFile、アプリがファイルを返す downloadFile があります。AIアプリであれば、プロンプトは uploadText、AIの回答は downloadText と考えると設計しやすくなります。(Microsoft Learn)
evaluateInline と evaluateOffline を混同しない
Purview APIを組み込む際に失敗しやすいのが、同期評価と非同期評価の使い分けです。Microsoft Learnでは、executionMode の値として evaluateInline と evaluateOffline が示されており、evaluateInline は processContent の戻りを待つためアプリのメイン処理をブロックし、evaluateOffline は非同期評価にできると説明されています。(Microsoft Learn)
実務では次のように設計すると分かりやすくなります。
| 処理 | 推奨される考え方 |
|---|---|
| ユーザーが機密情報を含むプロンプトを送る | evaluateInline で処理前にブロックできるようにする |
| AIの応答を監査目的で記録する | evaluateOffline でUXへの影響を抑える |
| ファイルアップロード | 内容やラベルによっては同期評価を検討する |
| ログ・監査目的の記録 | 非同期処理にして失敗時の再送キューを用意する |
ブロックが必要な処理を非同期にしてしまうと、モデルに機密情報が渡った後で検知することになります。逆に、すべてを同期評価にすると、応答速度が落ちて利用者の不満につながります。どの操作を「処理前に止めるべきか」をセキュリティ部門と開発チームで事前に決めておくことが重要です。
ETagをキャッシュし、ポリシー変更に追従する
Purview API連携では、ポリシー変更への追従も重要です。Microsoft Learnでは、protectionScopes/compute の呼び出しで返されるETagをキャッシュし、processContent 呼び出し時に If-None-Match ヘッダーとして送る必要があると説明されています。ポリシー状態が変わった場合は protectionScopeState が modified になり、アプリ側で保護範囲を再計算する必要があります。(Microsoft Learn) (Microsoft Learn)
これは本番運用で非常に重要です。セキュリティ管理者がDLPポリシーを変更しても、アプリが古い判定結果を持ち続けると、意図したブロックや監査が効かない可能性があります。
開発時には、次のテストを入れておくと安全です。
- DLPポリシー変更後にアプリが再計算するか
protectionScopeStateがmodifiedの場合に古い判定を使い続けないか- ETagがない場合、期限切れの場合、APIエラーの場合の挙動
- ブロック応答を受けたときに、AIモデルへ入力を渡さず停止できるか
- 監査ログ用の再送処理で重複記録が発生しないか
Agent FrameworkではミドルウェアにPurviewを組み込む
Microsoft Agent Frameworkを使う場合は、エージェントのミドルウェアパイプラインにPurview policy middlewareを追加する設計になります。Microsoft Learnでは、Agent Framework SDK内でPurview APIを統合することで、プロンプトや応答内の機密データを組織ポリシーに沿って保護し、DLPによるインラインブロック、監査、Communication Compliance、Insider Risk Management、eDiscovery、Data Lifecycle Managementへの記録に活用できると説明されています。(Microsoft Learn)
Agent Framework連携では、開発者が毎回API呼び出しを直接実装するよりも、プロンプト・応答の通過点にミドルウェアを置ける点が利点です。ただし、認証情報の扱いには注意が必要です。Microsoft Learnのコード例では、開発時に便利な DefaultAzureCredential について、本番では意図しない資格情報探索や遅延、セキュリティリスクを避けるため、ManagedIdentityCredential など特定の資格情報を検討するよう警告されています。(Microsoft Learn)
プレビュー機能は本番前に利用可否を確認する
公式ブログでは、GitHub Copilot CLI、Claude Code、OpenAI Codex、OpenClawで開発されたローカルエージェントに対し、Purviewの可視化と保護機能をPublic Previewとして拡張することが案内されています。これにより、DSPMでのエージェント可視化、DLPによるランタイム保護、Insider Risk Managementのシグナル、監査ログを組み合わせ、ローカルエージェントが機密データを扱うリスクを検知・制御する方向性が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
また、Foundry向けには、プロンプト処理時のPurview DLP runtime controlsがPublic Previewとして案内され、Foundry Control PlaneにPurviewのデータセキュリティインサイトを埋め込む機能はGeneral Availabilityとして説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
GitHub Copilotについても、GitHub Enterprise顧客がEntra SSOを利用している場合に、GitHub Copilotのやり取りに関する監査ログをPurviewへストリーミングし、AIアクティビティを一元的に分析できるPublic Previewが案内されています。(TECHCOMMUNITY.MICROSOFT.COM)
ここで大切なのは、Public Previewを「全社本番でそのまま使える機能」と誤解しないことです。プレビュー機能は、対象リージョン、対象テナント、サポート範囲、SLA、管理画面の表示、ログ形式が変わる可能性があります。
本番展開前には、次のように扱うのが現実的です。
| フェーズ | 推奨対応 |
|---|---|
| 情報収集 | 公式ブログだけでなく、Microsoft Learn、ロードマップ、管理センターの表示を確認する |
| 検証 | 開発者部門やセキュリティ部門の少人数でテストする |
| 評価 | ログの粒度、ブロック精度、誤検知、UX、課金影響を確認する |
| 展開判断 | GA機能とPreview機能を分けて運用ルールを作る |
| 本番運用 | Preview依存の制御を唯一の防御線にしない |
移行・展開で失敗しやすいポイント
「Purviewを有効化すれば全AIアプリが自動で守られる」と考えない
Microsoft Purviewは強力なデータセキュリティ基盤ですが、カスタムAIアプリではアプリ側の統合が必要です。Microsoft Learnでも、Purview APIを使うにはAzureサブスクリプション、Microsoft Purview構成、Entra IDアプリ登録、適切な権限、Microsoft Graph APIの基本知識、評価対象となるユーザー入力やアプリ出力へのアクセスが前提として示されています。(Microsoft Learn)
つまり、AIアプリのコード、認証方式、ユーザーコンテキスト、ログ設計が不十分なままでは、Purviewのポリシーを十分に活かせません。特にAPIキーだけで動くアプリや、ユーザー単位のEntra IDコンテキストを渡していないアプリでは、ユーザー別のポリシー評価や監査が弱くなります。
ユーザーコンテキストがないと制御が限定される
Foundry連携でも、ユーザーコンテキストの有無は重要です。Microsoft Learnでは、Microsoft Foundry interactions向けのData Security Policiesは、Microsoft Entra ID認証のユーザーコンテキストトークンを使うAPI呼び出し、または明示的にユーザーコンテキストを含むAPI呼び出しでのみサポートされると説明されています。それ以外の認証シナリオでは、ユーザー操作はPurview AuditとDSPM for AI Activity Explorerにのみ表示されるとされています。(Microsoft Learn)
開発者は、次の点を設計レビューに入れるべきです。
- AIアプリの利用者をEntra IDユーザーとして識別できるか
- バックエンド処理でも「誰の操作か」を保持しているか
- サービスアカウント経由で全ユーザーの操作が同一扱いになっていないか
- 監査ログにユーザー、アプリ、操作、対象データ、時刻が残るか
- ゲストユーザーや外部ユーザーをどう扱うか
ブロック時のユーザー体験を設計していない
DLPでブロックするだけでは、現場は回避策を探します。AIアプリで機密情報を含むプロンプトがブロックされた場合、ユーザーに「何が起きたか」「どう修正すればよいか」を示す必要があります。
悪い例は、単に「エラーが発生しました」と表示することです。これではユーザーは同じ入力を何度も試すか、別の未承認AIサービスへ貼り付ける可能性があります。
良い例は次のような表示です。
入力内容に社内ポリシーで保護対象となる情報が含まれているため、このAIアプリでは処理できません。顧客番号、口座番号、個人情報、認証情報などを削除またはマスキングして再実行してください。必要な場合はデータ管理者に相談してください。
このメッセージは、セキュリティを弱めず、ユーザーに次の行動を示せます。
ログ保存と保持ポリシーを後回しにする
AIアプリのプロンプトや応答は、監査、eDiscovery、Communication Compliance、Data Lifecycle Managementの対象になり得ます。Microsoft Purviewでは、対応するAIアプリのやり取りをユーザー単位で監視でき、監査、通信コンプライアンス、eDiscovery、保持・削除といったコンプライアンス管理に利用できると説明されています。(Microsoft Learn)
これは便利である一方、プロンプトや応答そのものがコンプライアンスデータになることを意味します。保存期間、調査権限、個人情報の扱い、法務対応、削除要件を事前に決めずに記録を始めると、後から運用負荷が増えます。
管理者は、少なくとも次の項目を整理してください。
- AIプロンプトと応答を何日または何年保持するか
- どの管理者ロールが閲覧・検索できるか
- eDiscovery対象になる範囲はどこまでか
- 調査時にユーザー名を匿名化または仮名化する運用が必要か
- テスト環境のプロンプトも保持対象にするか
実務での導入手順
Microsoft PurviewのAIアプリ向けセキュリティ制御は、いきなり全社展開するより、対象アプリを絞って段階的に導入する方が安全です。
| ステップ | 作業内容 | 完了の目安 |
|---|---|---|
| AIアプリを棚卸しする | Copilot、Foundry、GitHub Copilot、独自AIアプリ、ローカルエージェントを一覧化する | 利用部門、所有者、データソース、認証方式が分かる |
| データ分類を確認する | 感度ラベル、SIT、カスタム分類、SharePoint / OneDrive設定を確認する | 機密データが分類・ラベル付けされている |
| 統制レベルを決める | 監査のみ、警告、上書き許可、ブロックを使い分ける | 業務影響とリスクのバランスが取れている |
| 実装方式を選ぶ | Foundry統合、Agent Framework、Graph API、SDKを選定する | アプリごとの実装方針が決まっている |
| 検証環境でテストする | ダミーの機密データでDLP、ログ、ブロック表示を確認する | 想定どおり止まり、記録され、調査できる |
| パイロット展開する | 開発部門や特定業務部門で限定運用する | 誤検知、遅延、問い合わせ内容を把握できる |
| 本番展開と監視を行う | Activity Explorer、DSPM、Audit、アラートを定期確認する | ポリシー改善の運用サイクルが回っている |
最初に取り組むなら、機密データを扱う可能性が高く、かつ対象ユーザーを絞りやすいAIアプリから始めるのが現実的です。たとえば、社内ナレッジ検索AI、契約書要約AI、営業提案書作成AI、開発者向けコード支援AIなどは、効果とリスクの両方が見えやすい対象です。
管理者と開発者のチェックリスト
管理者向けチェックリスト
- Microsoft PurviewポータルでDLP、感度ラベル、監査、保持、eDiscoveryの設定を確認したか
- SharePointとOneDriveで感度ラベルが有効になっているか
- AIアプリ向けのDLPポリシーを既存ポリシーと分けて設計したか
- Entra登録アプリ向けDLPポリシーの作成方法を確認したか
- Foundry連携に必要なAzureサブスクリプション、Defender for Cloud、Purviewライセンスを確認したか
- Activity ExplorerやDSPMでAIアクティビティを確認できるか
- 監査ログ、保持期間、調査権限、プライバシー対応を整理したか
- Preview機能とGA機能を分けて運用ルール化したか
開発者向けチェックリスト
- AIアプリがEntra IDのユーザーコンテキストを保持しているか
protectionScopes/computeを適切なタイミングで呼び出しているかuploadText、downloadText、uploadFile、downloadFileの扱いを整理したかevaluateInlineとevaluateOfflineを用途別に使い分けているかprocessContentの応答でブロック指示が来た場合、モデル処理前に停止できるか- ETagをキャッシュし、ポリシー変更時に再計算できるか
- API失敗時の再試行、フォールバック、ログ記録を設計したか
- ブロック時のユーザーメッセージを分かりやすく設計したか
- 本番認証で
DefaultAzureCredential任せにしていないか - 実データではなくダミーデータでDLPテストを行っているか
よくある疑問と判断基準
既存のDLPポリシーだけで十分か
十分とは限りません。既存のDLPポリシーがメール送信やファイル共有を前提にしている場合、AIプロンプトへの貼り付け、AI応答の生成、エージェントによるファイル参照、ローカル端末上の操作を想定していない可能性があります。AIアプリでは「送信先」だけでなく、「モデルに処理させる前に止めるべきか」を考える必要があります。
まず何から始めるべきか
最初にやるべきことは、AIアプリの棚卸しです。どのAIアプリが、誰の権限で、どのデータにアクセスし、プロンプトや応答をどこに保存するのかが分からなければ、Purviewの設定だけ整えても十分な統制にはなりません。
棚卸し後は、機密データを扱う上位3つのAIアプリを選び、DLPと監査を検証するのが現実的です。
開発者はPurviewの専門家になる必要があるか
専門家になる必要はありませんが、最低限の設計要素は理解する必要があります。特に、ユーザーコンテキスト、同期評価、非同期評価、ブロック応答、ETag、ログ保存は、アプリの動作そのものに影響します。
Microsoft Purviewの狙いは、開発者がセキュリティポリシーをすべて手作りすることではなく、組織が定義したポリシーをアプリ側で適用しやすくすることです。公式ブログでも、Purviewにより開発者がセキュリティ専門家にならなくても、データアクセス、利用、共有を一貫してガバナンスできる方向性が説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Preview機能は使うべきか
検証には使う価値があります。ただし、本番の唯一の防御線にするのは避けるべきです。Public Previewの機能は、利用可能なテナントや仕様が変わる可能性があります。Preview機能を試す場合は、対象ユーザーを絞り、GA済みのDLP、感度ラベル、監査、アクセス制御と組み合わせて使うのが安全です。
まとめ：AIアプリ公開前にPurview前提の設計レビューを行う
今回のMicrosoft Purviewのセキュリティ更新は、AIアプリやエージェントを安全に展開するための考え方を大きく変えるものです。ポイントは、AIアプリの完成後にセキュリティを後付けするのではなく、開発段階からPurviewのDLP、監査、感度ラベル、DSPM、Insider Risk Management、Communication Complianceを前提に設計することです。
管理者は、DLPポリシー、感度ラベル、SharePoint / OneDrive設定、監査ログ、保持ポリシー、ライセンス、Preview機能の扱いを確認してください。開発者は、ユーザーコンテキスト、Purview API、Agent Framework、Microsoft Foundry、SDK連携、ブロック時UXを設計レビューに入れる必要があります。
次に取るべき行動はシンプルです。まず、自社で使っているAIアプリとエージェントを一覧化し、機密データに触れるものから優先順位を付けます。そのうえで、1つのAIアプリを選び、Purviewのポリシー評価、監査ログ、ブロック動作を検証してください。小さく始めて、ポリシーと実装パターンを標準化することが、ガバナンス済みAIアプリを安全に増やす近道です。
コメント