Microsoft 365の大規模障害はなぜ一部のサーバー故障から全体に広がるのか｜Outlook・Teamsが止まる連鎖障害の仕組み

2026年11月12日（米国時間）、Microsoft 365でメールサービスのExchange Onlineに接続できない障害が起きました。Outlookだけでなく、Teams、SharePoint Online、Copilotなど複数のサービスが影響を受ける可能性があるとされています。私が気になったのは、「なぜ一部のサーバーの不調が、世界規模の障害に広がるのか」という点でした。

この記事では、ITmediaとPC Watchの報道、Googleの『Site Reliability Engineering』（SRE本）、Microsoftが公開したAzure Front Doorの障害後の報告をもとに、障害が広がる仕組みを整理します。今回の原因はMicrosoftが調査中で、確定した内容は報道の範囲に限られます。2026年11月時点の情報です。

• Microsoftは「多数のサーバーが予期せず応答しなくなり、残りのインフラに負担が集中した」と説明している
• 一部が止まると残りの負荷が増え、それがさらに停止を呼ぶ連鎖障害は、Googleも主要な障害パターンとして整理している
• ヘルスチェックや再試行、設定変更の展開は、使い方によっては被害を広げる側に回る
• 利用者側にできるのは、公式の状況確認と、復旧後の一斉アクセスを避けることくらい

Microsoft 365の障害で公表されていること

米国時間11月12日に起きたこと

ITmediaの記事（2026年11月13日6時41分公開）によると、Exchange Onlineのメールボックスに接続できない障害が発生しました。Outlookのウェブ版、デスクトップアプリ、モバイルアプリのほか、MAPI、ActiveSync、REST経由の接続にも影響が出ています。Microsoftは日本時間13日午前2時54分に公式Xで調査を始めたと発表し、その後、影響はあらゆる地域のユーザーに及ぶ可能性があると説明を改めました。

ステータスページで影響を受ける可能性があるとされたサービスは、Exchange Onlineのほか、Microsoft Teams、SharePoint Online、Microsoft 365 Copilot、Microsoft Defender XDR、Microsoft Planner、Microsoft To Do、Microsoft Purviewです。管理者向けのMicrosoft 365管理センターにもアクセスしにくい状況が生じ、Microsoftは公開ステータスページで確認するよう呼びかけています。

原因について説明された内容

ITmediaによると、Microsoftは当初、複数の地域でインフラの一部に高い負荷がかかっていると説明しました。その後のX投稿で、負荷はトラフィックの増加ではなく、多数のサーバーが予期せず応答しなくなり、残りのインフラに負担が集中したためだと明らかにしています。サーバーは自動ヘルスチェックに失敗して利用できなくなっていたとのことです。

PC Watchは、その後の調査で、サーバー上で暗号化された接続を確立する処理が過負荷になり、リクエストに応答できなくなっていると報じています。Microsoftはこの問題を解消する設定変更を一部のサーバーで検証し、障害の時期と重なる直近のネットワーク設定の変更を元に戻す作業も始めたということです。

まだ分からないこと

最初のきっかけが何だったのかは、確かめた資料には書かれていません。ITmediaによれば、Microsoftは当初「障害と同時期の変更は見つかっていない」としていましたが、再調査で少数の構成変更が確認され、これらが一因になった可能性があるとして調べています。全面復旧の時期も、ITmediaの記事の時点では示されていませんでした。そのため、この記事では「なぜ起きたか」ではなく、「一部の不調が全体に広がる一般的な仕組み」を扱います。

一部のサーバーが止まると、残りのサーバーに何が起きるか

Googleが「連鎖障害」と呼ぶ現象

Googleの『Site Reliability Engineering』第22章は、連鎖障害（cascading failure）を「正のフィードバックによって時間とともに大きくなる障害」と定義しています。システムの一部が故障すると、ほかの部分が故障する確率が上がる、という関係です。例として挙げられているのは、あるサービスの複製（レプリカ）が過負荷で1台落ち、残りのレプリカの負荷が増えて落ちやすくなり、ドミノ倒しのように全部が落ちるケースです。

同じ章は、連鎖障害の最も多い原因は過負荷だと書いています。ここで私は認識を改めました。サーバーは1台落ちても予備が引き継ぐので、冗長化していれば安心だと、どこかで思っていたのです。引き継ぐ側にも限界があるので、引き継いだこと自体が次の故障の原因になりえます。

仮のサーバー台数で計算してみる

仕組みを数字で確かめるために、仮の例を作りました。実際のMicrosoftの設備の数字ではありません。

仮定：サーバー10台、1台あたりの処理能力は毎秒100件、全体の要求は毎秒800件。この場合、1台あたりの負荷は800÷10＝80件で、余力は2割です。1台が止まると800÷9＝約89件、2台が止まると800÷8＝100件で上限ちょうど、3台が止まると800÷7＝約114件になり、処理能力を超えます。

この例では、2台までなら持ちこたえますが、3台目が止まった時点で全体の処理能力（700件）が要求（800件）を下回ります。そこから先は、残った台数が減るほど1台あたりの負荷が増えるので、止まるペースが速まります。余力が2割あっても、止まる台数が一定を超えると一気に崩れる、という形です。

負荷を下げても、すぐには止まらない

SRE本には、もう一つ気になる記述があります。毎秒10,000件で健全だったサービスが、11,000件で連鎖障害を起こした場合、負荷を9,000件に下げても、ほぼ確実にクラッシュは止まらない、というものです。理由は、台数が減った状態で需要を受けることになるからで、健全に動けるサーバーはごく一部になります。再起動したサーバーは、すぐに大量のリクエストを浴びて、ほとんどすぐに落ちてしまいます。

原因を取り除いても復旧に時間がかかる理由が、ここにあります。電力の世界にも似た連鎖があり、電力需給ひっ迫の仕組みの記事では、周波数が大きくずれると発電機が自動で切り離される「脱落」が連鎖し、大規模停電に至る流れを書いています。通信障害でも同じ構造が起きます。たとえば、ドコモの通信障害の原因「輻輳」の記事では、設備が詰まった後の再接続の集中が、復旧を遅らせる流れを整理しています。

📊 読者投票 受付中（現在4票）。あと1票で結果を公開します。

ヘルスチェックが被害を広げることがある

ヘルスチェックの役割

ヘルスチェックは、サーバーが正常に応答できるかを自動で確かめる仕組みです。応答できないサーバーを振り分け先から外したり、再起動したりするために使います。今回のMicrosoftの説明でも、サーバーが自動ヘルスチェックに失敗して利用できなくなった、とされています。

SRE本は、ヘルスチェックを2種類に分けています。「プロセスが応答しているか」を見るものはクラスタのスケジューラ向けで、「いま、この種類のリクエストに応答できるか」を見るものはロードバランサ向けです。この2つを区別しておくことが、問題を避ける助けになるとされています。

ヘルスチェック自体がサービスを不健康にする

SRE本の「Stop Health Check Failures/Deaths」の節には、ヘルスチェックそのものがサービスを不健康にする状況が書かれています。例として、半分のタスクは起動中で何も処理できず、残りの半分は過負荷でヘルスチェックに失敗してもうすぐ止められる、という状況です。このとき、ヘルスチェックを一時的に無効にすると、全タスクが立ち上がるまでシステムが落ち着くことがある、と説明されています。

ここで、今回の報道と照らしてみます。ITmediaによれば、Microsoftは日本時間13日午前6時の投稿で、別の方法でヘルスチェックを行うことを検証し、その結果、影響を受けたサーバーの一部が復旧したと説明しました。この変更はより広い範囲に適用され、応答しなくなったサーバーを継続的に検出して再起動する自動復旧の仕組みも準備中とのことです。私の読みでは、ヘルスチェックの条件の見直しが復旧の手がかりになったように見えますが、Microsoftが原因をそう整理したわけではありません。

再起動も、順序を間違えると負荷を移すだけになる

SRE本は、サーバーを再起動する場合も、連鎖障害の原因を特定してからにすること、再起動が単に負荷を別の場所へ移すだけにならないことを確認すること、そして少しずつ行うことを求めています。急いで全部を再起動するほど、立ち上がったサーバーが一斉に高負荷を受ける危険が増えるためです。

再試行が負荷を増やす

失敗したアクセスをやり直す動き

メールが開けないとき、利用者は更新ボタンを押し、アプリも自動で再接続を試みます。SRE本は、サーバーが応答しても期限に間に合わなかった場合、その作業が無駄になり、クライアントが再試行することで過負荷がさらに悪化すると書いています。

再試行を抑える決まり

SRE本が挙げる対策は、再試行にランダムな指数バックオフ（待ち時間を倍々に延ばす方式）を使うことです。再試行のタイミングがばらけないと、小さな乱れが同じ時刻に集まる再試行の波を生み、自己増幅するとされています。ほかに、1つのリクエストの再試行回数に上限を設けること、サーバー全体の再試行の予算を持つことも書かれています。予算の例は、1つのプロセスが1分間に使える再試行の数を決めておき、超えたら再試行せずに失敗として返す、というものです。

今回の障害の復旧で、利用者の再接続がどの程度影響したかは、確かめた資料に書かれていません。ただ、復旧の通知が出た直後にみんなが一斉に操作し直すのは、サーバーにとって楽ではない動きだと思います。急ぎでないなら少し時間をあけるほうが、少なくとも害はありません。

設定変更が世界中に広がる経路：Azure Front Doorの例

世界規模に広がった設定の不整合

Microsoftは、Azure Front Doorの2025年秋の障害について、Azure Networkingのブログで報告しています。Azure Front Doorは、世界210以上の接続拠点（PoP）を持つ入口のサービスです。CDNと同じように、利用者に近い拠点で応答する構成になっています。今回のMicrosoft 365の障害とは別の出来事で、原因も異なります。

報告によると、後に起きた障害では、2つのコントロールプレーン（設定を作る側）のバージョンにまたがる設定変更の順序によって、不整合なメタデータが作られました。データプレーン（実際に通信を処理する側）の処理が非同期だったため、保護システムのヘルスチェックはすべて通過しました。そのまま段階的な展開で世界中に広がり、「最後に正常だった設定」（LKG）のスナップショットも更新されています。その後、非同期処理の別の欠陥によってクラッシュが起きました。

復旧に約4.5時間かかった理由

報告には、マスタープロセスの復旧で数十万件の設定を最初から読み込み直す必要があり、約4.5時間を要したとあります。段階的に展開していたのに止められなかったのは、検査に通っていたからで、検査をすり抜ける不整合だったからです。

先に起きた障害との違い

同じ報告には、先に起きた障害も書かれています。7日にコントロールプレーンの欠陥で作られた「stuck tenant metadata」を、9日に手作業で削除した際に、設定保護の層を迂回したことが原因です。影響は主にヨーロッパ（約6%）とアフリカ（約16%）で出ました。2回とも、安全装置が働かなかった点が共通しています。

事業者が取る対策と、その限界

劣化させて続ける：負荷を捨てる設計

SRE本は、過負荷を防ぐ策を優先順位の順に並べています。いちばん重要とされているのは、サーバーの処理能力の限界と、過負荷時の壊れ方を試験することです。次に、品質を下げた安価な結果を返すこと、過負荷のときに早く安く失敗させてリクエストを断ることが挙げられています。全部を処理しようとして全部が失敗するより、一部を断って残りを守るほうが、全体の復旧が早いという考え方です。

Microsoftが挙げた再発防止策

Azure Front Doorの報告では、設定生成の安全性の強化、保護システムの回避の禁止、データプレーンの同期処理への変更、展開の段階の追加と待ち時間の延長が完了したとされています。さらに、設定を先に検証する独立した冗長プロセス「Food Taster」を、2026年1月に世界展開する計画も示されました。Food Tasterは、顧客のトラフィックを受けず、設定の解析と検証を同期的に先に済ませてから、有効な設定だけをデータプレーンに渡す役割です。

安全性と速さの交換になる

報告によれば、設定の伝播にかかる時間は、従来は5〜10分程度でしたが、障害後は約45分に延ばしています。変更を慎重に流すほど、安全は上がりますが、緊急の修正は届くまでに時間がかかります。障害の対策には、このような交換が含まれます。報告の日付はあくまで計画上の目標なので、現在の状況は公式の最新情報で確認してください。

障害のときに利用者が気をつけること

まず公式の状況ページを見る

ITmediaによれば、管理センターが使えない管理者には、公開ステータスページでの確認が呼びかけられていました。個人の端末の再設定や再インストールの前に、事業者側の障害かどうかを見ておくと、無駄な作業が減ります。

連絡手段を一つに頼らない

メールとチャットとカレンダーが同じ基盤に載っていると、障害のときに一度に止まります。ITmediaの記事のとおり、今回の影響範囲はExchange OnlineやTeamsなど複数に及ぶ可能性があります。組織なら、緊急連絡用に別の手段を決めておく、という程度のことは、ITに詳しくなくても考えられます。

限界：外から原因は分からない

この記事で整理したのは、一般的な仕組みです。今回の障害がこのどれに当たるのかは、Microsoftの事後報告が出るまで分かりません。SREの考え方を当てはめて「これが原因だ」と言い切るのは、確かめた資料の範囲を超えます。

立場別に見る、判断の整理

メールやTeamsを使う側の判断

使う側が決められるのは、障害のときの動き方です。公式の状況を確認し、復旧の通知が出ても急ぎでなければ少し待ち、重要な連絡には別の手段を用意する。この3つで、できることはほぼ尽きます。

システムを運営する側の判断

運営する側は、SRE本が示す順序が参考になります。まず容量の限界と過負荷時の挙動を試験し、過負荷のときは早く断る仕組みを入れ、再試行にはバックオフと予算を持たせます。さらに、設定変更は検証してから流し、検査を迂回する抜け道を作らない、という方針です。Azure Front Doorの2件が示すように、最後の2つが破られたときに被害が大きくなります。

障害の広がり方についてのよくある誤解

サーバーを増やしておけば、障害は起きないのか

起きます。台数を増やしても、一定数が同時に止まると、残りの負荷が処理能力を超えます。この記事の仮の例では、2台までは耐えられ、3台目で崩れました。余力の大きさと、同時に止まる台数の見込みの両方で決まります。

障害の原因は、攻撃や外部からの大量アクセスなのか

今回については、ITmediaによると、Microsoftは負荷の原因をトラフィックの増加ではなく、多数のサーバーが応答しなくなったことだと説明しています。ただ、攻撃の有無については確かめた資料に書かれていないため、この記事では判断しません。

復旧は、原因を直せば一瞬で終わるのか

終わらないことが多いです。SRE本のとおり、台数が減った状態で需要を受けると、再起動したサーバーがすぐ高負荷で落ちます。Azure Front Doorの報告でも、設定を読み込み直すだけで約4.5時間かかっています。Microsoftが今回、接続数を絞って徐々に戻していると報じられているのも、同じ理由によるものと考えられます（PC Watchの報道に基づく私の推測です）。

まとめ：Microsoft 365の障害から読む、連鎖障害の仕組み

Microsoftは、多数のサーバーが応答しなくなり、残りに負担が集中したと説明しています。この「負担の集中」が次の停止を呼ぶ仕組みは、Googleが連鎖障害として整理しているものと同じ形です。仮の計算でも、余力が2割あって、3台目で崩れました。

ヘルスチェックや再起動、再試行、設定の展開は、どれも障害を防ぐための仕組みですが、使い方次第で被害を広げます。Azure Front Doorの報告では、検査をすり抜けた不整合が世界中に流れ、復旧に約4.5時間かかっていました。

今回の本当の原因は、Microsoftの報告を待つ必要があります。それまでは、公式の状況ページで確認し、復旧後は一斉に操作せず、重要な連絡には別の手段を用意しておく。私が今回の調査から持ち帰れる判断は、この3つでした。続報が出たら、この記事と照らして確かめます。