Note
Azure AI 検索は、Azure ポータル、REST API、およびAzure SDKから使用できます。 また、Foundry IQ は、エンタープライズ コンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジ ベースに変換するマネージド ナレッジ レイヤーです。
この記事は、インデックス付きSharePointコンテンツに対するクエリ時のアクセス許可フィルター処理で、不足または予期しない結果が返される場合、またはアクセス許可でフィルター処理されたクエリが失敗した場合に使用します。
前提条件
- ACL インジェストが構成されたインデクサー Microsoft 365 SharePointによって設定されたインデックス。
- Query-time ACL and RBAC enforcement で説明されているとおりに構成された、クエリ時の権限フィルタリング。
- SharePoint サイト グループを使用する場合は、REST API バージョン
2026-08-01-previewまたは同等のプレビュー SDK パッケージ。 - インデックス定義、生成または明示的なインデクサーの状態、およびテスト ユーザーのSharePointアクセス許可へのアクセス。
- フィルター処理された結果とフィルター処理されていない結果を比較する必要がある場合は、Search Index Data Contributor または同等のより高いレベルの読み取りアクセス許可が必要です。
トラブルシューティングのデシジョン ツリーに従う
これらのチェックを順番に完了します。 観察された結果によって、修正が必要な構成またはアクセス許可が識別されたら停止します。
1. クエリ時にエラーが発生したかどうかを確認する
この記事では、コンテンツと ACL メタデータSharePointインデックスが作成された後のアクセス許可のフィルター処理について説明します。
- データ ソースの作成時またはインデクサーの実行時に
Invalid AAD tenantが報告された場合は、Microsoft Entra テナントの修復に従ってください。 -
TenantId、認証、またはデータ ソースの接続文字列を修正する必要がある場合は、「Microsoft 365 の SharePoint インデクサーを構成する」を参照してください。 - インデックス作成中に
UserIds、GroupIds、またはSharePointSiteUrlが見つからない場合は、 ACL インジェストのトラブルシューティング テーブルを使用します。
インデックス付きアクセス許可メタデータが存在し、クエリを実行したときに現象が発生した場合にのみ、ここで続行します。
2. 3 つの ID を識別する
各ロールを担う ID 情報を記録します。 1 つの識別子を別の識別子に置き換えないでください。
| Identity | Purpose | 確認する場所 |
|---|---|---|
| ユーザーに問い合わせています |
x-ms-query-source-authorizationの委任されたユーザー トークンによって、ユーザーが取得できる保護されたドキュメントが決まります。 |
アプリケーション認証フローとクエリ要求。 |
| SharePoint コネクタ アプリの登録 | インデックスのsharePointConnectorAppRegistrationを使用Azure AI 検索、クエリを実行するユーザーのSharePoint サイト グループ メンバーシップを解決できます。 |
「SharePoint グループのサポートの構成」で説明されているインデックス定義とアプリの登録。 |
| Azure AI 検索 の要求 ID |
Authorization ヘッダーのMicrosoft Entraベアラー トークン、または api-key ヘッダーの API キーは、検索サービスに対する要求を認証します。 ID には、インデックスを照会するためのアクセス許可が必要です。 |
使用するクエリ クライアントとAzure AI 検索 のデータ プレーン ロールの割り当て。 |
3. アクセス許可フィルターの構成を確認する
インデックス、インデクサー、生成されたオブジェクトを所有者アーティクルと比較します。
- インデックス
permissionFilterOptionenabledに設定されていることを確認します。 -
UserIdsとGroupIdsのpermissionFilterの値が正しいことを確認します。 - SharePointサイト グループの場合は、インデックスに
sharePointConnectorAppRegistrationがあり、SharePointSiteUrlを持つsharepointSiteUrl: trueフィールドがあることを確認します。 - インデックス付きドキュメントまたはチャンクに該当するアクセス許可フィールドが含まれているかどうかを確認します。 スキルセットがインデックス プロジェクションを使用している場合は、ACL フィールドが
indexProjections.mappingsに含まれているかどうかを確認します。
値がない場合は、「 ACL インジェストとクエリ時間の適用用に検索サービスを構成する」に戻ります。
4. クエリ トークンを安全に確認する
ログに記録したり、サポート要求に貼り付けたり、フル アクセス トークンを共有したりしないでください。 診断出力をキャプチャする前に、トークン ペイロードのみをローカルでデコードし、識別子をサニタイズします。
- 要求に、テスト ユーザーの現在の委任されたトークンを含む
x-ms-query-source-authorizationが含まれていることを確認します。 - ペイロードをローカルでデコードし、
oidが目的のテスト ユーザーを識別することを確認します。<test-user-object-id>などのサニタイズされた値を記録します。 - ユーザーを再認証し、トークンが見つからないか期限切れになった場合は再試行します。
ユーザー トークンを省略した場合、アクセス許可で保護されたコンテンツは返されません。
Authorization ヘッダーだけでは、x-ms-query-source-authorizationは置き換えられません。
5. Microsoft Entraアクセス許可を確認する
- インデックス付き
UserIdsまたはGroupIdsに予期されるMicrosoft Entra オブジェクト ID が含まれていることを確認します。 昇格された読み取りクエリ は、この診断用の比較にのみ使用してください。 - テスト ユーザーが直接割り当てられているか、推移的なMicrosoft Entra グループ メンバーシップを通じて割り当てられたMicrosoft Entra グループに到達したことを確認します。
- Microsoft Entra グループが SharePoint グループに入れ子になっている場合は、割り当てを変更してください。 この混合リレーションシップは展開されず、結果が見つからない可能性があります。 ユーザーをSharePoint グループに直接追加するか、サポートされているMicrosoft Entra グループの割り当てを通じてアクセス許可を付与します。
正確なサポート境界については、「 サポートされているグループリレーションシップ」を参照してください。
6. SharePoint サイト グループのアクセス許可を確認する
ドキュメント ACL が所有者、メンバー、閲覧者、またはカスタム SharePoint サイト グループに依存している場合は、この手順を実行します。
- 昇格読み取りクエリを使用して、
GroupIdsに想定されるspg:プレフィックス付きのグループ ID が含まれていること、およびSharePointSiteUrlがソース サイトを識別することを確認します。 - テスト ユーザーがそのSharePoint グループの直接メンバーであることを確認します。
- インデックスの
sharePointConnectorAppRegistrationで、SharePoint グループのサポートに必要な識別子とアクセス許可が使用されたことを確認します。
インデックス付きフィールドが空または古い場合は、クエリを再テストする前に、インジェストを修正するか、SharePointのアクセス許可を同期します。
7. クエリ要求を確認する
- SharePoint サイト グループのアクセス許可フィルターには、REST API バージョン
2026-08-01-previewまたは同等のプレビュー SDK パッケージを使用します。 -
Authorizationが、インデックスに対してクエリを実行できるプリンシパルを認証することを確認します。 - 委任されたテスト ユーザー トークン
x-ms-query-source-authorization含まれていることを確認します。 - アクセス許可の動作を分離できるように、関連のないフィルターやランク付けの変更を行わずに、同じクエリを再試行します。
要求図形の所有者として 、一般的なクエリの例 を使用します。 保存された要求またはログに完全なトークンを含めないでください。
8. 予想される結果と実際の結果を比較する
- テスト ユーザーがアクセスできるドキュメントと、SharePointでアクセスできないドキュメントを 1 つ選択します。
- アクセス許可でフィルター処理されたクエリをテスト ユーザーとして実行し、ドキュメント キーまたはその他の非セキュリティ識別子のみを記録します。
- 管理者特権で読み取りクエリを実行し、格納されている
UserIds、GroupIds、およびSharePointSiteUrlの値をソースのアクセス許可と比較します。 - 管理者特権での読み取りで予想されるドキュメントが返されるが、ユーザー クエリでは返されない場合は、ユーザー トークンとグループ解決に重点を置きます。 昇格権限での読み取りでもそれを見逃す場合は、取り込み、マッピング、ACL の同期に注力してください。
権限の昇格された読み取りは調査目的です。 エンド ユーザーに無制限の結果を返すために使用しないでください。
9. 要求の相関関係の詳細をキャプチャする
それでもクエリが失敗する場合は、API バージョン、UTC タイムスタンプ、サニタイズされた要求本文、HTTP 状態、応答ヘッダー、およびサービスによって返されるすべての要求または関連付け ID をキャプチャします。 インデックス名と、同じドキュメントが管理者特権での読み取りの下に表示されるかどうかを含めます。
Microsoft サポートと診断を共有する前に、アクセス トークン、API キー、シークレット、ユーザー名、テナント固有の URL を削除します。