SharePoint OnlineでRestricted Access Controlを設定したのに、Microsoft Searchの検索結果やMicrosoft 365 Copilotの回答にサイトの内容が残っていると、「アクセス制限が効いていないのではないか」と不安になることがあります。
結論として、Restricted Access Controlは組織全体の検索とMicrosoft 365 Copilotにも適用されますが、検索インデックスへの反映は即時ではありません。反映時間はサイト内のアイテム数に左右され、大規模なサイトほど時間がかかる可能性があります。設定直後の検索結果だけで失敗と判断せず、まず対象外ユーザーがサイトやファイルを直接開けないことを確認し、その後に検索とCopilotを再テストすることが重要です。(Microsoft Learn)
SharePointのアクセス制限後も検索・Copilotに内容が出る理由
Restricted Access Controlでは、サイトへのアクセス判定と、検索・Copilotへの反映が同じタイミングで完了するとは限りません。
管理者は、次の2つを分けて確認する必要があります。
| 確認対象 | 確認している内容 | 反映遅延の影響 |
|---|---|---|
| サイトやファイルの直接アクセス | Restricted Access Controlによる実際のアクセス判定 | 検索結果とは別に確認する必要がある |
| Microsoft Search | 検索インデックスに反映されたアクセス状態 | アイテム数が多いサイトほど遅くなる可能性がある |
| Microsoft 365 Copilot | Copilotが参照できる検索・アクセス情報 | 検索と同様に反映まで時間がかかることがある |
たとえば、アクセスを許可していないユーザーがファイルのURLを直接開くと拒否される一方で、Microsoft Searchには一時的にファイル名が残っている場合があります。
この状態なら、Restricted Access Control自体は機能しており、検索インデックス側の更新が完了していない可能性があります。
ただし、対象外ユーザーがファイル本文を直接開ける場合は、単なる検索インデックスの遅延ではありません。設定対象のサイト、制御グループ、ユーザーのグループ所属などを見直す必要があります。
「1時間で反映される」とは限らない
Restricted Access Controlをテナントで初めて有効にするときは、次のPowerShellコマンドを使用できます。
Set-SPOTenant -EnableRestrictedAccessControl $trueMicrosoftの公式ドキュメントでは、このテナント設定が有効になるまで最大1時間かかる可能性があると説明されています。
一方、サイトに設定したRestricted Access Controlが検索とMicrosoft 365 Copilotへ反映される時間については、固定された上限時間が示されていません。検索インデックスの更新時間はサイト内のアイテム数に依存し、アイテム数が多いサイトほど長くなる可能性があります。(Microsoft Learn)
つまり、次の2つを混同しないことが重要です。
| 変更内容 | 公式ドキュメント上の目安 |
|---|---|
| テナントでRestricted Access Controlを有効化 | 最大1時間かかる可能性がある |
| サイトの制限を検索・Copilotへ反映 | 固定時間は示されておらず、サイトのアイテム数に依存する |
「テナント設定は1時間以内だから、検索結果も1時間以内に消える」とは限りません。
また、反映時間を判断するときは、サイトの保存容量だけでなく、アイテム数を見る必要があります。容量が小さくても、多数の小さなファイル、ページ、リスト項目を保持しているサイトでは、インデックス更新に時間がかかる可能性があります。
Restricted Access Controlのアクセス判定を理解する
Restricted Access Controlは、Microsoft EntraセキュリティグループまたはMicrosoft 365グループを使用し、SharePointサイトへアクセスできるユーザーを限定する機能です。
重要なのは、制御グループへの追加だけではSharePointのアクセス権が付与されないことです。
ユーザーがサイトへアクセスするには、次の両方を満たす必要があります。
- 通常のSharePointアクセス権を持っている
- Restricted Access Controlに指定されたグループのメンバーである
判定結果は次のようになります。
| 通常のSharePointアクセス権 | 制御グループのメンバー | アクセス結果 |
|---|---|---|
| あり | あり | アクセス可能 |
| あり | なし | Restricted Access Controlで拒否 |
| なし | あり | SharePointアクセス権がないため拒否 |
| なし | なし | 拒否 |
1サイトには、Microsoft EntraセキュリティグループまたはMicrosoft 365グループを最大10個まで指定できます。(Microsoft Learn)
この仕組みを理解していないと、「制御グループに追加したのにアクセスできない」「元から権限を持っているのに拒否された」といった問題が起こります。
Restricted Access Controlの設定状態を確認する
検索・Copilotの反映遅延を疑う前に、サイト側へ正しいポリシーが保存されているか確認します。
SharePoint管理センターで確認する
SharePoint管理センターでは、次の手順で確認できます。
- SharePoint管理センターを開く
- 「サイト」から「アクティブなサイト」を開く
- 対象サイトを選択する
- 「設定」タブを開く
- 「制限付きサイトアクセス」の編集画面を開く
- アクセス制限が有効になっていることを確認する
- 指定されたグループが正しいことを確認する
Teamsに接続されたサイトでは、接続先のMicrosoft 365グループが既定の制御グループとして表示されることがあります。
PowerShellで確認する
PowerShellでは、次のコマンドで設定状態とグループを確認できます。
Get-SPOSite -Identity <サイトURL> |
Select-Object RestrictedAccessControl, RestrictedAccessControlGroups確認するポイントは次のとおりです。
RestrictedAccessControlが有効になっているかRestrictedAccessControlGroupsに意図したグループIDが登録されているか- 別のサイトURLを確認していないか
- Teamsのプライベートチャネルや共有チャネル用サイトを見落としていないか
公式ドキュメントでも、サイト単位の設定確認にはRestrictedAccessControlとRestrictedAccessControlGroupsを取得する方法が示されています。(Microsoft Learn)
反映遅延か設定ミスかを切り分ける手順
変更内容と時刻を記録する
設定変更時には、少なくとも次の情報を記録しておきます。
- 設定した日時
- 対象サイトのURL
- サイト内のおおよそのアイテム数
- 登録した制御グループ
- アクセスを許可するテストユーザー
- アクセスを拒否するテストユーザー
- 検索に使用するファイル名や固有キーワード
変更時刻を記録していないと、どの程度待ったのか分からず、反映遅延と障害を切り分けにくくなります。
対象外ユーザーで直接アクセスする
最初に、制御グループへ所属していない一般ユーザーで次のURLを直接開きます。
- SharePointサイトのトップページ
- 対象ドキュメントライブラリ
- 制限対象のファイル
- 共有リンク
テストには、普段使用している管理者アカウントではなく、制御グループに所属していないことを確認した一般ユーザーを使用します。
直接アクセスの結果によって、次のように判断できます。
| 直接アクセスの結果 | 判断 |
|---|---|
| サイトやファイルを開けない | アクセス制限は機能している可能性が高い |
| サイトやファイルを開ける | インデックス遅延ではなく、設定やグループ所属を再確認する |
| サイトは拒否されるが別のファイルは開ける | 別サイト、別チャネルサイト、別共有経路の可能性を確認する |
Microsoft Searchを固有語で確認する
検索テストでは、一般的な単語ではなく、対象ファイルにしか含まれない固有の文字列を使用します。
たとえば、次のような検索条件が適しています。
- 完全なファイル名
- 文書内にだけ存在する案件番号
- 固有のプロジェクト名称
- 他の文書には使用していない一文
同じ名称のファイルが複数サイトにあると、別サイトの結果を対象サイトの情報と誤認する可能性があります。検索結果に表示されたURLや保存場所まで確認してください。
検索結果が残っていても、クリック後にアクセス拒否となる場合は、検索インデックスの反映待ちである可能性があります。
Copilotは新しいチャットで確認する
Microsoft 365 Copilotの確認では、過去の会話をそのまま使わず、新しいチャットを開始します。
既存チャットに以前生成された回答が残っているだけでは、現在も対象サイトを参照できている証拠にはなりません。
テスト時は、次のように対象を限定します。
「令和8年度機密プロジェクト計画書.docx」の内容を要約し、
参照したファイルの保存場所とソースを示してください。Copilotが似た内容を回答しただけでは、対象サイトを参照したとは断定できません。次の点を確認します。
- 対象ファイルへのソースリンクが表示されているか
- ソースURLが制限対象サイトを指しているか
- 別サイトの同名ファイルを参照していないか
- 一般知識や会話履歴から生成された回答ではないか
- 新しいチャットでも同じ結果になるか
制限対象サイトへのソースリンクが新しいチャットでも表示される場合は、反映が完了していないか、ポリシーの対象外になっている可能性があります。
同じ条件で時間を置いて再確認する
検索インデックスの反映状況を比較するには、検索語、ユーザー、サイト、Copilotへの質問を変えずに再テストします。
テスト条件を毎回変えると、反映されたのか、検索条件が変わっただけなのか判断できません。
MicrosoftはRestricted Access Controlについて固定の完了時間を示していないため、「何時間で必ず消える」と利用部門へ約束するのは避けるべきです。大規模サイトでは、設定日と利用開始日を同日にせず、事前にアクセス制限と検索・Copilotの確認期間を設ける運用が安全です。(Microsoft Learn)
症状別の原因と対処方法
| 症状 | 主な原因 | 対処方法 |
|---|---|---|
| 対象外ユーザーが直接ファイルを開ける | 制御グループへの所属、設定対象サイト、ポリシーの保存状態に問題がある | グループ所属とGet-SPOSiteの結果を確認する |
| 直接アクセスは拒否されるが検索結果に残る | 検索インデックスの反映遅延 | 時間を置き、同一条件で再検索する |
| Microsoft Searchから消えたがCopilotが回答する | 古いチャット、別サイトの情報、Copilot側の反映待ち | 新しいチャットでソースリンクまで確認する |
| 制御グループへ追加したユーザーもアクセスできない | 通常のSharePointアクセス権がない | サイトまたはコンテンツのアクセス権を別途付与する |
| Teamsの一部チャネルだけアクセスできる | プライベートチャネルまたは共有チャネルが別サイトになっている | チャネル用SharePointサイトにも個別設定する |
| 同じファイル名の結果が残る | 別サイトに同名ファイルがある | 検索結果のURLと保存場所を確認する |
| 長時間経過しても状態が変わらない | 大規模サイト、誤設定、サービス側の問題 | 設定情報とテスト結果を整理し、Microsoftサポートへ問い合わせる |
Teamsのチャネルサイトは別に設定する
Teamsに接続されたSharePointサイトを制限しただけでは、プライベートチャネルや共有チャネルのサイトまで自動的に制限されるとは限りません。
標準チャネルは通常、チームに接続されたSharePointサイトを使用します。一方、プライベートチャネルと共有チャネルには、それぞれ別のサイトコレクションが作成されます。
そのため、親となるチームサイトへRestricted Access Controlを設定しても、プライベートチャネルや共有チャネルのサイトには自動適用されません。各チャネルサイトに対して個別に設定する必要があります。(Microsoft Learn)
次のような場合は、検索インデックスの遅延より先にチャネルサイトを確認してください。
- Teamsの標準チャネルにあるファイルは開けないが、プライベートチャネルのファイルは開ける
- 検索結果のURLが想定していたチームサイトと異なる
- URLにチャネル名や独立したサイト名が含まれている
- 同じチーム内のファイルなのにアクセス結果が異なる
なお、共有チャネルへ別テナントから参加している外部ユーザーは、リソーステナントのRestricted Access Controlによる評価対象にならないと説明されています。外部参加者のアクセスは、共有チャネルと関連サイトに付与された権限によって決まります。(Microsoft Learn)
似た名称のアクセス制御機能と混同しない
SharePointには、検索やCopilotに関係する名称の似た機能が複数あります。
| 機能 | 主な目的 | SharePointアクセス権への影響 |
|---|---|---|
| Restricted Access Control | 指定グループのメンバーにサイトアクセスを限定する | 追加のアクセス条件として機能する |
| Restricted Content Discovery | 特定サイトを組織全体検索やCopilotから見つけにくくする | 既存のアクセス権は変更しない |
| Restricted SharePoint Search | 許可リストを使って組織全体検索やCopilotの対象を一時的に制限する | セキュリティ境界ではなく、アクセス権は変更しない |
Restricted Content Discoveryは、サイトの内容が組織全体の検索やMicrosoft 365 Copilotに表示される範囲を制御する機能です。サイトへの直接アクセス権は変更されず、ユーザーが所有しているコンテンツや最近操作したコンテンツは引き続き見つかることがあります。(Microsoft Learn)
したがって、機密サイトへのアクセスそのものを特定グループに限定したい場合、Restricted Content Discoveryだけでは代替できません。
Restricted SharePoint Searchもアクセス権を変更する機能ではありません。Microsoftは同機能を一時的な対策として位置付けており、2026年7月31日以降は新規の有効化をブロックすると案内しています。(Microsoft Learn)
再インデックスを最初の対処にしない
検索結果が残ると、サイト全体の再インデックスを実行したくなります。しかし、Restricted Access Controlの反映待ちに対して、最初から再インデックスを実行するのは適切とは限りません。
Microsoftは、サイト全体の再インデックスについて、検索システムへ大きな負荷を与える可能性があるため、全アイテムの再インデックスが必要な変更を行った場合以外は実行しないよう注意しています。
また、再インデックスを要求しても、その場で処理が完了するわけではありません。コンテンツが変更済みとしてマークされ、次回の予定されたクロールで処理されます。(Microsoft Learn)
Restricted Access Controlの公式手順では、検索・Copilotへの反映が遅い場合にサイト全体の再インデックスを必須としていません。
まずは次の順序で対応します。
- サイトのRestricted Access Control設定を確認する
- 制御グループとユーザーの所属を確認する
- 対象外ユーザーによる直接アクセスを確認する
- サイトのアイテム数を確認する
- 時間を置いて検索・Copilotを再テストする
- 解消しない場合はMicrosoftサポートへ問い合わせる
検索スキーマや管理プロパティを変更したなど、別の理由で全コンテンツの再クロールが必要な場合に限り、再インデックスを検討してください。
管理者が残しておくべき確認記録
Restricted Access Controlを本番運用する場合は、設定完了を「保存ボタンを押した時点」としないことが重要です。
変更記録には、次の項目を残します。
- サイトURL
- 設定変更日時
- 変更担当者
- 制御グループの表示名とID
- サイトのおおよそのアイテム数
- 許可ユーザーによる直接アクセス結果
- 拒否ユーザーによる直接アクセス結果
- Microsoft Searchの確認日時と検索語
- Microsoft 365 Copilotの確認日時と質問内容
- Copilotが提示したソースURL
- 最終確認日時
完了条件も、次の2段階に分けると管理しやすくなります。
- アクセス制御完了：対象外ユーザーがサイトとファイルを直接開けない
- 検索・Copilot反映完了：対象外ユーザーの検索結果とCopilotのソースに対象コンテンツが表示されない
この運用にしておけば、検索インデックスの反映待ちを設定ミスと誤認したり、反対に設定ミスを単なる遅延として放置したりするリスクを減らせます。
SharePointのアクセス制限は直接アクセスと検索を分けて確認する
Restricted Access Controlは、SharePointサイトへのアクセスだけでなく、組織全体の検索とMicrosoft 365 Copilotにも適用されます。ただし、検索インデックスへの反映には時間がかかり、サイト内のアイテム数が多いほど遅くなる可能性があります。
設定後は、まず制御グループに所属していないユーザーでサイトとファイルを直接開きます。直接アクセスが拒否されることを確認した後、固有のファイル名やキーワードを使ってMicrosoft Searchを再確認し、Microsoft 365 Copilotでは新しいチャットからソースリンクまで確認してください。
直接アクセスできてしまう場合は、待つのではなく設定を見直します。直接アクセスは拒否されるものの検索やCopilotに残っている場合は、変更時刻とサイトのアイテム数を記録し、反映後に同じ条件で再テストするのが適切な対応です。
コメント