こんにちは。弁護士の浅見隆行です。
2025年10月20日午後4時ごろ（日本時間）に、Amazon Web Services（AWS）の米国東部1リージョン（バージニア州北部、US-EAST-1）で大規模な通信障害が発生しました。
AWSの障害発生による障害の連鎖
この大規模障害によって、AWSを利用しているNintendo Switch 2,Nintendo Switchなどのネットワークサービス全般、Amazon Prime Video などの一般消費者向けサービスのほか、Zoom、Slack、Boxなどの業務に不可欠なサービスにも障害が連鎖しました。
その結果、これらのオンラインサービスやクラウドサービスに依存していたユーザー企業（クラウドユーザー企業）でも、「Zoomを利用した商談ができなくなった」「Boxで共有している業務に必要なデータファイルが閲覧できない」などの支障も生じています。
オンラインサービスやクラウドサービスが全盛期の今日において、AWSのような巨大なクラウドインフラに極度に依存している「集中リスク」が顕在化したとも言えます。
過去にはMicrosoftやGoogleでも障害の発生
これは決してAWSだけの問題ではありません。
2025年9月には紅海の海底ケーブルの切断により Microsoft Azure のネットワークが遅延する問題が発生し、2025年6月13日にはGoogle Cloud の障害により、Google Cloud を利用しているSpotifyなどのサービスにも障害が連鎖しました。
2024年8月には、Microsoft365がDDoS攻撃によりサービスが一時停止したことがあります。
AWS以外のMicrosoftを利用していようが、GoogleCloudを利用していようが、同じ問題が発生する可能性があるということです。
クラウドユーザー企業が講じるべきBCP対策
ユーザー企業は、「クラウドサービスの停止は必ず起きる」という前提で、事業を継続するための仕組み（BCP）を構築することが必要です。
取締役／取締役会は、「情報の保存管理体制」の構築、「損失の危機管理」を整備することは、内部統制構築義務の中に含まれていると考えて行動すべきです。
危機意識は持ち続ける
クラウドサービスを利用している多くの企業は、自社でサーバーを保有・運用する「オンプレミス」よりも、クラウドのほうが事業継続や情報保存・管理の観点から安全であるという考えによるところが少ないでしょう。
当事務所も同じです。
また、コスト面でも、自社システムを立ち上げるよりは、クラウドの方が安く抑えられるメリットもあります。
しかし、利点に重きを置いてクラウドサービスを利用するにしても、「クラウドに預けておけば安心」と慢心することは避ける必要です。
AWS、Azure、GoogleCloudにすら障害が起きているのですから、「サーバーやクラウドサービスに障害が起きるかもしれない」との危機意識は持ち続けることが必要です。
障害を前提とした計画
BCP策定の第一歩は、何を最優先に守るかを決めることです。
その上で、障害が発生したときを想定して、事業の継続に不可欠な業務を特定し、中断が許されない業務を洗い出します。
クラウドユーザー企業の立場では、クラウドサービスの復旧は待つしかありません。
それでも事業の継続を止めるわけにはいきません。
そこで、クラウドが復旧されるのを待っている間でも「これさえあれば最低限の事業を継続できる」を見越して、何が必要なのかを想定・計画しておくのです。
クラウドの障害どころか、ネットワークが遮断されている場合に、どう対応したらいいかを想定したらよいかもしれません。
顧客対応、受発注、入金確認など、重要業務については紙ベースでの対応マニュアルや、他の代替システムへの手動切り替え手順を事前に整備しておくのです。
オンラインサービスのリスク分散
特定のクラウドベンダーへの依存度を下げるため、異なるクラウドベンダーのサービスを組み合わせて利用する（マルチクラウド戦略）ことも有効です。
これにより、一つのクラウドがダウンしても、他方のクラウドへ切り替えて運用を継続できる可能性が高まります。
とはいえ、同じ業務のために複数のクラウドサービスと契約することはコストが重複するだけで無駄です。
そのため、すべてを同じ会社のクラウドサービスに依存しないで、例えば、officeはMicrosoft365、メールはGoogleWorkspace、Web会議はZoomなどに分散し、Microsoft365に障害が起きたらGoogleWorkspaceのツールを使って業務を行う、Zoomに障害が起きたらGooglemeetでWeb会議を行うなど、代替できるようにクラウドを選ぶというイメージです。
データの保護と復旧計画の実効性確保
クラウドサービスが停止したことを想定して、データをクラウド上に定期的にバックアップする環境を整備し、重要なデータを一箇所ではなく複数の場所やクラウド上に保存（オフサイト保管）します。
2025年9月26日には韓国政府が管理するデータセンターで火災が発生し、過去8年分の業務資料858テラバイト（TB）が消滅しましたが、こうした場合でも、データのバックアップされていれば、早期に復旧できたかもしれません。
先日のアサヒGHDのケースに限らず、最近増加しているランサムウェア攻撃などによるデータ改ざんリスクに備えて、書き込み後にデータを変更できない「イミュータブルストレージ」を利用し、信頼性の高いバックアップを実現することも、事業継続性の観点からは有効です。
政府、金融機関、医療機関などでは利用されているようです。
お客さまへの情報発信
障害発生時の混乱を防ぎ、迅速に対処するための体制を平時から構築しておくことも不可欠です。
中でも意識すべきなのは、迅速な情報共有と危機管理広報の実践です。
障害が発生した際は、社内と外部への迅速かつ的確な情報共有が求められます。
例えば、任天堂は障害発生の直後にXのサポートアカウントにて情報を発信し、その後もXと公式サイトの両方で障害の進捗状況を発表し続けていました。
こうしてお客様向けの情報発信を迅速に行い、かつ、それを継続することは、「どうなってんだ」と不安に陥ったり消費者を安心させ、苛立っている消費者をなだめることにもなるので、お客さまからの信頼を向上させることににつながります。
