Microsoftは2026年11月14日、Microsoft 365の世界規模の障害について、影響が残っていた顧客と地域へのサービス復旧を完了したと発表した。13日には広い範囲で回復が進んだものの、一部では復旧作業が続いていた。今回の発表は、その段階から復旧完了への変化を告げるものだ。
国内では、東海国立大学機構が同じ障害の復旧時刻を日本時間14日午後1時10分と記録している。接続が戻ること、配送待ちのメールを処理すること、残る顧客と地域のサービスを復旧することは、Microsoftの更新では別々の段階だった。復旧完了までに何が起き、原因について何が残されているのか。
全面復旧の発表と33時間44分の記録
Microsoft 365 Statusは14日の公式投稿で、「影響が残っていた顧客と地域へのサービスを復旧した」と発表した。詳細な更新先として、Microsoft 365管理センターの障害番号MO1550821を案内している。13日の広範な回復に続き、残る顧客と地域についても復旧完了を知らせたものだ。
東海国立大学機構が掲示したMO1550821の障害期間は、11月13日午前3時26分から14日午後1時10分までの33時間44分だった。機構の記録は日本時間で、開始から翌日同時刻までが24時間、そこから午後1時10分までが9時間44分となる。この数字は機構が掲示した障害期間であり、世界各地の利用者が一律に連続して使えなかった時間を表すものではない。
同機構は影響を受けたサービスとしてExchange Online、Microsoft 365 suite、Microsoft Copilotのほか、Microsoft Defender XDR、Teams、SharePoint Onlineを挙げた。機構内ではメールを送受信できず、Outlookを起動できない状態を確認している。TeamsとSharePointについては一部機能が使えなくなったという。
XenoSpectrumの14日朝の報道では、障害が続く中での復旧作業と国内への影響を伝えた。その後、Microsoftは残っていた顧客・地域の復旧を発表し、機構側の記録にも終了時刻が入った。
過去の容量増強の問題が、後の変更で表面化
ウィスコンシン大学ミルウォーキー校（UWM）が公開した障害履歴には、Microsoftの更新が転載されている。その中で同社は米中部標準時13日午前11時57分、過去のネットワーク容量増強で生じた問題が、その後のネットワーク変更を受けて表面化したと説明した。当時は原因に対処し、影響が残る顧客と地域の復旧を進めている段階だ。
Microsoftのそれ以前の更新によると、安全な接続を確立するサーバーのプロセスが過負荷になり、要求を処理できなくなっていたという。同社は一部サーバーで設定変更を検証し、再起動と並行して展開を準備したほか、最近のネットワーク構成変更を戻す作業にも着手した。
しかし、サーバーをいったん戻せば、それで安定する状況ではなかった。同社は、復帰直後に正常だったサーバーも、トラフィックを受けると再び応答しなくなる場合があると説明している。そこでトラフィックの種類を制限し、一部サーバーを以前のソフトウェア構成で再構築する対策を取った。13日午前0時56分（米中部標準時）の更新では、仮想マシンの増強も実施したと報告している。
復旧には処理能力を戻すだけでなく、戻した環境が実際の需要を受けても安定するかを確かめる作業が伴った。Microsoftは需要の規模を踏まえ、各段階で安定性を検証しながら復旧したため、時間を要したと説明する。
接続回復とメール配送には時間差があった
メールの送受信要求を受け付けられるようになっても、障害中に配送待ちとなったメールの処理は残る。接続の回復とメールフローの正常化が同時とは限らないことを、東海国立大学機構が転載したMicrosoftの日本時間14日午前5時1分の更新も説明していた。
同じ掲示によると、日本時間午前11時17分の更新では、サービスの低下と蓄積したメールの処理を引き続き追跡していた。日本時間午後1時17分の更新では、サービスを復元済みと説明している。機構が自ら記録した午後1時10分の復旧時刻と、Microsoftの更新時刻はそれぞれ別の記録だ。
UWMの障害履歴に転載された13日午前6時（米中部標準時）の更新では、欧州で可用性と配送性能が改善し、日本は比較的安定、北米も改善していると評価した。この時点でMicrosoftは配送待ちメールを減らすことを優先し、遅延したメッセージを保護するため、タイムアウトを48時間に延長する措置を維持していた。48時間は遅延メールの保護を目的とする待機期間である。
同日午前8時1分（米中部標準時）の更新では、配送待ちは通常水準に近づいた一方、一部では断続的な障害やメールの遅延が残る可能性があるとした。地域ごとの回復、配送待ちの解消、個々の利用者の状態は同じ速度では進まない。14日の最終発表は、残る顧客と地域へのサービス復旧という段階に到達したことを示している。
次の焦点は、変更管理と再発防止の説明
MicrosoftはUWMが転載した13日午前11時57分（米中部標準時）の説明で、今回を技術的な問題とし、サイバー攻撃やAI、エージェントとの関係を否定した。同社は調査を終えた後、根本原因と多層的な防御の改善を含む事後報告書を提供する方針を示している。
現時点の説明では、過去の容量増強時にどんな不具合が生じ、後のネットワーク変更によってそれが表面化し、安全な接続を担うプロセスの過負荷にどうつながったかという具体的な経路は明らかになっていない。
復旧中には、再起動で応答を取り戻したサーバーがトラフィックを受けて再び応答しなくなる場合もあった。事後報告では、変更を適用する際にどの段階で異常を捉えられるのかに加え、復旧時にトラフィックを戻しても安定性を保てるかをどう検証するのかが判断材料になる。障害の影響を抑えながらサービスを戻すには、両方の段階で有効な対策が必要だ。