概要

2026年5月29日、激しい雷雨がアメリカ西部を直撃し、Microsoftのデータセンター複数棟が同時に電力を失った。これによりAzureのWest US 2リージョンで04:24 UTC（日本時間13:24）から障害が始まり、20:18 UTC（翌日05:18 JST）に全サービスが復旧するまで約16時間にわたる大規模な停止が続いた。バックアップ発電機は正常に起動したものの、冷却システムが追いつかず一部エリアで温度が上昇し、復旧作業をさらに困難にした。

影響を受けたサービスはApp Service・Azure Functions・Azure Kubernetes Service・Azure Cosmos DB・Azure SQL Database・Azure Storageをはじめ30サービス以上に達した。なお同日の09:39〜17:05 UTCには、West US 2の停電とは別の要因（リクエスト負荷分散を担うバックエンドのメモリ逼迫）により、複数リージョンにまたがるAzure OpenAI Serviceの障害も発生している。Microsoftは05:00 UTCに雷雨を原因と特定して復旧に着手。10:00 UTC頃から電力の段階的な回復が始まり、18:15 UTCに電力が完全に復旧した後、最終的に20:18 UTCに全サービスが正常化した。Microsoftは72時間以内に予備的なポストインシデントレビュー（PIR）を公開するとしている。

Copilot停止が示したAIサービスのインフラ依存

今回の障害で特に注目されたのは、Microsoft Copilotの全面停止だ。CopilotはAndroidアプリをはじめ複数のMicrosoftプラットフォームで接続エラーやタイムアウトを起こし、コンシューマー・エンタープライズの双方に影響した。Copilotは一見するとMicrosoft 365に組み込まれたソフトウェアのように見えるが、その実体はアイデンティティ管理・オーケストレーション・モデルルーティング・ストレージ・検索・エンタープライズグラフアクセス・テレメトリ・ポリシー適用・リージョナルクラウドキャパシティといった多数のインフラ層に依存している。基盤インフラが揺らぐと、ユーザーにはアプリとして見えていても即座に使用不能になるという構造的な脆弱性が改めて浮き彫りになった。

ITチームへの教訓

この障害を受け、専門家はCopilotをはじめとするAIサービスを組織のインフラの一部として捉え直すよう警告している。具体的には次の4点が挙げられる。

  1. AIをインフラとして扱う — Copilotを"便利なオプション機能"ではなく、生産依存のサービスとして位置づけ、レジリエンス計画・監視・フォールバックワークフローを整備する。
  2. インシデントランブックを事前に用意する — どの業務プロセスがCopilotに依存しているかを明確化し、障害時のコミュニケーションプロトコルと代替手順を定めておく。
  3. リージョン依存性を把握する — 「グローバル」に見えるサービスでも実際はリージョンに紐づいており、Azure Status PageやテナントのService Healthを平時から監視することが重要だ。
  4. グレースフルデグラデーションを設計する — 顧客対応・インシデント処理・コンプライアンス・セキュリティ運用・経営判断など、ビジネスクリティカルな業務では非AI代替フローを温存する。

AIが業務基盤に深く組み込まれるほど、クラウドの可用性は競争力の一部となる。透明性の高いステータス通知、予測可能なフェイルオーバー、わかりやすい管理コントロールを備えたサービス設計が、今後の企業向けAI選定において重要な評価軸になると指摘されている。