2025年の主要なクラウドサービス障害は、事業継続を外部ベンダーに依存するリスクと、準備不足の企業が被る広範な影響をまざまざと見せつけた。

　2025年10月に発生し、数時間に及んだAWSの世界的な障害は、数千の顧客に影響を与えた。同月にはMicrosoft Azureでも障害が発生し、同様の混乱を引き起こした。Microsoft Azureの障害は、サブスクリプション型オフィススイート「Microsoft 365」やAI（人工知能）アシスタント「Microsoft Copilot」を含む複数のMicrosoftサービスで障害が発生した。

　これらの障害は単なる「不便」ではない。ITインフラをクラウドサービスに依存している企業に実質的な損害をもたらすからだ。リスク分析企業CyberCubeによると、2025年10月に発生したAWS障害による暫定的な保険損失額の見積もりは、3800万ドルから5億8100万ドルの範囲に及ぶ。

　クラウドサービス障害によって、顧客向けの製品やサービスが利用できなくなったり、アプリケーションやWebサイトの読み込みが遅延したりすれば、ユーザー体験は著しく損なわれる。企業の評判へのダメージや顧客の不満にもつながりかねない。

　相次ぐ障害事例は、ベンダー起因のトラブルに伴うリスクを強調している。特に、単一のベンダーや特定のリージョン（地域）に過度に依存するシステム構成は、事業に損害を与える恐れがある。予期しない連鎖的な影響によって、障害が復旧した後も問題が尾を引くことがある。例えば、AWSの障害原因がDNS（ドメインネームシステム）の不具合だった場合、認証機能などのDNSを利用する他のサービスにも影響が波及するためだ。

システムが使えれば業務を継続できるわけではない

　企業は「システム可用性」と「業務継続性」を混同しがちだが、両者の間には明確な違いがある。

　システム可用性とは、システムやインフラがオンラインであり、全ての構成要素が期待通りに動作している状態を指す。しかし、システムが利用可能な状態に戻ったからといって、業務機能が完全に復旧したとは限らない。これに対して業務継続性とは、企業が中核となる業務機能を実行し、事業を継続させるために必要なプロセスやオペレーションを遂行できる能力を指す。

　システム可用性はインフラの技術的な状態を評価する指標に過ぎない。必ずしも全ユーザーの業務、ワークフロー、システム間の連携機能が完全に復旧していることを意味しない。そのため、障害の発生中および発生後において、システム可用性と業務継続性のギャップを埋めるBCPを作成することが重要だ。

　コンビニエンスストアチェーンWawaでシニア事業継続アドバイザーを務めるジャスティン・ケイツ氏は、事業継続に必要なこととして、システムがダウンした際に必要となる手動での回避策の計画や、そうした一時的なプロセスを支える人員と設備を確保することを挙げる。

　コンサルティング企業McKinsey & Companyによると、優れたレジリエンス（回復力）を持つ企業は、新型コロナウイルス感染症（COVID-19）のパンデミック（世界的大流行）による混乱にもうまく対処できていた。起こり得るシステム障害に備えるために、企業は技術面と業務運用面の双方から、自社のレジリエンスを測定、追跡する指標を持つべきだ。

　ネットワーク接続サービスを提供するMegaportのCTO（最高技術責任者）であるキャメロン・ダニエル氏は、企業のレジリエンスを測るための重要な指標として以下を挙げる。

• 目標復旧時間（RTO：Recovery Time Objective）
• 目標復旧時点（RPO：Recovery Point Objective）
• 平均復旧時間（MTTR：Mean Time to Recovery）

　「ハイブリッドクラウドの採用が進む現代において、ワークロード（処理）がどれほど迅速に復旧し、どの時点のデータまで戻せるかを知るためには、これらの指標が欠かせない」とダニエル氏は指摘する。

　次回は、回復力を確保するためのインシデント対処計画とアーキテクチャの設計手順を解説する。