Microsoft Purviewの秘密度ラベルを使っている組織にとって、今回のAzure AI Searchの更新で最も重要なのは、ソース文書に付与された秘密度ラベルを、AI検索・RAG・エージェントのナレッジ取得経路まで引き継げるようになる点です。これまでアプリ側で独自にラベルや権限を見に行っていた構成では、設計を見直せる可能性があります。
ただし、Public Previewの機能であり、本番利用を前提にすぐ全面展開するものではありません。管理者は、対応するknowledge sources、Microsoft Entra IDとRBAC、Azure AI SearchのマネージドID、既存インデックスの再作成要否、チャンク化されたインデックスへのラベル投影を先に確認する必要があります。MicrosoftのAzure Updatesでは「In preview」は非運用環境での使用・テスト向けと説明されています。(Microsoft Azure)
Microsoft Purviewのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
今回の更新は、Microsoft Purviewそのもののラベル管理機能を大きく変えるものではありません。変わるのは、Microsoft Purviewの秘密度ラベルをAzure AI Searchのknowledge sourcesとknowledge basesの流れに乗せられる範囲です。
Azure AI Searchのknowledge sourcesでは、Blob、indexed OneLake、indexed SharePointの各ナレッジソースに対して、ingestionPermissionOptionsにsensitivityLabelを含めることでMicrosoft Purviewの秘密度ラベルを取り込めます。同期されたラベルはretrieve応答に表示され、クエリ時のドキュメントレベルアクセス制御にも使われます。(Microsoft Learn)
実務上は、次のような構成に影響します。
| 対象 | 影響 |
|---|---|
| 社内文書をAzure AI Searchに取り込み、RAGアプリで使っている環境 | ラベル付き文書をユーザー権限に応じて検索結果から除外しやすくなる |
| Foundry Agent ServiceやCopilot系のエージェントにknowledge baseを接続している環境 | 回答の根拠となる文書参照に秘密度ラベル情報を渡せる |
| SharePoint、OneLake、Blob、ADLS Gen2の文書を検索対象にしている環境 | 既存のMicrosoft Purview情報保護ポリシーとの整合性を取りやすくなる |
| APIキー中心でAzure AI Searchを呼び出しているアプリ | RBACとユーザートークンを使う実装への見直しが必要になる |
重要なのは、「AIが回答を生成したあとにラベルを表示する」だけでは不十分だという点です。RAGやエージェントでは、回答文そのものが情報漏えいの単位になります。検索結果に含めてよい文書を、回答生成前の取得段階で制御できるかが設計上の分かれ目です。
何が変わったのか
今回のPublic Previewにより、Azure AI Searchのknowledge sourcesでMicrosoft Purviewの秘密度ラベルを扱う道筋が広がりました。
大きな変更点は、次の3つです。
| 変更点 | 内容 | 管理者・開発者への影響 |
|---|---|---|
| ラベルの取り込み | ソース文書に付与されたMicrosoft Purviewの秘密度ラベルをインジェスト時にAzure AI Searchへ同期 | インデックスやknowledge source作成時の設定確認が必要 |
| ラベル情報の応答出力 | knowledge baseのretrieve応答に、参照単位のsensitivityLabelInfoや応答レベルのresponseSensitivityLabelInfoを含められる | チャットUIやエージェント側でラベル表示・操作制御を実装できる |
| クエリ時のアクセス制御 | ユーザーのMicrosoft Entra IDトークンとPurviewポリシーをもとに、返してよい文書だけを取得 | APIキーだけの検索実装では不十分になり、RBACとユーザートークンが重要になる |
Azure AI Searchのドキュメントでは、knowledge baseのretrieve応答に参照ごとのsensitivityLabelInfoと、上位のmetadata.responseSensitivityLabelInfoを含められるプレビュー機能が案内されています。(Microsoft Learn)
対象になるknowledge sources
すべてのknowledge sourcesで同じようにMicrosoft Purviewの秘密度ラベルを取り込めるわけではありません。まず、今回の機能がどのデータ経路に効くのかを切り分けてください。
| knowledge source / 構成 | 秘密度ラベル対応の考え方 | 確認ポイント |
|---|---|---|
| Azure Blob / ADLS Gen2を使うblob knowledge source | ingestionPermissionOptionsにsensitivityLabelを指定して取り込み | ラベル付きファイルがPurviewとAzure AI Search indexerの両方で対応する形式か |
| indexed OneLake knowledge source | sensitivityLabelを指定してラベルメタデータを取り込み | OneLake側のラベル運用とインデクサー実行スケジュール |
| indexed SharePoint knowledge source | SharePoint上の文書ラベルをインデックスへ同期 | SharePoint ACLとPurviewラベルをどう併用するか |
| searchIndex knowledge source | 既存インデックス側でpurviewEnabledとラベルフィールドが設定されている場合にラベル情報を扱える | 既存インデックスを後からそのまま流用できるか |
| remote SharePoint、web、その他のリモート系 | インジェストしないため、今回のsensitivityLabel取り込みとは別に考える | 取得時の権限モデルやネイティブAPIの制御を確認 |
Microsoft Learnでは、参照タイプごとにラベルメタデータが出る条件が整理されており、azureBlob、indexedOneLake、indexedSharePointではknowledge source側のsensitivityLabel指定、searchIndexでは基盤インデックスのpurviewEnabledとsensitivityLabel: trueのフィールドが条件とされています。(Microsoft Learn)
管理者が先に確認すべき設定
Microsoft Purview側のラベルとポリシー
最初に見るべきなのはAzure AI Searchではなく、Microsoft Purview側です。秘密度ラベルが作られていない、対象文書に適用されていない、ユーザーやグループへのポリシー割り当てが曖昧な状態では、Azure AI Searchに同期しても期待した制御になりません。
確認すべき項目は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| 秘密度ラベルが定義済みか | 「社外秘」「機密」「役員限定」など、検索・AI利用時に区別したい分類がある |
| 対象文書にラベルが適用済みか | Word、PowerPoint、PDF、SharePoint上の文書など、実際の検索対象にラベルが付いている |
| ラベルポリシーがユーザーに割り当てられているか | 検索するユーザーが、Purview上で対象ラベルのコンテンツを閲覧できる状態か |
| テストユーザーが分かれているか | 「閲覧できるユーザー」と「閲覧できないユーザー」の両方で検証できる |
Microsoft Learnでは、Purview秘密度ラベルポリシーが構成済みで、文書に適用されていることが前提条件として示されています。(Microsoft Learn)
Azure AI SearchのマネージドIDとRBAC
秘密度ラベルの取り込みでは、Azure AI SearchがMicrosoft Purviewのラベルメタデータへアクセスする必要があります。そのため、検索サービスにシステム割り当てマネージドIDを有効化し、必要な権限を付与します。
特に注意したいのは、権限付与が軽い作業ではないことです。Microsoft Learnでは、検索サービスにPurview APIと秘密度ラベルへのアクセスを許可するには、Microsoft EntraテナントのGlobal AdministratorまたはPrivileged Role Administratorが必要とされています。さらに、検索サービスのシステム割り当てマネージドIDにContent.SuperUserとUnifiedPolicy.Tenant.Readを付与する手順が案内されています。(Microsoft Learn)
運用では、次の流れで進めるのが安全です。
| 手順 | 作業内容 | 失敗しやすい点 |
|---|---|---|
| 事前承認 | セキュリティ部門・コンプライアンス部門に目的を説明 | 「検索機能の設定」と軽く扱い、権限の強さを見落とす |
| マネージドID有効化 | Azure AI Searchサービスにシステム割り当てマネージドIDを付ける | ユーザー割り当てマネージドIDで代替しようとする |
| Purviewアクセス付与 | 必要なロールを管理者が付与 | 管理者ロール不足で設定が途中で止まる |
| RBAC有効化 | Azure AI SearchへのクエリをRBACで認証 | 既存アプリがAPIキー前提のまま残る |
| テスト | ラベル別に閲覧可・不可のユーザーで検索 | 管理者アカウントだけで成功確認してしまう |
開発者が確認すべき実装ポイント
knowledge source作成時にsensitivityLabelを指定する
knowledge source経由で秘密度ラベルを扱う場合、作成時にingestionPermissionOptionsへsensitivityLabelを含めます。考え方としては、コンテンツだけでなく「その文書に付いているラベルメタデータ」も一緒に取り込む設定です。
REST APIでは、概念的には次のような指定になります。
{
"ingestionParameters": {
"ingestionPermissionOptions": ["sensitivityLabel"]
}
}Blob、indexed OneLake、indexed SharePointの作成ドキュメントでは、IngestionPermissionOptionsまたはingestionPermissionOptionsにSensitivityLabel / sensitivityLabelを指定できることが説明されています。(Microsoft Learn)
ここでの注意点は、既存のknowledge sourceに後から気軽に足せる設定として考えないことです。公開ドキュメントのプロパティ表ではingestionPermissionOptionsのEditableがNoと示されています。既存環境へ展開する場合は、新しいknowledge sourceや生成されるインデックス・インデクサーの再作成を含めて移行計画を立てるべきです。(Microsoft Learn)
既存インデックスを使う場合はpurviewEnabledを確認する
既存のAzure AI Searchインデックスをknowledge sourceとして使う場合は、インデックス側の設定も重要です。
Microsoft Learnでは、秘密度ラベルのサポートが必要な場合、インデックス定義でpurviewEnabledをtrueに設定し、秘密度ラベル用のフィールドにsensitivityLabel: trueを設定する例が示されています。また、purviewEnabledはインデックス作成時に設定する必要があり、後から変更できない恒久設定とされています。(Microsoft Learn)
つまり、既存インデックスがPurview対応で作られていない場合は、単純な設定変更では済まない可能性があります。実務では、次の判断になります。
| 既存構成 | 推奨判断 |
|---|---|
purviewEnabledなしの既存インデックス | 新インデックスを作成して再インデックスする計画を立てる |
ラベルフィールドはあるがsensitivityLabel: trueでない | スキーマを見直し、必要に応じて新インデックスへ移行 |
| チャンク化していない通常インデックス | フィールドマッピングとクエリ時認証を重点確認 |
| チャンク化済みのベクトルインデックス | 各チャンク行へラベルを投影できているかを最優先で確認 |
チャンク化されたRAGインデックスではラベル投影が必須
RAG構成では、1つの文書を複数のチャンクに分割してベクトル化することが一般的です。このとき、親文書に秘密度ラベルがあっても、子チャンクにラベルが引き継がれていなければ、検索時の制御やラベル表示が期待どおりに動きません。
Microsoft Learnでは、Text Split skillや統合ベクトル化などでチャンクを作る場合、index projectionsを使って秘密度ラベルを各チャンクへ投影する必要があると説明されています。投影がない場合、子チャンク行が正しくフィルターされず、agentic retrievalの応答でもチャンクごとのsensitivityLabelInfoを含められません。(Microsoft Learn)
確認すべきポイントは、次の3つです。
| 確認箇所 | 見るべき内容 |
|---|---|
| skillset | Text Split skillや統合ベクトル化で親文書を分割しているか |
| index projections | sensitivityLabelを親文書からチャンク行へマッピングしているか |
| 検索応答 | チャンク単位の参照にsensitivityLabelInfoが出るか |
チャンク化されたRAGでは、「本文は分割したが権限情報は親に置いたまま」という設計がよく起きます。これは検索品質の問題ではなく、セキュリティ設計の問題として扱うべきです。
クエリ時の認証はAPIキー中心からRBAC中心へ見直す
Microsoft Purview秘密度ラベルを使ったクエリ時制御では、アプリケーションの権限だけでなく、実際に検索しているユーザーの文脈が必要です。
Microsoft Learnでは、クエリ時にAzure AI Searchが次の2つを検証すると説明されています。
| 入力 | 役割 |
|---|---|
Authorization: Bearer <app-token> | 呼び出し元アプリがインデックスへクエリできるかを判断 |
x-ms-query-source-authorization: <user-token> | エンドユーザーが秘密度ラベル付きコンテンツを閲覧できるかを判断 |
ユーザートークンはx-ms-query-source-authorizationヘッダーに渡します。ドキュメントの例では、このヘッダーにはBearerプレフィックスを付けず、生のトークン値を渡す形が示されています。(Microsoft Learn)
POST {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2025-11-01-preview
Authorization: Bearer {{app-query-token}}
x-ms-query-source-authorization: {{user-query-token}}
Content-Type: application/json
{
"search": "*",
"select": "title,summary,sensitivityLabel"
}既存のRAGアプリがAPIキーだけでAzure AI Searchを呼び出している場合、このままではユーザー別のラベル制御を正しく表現できません。アプリ側では、Microsoft Entra IDでサインインしたユーザーのトークンを取得し、検索リクエストに渡す設計へ移行する必要があります。
また、Purview秘密度ラベルが有効なインデックスでは、APIキーアクセスはインデックススキーマ取得に制限され、ドキュメント操作ではRBAC認証が必要とされています。(Microsoft Learn)
retrieve応答のラベル情報をUIとポリシーに活用する
knowledge baseやMCP経由で取得する場合、返ってくるラベル情報はUI設計にも関係します。
たとえば、参照文書ごとのsensitivityLabelInfoを使えば、回答の根拠に「Confidential」などのラベルを表示できます。応答全体のmetadata.responseSensitivityLabelInfoを使えば、回答ブロック全体に秘密度バナーを出したり、コピーや共有などの操作を抑制する判断材料にできます。Microsoft Learnでも、metadata.responseSensitivityLabelInfoを応答レベルのバナー表示やポリシー制御に使うことが推奨されています。(Microsoft Learn)
ただし、ラベルIDが返るだけで、すべての保護ポリシーを自動的にUIへ反映できるわけではありません。ラベル名、説明、ポリシー制御、権限などの追加情報が必要な場合は、Microsoft Graphのsensitivity label APIなどでラベル定義を解決する設計が必要です。(Microsoft Learn)
実装時は、最低限次の動作を決めておくとよいでしょう。
| UI・アプリの論点 | 推奨設計 |
|---|---|
| 回答に複数ラベルの文書が混在する | 最も高い秘密度を応答全体の扱いに採用する |
| ラベルIDはあるが表示名が未取得 | 「機密ラベル付きコンテンツ」などの安全側の表示に倒す |
| ユーザーがコピー・共有しようとする | responseSensitivityLabelInfoを見て制限可否を判定する |
| ログに回答本文を保存する | ラベル付き回答のログ保存可否を別途ポリシー化する |
| 外部ツールへ回答を渡す | ラベル付き応答は転送先の境界と監査要件を確認する |
AI検索では、根拠文書だけでなく「生成された回答」も情報資産になります。UIにラベル名を出すだけで満足せず、保存、コピー、共有、外部送信、監査ログの扱いまで設計してください。
展開前に確認すべき制限事項
Public Previewの段階では、制限事項を把握したうえで検証範囲を決めることが重要です。
| 制限・注意点 | 実務上の意味 |
|---|---|
| 本番ワークロードには慎重な検証が必要 | プレビュー機能のため、PoCや限定部門での検証から始める |
| Azure portalだけでは完結しない可能性がある | REST APIまたはSDKでの作成・確認手順を用意する |
| ゲストアカウント・クロステナントクエリは非対応 | 外部協力会社やB2Bゲストを含む検索体験では別設計が必要 |
| Autocomplete / Suggest APIは非対応 | 検索候補機能にラベル付き文書を混ぜない設計が必要 |
| ラベル変更は次回の正常なインデクサー実行まで反映されない | 緊急の権限変更を即時反映できると考えない |
| 一部のインデクサー機能はラベル付き文書に非対応 | Custom Web API skill、GenAI Prompt skill、Knowledge store、enrichment cache、Debug sessionsを使う既存skillsetは要確認 |
| Purview評価に失敗した場合は5xxになる場合がある | ラベル評価不可時に未フィルター結果を返す設計にしない |
Microsoft Learnでは、ゲストアカウントやクロステナントクエリ、Autocomplete / Suggest API、ユーザー割り当てマネージドID、特定のインデクサー機能に関する制限が示されています。また、ラベル変更は次回の成功したインデクサー実行までインデックスへ反映されない点も明記されています。(Microsoft Learn)
移行時に失敗しやすいポイント
ラベルを付ければ自動で安全になると思い込む
Microsoft Purviewで文書に秘密度ラベルを付けても、それだけでAzure AI SearchのRAGアプリが自動的に安全になるわけではありません。ラベルを取り込む設定、ラベルフィールド、インデクサー、クエリ時のユーザートークン、UI側の扱いがそろって初めて意味があります。
特に既存RAGでは、次のような状態が起きがちです。
| よくある状態 | 問題 |
|---|---|
| 文書にはラベルがあるが、インデックスにラベルフィールドがない | 検索時にラベルを評価できない |
| インデックスにラベルはあるが、チャンクに投影していない | チャンク単位の取得制御やラベル表示が崩れる |
| アプリがAPIキーだけで検索している | ユーザー別のアクセス可否を評価できない |
| UIにラベルを出すだけで、コピーや共有を制御していない | 回答文から情報が広がる可能性が残る |
既存インデックスをそのまま使える前提で進める
purviewEnabledはインデックス作成時に設定する必要があり、後から変更できない恒久設定です。既存インデックスを本格的にPurview対応へ移す場合は、再インデックスや切り替え期間の設計が必要になります。(Microsoft Learn)
移行時は、いきなり既存インデックスを置き換えるのではなく、次のような段階移行が現実的です。
| フェーズ | 作業 |
|---|---|
| 現状棚卸し | データソース、knowledge source、インデックス、skillset、アプリの認証方式を確認 |
| 検証用インデックス作成 | purviewEnabledを有効にした新インデックスを作成 |
| 限定データで再取り込み | ラベル付き文書とラベルなし文書を混ぜてインジェスト |
| ユーザー別テスト | 閲覧可能ユーザーと不可ユーザーで検索結果を比較 |
| UI検証 | sensitivityLabelInfoとresponseSensitivityLabelInfoの表示・制御を確認 |
| 本番移行判断 | 制限事項、監査要件、障害時動作を確認して段階展開 |
ラベル変更の反映タイミングを運用に入れていない
秘密度ラベルは、文書の作成後に変更されることがあります。たとえば、社内資料として作成した文書を「機密」に引き上げる、退職者や外部協力会社が関係する文書のアクセス条件を見直す、といったケースです。
Azure AI Searchでは、ラベル変更がインデックスに反映されるのは次回の正常なインデクサー実行後です。インデクサーのスケジュール設計、手動再実行の手順、緊急時の公開停止手順を用意しておかないと、「Purviewでは制限したのにAI検索にはしばらく残る」という運用ギャップが生まれます。(Microsoft Learn)
管理者向けチェックリスト
展開前に、次のチェックリストを使って確認してください。
| チェック | 確認内容 |
|---|---|
| 対象データの特定 | Blob、ADLS Gen2、OneLake、SharePoint、既存search indexのどれか |
| ラベル運用 | Microsoft Purviewの秘密度ラベルとポリシーが本番運用されているか |
| テナント条件 | Azure AI Searchサービスと検索ユーザーが同一Microsoft Entraテナントにいるか |
| マネージドID | Azure AI Searchにシステム割り当てマネージドIDがあるか |
| Purview権限 | 管理者承認のもとで必要なPurview関連権限を付与できるか |
| インデックス | purviewEnabledを有効にした新規インデックスが必要か |
| knowledge source | ingestionPermissionOptionsにsensitivityLabelを指定して作成するか |
| チャンク投影 | Text Split skillや統合ベクトル化で各チャンクにラベルを投影しているか |
| クエリ認証 | APIキーではなくRBACとx-ms-query-source-authorizationを使えるか |
| UI制御 | ラベル情報を表示・コピー制御・共有制御・ログ方針に反映するか |
| 障害時動作 | Purview評価失敗時やインデクサー失敗時の扱いを決めているか |
| 監査 | 管理者調査や elevated read の利用条件を決めているか |
開発者向けテスト観点
検証では「検索できるか」だけでなく、「検索できてはいけない文書が出ないか」を重点的に見ます。
| テストケース | 期待結果 |
|---|---|
| ラベルなし文書を検索 | 通常どおり取得できる |
| ユーザーAが閲覧可能なラベル付き文書を検索 | 結果に表示され、参照にsensitivityLabelInfoが含まれる |
| ユーザーBが閲覧不可のラベル付き文書を検索 | 結果に表示されない |
| 同じ質問をユーザーA・Bで実行 | 回答内容と参照文書が権限に応じて変わる |
| チャンク化文書を検索 | 各チャンク参照にラベル情報が付き、権限に応じて除外される |
x-ms-query-source-authorizationなしで検索 | エンドユーザー向け動作として採用しない |
| Purviewやインデクサーの一時失敗 | 未フィルター結果を返さず、安全側に倒れる |
| ラベル変更後に検索 | 次回インデクサー実行後に結果が変わることを確認 |
特にRAGアプリでは、回答本文だけを見て成功判定しないでください。参照文書、ラベル情報、検索アクティビティ、ユーザー別の差分まで確認する必要があります。
今すぐ試すべき組織、様子を見るべき組織
このPublic Previewは、すべての組織がすぐ採用すべき機能ではありません。向いているケースと、まだ慎重にすべきケースを分けて判断しましょう。
| 判断 | 該当する組織 |
|---|---|
| 早めに検証すべき | Microsoft Purview秘密度ラベルをすでに運用している |
| 早めに検証すべき | SharePoint、OneLake、Blob、ADLS Gen2の社内文書をRAGやエージェントで使っている |
| 早めに検証すべき | Foundry Agent ServiceやCopilot向けにknowledge baseを整備している |
| 早めに検証すべき | AI回答に機密情報が混ざるリスクを管理部門から指摘されている |
| 慎重に待つべき | 本番SLAが必須で、Preview機能を採用できない |
| 慎重に待つべき | ゲストユーザーやクロステナント利用が中心 |
| 慎重に待つべき | Autocomplete / Suggestを重要な検索体験として使っている |
| 慎重に待つべき | APIキー前提の既存アプリをすぐ変更できない |
| 慎重に待つべき | ラベル変更の即時反映が必須 |
判断の軸は、「便利になるか」ではなく「現在のAI検索で、秘密度ラベル付き文書がどの程度リスクになっているか」です。機密文書をRAGに入れているなら、早期検証の価値は高いでしょう。一方、プレビュー機能を本番統制に組み込めない組織では、まず検証環境で設計パターンを固めるのが現実的です。
次に取るべき行動
まずは、既存のRAG・エージェント構成を棚卸ししてください。見るべき対象は、データソース、knowledge source、インデックス、skillset、認証方式、UIでのラベル表示、ログ保存先です。
そのうえで、次の順序で進めると失敗しにくくなります。
| 順序 | やること |
|---|---|
| 1 | Microsoft Purviewでラベルとポリシーが正しく運用されているか確認する |
| 2 | 対象データソースがBlob、ADLS Gen2、OneLake、indexed SharePoint、既存search indexのどれかを分類する |
| 3 | 検証用にpurviewEnabledを有効化した新規インデックスまたはknowledge sourceを用意する |
| 4 | ingestionPermissionOptionsにsensitivityLabelを指定してラベル付き文書を取り込む |
| 5 | チャンク化している場合は、各チャンクに秘密度ラベルが投影されることを確認する |
| 6 | RBACとx-ms-query-source-authorizationを使ってユーザー別に検索結果を検証する |
| 7 | sensitivityLabelInfoとresponseSensitivityLabelInfoをUI、監査、操作制御にどう使うか決める |
| 8 | インデクサー実行間隔、ラベル変更時の反映、障害時の安全側動作を運用手順に落とし込む |
Microsoft Purviewの秘密度ラベルをAzure AI Searchのknowledge sourcesへ流せるようになることで、AI検索のセキュリティ設計は一段実務的になります。一方で、ラベル、インデックス、チャンク、認証、UI、監査のどれかが欠けると、期待した保護にはなりません。
まずは小さなラベル付き文書セットで、許可ユーザーと非許可ユーザーの検索結果がどう変わるかを確認してください。その結果をもとに、既存RAGやFoundryエージェントへの段階展開を検討するのが安全です。
コメント