はじめに
本記事では、Microsoft 365（以下、M365）を主たるコミュニケーション基盤として利用している企業を対象に、Google Workspace（以下、GWS）を補完的に併用することでレジリエンシーを高める構成について整理します。
多くの企業では、メールやチャット、オンライン会議といったコミュニケーション基盤を M365 に統合してきました。 特にコロナ禍以降、Teams と Exchange Online を中心としたデジタルワークプレースは、事業継続上の中核インフラになっています。
一方で、一部のミッションクリティカルな業界では、数時間のコミュニケーション停止が対外信用や収益に直結することから、クラウドサービスの全面障害に備え、クラウド移行後もオンプレミスのメールサーバーや別系統のチャット／会議基盤を「バックアップ」として維持している例もあるかと思います。
ただしオンプレミス基盤をバックアップとして残し続けるアプローチは、ハードウェア更改・パッチ適用・運用要員といった観点で、長期的な負荷が無視できません。
M365 を前提としつつ、既存インフラと組み合わせながらGWS の一部機能（メール／チャット／会議）を併用することで、クラウド同士の組み合わせによるクイックなレジリエンシー向上について具体像を前編と後編に分けて検討していきます。
M365 メイン利用を前提としたレジリエンシー強化の論点
M365 単体でも可用性は高水準ですが、一部の組織では次のような高レベルな要件が存在する場合があります。
・内外とのメールや会議が数時間止まるだけでも業務インパクトが大きい
・特定クラウドベンダーへの依存リスクを抑えたい
・オンプレミスの冗長系を維持する代わりに、クラウド間で冗長化を行いたい
とはいえ、社内全利用者の環境を二重化する場合、ライセンスコストと情報システム部門の運用負荷に対するインパクトが大きくなります。
そこで本記事では、M365 を全社標準としつつ、
・レジリエンシーが特に求められる一部の従業員を GWS 併用可能とする
・GWS はメール／チャット／会議といったコラボレーション用途に限定する
・ユーザー／ID／セキュリティポリシーは可能な限り M365/Entra ID に集約する
という前提で構成を検討します。
このとき M365 管理者が気にすることになるのは、主に次の三点になるかと思います。
・GWS側のユーザーやグループを二重管理せずに済むか
・有事の際の即時利用が可能なよう、メールや予定表のデータをどの程度同期・連携できるか
・セキュリティレベルやポリシーを M365 と揃えられ、二重管理を抑制できるか
以下では、これらの観点を順に考えていきます。
レジリエンシー観点における GWS の役割整理
機能対応だけ簡単に整理すると、Exchange Online に相当するのが Gmail、Teams のチャットに近いのが Google Chat、Teams 会議に対応するのが Google Meet です。
ファイルについては OneDrive／SharePoint に対し Google Drive がありますが、本構成ではデータガバナンスを考慮し、原則として M365 側を一次データストアとし、GWS 側のファイル機能はレジリエンシー構成の必須要素には含めない前提として考えます。
GWS は、「メール／チャット／会議のバックアップ基盤」という役割に絞り、コンテンツやチームサイトなどのコラボレーション資産は M365 に集約する設計です。
この役割分担により、「レジリエンシー向上」という目的と「データ散在によるガバナンス負荷の増大」をバランスさせやすくなり、情報システム部門における運用負荷も抑制されます。
ユーザー／ID を共通化する：Entra ID を単一ディレクトリに
まず、サービス利用の前提となるユーザーやグループといったIDオブジェクトについて考えます。M365を利用する多くの企業ではオンプレミスADからの同期やIDMS基盤からのプロビジョニング運用がEntra IDに対して既に行われているものと思います。
GWSでも同様のプロビジョニング処理が可能ではありますが、同期基盤の新規導入や恒久運用といった負荷が生じます。
ユーザーやグループの管理については、Entra IDを単一ディレクトリとして用い、そこから GWS へ自動プロビジョニングすることで、二重管理を避けることができます。
Entra ID のエンタープライズアプリとして「Google Cloud / G Suite Connector」を登録し、SCIM による自動プロビジョニングを有効化すると、Entra ID 上のユーザー／グループを GWS に自動で作成・更新・無効化することが可能です。
同期対象を特定のセキュリティグループに限定できるため、「レジリエンシー対象グループ」に所属するユーザーだけを GWS 側に作る、といった運用が現実的です。
M365 管理者視点では、「Entra ID にユーザーを作成すれば、M365 と GWS 両方に必要なリソースが自動で用意される」イメージです。
異動や退職に伴う属性変更・無効化についてもEntra ID 側と統一され、個別基盤の構築を実施せずともID ライフサイクルの一貫性を保ったままマルチクラウド構成を実現できます。
認証とセキュリティポリシー：平常時は Entra ID に統合
認証については、平常時は Entra ID をアイデンティティプロバイダー（IdP）として GWS へ SAML シングルサインオンを構成するのが基本となります。これにより、ユーザーは M365 と同じ認証基盤・同じアカウントで GWS を利用でき、認証セキュリティポリシーも Entra ID 側に集約されます。
この構成の利点は、既に Entra ID で整備しているセキュリティポリシーを、GWS へのアクセスにもそのまま適用できる点です。たとえば、
・条件付きアクセスによるネットワーク／デバイス制御
・Intune管理デバイスのコンプライアンスポリシー準拠判定
・MFA の必須化
・リスクベースサインインのブロック
といった制御を、M365／GWS の両方に対して一貫した形で適用でき、M365で構築したセキュリティ基準をGWS上に再構築や二重運用を行う必要がなくなります。
Entra ID 障害時を見据えた具体的な備え
一方で、レジリエンシーという観点では「Entra ID 自体が全面的に障害を起こすケース」も想定しておく必要があります。ここに対しては、次のような多層的な備えを組み合わせることが考えられます。
まず GWS 側には、SAML（Entra ID）経由でログインする通常ユーザーとは別に、ローカルパスワード＋Google 独自の 2 段階認証（2SV）でログインできるバックアップ用アカウント（いわゆるブレークグラスアカウント）をシステム管理者向けに用意し、有事のIdP切替えアカウントとして確保しておきます。
次に、SAML SSO 自体は有効に保ちつつ、一部ユーザーについては「IdP 障害時にローカルログインへ切り戻す」ための運用手順をドキュメント化します。
具体的には、GWS 管理コンソールでの SSO 無効化手順、パスキーによるパスワードレス認証を利用していない場合は非常用パスワードの配布方法などを事前に定め、定期的に訓練しておく形です。
これにより、「Entra ID ダウン時の GWS 道連れ」という状況を回避します。
Exchange Online や Teams の部分的サービス障害時においてはこれらの考慮は不要ですが、Entra ID 認証基盤の全面障害時を考慮した場合はこられの備えを行っておくことが重要です。
逆にEntra ID全面障害時の切替えを一切無くす構成においては、IDプロビジョニングや認証ポリシー類について個別管理と恒久的な維持が必要となるため、レジリエンシー観点での復旧目標時間との兼ね合いで検討する必要があります。
なお、M365の認証についてもEntra IDではなくサードパーティのIdPを利用しているような構成においては、GWS認証も同様のサードパーティIdPを利用することでこの課題は解消されます。
おわりに
ここまで前編では、M365 を前提としたまま GWS を併用する際の基本的な考え方として、役割分担と共通化の軸を整理しました。
後編では、この前提を踏まえ、サービス間でのデータ同期やサービス障害時の具体的な障害シナリオで、M365 と GWS 間でどのよう対応を実施すべきか実務的な観点から掘り下げていきます。
※記載されている会社名、 商品名、またはサービス名は、各社の登録商標または商標です。