はじめに
こんにちは、ネクストモード株式会社のiwaです。
先日、「SSOを設定しているのに、Okta経由ではGoogle Workspaceへのログインに失敗し、Googleのパスワードを使ったログインだけ成功する」という相談がありました。
調べる中で見えてきたのは、Google Workspaceでは、特権管理者と一般ユーザーでSSOの扱いが異なるという点です。
これは、エラーが起きたときだけでなく、SSOを導入・見直しするときにも知っておきたい仕様です。
特権管理者も、一般ユーザーと同じSSO設定で使える？
一般用と管理用を分けるなら、何を分ければよい？
強い管理者権限を踏まえて、どう設計すればよい？
この記事では、SSOプロファイルの違いを押さえたうえで、日常用・管理用アカウントの分離と、必要に応じたOktaアプリの使い分けを整理します。
新旧の仕様や提供時期の補足は、後半のQ&Aにまとめました。
本記事は、GoogleとOktaの公式ドキュメントを中心に、一次情報をもとに整理しています。
結論
この記事の結論
- 特権管理者は、新方式のSSOではサインインできません。SSOを使う場合は、Legacy SSOプロファイルと、対応するログイン経路が必要です。[1][2]
- まず分けたいのは、日常用と管理用のアカウントです。本記事の基本案では、日常用のOkta SSOは継続し、管理用だけGoogleで直接認証します。全社で必ず新旧2つのSSOプロファイルが必要、という意味ではありません。[1][8]
- 管理用にもSSOが必要な場合に、プロファイルとアプリを使い分けます。一般用は新方式、管理用はLegacyへ接続するOktaの構成例があります。ただし、分けても特権管理者の権限そのものが狭くなるわけではありません。[5][10]
まず押さえたい、一般ユーザーと特権管理者の違い
SSO（シングルサインオン）は、OktaなどのIdP（認証を担うサービス）で認証し、その結果をGoogle Workspaceなどのサービスへ渡してログインする仕組みです。
Google側では、連携相手や証明書などをSSOプロファイルに設定します。
Googleには、組織向けの従来方式「Legacy SSOプロファイル」と、複数のIdPに対応する「SSOプロファイル」があります。
本記事では後者を「SSOプロファイル（新方式）」と呼びます。「新方式」は、最近できた設定という意味ではありません。[2][3]
SSOプロファイルは、同じGoogle Workspace組織の中に作る、認証連携設定のまとまりです。テナントを複数作る話ではありません。
OU（組織部門）やグループに使うプロファイルを割り当て、会社ごとのIdPの違いに対応したり、新設定を一部のユーザーで試したりできます。[3][13]
大切なのは、新方式は特権管理者のSSOに対応していないことです。
特権管理者のままSSOを利用する場合は、Legacyでサポートされる経路を選びます。[1][2]
新旧プロファイルで、SSOできる対象が違う
管理コンソールへの直接サインインは、別の経路
特権管理者がadmin.google.comから新たにサインインする場合は、LegacyでもSSOへ転送されず、Googleの認証情報を使います。
図1 上段はOktaのアプリタイルから開始するSAML SSOを比較。両側の連携設定と利用者への適用が整っていることが前提です。Legacyは特権管理者専用ではなく、一般ユーザーも利用できます。Google・Okta公式資料をもとに作成。[1][2][4][5]
この違いは、「一般ユーザーと特権管理者は、必ず別のプロファイルに分けなければならない」という意味ではありません。
一般用に新方式を使いつつ、特権管理者にもSSOを提供するなら、Legacyを使う経路を別に用意する、という整理です。[1][5]
プロファイルを分ける前に、権限の大きさを考える
特権管理者は、Google管理コンソールやAdmin APIのすべての機能へアクセスでき、組織のアカウント全体を管理できるロールです。「一般ユーザーより少し設定を多く変更できる人」ではありません。
管理者ロールの付与、他の管理者の管理、ドメイン全体の委任など、影響の大きい操作も含まれます。[10]
特権管理者までIdP経由で認証できると、認証を一元化できる一方、IdPが侵害されたときに、Google管理コンソールや組織全体へ影響が及ぶリスクがあります。
Googleもこの利点とリスクを説明し、特権管理者のSSOを有効にする場合は、IdPとGoogleの両方で2段階認証を有効にすることを推奨しています。[1]
このリスクがあるため、「SSOで入れるようになった」で設計を終わらせず、誰に特権管理者権限が必要か、日常業務でもその権限を持たせる必要があるかを先に考えたいところです。
Googleは、日常業務には管理者権限のない別アカウントを使い、通常の管理作業も必要に応じて権限を限定した管理者ロールに委任することを推奨しています。[8]
プロファイルの分離と、権限の分離は別の話です。
一般用・管理用のSSO経路を分けても、特権管理者の操作権限は狭まりません。必要最小限の権限、2段階認証、監査、復旧手段をあわせて設計します。
日常用・管理用の使い方から、SSOの構成を選ぶ
A・Bとも、日常用と管理用のアカウントは分離します。
違いは、管理用アカウントでGoogleサービスへ入る際にも、OktaのSSOを使うかどうかです。日常用のOkta SSOは、どちらの案でも継続します。
設計の選び方
| 項目 |
A：管理用はGoogleで直接認証 |
B：管理用もOkta SSO |
| アカウント |
日常用と特権管理者用を分ける |
日常用と特権管理者用を分ける |
| 日常用の認証 |
Okta SSOを継続（新方式） |
Okta SSOを継続（新方式） |
| 管理用の認証 |
Okta SSOは使わず、Googleの認証情報＋2段階認証 |
管理用OktaアプリからLegacyへSSO |
| Google側の構成 |
管理用SSOのためのLegacy追加は不要 |
一般用の新方式と、管理用のLegacyを併用 |
※B案でも、特権管理者がadmin.google.comから直接サインインする場合は、Oktaへ転送されずGoogleで認証します。B案は、管理用アカウントでもGoogleサービスへのSSOを使いたい場合の構成です。[1][5]
A：日常用はOkta SSO、管理用はGoogleで直接認証
A案では、管理用アカウントのGoogleへのサインインに、Okta SSOを使いません。
日常用は管理者権限のないアカウントで、引き続きOkta経由でGmailやカレンダーを利用します。管理用はGoogleの認証情報と2段階認証で、管理コンソールへ直接サインインします。[1][8]
「SSOに失敗するから特権管理者権限を外す」のではなく、日常用にその権限を持たせる必要がないため分離する、という考え方です。
権限を外す前には、別の特権管理者で管理・復旧ができることを確認します。対象アカウントをOkta連携の認可に使っている場合は、その影響も確認してください。後者は連携を止めないための設計上の確認です。
B：管理用にもSSOが必要なら、新方式とLegacyを使い分ける
一般用で新方式を使っている環境では、Oktaは次のようにGoogle Workspaceアプリを2つに分ける構成を案内しています。
本記事で紹介する管理用SSOの入口は、Oktaダッシュボードの管理用アプリタイルです。[5]
OktaアプリとGoogle側プロファイルの対応
| 用途 |
OktaのGoogle Workspaceアプリ |
Google側の接続先 |
| 一般用 |
RPIDに新方式のプロファイルの値を設定 |
SSOプロファイル（新方式） |
| 管理用 |
RPIDを空欄に設定 |
Legacy SSOプロファイル |
RPIDは、OktaアプリがどのGoogle側プロファイルを使うかを決める設定です。RPIDを空欄にするだけでは設定は完成しません。
Legacyを有効化し、サインインURL・証明書などを管理用アプリに対応させ、適用先とログイン経路を確認します。既存のLegacy用アプリがある場合は、まずその設定・利用者を確認します。[3][4][5]
管理用のSSOを採用しても、Google側の2段階認証や復旧手段は不要になりません。
特権管理者のSSOを有効にするなら、Googleの推奨に沿ってIdP・Google双方を保護します。[1][8]
変更前に、既存設定と復旧手段を確認する
この構成を自社へ取り入れるときは、「アカウント」「Google側のプロファイル」「Okta側のアプリ」を別々に整理しておくと、変更の影響を把握しやすくなります。
設計・変更前のチェック
| 確認すること |
押さえておきたい点 |
| 権限と用途 |
特権管理者が本当に必要な作業か。日常用アカウントや権限を限定した管理者ロールへ分離できないか。 |
| アプリと接続先 |
一般用・管理用それぞれのOktaアプリ、RPID、Google側プロファイル、適用先、利用する入口を対応づける。 |
| 既存利用者への影響 |
一般用のRPIDを消したり、既存LegacyのURL・証明書を上書きしたりしない。現在の利用者と戻し方を確認する。 |
| プロビジョニング |
アプリの割り当て解除でGoogleアカウントが停止される設定になっていないか。複数アプリから同じ属性を更新しないか。 |
| 保護と復旧 |
2段階認証、個人を識別できる管理用アカウント、別の特権管理者、IdPに依存しない管理コンソールへの復旧経路を確保する。 |
Oktaは、一般用アプリのRPIDを削除すると、そのプロファイルを使うユーザーのSSOが壊れるおそれがあると注意しています。
また、アプリの「Deactivate Users」が有効な場合、割り当て解除が連携先アカウントの無効化につながるため、解除前に設定を確認します。[5][9]
新たに管理用アプリを作る場合、私はまずSSO専用とし、プロビジョニングを有効にしない構成を検討します。
これは公式の必須条件ではなく、複数アプリが同じユーザー情報を更新し合うことを避けるための設計上の提案です。
最後に、一般用と管理用をそれぞれ想定した入口から試し、通常時だけでなく、SSOが使えない場合も管理操作へ戻れることを確認します。
おわりに
Google WorkspaceのSSOでは、ユーザーの所属先だけでなく、特権管理者かどうかで利用できる方式が変わります。
一般用に新方式を使い、管理用にもSSOが必要なら、Legacyへの経路を別に用意する構成を検討します。
ただし、目的はプロファイルを分けること自体ではありません。日常業務へ強い権限を持ち込まず、管理用の認証・監査・復旧を整えることです。
まずは、自社で「誰が、何のために、どのアカウントで、どこから入るか」を整理してみてください。
OktaとGoogle Workspaceの連携や、管理者アカウントの運用設計で判断に迷う場合は、弊社までお問い合わせください。
本記事の公式ドキュメントの確認日は2026年10月19日です。
仕様・画面は変更される可能性があるため、構成時には最新の公式資料をご確認ください。
補足Q&A：仕様やログイン経路をもう少し詳しく
本文では設計の考え方を中心に紹介しました。新旧の細かな違い、提供時期、ログイン経路などは、気になる項目を開いてご確認ください。
A案はOktaを使わない構成ですか？ ブレイクグラスとは違いますか？
A案は、日常用ではOkta SSOを使い続け、管理用だけGoogleで直接認証する構成です。
Oktaを組織全体から外す案ではありません。SSOの使い分けと、Oktaからのユーザープロビジョニング（アカウント作成・更新）の利用有無は、別の設計事項です。[8][13]
ブレイクグラスアカウントは、IdP障害や設定ミスなどで通常の経路を使えないときの緊急復旧専用アカウントを指します。A案で通常の管理作業に使う管理用アカウントとは、役割が異なります。
SSOに依存しない点は共通しますが、「Googleで直接認証できる管理者＝すべてブレイクグラス」ではありません。[12]
緊急用は、認証情報やセキュリティキーの保管、利用できる人、利用時の通知・監査、定期的な復旧テストまで決めます。
通常用の管理者アカウントを分けるだけで、緊急アクセスの設計が完成するわけではありません。[8][12]
複数のSSOプロファイルとは？ 何のために分けるのですか？
1つのGoogle Workspace組織の中に、認証連携の設定を複数持つ、という意味です。
たとえば、プロファイルAは本社のOkta、プロファイルBは子会社のMicrosoft Entra IDにつなぎ、それぞれのユーザーが所属するOU・グループへ割り当てます。Google Workspaceのテナントを増やす必要はありません。[3][11][13]
複数プロファイルを使う主な場面
| 用途 |
分ける理由と使い方 |
| 会社・部門でIdPが異なる |
同じGoogle Workspaceへ統合しても、各社が使うIdPは残したい場合に、OU・グループごとに認証先を変える。 |
| IdPや設定の移行・テスト |
新しい設定をテスト用プロファイルにし、一部ユーザーで確認してから対象を広げる。同じOktaに接続する複数プロファイルでもよい。 |
| 障害時の予備IdP |
予備用プロファイルを事前に準備し、障害時に割り当てを切り替える。自動で切り替わる仕組みではなく、切替・復旧手順の設計が必要。 |
アクセスのたびにプロファイルを変えたり、複数のIdPを順番に通して認証を重ねたりする仕組みではありません。
複数IdPを使い分けることも、1つのIdPへの移行テストに使うこともできます。分ける目的は要件に合わせた認証先の整理であり、数を増やすだけで安全になるわけではありません。[2][3][12][13]
OIDCとは？ 複数のIdPを使い分けるための方式ですか？
OIDC（OpenID Connect）は、SAMLと同じく、IdPで認証した結果をサービス側へ伝えるための通信方式です。
OAuth 2.0を基盤とする認証プロトコルで、「複数のIdPを使うとき専用の方式」ではありません。[14]
「どのIdPにつなぐか」と「SAML・OIDCのどちらで連携するか」は別の話です。1つのIdPでもOIDCを使えますし、複数のIdPをすべてSAMLで連携することもできます。
実際に選べる方式は、Google側とIdP側の対応によります。Googleの新方式は両方に対応しますが、本記事で説明するOktaのGoogle Workspace連携はSAMLです。[3][4][13][14]
「新方式」とLegacyは、具体的に何が違いますか？
Legacyは組織向けに1つのIdPを設定する従来方式、新方式は複数の認証連携設定を使い分けられる方式です。どちらもOU・グループへの適用が可能です。
新方式はOIDCや新しいAPIにも対応しますが、特権管理者のSSOは対象外です。[1][2][3]
新旧プロファイルの主な違い
| 比較する点 |
Legacy（従来方式） |
SSOプロファイル（新方式） |
| IdPの構成 |
組織向けに1つのIdPを設定 |
同一組織内で複数の認証連携設定を持ち、OU・グループへ割り当てる |
| 対応プロトコル |
SAML |
SAML／OIDC（本記事はSAML連携を扱う） |
| 特権管理者のSSO |
対応する入口に限り利用可能 |
非対応 |
| OktaのRPID |
空欄 |
対象プロファイルの値を設定 |
| 新旧の併用 |
新方式と併用可能 |
Legacyと併用可能 |
新方式へ移行しても、特権管理者のSSOまでそのまま引き継がれるわけではありません。
管理用の認証方法を先に決めてから移行します。[1][2]
新旧プロファイルで、どの設定情報を照合すればよいですか？
設定に必要な情報は、比較表にしておくと確認しやすくなります。
以下は、OktaのGoogle WorkspaceアプリによるSAML連携の主な照合項目です。新方式・Legacyそれぞれに対応するアプリの設定値を確認します。[3][4]
OktaからGoogleへ登録する主な情報
| 情報 |
Legacy SSOプロファイル |
SSOプロファイル（新方式・SAML） |
| サインインURL・サインアウトURL |
接続するOktaアプリが示す値 |
接続するOktaアプリが示す値 |
| 署名検証用の証明書 |
接続するOktaアプリの証明書 |
接続するOktaアプリの証明書 |
IdPエンティティID
（Oktaの識別情報） |
現行のLegacy設定には独立した入力欄なし |
OktaアプリのIdPエンティティIDを入力 |
| パスワード変更URL |
Oktaアプリが案内するURL |
Oktaアプリが案内するURL |
Google側の情報と、Okta側で確認する設定
| 項目 |
Legacy SSOプロファイル |
SSOプロファイル（新方式・SAML） |
GoogleのACS URL
（SAML応答の送信先） |
https://accounts.google.com/a/example.com/acs
※example.comは自社のGoogleドメインに置き換える |
Googleの対象プロファイルの［SPの詳細］で確認。プロファイルごとに異なる |
GoogleのSPエンティティID
（Google側の識別情報） |
google.com または google.com/a/example.com。ドメイン固有の発行者の設定により異なる |
Googleの対象プロファイルの［SPの詳細］で確認。プロファイルごとに異なる |
| OktaアプリのRPID |
空欄 |
GoogleのSPエンティティIDに含まれるrpidの値を設定 |
| Google Workspaceの企業ドメイン |
Oktaアプリの［General］で自社ドメインを確認 |
Oktaアプリの［General］で自社ドメインを確認 |
| Google側の有効化・適用先 |
Legacyを有効化し、利用対象と入口の設定を確認 |
対象プロファイルを作成し、OU・グループへ割り当てる |
RPIDはプロファイルを識別する値で、URL全体や証明書ではありません。
OktaのテンプレートはRPIDや企業ドメインをもとに接続先を扱うため、上表のACS URLやSPエンティティIDをすべて手入力する、という意味ではありません。[4]
画面名・入力項目・URLの形式は変わる可能性があります。
値は記事から流用せず、対象のOktaアプリの［View Setup Instructions］と、Googleの対象プロファイル画面で取得してください。特に、別アプリのURLや証明書を取り違えないようにします。[3][4]
いつから新旧の方式があるのですか？ 制約もその時からですか？
特権管理者が新方式に非対応となった正確な開始日は、今回の調査では特定できていません。新方式が登場した2022年から同じ制約だったのかも、確認資料だけでは断定できません。
分かっているのは、新方式の提供時期と、現在の対応可否です。[1][2][6][7]
以下の「Okta技術記事」は、ナレッジベース（Knowledge Base、KB：製品の技術情報や対処方法をまとめた記事集）に掲載された解説記事を指します。
-
2022.05.12
複数IdP向けSSOプロファイルのベータ発表Google Workspace Updatesで、複数のサードパーティIdPを使うSSOプロファイルのベータが発表されました。
[6]
-
2022.08.09
複数IdP対応が一般提供にGoogle Cloud公式ブログが、複数のサードパーティIdPによるSSOの一般提供を発表しました。
[7]
-
2025.07.04
記事の表示日
Oktaの技術記事にも、特権管理者の制約と構成例この日付が表示される技術記事に、管理用はRPID空欄でLegacyへ、一般用はRPIDありの別アプリへ接続する構成が記載されています。日付は技術記事の表示日であり、制約の開始日ではありません。
[5]
-
2026.10.19
確認時点
現行のGoogle公式ヘルプでも、新方式は非対応特権管理者のSSOはLegacyでのみ、かつ対応する一部の経路でサポートされると説明されています。
[1][2]
2022年5月にベータ、同年8月に一般提供となったことは公式発表で確認できます。
ただし、機能の提供日や技術記事の表示日を、そのまま特権管理者の制約開始日とは扱いません。[6][7]
2025年4月24日のコミュニティ投稿にも、新方式では特権管理者がSSOできないという記述があります。
ただし、これは利用者の報告であり、新方式の登場時からの制約だったことを裏付ける資料ではありません。コミュニティ情報も確認しましたが、開始日は断定しません。[15]
一般用と管理用のSSOプロファイルは、必ず分ける必要がありますか？
全社で必ず2つのSSOプロファイルを使う必要はありません。
Legacyは一般ユーザーにも利用でき、管理用アカウントをGoogleの認証情報で使うなら、その管理用SSOのためにLegacyを追加する必要はありません。[1][2][3]
本文で紹介した2アプリ構成は、「一般用は新方式を維持し、特権管理者にもSSOを提供する」という要件がある場合のOktaの案内です。
アカウントの分離と、プロファイル・アプリの分離を混同しないようにします。[5][8]
Legacyで特権管理者がSSOできるのは、Okta起点だけですか？
いいえ。Legacyでは、Okta起点のほか、IdPへ自動転送する設定のドメイン固有サービスURLからもSSOできます。
ただし、本記事の構成では、運用を分かりやすくするため管理用Oktaアプリのタイルから開始します。[1][5]
admin.google.comへの直接サインインは別です。特権管理者はOktaへ転送されず、Googleの認証情報でログインします。
つまり、「Legacyなら、どのGoogleの入口からでもSSOになる」わけではありません。[1]
OU・グループ・管理者ロール・Oktaアプリは、それぞれ何を決めますか？
OU・グループはGoogle側で設定の適用先を管理する単位です。ユーザーの管理者ロールは権限を決め、OktaアプリのRPIDは使うGoogle側のSSOプロファイルを決めます。
同じOUにいることと、同じ権限・同じSSO経路を使うことは同義ではありません。[3][4][10]
さらにGoogleは、Legacyが有効な場合、そのACS URL（SAML応答の送信先）へ送られたアサーションを、別のプロファイルが割り当てられたユーザーや特権管理者のものでも受け付けると説明しています。
署名はLegacy側の証明書で検証されます。[3]
そのため、OU・グループへの割り当てだけでLegacyへの認証を隔離できる、と考えないことも重要です。Okta側のアプリ割り当てと認証ポリシー、実際の送信先まで含めて管理します。
OUを変更する場合は、SSO以外の適用設定への影響も確認します。
Legacyは今後も使い続けられますか？
2026年10月19日に確認したGoogleの移行案内では、Legacyの終了時期は確認できませんでした。Googleは新方式への移行を推奨し、新機能も新方式に注力すると説明しています。
新旧は併用できますが、Legacyを将来もずっと利用できると保証するものではありません。[2]
Legacyを採用するときも、「特権管理者のSSOが本当に必要か」を定期的に見直し、構成変更時には最新の公式案内を確認してください。
参考資料
Google・Okta公式資料を仕様の根拠とし、マクニカ公開記事を構成の補足に用いています。コミュニティ投稿は、過去の報告の参考として区別しています。確認日：2026年10月19日。設定値は構成時点の管理画面と公式手順で再確認してください。
参考資料・出典一覧（15件）
