シンプルさの罠：クラウドEメールがBCPの会話に欠かせない理由

クラウドはすべてを簡素化するはずだった。そして、ほとんどのワークロードはそうなった。マイクロソフトの環境で働く人々にとって、Microsoft 365は、電子メール、カレンダー、コラボレーションが単に機能し、それをサポートするサーバーのことを考える必要がない世界を約束し、ほぼ実現した。.

しかし、世界は変わりつつある。貿易摩擦やデータ主権問題はそれを物語っている。停電はもはやエッジケースではない。.

2026年1月に, Microsoft 365が世界的にダウン. .メールが止まった。Outlookが読み込まれない。カレンダーにアクセスできなくなった。爆発半径は1社ではなかった。プラットフォーム上のすべてのテナントが一度に爆発したのだ。.

フォールバックを持たないすべての組織にとって、事業継続は脅かされた。そして、DORAやNIS2のような規制の下で運営されている組織にとって、それはもはや単なる業務上の問題ではない。それは、罰金、報告義務、監督当局の介入の可能性といったリスクを伴う、規制遵守の失敗である。.

複数の管轄区域や業界にわたって、規制当局は事業継続が実際に意味することの基準を引き上げつつある：

• DORA (2025年1月完全施行）：金融部門の組織は、文書化されたICT継続計画を維持し、定期的にテストし、混乱時にもシステムが稼働し続けることを保証し、サードパーティーのクラウドプロバイダーからのリスクを積極的に軽減しなければならない。SLAを導入しているだけでは十分な緩和策とはみなされない。.

監督当局は、組織がコンプライアンスに違反していることが判明した場合、是正計画を課したり、追加監査を実施したり、特定の事業活動を制限したり、監督を強化したりする権限を持っている。.

• NIS2エネルギー、医療、運輸、行政、デジタルインフラにもほぼ同様の義務を課す。電子メールシステムは明示的に対象。罰則 世界の年間売上高の2%. .立証責任は規制当局ではなく、組織にある。.

規制当局は、是正措置を義務付け、コンプライアンスの詳細な証拠を要求し、深刻な場合には、コンプライアンスが回復するまで、必要不可欠または重要なサービスに関連する業務を制限または禁止することができる。.

• GDPRとデータ主権 米国に本社を置くクラウド・プロバイダーとのみ保有している電子メール・データは、サーバーが物理的にどこにあるかにかかわらず、米国CLOUD法の強制開示の対象となる。ヘルスケア、法律サービス、臨床研究などの規制部門に属する欧州の組織にとって、これは現実的かつ継続的なコンプライアンス違反となります。.

規制当局は、組織がデータ居住地と法的管轄権の管理を実証することを期待しているが、これはハイパースケーラが組織に代わって完全に保証することはできない。.

事業継続を求める規制はこれだけではない。業種や地域にもよるが、その他多くの枠組みにも同様の義務が課せられている：

これらのフレームワークすべてに共通するのは、継続性の責任はベンダーではなく組織にあるということだ。「クラウドプロバイダーがダウンしました」では、どの管轄区域の監査人も納得しない。.

答えはM365を放棄することではない。M365を拡張することだ。アクティブ・スタンバイ・アーキテクチャを採用することで、エンドユーザーを混乱させることなく、耐障害性とビジネス継続性を実現することができる。.

このようなアーキテクチャでは、1つの環境が通常状態で100%のライブトラフィックを処理する。もう1つの環境は継続的なパリティを維持し、プライマリに障害が発生したときのトラフィックを引き受ける。当然ながら、フェイルオーバーフローは事前に計画し、テストしておく必要がある。.

下図に見られるように、アクティブ・スタンバイ・アーキテクチャの基盤として機能する3つの重要な側面がある：

1 - アン 自動同期ツールのような CB Exchange Server Sync, このため、プラットフォーム間でメールとカレンダーの双方向性を維持しながら、データの保存場所を完全に管理することができます。.

2 - A メールゲートウェイ, Postfixのような、制御されたバッファを提供することで、停電時にセカンダリエンドポイントにメールを再ルーティングすることができます。.

3 - あらかじめ作成されたメールクライアント・プロファイル, を使用して、ユーザーをセカンダリ・エンドポイントにすばやく切り替えることができます。ファースト・ラン」設定の遅延を避けるため、すべてのエンド・ユーザーは、両方のシステム用にあらかじめステージングされたプロファイルを持っている必要があります。電子メールクライアントとしてクラシックOutlookを使用するか、「ゼロセットアップ」フォールバックとしてすべてのユーザーがOWAを使用するように訓練されることをお勧めします。.

スタンバイ状態にある代替環境については、組織のインフラの好みやソブリン要件に応じて、以下の2つのオプションを検討することができる。.

最高だ： データ主権要件、規制部門、EUベースの業務、または既存のオンプレミスインフラストラクチャを持つ組織。.

どのように機能するのか：

• オンプレミスExchangeは、スタンバイ代替環境として使用され、組織独自のデータセンターでホストされる。.
• CB Exchange Server Syncは、Microsoft 365とオンプレミスのExchangeの間で、メール、連絡先、カレンダーの継続的な双方向同期を維持します。すべてのデータは両方のシステムで同一になります。.
• 通常の状態では、Microsoft 365がすべてのライブトラフィックを処理する。.
• フェイルオーバー時には、メールは自動的にオンプレミスのExchangeを経由します。.

エンドユーザーにとってのフェイルオーバーフローのイメージ：

• Outlookのデスクトップ、モバイル、OWAは、利用可能な環境に接続する。.
• インターフェイスはまったく同じだ（覚えるべき新しいシステムも、従うべき緊急手順もない）。.
• 停電中に作成されたメールは、復旧時に自動的にMicrosoft 365に同期される。.

データ主権の利点：

• 静止状態の電子メール・データは、組織が管理するハードウェア上の、組織の管轄下にあるデータセンターに保管される。.
• 完全なチェーン・オブ・カストディと監査可能性
• DORAの第三者リスク規定に対する直接的で実証可能な回答

監査役が見るもの 稼動している、テスト可能なスタンバイ環境。ポリシー文書ではない。SLAの参照でもない。継続性の証明。.

最高だ： 完全なクラウドの冗長性を好む企業、すでにベンダーの多様化を評価している企業、あるいはオンプレミスのインフラを持たない（あるいは持つことを検討するチームを持たない）企業。.

どのように機能するのか：

• Google Workspaceはスタンバイの代替環境として使用される。これは別のベンダーのインフラであり、別のデータセンターのフットプリントであり、別の障害表面である。.
• Postfixのようなメールゲートウェイは、イングレスを一元化してルーティングを管理し、MXの伝播とは独立してフェイルオーバーフローを制御する。
• CB Exchange Server Syncは、バックグラウンドでGoogle Workspaceと双方向のメールとカレンダーのパリティを静かに継続的に維持します。両方のシステムで同じデータを使用できます。.
• 通常の状態では、Microsoft 365は100%のライブトラフィックを処理する。.
• フェイルオーバー時には、ゲートウェイで半自動ルーティングフリップがトラフィックをGoogle Workspaceにリダイレクトする。.
• これにより、MXブレーン・スプリット（ライブ移行中にMXレコードの変更がDNSリゾルバ間で矛盾して伝播する場合に発生するスプリット・ルーティングの衝突）を回避できる。.

エンドユーザーにとってのフェイルオーバーフローのイメージ：

• Outlookを使い慣れたユーザーは、フェイルオーバー期間中、メールコネクター経由でOutlookを使用することも、GmailウェブまたはGmailモバイルインターフェースに切り替えることもできる。.

データ主権ノート

このオプションは、インフラを所有したり保守したりする必要がないため便利だが、オプション 1 のようなオンプレミス所有権の保証はない。データ主権はGoogle Workspaceの導入構成とリージョン設定に依存する。管轄権の要件が厳しい組織では、オプション1の方がより強力な選択肢となる。.

どの展開パターンが組織に適合するかにかかわらず、基盤となるアーキテクチャは同じ保証を提供する：

• 冗長性 エンドユーザーには見えず、監査人には見える
• アクティブ・スタンバイ・アーキテクチャ 継続的な同期コールドスタンバイ、バックアップ・リストア、手動でのデータ復旧は不要です。
• A フェイルオーバーフロー 必要とされる前に計画され、テストされるもの

• デフォルト状態としての監査対応DORAやNIS2の審査官が、組織として電子メールの継続性をどのように確保しているかを質問したとき、その答えは、ベンダーのSLAを参照したポリシー文書ではなく、稼動している生きたシステムである。
• 商業的差別化要因としての主権:EUでは、公共部門や重要インフラとの契約の多くが、国内またはEU域内のみのデータ処理を要求している。オーストラリアでは、APRA CPS 230がサードパーティプロバイダーに直接説明責任を課している。米国では、FBIのCJISやNYDFSのような枠組みが、ベンダーではなく組織に機密データの厳格な管理を求めている。この3つのケースすべてにおいて、データ主権を実証できる組織は、クラウドのみの競合他社が入札できないような任務を勝ち取っている。.
• ゼロ・トラスト、電子メールでの運用最も回復力のあるBCPの態勢は、どのようなシステムにも障害が発生する可能性があり、それに応じて設計されることを前提としています。上記で紹介した、継続的な同期を行うアクティブ・スタンバイ・アーキテクチャは、組織が最も失うことが許されないワークロードに適用された場合、その仮定がどのように見えるかを示している。.
• 時代を先取りする投資現在、ハイブリッドメールのレジリエンスに投資している企業は、事後対応ではなく、規制、運用、市場の需要に先手を打つ姿勢を取っている。.

クラウドはすべてを簡素化するはずだった。ほとんどのワークロードでは、それは成功した。しかし レジリエンス（回復力）のないシンプルさは、より良い名前の脆弱性にすぎない.

規制当局の呼び出しがあったとき、あるいは大規模な停電で操業が停止したとき、あなたは “と思うだろうか？“ベンダーのSLAを信頼した”「という答えが受け入れられるだろうか？

単一のクラウドベンダーのアップタイムを盲信する時代は終わり、特に電子メールのような重要なビジネスシステムではそうです。電子メールは、取引先がどのようなプラットフォームを使っていても機能するコミュニケーション・チャネルのひとつです。だからこそ、ほとんどすべてのビジネスクリティカルなやりとりの中核を担っているのだろう。あらゆる顧客関係、規制上の義務、動き出した取引にとって極めて重要です。これが失敗すると、下流のすべてが失敗する。.

これまでMicrosoft 365のみに依存していた組織にとって、ライブでテスト可能なデュアル環境アーキテクチャを構築することは、単なる技術的な賢明さではない。それは今や規制上の常識である。. 完全なソブリン化のためにオンプレミスのExchangeスタンバイを追加しようが、ベンダーの多様性のためにGoogle Workspaceでクラウド間フェイルオーバーを行おうが、ポイントは同じだ。.

レジリエンスは最初から設計されていなければならない。そうすれば、シンプルさが失敗しても、継続性は失敗しない。.

このタイプのアクティブ・スタンバイ・アーキテクチャーの詳細と、その方法について知りたい。 CB Exchange Server Sync あなたのシナリオで機能しますか？私たちの技術専門家との専用の無料相談セッションを確保します：