はじめに
前回は、単純に Google Workspace と Microsoft Entra を併用する構成を整理しました。
これまでの記事は以下になります。
- Google Workspaceを使い続けながらWindows端末管理をIntuneへ移行する設計パターン
- IDをベンダに依存させないためのGoogle / Microsoft分離設計
- オンプレADを廃止する前に確認すべきWindows端末移行パターン
- Google WorkspaceとMicrosoft Entraを併用する構成
この構成は20〜50名規模なら十分に運用可能です。
ただし、現実に運用していくと、次のような負荷が見えてきます。
・入社時に Google と Microsoft の両方へアカウントを作る必要がある
・異動時に Google / Microsoft の両方でグループ変更が必要
・退職時に停止漏れやライセンス剥奪漏れが起きやすい
・Windows 利用区分ごとの Microsoft ライセンス管理が煩雑になる
・既存ユーザーの突合と台帳維持が人手依存になる
ここで候補になるのが、IDaaS です。
今回は国産IDaaSのEXITC を使うことを考えます。
ただし、この記事で扱うのは「EXTIC に全部任せる」ような設計は行いません。
EXTIC を唯一の認証基盤にせず、既存の Google / Microsoft ID をそのまま活かしながら、ID運用を自動化する層として使う設計です。
この記事は特定環境の実構成ではなく、公開用に抽象化した設計パターンです。
実ドメイン、実グループ名、管理者アカウント、運用中の詳細設定は記載しません。
結論
結論から書きます。
EXTIC は「唯一のIdP」や「唯一のID正本」にせず、Google Workspace と Microsoft Entra の間に置く“依存しない自動化層”として使うのがよいです。
設計の要点は次です。
1. Google / Microsoft の既存ユーザーはそのまま使う
2. 会社メール、Google ID、Microsoft ID は分離を維持する
3. EXTIC は ID突合、差分確認、グループ・ライセンス連携に使う
4. break-glass 管理者は EXTIC 管理外にする
5. hard delete は自動化しない
6. EXTIC が停止しても Google / Microsoft に直接ログインできるようにする
7. 会社ID台帳は EXTIC 外にも保持する
つまり、EXTIC は便利な自動化エンジンとして使うが、止まったら全社ログイン不能になるような使い方はしない、という方針です。
前提となるIDモデル
この記事で扱う前提は、次のような分離モデルです。
会社メールアドレス:
user@example.co.jp
Google Workspace ID:
user@g.example.co.jp
Microsoft Entra ID:
user@ms.example.co.jp
そして、user の部分、つまり local part は揃えます。
会社メール: yamada@example.co.jp
Google ID: yamada@g.example.co.jp
Microsoft ID: yamada@ms.example.co.jp
この構成では、Google と Microsoft の既存アカウントを維持したまま、両者の対応関係を外部から管理することが重要です。
なぜ EXTIC を入れるのか
前回の記事でも触れたとおり、EXTIC がなくても台帳と手動運用で回せる範囲はあります。
ただし、以下のような要件が出てくると、人手だけではきつくなります。
・新入社員の作成を Google / Microsoft に同時反映したい
・異動時に所属グループを両方で揃えたい
・Windows 利用区分に応じて Microsoft ライセンスを自動で切り替えたい
・有効開始日 / 無効開始日 / 削除予定日を持ちたい
・停止漏れを減らしたい
・誰がどのID情報を変えたかを追いたい
EXTIC は、Google Workspace や Microsoft 365 を含む各種クラウドサービスへの ユーザー・グループ情報連携、Microsoft 365 への ライセンス付与・剥奪、さらに IDライフサイクル管理 を持っています。(EXTIC 公式: ID管理機能)
つまり、今回の構成における EXTIC の役割は、
・既存アカウントの突合
・属性の正規化
・グループ連携
・Microsoft ライセンス連携
・入退社処理の補助
です。
「依存しない自動化層」とは何か
ここが一番重要です。
EXTIC を導入するときに避けたいのは、次のような設計です。
悪い例:
Google も Microsoft も、全部 EXTIC を通らないとログインできない
EXTIC が唯一のID正本で、他に台帳がない
EXTIC から削除を自動実行する
管理者や break-glass まで EXTIC に依存する
これだと、EXTIC 停止時に影響が大きすぎます。
一方で、今回推奨するのは次の考え方です。
Google:
Google 側認証は Google に残す
Microsoft:
Microsoft 側認証は Microsoft に残す
EXTIC:
認証の中心ではなく、ID運用の自動化・整合化を担当する
このように、ログイン経路は Google / Microsoft 側に残し、EXTIC は運用の自動化だけを担当すると、依存度を下げられます。
構成イメージ
公開用に抽象化すると、構成は次のようになります。
ポイントは3つです。
1. 会社ID台帳は EXTIC 外にも持つ
2. Google / Microsoft の既存ユーザーは残す
3. 緊急管理者は EXTIC 管理外にする
既存ユーザーをそのまま使うための考え方
今回の前提では、既に Google と Microsoft の両方にユーザーが存在しています。
そのため、EXTIC 導入時にやるべきことは、まず 新規作成ではなく突合です。
最低限、次の情報を持つ必要があります。
employeeId
localPart
会社メール
Google primary email
Google user ID
Google aliases
Microsoft UPN
Microsoft object ID
Microsoft 旧UPN
利用区分
ライセンス区分
状態
ここで重要なのは、メールアドレスやUPNだけでなく、Google user ID と Microsoft object ID を持つことです。
理由は単純で、将来メールアドレスや UPN が変わる可能性があるからです。
既存ユーザーを長く安全に扱うには、表示用属性と照合用属性を分ける必要があります。
EXTIC で最初に自動化すべきこと
いきなり全部を自動化しない方がよいです。
最初は、以下の順で進めるのが安全です。
1. 突合と差分確認
まずは 既存 Google / Microsoft ユーザーの対応表を作り、差分を見つけます。
・Google にだけ存在するユーザー
・Microsoft にだけ存在するユーザー
・localPart が一致しないユーザー
・旧 onmicrosoft.com UPN が残っているユーザー
・ライセンス区分と実ライセンスが一致しないユーザー
・退職者が残っているユーザー
この段階では、EXTIC から Google / Microsoft へ書き込まなくても十分価値があります。
2. Microsoft 側のグループ・ライセンス連携
次に価値が出やすいのは、Microsoft 側です。
たとえば次のように、利用区分に応じてグループを決めます。
windows_office
→ Business Premium 付与グループ
windows_no_office
→ Intune + Entra P1 + Defender 付与グループ
none
→ Microsoft ライセンスなし
EXTIC は Microsoft 365 に対して、ユーザー情報・グループ情報の連携と、ユーザー単位のライセンス付与・剥奪に対応しています。(EXTIC 公式: ID管理機能)
この部分を EXTIC で整理できると、少なくとも Microsoft 側の運用はかなり楽になります。
3. 入退社処理の補助
次の段階で、入社日・退職日などの日付制御を使います。
入社日:
Google / Microsoft を有効化
退職日:
Google / Microsoft を停止
Microsoft ライセンスを剥奪
一定期間後:
手動承認のうえで削除
重要なのは、最初から hard delete を自動化しないことです。
停止とライセンス剥奪までを自動化し、削除は人が最終判断する方が安全です。
EXTIC でやらない方がよいこと
導入初期に避けるべきことは明確です。
1. Google / Microsoft の認証を全部 EXTIC に寄せる
これは依存度が高すぎます。
ログイン障害時の影響が大きくなります。
2. break-glass 管理者を EXTIC 管理下に置く
緊急用管理者アカウントは、EXTIC や通常の自動化から外しておくべきです。
Microsoft も、緊急アクセス用アカウントは通常の依存関係から切り離しておくことを推奨しています。(Microsoft Learn: Manage emergency access admin accounts in Microsoft Entra ID)
3. 既存ユーザーを作り直す
既存の Google / Microsoft ユーザーがあるなら、最初は紐付けるだけにします。
既存ユーザーを削除・再作成すると、ライセンス、所有権、共有、監査、端末紐付けに影響が出ます。
4. 自動削除を入れる
停止やライセンス剥奪までは自動化しても、削除は事故の影響が大きいです。
削除は当面、人手確認付きにするのが安全です。
EXTIC が止まっても困らないためのルール
「依存しない自動化層」という考え方を実務で成立させるには、次のルールが必要です。
1. 会社ID台帳を EXTIC 外にも保持する
最低限、次の情報は CSV やスプレッドシート、Git 管理などで別保持します。
社員番号
localPart
会社メール
Google primary
Google user ID
Microsoft UPN
Microsoft object ID
利用区分
ライセンス区分
状態
2. Google / Microsoft へ直接ログインできる状態を残す
EXTIC がなくても、Google 管理コンソールと Microsoft 管理センターで手動運用へ戻せるようにします。
3. グループ設計を Google / Microsoft 側にも残す
EXTIC の内部ルールだけでなく、Google / Microsoft 側でも意味が分かるグループ名にしておくと、障害時に追いやすくなります。
4. 連携経路を一つにする
Google 標準の Office 365 自動プロビジョニングと EXTIC を同時に使うと、二重プロビジョニングになりやすいです。
Google Workspace には Office 365 への自動プロビジョニング機能がありますが、EXTIC を採るなら、少なくとも同じ対象に対して二重に流さない方が安全です。(Google Workspace Admin Help: About automated user provisioning)
段階導入の進め方
EXTIC を導入するなら、次の順番が安全です。
Phase 1:
既存 Google / Microsoft ユーザーの突合
差分確認
Phase 2:
Microsoft 側グループ・ライセンス連携
Phase 3:
Google 側の属性・グループ整理
Phase 4:
新入社員だけを対象に、作成 / 停止フローを段階導入
Phase 5:
退職処理を停止まで自動化
削除は引き続き手動承認
この順番なら、いきなり本番停止事故を起こしにくいです。
EXTIC を入れることで得られる効果
EXTIC をこの形で使うと、次の効果があります。
・既存ユーザーを壊さずに ID整合性を上げられる
・Google / Microsoft をまたぐ運用台帳を整理できる
・Microsoft ライセンス運用を自動化しやすい
・入退社処理の品質を上げやすい
・将来 SaaS が増えたときに拡張しやすい
一方で、認証そのものを全部寄せないため、次も維持できます。
・Google 側障害時の切り分けがしやすい
・Microsoft 側障害時の切り分けがしやすい
・EXTIC 停止時に手動運用へ戻せる
・特定製品への過度依存を避けられる
まとめ
EXTIC を導入する目的は、全部のログインを集約することとは限りません。
今回のように、
・会社メールは独自ドメイン
・Google Workspace は業務基盤
・Microsoft Entra / Intune / Defender は Windows管理基盤
・既存ユーザーはそのまま活かす
という構成では、EXTIC は 唯一のIdP ではなく、ID運用の自動化・整合化を担う層として使うのが現実的です。
重要なのは次の3点です。
1. 既存 Google / Microsoft ユーザーを壊さない
2. EXTIC がなくても手動運用へ戻れるようにする
3. 削除ではなく、まずは突合・グループ・ライセンス・停止から自動化する
この設計なら、EXTIC を活かしつつ、EXTIC に依存しすぎない構成を作ることができます。
次回は、Google Vault 導入とメール配送経路整理の考え方を整理します。