Microsoft Entraの「Conditional Access policy – SharePoint in Microsoft 365」は、SharePointサイトに対して通常より厳しいアクセス条件を適用したい管理者向けの設定です。結論から言うと、今回確認すべきポイントは「認証コンテキストをSharePointサイトまたは秘密度ラベルに結び付けること」「対象外のアプリやシナリオを事前にテストすること」「ライセンス、PowerShell、サードパーティ製アプリの対応を展開前に確認すること」です。Microsoft Learnの日本語ページは2026年5月14日に更新されており、SharePointのルートサイトには適用できない点や、OneDrive同期アプリ、SharePointモバイルアプリ、Outlook連携などの制限も明記されています。(Microsoft Learn)
Microsoft EntraのConditional Access policy – SharePoint in Microsoft 365とは
Microsoft Entraの条件付きアクセスは、「ユーザーが特定のリソースにアクセスする場合は、多要素認証や準拠済みデバイスなどの条件を満たす必要がある」という形で、アクセス制御を自動化する仕組みです。Microsoftの公式説明では、条件付きアクセスはゼロトラストのポリシーエンジンとして、ユーザー、デバイス、場所、リスク、アプリケーションなどのシグナルを使ってアクセス可否を判断します。(Microsoft Learn)
SharePoint向けの今回のポイントは、Microsoft Entraの認証コンテキストを使い、特定のSharePointサイトにより厳しい条件付きアクセスを適用できることです。ポリシーはSharePointサイトに直接適用する方法と、Microsoft Purviewの秘密度ラベルを通じて適用する方法があります。(Microsoft Learn)
たとえば、通常のMicrosoft 365サインインではMFAだけを求める一方で、役員会資料や法務文書を置いたSharePointサイトにアクセスする場合は、追加で利用規約への同意、準拠済みデバイス、信頼済みネットワークからのアクセスを要求できます。
今回の公式情報で管理者が押さえるべき変更・確認ポイント
今回の更新は、単に「SharePointにも条件付きアクセスを使える」という一般論ではなく、展開時に失敗しやすい前提条件と制限事項を確認する意味が大きい内容です。
| 確認ポイント | 内容 | 実務での判断 |
|---|---|---|
| 適用単位 | SharePointサイトに認証コンテキストを紐づける | 全社一律ではなく、機密性の高いサイトから適用する |
| 適用方法 | サイトへ直接適用、または秘密度ラベル経由で適用 | 少数サイトなら直接適用、多数サイトならラベル運用が向く |
| 対象外 | SharePointのルートサイトには適用不可 | https://contoso.sharepoint.com ではなく /sites/xxx 単位で設計する |
| ライセンス | Microsoft 365 E5/A5 Compliance、Microsoft 365 E5 Information Protection and Governanceなどが必要 | 事前に契約と対象ユーザーを確認する |
| アプリ制限 | OneDrive同期アプリ、SharePointモバイルアプリ、Outlook連携などに制限あり | 展開前に業務アプリと利用端末でテストする |
| 開発者対応 | サードパーティ製アプリはクレームチャレンジへの対応が必要 | SharePoint連携アプリや独自アプリを棚卸しする |
特に重要なのは、認証コンテキストを設定したSharePointサイトでは、一部のアプリや機能が期待通りに動作しない点です。公式情報では、OneDrive同期アプリは認証コンテキスト付きサイトを同期しないこと、SharePointモバイルアプリ、Viva Engage、Teams上の一部操作、OutlookからのSharePointサイト通信などがサポート外または制限対象として挙げられています。(Microsoft Learn)
影響を受ける管理者・開発者・利用者
この設定の影響範囲は、SharePoint管理者だけに閉じません。Microsoft Entra、Microsoft Purview、Teams、OneDrive、Outlook、Power BI、サードパーティ製アプリの担当者まで関係します。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| Microsoft Entra管理者 | 条件付きアクセス ポリシーと認証コンテキストの設計が必要 | 対象ユーザー、条件、許可制御、除外アカウント |
| SharePoint管理者 | サイト単位で認証コンテキストを適用する | 対象サイト、ルートサイト除外、PowerShell設定 |
| Purview管理者 | 秘密度ラベル経由で認証コンテキストを適用する | ラベル設計、公開範囲、サイト所有者の操作権限 |
| Teams管理者 | TeamsのFilesタブや会議録画アップロードに影響する可能性 | Teams経由のファイル利用シナリオ |
| 開発者 | SharePoint連携アプリでクレームチャレンジ対応が必要 | OIDC/OAuth、MSAL、acrsクレーム、例外処理 |
| エンドユーザー | MFA、利用規約、デバイス条件などの追加要求が発生 | 事前周知、利用できないアプリの代替手段 |
条件付きアクセスはリソースへのアクセス時に評価されます。Microsoftの説明では、ポリシーはクライアントアプリそのものではなく、クライアントが呼び出すサービスやリソースに対して適用されるため、SharePointサービスを対象にしたポリシーはSharePointを呼び出す各種クライアントに影響します。(Microsoft Learn)
認証コンテキストをSharePointに適用する2つの方法
SharePointサイトへ認証コンテキストを適用する方法は、大きく分けて「サイトへ直接適用」と「秘密度ラベル経由で適用」の2つです。
サイトへ直接適用する方法
特定のサイトだけを厳しく保護したい場合は、SharePoint Online PowerShellのSet-SPOSiteコマンドレットを使って、認証コンテキストを直接割り当てます。公式ドキュメントでは、-ConditionalAccessPolicy AuthenticationContextと-AuthenticationContextNameを組み合わせる例が示されています。(Microsoft Learn)
Set-SPOSite -Identity https://contoso.sharepoint.com/sites/research `
-ConditionalAccessPolicy AuthenticationContext `
-AuthenticationContextName "Sensitive information - guest terms of use"この方法は、対象サイトが少ない場合や、まずパイロット展開したい場合に向いています。一方で、対象サイトが増えると個別管理が煩雑になります。サイトの棚卸し、設定状況の確認、変更履歴の管理をPowerShellや管理台帳で整備しておくべきです。
秘密度ラベル経由で適用する方法
複数のSharePointサイトやTeamsに一貫した保護を適用したい場合は、Microsoft Purviewの秘密度ラベルを使う方法が適しています。公式情報では、秘密度ラベルの設定で「Microsoft Entra条件付きアクセスを使用してラベル付けされたSharePointサイトを保護する」を選び、既存の認証コンテキストを選択する手順が示されています。(Microsoft Learn)
秘密度ラベルを使うと、「社外秘」「法務」「役員会資料」などの分類に応じて、サイト単位の保護設定を標準化できます。ただし、ラベルはTeams、Microsoft 365グループ、SharePointサイトなどのコンテナー設定にも影響するため、単なるファイル分類ラベルとして考えないことが重要です。Microsoft Purviewの説明でも、秘密度ラベルはSharePointサイト、Teams、Microsoft 365グループなどのコラボレーションワークスペースを保護する設定として利用できるとされています。(Microsoft Learn)
| 適用方法 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| サイトへ直接適用 | 少数の重要サイト、検証環境、個別管理したいサイト | 影響範囲を限定しやすい | PowerShell管理が必要。設定漏れや台帳管理に注意 |
| 秘密度ラベル経由 | 機密区分ごとに多数サイトへ展開したい場合 | ガバナンス設計と相性が良い | ラベルの公開範囲、所有者の操作、既存ラベル設計との整合が必要 |
展開前に確認すべきライセンスと前提条件
公式情報では、SharePoint Advanced Managementの前提条件を確認したうえで、Microsoft 365 E5/A5 ComplianceまたはMicrosoft 365 E5 Information Protection and Governanceのいずれかが必要とされています。(Microsoft Learn)
また、SharePoint Advanced Managementの前提条件として、基本サブスクリプション、Microsoft 365 CopilotまたはSharePoint Advanced Management Plan 1アドオン、必要な管理ロール、SharePoint Online PowerShellモジュールなどの確認が必要です。(Microsoft Learn)
展開前には、少なくとも次を確認してください。
| 確認項目 | チェック内容 |
|---|---|
| Microsoft Entraライセンス | 条件付きアクセスを利用できるライセンスがあるか |
| SharePoint Advanced Management | 対象機能を使うための前提条件を満たしているか |
| 管理ロール | 条件付きアクセス管理者、SharePoint管理者、Purview管理者などの役割分担 |
| PowerShell環境 | 最新のSharePoint Online管理シェルを利用できるか |
| 緊急アクセスアカウント | 条件付きアクセスから除外するブレークグラスアカウントがあるか |
| テストユーザー | 管理者ではない検証用ユーザーと検証用グループがあるか |
条件付きアクセスの公式展開ガイドでは、ポリシーを本番適用する前に、緊急アクセスアカウントを除外し、パイロットグループでテストし、ユーザーが必要な認証方法を登録していることを確認するよう案内されています。(Microsoft Learn)
具体的な設定手順
SharePoint向けの認証コンテキストは、次の順序で設計すると失敗しにくくなります。
認証コンテキストを作成する
Microsoft Entraの条件付きアクセス画面で、認証コンテキストを新規作成します。名前と説明を入力し、アプリに発行する設定を有効にして保存します。(Microsoft Learn)
名前は後から管理しやすいように、用途が分かる形にします。
例：
SP-Sensitive-Guest-ToU
SP-Executive-MFA-CompliantDevice
SP-Legal-TrustedLocation「C1」「C2」のような内部IDだけで管理すると、後からポリシーの目的が分かりにくくなります。管理者が複数いる環境では、対象サービス、条件、対象ユーザーを含めた命名にしておくと、誤設定を減らせます。
条件付きアクセス ポリシーを作成する
次に、作成した認証コンテキストを対象にした条件付きアクセス ポリシーを作成します。公式例では、ゲストまたは外部ユーザーを対象にし、クラウドアプリまたはアクションの設定で「認証コンテキスト」を選び、アクセス条件として利用規約への同意を求める流れが示されています。(Microsoft Learn)
実務では、次のように設計します。
| 設定項目 | 例 |
|---|---|
| ユーザー | B2Bゲスト、外部ユーザー、特定部門、役員 |
| 対象 | 作成済みの認証コンテキスト |
| 条件 | 場所、デバイス状態、サインインリスクなど |
| 許可制御 | MFA、認証強度、準拠済みデバイス、利用規約 |
| セッション制御 | 必要に応じてアプリ制御やサインイン頻度 |
| ポリシー状態 | 最初はレポート専用、検証後にオン |
本番前は、いきなり「オン」にするのではなく、レポート専用モードで影響を確認するのが安全です。Microsoftの条件付きアクセス展開ガイドでも、ポリシーを段階的に展開し、有効化前に使用状況をテスト・監視することが推奨されています。(Microsoft Learn)
SharePointサイトまたは秘密度ラベルに適用する
最後に、認証コンテキストをSharePointサイトへ直接適用するか、秘密度ラベルに紐づけます。
直接適用する場合は、Set-SPOSiteを使います。秘密度ラベルを使う場合は、Microsoft Purviewポータルでラベルの「グループとサイト」の保護設定を編集し、外部共有と条件付きアクセス設定を有効にしたうえで、既存の認証コンテキストを選択します。(Microsoft Learn)
制限事項：展開前に必ずテストすべき機能
この設定で最も注意すべき点は、認証コンテキストを有効にしたサイトで利用できないアプリやシナリオがあることです。公式情報では、広範囲に展開する前に、認証コンテキストを有効にしたサイト上でアプリをテストするよう明記されています。(Microsoft Learn)
| 分類 | 制限されるアプリ・シナリオ | 実務上の注意点 |
|---|---|---|
| Officeアプリ | 古いバージョンのOfficeアプリ | 最新版への更新状況を確認する |
| モバイル | SharePointモバイルアプリ（iOS、Android） | モバイル利用者には代替アクセス手段を周知する |
| OneDrive | OneDrive同期アプリは対象サイトを同期しない | 「同期してローカル編集」が前提の部門は影響大 |
| Teams | OneNoteアプリ追加、会議録画アップロード、フォルダー名変更などが失敗する場合あり | TeamsのFilesタブ運用を検証する |
| Outlook | Outlookから保護されたSharePointサイトとの通信は非対応 | 添付・リンク・ファイル参照の業務フローを確認する |
| Power BI / Excel | SharePointリストのPower BI可視化、Excel Web Query（IQY）エクスポートが非対応 | データ分析部門の利用を確認する |
| 複数ファイル操作 | 複数ファイルダウンロード、クロスgeoのコピー・移動に制限あり | ファイル移行や大量操作の前に検証する |
| アプリカタログ | エンタープライズアプリケーションカタログサイトコレクションへの関連付けは非対応 | 開発・配布基盤には適用しない |
特にOneDrive同期アプリの制限は、ユーザー影響が大きくなりやすいポイントです。SharePointを「クラウド上のファイルサーバー」として使っている組織では、同期不可になるだけで業務が止まる部門があります。対象サイトを選ぶ際は、機密性だけでなく「同期前提の業務か」「Teams経由で頻繁に操作されるか」「外部ユーザーがどのアプリからアクセスするか」まで確認してください。
サードパーティ製アプリと開発者が確認すべき点
SharePointサイトに認証コンテキストを設定すると、サードパーティ製アプリや独自アプリも影響を受ける可能性があります。公式情報では、認証コンテキストがアタッチされたサイトを使うサードパーティ製アプリは、クレームチャレンジを処理できる必要があるとされています。(Microsoft Learn)
開発者向けの公式ガイドでは、条件付きアクセス認証コンテキストを使うと、アプリ全体ではなく機密データや機密操作に対して細かなポリシーを適用できると説明されています。また、SharePointの機密ドキュメントを含むサイトコレクションにアクセスする場合、準拠済みデバイスや信頼済みIP範囲を要求する例も示されています。(Microsoft Learn)
開発者が確認すべきポイントは次の通りです。
| 確認項目 | 内容 |
|---|---|
| 認証方式 | OpenID Connect / OAuth 2.0を使ってMicrosoft IDプラットフォームと統合しているか |
| MSAL対応 | Microsoft IDプラットフォームの認証ライブラリを利用しているか |
acrsクレーム | 必要な認証コンテキストがトークンに含まれているか評価できるか |
| クレームチャレンジ | 不足している場合にユーザーをMicrosoft Entra IDへ戻して追加評価できるか |
| ハードコード回避 | 認証コンテキスト値をアプリ内に固定していないか |
| マルチテナント対応 | テナントごとに認証コンテキストIDが異なる前提で実装しているか |
公式の開発者ガイドでは、保護対象の操作でacrsクレームを評価し、必要な認証コンテキストがなければクレームチャレンジを発生させる流れが説明されています。また、認証コンテキスト値をアプリにハードコードしないことも推奨されています。(Microsoft Learn)
バックグラウンドアプリのブロック設定に注意
認証コンテキストをサイトに設定した場合、管理者は特定のアプリケーションプリンシパルに対して、バックグラウンドアプリがそのサイトへアクセスすることを防げます。公式情報では、この機能を使うには、少なくとも1つのアプリケーションプリンシパルが構成された条件付きアクセス ポリシーが必要で、Set-SPOTenant -BlockAppAccessWithAuthenticationContextで明示的に有効化する必要があると説明されています。(Microsoft Learn)
Set-SPOTenant -BlockAppAccessWithAuthenticationContext $true既定値はfalseです。つまり、認証コンテキストを設定しただけで、すべてのバックグラウンドアプリが自動的にブロックされるわけではありません。
ただし、安易に有効化すると、文書管理、監査、バックアップ、DLP、ワークフロー、電子契約、検索連携などのバックエンド処理に影響する可能性があります。設定前に、対象サイトへアクセスしているアプリケーションプリンシパルを棚卸ししてください。
展開時に失敗しやすいポイント
ルートサイトに適用しようとする
SharePointのルートサイトには、この機能を適用できません。対象は、たとえばhttps://contoso.sharepoint.com/sites/researchのようなサイトです。 (Microsoft Learn)
失敗を避けるには、対象サイト一覧を作る段階で、ルートサイト、ハブサイト、Teams接続サイト、OneDrive、アプリカタログサイトなどを分類しておきます。
認証コンテキストだけ作って条件付きアクセス ポリシーを有効にしていない
認証コンテキストは、条件付きアクセス ポリシーと結び付いて初めて意味を持ちます。公式情報では、認証コンテキストをサイトに直接設定していても、そのコンテキストを使うアクティブな条件付きアクセス ポリシーがない場合、複数ファイルのダウンロード機能が動作しないことがあると説明されています。(Microsoft Learn)
設定後は、次の3点を必ず確認してください。
- 認証コンテキストが作成されている
- 条件付きアクセス ポリシーがその認証コンテキストを対象にしている
- ポリシーがレポート専用またはオンの状態で、想定通り評価されている
OneDrive同期を前提にしたサイトへ適用する
OneDrive同期アプリが使えない点は、ユーザーからの問い合わせが増えやすいポイントです。特に、営業、設計、管理部門などがローカル同期を前提に作業している場合、認証コンテキストの適用は慎重に判断してください。
代替案としては、対象サイトを本当に同期禁止にしたい高機密サイトに限定する、Webアクセス中心の運用に切り替える、同期が必要な一般業務サイトとは分ける、といった設計が現実的です。
TeamsとSharePointを別物として扱う
TeamsのFilesタブはSharePointサイトと密接に関係します。SharePointサイトに認証コンテキストを設定すると、Teams経由の操作にも影響が出る場合があります。公式情報でも、Teamsチャネル会議録画のアップロード失敗、TeamsでのSharePointフォルダー名変更失敗、OneNoteアプリ追加の制限などが挙げられています。(Microsoft Learn)
SharePointだけで検証せず、Teamsからのアクセス、会議録画、チャネルファイル、ゲストユーザーの操作もテストしてください。
秘密度ラベルの影響範囲を軽く見る
秘密度ラベル経由の適用は便利ですが、サイト所有者やチーム所有者の操作によってラベルが変更される運用では、認証コンテキストの適用状態も変わる可能性があります。Microsoft Purviewの説明では、外部共有オプションや認証コンテキストのラベル設定を構成・発行すると、サイト所有者がチームまたはサイトの秘密度ラベルを適用・変更することで、それらのオプションを設定・変更できるようになると説明されています。(Microsoft Learn)
管理者だけで制御したいサイトでは、ラベル運用の権限設計を見直してください。
管理者向けの展開チェックリスト
本番展開前には、次の順番で確認すると安全です。
| フェーズ | やること | 完了基準 |
|---|---|---|
| 棚卸し | 高機密サイト、外部共有サイト、Teams接続サイト、OneDrive同期利用サイトを洗い出す | 対象サイト一覧がある |
| 設計 | 直接適用か秘密度ラベル経由かを決める | サイト分類ごとの適用方式が決まっている |
| ライセンス確認 | Entra、SharePoint Advanced Management、Purview関連の要件を確認 | 必要な管理者と対象ユーザーが利用可能 |
| 認証コンテキスト作成 | Microsoft Entraで認証コンテキストを作る | 名前、説明、公開設定が整っている |
| 条件付きアクセス作成 | 対象ユーザー、条件、許可制御を設定する | レポート専用で評価できる |
| パイロット | 少数のサイトとテストユーザーで検証する | ブラウザー、Teams、OneDrive、Outlook、外部ユーザーで確認済み |
| ユーザー周知 | 追加認証、使えないアプリ、問い合わせ先を案内する | 対象ユーザーに通知済み |
| 本番展開 | ポリシーをオンにし、段階的に対象を広げる | サインインログと問い合わせを監視できる |
| ロールバック準備 | ポリシー無効化、対象除外、サイト設定解除の手順を用意する | 障害時の戻し方が明文化されている |
Microsoftの展開ガイドでは、ポリシー有効化前にレポート専用モードで少なくとも一定期間確認し、サインインログを見てから次の段階へ進むことが推奨されています。(Microsoft Learn)
実務でのおすすめ設計
最初から全社のSharePointサイトへ一気に適用するのは避けるべきです。認証コンテキストは、便利な一方でクライアントアプリや業務フローへの影響が大きいため、次の順序で進めると失敗しにくくなります。
まず、対象を「本当に追加条件が必要なサイト」に絞ります。たとえば、役員会資料、M&A、法務、監査、研究開発、人事評価、外部委託先との共有サイトなどです。
次に、ユーザー体験を決めます。ゲストだけ利用規約に同意させるのか、社内ユーザーにもMFAや準拠済みデバイスを求めるのか、信頼済みネットワーク以外からのアクセスを制限するのかを明確にします。
最後に、業務アプリの影響を検証します。特にOneDrive同期、Teams、Outlook、Power BI、Excelエクスポート、サードパーティ製DMSやワークフロー製品を使っている場合は、実ユーザーに近い検証が必要です。
まとめ：次に取るべき行動
Microsoft EntraのConditional Access policy – SharePoint in Microsoft 365は、SharePointサイト単位で強いアクセス制御を実現するための重要な仕組みです。ただし、設定すればすぐ安全になるという単純な機能ではありません。認証コンテキスト、条件付きアクセス ポリシー、SharePointサイト、秘密度ラベル、利用アプリの制限が組み合わさるため、設計と検証が欠かせません。
まずは、機密性の高いSharePointサイトを10件程度に絞って棚卸しし、OneDrive同期やTeams利用の有無を確認してください。そのうえで、1つの認証コンテキストと1つのパイロットサイトを作り、レポート専用モードで影響を見ます。問題がなければ、秘密度ラベルによる標準化や、対象部門への段階展開に進むのが現実的です。
コメント