Microsoft PurviewとAzure AI Foundryの連携は、「Azure AI Foundryで作ったAIアプリやエージェントの利用状況を、Microsoft Purview側で監査・分類・DLP・eDiscovery・保持などの対象にしやすくする」ための更新です。結論として、管理者はすぐに対象サブスクリプション、認証方式、Purviewライセンス、従量課金、監査・保持・DLPポリシーの確認を始めるべきです。特に、Foundry側で有効化するとサブスクリプション単位で影響が広がるため、「とりあえずオンにする」よりも、対象アプリと取得されるAI interaction dataの扱いを先に整理することが重要です。Microsoft 365ロードマップでは、この項目はRoadmap ID 537271として公開され、プレビューは2025年12月、一般提供は2026年5月、状態はRolling outと示されています。(Microsoft)
Microsoft Purviewのセキュリティ更新で何が変わるのか
今回の「Microsoft Purview: Azure AI Foundry integration with Microsoft Purview for AI」は、Azure AI Foundryの管理者がAzureサブスクリプション上でMicrosoft Purviewを有効化できるようにする更新です。有効化後は、AIアプリやエージェントのやり取りに関するデータがMicrosoft Purviewに送られ、AIデータのコンプライアンス、ガバナンス、セキュリティ態勢管理を一元的に扱えるようになります。(Microsoft)
これまでAIアプリの利用状況は、アプリ側のログ、Azure側の監視、セキュリティチームの個別調査に分散しがちでした。今回の連携により、Microsoft Purviewを中心に、プロンプト、応答、関連メタデータ、機密情報の検出、監査、保持、調査といった管理をまとめやすくなります。
ただし、これは単なる「ログ連携」ではありません。AIに入力された情報やAIから返された応答は、機密情報、個人情報、営業秘密、契約情報、ソースコードなどを含む可能性があります。そのため、管理者は可視化できるようになるメリットだけでなく、「誰が閲覧できるのか」「どの期間保持するのか」「DLPでどこまで制御するのか」まで決めておく必要があります。
リリース状況と対象範囲
Microsoft 365ロードマップ上の情報を整理すると、今回の更新は次の位置付けです。
| 項目 | 内容 | 確認すべきポイント |
|---|---|---|
| Roadmap ID | 537271 | Microsoft 365ロードマップで追跡する際の識別子 |
| 機能名 | Microsoft Purview: Azure AI Foundry integration with Microsoft Purview for AI | Azure AI FoundryとMicrosoft Purview for AIの連携 |
| 対象製品 | Microsoft Purview | Purview管理者、セキュリティ管理者、AI開発チームが関係 |
| プラットフォーム | Web | Purviewポータル、Foundryポータル、Azure portalでの確認が中心 |
| クラウド | Worldwide Standard Multi-Tenant | まずは標準マルチテナント環境が対象 |
| ステータス | Rolling out | テナントや環境によって反映時期がずれる可能性あり |
| Preview date | December CY2025 | 検証済み環境がある場合は設定差分を確認 |
| GA date | May CY2026 | 本番利用を前提に運用設計を進める段階 |
| 最終更新 | 2026-06-01T23:15:29 UTC | 日本時間では2026年6月2日朝の更新として扱える |
Microsoft 365ロードマップの情報は、リリース予定日や説明が掲載される一方で、内容は変更される可能性があります。一般提供、延期、キャンセルなどに伴い、掲載情報が変わることもあるため、導入前にはロードマップとMicrosoft Learnの最新ドキュメントを併せて確認してください。(Microsoft)
Purviewで扱えるようになるAIデータと機能
Microsoft Learnでは、Microsoft Foundryを使うAI interactionsに対して、Microsoft Purviewの複数の機能がサポートされると説明されています。主な対象は、DSPM、監査、データ分類、秘密度ラベル、DLP、Insider Risk Management、Communication Compliance、eDiscovery、Data Lifecycle Management、Compliance Managerです。一方で、秘密度ラベルを使わない暗号化はサポート対象外として示されています。(Microsoft Learn)
| Purview機能 | 何に使うか | 管理者が見るべきポイント |
|---|---|---|
| DSPM / DSPM for AI | AI利用状況、機密データの露出、リスクの可視化 | どのAIアプリで機密情報が使われているかを把握 |
| Audit | プロンプト、応答、操作履歴の監査 | 誰が、いつ、どのAIアプリを使ったかを調査 |
| Data classification | プロンプトや応答内の機密情報を分類 | SITやトレーニング可能な分類子の設計を確認 |
| Sensitivity labels | ラベル付きデータの扱いを制御 | RAGや検索連携でラベルが尊重されるかを検証 |
| DLP | 機密情報の送信や入力を制御 | まず監視、次に警告・ブロックへ段階展開 |
| Insider Risk Management | 内部不正や不注意なAI利用の検出 | AI利用を既存の内部リスク調査に組み込む |
| Communication Compliance | 不適切または規制違反の可能性があるAI会話を検出 | レビュー担当者とスコープを明確化 |
| eDiscovery | 法務・監査調査でAI interactionsを検索・収集 | ケース作成、検索条件、エクスポート手順を事前確認 |
| Data Lifecycle Management | AI interactionsの保持・削除 | 保持期間を業務・法務要件に合わせる |
| Compliance Manager | AI規制対応の評価・改善 | AI関連規制への統制状況を見える化 |
特に重要なのは、プロンプトと応答が統合監査ログにキャプチャされ、Activity ExplorerやAuditから検索・確認できる点です。Microsoft Learnでは、ユーザーがAIアプリとどのように、いつ対話したかに加え、操作中にアクセスされたMicrosoft 365上のファイル参照や秘密度ラベル情報が含まれる場合があると説明されています。(Microsoft Learn)
管理者が最初に確認すべき設定
この更新で最も注意すべき点は、有効化の単位です。Microsoft Foundry側では、Operate、Compliance、Security postureタブからAzureサブスクリプションを選択し、Microsoft Purviewのトグルをオンにする手順が示されています。つまり、個別アプリだけを見るのではなく、サブスクリプションに含まれるAIアプリや運用環境全体を確認する必要があります。(Microsoft Learn)
| 確認項目 | なぜ重要か | 実務上の対応 |
|---|---|---|
| 対象サブスクリプション | 有効化範囲が広がる可能性がある | 本番、検証、PoCのサブスクリプションを分けて棚卸しする |
| Foundry側の権限 | 有効化にはFoundry Account Ownerロールが必要 | Azure管理者とFoundry管理者の責任分界を決める |
| Purview側の権限 | DSPM for AIやActivity Explorerの閲覧に権限が必要 | Compliance AdministratorやContent Explorer系ロールを見直す |
| Purviewライセンス | Foundry連携にはMicrosoft Purviewライセンスが必要 | 対象テナントでライセンス要件を確認する |
| 従量課金 | Foundry AI interactionsのポリシー管理にはpay-as-you-go billingが関係する | 予算管理、課金責任者、検証範囲を決める |
| 認証方式 | DLPなどのポリシー適用可否に影響する | Entra IDユーザーコンテキスト認証を使っているか確認する |
| 保持・eDiscovery | AI interactionsが調査対象になり得る | 保持期間、検索条件、レビュー担当を事前に決める |
| ネットワーク分離 | Foundry側ドキュメントでは、この統合はnetwork isolationをまだサポートしないとされる | プライベート接続前提の環境では本番適用前に制約を確認する |
Foundry側でMicrosoft Purviewを有効化するにはFoundry Account Ownerロールが必要です。また、Microsoft Purview AuditはFoundry services向けのPurviewライセンスに含まれる一方、Purview側でデータセキュリティポリシーを設定する場合は従量課金メーターに基づく課金が関係します。(Microsoft Learn)
開発者が注意すべき認証と実装のポイント
開発者にとって最も重要なのは、AIアプリがどの認証方式でFoundryを呼び出しているかです。Microsoft Learnでは、Microsoft Purview Data Security Policiesは、Foundryのマネージド推論エンドポイントに対してMicrosoft Entra IDのユーザーコンテキスト認証を使う対話に適用されると説明されています。それ以外の認証シナリオでは、ユーザー対話はPurview AuditやDSPM for AI Activity Explorerの分類には表示されますが、データセキュリティポリシーによる強制は行われないとされています。(Microsoft Learn)
これは実務上、大きな差になります。たとえば、アプリがAPIキーやアプリ専用の資格情報でバックエンドからモデルを呼び出している場合、監査や分類には出ても、ユーザーごとのDLP制御やポリシー適用が期待通りに働かない可能性があります。AIアプリを本番運用しているチームは、次の観点で実装を確認してください。
| 開発観点 | 確認すること | 失敗しやすいポイント |
|---|---|---|
| ユーザーコンテキスト | Entra IDユーザーコンテキストをFoundry呼び出しに渡しているか | バックエンドの単一サービスIDだけで呼び出している |
| エンドポイント | Foundryのマネージド推論エンドポイントを使っているか | 別経路のAPI呼び出しがPurviewポリシー対象外になる |
| RAG構成 | Azure AI Searchなどの検索基盤でラベルや権限を尊重しているか | ユーザーが本来見られない文書が回答に混ざる |
| DLP連携 | Purview APIやAgent Frameworkが必要な場面か | Foundryのネイティブ連携だけで全制御ができると誤解する |
| テストデータ | 機密情報を含むプロンプトと応答で検証したか | 正常系のチャットだけ確認して本番展開する |
Microsoftの開発者向けドキュメントでは、Foundryのネイティブ統合は監査やガバナンス目的では推奨される一方、DLPポリシーの強制や過剰共有の防止には、Agent FrameworkやMicrosoft Purview APIsの利用が必要になる場面が示されています。特に、AIアプリが機密情報をLLMに送る可能性がある場合や、リスクの高いユーザーに対する制御を行う場合は、設計段階でPurview API連携を検討すべきです。(Microsoft Learn)
RAGアプリでは秘密度ラベルと権限継承を必ず検証する
Azure AI FoundryでRAGアプリや社内文書検索エージェントを作っている場合、Microsoft Purview連携の価値はさらに大きくなります。Microsoft Learnでは、AI Searchをナレッジ検索サービスとして使うRAGベースのFoundryアプリやエージェントは、Microsoft 365 Copilotと同様に秘密度ラベルを尊重できると説明されています。暗号化されたアイテムを検索結果として返すには、ユーザーにVIEWに加えてEXTRACTの使用権限が必要です。(Microsoft Learn)
ここでの実務上の落とし穴は、「検索インデックスに入っているから回答できる」と考えてしまうことです。社内規程、契約書、人事情報、設計資料などをRAGに使う場合、検索インデックス作成時点だけでなく、クエリ実行時にユーザー権限と秘密度ラベルが正しく評価されるかを確認してください。
検証では、少なくとも次の3パターンを用意すると判断しやすくなります。
| テストパターン | 期待する結果 |
|---|---|
| 権限のあるユーザーがラベル付き文書を質問する | 必要な範囲で回答または参照される |
| 権限のないユーザーが同じ文書を質問する | 回答に含まれない、または参照されない |
| 暗号化ラベル付き文書を質問する | VIEWとEXTRACT権限の有無で結果が変わる |
この検証をしないまま本番化すると、AI回答による過剰共有に気づきにくくなります。RAGアプリでは、モデルの精度評価だけでなく、「アクセスしてよい情報だけを使って回答しているか」をリリース判定に含めてください。
展開手順は「棚卸し、限定有効化、監査確認、ポリシー強化」の順で進める
Microsoft PurviewとAzure AI Foundryの連携は、いきなり全社展開するより、対象を絞って検証する方が安全です。特に、プロンプトや応答には機密データが含まれる可能性があるため、可視化の前に閲覧権限と保持方針を決めておく必要があります。
| フェーズ | 作業内容 | 完了条件 |
|---|---|---|
| 事前準備 | Foundryアプリ、エージェント、サブスクリプション、認証方式を棚卸しする | 対象と除外範囲が一覧化されている |
| 権限整理 | Foundry Account Owner、Purview管理者、監査閲覧者を決める | 有効化・閲覧・調査の担当が分かれている |
| 限定有効化 | 検証用または代表的なサブスクリプションでPurviewをオンにする | 想定したAI interactionsが収集される |
| 監査確認 | DSPM for AI、Activity Explorer、Auditでデータを確認する | プロンプト、応答、分類、アプリ名、ユーザー情報の見え方を把握 |
| ポリシー設計 | DLP、Communication Compliance、Insider Risk、保持を段階的に設定 | 監視から警告・ブロックへの移行基準がある |
| 本番展開 | 対象サブスクリプションを広げる | 影響範囲、コスト、運用手順が承認済み |
| 継続運用 | レポートとアラートを定期レビューする | AI利用の変化に合わせてポリシーを更新 |
Microsoft Learnでは、DSPM for AIの推奨事項からAzure AI apps and agentsのデータ保護を開始し、プロンプトと応答のキャプチャ設定、レポート確認、Activity Explorerでの詳細確認へ進む流れが示されています。また、データ表示にはContent Explorer Content Viewerロールグループなどの権限が関係します。(Microsoft Learn)
保持とeDiscoveryは後回しにしない
AI interactionsをPurviewで扱えるようになると、監査や調査には便利ですが、同時に法務・コンプライアンス上の扱いも明確にする必要があります。Microsoft Learnでは、Microsoft Foundryとのやり取りをコンプライアンス目的で保持する場合、Microsoft PurviewポータルのData Lifecycle ManagementからRetention Policiesを作成し、場所としてEnterprise AI appsを選択する手順が示されています。(Microsoft Learn)
eDiscoveryでは、Azure AI service interactionsを検索・収集・分析・レビュー・エクスポートする場面が想定されます。Microsoft Learnでは、ItemClassプロパティに IPM.SkypeTeams.Message.ConnectedAIApp.AzureAI.<AzureResourceName> の値を使って検索する方法が示されています。(Microsoft Learn)
ここで重要なのは、保持ポリシーを「長く残せば安心」と考えないことです。AIのプロンプトや応答には、通常の業務文書よりも雑多で機密性の高い情報が混ざりやすい傾向があります。保持期間は、監査要件、業界規制、社内規程、個人情報の最小化原則、調査実務を踏まえて決めるべきです。
DLPとCommunication Complianceは段階展開が安全
DLPを最初から強いブロック設定にすると、開発者や業務部門のAI利用を止めてしまうことがあります。一方で、監視だけでは機密情報の流出リスクを抑えきれません。現実的には、次のような段階展開が適しています。
| 段階 | 設定例 | 目的 |
|---|---|---|
| 監視 | 機密情報を含むAI interactionsを記録する | 実際の利用状況とリスクを把握 |
| 警告 | 機密情報を入力したユーザーに警告を出す | 業務影響を抑えながら行動変容を促す |
| 例外付きブロック | 特定部署や特定データ種別でブロックする | 高リスク領域から制御を強化 |
| 全体最適化 | DLP、Insider Risk、Communication Complianceを連携 | AI利用を継続的に管理する |
Microsoft PurviewのDLPは、Microsoft 365サービスやエンドポイント上の機密情報を識別し、監視や保護に使われます。AIアプリとの関係では、プロンプト内の機密情報に基づくブロックや、サードパーティ生成AIサイトへの貼り付け警告・ブロックなども関連します。(Microsoft Learn)
Communication Complianceでは、AIアプリのユーザープロンプトや応答を含むコミュニケーション上の問題を検出・管理する用途が想定されています。業界規制、ハラスメント、機密情報の不適切な共有、社内規範違反などをレビュー対象にする場合は、ポリシーの範囲とレビュー担当者を事前に定義してください。(Microsoft Learn)
公式ドキュメント間の表現差にも注意する
今回のロードマップ項目では、AI Foundry上でMicrosoft Purviewを有効化すると、すべてのアプリとエージェントのAI interaction dataがPurviewに流れると説明されています。(Microsoft)
一方で、Microsoft Defender for Cloud側のドキュメントには、Microsoft Purview integration does not include data or context from Foundry agentsという注意が残っています。(Microsoft Learn)
このように、リリース途中の機能では、ロードマップ、Foundryドキュメント、Defender for Cloudドキュメントの表現が一時的にそろわないことがあります。本番展開前には、対象のエージェント種別、呼び出し経路、認証方式ごとに、Purview Audit、DSPM for AI Activity Explorer、DLPポリシーの挙動を実機で確認してください。特に、エージェントを複数のフレームワークやカスタムAPIで構成している場合は、「Foundryで作ったから全部同じように管理される」と考えない方が安全です。
導入判断の基準
今回のMicrosoft Purview連携は、Azure AI Foundryを業務利用している組織ほど優先度が高くなります。ただし、すべての環境で即時に強制制御まで進める必要はありません。次の基準で判断すると、導入計画を作りやすくなります。
| 状況 | 推奨アクション |
|---|---|
| Foundryアプリが本番稼働している | 早期に限定有効化し、監査とDSPM for AIの可視化を開始 |
| 生成AIで顧客情報、契約情報、ソースコードを扱う | DLP、保持、eDiscoveryまで含めて設計 |
| RAGでSharePointや社内文書を検索している | 秘密度ラベル、アクセス権、EXTRACT権限を重点検証 |
| 認証がAPIキー中心 | Entra IDユーザーコンテキスト認証への見直しを検討 |
| ネットワーク分離が必須 | 現時点の制約を確認し、適用範囲を限定 |
| Purviewライセンスや課金管理が未整理 | 先にライセンス、従量課金、予算責任者を決める |
| PoC段階で利用者が限定的 | 監査・分類の検証から開始し、ブロックは後段で検討 |
管理者と開発者が次に取るべき行動
まず、Azure AI Foundryで稼働しているアプリ、エージェント、サブスクリプション、認証方式を一覧化してください。次に、Microsoft Purview側で誰がAI interactionsを閲覧・調査できるのかを決め、DSPM for AI、Audit、Activity Explorer、DLP、保持、eDiscoveryの利用方針を整理します。
開発チームは、Entra IDユーザーコンテキストがFoundryの呼び出しに正しく渡っているか、RAGで秘密度ラベルと権限が尊重されるか、必要に応じてPurview APIsやAgent Frameworkを使うべきかを確認してください。
今回の更新は、AI活用を止めるためのものではなく、AIを業務システムとして安全に運用するための土台です。Microsoft Purviewを有効化する前に、対象範囲、権限、課金、保持、DLP、実装方式をそろえておけば、Azure AI Foundryで作ったAIアプリやエージェントを、監査可能で説明責任を果たせる形に近づけられます。
コメント