Microsoft Purview 管理者アクセス監査は、Azure AI Search や Foundry IQ のナレッジベースに取り込んだ「秘密度ラベル付きコンテンツ」へ、管理調査目的でアクセスした履歴を Microsoft Purview の監査ログに残すための更新です。結論から言うと、Azure AI Search で Purview ラベル付き文書を検索・RAG・エージェントのナレッジソースに使っている組織は、RBAC 認証、Purview ラベルの取り込み、elevated read の利用権限、監査ログの検索権限を早めに確認すべきです。今回の機能はパブリックプレビューであり、公式更新では Azure AI Search に Microsoft Purview admin access auditing が追加されたことが示されています。(Microsoft Azure)
この更新で重要なのは、「通常ユーザーの検索結果を制御する機能」ではなく、管理者や開発者が調査目的でラベル付きドキュメントへ特権的にアクセスした場合に、そのアクセスを監査できるようにする点です。情報漏えい調査、eDiscovery、コンプライアンスレビュー、RAG アプリの検証などで、誰がどのラベル付きコンテンツに触れたのかを後から追跡しやすくなります。
Microsoft Purviewの管理者アクセス監査で変わること
今回の「Public Preview: Purview admin access auditing for sensitivity-labeled content in Azure AI Search」は、Azure AI Search の Purview 対応インデックスやナレッジ取得経路で、管理者特権の読み取りを監査対象にする更新です。
Azure AI Search では、Purview の秘密度ラベルをインデックスに取り込み、クエリ時にラベルポリシーを評価して、ユーザーがアクセスできるドキュメントだけを返す構成が可能です。今回の管理者アクセス監査は、その通常制御に加えて、管理調査用の elevated read を使ったアクセスを Purview 監査ログに出力するものです。(Microsoft Learn)
| 観点 | これまで意識すべきだったこと | 今回の更新で追加される確認ポイント |
|---|---|---|
| 通常ユーザーの検索 | ユーザー ID と Purview ラベルポリシーに基づき、検索結果を制御する | 引き続きユーザーコンテキストを正しく渡す必要がある |
| 管理調査 | 管理者が調査目的で通常権限を超えて確認する場面がある | elevated read によるアクセスを Purview 監査ログで追跡する |
| RAG・エージェント | Azure AI Search や Foundry IQ のナレッジソースに機密文書が入る | retrieve、MCP、Foundry IQ ナレッジベース経由のラベル付きコンテンツも考慮する |
| 監査対応 | Microsoft Purview Audit で各種アクティビティを検索する | Azure AI Search レコードタイプやラベル名、ソース ID で調査できるようにする |
特に大きいのは、管理者特権で読み取った場合に、返されたドキュメントごとに監査エントリが出力される点です。公式ドキュメントでは、N 件のドキュメントを返す 1 回の検索要求に対して、N 件の監査エントリが生成されると説明されています。監査エントリは検索応答後に非同期で Purview にアップロードされます。(Microsoft Learn)
通常の検索制御とelevated readの違い
通常のクエリと elevated read を混同すると、設計ミスにつながります。通常の検索は「ユーザーが見てよいものだけを返す」ための制御です。一方、elevated read は「管理調査のために通常は見えないラベル付きドキュメントも返し、そのアクセスを監査する」ための仕組みです。
| 種類 | 主な用途 | 必要な考え方 |
|---|---|---|
| 通常クエリ | 社内検索、チャットボット、RAG アプリ、エージェントの通常利用 | エンドユーザーのトークンを渡し、ユーザーが許可された文書だけを返す |
| elevated read | インシデント対応、監査、eDiscovery、コンプライアンスレビュー、開発時の管理調査 | 権限を限定し、利用理由を社内ログやチケットで残し、Purview Audit で確認する |
通常クエリでは、アプリケーションの認証に加えて、x-ms-query-source-authorization ヘッダーでエンドユーザーのトークンを渡します。Azure AI Search は、アプリ側の RBAC ロールとユーザー ID の両方を確認し、Purview ラベルポリシーに基づいて結果をフィルターします。(Microsoft Learn)
POST https://<search-service>.search.windows.net/indexes/<index-name>/docs/search?api-version=2025-11-01-preview
Authorization: Bearer <app-query-token>
x-ms-query-source-authorization: <user-query-token>
Content-Type: application/jsonelevated read では、x-ms-enable-elevated-read: true を指定します。この場合、ラベルベースのアクセスチェックをスキップして一致するドキュメントを返し、返された各ドキュメントについて Microsoft Purview 監査ログにエントリを出力します。ただし、elevated read を使うには 2026-05-01-preview 以降の API が必要で、呼び出し元ユーザーには Search Index Data Contributor ロールが必要です。Search Index Data Reader では不十分です。(Microsoft Learn)
POST https://<search-service>.search.windows.net/indexes/<index-name>/docs/search?api-version=2026-05-01-preview
Authorization: Bearer <contributor-token>
x-ms-enable-elevated-read: true
Content-Type: application/jsonなお、x-ms-enable-elevated-read を true にした場合、x-ms-query-source-authorization ヘッダーは使用できません。つまり、「通常ユーザーの代理」と「管理者特権の読み取り」は明確に分けて実装する必要があります。(Microsoft Learn)
影響範囲：Azure AI SearchだけでなくFoundry IQも確認する
この更新の影響は、Azure AI Search の検索 API だけに閉じません。Azure AI Search を基盤にしたナレッジベース、knowledge retrieval、MCP エンドポイント、Foundry IQ のナレッジベースを使っている場合も確認対象です。Microsoft Learn では、Azure AI Search を直接呼び出す場合だけでなく、ナレッジベースの retrieve アクションや MCP エンドポイントを通じてラベル付きコンテンツを利用する場合にも、管理者特権読み取りと Purview 監査ログが適用されると説明されています。(Microsoft Learn)
| 確認対象 | 影響の有無 | 管理者・開発者が見るポイント |
|---|---|---|
| Azure AI Search の Purview 対応インデックス | 高 | purviewEnabled、RBAC、API バージョン、監査ログ |
| Azure AI Search を使った社内検索 | 高 | ユーザートークンを渡しているか、API キー依存が残っていないか |
| RAG アプリ | 高 | 検索結果や引用元に秘密度ラベル情報を反映できるか |
| Foundry IQ ナレッジベース | 高 | ナレッジソースの権限メタデータ、retrieve 経路、監査ログ |
| MCP 対応クライアント | 中〜高 | sensitivityLabelInfo を使って表示・制御できるか |
| Purview ラベルを使っていない検索インデックス | 低 | すぐに影響は小さいが、将来の機密データ取り込み時に設計が必要 |
Azure AI Search で Purview 秘密度ラベルの取り込み対象となるデータソースには、Azure Blob Storage、Azure Data Lake Storage Gen2、Microsoft 365 の SharePoint、Microsoft OneLake が含まれます。ただし一部はプレビュー扱いであり、対応状況や制限はサービス更新に合わせて確認が必要です。(Microsoft Learn)
管理者が確認すべきMicrosoft Purview側の設定
まず確認すべきは、Microsoft Purview Audit が有効で、監査ログを検索できる管理者が適切に割り当てられているかです。Microsoft 365 の監査ログ検索はエンタープライズ組織では既定で有効とされていますが、新規テナントや SMB ライセンス、試用環境では手動確認が必要な場合があります。(Microsoft Learn)
監査ログが有効か確認する
Exchange Online PowerShell で次を実行します。
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabledTrue であれば監査ログ検索が有効です。False の場合は、Microsoft Purview ポータルまたは Exchange Online PowerShell で有効化します。Microsoft のドキュメントでは、有効化後に検索結果が返るまで時間がかかる場合があるとされています。(Microsoft Learn)
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true監査ログを検索できるロールを確認する
Purview 監査ログを検索するには、Microsoft Purview ポータルで Audit Logs または View-Only Audit Logs ロールが必要です。監査ログの検索権限は強い権限なので、全体管理者に広く付けるのではなく、セキュリティ運用、監査、コンプライアンス担当者に限定するのが現実的です。(Microsoft Learn)
保持期間を確認する
監査ログの保持期間はライセンスや保持ポリシーに依存します。Microsoft Learn では、E5 などの対象ライセンスでは一部の監査レコードが既定で 1 年保持され、それ以外の多くのライセンスでは 180 日保持されると説明されています。インシデント調査や法務対応で 180 日を超える証跡が必要な組織は、Purview Audit の保持ポリシーも合わせて見直してください。(Microsoft Learn)
Azure AI Search側で確認すべき設定
Purview 管理者アクセス監査を正しく使うには、Azure AI Search 側の前提設定が重要です。単に Purview の監査ログを有効にするだけでは不十分です。
| 設定項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| マネージド ID | Azure AI Search サービスのシステム割り当てマネージド IDを有効にする | ユーザー割り当てマネージド ID で進めようとして詰まる |
| RBAC | Search Index Data Reader / Contributor などのロールを用途別に割り当てる | API キー前提の既存アプリがそのまま残る |
| Purview API への権限 | ラベルとポリシーを取得するための権限を付与する | セキュリティ部門の承認なしに高権限を付けてしまう |
purviewEnabled | インデックス作成時に true にする | 後から変更できると思って既存インデックスを流用する |
| データソース設定 | indexerPermissionOptions に sensitivityLabel を含める | 権限メタデータが取り込まれず、期待した制御にならない |
| チャンク分割 | チャンク行にも秘密度ラベルを投影する | RAG 用の子チャンクでラベルが欠落する |
Microsoft Learn では、purviewEnabled はインデックス作成時に true に設定する必要があり、後から変更できないと明記されています。また、purviewEnabled が true の場合、ドキュメント操作 API は RBAC 認証のみをサポートし、API キーのアクセスはインデックススキーマの取得に制限されます。(Microsoft Learn)
これは移行時に大きな影響があります。既存の Azure AI Search インデックスを API キーで更新・検索しているアプリでは、Purview 対応インデックスへ移行する前に認証方式を RBAC ベースへ切り替える必要があります。
開発者が実装時に見るべきポイント
開発者が最も注意すべきなのは、通常検索と管理者調査用検索を同じコードパスに混ぜないことです。通常検索はユーザーコンテキストを渡し、管理者調査は elevated read として明示的に扱います。
| 実装シーン | 正しい実装 | 避けるべき実装 |
|---|---|---|
| 社内検索画面 | サインインユーザーのトークンを x-ms-query-source-authorization で渡す | アプリ権限だけで全ユーザーに同じ結果を返す |
| RAG アプリ | 検索・retrieve の結果に含まれるラベル情報を UI や引用表示に反映する | 回答本文だけ表示し、ラベルや引用元を隠す |
| 管理調査画面 | elevated read を専用機能に分離し、利用者を限定する | 通常検索のオプションとして誰でも有効化できる |
| テスト自動化 | アクセス可能ユーザー、不可ユーザー、elevated read を分けて検証する | 管理者アカウントだけで動作確認して本番投入する |
| ログ連携 | Purview Audit と自社アプリログの時刻・ユーザー・チケット番号を突き合わせる | Purview 側の非同期反映だけを前提に即時検知を設計する |
Foundry IQ や retrieve アクションを使う場合、応答には参照ごとの sensitivityLabelInfo と、応答全体の代表ラベルである metadata.responseSensitivityLabelInfo が含まれる場合があります。これらは、回答画面に「Confidential」などのラベルバナーを出したり、コピー・共有などの操作制御を判断したりする材料になります。(Microsoft Learn)
特に RAG アプリでは、検索結果の本文だけでなく「どのラベルの文書を根拠に回答したか」を利用者に示す設計が重要です。たとえば、回答の引用元に Confidential ラベルが含まれる場合、回答全体にも機密性の高い扱いを適用する必要があります。
Purview監査ログで確認できる主な情報
elevated read によって出力される監査エントリには、標準スキーマの情報に加え、Azure AI Search 固有のフィールドが含まれます。公式ドキュメントでは、CreationTime、Operation、OrganizationId、RecordType、UserPrincipalName、ClientIP などの標準フィールドに加え、DocumentDataSourceType、DocumentDataSourceId、SensitivityLabelName などが示されています。(Microsoft Learn)
| フィールド | 確認できること | 調査での使い方 |
|---|---|---|
UserPrincipalName | 誰が要求したか | 管理者・開発者・サービス運用者の特定 |
ClientIP | どこから要求されたか | 想定外ネットワークからのアクセス確認 |
DocumentDataSourceType | 元データの種類 | Azure Blob、SharePoint、OneLake などの切り分け |
DocumentDataSourceId | アクセスされた元文書の識別子 | 対象文書の特定 |
SensitivityLabelName | 適用されていた秘密度ラベル | Confidential、Highly Confidential などの影響度判断 |
RecordType | Azure AI Search の監査レコード種別 | Purview Audit Search での絞り込み |
Microsoft Purview ポータルでは、Audit Search から日付範囲、ユーザー、Azure AI Search のレコードタイプなどで絞り込み、該当エントリを開いてカスタムフィールドを確認します。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
既存インデックスに後からpurviewEnabledを付けられない
purviewEnabled はインデックス作成時に設定する必要があり、後から変更できません。既存インデックスをそのまま拡張する前提で計画すると、移行直前に作り直しが必要になります。安全に進めるなら、新しい Purview 対応インデックスを作成し、データ取り込み、検索結果、権限評価、監査ログを検証してから切り替えるべきです。(Microsoft Learn)
APIキー依存のアプリが動かなくなる可能性がある
Purview 対応インデックスでは、コンテンツ関連の操作に RBAC 認証が必要です。API キーはスキーマ取得に制限されるため、既存のバッチ処理、管理ツール、検索画面、インデクサー関連スクリプトが API キー前提の場合は見直しが必要です。(Microsoft Learn)
ラベル変更が即時反映されるとは限らない
ソース文書の秘密度ラベルを変更しても、次回のインデクサー実行までインデックスに反映されない場合があります。Microsoft Learn でも、前回のインデクサー実行時点のラベルが評価対象であり、最近のラベル変更は次回の再インデックスまで反映されない場合があると説明されています。(Microsoft Learn)
チャンク化したRAGインデックスでラベルが抜ける
統合ベクター化やテキスト分割スキルで文書をチャンク化する場合、親文書の秘密度ラベルを子チャンクにも投影する必要があります。このマッピングがないと、チャンクレベルの参照やクエリ時フィルターが正しく機能しません。RAG アプリでは特に見落としやすいポイントです。(Microsoft Learn)
AutocompleteやSuggestは前提にしない
Purview 対応インデックスでは、Autocomplete API と Suggest API がサポートされない制限があります。既存の検索 UI で入力補完や候補表示を使っている場合、Purview 対応インデックスに切り替えると同じ体験を維持できない可能性があります。(Microsoft Learn)
Purview側に到達できない時の挙動を考慮する
ラベル評価や監査ログ出力ができない場合、Azure AI Search は部分的または未フィルターの結果を返すのではなく、5xx を返すケースがあります。elevated read では、監査ログを出力できない限りラベル付きドキュメントを返さないと説明されています。アプリ側で 5xx を受けたときに、安易に別経路で未制御の検索を実行する設計は避けるべきです。(Microsoft Learn)
展開前の実務チェックリスト
本番に近い環境へ展開する前に、次の順番で確認すると手戻りを減らせます。
| 順番 | 確認項目 | 完了条件 |
| -: | —————– | ————————————————————————- |
| 1 | 対象データの棚卸し | Azure AI Search に取り込む文書のうち、Purview ラベル付き文書を把握している |
| 2 | インデックス移行設計 | purviewEnabled を前提に新規インデックス作成・切り替え手順を決めている |
| 3 | 認証方式の確認 | API キー依存を洗い出し、RBAC 認証へ移行できる |
| 4 | Purview 権限付与 | マネージド ID、ラベル取得権限、内部承認プロセスを整理している |
| 5 | 通常検索の検証 | 権限のあるユーザーだけが対象文書を取得できる |
| 6 | 権限なしユーザーの検証 | ラベル付き文書が検索結果から除外される |
| 7 | elevated read の検証 | 管理調査用の結果が返り、Purview Audit に記録される |
| 8 | 監査ログ運用 | Audit Search、必要に応じて Office 365 Management Activity API や SIEM 連携の方針を決めている |
| 9 | UI 表示 | 回答、引用元、ラベルバナー、共有制御の扱いを決めている |
| 10 | 障害時対応 | Purview 到達不可や 5xx 発生時のユーザー表示・再試行方針を決めている |
監査ログは即時に検索結果へ出るとは限りません。Microsoft Learn では、監査レコードが検索結果に返るまでの時間を保証しておらず、サービスによっては時間がかかる場合があると説明されています。運用設計では「数分で必ず検知できる」前提ではなく、Purview Audit、自社アプリログ、ネットワークログ、チケット管理を組み合わせて追跡できるようにしておくと安全です。(Microsoft Learn)
優先して対応すべき組織
すべての組織が同じ緊急度で対応する必要はありません。優先度は、Azure AI Search に機密データを入れているか、Purview ラベルを運用しているか、AI エージェントや RAG で検索結果を再利用しているかで判断します。
| 優先度 | 該当する組織 | 取るべき対応 |
|---|---|---|
| 高 | Purview ラベル付きの SharePoint、Blob、OneLake 文書を Azure AI Search や Foundry IQ で使っている | すぐに検証環境で設定・監査ログ・移行手順を確認する |
| 高 | 金融、医療、製造、公共など、監査証跡が求められる業務で RAG を使う | elevated read の利用者、承認フロー、監査手順を文書化する |
| 中 | Azure AI Search は使っているが、まだ秘密度ラベルを取り込んでいない | 将来の Purview 対応を見越して RBAC 化とインデックス再作成方針を検討する |
| 中 | Foundry IQ や MCP を試験導入している | retrieve 経路でユーザーコンテキストとラベル情報が扱えるか確認する |
| 低 | 公開情報だけを検索対象にしている | 直近の影響は小さいが、機密文書を追加する前に設計を見直す |
まず何をすべきか
最初に行うべきことは、Azure AI Search に入っているデータと Purview 秘密度ラベルの関係を棚卸しすることです。次に、既存インデックスを Purview 対応に作り直す必要があるか、API キー依存が残っていないか、管理者調査用に elevated read を誰へ許可するかを決めます。
今回の Microsoft Purview 管理者アクセス監査は、AI 検索や RAG の利便性を高める機能というより、機密データを AI 検索基盤に載せるための説明責任を強化する機能です。通常ユーザーには最小権限で検索させ、管理者には必要な調査権限を与え、その代わりにアクセス証跡を Purview Audit に残す。この分離ができていれば、Azure AI Search や Foundry IQ を使ったエンタープライズ AI の展開を、セキュリティ部門や監査部門に説明しやすくなります。
パブリックプレビューの段階では、まず非本番環境で API バージョン、RBAC、監査ログ、ラベル変更時の反映、障害時の挙動を検証してください。そのうえで、本番展開時には「誰が elevated read を使えるのか」「何の目的で使ったのか」「どのログで確認するのか」を運用ルールとして明文化することが重要です。
コメント