Google Workspace と Microsoft 365（Entra ID）、さらに Okta まで混在してくると、「どこで認証するのが正解なのか」「パスワードを同期すべきか」で迷いがちです。本記事では、Google Workspace を IdP、Microsoft Entra ID を SP とする構成や、Okta を中核にした一元管理の考え方、そしてフェデレーション後によく発生する AADSTS51004 エラーの原因と対処までを、実運用レベルの視点で整理します。
複数クラウド時代の ID 管理をどう整理するか
まず前提として、Google Workspace・Microsoft Entra ID（旧 Azure AD）・Okta といったクラウド ID 基盤は、役割によって以下のように整理できます。
| 役割 | 典型的なプロダクト | 主な責務 |
|---|---|---|
| IdP（Identity Provider） | Google Workspace, Okta, Entra ID | ユーザー認証、MFA、パスワード・認証ポリシー |
| SP（Service Provider） | Microsoft 365、SaaS 各種 | アプリ本体、認可（ライセンス・権限） |
| プロビジョニング基盤 | Okta、Entra ID プロビジョニング、各種 IGA 製品 | アカウント作成・更新・無効化、属性同期、承認フロー |
近年は「IdP は 1 箇所に寄せる（認証の単一の真実を作る）」ことが強く推奨されます。Microsoft も Google も、SAML/OIDC による相互フェデレーションや SCIM によるプロビジョニング連携を公式にサポートしています。
この前提の上で、以下の 3 つの論点を掘り下げます。
- Google Workspace を IdP、Microsoft Entra ID を SP にする構成
- Okta を中核とした一元管理の是非と設計ポイント
- フェデレーション後に既存ユーザーがサインインできない問題（AADSTS51004）
Google Workspace を IdP、Microsoft Entra ID を SP にする構成
ユースケースと要件の整理
質問としてよく挙がるのは次のようなケースです。
- ユーザーは Google Workspace のアカウントでサインインしたい。
- Microsoft 365（Exchange Online, SharePoint Online, Teams など）は Microsoft Entra ID 側のユーザーで利用し続けたい。
- 「Google 側でパスワードを変更したら、Entra ID にも同期されないのか？」
- 今は Google と Entra の両方に同名ユーザーが存在するが、パスワードは別々。
この状況に対する答えは、ざっくり次のとおりです。
| 項目 | 結論 | ポイント |
|---|---|---|
| SSO（フェデレーション） | 実現可能 | Google IdP / Entra SP として SAML or OIDC 連携 |
| パスワード同期 | 不可 & そもそも不要 | フェデレーション中は Entra のパスワードを使わない |
| ユーザーオブジェクト | Entra にも必要 | SCIM や API で自動プロビジョニングする設計にする |
SSO / フェデレーションの全体像
Google Workspace を IdP として Entra ID とフェデレーションする場合、代表的なシナリオは SAML ベースの SSO です。Microsoft 公式でも、Google Workspace を SAML IdP として Entra ID に信頼させる構成が説明されています。
サインインの流れは概ね次のようになります。
- ユーザーが
[email protected]で Microsoft 365 ポータルにアクセス。 - Entra ID は
domain.comが Google にフェデレーションされているドメインであることを認識し、認証要求（SAML/OIDC）を Google にリダイレクト。 - ユーザーは Google Workspace のログイン画面で認証（パスワード + MFA）。
- Google は SAML アサーション（または OIDC トークン）を発行し、Entra ID に返却。
- Entra ID はトークンを検証し、対象のユーザーオブジェクトに紐づけて Microsoft 365 のトークンを発行。
ここで重要なのは、「パスワードを知っているのはあくまで Google」という点です。Entra ID は「Google が発行したトークンを検証するだけ」であり、パスワード自体には触れません。
パスワード同期ができない / すべきでない理由
よくある誤解が「Google のパスワードを Entra ID にもコピーできないか？」というものです。これを整理すると以下のようになります。
| 誤解 | 実際 |
|---|---|
| パスワードを 2 つのクラウドに同期しておけば安心 | フェデレーション中は Entra のパスワードは サインインに使われない |
| Google → Entra にパスワードを API で書き込めるはず | IdP 間でパスワードをコピーする公式な仕組みはなく、そもそもセキュリティ的にも非推奨 |
| パスワードリセットを両方でできるようにしたい | 「パスワードの権威」を 1 箇所に決めて、他はフェデレーションで委譲するのがベストプラクティス |
Microsoft / Google いずれのドキュメントでも、フェデレーション構成時は IdP 側で認証し、SP 側（ここでは Entra ID）はトークン検証とアプリトークン発行に専念するモデルが前提です。
そのため、「パスワード同期」はそもそも設計目標から外すべきです。やるべきなのは、
- どこを 唯一の認証基盤（IdP）とするかを決める
- 他の基盤には ユーザーと属性だけをプロビジョニングする
という整理です。
ユーザーオブジェクトは別途プロビジョニングで用意する
認証は Google で行うとしても、Microsoft 365 のライセンス付与や Teams のメンバー管理のためには、Entra ID 側にユーザーオブジェクトが存在している必要があります。
ユーザーライフサイクルを正しく連携するには、次のいずれかの方法でプロビジョニングを設計します。
- Okta / Entra ID / IGA 製品などの SCIM 対応プロビジョニングを介して、Google → Entra にアカウントと属性を同期
- Google Workspace のディレクトリ API と Microsoft Graph API を使った 独自スクリプトで、作成・更新・無効化を反映
- 既存の人事マスタ（CSV や HR SaaS）をソースにした メタディレクトリ型の連携
SCIM や Entra の自動プロビジョニング機構は、多くの SaaS で標準的な選択肢になっており、ユーザー作成・更新・無効化を自動で同期できます。
認証・MFA・条件付きアクセスの責任分界
もう 1 つの重要ポイントは「MFA をどこで要求するか」です。構成パターンとしては次の 2 つが代表的です。
| パターン | 特徴 | メリット / デメリット |
|---|---|---|
| IdP 側で MFA 完結 | Google / Okta 側で MFA を要求し、Entra ID は MFA 済みクレームを信頼 | ユーザー体験はシンプルだが、Entra 条件付きアクセスによる細かい制御はやや限定的 |
| Entra 条件付きアクセスで追加 MFA | IdP 認証後でも、高リスク時だけ Entra 側で追加 MFA | 柔軟なリスクベース制御が可能だが、設計を誤ると二重 MFA になりやすい |
Google Workspace と Entra ID のフェデレーションでも、Google 側での認証結果を Entra 側が受け取り、条件付きアクセスと組み合わせて利用する構成が想定されています。
実務的には、「標準は IdP 側 MFA、特定の高リスク条件だけ Entra 追加 MFA」という折衷案が取りやすいです。
Okta を中核にした一元管理は可能か？
Okta 中央 IdP モデルの全体像
次に、Okta を中央 IdP として、Google Workspace と Entra ID をそれぞれ SP としてぶら下げたいという要件を考えます。
構成のイメージは次のようになります。
- ユーザーは Okta にサインイン（パスワード + MFA）。
- Google Workspace は SAML / OIDC SP として Okta に信頼を委譲。
- Microsoft Entra ID も SAML / WS-Fed / OIDC の SP として Okta を信頼。
- Okta から Google / Entra に対しては プロビジョニング API（SCIM など）でアカウントと属性を同期。
Okta は Office 365 / Entra ID へのプロビジョニングを公式にサポートしており、ユーザー作成・更新・無効化を自動化できます。
Okta → Google と Okta → Entra の違い
Okta から見た場合、Google Workspace と Entra ID への連携は少し性格が違います。
| 項目 | Okta → Google Workspace | Okta → Microsoft Entra ID |
|---|---|---|
| 認証 | 通常は Okta で認証し、Google は SP として利用 | Okta で認証し、Entra は SP として利用 |
| パスワード書き込み | Google の API 経由でパスワード更新が可能 | フェデレーション時はパスワードを使わないので書き込みの価値が薄い |
| プロビジョニング | ユーザー・グループを SCIM / API で同期 | ユーザー・グループを API で同期（ユーザーライフサイクル管理が中心） |
| 実運用でのおすすめ | Okta を唯一の認証基盤とし、Google はメール・コラボ用 SP | Okta を唯一の認証基盤とし、Entra は M365 と他 Azure リソース用 SP |
ポイントは、Okta → Entra について「パスワード同期」はほぼ意味がないことです。ドメインを Okta（または Google）にフェデレーションしている限り、Entra 側ではそのドメインのパスワードを使用しません。
したがって、Okta から Entra へは次だけを同期する設計に割り切るのが合理的です。
- ユーザーオブジェクト（作成・更新・無効化）
- 表示名・部署・役職などの属性
- ライセンスの付与（Okta グループと Entra グループのマッピング）
「パスワードを同期したい」の裏で本当にやりたいこと
現場で「パスワード同期をやりたい」と言われる場合、突き詰めると本当にやりたいことは次のどれかです。
- ユーザーに「どのサービスも同じパスワードでログインできる」という体験を提供したい。
- パスワードリセットの窓口を 1 か所にしたい。
- ロックアウトやポリシーも一元的に管理したい。
これらはすべて、IdP を 1 つに統一してフェデレーションすることで解決できます。パスワードを各サービスに同期するのではなく、「どこで認証するか」を統一するのが正しいアプローチです。
フェデレーション後に既存ユーザーがサインインできない（AADSTS51004）
AADSTS51004 エラーの意味
Google とのフェデレーションや Okta との連携を構成したあと、既存ユーザーだけがサインインできなくなるケースがよくあります。その際によく出るのが、次のようなエラーです。
AADSTS51004: The user account <id> does not exist in the <tenant> directory.
To sign in to this application, the account must be added to the directory.Microsoft のドキュメントやコミュニティでも、このエラーは 「そのテナントに、指定された UPN のユーザーが存在しない」ことを意味すると説明されています。特に Google Workspace とのフェデレーションを構成した後、UPN 不一致が原因で本エラーが発生しやすいことが指摘されています。
よくある原因パターン
実際の現場でよく見る原因はだいたい次の 3 つです。
| パターン | 具体例 | 確認ポイント |
|---|---|---|
| UPN 不一致 | Entra ユーザーの UPN が [email protected] のまま | Entra ポータルで userPrincipalName を確認 |
| 別テナント / ゲストユーザー | 同じメールドメインが別テナントにも存在し、間違ったテナントにサインイン | ログイン URL・テナント ID 固定で検証 |
| メールアドレスと UPN の混同 | mail 属性には [email protected] があるが、UPN は別値 | 「サインイン名＝UPN」であることを運用側が理解していない |
特にフェデレーション構成後は、ユーザーが [email protected] でサインインしようとしたときに、Entra ID が「その UPN を持つユーザーがテナントにいない」と判断すると AADSTS51004 になります。
対処ステップ：既存ユーザーをフェデレーション用ドメインに揃える
根本対処はシンプルで、既存ユーザーの UPN をフェデレーション対象ドメイン（例：@domain.com）に揃えることです。
代表的な進め方は以下のとおりです。
- 対象ユーザーの洗い出し
Entra ポータルや PowerShell / Graph API で、UPN が@tenant.onmicrosoft.comなどフェデレーション外ドメインのユーザーを抽出します。 - UPN を一括変更
変更先のドメイン（例：domain.com）が Entra でも Google でも既に検証済みであることを確認し、UPN を一括変更します。
例（古いが分かりやすい PowerShell 例）：Set-MsolUserPrincipalName ` -UserPrincipalName [email protected] ` -NewUserPrincipalName [email protected]現在は Microsoft Graph PowerShell で同様の操作を行うことが推奨されています。 - テナントを固定してサインインテスト
https://login.microsoftonline.com/<テナントID>/のようにテナント ID 固定の URL でサインインテストを行い、「別テナントに飛んでいないか」を切り分けます。 - 自動プロビジョニングの再照合
SCIM や Entra の自動プロビジョニングを使っている場合、識別子をuserPrincipalNameに合わせ、初回フル同期や再照合で既存ユーザーを「新規作成」ではなく「既存ユーザーへのマージ」にします。 - サインインログで事実確認
Entra ID のサインインログで、実際にどの識別子で認証が試行され、どのテナントで AADSTS51004 が出ているかを確認します。
特に「メールアドレス＝UPN」と思い込んだまま設計すると、既存ユーザーだけがフェデレーション後にサインインできなくなる、という典型的なトラブルにはまりやすいので注意が必要です。
実装のひな型：ステップバイステップ
方針決定：認証の単一の真実を決める
最初に決めるべきことは、次の 2 点だけです。
- 「認証の権威」＝どの IdP にするか
（Google か、Okta か、Entra か） - 「アカウント在庫」＝どこにユーザーを必ず持たせるか
（Entra・Google・Okta・人事マスタなど）
本記事の前提では、「認証の権威」は Google もしくは Okta に寄せ、「アカウント在庫」としては Entra ID にも必ずユーザーを持たせる、という設計が現実的です。
ドメイン準備とフェデレーション設定
Google Workspace を IdP にする場合、Entra ID 側でフェデレーション対象ドメインを登録しておきます。Microsoft Learn には、Google Workspace を IdP として Entra ID を信頼させる具体的な手順が公開されています。
高レベルには次のような流れです。
- Entra ID に
domain.comを追加・検証。 - Entra ID 側で
domain.comの認証方式を「フェデレーション」に変更（SAML など）。 - Google Workspace 管理コンソールで「Microsoft 365 / Office 365」用の SAML アプリを追加。
- Entra ID からメタデータ（証明書・エンドポイント）を取得し、Google に登録。
- Google 側で NameID や属性マッピングを設定（メールアドレス or UPN）。
Okta を中央 IdP にする場合も同様に、Okta に Microsoft 365 / Entra ID をアプリとして登録し、SAML/OIDC のメタデータを Entra / Google 双方に設定します。
自動プロビジョニング（SCIM / API）設計
次に、ユーザー作成・更新・無効化を自動化する仕組みを設計します。ポイントは以下です。
- 識別子（マッチキー）は UPN を基準にする
Google 側のメールアドレス or 外部 ID と、Entra 側の UPN を 1 対 1 にマッピングできるようにします。 - ソース・オブ・トゥルース（真のマスタ）を決める
人事システム → Okta → Entra / Google なのか、Google → Entra なのかを明確にします。 - 無効化ルールの設計
退職時は「まず IdP 側でサインイン不可にしてから、Entra のライセンスを剥奪・アカウント無効化」という順番にするなど、セキュリティと運用のバランスを考えます。
SCIM を使ったプロビジョニングは、多くの SaaS と Entra / Okta で共通化されたアプローチになっており、「誰をどのアプリにいつまで残すか」を自動で管理する基盤として活用できます。
既存ユーザー整備：UPN とグループを揃える
フェデレーションを開始する前に、既存ユーザーを整備しておくとトラブルを大きく減らせます。
- UPN を
@domain.comに揃える（前述の AADSTS51004 対処） - メールアドレス（
mail属性）と UPN をできるだけ一致させる - グループ設計（部署・役職・ロール）を IdP 側に寄せ、Entra 側は受け取り先として最低限にする
- ライセンス付与をグループベースで自動化し、個別付与を廃止する
可能であれば、本番移行前に「テストテナント」や「パイロット OU / グループ」でフェデレーションを試し、UPN やグループ設計の問題を洗い出しておくと安全です。
MFA / 条件付きアクセスの整合を取る
MFA の設計はユーザー体験とセキュリティのバランスが問われます。よくある失敗は、
- Okta で MFA
- ＋ Entra 条件付きアクセスで「すべてのユーザーに MFA 必須」
としてしまい、ユーザーが毎回 2 回 MFA を要求されるパターンです。
おすすめは、
- 通常のアクセスは IdP 側 MFA のみ（Google / Okta / Entra のいずれか）
- 高リスクの条件（未知のデバイス・海外・レガシープロトコルなど）のみ Entra 条件付きアクセスで追加 MFA
といった「リスクベース追加 MFA」の考え方です。
段階的切替とロールバックプラン
最後に、移行の進め方のポイントです。
- パイロットグループから開始
情シス部門や IT リテラシーの高い部署をパイロットにし、実際のサインインログとユーザーの声を確認します。 - ロールバック手順を事前に用意
ドメインの認証方式を「マネージド（Entra ネイティブ）」に戻す手順を確認し、いざというときに即時戻せるようにします。 - サポート情報の整備
「ログイン画面が変わります」「MFA の手順が変わります」などの案内を、画面キャプチャ付きで用意しておきます。
設計パターン別のおすすめ構成例
パターン A：Google Workspace 中心＋Microsoft 365 併用
- IdP：Google Workspace
- SP：Entra ID（Microsoft 365）、その他 SaaS
- ユーザーマスタ：人事システム or Google
この場合は、本記事前半で説明したように、Google を IdP、Entra を SP とするフェデレーションが分かりやすい選択です。
- ユーザーは常に「Google のパスワード」でサインイン
- Microsoft 365 は Google SSO 経由で利用
- Entra 側のユーザーはプロビジョニングで自動作成・更新
パターン B：Okta 中央 IdP＋Google・Entra をぶら下げる
- IdP：Okta
- SP：Google Workspace, Entra ID, 各種 SaaS
- ユーザーマスタ：人事システム or Okta
この場合は、
- すべてのユーザーは Okta にサインイン
- Google / Entra は Okta による SAML/OIDC SSO を利用
- Okta から Google / Entra にユーザーをプロビジョニング
- パスワード同期ではなく「認証の一元化」で UX を揃える
という構成にすると、将来的に Google → Entra へ統合する場合でも、Okta 側の設計をほぼ変えずに移行できます。
パターン C：将来的に Entra へ統合したい場合の中間ステップ
将来的に「認証もアカウント在庫も Entra に統合したい」という場合は、次のような段階的アプローチがよく採られます。
- 現在：Google / Okta を IdP、Entra を SP とするフェデレーション構成。
- 中期：ユーザーライフサイクル管理（入社・異動・退職）を Entra SCIM や Entra ID Governance に寄せていく。
- 最終：IdP を Entra に切り替え、Google は Entra にフェデレーションされた SP として利用。
この場合でも、途中で「パスワード同期」を挟む必要はなく、常に「どこで認証するか」を一本化しておくのが重要です。
まとめ：パスワード同期ではなく「認証の一本化」を目指す
本記事のポイントを改めて整理します。
- Google Workspace を IdP、Entra ID を SP にする構成は一般的であり、SAML/OIDC フェデレーションで実現可能です。
- Google → Entra へのパスワード同期はできないし、フェデレーション構成ではそもそも不要です。認証は IdP（Google / Okta）に一本化します。
- Entra 側には ユーザーオブジェクトと属性をプロビジョニングし、Microsoft 365 のライセンス・グループ・条件付きアクセスなどの「アプリ制御」を担わせるのが役割分担として自然です。
- Okta 中央 IdP モデルでは、Okta → Entra の「パスワード同期」はほぼ価値がなく、ユーザー・属性・グループの同期に集中するべきです。
- AADSTS51004 は 「その UPN のユーザーがテナントにいない」ことを意味し、多くの場合は UPN 不一致やテナント違いが原因です。UPN をフェデレーションドメイン（
@domain.com）に揃えることが近道です。
キーワードは、
- Google（または Okta）＝認証の“単一の真実”
- Entra ＝アカウント在庫とアプリ制御
- 「パスワードを各所に同期」ではなく「どこで認証するかを一本化」する
という 3 つです。この方針さえブレなければ、Google と Microsoft、Okta を跨いだ複雑な環境でも、長期的にメンテナンスしやすい ID 基盤を構築できます。
コメント