Google WorkspaceとMicrosoft Entraを併用する構成

Posted at 2026-04-28

はじめに

ここまでの記事で、次の設計を前提に整理してきました。

Google Workspace はメール・ファイル共有・日常コラボレーションの基盤として使い続ける
Windows 端末管理は Microsoft Entra ID / Intune / Defender for Business に寄せる
会社メールアドレス、Google ID、Microsoft ID は意図的に分ける
@ の前、つまり local part は揃える

これまでの記事は以下になります。

この記事では、個別管理を前提に以下を整理します。

・どこまでは現実的に回るか
・どこからつらくなるか
・何を手動運用で吸収することになるか

この記事は特定環境の実構成ではなく、公開用に抽象化した設計パターンです。
実ドメイン、実ユーザー名、実グループ名、管理者アカウント名は記載しません。

結論

結論から書きます。

20〜50名規模ならこのまま運用は可能です。
ただし、前提条件があります。

1. 既存の Google / Microsoft ユーザーをそのまま活かす
2. 会社メール、Google ID、Microsoft ID の対応表を持つ
3. local part を揃える
4. Microsoft 側のライセンスはグループで寄せる
5. 削除は自動化せず、まず停止・剥奪までに留める
6. 管理者・break-glass アカウントは通常運用から分ける

一方で、次のような状態になると、人手運用の負荷が目立ちます。

・入社、異動、退職が増える
・Google と Microsoft 以外の SaaS も増える
・ライセンス体系が複雑になる
・停止日 / 削除日 / 付与日を日付で制御したくなる
・誰が何を更新したかを監査したくなる

つまり、**この構成は「成立するが、運用設計をかなり丁寧にしないと崩れる」**というのが実態です。

前提となるIDモデル

この記事で扱うのは、次のような分離モデルです。

会社メールアドレス:
  user@example.co.jp

Google Workspace ID:
  user@g.example.co.jp

Microsoft Entra ID:
  user@ms.example.co.jp

そして、user の部分は揃えます。

会社メール:        yamada@example.co.jp
Google ID:         yamada@g.example.co.jp
Microsoft ID:      yamada@ms.example.co.jp

この構成では、Google と Microsoft の既存アカウントをそのまま使う前提です。
新たにどちらかへ全面移行するのではなく、対応表を持って併用する形です。

なぜこの構成で回せるのか

20〜50名規模なら、最初は次の運用で回せます。

・Google Workspace 側のユーザー管理は Google Admin console
・Microsoft 側のユーザー管理は Microsoft Entra / Microsoft 365 管理センター
・Windows 利用区分は台帳で管理
・Microsoft ライセンスはグループベースで付与
・入退社時は台帳を見ながら両方を更新

Microsoft Entra ではグループベースライセンスが使え、グループにライセンスを割り当てると、メンバー追加時に対象ライセンスが自動付与され、グループから外すと外れる仕組みです。(Microsoft Learn: What is group-based licensing in Microsoft Entra ID?)

また、Microsoft 365 管理センターでは、ユーザーやグループに対してライセンスを割り当てたり、外したりできます。(Microsoft Learn: Assign or unassign licenses for users in the Microsoft 365 admin center)

つまり、Microsoft 側のライセンス制御だけ見れば、IDaaSがなくても一定までは整理できます。

本構成の運用イメージ

公開用に抽象化すると、運用イメージは次のようになります。

この構成のポイントは、ID台帳が中心だということです。

台帳がないと、Google と Microsoft の既存ユーザーを対応付けられません。
逆に、台帳があれば、少なくとも次のことは人手で回せます。

・誰が Google にいるか
・誰が Microsoft にいるか
・誰が Windows 利用者か
・誰に Office が必要か
・誰がどの Microsoft ライセンス区分か

最低限持つべき台帳項目

本構成の場合、台帳の出来がそのまま運用品質になります。

最低限、次の項目は必要です。

employeeId
localPart
氏名
所属
雇用区分
status
会社メール
Google primary email
Google user ID
Google aliases
Microsoft UPN
Microsoft object ID
Microsoft旧UPN
Windows利用区分
Office利用有無
Microsoftライセンス区分
Google状態
Microsoft状態
管理者権限の有無
break-glass対象外フラグ

実体は、Google スプレッドシートでもよいですし、CSV / Git 管理でも構いません。
重要なのは、Google と Microsoft の両方のオブジェクトIDを持つことです。

メールアドレスや UPN は将来変わる可能性がありますが、オブジェクトIDは対応付けの安定キーになります。

本構成でまず起きる問題

ここからが本題です。

1. 入社時に二重作成が必要になる

新入社員を受け入れるたびに、次のような作業が発生します。

・Google Workspace にユーザー作成
・Google グループ設定
・会社メールエイリアス設定
・Microsoft Entra にユーザー作成
・Microsoft 側グループ割当
・ライセンス付与
・必要なら Windows 利用区分の反映

20名規模ならまだ回りますが、人数が増えると「作り忘れ」「付け忘れ」が起きます。

2. 異動時にグループがズレる

部門異動や役職変更が起きると、Google と Microsoft の両方のグループを見直す必要があります。

Google:
  メーリングリスト
  共有ドライブ
  カレンダー共有

Microsoft:
  ライセンス付与グループ
  Intune対象グループ
  Office利用グループ

この2系統が別管理だと、片方だけ変えて終わる事故が起きやすいです。

3. 退職時に停止漏れが起きやすい

退職者対応では、最低でも次が必要です。

・Google 側停止
・Microsoft 側停止
・ライセンス剥奪
・端末回収 / ワイプ
・共有物の引継ぎ

手動運用だけだと、次のような事故が起きます。

・Google は止めたが Microsoft は残った
・アカウントは止めたがライセンスが残った
・退職者の端末が Intune では残っている
・共有グループから外し忘れた

4. 既存ユーザーの対応表が壊れやすい

既に Google と Microsoft に別々のアカウントがある場合、次のような揺れがあると厄介です。

・Google 側の表示名変更
・Microsoft 側 UPN 変更
・旧 onmicrosoft.com UPN が残る
・同姓同名対応で localPart にルール差が出る
・役職付きアカウント、共有アカウント、管理者アカウントが混ざる

これらは運用ルールを明文化しないと崩れます。

Google 標準の自動プロビジョニングをすぐ使わない理由

Google Workspace には、自動プロビジョニング機能があります。Google の公式説明では、Google Admin console 上のユーザー変更を対応アプリへ自動反映でき、数時間ごとに同期されます。(Google Workspace Admin Help: About automated user provisioning)

また、Office 365 向けの自動プロビジョニング設定も用意されています。(Google Workspace Admin Help: Configure Office 365 user provisioning)

では、Google 標準機能で十分かというと、そう単純ではありません。

理由は次です。

・既存 Google / Microsoft ユーザーを先に照合する必要がある
・どちらが正本かを決めないと競合する
・primary email や UPN を今後変える可能性があると面倒
・いきなり自動停止 / 自動削除まで入れると事故りやすい

つまり、「自動化機能がある」ことと「いま導入すべき」ことは別です。

本構成で最初にやるべきことは、自動化そのものではなく、既存ユーザーの台帳化と照合です。

Microsoft 側はどこまで整理できるか

Microsoft 側については、ある程度まで素直に整理できます。

1. カスタムドメインの利用

Microsoft Entra では、tenant.onmicrosoft.com 以外に、自社ドメインや管理用サブドメインを追加してユーザー名に使えます。初期の onmicrosoft.com ドメインは削除できませんが、カスタムドメインを追加して主として使うことはできます。(Microsoft Learn: Add your custom domain name to your tenant)

そのため、Microsoft 側の UPN を例えば user@ms.example.co.jp に揃える、という設計は現実的です。

2. グループベースライセンス

既に触れたとおり、ライセンスはグループに寄せられます。たとえば次のような整理が可能です。

MS-Windows-Office
  → Business Premium

MS-Windows-NoOffice
  → Intune + Entra P1 + Defender

MS-NoWindows
  → Microsoft ライセンスなし

ここまでやれば、少なくとも Microsoft ライセンスの付け忘れ・外し忘れはかなり減らせます。

3. ただし「誰をどのグループに入れるか」は手動になる

最終的にはここを人手で行う必要があります。

・その人は Office ありか、なしか
・Windows 利用者か、端末なしか
・管理者か、通常社員か
・Pilot 対象か

この判定ルールを、毎回人が見て判断することになります。

本構成が向いているケース

次の条件なら、本構成で十分に運用可能です。

・社員数が20〜50名程度
・入退社がそれほど多くない
・Google / Microsoft 以外のSaaS連携がまだ少ない
・グループ設計が比較的単純
・台帳運用を丁寧にできる
・削除は自動化せず、まず停止までに留める

特に、既存の Google / Microsoft ユーザーをそのまま使いたい場合は、最初から大きい自動化を入れない方が安全です。

本構成が厳しくなる境界線

逆に、次の状態になると本構成は厳しくなります。

・社員数が増えて入退社が増える
・契約社員、外部協力者、兼務者が増える
・Google / Microsoft 以外のSaaSが増える
・ライセンス区分が増える
・有効開始日 / 無効開始日 / 削除予定日を持ちたくなる
・監査証跡をきれいに残したくなる
・停止漏れやライセンス剥奪漏れを減らしたくなる

ここで必要になるのが、

・ID突合
・差分確認
・グループ連携
・ライセンス連携
・入退社処理の時限制御

です。

つまり、第4弾の時点で見えてくる限界が、そのまま第5弾のテーマになります。

いま時点の実務的な着地点

本構成では、以下を運用標準にするのが妥当です。

1. ID台帳を必ず持つ

社員番号
localPart
会社メール
Google primary
Google object
Microsoft UPN
Microsoft object
利用区分
ライセンス区分
状態

2. local part を揃える

user@example.co.jp
user@g.example.co.jp
user@ms.example.co.jp

3. Microsoft ライセンスはグループで寄せる

個別手動ではなく、最低限グループベースまで整理します。

4. 削除ではなく停止を基本にする

退職時も、いきなり hard delete しない方が安全です。

5. 管理者・break-glassアカウントは通常運用から分ける

通常社員台帳と同じ扱いにしない方がよいです。

まとめ

Google Workspace と Microsoft Entra を併用する構成は成立します。

ただし、成立させる条件は明確です。

・既存ユーザーを壊さない
・ID台帳を持つ
・@の前を揃える
・Microsoft 側ライセンスはグループに寄せる
・削除は自動化しない
・管理者アカウントを分離する

この構成は、20〜50名規模なら十分現実的です。

一方で、

・入退社処理
・異動
・グループ更新
・ライセンス付与/剥奪
・停止漏れ防止
・監査

を人手運用で回す限界も見えてきます。

参考情報

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up