はじめに
前編では、Microsoft 365（M365）を主たるコミュニケーション基盤としつつ、Google Workspace（GWS）を補完的に組み合わせる際の前提条件として、「ID とセキュリティをどこに寄せるのか」「GWS をどの役割に限定するのか」 といった設計の軸となる部分を整理しました。
Entra ID を単一ディレクトリとしてユーザーとグループを一元管理し、認証と条件付きアクセスも Entra ID 側に集約することで、マルチクラウド構成でありながらポリシーや統制レベルを揃える案を記載しました。
後編となる本記事では、その前提を踏まえて一歩踏み込み、実際のレジリエンシー向上に直結する技術要素と運用シナリオを扱っていきます。
メールの二重配送とデータの共通化
レジリエンシー構成で最も重要視されるコンポーネントの一つがメールです。
ポイントは、「対象ユーザーの受信メールを、M365 と GWS の両方に届け、バックアップ側のメールボックス内のアイテムも常に最新化しておく」ことです。
やり方としては、概ね次の二通りが考えられます。
1つ目は、既存の Secure Email Gateway（SEG）からの二重配送です。
SEG を社外からのメールの入り口とし、そこから Exchange Online と GWS の両方に対して配送を行います。多くの SEG 製品は複数の配送先を設定できるため、M365 側と GWS 側で同じメールを受信する構成が可能です。
Exchange Onlineの前段にサードパーティのSEGが存在している場合に利用可能な構成です。
2つ目は、GWS 側の「二重配信（二重配送）」機能を利用する方法です。
GWS ドメインに届いたメールを、Gmail の受信トレイと、別の SMTP サーバー（既存のメールサーバーや Exchange Online）に同時配送する構成がサポートされています。
これはExchange Online の前段にSEGが存在しない場合の構成となります。
ただし、このパターンの問題点はプライマリの受信がM365ではなく、GWSとなる点です。
Exchange Online には二重配送に該当する機能が存在していないため、組織全体の受信メールの複製転送という要件を満たすためには、GWSをプライマリとして受信させる必要があります。 このため、MXレコードをGWS側に持たせ必要があり、GWS側でも一定のメールセキュリティに関する設計考慮が必要となります。
なお、GWSを利用するユーザーが極少数である場合に限り、Exchange Onlineのトランスポートルールにて1:1 の複製転送ルールを各個作成する事は可能です。
どちらのアプローチでも、対象ユーザーの受信メールは常に M365 と GWS の両方で保持されるため、Exchange Online に障害が発生しても Gmail 側から同じメールを参照し、同一ドメインの送信者アドレスでやり取りを続行できます。
なお、「送信メール」の二重配送には対応していないため、これに関しては割切りが必要となりますが、少なくとも受信メールについては「二重化された単一の業務ストリーム」として扱えます。
予定表連携：M365 側からの同期と Calendar Interop
予定表連携については、M365 を軸に「どちらで予定を登録しても、双方から参照できる」状態を作ることがポイントです。M365 側から見たアプローチは大きく二つあります。
Teams / Exchange Online からの双方向同期
1つ目は、Microsoft Teams（実体は Exchange Online の予定表）と Google カレンダーの間で双方向同期を行う機能を利用する方法です。Teams 管理センターのセットアップウィザードから、Google Workspace 側に「Microsoft 365 Mail Migration and Calendar Sync」アプリをインストールし、Google のユーザーと M365 のユーザーをマッピングすると、両者の予定表を双方向に同期させることができます。
この方式の特徴は、ユーザー単位でイベント（予定）そのものを相互にコピーし合う点にあります。 Teams／Outlook で作成した予定が Google カレンダーに反映され、Google カレンダーで作成した予定が Exchange Online 側にも同期されるため、ユーザーは「どちらのクライアントを使っても同じ予定が見える」体験を得られます。
M365 管理者視点では、「Exchange Online の予定表をマスターにしつつ、Google 側にもミラーリングする」イメージです。
ユーザマッピングはプライマリアドレス等の属性自動一致または、CSVアップロードによる任意マッピングが可能です。
なお、類似機能としてM365⇔GWSのFree/Busy予定表共有を行う「Calendar Interop」という機能がGWSに存在しますが、これはあくまでも両サービス間の「相互参照」という機能であり、「相互同期」という機能ではありません。
障害シナリオから見た挙動イメージ
ここまでの構成を前提として、いくつか代表的な障害シナリオを俯瞰しておきます。
・Exchange Online 障害時
二重配送により同一の受信メールが GWS 側にも保存されているため、対象ユーザーは Gmail からメール参照・送受信を継続できます。ドメインも同一で運用可能なため、対外的に「バックアップメールアドレス」へ切り替える必要はありません。
ただし、MXレコードがExchange Onlineを直接参照しているような構成（外部メールをExchange Online /EOP / MDOが直接受信する構成）の場合は、MXレコードをGWSへ切替える作業が必要となります。
・Teams 障害時
Teams 単体障害時では、「チャット／会議チャネルの切替え」をどう設計しておくかがポイントになります。この構成では、レジリエンシー対象ユーザーについてはあらかじめ Google Chat / Google Meet を利用可能な状態にしておき、Teams 障害を検知した時点で「日常のチャット・会議を一時的に GWS 側へ切り替える」運用を想定します。
社内連絡はメール（Exchange Online）と GWS 側チャットを併用し、外部との会議については、インバイトメール自体は引き続き Exchange Online から配信しつつ、会議 URL を Teams から Google Meet に置き換えたテンプレートをあらかじめ用意しておくことで、運用上の切り替え負荷を抑えることができます。
また、Teams からのカレンダー同期により「予定枠」はそのまま活かしつつ、会議本体だけを Google Meet に振り替えることができます。ユーザー視点では、Outlook 上の既存の会議を一旦キャンセルして再招集するのではなく、「会議 URL だけ差し替えた更新通知」を送る形にできれば、社内外参加者への影響を最小限にとどめられる形になります。
また、Teams からのカレンダー同期により「予定枠」はそのまま活かしつつ、会議本体だけを Google Meet に振り替えることができます。ユーザー視点では、Outlook 上の既存の会議を一旦キャンセルして再招集するのではなく、「会議 URL だけ差し替えた更新通知」を送る形にできれば、社内外参加者への影響を最小限にとどめられる形になります。
・Entra ID 認証障害時
ブレークグラスアカウントを用いて M365 管理ポータルへのアクセス可否を確認しつつ、必要に応じて GWS の SSO を一時的に無効化し、バックアップ用ローカルアカウントでログインできるようにします。この際、「誰が／どの条件で切り替えを行うか」「どのタイミングで通常運用に戻すか」を含めた運用設計と訓練が重要になります。
「何が落ちたときに、どのチャネルと認証方式で社内外と連絡を取るか」をシナリオとして具体化しておくことが、マルチクラウド構成の価値を引き出すうえで重要です。
おわりに：レジリエンシーとクラウド戦略の両面から
本記事では、M365 を主たるコミュニケーション基盤とする企業に向けて、GWS を併用することでレジリエンシーを高める構成案を整理しました。
全利用者を二重化するのではなく、レジリエンシーが特に求められる一部の従業員に限定して GWS をバックアップとして付与し既存インフラを活用することで、ライセンスコストと運用負荷を抑えつつ、業務継続上クリティカルなユーザーのコミュニケーション手段をクイックに強化するという考え方を紹介しました。
| 項目 | M365 側 （メイン） | GWS 側 （バックアップ） |
ポイント |
| ユーザー／グループ管理 | Entra ID を単一ディレクトリとして管理 | Entra ID から自動プロビジョニングでユーザー／グループを作成・更新 | ID ライフサイクルを Entra ID に集約し、「対象グループのみをGWS へプロビジョニング」する設計 |
| 認証・条件付きアクセス | Entra ID にてGWSに対してM365同等のよるサインイン、条件付きアクセスポリシーを適用 | 平常時は Entra ID を IdP とした SAML SSO でのログイン設定 | Entra ID の MFA／CA ポリシーを GWS へのアクセスにも適用し、セキュリティレベルを統一化 |
| メール | 構成に応じてETRを作成しGWSへの複製配送を設定する | SEG／二重配信機能で EXO と同じメールを受信 | 受信メールを常に両方へ配送し、EXO 障害時も Gmail から業務継続 |
| 予定表 | GWSとの予定同期を設定 | Teams／EXO からの同期を設定 | M365 側を起点に Google カレンダーと同期し、双方から最新の予定・空き時間を参照可能 |
| チャット・会議 | Teams を日常利用の主チャネルとして運用 | Google Chat / Google Meet をバックアップチャネルとして待機 | 平常時から一部ユースケースで GWS も使い、障害時に即座に切り替えられるよう訓練を行う |
併せて、M365 と GWS のマルチクラウド構成には、レジリエンシー以外の側面もあります。特定のクラウドベンダーだけに全面的に依存しない構成を取ることで、中長期的なサービス選定の自由度を確保しやすくなり、自社要件や環境変化に応じた機能・コスト・サポートレベルなどを総合的に評価するための「選択肢」を持ち続けることができます。
こうした選択肢の存在は、将来のクラウド戦略や投資判断を行ううえで、社内外のステークホルダーとより対等な立場で議論するための材料にもなり得ます。
近年は M365 のライセンス価格やプラン構成の見直しが続いていることもあり、GWS の本格利用も含めて複数サービスを比較検討する企業も増えつつあります。
レジリエンシー向上を主目的として一部ユーザーから GWS の併用を始めておくことは、いざサービス選択の幅を検討する局面になったときに、機能・運用・コストを実体験に基づいて評価できるという意味で、副次的な効果を持つと言えます。
コミュニケーション基盤のレジリエンシー高度化は、技術要素だけで完結するテーマではなく、業務継続計画（BCP）、コスト管理、セキュリティ／ガバナンス、そして中長期のクラウド戦略が交差する領域とも言えます。
自社にとって「止められない業務」「止められないユーザー」がどこにいるのかを改めて整理したうえで、１サービス単独ではカバーしきれないリスクを マルチクラウド構成でどこまで低減するのか。
本記事がその検討を進める際の材料になれば幸いです。
※記載されている会社名、 商品名、またはサービス名は、各社の登録商標または商標です。