Note
Azure AI 検索は、Azure ポータル、REST API、およびAzure SDKから使用できます。 また、Foundry IQ は、エンタープライズ コンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジ ベースに変換するマネージド ナレッジ レイヤーです。
Important
これらの機能は、2026-05-01-preview REST API の一部です。 2026-05-01-preview は、お客様の Azure サブスクリプションの一部としてお客様にライセンス供与されるものであり、Microsoft Product Terms における「Previews」に適用される条件、Microsoft Products and Services Data Protection Addendum（「DPA」）、および Supplemental Terms of Use for Microsoft Azure Previews に従うものとします。
2026-05-01-preview では、他のMicrosoft サービスやサード パーティのサービスへの接続がサポートされています。 これらのサービスの利用は各サービスの利用規約に従うものとし、データが Azure コンプライアンス境界の外部で処理または保存されたり、Azure コンプライアンス境界内に流入したりする場合があります。
2026-05-01-preview では、2026-05-01-preview 以外で設定されたアクセス許可を変更することはできません。 アクセスが制限されたコンテンツまたはアクセス許可が制限されたコンテンツで 2026-05-01-preview を使用する場合、2026-05-01-preview がそれらのアクセスまたはアクセス許可の制限に対する変更を認識する前にタイミング ラグが発生します。
データが組織のコンプライアンスと地理的境界の外部に流れるかどうか、および関連する影響があるかどうか、および適切なアクセス許可、境界、承認がプロビジョニングされるかどうかを管理するのは、お客様の責任です。
特定のユース ケースのコンテキストで構築したアプリケーションを慎重に確認およびテストし、すべての適切な決定とカスタマイズを行う責任があります。 この責任には、メタプロンプト、コンテンツ フィルター、その他の安全システムなどの独自の責任ある AI 軽減策を実装し、アプリケーションが適切な品質、信頼性、セキュリティ、信頼性の標準を満たしていることを確認する必要があります。 詳細については、「Azure AI 検索透過性に関するメモを参照してください。
Azure AI 検索では、ドキュメント レベルのアクセス制御がサポートされており、組織はデータ インジェストからクエリ実行まで、ドキュメント レベルできめ細かいアクセス許可を適用できます。 この機能は、セキュリティで保護された AI エージェント システムを構築し、データを接地し、取得拡張生成 (RAG) アプリケーション、およびドキュメント レベルで承認チェックを必要とするエンタープライズ検索ソリューションを構築するために不可欠です。
ドキュメント レベルのアクセス制御のアプローチ
Azure AI 検索には、ドキュメント レベルのアクセス許可を適用するための 4 つの主要なアプローチが用意されています。それぞれ異なるデータ ソースと ID モデルに適しています。
| アプローチ | 説明 |
|---|---|
| セキュリティ フィルター | 文字列の比較。 アプリケーションは、ユーザーまたはグループ ID を文字列として渡します。この ID は、文字列に一致しないドキュメントを除き、クエリにフィルターを設定します。 セキュリティ フィルターは、ドキュメント レベルのアクセス制御を実現するための手法です。 この方法は API にバインドされていないため、任意のバージョンまたはパッケージを使用できます。 |
| POSIX に似た ACL/RBAC スコープ (プレビュー) | クエリ トークンの背後にあるMicrosoft Entraセキュリティ プリンシパルは、検索結果に返されるドキュメントのアクセス許可メタデータと比較されます。ただし、アクセス許可に一致しないドキュメントは除きます。 アクセス制御リスト (ACL) のアクセス許可は、Azure Data Lake Storage (ADLS) Gen2 のディレクトリとファイルに適用されます。 ロールベースのアクセス制御 (RBAC) スコープは、ADLS Gen2 コンテンツとAzure BLOB に適用されます。 ドキュメント レベルでの ID ベースのアクセスに対する組み込みのサポートはプレビュー段階であり、REST API とプレビュー機能を提供するAzure SDK パッケージで利用できます。 機能のサポートの証拠については、 SDK バージョンのサポートの詳細を確認してください。 |
| Microsoft Purview 秘密度ラベル (プレビュー) | インデクサーは、サポートされているデータ ソース (Azure Blob Storage、ADLS Gen2、Microsoft 365、OneLake のSharePoint) から、Microsoft Purviewで定義されている秘密度ラベルを抽出します。 これらのラベルはメタデータとして保存され、クエリ時に評価され、Microsoft Entra トークンと Purview ポリシーの割り当てに基づいてユーザー アクセスが適用されます。 また、ラベルは ナレッジ ソース と エージェント検索応答によって表示されるため、ナレッジ ベースを使用する AI エージェントとチャット アプリは、同じラベル対応のフィルター処理を受け取ります。 このアプローチは、Azure AI 検索承認を企業のMicrosoft Information Protection モデルに合わせて調整します。 |
| Microsoft 365 ACL のSharePoint (プレビュー) | Azure AI 検索インデクサーは、サポートされているSharePointコンテンツからアクセス許可メタデータを抽出し、クエリ時のアクセス チェックに使用します。 サポートされているコンテンツ、プリンシパル、グループリレーションシップ、同期動作、およびアクセス許可については、「SharePoint インデクサーを使用してアクセス許可メタデータを取り込む」を参照してください。 |
アプローチを選択する
次の条件を使用して、データ ソース、ID モデル、およびコンプライアンス要件に最適なアプローチを特定します。
| Scenario | 推奨される方法 | なぜでしょうか |
|---|---|---|
| カスタム ID システム、Microsoft以外のセキュリティ フレームワーク、または任意のプッシュ モデル インデックス。 | セキュリティ フィルター | API に依存せず、一般公開されており、単純な文字列照合に基づいています。 |
| 既存の ACL または RBAC 割り当てを使用した ADLS Gen2 またはAzure Blob Storageのコンテンツ。 | POSIX に似た ACL/RBAC スコープ | ネイティブMicrosoft Entra統合。クエリ時の強制では、ドキュメント化された同期メカニズムによってインデックスに書き込まれたアクセス許可メタデータが使用されます。 |
| Microsoft Purview情報保護ポリシーによって既に管理されているエンタープライズ コンテンツ。 | Microsoft Purview 機密ラベル | Azure AI 検索全体で一元化された分類とポリシーの割り当てを再利用します。 |
| Microsoft 365 (ライブラリ、リスト、ASPX サイト ページ) のSharePointからソースを取得したコンテンツ。 | Microsoft 365 ACL のSharePoint | SharePoint サイト グループを含む、SharePoint のネイティブのアクセス許可を尊重します。 |
フィルターを使用したセキュリティ トリミングのパターン
ネイティブ ACL/RBAC スコープの統合が実行できないシナリオでは、セキュリティ文字列フィルターを使用して、除外条件に基づいて結果をトリミングします。 このパターンには、次のコンポーネントが含まれています。
- ユーザー ID またはグループ ID を格納するには、インデックスに文字列フィールドを作成します。
- 関連付けられている ACL を含むソース ドキュメントを使用してインデックスを読み込みます。
- 文字列に一致するフィルター式をクエリ ロジックに含めます。
- クエリ時に、呼び出し元の ID を取得します。
- 呼び出し元の ID をフィルター文字列として渡します。
- 結果は、ユーザーまたはグループの ID 文字列を含められなかった一致を除外するためにトリミングされます。
プッシュ またはプル モデル API を使用できます。 このアプローチは API に依存しないため、インデックスとクエリにフィルター処理手順の有効な文字列 (ID) があることを確認するだけで済みます。
このアプローチは、カスタム アクセス モデルまたはMicrosoft以外のセキュリティ フレームワークを持つシステムに役立ちます。 この方法の詳細については、「結果をトリミングするためのセキュリティ フィルター Azure AI 検索を参照してください。
POSIX に似た ACL と RBAC スコープのアクセス許可のネイティブ サポートのパターン (プレビュー)
ネイティブ サポートは、インデックス作成とクエリを実行するドキュメントに関連するMicrosoft Entraユーザーとグループに基づいています。
Azure Data Lake Storage (ADLS) Gen2 コンテナーでは、コンテナーとファイルの ACL がサポートされます。 ADLS Gen2 の場合、ドキュメント レベルでの RBAC スコープの保持は、 ADLS Gen2 インデクサー または BLOB ナレッジ ソース (ADLS Gen2 をサポート) とプレビュー API を使用してコンテンツを取り込む場合にネイティブにサポートされます。 Azure BLOB インデクサー またはナレッジ ソースを使用するAzure BLOB の場合、RBAC スコープの保持はコンテナー レベルです。
ACL で保護されたコンテンツの場合は、管理を容易にするために、個々のユーザー アクセスに対するグループ アクセスを使用します。 このパターンには、次のコンポーネントが含まれています。
- ACL が割り当てられているドキュメントまたはファイルから始めます。
- インデックスでアクセス許可フィルターを有効にします。
- インデックス内の文字列フィールドにアクセス許可フィルターを追加します。
- 関連付けられた ACL を持つソース ドキュメントでインデックスを読み込みます。
- インデックスにクエリを実行し、要求ヘッダーに
x-ms-query-source-authorizationを追加します。
クライアント アプリは、 検索インデックス データ閲覧者ロールまたは検索インデックス データ 共同作成者ロールを使用して 、インデックス に対する読み取りアクセス許可を受け取ります。 クエリ時のアクセスは、インデックス付きコンテンツのユーザーまたはグループのアクセス許可メタデータによって決まります。 アクセス許可フィルターを含むクエリは、要求ヘッダーに x-ms-query-source-authorization としてユーザーまたはグループ トークンを渡します。 クエリ時にアクセス許可フィルターを使用する場合、Azure AI 検索は次の 2 つをチェックします。
最初に、クライアント アプリケーションがインデックスにアクセスできるようにする 検索インデックス データ 閲覧者 アクセス許可を確認します。
次に、要求に対する追加のトークンを指定すると、検索結果で返されるドキュメントに対するユーザーまたはグループのアクセス許可がチェックされます。一致しないアクセス許可は除きます。
インデックスにアクセス許可メタデータを取得するには、プッシュ モデル API を使用して、JSON ドキュメントを検索インデックスにプッシュします。ペイロードには、各ドキュメントの POSIX に似た ACL を提供する文字列フィールドが含まれています。 このアプローチとセキュリティ トリミングの重要な違いは、インデックスとクエリのアクセス許可フィルター メタデータが認証Microsoft Entra IDとして認識されるのに対し、セキュリティ トリミングの回避策は単純な文字列比較です。 また、Graph SDK を使用して ID を取得することもできます。
また、データ ソースが Azure Data Lake Storage (ADLS) Gen2 であり、コードがインデックス作成のためにプレビュー API を呼び出す場合は、プル モデル (インデクサー) API を使用することもできます。
データ インジェスト プロセス中に ACL アクセス許可メタデータを取得する (プレビュー)
ACL アクセス許可を取得する方法は、ドキュメント ペイロードをプッシュするか、ADLS Gen2 インデクサーを使用するかによって異なります。
次の機能を提供するプレビュー API から始めます。
- 2026-05-01-preview REST API
- Python 用 Azure SDK のプレリリース パッケージ. ACL と RBAC スコープのインジェストをサポートする最新のプレビュー バージョンの変更ログを確認します。
- .NET 用 Azure SDK のプレリリース パッケージ。 ACL と RBAC スコープのインジェストをサポートする最新のプレビュー バージョンの変更ログを確認します。
- Java 用 Azure SDK のプレリリース パッケージ。 ACL と RBAC スコープのインジェストをサポートする最新のプレビュー バージョンの変更ログを確認します。
プッシュ モデルアプローチの場合:
- プレビューまたはプレリリース SDK を使用してインデックス スキーマが作成されていること、およびスキーマにアクセス許可フィルターがあることを確認します。
- グループ ID またはユーザー ID を取得するには、Microsoft Graph SDK を使用することを検討してください。
- ドキュメントとその関連するアクセス許可メタデータを検索インデックスにプッシュするには、Index Documents または同等のAzure SDK API を使用します。
プル モデルの ADLS Gen2 インデクサー アプローチまたは BLOB (ADLS Gen2) ナレッジ ソースの場合:
- ディレクトリ内のファイルが ADLS Gen2 アクセス制御モデルを使用してセキュリティで保護されていることを確認します。
- Indexers - Create (REST API)、Knowledge Sources - Create (REST API)、または同等のAzure SDK API を使用してインデクサー、インデックス、データ ソースを作成します。
スキルセットが、統合ベクター化用の Text Split スキルなどを使用してドキュメントをチャンクに分割する場合、アクセス許可メタデータ フィールドはインデクサーのフィールド マッピングからインデックス プロジェクションに移動します。 ACL フィールドを設定する場所の選択を参照してください。
Microsoft 365 SharePointの基本的なACLアクセス許可取り込みパターン (プレビュー)
インデックス付きSharePointコンテンツの場合、Azure AI 検索はソースのアクセス許可をメタデータとして格納し、それらを使用してクエリ結果をフィルター処理できます。 この機能には、Microsoft 365 インデクサーのSharePointと、2026-05-01-preview REST API または同等のプレビュー SDK パッケージを使用して、プレビュー段階でアクセスできます。
アクセス許可の要件、サポートされているグループリレーションシップ、アクセス許可の同期、および制限については、「SharePoint インデクサーを使用してアクセス許可メタデータを取り込む」を参照してください。
スキルセットが (たとえば、統合ベクター化のためのテキスト分割スキルを使用して) ドキュメントをチャンクする場合、ACL フィールドはインデクサー フィールド マッピングからインデックス プロジェクションに移動します。 ACL フィールドを設定する場所の選択を参照してください。
Microsoft Purview センシティビティ ラベルのパターン (プレビュー)
ラベル インジェストを有効にすると、Azure AI 検索はサポートされているデータ ソースから秘密度メタデータを抽出します。 これらのデータ ソースには、Azure Blob Storage、Azure Data Lake Storage Gen2 (ADLS Gen2)、Microsoft 365のSharePoint、および OneLake Microsoftが含まれます。 抽出されたラベルは、ドキュメント コンテンツと共にインデックスに格納されます。
クエリ時に、Azure AI 検索は、各ドキュメントの秘密度ラベル、ユーザーのMicrosoft Entra トークン、および組織の Purview ポリシーをチェックしてアクセスを決定します。 ユーザーの ID とラベルベースのアクセス許可で構成された Purview ポリシーでのアクセスが許可されている場合にのみ、ドキュメントが返されます。
このパターンには、次のコンポーネントが含まれます。
- 2026-05-01-preview REST API または Purview ラベル インジェストをサポートする対応する SDK を使用して、インデックス、データ ソース、インデクサー (スケジュール設定用) を構成します。
- 検索サービス でシステム割り当てマネージド ID を 有効にします。 Purview ラベル抽出では、ユーザー割り当てマネージド ID はサポートされていません。サービス独自の ID は、昇格された Purview アクセス許可を保持する必要があります。 次に、テナント全体管理者または特権ロール管理者に、検索サービスがMicrosoft Purviewで認証し、ラベル メタデータを抽出できるようにするために必要なアクセス権を付与します。
- インジェスト中にシステムが認識して保持できるように、インデックス作成の前に秘密度ラベルをドキュメントに適用します。
- クエリ時に、ヘッダー
x-ms-query-source-authorizationを介して有効なMicrosoft Entra トークンを各クエリ要求にアタッチします。 Azure AI 検索は、トークンと関連するラベル メタデータを評価して、ラベルベースのアクセス制御を適用します。
Purview 秘密度ラベルの適用は、シングルテナント シナリオに限定され、RBAC 認証が必要です。 プレビュー期間中は、REST API とAzure SDKでのみサポートされます。 オートコンプリート API と Suggest API は現在、Purview 対応インデックスでは使用できません。
秘密度ラベルが表示される場所
システムがクエリ時にラベルを適用したり、応答の取得でラベルを返したりする前に、まずラベル メタデータをインデックスに同期する必要があります。 このセクションで説明されている両方の使用パスは、この同期手順に依存しています。 ラベルを同期するには、サポートされているデータ ソースに対して直接Azure AI 検索 インデクサーを構成するか、ナレッジ ソースを作成するときに同等のインジェスト オプションを有効にします。 どちらの場合も、環境は、センシティビティ ラベル メタデータ同期構成の前提条件 (マネージド ID、検索サービスの RBAC、および必要なMicrosoft Purviewとデータ ソースのアクセス許可) を満たしている必要があります。 エンドツーエンドのインデクサーのセットアップについては、「Azure AI 検索 インデクサーを使用して Microsoft Purview の秘密度ラベルを取り込む」を参照してください。 ナレッジ ソース主導の取り込みでは、ingestionPermissionOptions時に sensitivityLabel を設定して を含めます。
ラベルを同期すると、2 つのクエリ パスで同じインデックス付きラベル メタデータが使用されます。 アプリケーションがAzure AI 検索を呼び出す方法に一致するパスを選択します。
Direct クエリ API (
/docs/search): ユーザーのMicrosoft Entra トークンをx-ms-query-source-authorizationにアタッチします。 管理者は、監査対応の調査のために 特権読み取り 要求を送信することもできます。 セットアップと例については、「Microsoft Purview の秘密度ラベルのクエリ時の適用」を参照してください。ナレッジ ソースとエージェント検索 (MCP):ナレッジ ソースに
ingestionPermissionOptionsを含むようにsensitivityLabelを設定します。 取得アクションと MCPknowledge_base_retrieveツールは、クライアントが表示バナーとポリシーの適用に使用できる参照ごとのsensitivityLabelInfoと応答レベルのmetadata.responseSensitivityLabelInfoを返します。 セットアップについては、「 ナレッジ ソースの作成 」および「 応答を取得する際の機密ラベルメタデータの検査」を参照してください。
ナレッジ ソースが、統合されたベクター化やカスタムテキスト分割スキルによって設定されたインデックスなど、チャンクインデックスを指している場合、スキルセットは 各チャンク行に秘密度ラベルも投影する必要があります。 このプロジェクションがないと、チャンク レベルの参照はフィルター処理されません。
詳細については、「 Azure AI 検索 インデクサーを使用して Microsoft Purview の秘密度ラベルを取り込む方法」を参照してください。
クエリ時にドキュメント レベルのアクセス許可を適用する
トークンベースのクエリ強制は、POSIX ライクな ACL および RBAC のスコープ、Microsoft Purview の秘密度ラベル、ならびに Microsoft 365 における SharePoint ACL パターンに適用される共通機能です。 ネイティブ トークン ベースのクエリを使用して、Azure AI 検索は各要求で呼び出し元のMicrosoft Entra トークンを検証し、ドキュメント ACL メタデータがインデックスに同期されている限り、呼び出し元がドキュメント ACL に従って読み取りを許可されているドキュメントのみに結果セットをトリミングします。
x-ms-query-source-authorization ヘッダーを介してユーザーのトークンをクエリ要求に添付すると、Azure AI 検索 は次のようになります:
- トークンからユーザー、グループ、スコープの要求を抽出します。
- これらの要求を、インデックス付きドキュメント (ACL エントリ、RBAC スコープ、Purview ラベルの割り当て、または SharePoint ACL) と共に格納されているアクセス許可メタデータと比較します。
- 同期されたアクセス許可メタデータによって呼び出し元のアクセスが許可されているドキュメントのみを返します。
クエリ時の強制は、呼び出し元のMicrosoft Entra要求を、インデックスに既に格納されているアクセス許可メタデータと比較して評価します。 ソース システムのアクセス許可の変更 (Microsoft Entra グループ メンバーシップ、ADLS Gen2 ACL、Purview ラベルの割り当て、またはSharePoint ACL) は、そのメタデータがソース固有のメカニズム (後続のインデクサーの実行、プッシュ API 更新、Purview ドリブン更新など) を通じてインデックスに同期された後にのみ検索結果に反映されます。 SharePointでは、2026-05-01-preview REST API 以降のインデクサーの実行が成功するたびに、一意のアクセス許可を持つ項目に対する ACL の変更が増分的に取得されますが、親スコープ (サイト、ライブラリ、リスト、またはフォルダー) から継承された変更には明示的な更新が必要です。 詳細については、「 インデックス付きコンテンツとソース コンテンツの間でアクセス許可を同期する」を参照してください。
エンドツーエンドのクエリ実装手順については、Azure AI 検索 での
ドキュメント レベルのアクセス制御の利点
Azure AI 検索のネイティブ ドキュメント レベルのアクセス制御は、アプリケーション側のフィルター処理よりも具体的な利点を提供します。
- カスタムアクセス許可コードを削除します。 入れ子になったグループ解決、マルチレベル ACL トラバーサル、またはクエリ後のトリミングをアプリケーションに実装する必要はありません。 Azure AI 検索は、クエリの実行中に比較とフィルター処理を処理します。
- 既存のコンプライアンス制御と連携する: Microsoft Entra、Microsoft Purview、SharePointのアクセス許可のメタデータを再利用すると、検索結果をソース ID システムに合わせて維持できます。 各ソースのアクセス許可同期モデルを確認して、その制限を理解します。
- 各 ACL 同期の後に、ソースのアクセス許可を優先します。トークンベースのアプローチ (ACL、RBAC スコープ、Purview ラベル、SharePoint ACL) の場合、クエリ時の適用では、ドキュメント化されたソース固有の同期メカニズム (インデクサーの実行、プッシュ API 更新、または Purview 更新) によって既にインデックスに書き込まれているアクセス許可メタデータが使用されます。
- パフォーマンスとクエリ後のトリミングが向上します。 検索パイプライン内でのフィルター処理は、アプリケーションに大きな結果セットを読み込み、そこでトリミングするよりも高速です (特にクエリ量が多い場合)。
- 既存の ID インフラストラクチャを再利用します: Microsoft Entra と SharePoint の ID は引き続きアクセス判断の正本情報源であるため、ID の重複や、別個のアクセス許可ストアを維持するための運用オーバーヘッドを削減できます。
チュートリアルとサンプル
その他の記事やサンプルを使用して、Azure AI 検索のドキュメント レベルのアクセス制御について説明します。
- チュートリアル: インデクサーを使用して ADLS Gen2 アクセス許可メタデータのインデックスを作成する
- azure-search-rest-samples/acl
- azure-search-python-samples/Quickstart-Document-Permissions-Push-API
- azure-search-python-samples/Quickstart-Document-Permissions-Pull-API
- デモ アプリ: 秘密度ラベルの取り込みと受け入れ