はじめに
前回「Google Workspaceを使い続けながらWindows端末管理をIntuneへ移行する設計パターン」 では、Google Workspaceを使い続けながら、Windows端末管理をMicrosoft Entra ID / Intune / Defender for Businessへ寄せる設計パターンを整理しました。
今回は、その前提となる ID設計 について整理します。
Google WorkspaceとMicrosoft 365 / Microsoft Entra IDを併用している企業では、次のような問題が起きがちです。
・会社メールアドレスとログインIDが一致しない
・Google側とMicrosoft側で別々にユーザーを作っている
・退職者が片方にだけ残る
・Microsoft側のライセンス付与が人手運用になる
・SSOや自動プロビジョニングを入れたいが、どちらを正本にするか決まらない
・特定ベンダにIDを寄せすぎたくない
この記事では、会社メールアドレス、Google WorkspaceのID、Microsoft Entra IDのIDを意図的に分ける設計を取り上げます。
この記事は特定環境の実構成ではなく、公開用に抽象化した設計パターンです。実ドメイン、実ユーザー名、実グループ名、管理者アカウント名は記載しません。
結論
Google WorkspaceとMicrosoft Entra IDを併用する場合、次のように分ける設計は現在でも有効です。
会社メールアドレス:
user@example.co.jp
Google Workspace ID:
user@g.example.co.jp
Microsoft Entra ID:
user@ms.example.co.jp
ポイントは、@の前、つまりlocal partを揃えることです。
会社メール: yamada@example.co.jp
Google ID: yamada@g.example.co.jp
Microsoft ID: yamada@ms.example.co.jp
この設計により、次のことができます。
・会社メールアドレスをベンダ非依存の独自ドメインとして維持できる
・GoogleとMicrosoftのID空間を分離できる
・どちらか一方のサービスに全面依存しにくくなる
・将来のIDaaS導入時にも対応関係を作りやすい
・利用者単位の対応表を人間にも機械にも扱いやすくできる
一方で、当然デメリットもあります。
・ログインIDが複数になる
・入社、異動、退職時に二重管理が発生する
・SSOや自動プロビジョニングの設計が少し複雑になる
・ID台帳を持たないと不整合が発生する
したがって、この設計では ID台帳 が必須です。
なぜ会社メールアドレスとログインIDを分けるのか
会社として最も重要なのは、対外的な連絡先である会社メールアドレスです。
user@example.co.jp
これは、GoogleやMicrosoftのどちらかに依存させるべきものではありません。会社が保有する独自ドメインを正本にし、ベンダ変更時にも維持できるようにします。
一方で、Google WorkspaceやMicrosoft Entra IDには、それぞれのサービスを利用するためのIDが必要です。
Google Workspace:
Gmail、Drive、Calendar、Vaultなどを使うためのID
Microsoft Entra ID:
Windowsサインイン、Intune、Defender、Microsoft 365 Appsなどを使うためのID
この2つを無理に同一化しないことで、サービスごとの役割を分けられます。
3つのIDモデル
Google WorkspaceとMicrosoft Entra IDを併用する場合、ID設計には大きく3つのモデルがあります。
モデルA: 全部 user@example.co.jp に統一する
会社メール: user@example.co.jp
Google ID: user@example.co.jp
Microsoft ID: user@example.co.jp
これは利用者にとって最も分かりやすい構成です。
メリット
・ログインIDが1つに見える
・SSOや自動プロビジョニングが設計しやすい
・SaaS連携時にID不一致が起きにくい
・利用者説明が簡単
デメリット
・どちらかのIdPに依存しやすい
・障害時の影響範囲が大きくなる
・ベンダを分ける設計思想とはやや相性が悪い
・移行作業の影響範囲が大きい
全社的にSSOを強く推進する企業では有力ですが、「GoogleにもMicrosoftにも過度に依存したくない」という思想とは少しズレます。
モデルB: 会社メールだけ共通、Google/Microsoft IDは分ける
会社メール: user@example.co.jp
Google ID: user@g.example.co.jp
Microsoft ID: user@ms.example.co.jp
この記事で推奨するのはこのモデルです。
メリット
・会社メールアドレスをベンダ非依存にできる
・GoogleとMicrosoftのID空間を分けられる
・片方の認証や設定変更がもう片方へ波及しにくい
・段階的な移行がしやすい
・IDaaSを後から入れても対応表を作りやすい
デメリット
・利用者に複数IDを説明する必要がある
・自動化には台帳やIDaaSが必要になる
・SSOを入れる場合は設計がやや複雑になる
20〜50名規模で、Google Workspaceを使い続けながらWindows端末だけMicrosoft側で管理する構成では、このモデルが現実的です。
モデルC: 片方をIdPにしてもう片方へフェデレーションする
例として、Google WorkspaceをIdPにし、Microsoft Entra IDへのサインインをGoogle認証に寄せる構成です。
Google Workspace
↓ 認証
Microsoft Entra ID
Microsoftの公式手順でも、Google WorkspaceをMicrosoft Entra IDのIdPとして構成し、Google Workspaceの資格情報でMicrosoft Entra IDへサインインできる構成が説明されています。
メリット
・利用者の認証体験を統一しやすい
・パスワード管理を片方に寄せられる
・退職時の停止を一元化しやすい
デメリット
・IdP側の障害がMicrosoft側サインインにも影響する
・設定ミス時の影響が大きい
・既存ユーザーの照合が必須
・ドメイン単位の影響が出やすい
フェデレーションは有効な選択肢ですが、最初に入れるべきではありません。まずは既存アカウントの突合と台帳化を行い、IDの対応関係を明確にしてから検討すべきです。
推奨モデル
この記事で推奨するのは、次の構成です。
会社メールアドレス:
user@example.co.jp
Google Workspace ID:
user@g.example.co.jp
Microsoft Entra ID:
user@ms.example.co.jp
ルール:
user部分は必ず一致させる
この構成では、会社メールアドレスを正本として維持しながら、GoogleとMicrosoftのID空間を分けます。
会社メール = 対外的な正本
Google ID = Google Workspace利用のためのID
Microsoft ID = Windows / Intune / Defender / Office利用のためのID
重要なのは、IDを分けるだけでは不十分という点です。分けたIDを対応付けるための台帳が必要です。
ID台帳に持つべき項目
最低限、次のような台帳を持ちます。
employeeId
localPart
氏名
所属
雇用区分
会社メール
Google primary email
Google user ID
Google aliases
Microsoft UPN
Microsoft object ID
Microsoft旧UPN
Windows利用区分
Office利用有無
Microsoftライセンス区分
Google状態
Microsoft状態
管理者権限の有無
break-glass対象外フラグ
表にすると、次のようになります。
| 項目 | 例 |
|---|---|
| employeeId | 00123 |
| localPart | yamada |
| 会社メール | yamada@example.co.jp |
| Google primary | yamada@g.example.co.jp |
| Microsoft UPN | yamada@ms.example.co.jp |
| Windows利用区分 | windows_office / windows_no_office / none |
| Microsoftライセンス | Business Premium / Intune+EntraP1+Defender / none |
| Google状態 | active / suspended |
| Microsoft状態 | enabled / disabled |
localPart だけで突合するのは不十分です。改姓、同姓同名、表記変更、外部協力者の追加などで揺れるためです。
安定キーとして、次も持つべきです。
Google user ID
Microsoft object ID
社員番号
メールアドレスやUPNは変更されることがありますが、オブジェクトIDは突合キーとして安定しています。
Google Workspace側の注意点
Google Workspaceでは、ユーザーはprimary emailでサインインします。ユーザーエイリアスドメインを使うと、別ドメインのメールアドレスを付与できますが、サインインに使うのはprimary emailです。
たとえば次のような構成です。
Google primary email:
user@g.example.co.jp
Google alias:
user@example.co.jp
この場合、ユーザーは user@g.example.co.jp でGoogle Workspaceにサインインします。user@example.co.jp はメール送受信のアドレスとして使えますが、ログインIDとしてはprimary emailと同じではありません。
この挙動を理解しておかないと、次のような混乱が起きます。
・会社メールではログインできると思っていた
・Googleの共有やカレンダー招待にprimary emailが出る
・SaaS連携時に想定と違うIDが送られる
したがって、Google側では次の2つを明確に分けます。
Google primary email:
GoogleログインID
会社メールalias:
対外メールアドレス
Microsoft Entra ID側の注意点
Microsoft Entra IDでは、テナントにカスタムドメインを追加し、そのドメインをユーザー名、つまりUPNに使えます。
たとえば、Microsoft側のIDを次のようにできます。
user@ms.example.co.jp
Microsoft側では、このUPNをWindowsサインイン、Microsoft 365 Apps、Intune、Defenderなどで使います。
この構成のポイントは、会社メールドメイン example.co.jp をMicrosoft側メール用途に使わないことです。
Microsoft 365のドメイン設定では、Exchange Online用のDNS設定を求められることがあります。しかし、Google Workspaceでメールを受ける方針なら、Microsoft側へメール配送を向ける必要はありません。
つまり、Microsoft側のドメインは次の役割に限定します。
Microsoft Entra ID用のログインドメイン
Windows / Intune / Defender / Office用のID空間
なぜ最初からSSOを入れないのか
SSOは便利ですが、最初から入れるべきとは限りません。
特に既存のGoogleユーザーとMicrosoftユーザーがすでに存在する場合、まずやるべきことはSSOではなく 突合 です。
Googleの user@g.example.co.jp は誰か
Microsoftの user@ms.example.co.jp は同じ人か
退職者は残っていないか
管理者アカウントと通常社員アカウントが混ざっていないか
旧UPNや旧アカウントが残っていないか
これを確認せずにSSOや自動プロビジョニングを入れると、次のような問題が起きます。
・別人に紐付く
・重複ユーザーができる
・退職者が有効化される
・管理者がサインインできなくなる
・既存ライセンスが外れる
したがって、順序は次が安全です。
1. Google / Microsoft の既存ユーザーを棚卸し
2. localPart と employeeId で突合
3. 台帳を作る
4. Microsoft側ライセンスとグループを整理
5. 必要ならSSOや自動プロビジョニングを検討
自動プロビジョニングの前に決めること
Google Workspaceには、Office 365向けの自動プロビジョニング機能があります。Google側のユーザー変更をOffice 365側に反映できる仕組みです。
ただし、既存ユーザーが両方にある場合、いきなり有効化するのは危険です。
特に注意すべきなのは、primary emailの扱いです。Googleのドキュメントでは、Office 365へ自動プロビジョニングした後のGoogle Workspaceユーザーのprimary email変更には制約があり、Microsoft側のImmutableID / onPremisesImmutableIdの更新が必要になる場合があります。
つまり、次を決める前に自動プロビジョニングを入れてはいけません。
Google primary emailを将来変えるのか
Microsoft UPNを将来変えるのか
会社メールをログインIDに統一するのか
IDaaSを導入するのか
どちらをID正本にするのか
この段階では、Google標準プロビジョニングよりも、まず台帳化と手動運用の整理を優先する方が安全です。
IDaaSを使う場合の位置づけ
IDaaSを入れる場合でも、最初から唯一の認証基盤にする必要はありません。
おすすめは、IDaaSを次のように使うことです。
IDaaS:
ID台帳の突合
Google / Microsoft の差分確認
グループ連携
Microsoftライセンス連携
入退社処理の補助
逆に、最初から次を行うのは避けた方がよいです。
IDaaSを唯一のIdPにする
IDaaSを唯一のID正本にする
hard deleteを自動化する
break-glass管理者をIDaaS管理下に置く
IDaaSが停止しても、GoogleとMicrosoftには直接ログインできる状態を残すべきです。
つまり、IDaaSは 便利な自動化層 として使い、認証の単一障害点 にしない設計が現実的です。
break-glass管理者は別扱いにする
ID設計で忘れてはいけないのが、緊急用管理者アカウントです。
通常ユーザーのID管理を自動化しても、緊急用管理者アカウントは自動化対象外にします。
・通常社員アカウントとは分ける
・IDaaS管理外にする
・Google/Microsoftそれぞれに直接ログインできるようにする
・削除、停止、自動プロビジョニング対象にしない
これにより、SSOやIDaaS、フェデレーションに障害が起きても、管理者が直接復旧できます。
運用ルール
このID分離設計を成立させるには、最低限次のルールが必要です。
1. localPartは必ず一致させる
2. 会社メールは user@example.co.jp とする
3. Google primaryは user@g.example.co.jp とする
4. Microsoft UPNは user@ms.example.co.jp とする
5. Google / Microsoft のobject IDを台帳に持つ
6. 退職時は削除ではなく停止を基本にする
7. hard deleteは承認制にする
8. break-glass管理者は自動化対象外にする
9. 共有アカウントと個人アカウントを分ける
10. IDaaSを使う場合も手動復旧できる台帳を残す
このルールがないと、IDを分けるメリットよりも、運用負荷の方が大きくなります。
導入ロードマップ
現実的には、次の順番で進めます。
Phase 1:
Google / Microsoft の既存ユーザー一覧を取得
台帳を作る
localPart不一致を洗い出す
Phase 2:
Microsoft側UPNを整理
Google側primary / aliasを整理
退職者、共有アカウント、管理者アカウントを分類
Phase 3:
Windows利用区分を決める
Officeあり / なし / 端末なしを分類
Microsoftライセンスグループを作る
Phase 4:
Intune / Defender / Business Premiumなどのライセンス運用を開始
最初は手動または限定グループで運用
Phase 5:
IDaaSの導入を検討
まずは突合・差分確認・グループ連携から始める
Phase 6:
必要に応じてSSOや自動プロビジョニングを検討
重要なのは、SSOや自動プロビジョニングは後段ということです。
まずは、既存ユーザーを壊さず、対応関係を明確にすることが先です。
この設計が向いている企業
この設計は、次のような企業に向いています。
・Google Workspaceを使い続けたい
・Windows端末管理だけMicrosoftに寄せたい
・Microsoft 365へ全面移行したくない
・会社メールアドレスをベンダ非依存にしたい
・GoogleとMicrosoftの両方に既存ユーザーがある
・SSOよりも安全な段階移行を優先したい
・将来IDaaSを入れる余地を残したい
逆に、次のような企業では、最初からID統合を検討してもよいです。
・Microsoft 365へ全面移行する予定がある
・Google Workspaceをやめる予定がある
・全社SSOを最優先したい
・人事マスタを起点に全SaaSを自動管理したい
・100名以上で入退社が頻繁に発生する
まとめ
Google WorkspaceとMicrosoft Entra IDを併用する場合、IDを1つに統一することだけが正解ではありません。
数十名規模の企業では、次のような分離設計も十分現実的です。
会社メール:
user@example.co.jp
Google ID:
user@g.example.co.jp
Microsoft ID:
user@ms.example.co.jp
この設計の要点は次です。
・会社メールアドレスをベンダ非依存の正本にする
・GoogleとMicrosoftのID空間を分ける
・localPartを揃える
・employeeIdとobject IDを持つ台帳を作る
・SSOや自動プロビジョニングは後段にする
・IDaaSは依存先ではなく自動化層として使う
・break-glass管理者は自動化対象外にする
IDを分けること自体が目的ではありません。目的は、会社メール、Google、Microsoft、端末管理、将来のIDaaS導入を、それぞれ制御可能な状態に保つことです。
次回は、オンプレADを廃止する前に確認すべきWindows端末移行パターンについて整理します。
参考リンク
- Add a user alias domain or secondary domain - Google Workspace Admin Help
- Add a custom domain name to Microsoft Entra ID
- Configure Federation Between Google Workspace And Microsoft Entra ID
- Configure Office 365 user provisioning - Google Workspace Admin Help
- Office 365 cloud app - Google Workspace Admin Help