Azure AI 検索 における Microsoft Purview 秘密度ラベルのクエリ時の強制適用 (プレビュー)

クエリ時に、Azure AI 検索は、Microsoft Purview で定義されている秘密度ラベル ポリシーを適用できます。 これらのポリシーには、各ドキュメントに関連付けられている EXTRACT 使用権限 の評価が含まれます。これにより、ユーザーはアクセスが許可されているドキュメントのみを取得できます。

この機能により、ドキュメント レベルのアクセス制御が拡張され、組織の情報保護とコンプライアンス要件は Microsoft Purview で管理されます。

Purview 秘密度ラベルのインデックス作成が有効になっている場合、Azure AI 検索はクエリ時に各ドキュメントのラベル メタデータをチェックします。 Purview ポリシーに基づいてアクセス フィルターを適用し、要求元のユーザーがアクセスを許可されている結果のみを返します。

この記事では、クエリ時間の秘密度ラベルの適用のしくみと、セキュリティで保護された検索クエリを発行する方法について説明します。

前提 条件

• Azure AI 検索 インデクサーを使用して Microsoft Purview の秘密度ラベルを取り込むすべての手順を完了します。

• Azure AI 検索 サービスでシステム割り当てマネージド ID (ユーザー割り当てマネージド ID ではなく) が有効になっており、Content.SuperUserとUnifiedPolicy.Tenant.Readロールの割り当てが保持されていることを確認します。 クエリ時間の適用は、システム割り当て ID に正しい構成がある場合にのみインデクサーが抽出できるラベル メタデータに依存します。 インデクサーのセットアップに関する記事の 手順 1 を参照してください。

• Azure AI 検索 サービスとクエリを発行するユーザーの両方が、同じMicrosoft Entra テナントに存在する必要があります。

• インデックスのクエリを実行するための REST API バージョン 2025-11-01-preview 以降、または同等のプレビュー SDK パッケージ。 elevated read 機能と Purview 監査ログを利用するには、2026-05-01-preview 以降が必要です。

• API キーではなく、Azure ロールベースのアクセス制御 (RBAC) を使用してクエリを認証します。 Purview 秘密度ラベルが有効になっている場合、API キーのアクセスはインデックス スキーマの取得に制限されます。

制限

• ゲスト アカウント とテナント間クエリはサポートされていません。

• オートコンプリート API と Suggest API は、Purview 対応インデックスではサポートされていません。

• ラベルの評価が失敗した場合、サービスは、部分的またはフィルター処理されていない結果セットではなく、特定の HTTP エラー コードを返します。 エラー コードと原因の完全な一覧については、「 クエリ エラーのトラブルシューティング」を参照してください。

• システムは、前回のインデクサー実行時に存在していたラベルのみを評価します。 最近のラベルの変更は、次にスケジュールされたインデックスが再作成されるまで反映されない場合があります。

クエリ実行時の感度ラベル適用のしくみ

秘密度ラベルを含むインデックスに対してMicrosoft Purviewのクエリを実行すると、Azure AI 検索は結果を返す前に関連するPurviewポリシーを確認します。 この方法では、クエリは、ユーザー トークンがアクセスを許可されているドキュメントのみを返します。

1. ユーザー ID とアプリケーション ロールの入力

クエリ時に、Azure AI 検索は両方を検証します。

• 呼び出し元のアプリケーションの RBAC ロール。 Authorization ヘッダーに含まれています。 最低限必要なロールは Search Index Data Reader。 詳細については、Azure AI 検索 RBAC ガイドを参照してください。
• x-ms-query-source-authorization ヘッダーで指定されたトークンを介したユーザー ID。

ラベルベースの可視性を承認するには、両方が必要です。

2. 秘密度ラベルの評価

クエリ要求を受信すると、Azure AI 検索は次を評価します。

1. 各インデックス付きドキュメントの sensitivityLabel フィールド (インジェスト中にMicrosoft Purviewから抽出されます)。
2. ユーザーの有効な Purview アクセス許可 (Microsoft Entra IDおよび Purview ラベル ポリシーによって定義されます)。

ユーザーが EXTRACT アクセス許可を持つドキュメントの秘密度ラベルを承認されていない場合、そのドキュメントはクエリ結果から除外されます。

3. セキュリティで保護された結果のフィルター処理

Azure AI 検索は、ユーザー定義のすべてのフィルターとスコアリングの手順の後にセキュリティ フィルターを適用します。
ドキュメントは、次の場合にのみ最終的な結果セットに含まれます。

• 呼び出し元のアプリケーションには、有効なロールの割り当て (RBAC 経由) がある。
• x-ms-query-source-authorizationによって表されるユーザー ID トークンは有効であり、ドキュメントの秘密度ラベルを持つコンテンツを表示できます。

いずれかの条件が失敗した場合、ドキュメントは結果から省略されます。

ユーザー アクセス トークンを取得する

ユーザー コンテキストを使用してAzure AI 検索クエリを実行するには、サインインしているユーザーを表すアクセス トークンを取得する必要があります。 使用する方法は、独自のトークンを使用してローカルでテストするか、ソース ドキュメントにアクセスできるか、エンドユーザー トークンを渡す必要があるアプリケーション フローを実装するかによって異なります。

テスト シナリオ用

ローカル テストでは、Azure CLIを使用してユーザー アクセス トークンを取得できます。

$token = az account get-access-token `
  --resource https://search.azure.com `
  --query accessToken `
  --output tsv

この方法では、現在の Azure CLI ログイン セッションが使用されるため、秘密度ラベルを使用して割り当てられた EXTRACT アクセス許可を持つドキュメントに対してコンテキストを使用できます。 このメソッドは、開発と検証のシナリオのみを対象としています。

OBO シナリオのトークン取得

代理 (OBO) フローを実装するアプリケーションは、Microsoft Authentication Library (MSAL) などのサポートされている認証ライブラリを使用して、Microsoft Entra IDを介してトークンを取得する必要があります。

OBO シナリオでは、アプリケーションが呼び出すダウンストリーム API のトークンを要求します。 たとえば、Azure AI 検索を呼び出すとき、リソース URI は https://search.azure.com/.default です。

.default スコープは、指定されたリソースに対してアプリケーションが事前に管理したすべての委任されたアクセス許可を要求します。

EXTRACTを含む秘密度ラベルのアクセス許可は、OAuth スコープとして表されません。 Azure AI 検索などのダウンストリーム サービスは、トークン内のユーザー ID と適用された秘密度ラベル ポリシーに基づいて、実行時にこれらのアクセス許可を評価します。

クエリの例

Microsoft Purview の機密ラベルの適用を使用したクエリ要求の例を次に示します。

アプリケーション トークンをベアラー トークンとして Authorization ヘッダーに渡します。 x-ms-query-source-authorization プレフィックスを指定せずに、Bearer ヘッダーの生のトークン値としてユーザー トークンを渡します。

POST  {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2026-08-01-preview
Authorization: Bearer {{app-query-token}}
x-ms-query-source-authorization: {{user-query-token}}
Content-Type: application/json

{
    "search": "*",
    "select": "title,summary,sensitivityLabel",
    "orderby": "title asc"
}

管理調査用の特権での読み取り (プレビュー)

管理者特権での読み取りを使用すると、承認された開発者は、呼び出し元のユーザーが通常は表示できないラベル付きドキュメントを返すことができます。同時に、要求から返されるすべてのドキュメントに対してMicrosoft Purview監査ログ エントリが出力されます。 コンプライアンス レビュー、電子情報開示、インシデント対応、およびアクセスの監査可能なレコードが必要なその他の管理調査に使用します。

昇格された読み取りは、REST API バージョン 2026-05-01-preview 以降の Purview 対応インデックスで使用できます。

管理者特権での読み取りのしくみ

1. 呼び出し元のアプリケーションは、検索要求に x-ms-enable-elevated-read: true ヘッダーを設定します。

2. Azure AI 検索は、各ラベルに対する要求ユーザーの EXTRACT アクセス許可に関係なく、ドキュメントごとのラベルベースのアクセス チェックをスキップし、一致するドキュメントを返します。

3. 応答内の各ドキュメントについて、Azure AI 検索は、要求するテナントの代わりに、Microsoft Purview監査ログ に 1 つのエントリを出力します。 N 個のドキュメントを返す 1 つの検索要求で、N 個の監査エントリが生成されます。

4. 監査エントリは、検索応答が返された後、Purview に非同期的にアップロードされます。

必要なロールの割り当て

呼び出し元の開発者ユーザーは、検索サービスまたはインデックス スコープで検索 インデックス データ共同作成者 ロールを保持する必要があります。 検索インデックス データ 閲覧者 では不十分です。 ロールが割り当てられていない場合、403 Forbidden での読み取り操作は失敗します。 Azure AI 検索ロールの詳細については、「ロールを使用してAzure AI 検索に接続するを参照してください。

x-ms-enable-elevated-read ヘッダーが true に設定されている場合、x-ms-query-source-authorization ヘッダーの使用は許可されません。

管理者権限での読み取りの例

POST  {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2026-08-01-preview
Authorization: Bearer {{contributor-token}}
x-ms-enable-elevated-read: true
Content-Type: application/json

{
    "search": "*",
    "select": "title,summary,sensitivityLabel",
    "orderby": "title asc"
}

Microsoft Purviewに送信された監査フィールド

各監査エントリは、Office 365 管理アクティビティ API スキーマに従い、次のフィールドを含みます。

優雅な劣化

一時的な Purview の停止中など、クエリの処理中にAzure AI 検索 Microsoft Purviewに到達できない場合、その要求のラベル評価はスキップされます。 動作は、要求にユーザー ID トークンが含まれているかどうかによって異なります。

• 管理者特権での読み取り要求 (x-ms-enable-elevated-read: true): 要求は 5xxで失敗します。 Azure AI 検索は、最初に監査ログを出力できない限り、ラベル付けされたドキュメントを返しません。

• 標準のラベル適用要求 ( x-ms-query-source-authorization): 要求は 5xxで失敗します。 Azure AI 検索は、ラベル ポリシーを評価できない場合、部分的またはフィルター処理されていない結果を返しません。

• 少なくともx-ms-query-source-authorizationロールを持つアプリケーションによって発行されたなしの呼び出し: 要求は成功し、秘密度ラベルがないドキュメントのみを返します。 ラベル付きドキュメントは応答から省略されます。

この低下したパスは、ラベル付けされていない結果を明示的に受け入れるユーザー向け以外のワークフローのみを対象としています。 エンド ユーザーの検索エクスペリエンスに依存しないでください。

クエリ時間の機密ラベルの評価中に返されるエラー コードの完全な一覧については、「 クエリ エラーのトラブルシューティング」を参照してください。

Microsoft Purview で特権読み取り監査ログを検索する

Azure AI 検索は、呼び出し元のテナントのMicrosoft Purview監査ログに監査エントリをアップロードします。 読み取りアクティビティの増加を調査するには:

1. Microsoft Purview ポータルで、Solutions>Audit を選択します。

2. Audit Search を選択し、日付範囲、ユーザー、またはAzure AI 検索 レコードの種類でフィルター処理します。

3. SensitivityLabelName、DocumentDataSourceType、DocumentDataSourceIdなど、標準スキーマ フィールドとAzure AI 検索ユーザー設定フィールドを表示するエントリを開きます。

監査検索、保持動作、および必要な Purview ロールの実行に関する詳細なガイダンスについては、「Microsoft Purview ポータルを参照してください。

Azure AI 検索におけるセンシティビティ ラベルの処理

Azure AI 検索では、SharePoint、Azure BLOB などのソースからの秘密度ラベルを持つドキュメント コンテンツにインデックスを付けると、コンテンツとラベルメタデータの両方が格納されます。 検索クエリは、ドキュメントに適用された秘密度ラベルを識別する GUID と共に、インデックス付きコンテンツを返します。これは、ユーザーが秘密度ラベル定義を介して割り当てられたそのドキュメントのデータ EXTRACT アクセス権を持っている場合のみです。 この GUID はラベルを一意に識別しますが、ラベル名や関連するアクセス許可などの人間が判読できるプロパティは含まれません。

GUID だけでは、ユーザー インターフェイスを含むシナリオでは不十分です。多くの場合、秘密度ラベルには、印刷アクセス許可やスクリーンショット、画面キャプチャの制限など、Microsoft Purview Information Protection によって適用されるその他のポリシー制御が含まれているためです。 Azure AI 検索はこれらの機能を表示しません。

ラベル名を表示したり、UI 固有の制限を適用したりするには、アプリケーションで Microsoft Purview Information Protection エンドポイントを呼び出して、完全なラベル メタデータと関連するアクセス許可を取得する必要があります。

Azure AI 検索によって返される GUID を使用してラベルのプロパティを解決し、Purview Labels API を呼び出して、ラベル名、説明、ポリシー設定をフェッチできます。

クエリのエラーのトラブルシューティング

クエリ時間の機密ラベルの評価が失敗した場合、Azure AI 検索は原因を識別する特定の HTTP エラー コードを返します。 サービスは、部分的またはフィルター処理されていない結果セットを返しません。 ラベル ポリシーを評価できない場合、ラベル付けされていないコンテンツや未承認のコンテンツを公開するのではなく、クエリは失敗します。

400 無効な要求

400 エラーは、インデックス構成または要求ヘッダーに問題があることを示します。 再試行する前に構成を修正します。

401 権限がありません

401 エラーは、承認トークンまたはアプリケーションの Purview アクセス許可に問題があることを示します。

502 無効なゲートウェイ

502 エラーは、Azure AI 検索とMicrosoft Purviewの間の接続エラーを示します。 通常、これらのエラーは一時的なものです。

504 ゲートウェイ タイムアウト

504 エラーは、許可された時間内にMicrosoft Purviewが応答しなかったことを示します。

エンド ツー エンドテストのセットアップ

Azure AI 検索で秘密度ラベルの構成を検証するには、エンド ツー エンドのリファレンスセットアップを参照してください。

このリポジトリでは、次の方法を示します。

• Azure AI 検索 で秘密度ラベルの同期と受け入れを構成する
• 秘密度ラベルを持つドキュメントのインジェストとクエリ時間の適用シナリオをテストする
• ラベル名を抽出し、RAG アプリケーションまたはエージェントで使用される引用文献の一部として公開します。