2026年11月13日、金曜日の朝に東京でこの記事を書いています。Microsoft 365は、皆さんが出社する前から不安定な状態でした。弊社は「自社で運用するよりMicrosoft 365のほうが良い」とお客様に勧めています。こういう朝は、その一言が言いにくくなります。
何が起きたか
Microsoftは今回の障害を2件のインシデントとして扱っています。1件目はEX1550543で、Exchange Onlineのメールボックスに複数の接続方法で接続できない可能性があるというものです。日本時間の金曜01:17、ニューヨークでは木曜の午前11:17に始まりました。2件目のMO1550821は、複数のMicrosoft 365サービスに接続できない可能性があるという内容で、03:27に始まっています。09:00の時点で、どちらも「サービスの低下」のまま継続中でした。
MO1550821の最新の更新には14のサービスが挙がっています。Exchange Online、Teams、SharePoint Online、Microsoft 365 Copilot、Planner、To Do、Power BI。そしてDefender XDR、Defender for Office 365、Intune、データ損失防止を含むPurviewの複数のサービスです。不安定だったのはメールとチャットだけではありません。攻撃を監視し、デバイスを管理し、データの持ち出しを止めるためのツールも同じ一覧に入っていました。
Microsoftの説明は夜の間に変わっていきました。以下の時刻は日本時間で、ITmedia NEWS、マイナビニュース TECH+、テレビ朝日系ANNの報道と、英語のWebProNews、インシデント記録の公開コピーに基づきます。当初の説明は、インフラの一部で負荷が上昇しているというものでした。04:30までに、負荷の原因はトラフィックの増加ではないと説明が変わります。多数のサーバーが予期せず利用できなくなり、自動のヘルスチェックに失敗し、残ったサーバーでは処理しきれなくなった、という内容です。Microsoftはすべてのデプロイと構成変更を止め、トラフィックを移し、サーバーを再起動し、一部ではヘルスチェックを迂回させました。05:00の少し前には、影響の開始時期と一致する直近の変更は見つかっていないと述べています。しかし06:00までに、少数の構成変更が見つかったとして、障害の一因になった可能性を調べ始めました。07:03には、影響を受けたサーバーで中核のプロセスが過負荷になっていると報告しました。09:00には、復旧したサーバーがトラフィックを受けるとすぐにまた応答しなくなるため、一部を以前のソフトウェア構成で再構築し始めたとしています。
根本原因はまだ確定していません。Microsoftがインシデント後レビューを公開した時点で、この記事を更新します。
インシデントの状況を確認できる場所
上のインシデント番号は、Microsoft 365管理センターのものです。管理センターはadmin.microsoft.comにあるWebの管理画面で、組織の管理者がユーザー、ライセンス、各種設定を管理します。その中の「サービス正常性」ページ（「正常性」メニューの下）に、発生中のインシデントとMicrosoftからの更新が並びます。更新はおおむね1時間ごとです。このページを開けるのは管理者ロールを持つアカウントだけなので、上のインシデント番号のリンクも管理者の方しか開けません。権限の限られた「サービス サポート管理者」や「ヘルプデスク管理者」のロールでも閲覧できます。
スマートフォン版もあります。私が今朝、更新を追っていたのはこちらです。無料のMicrosoft 365 Adminアプリ（iPhone・iPad版、Android版）は、同じサービス正常性の情報を表示し、インシデントの発生や更新をプッシュ通知で知らせます。各インシデントには共有ボタンがあり、管理者が社内に内容を伝えるのに使えます。このアプリにも管理者アカウントが必要です。
管理者ロールのない方は、Microsoftの公開ステータスページstatus.cloud.microsoftと、Xの@MSFT365Statusで大きな障害の情報を確認できます。ITmediaによると、今回は管理センター自体にも接続しにくい状況がありました。この2つは、必要になる前に知っておく価値があります。
Microsoftはもっとうまくやれるはずです
Microsoftほどの開発予算を持ち、数億人が一日中使うサービスを提供している会社です。サーバーの一つの層で起きた障害が、すべての地域で、メール、チャット、ファイル、デバイス管理、セキュリティツールにまで広がるべきではありません。発生から7時間以上たっても原因を探している、という状況も同じです。根本原因が何であれ、一つの障害がどこまで広がるかは設計で決まります。Microsoftにはそれをもっと狭く抑える力があり、顧客にはそう求める権利があります。
今年はこれが初めてでもありません。MicrosoftはMicrosoft 365の全世界の稼働率を四半期ごとに公開しています。Tony Redmond氏は2013年からこの数字を記録しており、2025年までは一度も99.9%を下回りませんでした。2026年第1四半期は99.526%で、同氏の記録では過去最低です。同氏の計算では、3か月で約614分の中断にあたります。第2四半期は99.994%に戻りました。
契約も損失を埋めてはくれません。Microsoftのサービス レベル アグリーメント（SLA）が約束しているのは、サービスごと、暦月ごとに99.9%の稼働率です。30日の月なら約43分にあたります。これを下回った場合のサービス クレジットは、対象サービスの月額料金の25%です。99%未満で50%、95%未満で100%になります。テナントの全ユーザーが5時間メールを使えなかったとしても、稼働率は約99.3%で、25%の区分にとどまります。
細かい条件を読むと、さらに小さくなります。Exchange Onlineのダウンタイムは、メールを送受信できなかったユーザーについて「ユーザー分」で数えるため、社員の半分が使えなかったテナントは半分として計算されます。SLAは「実際にサービスが利用できない状態を伴わない性能低下や遅延」を対象外とし、Microsoftの障害通知は「サービス レベル未達の確認ではない」とも定めています（引用はいずれも英語版SLAの弊社訳）。今回の2件はどちらも「サービスの低下」という扱いです。クレジットは「逸失利益を含む、その他のいかなる損失の補償にもならない」とも書かれています。仮にクレジットが適用されても、Exchange Onlineの月額の4分の1では、失われた午前中の仕事にはとても見合いません。
自社で運用した場合の費用
では、メールを社内運用に戻すべきでしょうか。海外本社からそう聞かれる日本法人の方もいるはずです。今朝、Redditのシステム管理者向けスレッドで、ユーザー2,200人の組織を想定した試算を投稿した人がいました。見積書ではなく、一人の管理者による概算です。Microsoftはオンプレミス版Exchangeの価格表を公開していないため、ライセンスの金額は弊社では検証できません。それでも、全体の構図は参考になります。
| 項目 | 投稿者の試算（米ドル） |
|---|---|
| Exchange Server SEのライセンス、ソフトウェア アシュアランス、Windows Serverライセンス、CAL | 約43万 |
| この規模を処理できるサーバー3台 | 最低50万 |
| 冗長化した第2拠点を含む、立ち上げ時のハードウェア | 約150万 |
| eDiscoveryツールを含む運用費 | 年間約50万 |
| 専任スタッフ2名（諸経費込み） | 年間約30万 |
| 同じ2,200人分のMicrosoft 365 E3（割引後） | 年間約75万 |
下の4行を見てください。自社運用のメールは、初期費用が約150万ドル、運用に年間約80万ドルかかります。E3の年間75万ドルは、1ユーザーあたり月額およそ28ドルです。投稿者が指摘していた落とし穴はここからです。Teams、SharePoint、Officeアプリは引き続き必要なので、E3の支払いはなくなりません。自社運用のExchangeはサブスクリプションの代わりにはならず、その上に積み増す費用になります。
オンプレミスにすればサブスクリプションから離れられる、というわけでもありません。Microsoftが現在サポートしている唯一のバージョンであるExchange Server Subscription Editionは、サーバー ライセンスにもすべてのクライアント アクセス ライセンスにも、有効なソフトウェア アシュアランスまたはサブスクリプションを必要とします。
外資系企業の日本法人によくある数十人から数百人の規模に置き換えると、弊社の見立てでは条件はさらに悪くなります。ライセンス費用は人数に応じて減ります。しかし、第2拠点、24時間体制のパッチ適用、Exchangeを運用できる人材は、人数が少なくても減りません。
報道されない障害
こういう朝の印象には偏りがあります。Microsoft 365が不安定になればニュースになり、すべての顧客が同時に知ることになります。一方、ある会社のメールサーバーがディスク コントローラーの故障や証明書の期限切れで丸一日止まっても、社外の人は誰も知りません。
自社運用では、セキュリティ対応も自社の仕事になります。2021年3月、オンプレミス版Exchange Serverの未知の脆弱性4件が攻撃に悪用されました。自社でサーバーを運用していた組織は、すぐにパッチを適用したうえで、すでに侵入されていないかを調べなければなりませんでした。Exchange Onlineは影響を受けていません。
Redditの投稿者はもう一つ指摘していて、これがいちばん強い論点かもしれません。メールをやり取りする相手のほとんどは、Microsoft 365かGoogle Workspaceを使っています。今朝、自社のメールサーバーが完全に正常だったとしても、送ったメールのかなりの部分は、メールボックスを開けない相手に届いていたことになります。
代わりにやっておくこと
Microsoft 365がときどき使えなくなることを、台風で電車が止まる日と同じように前提にしておく。事前に考えてあれば、数時間の停止は乗り切れます。
- Microsoftに依存しない連絡手段を決めておく。 電話連絡網でも、別のメッセージ サービスのグループでも構いません。必要になる前に用意し、試しておきます。TeamsもOutlookも使えないときにどこを見ればよいか、社員が知っている状態にします。
- サービス正常性を見られる人を2人以上にする。 もう1人に閲覧できる管理者ロールを割り当て、2人ともMicrosoft 365 Adminアプリを入れて通知を有効にします。管理センター自体に接続できない場合は、status.cloud.microsoftを確認します。
- オフラインでも仕事を続けられるようにする。 Outlookのキャッシュ モードとOneDriveの同期フォルダーがあれば、受信済みのメールを読み、手元のファイルの編集を続けられます。
- データの控えを自社で持つ。 別の事業者にMicrosoft 365のバックアップを取っても障害は短くなりません。ただ、メールとファイルの唯一のコピーが、止まっているサービスの中にしかない、という状況は避けられます。
- インシデント後レビューを読む。 これだけ広範囲の障害では、Microsoftは解決から48時間以内に暫定版、5営業日以内に最終版を公開するとしています。サービス正常性の該当インシデントに掲載され、対策が原因に対応しているかどうかを確認できます。
こうした備えは、Microsoftの責任を軽くするものではありません。弊社は今後も、自社運用よりMicrosoft 365を勧めます。自社運用のほうが費用がかかり、障害が表に出にくいからです。同時に、今朝のような事態は起きるべきではないと、Microsoftにもお客様にも言い続けます。
次の障害に向けた日本拠点の備えについては、弊社のMicrosoft 365サービスをご覧いただくか、お問い合わせください。
著者について
Rick Cogley（リック・コグレー）は、東京を拠点とするバイリンガルITマネジメント企業、株式会社イソリアの代表取締役CEOです。1999年以来、イソリアは日本で事業を展開する国際企業にB2B ITサービスを提供し、日本のビジネス文化の複雑さに対応しながら、世界水準の技術サポートを提供しています。