Microsoft Graph の Sites.Read.All (Delegated) を追加すると、認可画面で「管理者の承認が必要（Need admin approval）」が表示される――2025年に入ってからこの相談が急増しています。本記事では、なぜ「ドキュメント上は Admin consent = No」なのに管理者承認を求められるのか、その背景と確認ポイント、そして現実的な回避・運用パターンまでを、開発者とテナント管理者の双方の視点で詳しく解説します。（2025年11月時点の整理）
結論（先に要点）
- 権限定義そのもの（AdminConsentRequired）と、テナントの「同意ポリシー」の既定値は別物です。Microsoft Graph の権限リファレンス上、
Sites.Read.All (Delegated)は依然として「Admin consent: No」です。 - しかし2025年7月頃から段階的に既定のユーザー同意設定が強化され、ファイル/サイト系の高インパクト権限（
Files.Read.All、Files.ReadWrite.All、Sites.Read.All、Sites.ReadWrite.Allなど）を一般ユーザーが自己同意できないテナントが増えました。結果として UI では「管理者の承認が必要」が出ます。 - よって、「仕様が 権限定義レベルで変わった」というより、テナントの同意ポリシー既定が厳格化されたために体感上「管理者承認必須」に見える――が正しい理解です。
どの設定が影響しているのか
発生要因は大きく以下の2層に分かれます。
| 層 | 何が決まるか | 代表的な設定/状態 | 影響 |
|---|---|---|---|
| 権限定義（API 側） | 権限の性質（Delegated/Application）と「Admin consent 要否」の既定 | Sites.Read.All (Delegated) はドキュメント上「Admin consent = No」 | ここは 2025年でも「No」のまま |
| テナント同意ポリシー（Entra 側） | ユーザーが自己同意可能な権限の範囲 | 「Microsoft 管理の同意ポリシー」や「ユーザー同意の既定」 | 高インパクト権限は自己同意不可 → 認可画面で「管理者の承認が必要」 |
2025年の変更背景（運用が厳格化された）
2025年7月中旬以降、Microsoft 365/Entra ID ではユーザー同意の既定が段階的に厳格化されました。既定が「Microsoft に管理させる（Let Microsoft manage your consent settings）」へ移行したテナントでは、ファイル/サイトへ広域アクセスできる権限を一般ユーザーが同意することがブロックされ、管理者承認へ誘導されます。これにより、Sites.Read.All (Delegated) であっても、テナント設定の観点では管理者承認が必須相当の挙動になります。
重要なのは、「全テナント一律」ではないという点です。既にカスタムの同意ポリシーや「選択した低インパクト権限のみユーザー同意可」にしているテナントなど、管理者が方針を決めている場合は結果が異なります。したがって、まずは自分のテナントの同意設定を確認してください。
まずやるべきテナント側の確認
- ユーザー同意の既定を確認
Entra 管理センター → アプリケーション → エンタープライズ アプリケーション → 同意とアクセス許可 → ユーザーの同意の設定。
ここが「Microsoft に管理させる」または「ユーザー同意を許可しない」になっていると、Sites.Read.Allを含む高インパクト権限は自己同意できません。 - 管理者同意ワークフローの有効化
ユーザーが自己同意できない場合でも、管理者へ承認申請できるようにワークフローを有効化しておくとスムーズです。 - 発行元（Verified publisher）の確認
発行元が未検証のアプリは同意の審査が厳格化されます。可能なら検証済みに。 - エンタープライズアプリの「ユーザーの割り当てが必要」フラグや条件付きアクセスの影響がないかも確認
開発者が押さえるべきポイント
| ポイント | 説明 | 実務ヒント |
|---|---|---|
| AdminConsentRequired と UI の乖離 | 権限定義は「No」でも、テナントの同意ポリシーにより UI で管理者承認が求められる | ドキュメントだけでなく、テナント同意設定を必ず確認 |
| Delegated でも広域は高リスク | 「ユーザーがアクセスできる全サイトに到達できる」ため影響が大きい | 必要最小限に設計し、レビュー可能な権限セットに |
| Sites.Selected の活用 | 対象サイトを絞れるため最小権限化に有効 | ただし Sites.Selected 自体にサイトアクセス権はなく、別途サイトごとの付与が必須 |
| Graph Search の挙動 | /search/query など一部 API は Sites.Read.All / Files.Read.All を要求 | Sites.Selected 単独では動かない用途がある点に注意 |
ケース別の解決アプローチ
ケースA：最短で動かしたい（本番/検証を止めたくない）
- テナント管理者に、当該アプリの 組織全体への同意（Grant admin consent） を依頼。
- 併せて管理者同意ワークフローを有効化し、以後の要求はワークフロー経由で審査。
- 承認後はアプリのアクセスレビュー（四半期ごとなど）を定例化。
ケースB：一部ユーザーだけ自己同意を許したい（例：開発部門のみ）
Entra ID のカスタム同意ポリシーを作成し、特定グループにだけ「指定した権限の自己同意」を許可する運用が可能です。
- 構成例：
「発行元が検証済み」かつ「Microsoft Graph のSites.Read.AllとSites.Selected」に限り自己同意可、という条件セットを作り、開発者グループに割り当て。 - 注意：
高インパクト権限をユーザー自己同意に戻すのはリスク増です。監査ログの監視・定期棚卸し・アプリ審査フローをセットで実装しましょう。
ケースC：アクセス範囲を限定したい（最小権限原則）
Sites.Selected を活用し、アプリに対象サイトのみにアクセスさせます。
- アプリに
Sites.Selected（Delegated または Application）を付与。 - SharePoint 管理者が サイト単位の権限付与（読み取り/書き込み/フルコントロール）を 別途実施。
- アプリからは付与済みサイトの Graph/REST のみ操作可能。
実務上の落とし穴：検索や横断 API など、一部の機能は Sites.Selected だけでは呼べません（/search/query など）。設計段階で API 要件を洗い出し、サイト限定で済むのか／横断読み取りが必要かを先に決めてください。
ケースD：アプリのみ（Application 権限）への切り替え
アプリのみのフローでも、高インパクト権限には管理者承認が必須です。加えて、アプリケーション権限は委任より強力になりがちで、条件付きアクセスの適用方法も変わるため、変更前にセキュリティ設計を見直してください。
よくある誤解と正しい理解
| 誤解 | 正しい理解 |
|---|---|
「2025年に Sites.Read.All (Delegated) の AdminConsentRequired が Yes に変わった」 | 権限定義は現在も No。ただしテナントの同意ポリシー既定が厳格化され、UI 上は管理者承認が求められるケースが増えた。 |
「Sites.Selected を使えば管理者承認は不要になる」 | Sites.Selected (Delegated) 自体は Admin consent が不要だが、テナントの同意ポリシーやサイト単位のアクセス付与が別途必要。さらに /search/query など一部 API は横断権限を要求する。 |
| 「ドキュメントの Admin consent は絶対」 | 権限定義は 必要条件でしかない。テナントのポリシー・条件付きアクセス・発行元検証などが最終挙動を決める。 |
現場で使えるトラブルシュート手順
- 認可 URL を確認（
prompt=consentやprompt=admin_consentを無闇に付けていないか） - アプリの API 権限一覧を棚卸し（不要な広域権限が混じっていないか）
- ユーザー同意の既定を確認（上述のパス）
- 管理者同意ワークフローを有効化し、実際に申請フローが動くか検証
- 発行元検証（Publisher verification）を実施
- Sites.Selected の適用範囲が要件に合うかを再評価（検索や横断閲覧が必要なら
Sites.Read.Allを検討）
役割分担（だれが何をやるか）
| 役割 | 主なタスク | 成果物/チェック |
|---|---|---|
| アプリ開発者 | 最小権限設計、必要 API の洗い出し、認可フロー実装 | 要求権限リスト／認可 URL／テスト手順書 |
| テナント管理者（Entra） | ユーザー同意設定、カスタム同意ポリシー、管理者同意ワークフローの整備 | ポリシー台帳、承認フロー、監査ログ監視ルール |
| SharePoint 管理者 | Sites.Selected のサイト単位付与、サイト権限の定期レビュー | サイト別付与一覧、棚卸し記録 |
| セキュリティ/内部監査 | 高インパクト権限の使用監視、四半期レビュー | 承認履歴、アクセスレビュー報告 |
設計パターンの比較
| パターン | 権限 | 利点 | 注意点 | 向いている用途 |
|---|---|---|---|---|
| 広域読み取り（Delegated） | Sites.Read.All | ユーザーがアクセスできる全サイトで動く、実装が簡単 | テナント既定により管理者承認が必要になりやすい。最小権限に反しがち | 横断検索、複数サイトの一括読取 |
| サイト限定（Application/Delegated） | Sites.Selected ＋ サイト別付与 | 最小権限、事故時影響が限定的 | サイト付与の運用が必要。/search/query など横断 API は別権限が要る | 特定サイトのバッチ処理、製品連携 |
| SharePoint REST/アドイン権限 | アドイン権限/アプリカタログ | 歴史的互換性、サイト限定の実装も可能 | 運用と開発の複雑さ。将来性/モダン化の検討が必要 | 既存資産の延命、限定要件 |
セキュリティと運用のベストプラクティス
- 最小権限の原則：最初から
Sites.Read.Allに寄らず、本当に必要な API と範囲を見極める。 - 権限の段階的付与：検証では
Sites.Selectedでサイト限定、要件で横断が必要ならリスク評価を経てSites.Read.Allを追加。 - 承認フローの整備：管理者同意ワークフローを常時有効化し、開発者や ISV の申請を稼働させる。
- 発行元検証とアプリ審査：発行元未検証アプリの導入は原則禁止。検証済みを前提に内規を整備。
- 監査と棚卸し：四半期ごとに「どのアプリがどの権限を持ち、どれだけ使われたか」をレビュー。
実装時のチェックリスト（保存版）
- 要求権限はサイト限定で足りるか？横断検索は要るか？
- 同意エラーの再現条件（ユーザー/グループ/デバイス/ネットワーク）を特定したか？
- テナントのユーザー同意の既定は何か？
- 管理者同意ワークフローは動作しているか？承認 SLA は？
- 発行元検証の状態は？アプリケーション登録のメタデータは整っているか？
- Sites.Selected のサイト付与手順は標準化され、だれが実行するか明確か？
「Need admin approval」画面が出たときの即応
- 該当アプリの API 権限を洗い出し、
Sites.Read.All/Files.Read.Allといった高インパクト権限が含まれていないか確認。 - テナント管理者に承認リクエストを送付（管理者同意ワークフロー推奨）。
- 恒久対応として、カスタム同意ポリシーの整備または Sites.Selected への再設計を検討。
FAQ
Q. どうしてドキュメントでは「Admin consent: No」なのに UI が管理者承認を求めるの？
A. 権限定義とテナントの同意ポリシーは別レイヤーです。後者が厳格化された結果、UI は管理者承認を要求します。
Q. 一般ユーザーだけで自己同意できる方法は？
A. 2025年の既定では原則不可です。どうしても必要ならカスタム同意ポリシーで対象ユーザーや権限を限定的に許可し、厳密な監査とレビューをセットで。
Q. Sites.Selected にすればすべて解決？
A. サイト限定には有効ですが、/search/query など一部 API は横断権限を要求するため、要件次第です。
実務テンプレ（依頼文例）
件名: Graph API "Sites.Read.All (Delegated)" の管理者承認依頼
内容:
- アプリ名: Contoso SharePoint Viewer
- 要求権限: Sites.Read.All (Delegated)
- 目的: ユーザーがアクセス可能なサイトの横断読み取り（検索/一覧）
- 代替検討: Sites.Selected でのサイト限定は要件を満たさない（横断検索あり）
- 監査: 四半期のアクセスレビューに含めます
- 期日: MM/DD まで
ご確認のうえ、Entra 管理センター > エンタープライズ アプリ > (当該アプリ) > アクセス許可 > [組織のために管理者の同意を与える] を実施ください。
まとめ
Sites.Read.All (Delegated)自体の権限定義は「Admin consent: No」のまま。しかし2025年の同意ポリシー厳格化により、実運用では管理者承認が必要になるケースが一般的になりました。- 短期対応は管理者承認の取得、中長期はカスタム同意ポリシー整備やSites.Selected による最小権限化で運用負荷とリスクを同時に下げるのが定石です。
- 検索や横断 API を使う場合は
Sites.Selectedだけでは足りないことがあるため、要件とセキュリティのバランスを評価し、関係者（開発/Entra 管理/SharePoint 管理/セキュリティ）で合意形成してください。
補足：迅速な「想定される対処手順」チェック
- テナント管理者にアプリの組織同意を依頼。
- Entra の ユーザー同意設定を確認し、必要時はカスタム同意ポリシーを作成して対象ユーザー/許可権限を限定。
- 最小権限の原則に沿って Sites.Selected を併用し、むやみに広域権限へ依存しない設計へ。
- 四半期ごとのアクセスレビューと監査ログのモニタリングを標準運用に。
コメント