Microsoft 365の大規模障害、サーバーが次々と停止した原因とは？復旧作業でも再び応答不能に

米Microsoftのクラウドサービスで2026年11月12日午後（米東部時間、日本時間11月13日未明から朝にかけて）、Microsoft 365の複数サービスに接続できなくなる大規模な障害が発生した。OutlookやMicrosoft Teams、Microsoft 365 Copilotなどの業務アプリケーションで接続不能や機能制限が報告され、企業の業務に影響が広がった。

Microsoftの説明によると、今回の障害はMicrosoft 365のすべての機能が一斉に停止したものではない。認証やメールボックスへの接続に関わる中核インフラで多数のサーバーが予期せず利用不能となり、稼働を続けるサーバーに負荷が集中したことで、一部の機能が正常に動作しなくなった。特にExchange Onlineに依存するTeamsやSharePoint Onlineの機能にも影響が及んでおり、クラウドサービス間の依存関係が障害を拡大させる構造が明らかになった。

Microsoft 365全体が停止したわけではない

障害の発生直後、外部の障害情報サイト「Downdetector」では、OutlookやTeamsに加え、Azure、OneDrive、Microsoft Storeなどでも障害報告が急増した。ただし、Downdetectorの情報は利用者から寄せられた報告に基づくものであり、Microsoftが公式に確認した障害範囲とは必ずしも一致しない。AzureやOneDrive、Microsoft Storeで報告が増えたことだけをもって、それぞれのサービス基盤で障害が発生したと断定することはできない。

Microsoftは公式のサービス正常性ページで、Microsoft 365 BusinessおよびEnterpriseの状態を「サービス低下（Service degradation）」と分類し、複数のサービスへの接続に問題が生じる可能性があると案内した。Microsoft 365管理センターでは、この広域障害をインシデント番号「MO1550821」として追跡している。初期の案内で影響対象として挙げられたのは、Exchange Online、Microsoft Teams、SharePoint Online、Microsoft 365 Copilot、Microsoft Defender XDRの5サービスだ。

サービス	確認された障害・機能制限	継続利用できる主な機能	影響範囲・確認時点
Exchange Online	Outlook on the web、デスクトップ版OutlookのMAPI接続、Exchange ActiveSync、REST接続によるメールボックスへのアクセス障害、メール配送の遅延	主要な接続経路全般に影響する可能性があり、正常動作が保証された経路は示されていない	当初は南北アメリカ、その後全世界に拡大（米東部時間11月12日午後、日本時間13日未明以降）
Microsoft Teams	カレンダー表示、会議スケジュールの作成、情報バリアを使用する組織での新規チャット作成	通常のメッセージ送受信、オンライン会議の開催・参加	全世界（MO1550821の一部）
SharePoint Online	Exchange Onlineに依存する一部の連携機能	SharePoint Onlineに直接保存されたファイルへのアクセス	全世界（MO1550821の一部）
Microsoft 365 Copilot / Defender XDR	サービスへの接続障害、応答不能	詳細は公表されていない	全世界（MO1550821の一部）

障害の影響はサービスによって異なっていた。中でも深刻だったのがExchange Onlineで、Microsoftはインシデント番号「EX1550543」として調査を進めた。Web版Outlookに加え、デスクトップ版Outlookで使われるMAPI接続、モバイル端末向けのExchange ActiveSync、RESTベースのAPI接続など、主要な接続方式でメールボックスにアクセスできなくなる問題が発生した。メールの配送遅延も確認されており、Exchange Onlineの中核機能に広く影響が及んでいた。

一方、Microsoft Teamsでは、通常のメッセージ送受信やオンライン会議の開催・参加といった主要機能はおおむね稼働を維持していた。利用できなくなったのは、Exchange Onlineに依存するカレンダー表示や会議のスケジュール作成などの機能だ。また、組織内の通信を制限する「情報バリア（Information Barriers）」を有効にしている環境では、新しいチャットを作成できない問題も発生した。SharePoint OnlineでもExchange Onlineとの連携機能に影響が出たものの、SharePoint Onlineに直接保存されたファイルへのアクセスは維持されていた。

つまり、Microsoft 365を構成するすべてのサービスが同時に停止したのではなく、Exchange Onlineへの依存関係を通じて、ほかのアプリケーションの一部機能にも障害が波及したと考えられる。ただし、現時点で確認されている情報だけでは、すべての症状が単一の原因によるものだったとは断定できない。企業のIT管理者にとって重要なのは、Microsoft 365全体を利用不能と判断するのではなく、サービスごとに正常な機能と影響を受けた機能を切り分けることだ。

同日午前のTeams障害と午後の広域障害は別のインシデント

11月12日には、今回の広域障害に先立ち、Microsoft Teamsで別の障害が発生していた。このため、同日に相次いだ障害を区別して把握する必要がある。なお、以下の米東部時間は冬時間の米東部標準時（EST、UTC-5）であり、日本標準時（JST、UTC+9）との時差は14時間となる。

最初に発生したのは、Microsoft 365管理センターで「TM1550488」として記録されたTeamsの障害だ。米東部時間11月12日午前9時45分から午前10時53分まで（日本時間11月12日午後11時45分から13日午前0時53分まで） 続き、主に南北アメリカのユーザーに影響した。メッセージの送信遅延や失敗、会話スレッドの新規作成・更新時のエラー、チャット履歴を取得できない問題などが報告された。

Microsoftは、このTeams障害について、内部インフラのリソース競合によってリソース使用率が異常に上昇し、メッセージング要求を正常に処理できなくなったと説明している。同社は米東部時間11月12日午前10時53分（日本時間13日午前0時53分）の時点で、この障害が完全に解消したと発表した。

その後、米東部時間11月12日午前11時17分（日本時間13日午前1時17分） にExchange Onlineのメールボックス接続障害が確認され、Microsoftは「EX1550543」として調査を開始した。当初は南北アメリカのユーザーに限られた問題とみられていたが、その後、影響が拡大した。米東部時間11月12日午後1時26分（日本時間13日午前3時26分）には、複数サービスにまたがる広域障害として「MO1550821」が起票され、Exchange Onlineの接続問題についても、世界中のユーザーが影響を受ける可能性があると案内が更新された。

このように、米東部時間11月12日（日本時間12日深夜から13日未明）には、Teams単独の障害と、その後のExchange Onlineを中心とする広域障害が相次いで発生した。ただし、Microsoftは午前中のTeams障害「TM1550488」と、後に発生した「EX1550543」「MO1550821」の間に因果関係があるとは説明していない。現時点では、同じ日に発生した別個のインシデントとして扱うのが適切だ。

障害の原因はトラフィック増加ではなくサーバー群の停止

障害の調査が進むにつれ、Microsoftによる原因の説明も変化した。当初、同社は複数地域のインフラで負荷が上昇していると報告し、特定のサービスに対するトラフィックが予想外に増加した可能性を調べていた。しかし、その後の調査で、負荷上昇の直接的な原因はトラフィックの急増ではないことが判明した。

Microsoftは公式Xアカウント「@MSFT365Status」を通じ、多数のサーバーが予期せず利用不能になり、残されたインフラに負荷が集中したと説明した。つまり、処理すべき通信量が急増したのではなく、通信を処理できるサーバーの数が減少したため、稼働中のサーバーに過剰な負荷がかかったということだ。同社は、影響を受けたサーバーを安全に復旧させるための作業を進めていると明らかにした。

さらに調査が進むと、サーバーが利用不能になるまでの仕組みも判明してきた。Microsoftの説明によると、安全な通信接続を確立するための中核プロセスが過負荷に陥り、影響を受けたサーバーが自動ヘルスチェックに合格できなくなった。ヘルスチェックは、サーバーが正常に動作しているかを監視し、異常が検出された場合にトラフィックの処理対象から除外する仕組みだ。

今回の障害では、この仕組みによってサーバーが次々と処理対象から外れ、残されたサーバーにさらに負荷が集中した。負荷が増えたサーバーでも同様の問題が発生すれば、処理能力は一段と低下する。こうして、サーバーの異常検出と切り離しが連鎖的な負荷集中につながったとみられる。本来は障害の影響を抑えるためのヘルスチェックが、結果として利用可能なサーバー数の減少に関わった形だ。

Microsoftはこの連鎖を止めるため、世界各地のインフラで新たなソフトウェアのデプロイや構成変更を凍結し、トラフィックを再分散する措置を講じた。特定地域では流入するトラフィックを一部制限し、影響を受けたサーバーの再起動も開始した。さらに、サーバーの状態を適切に判定できるよう、代替となるヘルスチェック方式の検証も進めた。

しかし、サーバーの再起動だけでは問題は解消しなかった。再起動によって一度は復旧したサーバーの一部が、再びトラフィックを受け付け始めると応答不能になる事象が確認されたためだ。これは、サーバーを稼働状態に戻すだけでは十分ではなく、通常の通信量を処理し続けられるかどうかが復旧の条件になることを意味する。トラフィックの再分散や再起動に加え、負荷が集中する原因への対処が必要となった。

その後、Microsoftは障害の発生時期と重なる直近のネットワーク構成変更に着目し、変更前の状態に戻すロールバック作業を開始した。ただし、構成変更の時期が障害発生と一致していたことや、ロールバックが実施されたことだけで、その変更が根本原因だったと断定することはできない。ネットワーク構成がサーバーの過負荷やヘルスチェックの失敗にどのように関係していたのかについては、最終的な調査結果を待つ必要がある。

一部サーバーの復旧を確認、完全復旧の見通しは未公表

米東部時間11月12日午後6時57分（日本時間11月13日午前8時57分） のステータス更新で、Microsoftは影響を受けたサーバーの一部が正常に復帰し、サービスに改善の兆候が見られ始めたと報告した。復旧したサーバーはその時点で安定して稼働しており、代替経路へのトラフィックの切り替えも進んでいるという。また、残るサーバーの復旧手順についても効率化が図られた。

ただし、サーバーが復旧しても、ユーザーが直ちにすべての機能を利用できるとは限らない。Microsoftは、クライアントアプリケーションが再接続を試みる過程で、ユーザーごとに復旧のタイミングが異なる可能性があると説明している。サーバー側の処理能力が回復しても、接続要求が集中すれば、利用者が体感するサービスの改善には時間差が生じ得る。

米東部時間11月12日午後6時57分（日本時間13日午前8時57分）の更新時点では、サービスが完全に復旧する時刻の見通しは示されていなかった。影響を受けたテナントの総数も明らかになっておらず、障害の根本原因をまとめた最終報告書も公表されていない。

今回の障害を受け、企業のIT管理者にはサービスごとの影響範囲を正確に把握することが求められる。Microsoft 365全体が停止したわけではなく、Teamsの通常のメッセージングやオンライン会議、SharePoint Online上のファイルへのアクセスなど、利用可能な機能も残されていた。また、同日午前のTeams障害と午後の広域障害についても、現時点では両者の因果関係が確認されていない。こうした状況を踏まえず、すべての機能が利用不能になったと判断することは適切ではない。

一方、今回の障害は、同じクラウドサービス群の内部にある依存関係が、想定以上に広い範囲へ影響を及ぼす可能性を浮き彫りにした。Exchange Onlineに依存するTeamsやSharePoint Onlineの一部機能が利用できなくなったことに加え、サーバーの自動ヘルスチェックによる切り離しが、残るサーバーへの負荷集中につながった点も重要だ。今後は、再起動したサーバーが通常のトラフィックを処理しながら安定稼働を維持できるか、ネットワーク構成変更のロールバックが復旧にどの程度寄与したかが注目される。

自社への影響を確認する際は、Downdetectorなどの外部サービスだけに頼らず、Microsoft 365管理センターに掲載される「EX1550543」および「MO1550821」のアドバイザリを参照する必要がある。管理センターにアクセスできない場合は、Microsoftの公開ステータスポータルで最新情報を確認し、実際に利用できる機能を個別に検証することが望ましい。

今回の障害がどのような条件で発生し、なぜ多数のサーバーが利用不能になったのかについては、Microsoftによる最終的な根本原因分析が待たれる。特に、ネットワーク構成変更と安全な通信接続を担うプロセスの過負荷、ヘルスチェックによるサーバーの切り離しが、どのようにつながっていたのかが焦点となる。その解明は、Microsoft 365の再発防止策だけでなく、複数のサービスが共通インフラに依存するクラウド環境の信頼性を評価するうえでも重要になる。