Microsoft 365大規模障害の原因とは？Outlook・Teamsへの影響とクラウド冗長化を解説【2026年11月】

2026年11月13日未明、日本を含む世界各地でMicrosoft 365の大規模な接続障害が発生しました。

Microsoft 365は企業や教育機関などで広く利用されているクラウドサービスです。

今回の障害では、Outlookのメールが利用できなくなるだけでなく、Microsoft Teams、SharePoint Online、Microsoft 365 Copilotなどにも影響が広がりました。

Microsoftの発表によると、障害の背景にはネットワーク関連の変更とサーバーの処理能力低下がありました。

しかし、ここで気になるのが次の疑問です。

「クラウドサービスはサーバーを冗長化しているはずなのに、なぜ大規模な障害が発生するのか？」

本記事では、Microsoftの公式障害通知をもとに、影響範囲・原因・復旧状況を整理します。

さらに、エンジニアの視点から、サーバー過負荷、クラウドの冗長化、フェイルオーバー、障害の連鎖を防ぐための設計についても解説します。

※本記事は2026年11月14日朝時点の情報です。復旧状況は随時更新されるため、最新情報はMicrosoftの公式サービス正常性ページをご確認ください。

Microsoft 365で何が起きたのか？

Microsoftは今回の障害について、以下の2つのインシデントIDで情報を公開しています。

障害ID	対象
EX1550543	Exchange Online・Outlook
MO1550821	Microsoft 365の複数サービス

Exchange Onlineでは、日本時間11月13日午前1時17分ごろから障害が記録されています。

また、Microsoft 365全体では同日午前3時26分ごろから複数サービスへの接続障害が記録されました。

影響範囲は当初、米大陸を中心に案内されていましたが、その後、世界各地のユーザーが影響を受ける可能性があると説明されました。

今回の障害は単なるメールサービスの停止ではありません。

Exchange Onlineと連携する複数のMicrosoft 365サービスでも、正常に利用できない機能が発生した点が特徴です。

Outlook・Teamsなどへの影響範囲

Microsoftの障害通知で案内された主な影響を整理すると、以下のとおりです。

サービス	主な影響
Outlook / Exchange Online	メールボックスへの接続失敗、送受信遅延
Microsoft Teams	予定表、会議スケジュールなどの一部機能
SharePoint Online	外部共有やExchange Onlineに依存する機能
Microsoft 365 Copilot	チャット応答や業務データへのアクセス
Microsoft Graph	メール・予定表・連絡先関連APIのタイムアウト
Microsoft Defender XDR	管理画面へのアクセス障害
Microsoft Planner / To Do	タスク関連機能の動作不良

ここで注意したいのが、すべてのサービスが完全に停止したわけではないという点です。

例えば、Microsoft Teamsでは、チャットや既存のオンライン会議など主要な機能の多くは稼働していた一方、Exchange Onlineに依存する予定表関連機能などに影響が出ました。

SharePoint Onlineについても、保存済みファイルへのアクセスは利用可能なケースがありました。

つまり、同じMicrosoft 365のサービスでも、利用する内部機能や依存先によって影響が異なっていたのです。

この点は、後述するマイクロサービスの依存関係や障害の連鎖を考えるうえで重要です。

Microsoft 365障害の原因は？

Microsoftは調査の途中で、サーバーの処理能力が不足している状況を報告しています。

当初は、複数のサーバーが予期せず利用できなくなり、残されたサーバーへ負荷が集中していることが確認されました。

さらに調査を進めた結果、影響を受けたサーバーの中核プロセスが過負荷になり、正常に応答できなくなっていることも報告されました。

その後、Microsoftは、以前のネットワーク容量増強作業に含まれていた技術的な問題が、最近実施したネットワーク変更をきっかけに表面化したと説明しました。

なお、現時点では詳細な根本原因分析レポートは未公表です。

そのため、特定のソフトウェアや機器、設定値が直接の原因だったと断定することはできません。

また、Microsoftは今回の障害について、サイバー攻撃やAIエージェントが原因ではないと説明しています。

なぜサーバーの障害が拡大するのか？

一般的なクラウドシステムでは、負荷分散装置を使って複数のサーバーへリクエストを振り分けます。

例えば、以下のような構成です。

        ユーザー
            |
            v
      Load Balancer
            |
     +------+------+
     |      |      |
     v      v      v
  Server A Server B Server C

通常は3台のサーバーでリクエストを処理します。

しかし、何らかの原因で2台が停止したらどうなるでしょうか。

        ユーザー
            |
            v
      Load Balancer
            |
     +------+------+
     |      |      |
     X      X      v
  Server A Server B Server C
   停止     停止     稼働
                     |
                     v
                  負荷集中

本来3台で処理していたアクセスが、残った1台に集中します。

残りのサーバーに十分な余力がなければ、レスポンスが遅くなり、タイムアウトや追加の障害を引き起こす可能性があります。

さらに、接続を試みるクライアントがリトライを繰り返すと、負荷が増えることも考えられます。

このような現象は、一般的に「障害の連鎖（Cascading Failure）」と呼ばれます。

※上記は仕組みを説明するための簡略化した構成図であり、Microsoft 365の実際の内部構成を示したものではありません。今回の障害でリトライの増加が直接原因になったと確認されたわけでもありません。

Microsoft 365の復旧状況は？

2026年11月14日午前7時ごろ（日本時間）のMicrosoftの障害通知では、影響を受けた環境の回復が継続していると説明されています。

大部分の影響が解消に向かっているものの、以下の対応を継続している状況です。

• 復旧したサーバーの安定性監視
• 影響が残る機能の回復確認
• 滞留したメールの配送処理
• 追加の対処が必要かどうかの調査

Microsoftはメール配送の遅延に対応するため、メールのタイムアウト期間を48時間に延長する措置も実施しました。

ただし、これはすべてのメールが48時間以内に必ず配信されることを保証するものではありません。

なぜ復旧まで時間がかかるのか？

サーバーを再起動しただけで、すべてのサービスがすぐに正常化するとは限りません。

例えば、障害中に大量のメールがキューへ蓄積していた場合、サーバーの接続処理が復旧しても、未処理のメールを配送する作業が残ります。

障害発生
   |
   v
サーバーが応答しない
   |
   v
処理待ちデータが増加
   |
   v
サーバー復旧
   |
   v
処理待ちデータを順次処理
   |
   v
通常状態に回復

これはメールだけでなく、メッセージキューを利用する業務システムにも共通する課題です。

特に重要なのが、復旧直後にすべてのアクセスを戻さないことです。

Microsoftも今回、段階的にトラフィックを再導入しながら、サービスの安定性を確認する対応を実施しています。

クラウドの冗長化とは？

ここからは、今回の障害をきっかけに理解しておきたいクラウド設計について解説します。

冗長化とは、システムを構成するサーバーやネットワークなどを複数用意し、一部が故障してもサービスを継続できるようにする仕組みです。

例えば、Web APIのサーバーを1台で運用している場合、そのサーバーが停止するとAPIが利用できなくなります。

そこで、複数台のサーバーを配置します。

          Client
             |
             v
       Load Balancer
             |
       +-----+-----+
       |           |
       v           v
     API A       API B
       |           |
       +-----+-----+
             |
             v
          Database

API Aが停止しても、API Bが利用可能であれば処理を継続できます。

ただし、この構成にも課題があります。

例えば、Databaseが1台しか存在しない場合、DB障害によってAPI AとAPI Bの両方が影響を受ける可能性があります。

このような箇所を「単一障害点（Single Point of Failure：SPOF）」と呼びます。

冗長化を考える場合、アプリケーションサーバーだけでなく、DB、認証基盤、ネットワーク、外部APIなども含めて検討する必要があります。

フェイルオーバーとは？

フェイルオーバーは、稼働中のシステムに障害が発生した場合、別のシステムへ処理を切り替える仕組みです。

例えば、Active-Standby構成では、通常時はActive側が処理を担当します。

通常時

Client
   |
   v
Active Server     Standby Server
      |                 |
      v                 |
   処理実行         待機状態

Active Serverが停止すると、Standby Serverへ切り替えます。

障害発生

Client
   |
   v
Active Server     Standby Server
     X                 |
                       v
                    処理実行

この切り替えがフェイルオーバーです。

Active-Activeとの違い

冗長化には、Active-Standby以外にActive-Active構成もあります。

構成	特徴
Active-Standby	通常は主系が処理し、障害時に待機系へ切り替える
Active-Active	複数のシステムが通常時から処理を分担する

Active-Activeでは、1台が停止しても残りが処理を継続できます。

しかし、残りのサーバーへアクセスが集中することになります。

そのため、Active-Activeだからといって、必ず障害を防げるわけではありません。

残存サーバーの処理能力、障害検知、負荷分散、データ同期などを考慮する必要があります。

リージョンを分ければ大規模障害は防げる？

クラウドでは、複数のリージョンにシステムを配置するマルチリージョン構成があります。

例えば、東京リージョンと大阪リージョンにWeb APIを配置する構成です。

                User
                 |
                 v
          Global Traffic Router
                 |
        +--------+--------+
        |                 |
        v                 v
  Tokyo Region      Osaka Region
        |                 |
        v                 v
     Web API           Web API
        |                 |
        v                 v
     Database         Database

一方のリージョンで障害が発生した場合、もう一方へトラフィックを切り替えることができます。

ただし、マルチリージョンでも完全な可用性は保証できません。

例えば、両リージョンが同じ認証基盤や共通の設定管理システムへ依存している場合、その共通部分の障害によって両方が影響を受ける可能性があります。

また、次のような課題も存在します。

• リージョン間でのデータ同期
• データの整合性
• フェイルオーバー時の切り替え時間
• 切り替え後の処理能力
• 運用コストの増加

クラウドの可用性を高めるためには、複数の場所へサーバーを配置するだけでなく、共通の依存先や障害時の処理まで設計することが重要です。

エンジニアが学ぶべき5つの障害対策

今回のMicrosoft 365障害を踏まえ、WebアプリケーションやAPI開発でも考慮したい設計を紹介します。

1. タイムアウトを明示的に設定する

外部APIやDBへの接続で応答が返ってこない場合、無制限に待機するとスレッドや接続リソースが不足する可能性があります。

そのため、接続タイムアウトと応答タイムアウトを設定します。

例えば、外部APIを呼び出す場合です。

API Request
     |
     v
External API
     |
     X 応答がない
     |
     v
Timeout
     |
     v
代替処理・エラー応答

タイムアウト値は業務要件や通常時の応答時間に応じて決定する必要があります。

2. リトライは回数を制限する

一時的なネットワーク障害では、リトライが有効なことがあります。

しかし、何度も再試行すると障害中のサービスへさらに負荷をかける可能性があります。

そのため、最大再試行回数を制限し、Exponential BackoffやJitterを組み合わせることが重要です。

1回目：API呼び出し
       |
       X 失敗
       |
       v
  少し待つ
       |
       v
2回目：API呼び出し
       |
       X 失敗
       |
       v
  待機時間を延ばす
       |
       v
3回目：API呼び出し
       |
       X 失敗
       |
       v
  リトライ終了

また、決済や注文登録などの処理は、無条件にリトライすると二重実行につながるため、冪等性の確保が必要です。

Spring Framework 7の@Retryableを使った具体的な実装は、以下の記事でも紹介しています。

Spring Framework 7の@Retryable入門：外部API障害に強いSpring Bootアプリを作る

3. Circuit Breakerで障害の連鎖を防ぐ

Circuit Breakerは、外部サービスへの呼び出しが一定回数失敗した場合、一時的に呼び出しを停止する仕組みです。

通常時：Closed
   |
   | 失敗が増加
   v
障害検知：Open
   |
   | 外部API呼び出しを停止
   v
一定時間後：Half-Open
   |
   | 少数のリクエストで確認
   v
成功ならClosedへ戻る

外部APIが停止しているときに大量のリトライを行うと、障害を悪化させる可能性があります。

Circuit Breakerを利用すれば、障害が発生している外部サービスへのリクエストを抑制できます。

Spring BootではResilience4jなどを利用する方法があります。

4. Bulkheadで障害を隔離する

Bulkheadは、障害が発生している処理の影響を、ほかの機能へ広げないための設計パターンです。

例えば、次のようなWeb APIがあるとします。

        Spring Boot API
               |
       +-------+-------+
       |               |
       v               v
   Payment API      Product API
       |               |
    専用の           専用の
   接続リソース     接続リソース

外部の決済サービスが遅延した場合でも、商品情報APIまで利用できなくなることを防ぐため、処理ごとに接続数や同時実行数を分離します。

この考え方は、マイクロサービスを利用するシステムでも重要です。

5. 障害を前提とした監視と復旧手順を用意する

システム監視では、CPU使用率やメモリ使用率だけでなく、以下の項目も確認することが重要です。

監視項目	目的
APIエラー率	障害の発生検知
レスポンスタイム	性能劣化の検知
リトライ回数	外部依存先の不安定化の検知
接続プール使用率	リソース枯渇の検知
メッセージキュー滞留数	処理遅延の検知
Health Check	サーバーの正常性確認
Failover実行結果	切り替えが正常に動くか検証

加えて、障害が起きたときにどの機能を停止し、どの機能を優先して復旧するかを事前に決めておく必要があります。

復旧目標時間（RTO）や、許容するデータ損失時間（RPO）を整理することも重要です。

Microsoft 365が使えないときの確認・対処方法

利用者がOutlookやTeamsに接続できなくなった場合、まずMicrosoftの公式情報を確認しましょう。

公式サービス正常性ページを確認

Microsoft Service Health Status

また、管理者であればMicrosoft 365管理センターから確認できます。

Microsoft 365管理センター

管理センターでは、以下の順番で操作します。

1. Microsoft 365管理センターへログイン
2. 「正常性」を開く
3. 「サービス正常性」を選択
4. 対象サービスのインシデントを確認する

今回の障害では、EX1550543とMO1550821が関連するインシデントIDです。

利用者側でできること

Microsoft側の障害が原因の場合、アプリケーションを再インストールしたり、パスワードを変更したりしても問題が解消するとは限りません。

組織内で公式の障害情報を共有し、メール以外の連絡手段を確保することが重要です。

また、送信できなかったメールについては、復旧後に送信済みフォルダーや配信状況を確認しましょう。

特に、注文受付、申請、顧客対応など、メールを業務処理の起点としている場合は、二重送信や処理漏れが発生していないか確認する必要があります。

よくある質問

Microsoft 365の障害は復旧しましたか？

2026年11月14日朝時点では、広範囲で回復が確認されていますが、Microsoftは滞留メールの処理とサービスの安定性監視を継続しています。完全復旧の確認には公式サービス正常性ページを参照してください。

Microsoft 365障害の原因はサイバー攻撃ですか？

Microsoftは、今回の障害についてサイバー攻撃やAIエージェントが原因ではないと説明しています。

ネットワーク容量増強作業に関連する技術的問題が、その後のネットワーク変更をきっかけに表面化したと報告されています。

Outlookのメールは消えてしまいますか？

今回の障害では、メール配送の遅延が確認されています。

ただし、配送遅延とメールデータの消失は別の問題です。

Microsoftは滞留メールの処理を継続しているため、復旧後に未着メールやエラー通知の有無を確認することが重要です。

クラウドならサーバー障害は発生しないのでは？

クラウドであっても、サーバーやネットワーク、ソフトウェアの障害は発生します。

冗長化によって故障の影響を抑えることは可能ですが、共通の依存先や処理能力不足などにより、障害が広範囲へ波及する場合があります。

まとめ

2026年11月13日に発生したMicrosoft 365の大規模障害では、OutlookやExchange Onlineを中心に、複数のサービスへ影響が広がりました。

Microsoftの説明では、ネットワーク変更に関連する技術的問題とサーバーの処理能力低下が発生しており、段階的な復旧作業が進められました。

今回の障害から学べるのは、サーバーを冗長化するだけでは、大規模障害を完全に防ぐことはできないという点です。

クラウドを利用したシステムでは、障害発生時の負荷分散、フェイルオーバー、共通依存先の障害対策、リトライ制御、復旧後のデータ処理まで考慮する必要があります。

Web APIを開発するエンジニアにとっても、こうした可用性設計は重要な知識です。

システムが正常に動くことだけでなく、一部が故障したときに、どこまでサービスを継続できるかを考えることが、安定したシステム設計につながるのではないでしょうか。

参考資料

• Microsoft公式：Service Health Status
• Microsoft Learn：Microsoft 365サービス正常性を確認する方法
• Microsoft障害通知の公開記録（ペンシルベニア大学・Microsoft管理センター通知の転載）
• Microsoft Learn：Circuit Breakerパターン
• Microsoft Learn：Bulkheadパターン
• Microsoft Learn：Transient Fault Handling
• ITmedia NEWS：Microsoft 365で大規模障害

※初版公開：2026年11月14日。障害の最終的な原因分析と完全復旧時刻については、Microsoftの続報に基づく更新が必要です。