2026年7月23日14:44 UTC（日本時間同日23:44）、Microsoft AzureのWest USリージョンで、リージョンへの出入りトラフィックが遮断される大規模な接続障害が発生した。復旧は19:41 UTC、影響時間は約4時間57分に及んだ。West USリージョン内で完結するワークロードへの影響はなかったが、リージョンをまたぐ通信を伴うサービスは軒並み機能不全に陥った。Microsoftが公開した予備インシデントレビュー（PIR）によれば、原因は定期的なデバイスメンテナンスの要求をシステムが処理する過程に潜んでいたソフトウェアのバグだった。

原因: メンテナンス要求変換ソフトウェアのバグ

Azureのデータセンターでは、特定のネットワーク経路を切り離す必要のあるデバイスメンテナンスを定期的に実施している。本来この処理は、冗長化された2経路のうち少なくとも1経路が正常であることを確認する安全チェックを経て、影響を最小限に抑える設計になっている。

しかし今回、メンテナンス要求をシステムが読み取り可能な指示に変換する過程のバグにより、本来対象ではないはずの追加デバイスまでメンテナンス対象と誤認識された。その結果、データセンターとワイドエリアネットワーク（WAN）を結ぶIPルートが想定より広い範囲で削除され、West USリージョン全体の入出トラフィックが遮断される事態となった。

障害検知後、Microsoftのネットワークチームは14:45から調査を開始し、17:45にメンテナンス変更のロールバックに着手、18:26に完了。全サービスの復旧が確認されたのは19:41だった。

19サービスに連鎖、復旧後も16サービスで障害チケットが残存

影響を受けたサービスはApp Service、Application Gateway、Azure Kubernetes Service（AKS）、Azure Database for PostgreSQL、Azure Cosmos DB、Azure Firewall、ExpressRoute、Microsoft Sentinel、Power BI Embeddedなど多岐にわたり、PIRで名指しされただけでも25以上のサービス・機能に及んだ。IncidentHubの追跡によれば、Azureに依存する外部SaaS側でも連鎖的な障害が観測され、各社のステータスページでの障害認知までに数分から3時間以上のばらつきがあったという。さらに、ネットワーク自体は18:26に復旧したにもかかわらず、16サービスで障害チケットが未解決のまま残ったことも報告されている。ネットワークの物理的な復旧と、その上で動くサービス群の自己回復は別問題であることを示す事例だ。

実務への影響

今回の障害は、West USという特定リージョンの問題にとどまらず、「リージョンをまたぐ通信」に依存するあらゆるサービスに波及した点が実務上の示唆に富む。東日本・西日本リージョンを併用している国内エンタープライズでも、構造的には同じことが起こり得る。

実務上のチェックポイントは次の3点だ。

  • 単一リージョン依存の棚卸し: 本番ワークロードがリージョン内で完結しているか、それとも他リージョンやオンプレミスとの通信（ExpressRoute、VPN Gateway、Peering）を前提にしているかを整理する。後者は今回のような障害の影響を受けやすい。
  • ダウンストリームの自己回復力の検証: ネットワークが復旧してもアプリケーション側が自動で再接続・再同期されるとは限らない。ヘルスチェック間隔やリトライ・バックオフの設定、手動再起動が必要な箇所を事前に洗い出しておく。
  • Azure Service Healthのアラート設定強化: リージョン単位の通知だけでなく、依存しているサービス単位でService Health Alertsを構成し、影響範囲の特定を早める。

筆者の見解

Azureをメイン基盤に据えている身として、こうした障害レポートは他人事ではなく毎回目を通すようにしている。今回気になったのは、原因そのものより「メンテナンス要求を変換するソフトウェアのバグ」という、自動化の境界で事故が起きた点だ。ルート削除の安全チェック自体は正しく設計されていたはずなのに、その手前の変換処理でスコープが誤って広がってしまった。安全側に倒す仕組みを作っても、その仕組みへの入力が壊れていれば意味がない。これは他のクラウド事業者にも、自分たちが社内で自動化を組むときにも当てはまる教訓だ。

Azureのプラットフォームとしての信頼性は、こうした障害が一度起きたからといって揺らぐようなものではないと考えている。ただ、応援する立場だからこそ率直に指摘しておきたいのは、復旧後も16サービスで障害チケットが残ったという事実だ。ネットワークが直ったことと、その上で動くサービス群がきちんと自己回復することは別問題であり、この差を埋める作り込みはまだ伸びしろがある。マルチリージョン構成やゾーン冗長を組んでいれば影響を免れたケースも多いはずで、日本のIT管理者にとっては「Azureが落ちたらどうするか」ではなく「自分たちの構成がどこまで単一リージョン依存になっているか」を点検する機会にしてほしい。地道な信頼の積み重ねを、これからも見ていきたい。

出典: この記事は The July 23 2026 Azure West US Outage: IP Route Removal and Downstream Impact の内容をもとに、筆者の見解を加えて独自に執筆したものです。