Microsoft PurviewとAzure AI Searchを組み合わせて社内検索やRAGアプリを作っている場合、今回のポイントは「秘密度ラベルを検索結果に反映するだけでなく、監査で追跡しやすくなる」ことです。2026年6月3日に更新された公式情報では、Azure AI SearchがMicrosoft Purviewの秘密度ラベルを扱うインデックスに対して、クエリ時のアクセス制御や特権読み取り、監査ログ連携をプレビューとして提供する内容が整理されています。(Microsoft Learn)
特に影響が大きいのは、SharePoint in Microsoft 365、Azure Blob Storage、Azure Data Lake Storage Gen2、Microsoft OneLakeなどのドキュメントをAzure AI Searchに取り込み、Microsoft Purviewの秘密度ラベルを使っている環境です。管理者は「ラベルが付いているから安全」と考えるのではなく、インデックス作成、RBAC、マネージドID、APIバージョン、監査ログ確認まで一連の設定を見直す必要があります。なお、本機能はプレビューであり、本番全面展開ではなく非本番環境での検証から始めるのが現実的です。Azure Updates上でも「In preview」は非本番利用とテスト向けの提供として説明されています。(マイクロソフト Azure)
今回のMicrosoft Purview更新で変わること
今回の更新は、Microsoft Purviewの秘密度ラベルをAzure AI Searchの検索体験により深く反映するものです。Azure AI Searchは、インデックス作成時にドキュメント単位の秘密度ラベルメタデータを抽出・保存し、クエリ時にMicrosoft Purviewのラベルポリシーに基づくアクセス制御を適用できます。(Microsoft Learn)
これにより、たとえば社内チャットボットがSharePoint上の機密文書を検索する場合、ユーザーがそのラベル付き文書を取得できる権限を持っているかどうかを、検索時に評価できるようになります。単に検索結果を返すのではなく、「そのユーザーに返してよい文書か」をMicrosoft Purviewのポリシーと照合する点が重要です。
| 観点 | これまで課題になりやすかった点 | 今回確認すべきこと |
|---|---|---|
| 秘密度ラベル | 検索インデックス側でラベル情報を十分に扱えず、アプリ側で別途制御が必要になりやすい | インデックス作成時にラベルメタデータを取り込む設定になっているか |
| 検索結果の制御 | RAGアプリや社内検索で、ユーザーごとの閲覧可否を実装側で補う必要があった | クエリ時にユーザートークンを渡し、ラベルベースのアクセス制御を適用しているか |
| 監査 | 管理調査時に「誰が、どのラベル付き文書にアクセスしたか」を追いにくい | Purview監査ログでAzure AI Search関連のイベントを検索できるか |
| 運用 | ラベル変更や権限変更が検索結果にいつ反映されるか不明確になりやすい | インデクサーの再実行間隔、再インデックス設計、障害時の5xx対応を決めているか |
Microsoftの公式更新では、Azure AI Searchがインデックス済みドキュメントに付随するMicrosoft Purview秘密度ラベルについて監査イベントを出力することが示されています。(マイクロソフト Azure) ただし、プレビュー段階では仕様や対象範囲が変わる可能性があるため、監査ログの内容は実際のテナントで検証してから運用ルールに落とし込むべきです。
影響を受ける環境
影響を受ける可能性が高いのは、次のような環境です。
- Azure AI SearchでSharePoint、Blob Storage、ADLS Gen2、OneLakeの文書をインデックス化している
- Microsoft Purviewの秘密度ラベルを社内文書に適用している
- Azure AI Searchを使ったRAGアプリ、社内検索、ナレッジ検索、エージェント型検索を構築している
- 検索APIをAPIキー中心で呼び出している
- 検索結果をLLMに渡し、回答生成に使っている
公式ドキュメントでは、秘密度ラベル取り込みの対象データソースとしてAzure Blob Storage、Azure Data Lake Storage Gen2、SharePoint in Microsoft 365、Microsoft OneLakeが挙げられています。(Microsoft Learn)
一方で、単にMicrosoft Purviewを契約しているだけ、またはAzure AI Searchを使っていない環境では、直接の影響は限定的です。ただし、今後RAGアプリや社内AI検索を導入する予定がある場合は、初期設計の段階で秘密度ラベルと監査の扱いを決めておく価値があります。
管理者だけでなく開発者にも関係する理由
この更新は、Microsoft Purview管理者だけで完結する話ではありません。Azure AI Searchのリソース管理者、Microsoft Entra ID管理者、アプリ開発者、セキュリティ・コンプライアンス担当者が同じ設計を共有する必要があります。
理由は単純です。秘密度ラベルのポリシーはPurview側にありますが、それを検索時に正しく評価するには、Azure AI Search側のインデックス設定、マネージドID、RBAC、クエリ時のユーザートークン、アプリ側のエラー処理がすべて揃っている必要があるためです。
管理者が最初に確認すべき設定
Microsoft Purviewの秘密度ラベル監査を検証する前に、まず「前提条件を満たしているか」を確認します。ここを飛ばすと、検索結果が想定より少ない、ラベル付き文書が返らない、監査ログが見つからない、といった問題につながります。
| 確認項目 | 確認する理由 | 失敗しやすいポイント |
|---|---|---|
| 秘密度ラベルポリシー | インデックス作成前にラベルとポリシーが文書へ適用されている必要がある | 後からラベルを付けても、次回インデクサー実行まで反映されない |
| Microsoft Entraテナント | Azure AI Searchサービスとクエリ実行ユーザーが同じテナントに存在する必要がある | ゲストユーザーやクロステナント利用を想定してしまう |
| システム割り当てマネージドID | Azure AI SearchがPurviewへ安全にアクセスするために必要 | ユーザー割り当てマネージドIDで代替できると誤解する |
| RBAC認証 | Purview対応インデックスではドキュメント操作APIにRBACが必要 | 既存アプリがAPIキー前提で実装されている |
| 監査ログの閲覧権限 | PurviewポータルでAudit Searchを使って検証するために必要 | ログは出ているが、担当者に閲覧権限がない |
公式ドキュメントでは、Purview APIと秘密度ラベルへのアクセス権を検索サービスに付与するため、Microsoft EntraテナントのGlobal AdministratorまたはPrivileged Role Administratorが必要とされています。また、Azure AI Searchのシステム割り当てマネージドIDに対し、Content.SuperUserとUnifiedPolicy.Tenant.Readを付与する流れが示されています。(Microsoft Learn)
この権限付与は強い権限を伴います。検証だからといって開発チームだけで進めず、セキュリティ部門やコンプライアンス部門の承認プロセスに乗せるべきです。特に、暗号化されたコンテンツや分類情報へアクセスする可能性があるため、検証用リソース、対象データ、担当者、ログ確認手順を明確にしてから進めるのが安全です。
開発者が確認すべき実装ポイント
開発者が最初に見るべきなのは、検索クエリの呼び出し方です。Purviewの秘密度ラベルをクエリ時に適用するには、単にAzure AI Searchへ検索リクエストを送るだけでは不十分です。
Azure AI Searchは、クエリ時に呼び出し元アプリケーションのRBACロールと、x-ms-query-source-authorizationヘッダーで渡されるユーザーIDトークンを検証します。ユーザーが該当する秘密度ラベルに対する権限を持たない場合、その文書は検索結果から除外されます。(Microsoft Learn)
標準クエリではアプリトークンとユーザートークンを分ける
実装上のポイントは、アプリケーションの権限とエンドユーザーの権限を混同しないことです。
POST {{endpoint}}/indexes/{{indexName}}/docs/search?api-version=2025-11-01-preview
Authorization: Bearer {{app-query-token}}
x-ms-query-source-authorization: {{user-query-token}}
Content-Type: application/jsonAuthorizationヘッダーは、検索を実行するアプリケーションの権限を示します。一方、x-ms-query-source-authorizationは、検索しているエンドユーザーの文脈を示します。アプリが強い権限を持っていても、ユーザーがそのラベル付き文書を取得できなければ、結果には含まれません。
OBO、つまりOn-Behalf-Ofフローを使う場合は、Microsoft Entra IDとMSALなどの認証ライブラリを使い、Azure AI Search向けのトークンを取得します。公式ドキュメントでは、Azure AI Searchを呼び出す場合のリソースURIとしてhttps://search.azure.com/.defaultが示されています。また、EXTRACTなどの秘密度ラベル権限はOAuthスコープではなく、実行時にPurviewポリシーに基づいて評価されます。 (Microsoft Learn)
特権読み取りは通常検索と分けて設計する
管理調査やインシデント対応では、通常ユーザーには見えないラベル付き文書を、権限を持つ担当者が調査目的で読む必要があります。この用途向けに、特権読み取りがプレビューで用意されています。
特権読み取りでは、x-ms-enable-elevated-read: trueヘッダーを使います。この場合、通常のユーザー権限に基づくドキュメントごとのラベルチェックをスキップして一致文書を返し、返された各ドキュメントについてMicrosoft Purview監査ログエントリを出力します。利用にはSearch Index Data Contributorロールが必要で、Search Index Data Readerでは不十分です。(Microsoft Learn)
POST {{endpoint}}/indexes/{{indexName}}/docs/search?api-version=2026-05-01-preview
Authorization: Bearer {{contributor-token}}
x-ms-enable-elevated-read: true
Content-Type: application/jsonここで注意すべきなのは、特権読み取りを通常のユーザー検索の延長として実装しないことです。調査用の画面、操作権限、承認フロー、ログレビューを分けて設計しなければ、便利な管理機能が過剰アクセスの入口になります。
インデックス設計と移行で注意すべきこと
既存のAzure AI Searchインデックスに後から少し設定を足せば済む、とは考えないほうが安全です。公式ドキュメントでは、秘密度ラベルを有効にするにはインデックス作成時にpurviewEnabledをtrueに設定する必要があり、この設定は永続的で後から変更できないとされています。(Microsoft Learn)
つまり、既存インデックスをそのままPurview対応へ変更できないケースでは、新しいインデックスを作成し、データソース、フィールド、スキルセット、アプリ側の接続先を段階的に移行する設計が必要です。
移行時の基本手順
| 手順 | 実施内容 | 確認ポイント |
|---|---|---|
| 既存構成の棚卸し | 対象インデックス、データソース、スキルセット、APIキー利用箇所を洗い出す | RAGアプリやバッチ処理も含める |
| 検証用インデックス作成 | purviewEnabled: trueを指定した新規インデックスを作る | 後から変更できないため命名と用途を明確にする |
| データソース設定 | indexerPermissionOptionsにsensitivityLabelを設定する | SharePoint、Blob、ADLS Gen2、OneLakeなど対象に合わせる |
| フィールドマッピング | metadata_sensitivity_labelなどのラベルメタデータをsensitivityLabelへマップする | ソースによりフィールド名が異なる可能性がある |
| チャンク投影 | Text Splitや統合ベクター化を使う場合、各チャンクへ秘密度ラベルを投影する | チャンク単位でラベルが欠落するとフィルターが崩れる |
| 権限別テスト | 一般ユーザー、ラベル権限ありユーザー、管理調査ユーザーで検索結果を比較する | 「見えるべきもの」「見えてはいけないもの」を両方確認する |
| 監査確認 | Purview Audit Searchでイベントとフィールドを確認する | ラベル名、ソース種別、ドキュメントIDを追跡できるか |
特にチャンク化したRAG構成では、親ドキュメントに秘密度ラベルがあっても、子チャンクにラベル情報が投影されていなければ正しくフィルターできません。公式ドキュメントでも、Text Splitスキルなどでチャンクを作る場合、各チャンクに秘密度ラベルを投影する必要があり、マッピングがないと子チャンク行が正しくフィルターされないと説明されています。(Microsoft Learn)
監査ログで確認すべき項目
監査ログの確認は、単に「ログがあるか」を見るだけでは不十分です。運用に使える監査にするには、調査時に必要な粒度で情報を追えるかを確認します。
Microsoft Purviewで特権読み取りの監査ログを調べる場合、PurviewポータルでSolutions > Auditを開き、Audit Searchから日付範囲、ユーザー、Azure AI Searchのレコード種類などでフィルターします。監査エントリには、SensitivityLabelName、DocumentDataSourceType、DocumentDataSourceIdなどのAzure AI Search固有フィールドが含まれます。(Microsoft Learn)
| フィールド | 見る目的 |
|---|---|
UserPrincipalName | 誰が操作したかを確認する |
ClientIP | どこから呼び出されたかを確認する |
DocumentDataSourceType | SharePoint、Blob、OneLakeなど、どの種別のデータかを確認する |
DocumentDataSourceId | 対象文書を特定する |
SensitivityLabelName | どの秘密度ラベル付き文書が対象だったかを確認する |
CreationTime | いつ操作されたかを時系列で確認する |
監査ログは検索応答が返された後に非同期でPurviewへアップロードされます。リアルタイムのアクセス制御と、後続の監査確認を同じタイミングで扱うと誤解が生まれます。運用手順では「検索リクエスト直後に必ずログが見える」と決めつけず、遅延を考慮して調査手順を設計してください。
制限事項と失敗しやすいポイント
プレビュー機能を評価するときは、できることよりも「できないこと」を先に押さえるほうが実務では役立ちます。
公式ドキュメントでは、Purview対応インデックスに対してゲストアカウントとクロステナントクエリはサポートされず、Autocomplete APIとSuggest APIもサポートされないとされています。また、ラベル評価に失敗した場合は5xxを返し、部分的またはフィルターされていない結果セットは返しません。(Microsoft Learn)
さらに、Azureポータルではこの機能がサポートされていないこと、ユーザー割り当てマネージドIDがサポートされないこと、Custom Web APIスキル、GenAI Promptスキル、Knowledge store、Indexer enrichment cache、Debug sessionsなど一部のインデクサー機能では秘密度ラベル付きドキュメントが処理されないことも明記されています。(Microsoft Learn)
よくある落とし穴
ラベル変更がすぐ検索結果に反映されると思い込む
ソース文書の秘密度ラベル変更は、次にインデクサーが正常に実行されるまでインデックスに反映されません。公式ドキュメントでは、インデクサーの最小サポート間隔は5分とされています。(Microsoft Learn)
たとえば、機密ラベルを付けた直後にRAGアプリで検索テストをしても、古いインデックス状態のままなら期待した制御にならない可能性があります。検証時は「ラベル変更」「インデクサー実行」「検索確認」「監査確認」をセットで記録しましょう。
APIキー前提の既存アプリをそのまま使う
purviewEnabledがtrueのインデックスでは、ドキュメント操作APIはRBAC認証が前提になります。APIキーアクセスはインデックススキーマの取得に制限されます。(Microsoft Learn)
既存の社内検索アプリがAPIキーで検索している場合、認証方式の変更が必要です。アプリ登録、RBACロール割り当て、OBOフロー、トークン更新、ローカル開発時のテスト方法まで見直してください。
秘密度ラベルのGUIDだけでUI表示を済ませる
Azure AI Searchが返す秘密度ラベルのGUIDは、ラベルを一意に識別するためのものです。しかし、ラベル名、説明、印刷や画面キャプチャ制限などのUI上必要な情報はGUIDだけでは分かりません。ラベル名の表示やUI固有の制限を実装するには、Microsoft Purview Information ProtectionエンドポイントやPurview Labels APIを使ってラベルメタデータを取得する必要があります。(Microsoft Learn)
RAGアプリで「この回答は機密文書に基づいています」と表示したい場合、検索結果のGUIDをそのまま画面に出すのではなく、ラベル名や説明へ解決する実装を用意しましょう。
5xxを通常の検索障害としてだけ扱う
Purview APIに一時的に到達できない場合など、ラベル評価に失敗するとAzure AI Searchは5xxを返します。標準のラベル適用リクエストでは、部分的な結果や未フィルター結果を返さないため、アプリ側では「安全側に倒れる」挙動になります。(Microsoft Learn)
ただし、ユーザー体験としては検索失敗に見えます。アプリ側では、一般的なリトライ、ユーザー向けメッセージ、管理者向けアラート、Purview側障害との切り分け手順を用意しておく必要があります。
RAGアプリや社内AI検索での実務的な使いどころ
この更新が特に効果を発揮するのは、Microsoft 365上の文書をAzure AI Searchで検索し、検索結果をLLMに渡す構成です。従来のRAGでは、検索で取得された文書がそのままプロンプトに入るため、検索段階のアクセス制御が甘いと、生成AIの回答を通じて情報が広がるリスクがありました。
Microsoft Purviewの秘密度ラベルをAzure AI Searchで尊重できれば、ユーザーがアクセスできないラベル付き文書を検索結果から除外しやすくなります。これは、AIの回答生成前に「そもそも取得してよい文書か」を判定できるという意味で重要です。
ただし、これだけでAIアプリ全体のガバナンスが完了するわけではありません。プロンプトや回答の監査、DLP、ユーザー操作ログ、回答画面でのラベル表示、引用元の扱い、管理者による特権調査などは別途設計が必要です。Microsoft PurviewはAIアプリの監査やデータ分類にも関係しますが、アプリ側がどの経路でPurviewと統合するかによって実装責任が変わります。(Microsoft Learn)
展開前のチェックリスト
検証を始める前に、次の順番で確認すると手戻りを減らせます。
- 対象データソースを決める
SharePoint、Blob、ADLS Gen2、OneLakeのどれを対象にするかを明確にします。 - 秘密度ラベルのテストデータを用意する
「公開」「社内」「機密」など、権限差が分かる複数ラベルの文書を用意します。 - 検証用Azure AI Searchインデックスを新規作成する
purviewEnabledは後から変更できないため、既存インデックスではなく検証用に作成します。 - RBACとマネージドIDを設定する
システム割り当てマネージドID、必要なPurview権限、検索アプリ側のRBACを確認します。 - ユーザー別に検索結果を比較する
ラベル権限を持つユーザー、持たないユーザー、管理調査ユーザーで同じクエリを実行します。 - 監査ログを確認する
Purview Audit Searchで対象イベントを検索し、ユーザー、文書、ラベル、ソースIDが追跡できるか確認します。 - 障害時の動作を決める
5xx発生時のリトライ、ユーザー表示、管理者通知、ログ保全を決めます。 - 本番展開の可否を判断する
プレビュー段階であることを踏まえ、対象範囲を限定するか、正式リリースまで待つかを判断します。
まず何から始めるべきか
最初にやるべきことは、既存のAzure AI Search構成の棚卸しです。どのインデックスがMicrosoft 365文書を取り込んでいるか、どのアプリが検索APIを呼んでいるか、APIキーを使っている箇所がないか、ラベル付き文書がRAGの回答生成に使われていないかを確認してください。
次に、検証用の小さなインデックスを作り、秘密度ラベル付き文書を数種類だけ取り込んで、権限の異なるユーザーで検索結果と監査ログを比較します。いきなり全社文書を対象にするより、ラベル、権限、検索結果、監査ログの関係を小さく再現するほうが確実です。
今回のMicrosoft PurviewとAzure AI Searchの更新は、AI検索の安全性を高めるための重要な一歩です。ただし、効果を出すには「Purview側でラベルを作る」だけでは足りません。インデックス作成、クエリ認証、RBAC、特権読み取り、監査、UI表示、障害対応までをまとめて設計し、プレビューの制限を理解したうえで段階的に展開しましょう。
コメント