【IT PMI連載 第7回】IdP / SSO統合設計 ― Entra ID・Okta・Google Workspaceの統合パターン
M&A後のIT統合において、最も技術的な設計力が求められるのが認証基盤（IdP）の統合です。
買収元がEntra ID（旧 Azure AD）を使い、買収先がGoogle Workspaceを使っている。あるいは、どちらかがOktaをIdPとして利用している。こうした異なる認証基盤の統合は、他のすべてのシステム統合の前提条件となるため、最初に設計すべきテーマです。
第7回では、IdP / SSO統合の設計パターンと実務上の判断基準を解説します。
なぜIdP統合が最初に必要なのか
IdP（Identity Provider）は、社員のアカウント・認証・アクセス制御の中核です。メールもファイル共有もSaaSも、すべてIdP上のアカウントを起点に利用されます。
IdPが統合されていない状態では、以下のような問題が発生します。
- 社員が複数のIDとパスワードを管理する必要がある
- 入退社時のアカウント発行・削除が二重作業になる
- 統一的なアクセス制御（条件付きアクセスなど）が適用できない
- SaaSのSSO連携がバラバラで管理が困難
つまり、IdPの統合は「ユーザー体験」と「セキュリティ」の両方に直結する最重要課題です。
よくある統合パターン
パターン1：片方に寄せる（完全統合）
一方のIdPをメインに据え、もう一方のユーザーを移行します。最もシンプルで、最終的にはこの形を目指すケースが多いです。
Entra ID に寄せる場合
- 買収先のユーザーをEntra IDに作成
- 買収先が使っていたSaaSのSSO設定をEntra IDに切り替え
- Google Workspaceは廃止、またはEntra IDからSAML連携で利用
Google Workspace に寄せる場合
- 買収元のユーザーをGoogle Workspaceに作成
- Entra IDは廃止、またはGoogle WorkspaceからSAML連携
判断基準： 利用しているSaaSの数、Microsoft 365 / Google Workspaceのどちらがメインか、ライセンスコスト、社員の習熟度で判断します。
パターン2：Oktaを上位IdPにする
両社がそれぞれEntra IDとGoogle Workspaceを使っている場合、Oktaを「上位のIdP」として配置し、両方をソースとして統合する方法です。
メリット： 移行期間中も両環境を併存でき、ユーザーへの影響が最小限。SaaSのSSO連携を一元管理できる。 デメリット： Oktaのライセンスコストが追加で発生。3つのIdPが存在する複雑な期間が生まれる。
パターン3：段階的移行（共存期間を設ける）
まず2つのIdP間で信頼関係（フェデレーション）を構築し、共存期間を経て段階的に統合する方法です。
Entra ID間のクロステナント同期 を使えば、2つのMicrosoft 365テナント間でユーザーオブジェクトを同期し、リソースへの相互アクセスを可能にできます。完全な統合前の「橋渡し」として有効です。
B2Bゲストアクセス を使って、一方のテナントのユーザーをもう一方にゲストとして招待し、SharePointやTeamsのリソースにアクセスさせる方法もあります。暫定策として即座に実装可能です。
設計時の判断フレームワーク
IdP統合の設計では、以下の5つの軸で判断します。
1. メインのワークスペースはどちらか。 Microsoft 365がメインならEntra ID、Google Workspaceがメインならそちらに寄せるのが自然です。
2. SaaSのSSO連携数。 どちらのIdPにより多くのSaaSがSSO連携されているかを確認します。SSO連携の付け替えは工数がかかるため、多い方をメインにする方がコストを抑えられます。
3. ディレクトリのデータ品質。 ユーザー属性（部署、役職、マネージャー情報など）がきちんと管理されている方をメインソースにした方が、移行後のデータ品質が高くなります。
4. 条件付きアクセスの要件。 Entra IDの条件付きアクセスポリシーは非常に強力で、デバイスコンプライアンス連携（Intune）や場所ベースのアクセス制御が可能です。高度なアクセス制御が必要な場合はEntra ID側に寄せることを推奨します。
5. SCIMプロビジョニングの対応状況。 自動化されたアカウント管理（SCIM）が設定されているかどうかも判断材料です。SCIMが機能しているIdPをベースにした方が、統合後の運用負荷が低くなります。
移行時の注意点
MFAの再登録
IdPを切り替えると、ユーザーのMFA登録情報（認証アプリ、電話番号）は基本的に引き継がれません。移行と同時にMFAの再登録が必要になるため、社員への事前案内と登録サポートの体制を用意します。
SaaSのSSO切り替え
SaaSのSSO設定を旧IdPから新IdPに切り替える際、切り替え中の数分〜数十分はそのSaaSにログインできなくなります。営業時間外に実施するか、事前にパスワードログインを一時的に有効化しておくなどの対策が必要です。
サービスアカウント・共有アカウント
「info@〇〇.com」のような共有メールボックスや、API連携用のサービスアカウントは、通常のユーザー移行とは別の手順が必要です。これらは事前に洗い出し、移行計画に組み込みます。
メールドメインの移行
IdP統合に伴ってメールドメインを移行する場合（例：買収先の社員のメールアドレスを変更する場合）、外部の取引先への周知、名刺の変更、自動転送設定の期間設定など、ITだけでは完結しないタスクが発生します。
統合後のアーキテクチャ例
推奨構成：Entra IDをメインIdPとする場合
Entra IDをメインIdPとし、条件付きアクセスでデバイスコンプライアンス（Intune）と組み合わせるのが、Microsoft 365をメインワークスペースとする企業では最も安定した構成です。
Google Workspaceを併用する場合は、Entra IDからGoogle WorkspaceへSAML SSO連携を設定し、Google側でのパスワード認証を無効化します。
SaaSへのSSO連携はEntra IDの「エンタープライズアプリケーション」から一元管理し、SCIMプロビジョニングで自動化します。
まとめ
IdP統合は、IT PMI全体の「背骨」となる設計です。ここを間違えると、後続のすべての統合作業に影響が出ます。逆に、IdP統合がきれいにできれば、SaaS統合もセキュリティ統合もスムーズに進みます。
次回は、IdP統合と密接に関連する「テナント統合の実務」について、Microsoft 365とGoogle Workspaceの具体的な移行手順を解説します。
まとめ・ご相談
M&A後のIT統合やテナント移行をご検討の方は、Project365（ITプロジェクト支援・IT PMI）をご覧ください。
貴社のIT課題について、まずは60分の無料相談でお気軽にご相談ください。