TL;DR – 概要
コールドバックアップは、障害発生後に Microsoft 365 のデータを復元するために使用されます。しかし、復元処理が行われている間、業務は停止してしまいます。これこそが、多くの事業継続計画で見落とされがちな点です。.
サービス停止中も稼働を続ける組織は、復旧を待ったりはしません。独立したプラットフォーム上のホットバックアップ（Google Workspaceがその実用的な一例です）にフェイルオーバーし、マイクロソフトが問題を解決する間も稼働を継続します。.
結論として： Microsoftのサービスが停止した場合でも、ホットバックアップがあれば、復元を待つことなく、メール、カレンダー、コラボレーション機能を継続して利用できます。この記事では、そのアーキテクチャの仕組みと、いざという時に備えて事前に構築する方法について解説します。.
Microsoft 365とGoogle Workspaceを並行して運用し、業務の継続性を確保する方法について、早速知りたいですか？
エクスプロアe Googleの同期ソリューション from Connecting Software
データベースのレプリケーションアーキテクチャとは異なり、事業継続の観点では、 ホットバックアップ これは、障害発生時にユーザーが即座に切り替えることができる、継続的に同期された代替環境です。A コールドバックアップ これは、データのオフラインまたは接続されていないコピーを指し、プライマリ環境が再び利用可能になった後に限り、文書やデータを特定の時点まで復元するために使用できます。.
ホットバックアップとコールドバックアップ：復旧は事業継続ではない
コールドバックアップでは、昨日の状態に戻ることはできますが、今日という一日を乗り切ることはできません。.
復元処理が行われている間、チームは手持ち無沙汰になり、顧客は待ち続けることになります。さらに、Microsoft 365 のような SaaS プラットフォームの場合、プラットフォーム自体が復旧してオンライン状態に戻るまで復元作業を開始することさえできません。つまり、復旧にかかる時間は完全に Microsoft の裁量に委ねられており、自社でコントロールすることはできないのです。これはバックアップの問題ではなく、アーキテクチャの問題なのです。.
停電時にも業務を継続できる組織は、他とは異なるアプローチをとっています。それらの組織の計画には、災害復旧ではなく、ユーザーが実際に作業できる稼働中の代替環境を用意することが盛り込まれています。.
Microsoft 365 のサービス停止は、決して例外的なケースではない
での 2025年10月, 、Teams、Exchange Online、および Microsoft 365 管理センターがダウンし、数千人のユーザーから影響の報告がありました。 2026年1月には、別のインシデントによりOutlook、Defender、Purviewが利用不能となり、マイクロソフトは北米インフラにおけるトラフィック処理の障害を原因として挙げました。ピーク時には、Downdetectorに1万5,000件の報告が殺到しました。復旧には10時間近くを要しました。.
2件の大規模なサービス停止。12か月。数千人のユーザーが影響を受けた。.
これはマイクロソフトに対する批判ではありません。同社のような大規模な事業を展開している以上、インシデントは起こり得ます。同社のような規模の事業では、インシデントは避けられないものです。しかし、インシデントが発生したからといって、ビジネスが完全に停止してしまうことは避けられるはずです。.
通信の遮断が緊急対応の遅延や重要な業務の停止、あるいはそれ以上の事態を招く組織にとって、事業継続の課題はさらに深刻なものとなります。この点については、本記事で具体的に取り上げています。 バックアップ計画の策定と真の事業継続のギャップ.
Microsoft 365 のライブ・コンティニュイティ・レイヤーを取得する方法
一部の組織は、このリスクに対処するため、マイクロソフトの冗長性をさらに強化したり、2つ目のテナントを運用したり、Azureのフェイルオーバー機能を活用したりしています。このアプローチはインフラの障害からは保護できますが、プラットフォームレベルのインシデントからは保護できません。そして、2025年と2026年に発生したサービス停止は、まさにそのプラットフォームレベルのインシデントだったのです。.
独立したプラットフォーム上で Microsoft 365 のホットバックアップを行うには、現実的な方法が 2 つあります。.
- 1つ目はマイクロソフトです Exchange オンプレミス版. 独立性が高く、実績があり、完全な制御が可能です。また、サーバーのパッチ適用、インフラの管理、そしてあらゆる障害への対応（たとえ午前2時であっても）を、再び自ら行うことになるでしょう。.
- 2つ目は、 独立したSaaSエコシステム, 、この仕組みではプラットフォームが自律的に管理される（そう、それは他人の問題だ）。. Googleワークスペース ここでは、これが最も実用的な選択肢です。このサービスは成熟しており、広く採用されているほか、企業のワークフローと深く統合されています。Microsoft 365との機能の重複も大きく、多くのユーザーは私生活でGmail、Googleカレンダー、Googleドライブをすでに使い慣れています。フェイルオーバーが発生しても、ユーザーはブラウザを開くだけで、すぐに作業を再開できます。.
サービスが復旧すると、ユーザーはそのまま作業を続けられ、Microsoft 365に何を復元すべきかなど考える必要すらありません。データやドキュメントは自動的に復元されるため、ユーザーは通常の環境に戻るだけで済みます。.
手動での操作は不要。生産性の急激な低下も、移行に伴う業務の混乱もありません。ただ、バックグラウンドで静かにその役割を果たす、もうひとつのプラットフォームがあるだけです。.
Microsoft 365 Continuity の総評
コールドバックアップは昨日のデータを保護し、ホットバックアップは今日の業務を保護します。NIS2、DORA、またはNISTのフレームワークに基づいて運営されている組織にとって、この区別はさらに重要となります。事業継続性は、実際の影響を伴うコンプライアンス要件です。.
NIS2 この規制は、不可欠かつ重要な事業体に対し、インシデント発生後の復旧能力だけでなく、インシデント発生中も事業継続を維持することを義務付けています。この規制に違反した場合、組織は最大1,000万ユーロ、または全世界の年間売上高の2%のいずれか高い方の罰金に加え、経営幹部の個人責任も問われることになります。.
DORA 金融機関に対し、ICT障害発生時においても重要な機能を維持する能力を含め、業務上の回復力を実証することを義務付けています。監督当局は、是正命令、公的な戒告、および金銭的制裁を科すことができます。さらに重要な点として、監督当局は、コンプライアンスが実証されるまで、業務を制限または停止させることができます。.
NIST SP 800-34 事業継続を、単なる予備策ではなく、組織の中核的な能力として位置づけています。米国の連邦政府機関およびその委託業者にとって、事業継続要件を満たせない場合、業務実施の認可を取り消される可能性があります。.
各フレームワークは、適用範囲や管轄権において異なります。しかし、そのメッセージは同じです。プラットフォームのインシデントによって業務が中断した場合、バックアップだけでは対策として不十分であるということです。.
Microsoft 365 がダウンし、チームがメールの送受信やファイルへのアクセス、連携ができなくなると、具体的な影響が生じ、規制当局も注視しています。SLA が守られなくなり、顧客からの苦情が相次ぎます。 監査が実施されることになります。病院、金融機関、公益事業、緊急サービスといったリスクの高い環境では、意思決定を行うべき人々が連絡を取り合えないため、意思決定が行えなくなってしまいます。.
持つこと バックアップが必要です. 持っていて コールドバックアップだけでは不十分です 真の事業継続のために。.
Connecting SoftwareのGoogle同期ソリューションを活用して、ホットバックアップを実現する方法をご覧ください
著者について
記入例 アナ・ネト, テクニカルアドバイザー Connecting Softwareにて。
"私は1997年からソフトウェア・エンジニアであり、最近は書くことと人前で話すことが好きです。この記事について質問やコメントはありますか？ご意見・ご感想をお待ちしております！"
