Microsoft 365の大規模障害、原因はAzureメンテナンスのバグによるIPルート消失

2026年7月23日、Microsoftの自動ネットワークメンテナンスシステムのバグにより、北米のエンタープライズユーザー向けにTeamsやSharePointなど十数種類のクラウドサービスが約5時間にわたりダウンした。Microsoftの暫定的な事後レビュー（PIR）によると、この障害は米国西部のAzureデータセンターがグローバルネットワークから切り離されたことで発生したという。

米東部標準時（ET）午前10時44分（日本時間23時44分）に始まり、午後3時41分（同翌4時41分）まで完全には解決されなかったこの障害は、BleepingComputerの報道によると、午前11時11分（同翌0時11分）までにDowndetectorで通常の83倍となる2,403件のユーザー報告を生み出した。またIncidentHubの分析によれば、Azureの米国西部リージョンを経由する少なくとも19の下流SaaSプラットフォームで連鎖的な障害が検出され、Microsoftが完全復旧を宣言した後も、そのうち16のサービスでインシデントが継続していたという。

■日常的なタスクが安全網をすり抜けた経緯

Microsoftの暫定PIRは、障害の発生源を極めて具体的に特定している。同PIRによれば、バグはネットワークハードウェアそのものではなく、人間のメンテナンス要求を機械が読み取れる命令に変換するソフトウェア層にあったという。

障害の連鎖は次のように進行した。エンジニアは、米国西部リージョンの特定のネットワーク経路を分離するという、低リスクに設計された標準的な手順である日常的なメンテナンス要求を発行した。Microsoftのシステムは、その要求をインフラが実行可能な命令に変換し、安全確認を実行する。これは、メンテナンス開始前に2つの冗長経路のうち少なくとも1つが正常に保たれることを検証するものであり、まさに今回のような障害を防ぐために存在していた。

しかし、MicrosoftのPIRで特定されたように、要求の変換システムにはバグが含まれていた。本来触れるべきではないネットワークデバイスまで、誤ってメンテナンス対象としてマークしてしまったのだ。安全確認は、エンジニアの本来の意図ではなく、バグを含んだ変換後の出力を評価したため、エラーを検知できなかった。チェックは通過し、メンテナンスが進行した結果、承認された以上のデバイスからIPルートが削除され、米国西部のデータセンターとMicrosoftの広域ネットワーク（WAN）間の接続が切断された。

WANは、世界中に分散するMicrosoftのデータセンターを接続するプライベートバックボーンである。Azureリージョンに出入りするすべてのユーザートラフィックは、このバックボーンを通過しなければならない。米国西部のデータセンターとバックボーン間のWANリンクが切断されたことで、データセンターは孤島と化した。内部だけで稼働するサービスは正常に機能し続けたが、外部との通信が必要なトラフィックはすべて行き止まりとなった。

MicrosoftのPIRによれば、この障害は当初、エンジニアの目にはWANにおける「大規模なルートのチャーン（経路の頻繁な変動）」として映ったという。これはルーターが経路の削除と再広報を繰り返す現象であり、設定ミスやバグのある自動化システムが変更を繰り返し実行していることを示す症状である。このチャーンを米国西部リージョンの特定のデータセンターまで追跡するのに、3時間以上を要した。

変換層の出力のみを検証し、人間の本来の意図を確認しない安全確認というこの構造的なギャップは、Microsoftが今後発表する最終PIRで対処すべき課題となる。変換を破損させるバグは、正確に実行されつつもスコープが誤った変更を生み出し、すべての安全確認をすり抜けてしまうため、安全網に構造的な死角を残すことになる。

■5時間にわたる連鎖的な障害の全容

影響範囲は広大だった。Microsoftは、インシデントID「MO1437424」の下で、十数種類の製品やサービスにわたる障害を確認した。

Downdetectorの報告の78%を占めたSharePoint Onlineでは、ユーザーがファイルを開いたり共有したりしようとすると「問題が発生しました」という一般的なエラーが返された。Microsoft Teamsのチャットは著しく劣化し、画像が読み込めなくなった。OneDriveへのアクセスは断続的になった。IT管理者が調査や対応を行うために必要なMicrosoft 365管理センターは、読み込みが遅延するか、まったく読み込めなくなった。Power Automateのワークフローは実行に失敗し、Copilot Chatではクエリ全体で遅延や障害が発生した。Microsoft Loopのページも開けなくなった。

MicrosoftのPIRによると、障害はAzureインフラの深部にも及び、Azure App Service、Application Gateway、Azure AI Search、Azure API Management、Azure Cosmos DB、Azure Databricks、Azure Firewall、Azure Kubernetes Service、Azure Monitor、Azure Virtual Desktop、ExpressRoute、Log Analytics、Microsoft Graph、Microsoft Sentinel、Power BI Embedded、Virtual WAN、VPN Gateway全体で接続障害とレイテンシの上昇が広がった。

BleepingComputerの報道によれば、Microsoft Defenderの顧客は該当時間帯にDefender Expertsからの応答受信に遅延が生じ、Threat ExplorerやAdvanced Huntingを通じてトリガーされた一部の脅威調査ワークフローは完全に失敗した。これは、セキュリティ運用チームが最も必要とする時間帯に可視性を失ったことを意味する。

Microsoft自身のPIRから導き出されたエンジニアリング対応のタイムラインは、経験豊富なチームが積極的に取り組んだとしても、未知の障害モードの診断にどれほどの時間を要するかを示している。

米東部標準時（ET）午前10時44分（日本時間23時44分）、デバイスのメンテナンスが開始され、最初の顧客への影響が始まった。午前10時45分（同23時45分）までに、ネットワークおよびインシデント対応エンジニアがトラフィックの異常とパケットロスを調査し始めた。午前11時から正午（同翌0時から1時）にかけて、エンジニアは大規模なWANルートのチャーンを調査しながら、影響範囲と規模を検証した。正午から午後1時45分（同翌1時から2時45分）にかけて、調査は不適切なルート広報に関連する異常なルーティング動作に絞り込まれ、エンジニアはこれを直近のメンテナンス活動と関連付けた。Microsoftは午後1時45分（同翌2時45分）にメンテナンス変更のロールバックを開始し、午後2時26分（同翌3時26分）に完了した。Microsoftの暫定PIRに記録されている通り、影響を受けたすべてのサービスでの完全な復旧が確認されたのは午後3時41分（同翌4時41分）だった。

代替ネットワーク経路へのトラフィックの迂回という初期の試みは部分的な緩和をもたらしたが、影響を受けた大半のユーザーのサービスを復旧させるには不十分だった。障害の最中、Microsoftはエンタープライズ顧客に対し、事業継続およびディザスタリカバリ計画を見直すよう促すアドバイザリを発行した。これは、緩和がすぐには見込めないことをITチームに伝える異例の措置だった。

■Microsoftよりも長く影響を受けた下流サービス

ET午後3時41分（日本時間翌4時41分）にMicrosoftが完全復旧を宣言した時点でも、Azureの米国西部リージョンでインフラを稼働させているSaaSベンダーを利用する組織にとって、障害は終わっていなかった。

数百のクラウドサービスのステータスページを監視するIncidentHubは、Azureのインシデントに関連する影響を認めた少なくとも19の下流サービスで連鎖的な障害を追跡した。IncidentHubの分析によると、Microsoftの復旧発表後も、これら19のサービスのうち16でインシデントが継続していた。下流ベンダーが影響を認識するまでのタイムラグは、Azureでの影響が始まってから数分から3時間以上と様々だった。

具体的な事例は、この連鎖の広がりを示している。Datadogは、Azure Monitor APIの部分的な障害により、Azureのメトリクスが遅延する可能性があると報告した。MongoDB Cloudでは、Azure米国西部でホストされているクラスターで接続障害が発生し、ノードが誤ってオフラインと表示され、クラスターの変更が遅延した。Wizは、米国の複数のデータセンターにわたるポータルとAPIの劣化を報告した。教育機関にサービスを提供するEllucian CloudのStudent Financial Success製品は、Azureが復旧するまでオフラインになった。IncidentHubの記録によれば、MeridianLinkは影響を受けた製品コンポーネントごとに5つの個別のインシデントを開いた。

この復旧の遅れは、大規模なインフラ障害の後に分散システムが再起動する際のパターンに従っている。Azureのネットワークが正常に戻った後も、下流のサービスは復旧を宣言する前に、独自の再接続キュー、滞留したAPI呼び出し、および状態の照合に対処しなければならなかった。

エンタープライズITチームにとって、このタイムラグはSLA（サービス品質保証）のレビューで見落とされがちなリスクを浮き彫りにしている。組織自身のMicrosoft 365サービスは、Exchange Online、SharePoint Online、Teamsなどのコアサービスに対する99.9%の稼働率保証によってカバーされているかもしれない。しかし、これらのサービスと統合されるSaaSツール（ワークフロー自動化プラットフォーム、データコネクタ、セキュリティツールなど）は、独自の依存関係チェーンと復旧タイムラインを持っており、これらの下流のSLAは上流のクラウド障害の影響範囲を考慮していない。

■2026年に記録された信頼性低下のパターン

7月23日の出来事は突如として起きたわけではない。TechTimesが以前報じたように、2026年第1四半期のMicrosoft 365の稼働率はわずか99.526%であり、これはアナリストが2013年に追跡を開始して以来最低の四半期数値であり、単一の四半期でほぼ1年分のSLA予算を使い果たす数字だった。

IncidentHubの創設者であるHrishikesh Barua氏は、7月23日の障害に関する分析の中で、これをより広範なパターンの中に位置づけた。同氏が観察したように、2025年から2026年にかけての自動化および変更管理の障害には共通のテーマがある。それは、安全確認は存在していたものの、ワークフローのどこかにあるバグがそれをすり抜けたということだ。

この特徴づけは的を射ている。2026年2月のCloudflare BYOIP障害では、自動化ソフトウェアが誤って顧客のBGPルートを取り消した。安全メカニズムは設計通りに機能したが、自動化層における自ら引き起こした設定ミスを防ぐことはできなかった。2026年5月のAzure OpenAI障害では、上流のAPI変更における再試行増幅バグが共有ロードバランサーを圧倒した。安全メカニズムは存在したが、内部ワークロードの保護方法の隙間を突いて障害が伝播した。MicrosoftのPIRが確認しているように、7月23日のMicrosoft 365の障害は第3の変種を追加した。それは、安全確認が本来の意図されたスコープを評価する前に、メンテナンス変更のスコープを過大に設定してしまう変換層のバグである。

それぞれの事象は技術的な詳細において異なっている。しかし、これらを合わせると認識可能な一つのクラスを形成する。それは、ハードウェアの故障、外部からの攻撃、あるいは意図的な人為的ミスによってではなく、設計者の意図とは異なる動作をする自動化システムによって引き起こされ、まさにそのようなエラーを捕捉するために構築された安全メカニズムをすり抜けてしまう大規模なインフラ障害である。

■Microsoftの今後の対応と企業ITチームがすべきこと

Microsoftは、メンテナンス要求の実行に使用される安全確認と自動化プロセスに焦点を当てた完全な内部レビューを実施中であることを確認した。また、Microsoftの暫定PIRによれば、その調査を完了した後、最終的な事後レビュー（PIR）を公開する予定であり、通常は事象発生から14日以内であるため、期限は2026年8月上旬ごろと見込まれる。

PIRの中で、Microsoftはレビューが「安全確認、自動化されたメンテナンス要求の変更プロセスなど」に焦点を当てることを明記している。この表現は、前述の構造的なギャップ、すなわち変換層のバグを捕捉できない安全確認の無力さと一致している。同社がこのギャップに対し、変換層の出力とは独立して人間の意図を検証するというアーキテクチャ上の対応をとるのか、それとも追加の承認ゲートを設けるという運用上の対応をとるのかは、今後の注目点である。

7月23日の障害は、エンタープライズITおよびクラウドアーキテクチャのチームに対して3つの具体的なシグナルを提供しており、これらは最終的なPIRの結論に関わらず適用される。

第一に、障害の最中にMicrosoftが出した事業継続計画の見直しを促すアドバイザリは、日常的な文言ではなかった。それは、標準的な初期対応であるトラフィックの迂回では状況を迅速に解決できないというシグナルだった。代替のメッセージングプラットフォーム、帯域外の電子メールシステム、バックアップのファイル共有経路など、フォールバック用の通信チャネルを文書化していた組織は、そうでない組織に比べて混乱が少なかった。

第二に、MicrosoftはPIRの中でマルチリージョン展開戦略を明確に推奨しており、ミッションクリティカルなワークロードについては、単一リージョンに影響を与える事象の発生中も可用性を維持するアーキテクチャを検討すべきだと指摘している。米国東部にアクティブなフェイルオーバーを持つワークロードに影響を与えない米国西部の障害は、単一リージョン展開をダウンさせる障害とは異なるカテゴリーのリスクである。

第三に、Microsoft 365のコアサービスに対する99.9%のSLAは稼働率を約束するものであり、データ保護やビジネスへの影響に応じた補償を約束するものではない。稼働率が99.9%を下回った場合に月額料金の25%を返金するというSLAのクレジット構造は、ほとんどのエンタープライズ展開において、長期にわたる障害の実際のコストのほんの一部しかカバーしない。Microsoftの2026年の信頼性に関する数値を踏まえてリスク受容の姿勢をまだ見直していない組織は、次の事象が起きる前に行うべきである。

■注目ポイントQ&A

●2026年7月23日のMicrosoft 365の障害の原因は何ですか？

Microsoftの自動ネットワークメンテナンス要求変換システムのバグにより、エンジニアが意図したよりも多くのネットワークデバイスが日常的なメンテナンス作業の対象としてマークされたことが原因です。これにより、それらの余分なデバイスからIPルートが削除され、米国西部のAzureデータセンターとMicrosoftの広域ネットワークバックボーン間の接続が切断されました。すべてのユーザートラフィックはリージョンに出入りするためにこのバックボーンを通過する必要があるため、データセンターは約5時間にわたってインターネットから到達不能になりました。

●なぜMicrosoftの安全確認は、障害を引き起こす前にバグを検知できなかったのですか？

Microsoftのメンテナンスプロセスには、メンテナンス開始前に2つの冗長ネットワーク経路のうち少なくとも1つが正常に保たれることを検証する安全確認が含まれています。問題は、このチェックがすでにバグを含んでいた要求変換層の出力を評価したことです。エンジニアの本来の意図ではなく、バグのある命令に対してチェックが実行されたため、有効に見える要求として通過してしまいました。安全網には構造的な死角があり、チェックが実行されるより上流で発生したバグを捕捉できなかったのです。Microsoftが今後発表する最終的な事後レビュー（PIR）で、このギャップに対処することが見込まれています。

●Microsoft 365サービスで障害が発生しているかどうかを確認するにはどうすればよいですか？

最も迅速で信頼できる情報源は、admin.microsoft.comにあるMicrosoft 365サービス正常性ダッシュボードです。エンタープライズ管理者は、Microsoftサービス正常性のアラートをSlack、電子メール、Microsoft Teams（別のチャネル経由）、Webhook、またはPagerDutyにルーティングするように設定することもできます。これにより、Teams自体が利用できない場合でも、運用チームに通知が届きます。二次的なシグナルとして、Downdetectorが独立したユーザー報告の追跡を提供しています。

●この障害を受けて、組織はMicrosoft 365から移行すべきですか？

より有用な問いは、組織のアーキテクチャがMicrosoft 365の常時稼働を前提としているかどうかです。7月23日の事象や、2026年第1四半期の99.526%という稼働率を含む直近3ヶ月の信頼性のパターンは、単一プロバイダーへのクラウド集中が、SLAクレジットでは完全に相殺できない障害リスクを生み出すことを示唆しています。Azure内でのマルチリージョン展開は地域的な障害の影響を軽減し、代替の通信ツールやファイル共有ツールを維持することは、主要プラットフォームがダウンした際のフォールバックを提供します。どちらもMicrosoft 365を放棄することを要求するものではなく、その可用性を保証されたものではなく確率的なものとして扱うことを求めています。

元記事: Microsoft 365 Outage: Azure Maintenance Bug Wiped IP Routes, Taking Down Teams for Hours