SharePoint のドキュメント ライブラリを自動で読み取り／書き込みしたくて Microsoft Entra（旧 Azure AD）のアプリ登録に権限を追加したのに、「Need admin approval（管理者の承認が必要）」で先に進めない…。この現象は、要求している権限が強く、管理者による Admin consent（管理者の同意）が必須になっているケースがほとんどです。仕組み・承認手順・管理者の探し方をまとめます。
「Need admin approval」が出るときに起きていること
このメッセージは、ざっくり言うと次のどちらか（または両方）が原因です。
- 要求している API 権限が「一般ユーザーでは同意できない権限」（＝管理者のみ同意可能）
- テナント設定で「ユーザーがアプリに同意する」こと自体が制限されている（ユーザー同意を無効化／限定）
SharePoint のサイトやファイルに対する広範な読み取り／書き込み権限は、情報漏えい・改ざんリスクが大きいため、Microsoft 側でも管理者の同意が必須になる設計が多いです。特に自動処理（ユーザーが操作しないバッチ／RPA／サーバー処理）で使うアプリケーション権限（Application permissions）は、原則として管理者同意が必要になります。
まず押さえる：委任された権限とアプリケーション権限の違い
同じ「読み取り／書き込み」でも、どの種類の権限を選ぶかで、同意フロー・必要ロール・実装が変わります。
| 項目 | 委任された権限（Delegated） | アプリケーション権限（Application） |
|---|---|---|
| 動作イメージ | ユーザーとして動く（ログインした人の権限の範囲） | アプリとして動く（ユーザー不在でも動作） |
| 代表的な用途 | ユーザー操作がある Web アプリ／アドイン／対話型ツール | バッチ処理、バックエンド処理、RPA、サーバー間連携 |
| 同意（consent） | 権限の強さとテナント設定によって、ユーザー同意できる場合もある | 管理者同意が必要になるケースが非常に多い |
| トークンの特徴 | スコープ（scp）を持つことが多い | ロール（roles）を持つことが多い（.default を使うことが多い） |
| 「Need admin approval」になりやすさ | 中〜高（要求権限が強いと出る） | 高（特に SharePoint 全体に効く権限は出やすい） |
SharePoint の自動読み書きで「強い権限」になりやすいパターン
SharePoint のドキュメント ライブラリを自動処理する場合、Microsoft Graph の権限（または SharePoint API 権限）を追加することが多いです。ここで「全サイト対象」の権限を選ぶと、管理者同意がほぼ必須になります。
| やりたいこと | よく使われる権限例（Microsoft Graph） | 管理者同意が必要になりやすい理由 | 現実的な推奨 |
|---|---|---|---|
| SharePoint 全体のファイルを読み取り | Sites.Read.All / Files.Read.All | 全サイトのデータにアクセス可能になる | 可能なら Sites.Selected へ寄せる |
| SharePoint 全体のファイルを読み書き | Sites.ReadWrite.All / Files.ReadWrite.All | 全サイトのデータ変更が可能（改ざんリスクが高い） | Sites.Selected + 対象サイトだけ Write が安全 |
| 特定のサイトだけ読み取り／書き込み | Sites.Selected | 権限自体は強いが、別途サイト単位で割り当てる設計 | 最小権限として最有力 |
| ユーザーが操作するアプリでファイル操作 | Files.ReadWrite（委任）など | ユーザー同意可の範囲に収まる場合があるが、テナント設定次第 | 対話型なら委任も検討（ただし要件次第） |
自動処理が目的なら、安易に Sites.ReadWrite.All を付けてしまうより、Sites.Selected をベースに「必要なサイトだけ」許可する設計のほうが、セキュリティ監査・社内承認・運用が圧倒的に通りやすいです。
管理者が行う「Admin consent（管理者の同意）」の実施手順
アプリ登録で権限を追加しただけでは、実際には利用できません。管理者がテナント全体に対して同意（Grant admin consent）して初めて、「アプリがその権限を使ってよい」という状態になります。
Entra 管理センターで同意する（基本ルート）
- 管理者が Microsoft Entra 管理センターにサインイン
- アプリケーション → アプリの登録 → 対象アプリを開く
- API のアクセス許可（API permissions） を開く
- 追加した権限に「管理者の同意が必要」「未承認」等の表示があることを確認
- 「（テナント名）に管理者の同意を付与（Grant admin consent）」 を実行
- 状態が「Granted（承認済み）」相当になっていることを確認
承認の確認で見るべきポイント
| 確認ポイント | 見る場所 | 期待される状態 | よくある落とし穴 |
|---|---|---|---|
| 権限が承認済みか | アプリ登録 → API permissions | テナントに対して承認済みの表示 | 追加しただけで承認したと思い込む |
| 権限の種類（委任／アプリ） | 同上 | 用途に合った種類になっている | 自動処理なのに委任権限を付けてしまう |
| 利用する API が正しいか | 同上 | Microsoft Graph か SharePoint かが要件通り | Graph と SharePoint API を混在して設計が破綻 |
| 権限が過剰でないか | 同上 | 最小権限に近い | Sites.ReadWrite.All を安易に付ける |
Admin consent を実行できる管理者ロール
管理者の同意は、誰でも実行できる操作ではありません。通常、次のような Entra のディレクトリ ロールを持つユーザーが実行できます（組織の運用方針で制限している場合もあります）。
| ロール | できること（要点） | よくいる部署・立場 | 依頼するときの一言例 |
|---|---|---|---|
| グローバル管理者（Global Administrator） | ほぼすべての管理操作が可能（最強） | 情シス／M365 全体管理 | 「アプリ登録の Graph 権限に管理者同意が必要です。Grant admin consent をお願いします」 |
| クラウド アプリケーション管理者（Cloud Application Administrator） | アプリとエンタープライズ アプリの管理、同意の付与など | Entra 運用担当 | 「対象アプリ（アプリID: xxxx）の API permissions の管理者同意が必要です」 |
| アプリケーション管理者（Application Administrator） | アプリの管理・同意付与など（組織設定により範囲差あり） | アプリ運用担当 | 「SharePoint 自動処理のため、Graph の Sites 系権限に同意が必要です」 |
| 特権ロール管理者（Privileged Role Administrator） | ロール付与・特権管理が中心（同意の実行役というより適任者をアサインできる立場） | PIM/ロール管理担当 | 「管理者同意を実行できるロールの方をご紹介／一時付与できますか？」 |
ポイントは、「承認できる人が限られる」ということです。開発担当者がアプリ登録を作成できても、組織のガバナンス上、管理者同意だけは別の担当者しかできない運用はよくあります。
一般ユーザー側でできる「申請」の動き方
組織の設定によっては、サインイン時の同意画面に「管理者に承認を要求（Request admin approval / Request admin consent）」のようなボタンが出る場合があります。この場合、ボタンから申請すると、指定された管理者（承認ワークフロー担当）へ通知が飛びます。
申請文は「権限の理由」と「範囲」を具体的に書く
管理者は「本当に必要か」「過剰ではないか」「どのデータに触れるか」で判断します。申請時に次の情報を添えると通りやすくなります。
| 書くべき情報 | 例 | 管理者が安心するポイント |
|---|---|---|
| 用途 | 「毎日 9:00 に請求書 PDF を特定ライブラリへ格納」 | 目的が明確で、勝手に広がらない |
| 対象範囲 | 「A サイトの ‘Docs’ ライブラリのみ」 | 全社横断ではない |
| 最小権限の工夫 | 「Sites.Selected を採用し、対象サイトのみ Write を付与」 | 権限が絞られている |
| 運用（責任者） | 「運用責任者：情報システム部 △△」 | 問題時の連絡先が明確 |
申請ボタンが出ない場合は、テナント側で「ユーザーの同意要求」を無効化している可能性が高いです。その場合は、素直に社内の情シス／Entra 管理担当へ依頼するのが最短です。
テナント管理者（承認できる人）の探し方
「管理者に頼め」と言われても、そもそも誰か分からないのが一番つらいところです。現実的な探し方を、権限状況別に整理します。
Entra ポータルに入れる場合（最短で確実）
- Microsoft Entra 管理センターにアクセス
- ロールと管理者（Roles & admins） を開く
- すべてのロール（All roles） から、次のロールを検索して開く
- Global Administrator
- Cloud Application Administrator
- Application Administrator
- ロールの画面で割り当てられているユーザーを確認し、社内チャットやメールで連絡
Microsoft 365 管理センターに入れる場合（M365 運用から辿る）
Microsoft 365 管理センターにアクセスできる人なら、ロール一覧から管理者を特定できることがあります（ただし見える範囲は権限次第です）。
- 管理センター → 役割（ロール） → 管理者ロールの割り当てを確認
- 情シス／運用窓口に回す（「アプリの管理者同意が必要」まで言うと話が早い）
どの管理ポータルにも入れない場合（現場で多い）
この場合、技術的に“自力で特定”するより、組織の運用ルートに乗せるほうが現実的です。
| 状況 | おすすめの動き | 伝えるべきキーワード |
|---|---|---|
| 情シス／ヘルプデスクがある | チケットを切る（最速） | 「Entra アプリ登録」「API permissions」「Grant admin consent」「Need admin approval」 |
| 開発部門の管理者がいそう | 社内の M365 管理担当を紹介してもらう | 「SharePoint 自動処理」「Graph 権限の管理者同意」 |
| それでも窓口が不明 | 契約／ライセンス管理者、購買、セキュリティ担当から辿る | 「テナント管理者（Global Admin）を探している」 |
| 組織として窓口が機能していない | Microsoft サポートへ相談（契約形態により窓口が異なる） | 「テナントの管理者を特定したい」「アプリの admin consent が必要」 |
実務的には、「Need admin approval が出ており、管理者同意が必要」と明確に言うと、たらい回しが減ります。「SharePoint 権限が足りない」だけだと、SharePoint 側の権限付与と勘違いされがちです。
承認後にまだ動かないときのチェックリスト
管理者が同意したのにエラーが続く場合、権限の付け方・トークン取得・サイト単位の許可など、別のポイントで詰まっていることがあります。
| 症状 | ありがちな原因 | 対処 |
|---|---|---|
| API permissions で承認済みに見えるのに、サインインで止まる | 別テナントで実行している／アプリが別の登録を参照している | テナントID、クライアントIDが一致しているか再確認 |
| クライアント資格情報フローで 401/403 | scope を誤っている（.default を使っていない等） | Graph なら https://graph.microsoft.com/.default を利用する設計か確認 |
| 403 Access denied が続く（SharePoint/Graph） | Sites.Selected を付けたが、サイト単位の許可を与えていない | 対象サイトへアプリ権限（read/write）を別途付与する |
| 委任権限で実装したのに動かない | 実装要件が「ユーザー不在」なのに委任で作っている | アプリケーション権限（アプリとして動く）へ見直し |
| 承認は済んだがセキュリティ部門から NG | Sites.ReadWrite.All 等が過剰 | Sites.Selected に変更、対象サイト限定、監査ログ設計を提示 |
実運用で効く：最小権限・監査・事故防止のコツ
SharePoint の読み書き自動化は便利な一方で、権限が強いと「アプリが侵害された瞬間に全社のファイルが危ない」状態になりえます。管理者同意を通しやすくする意味でも、次の運用設計が効きます。
| 観点 | おすすめ | 理由 |
|---|---|---|
| 権限 | Sites.Selected を基本にし、対象サイトだけ read/write | 権限の爆発（全サイトアクセス）を防げる |
| 認証 | 可能なら 証明書（certificate）を使う | クライアントシークレットより漏えいリスクを下げやすい |
| 更新・ローテーション | 期限管理・ローテーション手順を作る | 運用事故（期限切れ停止）を防ぐ |
| 監査 | サインインログ／監査ログでアプリの操作を追えるようにする | 「いつ誰が何をしたか」の説明責任を担保 |
| 対象データ | 専用ライブラリ／専用サイトに寄せる | 保護すべき領域と自動処理領域を分離できる |
具体例：Sites.Selected で“特定サイトだけ”読み書きさせる流れ
「Need admin approval を回避する」こと自体は難しくありませんが、権限を絞って承認されやすくするのが現実的な勝ち筋です。ここでは代表例として Sites.Selected の流れを整理します。
手順の全体像
- アプリ登録で Microsoft Graph の Application permissions に
Sites.Selectedを追加 - 管理者が Grant admin consent を実行
- 別途、対象サイトに対してアプリへ Read / Write を付与（サイト単位の許可）
- アプリが Graph 経由で対象サイトのドキュメント ライブラリを操作
（参考）サイト単位の許可付与に PnP PowerShell を使う例
組織の標準ツールや権限設計によって方法は変わりますが、よく使われる方法の一つが PnP PowerShell です。管理者（SharePoint 管理者やグローバル管理者など適切な権限者）が実行します。
Connect-PnPOnline -Url https://<tenant>-admin.sharepoint.com -Interactive
# 例：特定サイトに対して、アプリに Write 権限を付与
Grant-PnPAzureADAppSitePermission `
-AppId <アプリ(クライアント)ID> `
-DisplayName "SP-AutoProcessor" `
-Site https://<tenant>.sharepoint.com/sites/<siteName> `
-Permissions Write
# 付与状態の確認
Get-PnPAzureADAppSitePermission -Site https://<tenant>.sharepoint.com/sites/<siteName>
この「サイト単位の許可」を忘れると、Admin consent を通しても 403 が続きます。Sites.Selected は“同意だけでは足りない”のが重要ポイントです。
よくある誤解
| 誤解 | 実際 | 補足 |
|---|---|---|
| 「アプリ登録で権限を追加した＝使える」 | 追加しただけでは未承認。管理者同意が必要な権限は特に注意 | API permissions の状態を必ず確認 |
| 「SharePoint のサイト権限を付ければ OK」 | Entra の同意（OAuth 同意）とSharePoint のアクセス制御は別物 | Sites.Selected だと“両方”必要になることがある |
| 「Need admin approval はエラーだから回避が正義」 | むしろ安全装置。手順に沿って適切に承認するのが正攻法 | 権限を絞るほど承認されやすい |
まとめ
SharePoint のドキュメント ライブラリを自動で読み取り／書き込みする権限は強力であるため、「Need admin approval（管理者の承認が必要）」が出るのは自然な挙動です。解決のポイントは次の 3 つです。
- どの権限（委任／アプリケーション）を要求しているかを整理する
- 管理者ロールを持つ担当者に Admin consent を実行してもらう
- 可能なら Sites.Selected を使って対象範囲を限定し、承認も運用も通しやすくする
「誰に頼めばいいか分からない」場合でも、Entra のロール割り当て確認や情シス窓口への依頼で、必ず道が開けます。承認をゴールにせず、最小権限と運用設計までセットで進めるのが、トラブルを減らす近道です。
コメント