AWSに続きAzureでも大規模障害。問われるクラウドの安定性

日本時間の10月29日夕方から30日にかけて、米マイクロソフトのクラウドサービスであるMicrosoft Azureで世界規模の障害が発生。これに伴い、業務ソフトMicrosoft 365をはじめとする多数のサービスが影響を受け、世界中の企業活動に支障をきたした。

この障害は、先日世界を震撼させたAWSの大規模障害（詳細はこちら）からわずか1週間前に発生。その影響範囲の広さから、現代社会がいかにクラウド基盤に依存しているか、その現実を改めて突きつける結果となった。

この記事では、今回起きたAzure障害の技術的な背景とタイムライン、そして先週起きたAWSの大規模障害を振り返る。そして、我々がこの経験から何を学び、どう行動すべきかを考える。

障害のタイムラインと技術的背景

マイクロソフトの公式発表によると、障害の根本原因は、同社のグローバルコンテンツ配信ネットワークサービスであるAzure Front DoorにおけるDNS設定の意図しない変更にあった。

この変更がトリガーとなり、Azure Front Doorを経由するサービスへのトラフィックが適切にルーティングされず、世界中のAzureサービスへの接続性が著しく低下した。

障害の経緯は以下の通りだ。

時間（日本時間）	詳細
10月29日夕方	一部のユーザーからAzure portalやMicrosoft 365サービスへの接続問題が報告され始める。
10月29日夜	Microsoftが問題を公式に認識し、調査を開始。Azure Statusページにてインシデント情報を公開。
10月30日 午前8時20分	Microsoftは、大半のサービスが復旧したと発表。根本原因の特定と修正作業が進められた。
10月30日 12時（執筆時点）	公式サイトにて、主要なグローバル障害は「Mitigated（解決済み）」であることが確認できる。 なお、Microsoftは後日、詳細な原因と再発防止策を記載した事後分析レポート（PIR）を公開するとしている。

なお、障害の最新状況や過去のインシデントレポートは、Microsoft公式のAzure Statusページで誰でも確認できる。運用担当者にとって、このページはインシデント発生時の一次情報源として極めて重要だ。

Microsoft 365、Xboxなどに影響

今回の障害は、Azure基盤上で稼働する非常に広範なサービスに影響を与えた。企業活動に不可欠なものから、個人の生活に密着したものまで、その影響範囲は大きい。

影響を受けたサービス種別	サービス名
業務アプリケーション	Microsoft 365 (Teams, Outlook, SharePoint, Exchange Online)
ビジネスプラットフォーム	Dynamics 365, Power Platform
開発・実行環境	Azure App Service, Azure Functions, Azure Kubernetes Service (AKS)
エンターテインメント	Xbox Live

これらのサービスが利用できなくなったことで、世界中の企業で業務が停滞し、コミュニケーションに支障をきたした。

AWSに続いてしまった、大規模障害

今回のAzure障害と、その1週間前に発生したAWSの障害との間に、直接的な技術的関連性はない。AWSの障害は、DynamoDBの内部DNSシステムに起因するもので、発生箇所もメカニズムも異なる。

しかし、世界の二大クラウドプロバイダーが、わずか1週間のうちに相次いで大規模障害を起こしたという事実は、業界に大きな衝撃を与えた。

これは、特定のベンダーの技術的問題というよりも、現代のITインフラが抱える構造的なリスクを示唆しているとは考えられないだろうか。

関連ページ：15時間のAWS大規模障害で、クラウド依存リスクが露呈。得られる教訓とは

英国は、対策計画を策定する方針を発表

相次ぐ大規模障害に対し、各国政府もクラウドサービスを社会インフラとみなし、その安定性確保に向けた動きを始めている。

特に英国政府の動きは迅速だ。2025年10月20日のAWS障害により、歳入関税庁（HMRC）などの政府機関を含む国内サービスが影響を受けたことを受け、障害発生からわずか数日後の10月29日には、将来のクラウド障害に対処するための新たな計画を策定する方針を公式に発表。 

この計画は、科学・イノベーション・技術省（DSIT）が2025年冬に公開を予定している「政府サイバーアクションプラン」に盛り込まれる予定だ。

「国のお墨付き」は万能ではない

相次ぐ障害は、日米政府によるクラウドサービスの認証制度が持つ「保証の範囲」について、我々に再認識を促した。

日本の「ISMAP」や米国の「FedRAMP」は、国が「このクラウドサービスは、私たちの定めた安全基準をクリアしています」とお墨付きを与える制度だ。もちろん、今回障害を起こしたAWSやAzureも、このリストの常連である。

しかし、この制度が保証するのは、あくまでサイバー攻撃などから情報を守る「セキュリティ」であり、サービスが停止しない「可用性」ではない。認証は信頼できるサービスを選ぶ「入口」の基準に過ぎず、その先の運用リスクに対する備えは、すべて利用者自身が担うべき領域である。

今回の障害は、その事実を改めて強く認識させる出来事だったと言えるだろう。

障害を前提とした「レジリエンス経営」へ

「100%安全なクラウドは存在しない」という事実と向き合い、企業が目指すべきは、障害の発生を前提とした上で事業を継続させる「レジリエンス（回復力）」の確保だ。

英国が策定するインシデント対応計画は「事後」の対応力強化であり、日米のISMAPやFedRAMPは「事前」の予防策だ。レジリエンスの強化には、この両輪を回すことが不可欠だ。

まとめ

この機会に、企業は自社のシステム構成を再評価し、単一のプロバイダーやリージョンに依存するリスクを洗い出す必要性を検討すべきではないだろうか。

その上で、必要に応じてマルチクラウド戦略の導入、リージョンをまたいだディザスタリカバリ計画の策定、そして障害発生時の具体的な対応手順を定めたインシデント対応計画の整備と訓練に取り組む必要がある。

クラウドのリスクを主体的に管理・制御する「レジリエンス経営」への転換が、今まさに求められているように感じる。