WordPressのOAuth/OIDCプラグインでMicrosoft Entra ID（旧Azure AD）を使ってSSOを設定したのに、一般ユーザーのサインイン時に「同意」や「管理者の同意」ポップアップが出てしまうケースがあります。スコープを最小（openid / profile / email）にしても発生する理由と、ポップアップを出さないための具体策（同一テナント・マルチテナント両方）を整理します。
よくある状況：スコープは最小なのに同意画面が表示される
WordPress側のOAuth/OIDCプラグインでEntra IDに接続し、アプリ登録で付与しているスコープが openid / profile / email のみ。ポータル上でも 「Admin consent required: No」 と表示されている。
それにもかかわらず、一般ユーザーがSSOすると同意画面が表示され、場合によっては「管理者の承認が必要」系のメッセージに見えるポップアップが出てしまう……というのが典型的なハマりどころです。
「Admin consent required: No」の意味を正しく理解する
まず最重要ポイントとして、ポータルに表示される 「Admin consent required: No」＝同意が一切不要 ではありません。
| 表示 | 本当の意味 | 起こり得る挙動 |
|---|---|---|
| Admin consent required: No | ユーザー自身が同意してよい種類の権限 | 管理者の事前承認が無い場合、初回ログイン時にユーザー同意画面が出る |
| Admin consent required: Yes | 管理者しか同意できない権限 | 一般ユーザーは同意できず、管理者同意が必須 |
openid / profile / email は「ユーザーが同意してよい」権限なので、テナント管理者の承認がなくても、ユーザーが初回に「承諾」すれば使い始められます。ですが裏を返すと、テナント全体で事前承認されていない限り、初回に同意画面が出るのは自然な挙動です。
ポイント：「Admin consent required: No」は“管理者がいなくても使い始められる”という意味であり、“同意画面が絶対に出ない”という保証ではありません。
同意画面が出るパターンは大きく2つ
初回だけ出るパターン
多くの環境では、ユーザーが初回に同意（承諾）すれば、そのユーザーに対しては2回目以降は同意画面が出なくなります。これは「ユーザー単位の同意」が保存されるためです。
- ユーザーA：初回のみ同意 → 以後は同意画面なし
- ユーザーB：初回は未実施 → 初回ログイン時に同意画面が出る
つまり、ユーザーごとの初回体験としては消えるが、組織全体としてはユーザーが増えるたびに初回ポップアップが残り続ける、という状態になります。
毎回出るパターン
「一度同意しているのに毎回出る」「管理者同意済みのはずなのに毎回出る」場合は、SSOの要求パラメータやプラグイン設定が原因になっていることが多いです。最頻出は prompt=consent の混入です。
最重要チェック：認可リクエストに prompt=consent が付いていないか
OAuth/OIDCの認可リクエストURLに prompt=consent が付いていると、Entra IDは「毎回必ず同意画面を表示」します。管理者同意が完了していても、ユーザーが以前に同意していても、強制的に同意画面が出ます。
WordPressのOAuth/OIDCプラグインは、設定画面で「追加パラメータ」や「認可エンドポイントURLのカスタマイズ」ができるものがあります。そこに prompt 指定が入っていないか、まず確認してください。
| prompt値 | 動作 | よくある落とし穴 |
|---|---|---|
| consent | 毎回同意画面を強制表示 | 同意済みでも毎回ポップアップになる |
| none | 画面表示なしで進める（条件を満たさないとエラー） | サインインセッションが無いと「SSOに必要なセッション情報が不足」等で失敗しやすい |
| login | 毎回ログイン画面を強制 | SSOの良さが消える（毎回資格情報入力が必要になりがち） |
対処の基本方針はシンプルです。
- prompt=consent を削除する
- 無理に prompt=none を付けない（運用上エラーになりやすい）
- prompt は指定しない（既定動作に任せる）のが最も安全
prompt=none がエラーになるのは仕様
質問でよくあるのが「prompt=none を付けたら “Session information is not sufficient for single-sign-on” のようなエラーになった」というものです。これは不具合ではなく、対話なしで処理するための前提条件が満たせていないだけです。
- ブラウザに有効なサインインセッションがある
- 必要なポリシー（MFA要求など）を対話なしでクリアできる
- 条件付きアクセスで追加操作が要求されない
これらが揃わないと、対話を出せない以上、Entra IDはエラーを返します。したがって「同意画面を消すために prompt=none を付ける」のは、SSOの安定運用という観点ではおすすめしません。
同一テナント内で全ユーザーのポップアップを消す方法
同じテナント内の全ユーザーに対して、初回から同意画面を出したくない場合、実務上の答えはひとつです。テナント管理者による管理者同意（テナント全体への事前承認）を付与します。
ポータルで管理者同意を付与する手順
- Entra ID（Azureポータル）で対象のアプリ登録（またはエンタープライズアプリ）を開く
- API アクセス許可 を開く
- 「（組織名）に管理者の同意を与える」（Grant admin consent for …）を実行する
これにより、そのテナント内のユーザーは、初回から同意操作なしでサインインできるようになります。
補足：「管理者同意が不要」と表示される権限でも、テナント全体への事前同意を行うこと自体は可能です。ユーザーに“承諾ボタンを押させない”のが目的なら、この事前同意が最も確実です。
管理者同意をしたのに同意画面が消えないときの切り分け
「管理者同意を押したのにまだ出る」場合は、“同意が必要な状態”ではなく、“同意画面を強制している状態”や、“実際には別の権限を要求している状態”が多いです。次のチェックリストで潰していくと早いです。
| チェック項目 | 確認方法 | 対処 |
|---|---|---|
| prompt=consent が付いている | プラグインの認可URL設定、追加パラメータ、ログ、ブラウザのアドレス（リダイレクト直前） | prompt=consent を削除 |
| 要求している scope が想定より多い | 実際の認可リクエストURLの scope パラメータを確認 | プラグイン設定を見直し、openid profile email のみにする |
| 別のアプリ登録（クライアントID）を参照している | WordPress側のクライアントIDと、ポータルのアプリIDを照合 | 設定のクライアントID・テナントIDを統一 |
| テナント側でユーザー同意が制限されている | 管理者が同意させない方針（ユーザー同意禁止・制限）があるか確認 | 事前に管理者同意する、またはポリシーに沿って運用設計する |
| 条件付きアクセスやMFAで対話が必要 | 対象ユーザーにMFA要求があるか、条件付きアクセスポリシーを確認 | prompt=none を使わず、標準の対話ありフローで運用する |
特に「ポータル上では openid/profile/email だけのつもり」でも、プラグインが内部で追加のスコープを付けたり、別のエンドポイント向け設定が混在していたりすると、同意画面の内容が想定とズレます。最終的には“実際に飛んでいる認可リクエストURL”が正なので、ここだけは必ず確認してください。
マルチテナントで別会社テナントに事前同意させたい場合
次に、Company A が作ったマルチテナントアプリを Company B のテナントで使うケースです。結論から言うと、Company B 側の管理者の関与なしに、Company B テナント全体への事前同意を付与する方法はありません。
- Company A 側の管理者が、Company B テナントに“勝手にホワイトリスト登録”することはできない
- テナント全体の同意は、同意を付与するテナント側の管理者権限が必要
この制約は「仕組みとしてそうなっている」ため、回避策を探すよりも、管理者に負担をかけず最短で同意してもらう導線を作るのが現実解です。
マルチテナントの同意パターン
| パターン | 誰が承諾するか | 影響範囲 | ポップアップは消えるか |
|---|---|---|---|
| ユーザー同意 | 一般ユーザー | そのユーザーのみ | そのユーザーは2回目以降消えるが、他ユーザーは初回に出る |
| 管理者同意 | グローバル管理者、Cloud Application Administrator等 | テナント全体 | 全ユーザーで初回から出なくなる |
管理者の手間を最小化する方法：Admin Consent URL を渡す
管理者が忙しく、ポータル操作に時間を割けない場合でも、Admin Consent URL（管理者同意URL）を渡すと、クリックして承諾するだけでテナント全体への同意を完了できます。
概念としては次のようなURLを管理者に渡します。
https://login.microsoftonline.com/organizations/v2.0/adminconsent
?client_id=＜アプリのクライアントID＞
&scope=＜必要なスコープ一覧＞
&redirect_uri=＜同意後に戻るURL＞
&state=＜任意の値＞このURLに Company B の管理者（グローバル管理者または同意権限を持つ管理者ロール）がアクセスしてサインインし「承諾」すれば、Company B テナント全体で事前承認された状態になります。以降、Company B の一般ユーザーは初回から同意ポップアップなしでSSOできます。
Admin Consent URL のパラメータ設計の注意点
| 項目 | 意味 | 実務上の注意 |
|---|---|---|
| client_id | アプリ登録のクライアントID | WordPress側に設定しているものと一致させる |
| scope | 要求するスコープ | まずは最小（openid profile email）。必要があれば段階的に増やす |
| redirect_uri | 同意後の戻り先 | アプリ登録に登録済みのURLと完全一致が必須（末尾スラッシュ差も要注意） |
| state | CSRF対策や追跡用 | 推測されにくい値を入れ、戻り先で照合できると安全 |
重要：Admin Consent URLは“管理者の作業を簡単にする”ためのショートカットであり、管理者の承諾そのものを不要にする手段ではありません。最終承認は必ずCompany B側の管理者が行う必要があります。
管理者に送る依頼文テンプレ
「ポータルでここを押してください」よりも、「このURLを開いて承諾してください」のほうが対応率が上がりやすいです。以下はそのまま使えるテンプレ例です。
件名：WordPress SSO（Microsoft Entra ID）利用のための管理者同意のお願い
お疲れ様です。
Company Aが提供するWordPress SSO連携をCompany Bテナントで利用するため、
アプリへのテナント全体の管理者同意が必要です。
以下のURLを管理者権限（グローバル管理者または同等権限）で開き、
表示される画面で「承諾」をお願いします。
＜Admin Consent URL＞
（ここにURL）
承諾後、Company Bテナントの全ユーザーが初回から同意ポップアップなしでSSO可能になります。
ご不明点があればご連絡ください。現場でのおすすめ手順まとめ
「プラグイン設定」「同一テナント」「マルチテナント」を混ぜると混乱しやすいので、判断を表にまとめます。
| 状況 | 目的 | やること | 誰が対応するか |
|---|---|---|---|
| 同一テナントで全員ポップアップを消したい | 初回から無人SSOに近づける | ポータルで「組織に管理者同意」を付与 | テナント管理者 |
| 同意済みなのに毎回ポップアップ | 毎回表示の根絶 | prompt=consent を削除、実際のscopeを確認 | WordPress管理者・アプリ管理者 |
| 別会社テナントで全員ポップアップを消したい | 導入時の問い合わせ削減 | Admin Consent URLを作り、相手管理者に承諾してもらう | 相手テナント管理者 |
| 相手管理者が同意してくれない | 最低限の利用開始 | 各ユーザーが初回にユーザー同意する運用にする | 各ユーザー |
よくある落とし穴と対策
スコープを3つにしたのに「管理者の承認が必要」表示になる
表示上は「管理者の同意」ポップアップに見えても、実態としては次のどれかが混ざっていることがあります。
- テナント側ポリシーで「ユーザー同意」が制限されていて、ユーザー同意できない
- プラグインが追加スコープを要求しており、実際には管理者同意が要る権限を含んでいる
- 別のクライアントIDや別環境（テスト用/本番用）が混在している
この場合も、まずは「実際に送っている認可リクエストURL（scopeとprompt）」の確認が最短ルートです。
ユーザー体験を良くするなら最初にやるべきこと
- WordPress側で prompt=consent を入れない
- scopeは最小から始め、追加が必要になったら段階的に増やす
- 組織内利用なら、初期導入時に管理者同意までセットで実施する
- マルチテナントなら、導入手順書にAdmin Consent URLを含め、相手管理者の作業を1クリックに寄せる
まとめ
「Admin consent required: No」でも同意画面が出るのは珍しくありません。これは「ユーザーが同意してよい権限」という意味であって、「同意が不要」という意味ではないためです。全ユーザーに初回からポップアップを出したくないなら、同一テナントでもマルチテナントでも、基本は管理者同意によるテナント全体の事前承認が必要になります。
そして、毎回ポップアップが出るときは、多くの場合 prompt=consent が原因です。まずここを潰し、次に実際のscopeとテナント側の同意ポリシーを確認する。これが、WordPress×Entra IDのSSOを安定運用するための最短手順です。
コメント