2025年10月20日午後4時過ぎ、日本のビジネスシーンに緊張が走りました。

「システムにアクセスできません」「ウェブサイトが表示されません」「決済が完了しません」—日本中、いや世界中で同じような報告が相次ぎました。原因は、米アマゾンのクラウドサービスAWSで発生した大規模システム障害です。

この障害により、任天堂のゲームネットワーク、複数の銀行のオンラインサービス、航空会社のチェックインシステム、さらにはZoomやフォートナイトなど、私たちの生活とビジネスに密接に関わるサービスが影響を受けました。英国では税務当局のウェブサイトまで停止する事態となりました。

この出来事は、現代企業が直面する重要な問いを投げかけています。便利で効率的なクラウドサービスに依存することのリスクを、私たちはどこまで理解しているのでしょうか？

何が起きたのか—障害の時系列

約3時間の障害期間中、世界中の企業と利用者が影響を受けました。AWSは障害の原因について「データベースサービスに関連する問題」と説明していますが、報道時点では詳細な技術的原因は明らかにされていません。

どれだけの影響があったのか

影響を受けた主なサービス（報道による）

今回の障害で影響を受けたのは、私たちの日常生活に密接に関わるサービスばかりでした。

この表からわかるように、影響は特定の業種に限られませんでした。ゲームから金融、行政サービスまで、あらゆる分野がAWSというひとつのインフラに依存している現実が浮き彫りになりました。

なぜ米国東部の障害が世界中に影響したのか

今回の障害は米国東部リージョンで発生しました。しかし、日本を含む世界中でサービス停止が報告されています。なぜでしょうか？

理由は大きく3つあります。

第一に、米国東部リージョンはAWSで最も古く、最も多くのサービスが集中している地域だからです。多くの企業がコスト効率や利便性から、このリージョンにシステムを配置しています。

第二に、グローバル企業の多くが、世界中のユーザーに対して同一のバックエンドシステムを使用しているためです。つまり、日本のユーザーがアクセスするサービスでも、実際のデータ処理は米国のサーバーで行われているケースが多いのです。

第三に、システム間の相互依存関係です。あるサービスがAWSのデータベースを利用し、そのデータベースが別のAWSサービスに依存している、といった連鎖的な依存関係が、障害を広範囲に波及させました。

AWSとは何か—クラウド市場の巨人

世界クラウド市場の約3分の1を占める存在

今回障害を起こしたAWS（Amazon Web Services）は、アマゾン・ドット・コムが提供するクラウドサービスです。業界調査によれば、世界のクラウドインフラ市場で約33%のシェアを持ち、業界の圧倒的トップに君臨しています。

AWSは単なるサーバーレンタルサービスではありません。データストレージ、データベース、AI・機械学習、IoT、セキュリティなど、200以上のサービスを提供する巨大なプラットフォームです。

世界中の数百万のウェブサイトとオンラインサービスがAWS上で動いています。あなたが普段使っているサービスの多くも、知らないうちにAWSを利用している可能性が高いのです。

なぜ企業はAWSを選ぶのか

AWSがこれほど支持される理由は明確です。

• 初期投資が不要：自社でサーバーを購入・設置する必要がなく、すぐに始められる
• 従量課金制：使った分だけ支払うため、無駄がない
• スケーラビリティ：ビジネスの成長に合わせて簡単に拡張できる
• グローバル展開：世界中にデータセンターがあり、どの地域でもサービス提供可能
• 高い信頼性：通常時は99.99%以上の稼働率を誇る
• 最新技術：AI、機械学習など最先端技術がすぐに使える

これらのメリットは、特にスタートアップや中小企業にとって魅力的です。限られた資金とリソースで、大企業と同等のITインフラを利用できるからです。

過去にも起きていた大規模障害

実は、今回の障害は初めてではありません。AWSを含む主要クラウドプロバイダーは、過去にも大規模な障害を経験しています。

2021年12月のAWS障害

記憶に新しいのは、2021年12月に発生したAWSの大規模障害です。この時も米国東部リージョンで障害が発生し、Amazon自社の通販サイトを含む多数のサービスが数時間停止しました。

この障害では、Netflixの一部機能、多数のスマートホームデバイス、配送追跡システムなどが影響を受け、アマゾンの物流センターでは荷物の仕分け作業が手作業に切り替わる事態となりました。

他社クラウドでも発生している

AWS以外の主要クラウドプロバイダーでも、大規模障害は発生しています。

• Microsoft Azure：2025年7月に世界規模での障害発生。多数の企業システムに影響
• Google Cloud：過去数年で複数回の大規模障害を経験
• その他のクラウド：規模の大小を問わず、障害リスクは存在

つまり、「どのクラウドを選んでも、障害のリスクはゼロにはならない」というのが現実なのです。

クラウド依存がもたらすリスクとチャンス

重要なのは、これらのリスクとチャンスを理解した上で、自社のビジネスに最適なバランスを見つけることです。

企業が今後検討すべき対策の方向性

今回の障害を受けて、企業は何を考えるべきでしょうか。ここでは、業界専門家が一般的に推奨する対策の方向性を解説します。

1. 業務継続計画（BCP）の見直し

多くの企業がBCPを持っていますが、その多くは地震や火災など物理的災害を想定したものです。クラウド障害という「見えない災害」を想定したBCPを検討する必要があります。

具体的には以下のような点を含めるべきでしょう：

• クラウド障害時の業務継続手順
• 最低限維持すべき業務の特定
• オフライン代替手段の準備
• 顧客およびステークホルダーへの連絡体制
• 復旧後のデータ整合性確認手順

2. マルチクラウド戦略の検討

「すべての卵を一つのカゴに盛るな」という格言は、クラウド戦略にも当てはまります。複数のクラウドプロバイダーを組み合わせるマルチクラウド戦略が注目されています。

ただし、マルチクラウドにも課題があります。管理の複雑化、コストの増加、技術的な難易度の上昇などです。そのため、段階的なアプローチが現実的でしょう。

例えば：

• 最も重要なデータだけを複数のクラウドにバックアップ
• 新規システムは別のクラウドプロバイダーで構築
• 静的コンテンツと動的システムを異なるプロバイダーに分散
• 地理的に異なるリージョンにシステムを分散配置

3. ハイブリッドクラウドの活用

すべてをクラウドに移行するのではなく、重要なシステムは自社のオンプレミス（自社設置サーバー）に残す選択肢もあります。

これを「ハイブリッドクラウド」と呼びます。クラウドの柔軟性と、オンプレミスの完全なコントロールを組み合わせるアプローチです。

特に以下のような業務は、オンプレミスに残すことを検討する価値があるかもしれません：

• 基幹業務システム（停止すると致命的な影響）
• 機密性の高いデータを扱うシステム
• 規制要件が厳しい業界の重要システム
• レイテンシ（遅延）が許されないリアルタイムシステム

4. SLA（サービスレベル契約）の理解

多くの企業がクラウドサービスを契約する際、SLAの内容を詳しく確認していません。しかし、障害時に何が保証され、何が保証されないのかを理解することは極めて重要です。

【重要】SLAの稼働率保証レベルや返金率はサービスの種類によって異なりますが、一般的なクラウドサービス（AWS EC2など）のSLAに基づいた保証とダウンタイムの目安は以下の通りです。

重要な点は、SLA違反時の補償は通常「利用料金の返金」のみで、実際のビジネス損失は補償されないことです。

例えば、月額10万円のクラウドサービスで障害が発生し、あなたの会社が100万円の売上損失を被っても、補償されるのは最大で10万円（利用料金の100%）のみです。

また、SLAによる返金を受けるには、通常、利用者側から申請が必要であり、自動的に返金されるわけではありません。各クラウドサービスの具体的なSLA内容については、必ず公式サイトで最新情報を確認してください。

5. 監視と早期検知の体制構築

障害が発生したとき、それをいち早く検知し対応を開始することが被害を最小化します。

検討すべき監視項目：

• システムの応答時間の監視
• エラー率の監視
• クラウドプロバイダーのステータスページの自動チェック
• 重要な業務プロセスの死活監視
• 異常検知時の自動アラート設定

6. 定期的な障害訓練の実施

火災訓練と同様に、システム障害を想定した訓練を定期的に実施することが推奨されます。

訓練で確認すべき項目：

• 障害発生を検知してから対応開始までの時間
• 代替手段での業務継続の実現可能性
• 従業員の対応手順の理解度
• 顧客への連絡体制の有効性
• データバックアップからの復元能力

中小企業とスタートアップが考えるべきこと

大企業は潤沢な資金と専門チームを持っていますが、中小企業やスタートアップはそうはいきません。限られたリソースで、どのように対策すべきでしょうか？

「守るべきライン」を明確にする

すべてを完璧に守ろうとすると、コストが膨大になります。最も重要な業務だけを特定し、そこにリソースを集中させることが現実的です。

以下の質問に答えてみてください：

• 1時間停止したら致命的な業務は何か？
• 3時間停止しても許容できる業務は何か？
• 1日停止しても大きな問題にならない業務は何か？

この優先順位付けに基づいて、対策の予算配分を決定します。

低コストで始められる対策

予算が限られていても、できることはあります。

コストがほぼゼロの対策：

• 重要な連絡先を印刷して保管
• システム障害時の対応手順書を作成
• 従業員への定期的な注意喚起
• クラウドプロバイダーのステータスページをブックマーク
• 顧客への告知文テンプレートを事前準備

月額数千円から数万円の対策：

• 重要データの別クラウドへのバックアップ（月額5,000円から）
• システム監視ツールの導入（月額10,000円から）
• ドメインとメールサービスの分散（月額3,000円から）

スタートアップ特有の考慮点

スタートアップは、成長速度が速く、システム要件も頻繁に変わります。そのため、柔軟性を保ちながらリスクを管理する必要があります。

スタートアップが優先すべきこと：

• 最初から複数リージョンにシステムを分散配置
• マイクロサービスアーキテクチャの採用（障害の影響範囲を限定）
• 自動フェイルオーバー機能の早期実装
• インフラをコード化（Infrastructure as Code）して移行を容易に

初期段階から「移行可能な設計」にしておくことで、将来的に別のクラウドへの移行や、マルチクラウド化が容易になります。

これからのクラウド戦略—バランスの時代へ

今回のAWS障害は、私たちに重要な問いを突きつけました。便利さと依存のリスク、どうバランスを取るべきか？

「クラウドファースト」から「クラウドスマート」へ

2010年代、多くの企業が「クラウドファースト」—可能な限りすべてをクラウドに移行する—という方針を採用しました。その流れは今も続いています。

しかし、今回のような障害を経験すると、新しい考え方が注目されます。それが「クラウドスマート」です。

クラウドスマートとは：

• すべてをクラウドに移行するのではなく、適材適所で判断
• クラウドのメリットを享受しながら、リスクを管理
• 複数の選択肢を保持し、柔軟性を維持
• コストだけでなく、リスクも含めた総合的な判断

レジリエンス（回復力）の重要性

現代のITシステムで重要なのは、「障害を起こさないこと」ではなく、「障害が起きても素早く回復すること」です。

これを「レジリエンス（回復力）」と呼びます。レジリエンスの高いシステムとは：

• 障害を早期に検知できる
• 影響範囲を最小限に抑えられる
• 代替手段で業務を継続できる
• 短時間で通常状態に復帰できる
• 障害から学び、システムを改善できる

完璧なシステムは存在しません。しかし、回復力の高いシステムなら、障害があっても致命傷を避けられます。

透明性とコミュニケーション

障害が発生したとき、最も重要なのは顧客やステークホルダーへの迅速で正直なコミュニケーションです。

今回の障害でも、任天堂は速やかに障害を公表し、「AWSの障害の影響を受けた」と明確に説明しました。この透明性が、顧客の信頼を維持する鍵となります。

障害時のコミュニケーションで重要な点：

• 障害を隠さず、速やかに公表する
• 影響範囲を具体的に説明する
• 復旧見込み時刻を（わかる範囲で）伝える
• 顧客が取るべき行動を明示する
• 復旧後に経緯を報告する

政府・行政が果たすべき役割

今回の障害では、英国の税務当局のウェブサイトも影響を受けました。これは、公共サービスのクラウド依存にも同様のリスクがあることを示しています。

重要インフラとしてのクラウド

現代社会において、クラウドサービスは電気や水道と同じく「重要インフラ」となりつつあります。それが止まれば、社会全体に大きな影響が及びます。

各国政府は以下のような対策を検討する必要があるでしょう：

• クラウドプロバイダーへの規制とガイドライン策定
• 公共サービスのクラウド利用に関する基準設定
• 重要インフラのバックアップ体制義務化
• 障害時の情報開示要件の明確化
• 国内データセンターの整備支援

デジタル主権の議論

今回の障害は、「デジタル主権」についての議論も呼び起こします。自国の重要なデータやシステムを、海外の企業に依存することのリスクをどう考えるか、という問題です。

欧州では既に、データの保存場所や管理体制について厳格な規制を設けています。日本でも、今後このような議論が活発化する可能性があります。

技術者の視点—システム設計の考え方の変化

今回の障害は、システムエンジニアやアーキテクトにとっても重要な教訓となります。

単一障害点の排除

システム設計の基本原則の一つが、SPOF（Single Point of Failure：単一障害点）の排除です。

一つのコンポーネントが停止しただけでシステム全体が止まる設計は避けるべきです。今回の障害で影響を最小限に抑えられたサービスは、この原則を守っていた可能性が高いと考えられます。

具体的な設計パターン：

• 冗長化：重要なコンポーネントを複数配置
• 負荷分散：複数のサーバーにトラフィックを分散
• フェイルオーバー：障害時に自動的に代替システムに切り替え
• サーキットブレーカー：障害の連鎖を防ぐ遮断機構
• グレースフル・デグラデーション：一部機能停止でも主要機能は継続

可観測性（Observability）の重要性

システムの内部状態を外部から把握できる「可観測性」が、近年重視されています。

障害が発生したとき、何が起きているのかを素早く理解できなければ、対応も遅れます。ログ、メトリクス、トレースを適切に収集・分析する仕組みが不可欠です。

カオスエンジニアリングの実践

Netflix社が始めた「カオスエンジニアリング」という手法があります。これは、意図的にシステムに障害を起こして、その回復力をテストするというものです。

本番環境で実際に障害を起こすことで、想定外の問題を事前に発見し、真のレジリエンスを確保します。大胆な手法ですが、今後より多くの企業が採用していく可能性があります。