雲が落ちる日：Microsoft 365 の障害と、企業が持ち帰るべきこと

11月12日18時17分（キーウ時間）、Microsoft 365 で障害が始まりました。本稿公開の時点でも続いています。メールボックス、カレンダー、Teams、SharePoint が開かなくなりました。影響は世界中の企業に及び、ウクライナの企業も含まれます。この国では法人メールの大半が Microsoft 365 で動いているからです。

私たち自身のメールボックスでも起き、何が壊れたのかを確かめました。以下は、自分たちで検証した事実、Microsoft の公式見解、そして何より、Microsoft を使っているかどうかにかかわらず経営者が持ち帰るべきことです。

具体的に何が動かないのか

「メールが開かない」への最初の反応はいつも同じです。悪いのは自分たち、パスワード、回線、ドメイン設定だろう、と。ですから私たちはまず自分側の点検から始め、そこではっきりした像が得られました。

• アカウントへのサインインは成功する。 Microsoft は利用者を認識し、アクセスを許可します。つまりパスワードも権限もアクセス設定も関係ありません。
• メールの取得はサーバーエラーを返す ——コード 502。「アクセス権がない」でも「パスワードが違う」でもなく、「サーバーが応答できなかった」です。
• カレンダーも同じように落ちる ——コード 503。つまりメール単体の問題ではなく、Exchange Online にあるすべての問題です。
• ドメインのメールレコード（MX）は変更されていない 。依然として Microsoft を指しています。メールは本来行くべき先へ送られています。

結論は単純です。こちら側は無事で、応答していないのはサービスそのもの。疑わしいと思う方はこの同じ点検をすべきです。数分で済み、疑問の半分が消えます。

公式の経過

Microsoft はこの障害を二つの番号で扱っています。 EX1550543 は Exchange Online メールボックスへのアクセス、 MO1550821 は Exchange に依存するすべて。Teams の別件（TM1550488）はすでに終了しています。当初はアメリカの話とされ、のちに「どの地域の利用者にも影響しうる」と表現が改められました。

以下の時刻はキーウ時間です。

• 11月12日 18:17。 利用者がメールボックスを開けない。Microsoft はメールアクセスの問題を調査中と告知。
• 20:19。 複数の地域で同時に負荷の上昇を確認。
• 21:18。 補足。負荷が増えたのは 通信量の流入によるものではない 。一部のサーバーが突如として利用できなくなり、その分の処理を残りが引き受けた。
• 21:43。 影響を受けたサーバーが自動の正常性チェックを通らず、システム自身がそれらを切り離していることが判明。
• 21:57。 「障害の開始に関連する最近の変更は確認されていません。」
• 11月13日 00:00。 「影響を受けたサーバー上の主要プロセスが過負荷となり、処理能力が失われています。」
• 深夜。 補足。過負荷になっているのは、安全な接続の確立を担うプロセスそのもの。並行して Microsoft は、障害の開始と時間的に一致する 最近のネットワーク構成変更の巻き戻しに着手します。
• 06:11。 「確認します。悪意ある行為の結果である兆候は一切ありません。」
• 13:04。 アジア太平洋地域で復旧が完了。通信を段階的に通し、作業を他地域へ広げている。

原因：いまだ示されていない

公開時点で最も正直に言えるのは、 公式な原因は示されていないということです。Microsoft の説明は一日のうちに変わりました。「最近の変更は見当たらない」から「障害の開始と一致する最近のネットワーク構成変更を巻き戻している」へ。原因を含む完全な分析は、復旧完了後に公開すると同社は約束しています。

Microsoft が明言しているのは、 これはサイバー攻撃ではないということ。この表現は数時間の間隔を置いて二度使われました。

この一件で最も興味深いのは原因ではなく、復旧が長引いた理由です。稼働に戻したサーバーは、 通信を通した途端にまた落ちました。Microsoft は変更が「期待どおりに機能していない」と率直に認めています。その後は堂々巡りでした。すべての更新と構成変更の停止、再起動、正常性チェックの回避策、一部サーバーを以前の構成で再構築、仮想マシンによる能力の追加。事態が動いたのは、認可とリクエスト経路を担う部品への修正を当てたあとでした。

メールはどうなるのか

最も気がかりな問いなので、項を分けます。

• 配送は遅延している ——Microsoft は障害の説明の中で明言しています。
• メールの待機枠は48時間に延長された。 通常、一定時間内に配送できなかったサーバーは、失敗の印をつけて差出人に返します。枠の延長とは、メールが跳ね返らず、待ち行列で待つという意味です。
• データの消失について Microsoft は報告していない。 ただし正確に言えば、「何も失われていない」とも明言してはいません。文字どおり述べられたのは、遅延したメッセージは保持されるということです。

実務上の帰結。メールを送り直さないでください。待ち行列にあり、サービスが流し始めれば、顧客には重複して届きます。押し寄せを見込んでください。一日分がまとめて届きます。

企業がいますぐすべきこと

1. 問題が自分側ではないことを確かめる。 サインインは通るのにメールが開かないなら、提供側の問題です。障害の状況は Microsoft 365 管理センターの「サービス正常性」で、番号 EX1550543 と MO1550821 から確認できます。
2. 設定に手を触れない。 他者の障害のさなかに最も害をなすのは、自分の側を「直そう」とする試みです。書き換えたドメインレコード、入れ直したメールソフト、初期化したパスワード。サービスが戻ったとき、ほどくべきは自分で作った結果になります。
3. 予備の連絡路を立てる。 障害のあいだ、顧客との急ぎの用件はメッセンジャーか電話へ移してください。返事を待っている相手には知らせを。「メールが止まっています、Telegram へどうぞ」の一言が、沈黙よりずっとましです。
4. 停止を記録する。 業務の停止で損失が出たなら、時刻と影響を書き留めてください。Microsoft にはサービス水準の約束があります。この障害があなたの場合に補償の根拠となるかは、ライセンス契約と、購入経路となった取引先に確かめる話です。

将来に向けた四つの教訓

この規模の障害は稀であり、そこから「クラウドは駄目だ」と結論づけるのは誤りです。物置の自前サーバーのほうが、落ちる頻度は高く、復旧も遅い。教訓は別のところにあります。

1. 予備の連絡路は障害の前に存在していなければならず、最中に考えるものではない。 顧客とのやり取りがすべて一社のメールを通るなら、その障害はあなたを完全に止めます。Telegram のボット、社内メッセンジャー、電話——顧客があらかじめ知っているものなら何でも構いません。
2. すべてを一つの籠に入れない。 メール、文書、連絡、認証、防御を一社にまとめるのは、その会社で何かが壊れる日までは確かに便利です。壊れた日には、すべてが同時に止まります。今回まさにそうなりました。メールとともに Teams、SharePoint、Defender が落ちたのです。
3. お金を生むものは自分の管理下に置く。 サイト、注文、カタログ、問い合わせ——自分で状態を確かめ、控えを立ち上げ、他人の報告を待たずに顧客へ答えられる場所に置くべきです。
4. 「こちら」と「あちら」を見分けられるようにする。 本稿の冒頭にある簡単な点検が、何時間もの慌ただしさを省き、設定への無用な変更から守ります。

私たちのところではどうしているか

私たちはメールと文書に Microsoft 365 を使っており、この障害では私たちのメールボックスも開きませんでした。一方、顧客のために手がけているものは動き続けました。 自社システム Smart CMS上のサイト、チャットボット、顧客向け画面、電話——これらはメールとは別の自前サーバーで動いています。この障害で影響を受けた顧客サイトは一つもありません。

これこそ教訓で言うリスクの配分です。事務の道具は信頼できる外部の提供者に、売り上げと注文を扱うものは自分たちが責任を負える場所に。

出典について

アクセス、メールレコードの状態、応答コードの点検は自分たちで行いました。Microsoft の経過と引用は、管理センターおよびサービス状態ページでの同社の告知によるもので、業界の観測筋の伝える内容を相互に突き合わせました。これら二つの情報源は、当該顧客の管理者にしか開かれていないためです。各事業者にとっての一次情報は、自社の管理センターです。

---

本稿を用意したのは SmartGTのチームです。自社がどれほど一社に依存しているのか、同じような日に自社サイトがどうなるのか——不安があればご連絡ください。 center@uvc.in.net または +38 073 949 61 79。一緒に見て、どこを別々の籠に分けるべきか率直にお伝えします。