2026年2月2日19:46 UTC、Microsoftの定期セキュリティ修復ジョブが想定外のストレージアカウントに適用され、Azureの広範なサービスが連鎖的に停止した。VM拡張パッケージの配信基盤が遮断されたことでAKS・Azure DevOps・GitHub Actionsが次々と機能不全に陥り、復旧時のトラフィックスパイクがManaged Identityサービスを圧倒する二次障害へと発展。合計10時間超の影響は、クラウド共有基盤の構造的脆弱性を改めて浮き彫りにした。本稿では障害の技術的メカニズムを時系列で分解し、マルチクラウド設計への実践的教訓を導く。

障害の全体像 ── 10時間超にわたる二段階カスケード

今回のAzure障害は、単一の構成変更から始まった二段階のカスケード障害である。第一波はストレージアクセス遮断に起因するVM管理系サービスの停止、第二波は復旧処理自体がトリガーとなったManaged Identityの過負荷障害であった。

第一波の影響範囲はグローバルに及び、VMのライフサイクル操作（作成・削除・更新・スケーリング・起動・停止）がすべて失敗した。第二波はEast USおよびWest USリージョンに集中し、Managed Identityトークンの取得失敗によりリソース操作全般が不能となった。Microsoftは追跡ID「FNJ8-VQZ」（VM管理障害）および「M5B-9RZ」（Managed Identity障害）としてインシデントを管理している。

注目すべきは、二つの障害が独立した事象ではなく、復旧プロセス自体が新たな障害を生成するという「修復起因カスケード」のパターンを示した点である。これはクラウドインフラの障害対応設計において、復旧時の負荷急増を想定したキャパシティプランニングの重要性を物語っている。

第一波：ストレージ構成変更からVM管理系サービスへの連鎖

障害の起点は、Microsoftが定期実行しているストレージアカウントのアクセス修復ジョブであった。このジョブはセキュリティ強化を目的として匿名・パブリックアクセスを無効化するものだが、2月2日の実行時にデータ同期の不具合が発生し、本来対象外であるべきMicrosoft管理のストレージアカウント群にまでポリシー変更が適用された。

問題のストレージアカウントは、VM拡張パッケージ（VM Extension packages）をホストしている基盤コンポーネントであり、正常動作にパブリック読み取りアクセスが必須であった。パブリックアクセスが遮断されたことで、VM拡張パッケージのダウンロードが全面的に失敗し、以下の連鎖的な障害が発生した。

Phase 1（19:46 UTC〜）：ストレージアカウントへのパブリックアクセス遮断により、VM拡張パッケージのダウンロードが即座に失敗。Phase 2（〜21:30 UTC）：VMのライフサイクル操作（create/delete/update/scale/start/stop）が全面停止。Phase 3（〜00:30 UTC）：VM拡張パッケージに依存する上位サービスが連鎖的に機能不全に陥った。

影響を受けたサービスは広範囲に及ぶ。Azure Kubernetes Service（AKS）ではノードプロビジョニングとExtensionインストールが失敗し、Virtual Machine Scale Sets（VMSS）ではインスタンスのスケーリングと構成変更が不能となった。Azure DevOpsおよびGitHub ActionsではVM拡張パッケージを必要とするパイプラインが停止し、CI/CDワークフロー全体が麻痺した。このほかAzure Arc、Azure Batch、Azure Cache for Redis、Azure Backup、Azure Firewall、Azure Searchなど30以上のサービスが影響を受けた。

第二波：復旧トラフィックスパイクによるManaged Identity過負荷

Microsoftは21:15〜21:18 UTCに問題の修復ジョブを特定・無効化し、一次緩和策を展開した。VM管理系サービスは00:30 UTCまでに概ね回復に向かったが、ここで予期せぬ二次障害が発生した。

一次障害の間にキューイングされた大量のVM操作リクエストと、クライアント側のリトライ処理が一斉に再実行されたことで、Managed Identities for Azure Resourcesサービスに対するトークン取得リクエストが急増した。00:08 UTCに始まったこのトラフィックスパイクは、East USおよびWest USリージョンのManaged Identityサービスを完全に圧倒した。

Microsoftは当初インフラのスケールアップで対処を試みたが、バックログとリトライの規模がスケーリング能力を超えていたため失敗した。最終的にMicrosoftが採用したのは、影響を受けたサービスからトラフィックを完全に除去し、無負荷状態でインフラを修復した後、トラフィックを段階的に再導入するという手法であった。この対処により06:05 UTCに完全復旧が達成された。

この二次障害で影響を受けたサービスは、Azure Synapse Analytics、Azure Databricks、Azure Stream Analytics、Microsoft Copilot Studio、Azure Container Apps、Azure Database for PostgreSQL Flexible Serversなど多岐にわたる。Managed Identityは現代のAzureアーキテクチャにおける認証の根幹であり、その過負荷は認証を必要とするほぼすべてのリソース操作を不能にした。

構造的問題の分析 ── 共有基盤プリミティブという単一障害点

今回の障害は、クラウドプラットフォームにおける「共有基盤プリミティブ」のリスクを鮮明に示した。ストレージアカウントやManaged Identityといったプラットフォーム共有サービスは、設計上の単一障害点（Single Point of Failure）として機能しうる。これらのコンポーネントは多数の上位サービスから暗黙的に依存されており、その障害は指数関数的に影響を拡大させる。

第一の構造的問題は隠れた依存関係の不可視性である。VM拡張パッケージのストレージアカウントは、AKSやDevOpsなど数十のサービスが依存する重要インフラであるにもかかわらず、多くの組織はこの依存関係を十分に把握していない。障害時にどのサービスがどの基盤コンポーネントに依存しているかの「依存関係マップ」が欠如していることが、影響範囲の予測と対処を困難にした。

第二の問題は復旧時の「リトライストーム」に対する耐性設計の不足である。大規模障害からの復旧時には、滞留リクエストの一斉再実行とクライアント側のリトライが重畳し、通常時をはるかに上回るトラフィックスパイクが発生する。今回のManaged Identity障害は、この「復旧スパイク」に対するキャパシティヘッドルームとスロットリング機構が不十分であったことを示している。

第三の問題は構成変更の影響範囲制御の欠陥である。セキュリティ修復ジョブのターゲティングロジックにおけるデータ同期の不具合は、本番環境に対する構成変更のバリデーションとロールバック制御が不十分であったことを意味する。構成変更は段階的デプロイメント（カナリアリリース）とブラストラディウスの制限を伴うべきであるが、今回はグローバルスコープで一括適用されたことで影響が最大化した。

マルチクラウド設計への実践的教訓

Microsoftは再発防止策として、2026年2月中にキャパシティヘッドルームの増強とスケーリングセーフガードの強化を、4月までに修復ジョブのロールバック手順最適化とグレースフルデグラデーション実装を完了すると表明している。しかし、クラウド利用企業にとっての本質的な教訓は、プロバイダー側の改善に依存しない耐障害設計の確立である。

1. 依存関係の可視化と影響分析：自社のワークロードがどのクラウド基盤コンポーネントに依存しているかを網羅的にマッピングする。特にManaged IdentityやDNS、証明書管理、ストレージといった「プラットフォーム共有プリミティブ」への依存は、障害時の影響範囲を大幅に拡大させるため、代替認証経路やフォールバック機構の設計が必要である。

2. マルチリージョン・マルチクラウドの段階的導入：単一リージョン・単一クラウドへの依存は、今回のような広域障害に対して脆弱である。ミッションクリティカルなワークロードについては、少なくともマルチリージョン構成を採用し、可能であればマルチクラウドのアクティブ-パッシブ構成を検討すべきである。ただし、マルチクラウドは運用複雑性とコストを大幅に増加させるため、リスクとのトレードオフを定量的に評価することが重要である。

3. CI/CDパイプラインの疎結合化：Azure DevOpsとGitHub Actionsの同時停止は、多くの開発チームのデプロイメント能力を完全に奪った。CI/CDパイプラインの重要コンポーネントを単一プロバイダーに集中させないアーキテクチャ、あるいは緊急時の手動デプロイメント手順の整備が求められる。

4. リトライ戦略の適正化：クライアント側のリトライロジックに指数バックオフとジッター（ランダム遅延）を実装し、復旧時のリトライストームを軽減する。また、サーキットブレーカーパターンを導入し、下流サービスの障害検知時にリクエストを早期に遮断する設計が有効である。

5. 障害訓練（Chaos Engineering）の実施：依存サービスの障害を意図的にシミュレートし、カスケード障害の発生パターンと影響範囲を事前に把握する。特に復旧フェーズにおけるトラフィックスパイクの挙動を検証し、キャパシティプランニングに反映することが重要である。

FAQ

Azure 2月障害の原因は何だったのか？

定期実行のストレージアカウントセキュリティ修復ジョブが、データ同期の不具合によりVM拡張パッケージをホストするMicrosoft管理ストレージアカウントに誤って適用された。パブリックアクセスが遮断されたことで、VM管理系サービスが連鎖的に停止した。

障害の影響範囲と時間はどれくらいだったのか？

第一波（VM管理障害）は2月2日19:46 UTCから2月3日00:56 UTCまで約5時間10分、グローバル規模で発生した。第二波（Managed Identity障害）は2月3日00:08〜06:05 UTCの約6時間、East USとWest USリージョンで発生し、合計10時間超の影響となった。

なぜ復旧時にManaged Identityの二次障害が起きたのか？

一次障害中に滞留したVM操作リクエストとクライアント側のリトライが一斉に再実行され、Managed Identityサービスへのトークン取得リクエストが急増した。このトラフィックスパイクがサービスのスケーリング能力を超え、二次障害に発展した。

企業がとるべき対策は何か？

依存関係の可視化、マルチリージョン・マルチクラウド構成の検討、CI/CDパイプラインの疎結合化、指数バックオフ付きリトライとサーキットブレーカーの実装、およびChaos Engineeringによる障害訓練が推奨される。

参考文献