Microsoft 365で世界的な障害。Outlookなど約10時間たっても全面復旧せず、原因は未公表

01利用者は入れ直し不要。状態を確かめ、急ぎの連絡は別の道で

まず押さえたいのは、これがMicrosoftの側の障害だということだ。自分のパソコンやアカウントの不具合ではないので、Outlookを入れ直したり、パスワードを変えたりしても直らない。

• 状態を見る：Microsoftの稼働状況のページ（status.cloud.microsoft）で見る。自社への影響は、Microsoft 365の管理センター（admin.microsoft.com）の「正常性」→「サービス正常性」で見られる。見るには管理者の役割が要る。誰が管理者か分からなければ、契約しているIT業者に聞く
• 急ぎの連絡を切り替える：【10時10分 更新】 Microsoftによると、Teamsのチャットとオンライン会議はおおむね使える。急ぎはTeamsのチャットか電話で。障害のあいだに送ったメールは、届くのが遅れることがあるので、復旧のあとで相手に届いたかを確かめる
• メールのリンクは、いつもより慎重に：【10時10分 更新】 メールやTeamsのリンクを開く前に安全かを確かめる機能（Defender for Office 365のSafe Links）が、働かないおそれがある
• 便乗した連絡に乗らない：「障害のため、もう一度ログインしてください」といったメールやメッセージのリンクは開かない。大きな障害のときは、それに便乗したなりすましに気をつけたい

02日本でも4時すぎから報告が急増。メール・会議・ファイル・守りの道具に影響

Microsoftの記録では、障害が始まったのは日本時間の11月13日1時17分（米国東部時間の12日11時17分）。最初はOutlookのメールボックスにつながらない障害だった。約2時間後の3時26分、Microsoftはこれを「Microsoft 365全体の障害」として記録し直した。

【10時10分 更新】 Microsoftは9時45分、影響の一覧を見直した。影響を受けるのは、各サービスのうちメール（Exchange Online）とやり取りする機能で、それ以外は動いているという。見直したあとの一覧は次のとおりだ。

別の管理番号（PP1550869）では、Microsoft Graph（Microsoft 365のデータに、ほかのシステムからつなぐ窓口）を使うPower Platformのアプリやコネクタが、ときどき失敗すると報告された。同じ原因かどうかは、確かめられていない。

日本でも影響が出た。日経によると、障害の報告サイトDowndetectorへの日本の利用者の報告は4時すぎから急に増え、Outlookは6時ごろまでに300件を超えた。SNSには「会社のメールが読めない」という声が上がった（朝日新聞）。日本で何社・何人に影響したかは、まだ分かっていない。

海外では、より大きく広がった。Reutersによると、米国でのOutlookの報告は東部時間の14時7分の時点で9万7,000件を超え、APは13時過ぎに13万件近くに達したと伝えた。カナダ・トロントの病院グループは、メールが使えないため、設備の故障を知らせる「コード・グレー」を宣言した（患者のケアに影響はないと説明）。オーストラリアでは、遠隔教育の学校でTeamsの授業に入れない生徒が出た。これらの件数は利用者が投稿した数で、困った人の数ではない。

Microsoftは最初、南北アメリカの利用者の障害として知らせたが、その後、どの地域の利用者にも影響し得ると改めた。なお、同じMicrosoftのクラウドでも、Azureの稼働状況のページには全体の障害は出ていない。Azure全体が止まったわけではない。

03原因はアクセスの急増ではなく、サーバーの急減。点検に落ちて次々に外れた

これだけ大きな障害だと、「アクセスが殺到したのか」「攻撃か」と考えたくなる。だがMicrosoftは4時18分の更新で、全体のアクセスが増えたのではなく、多くのサーバーが急に使えなくなり、残ったサーバーに負荷が集中していると説明した。

サーバーが外れたのは、自動の点検（ヘルスチェック）に落ちたためだ。クラウドでは、調子の悪いサーバーを点検で見つけ、仕事の割り当てから自動で外す。ふだんは、壊れたサーバーに仕事を回さないための大事な仕組みだ。

スーパーのレジにたとえると分かりやすい。点検で「調子が悪い」とされたレジが次々に閉まると、客は残りのレジに並ぶ。残りのレジは行列をさばききれずに止まり、それも点検で閉められる。開いているレジが減るほど、残りに客が集まる。今回、Microsoftのサーバーで起きたのは、これと同じ悪循環だ。

この連鎖は、クラウドの運用ではよく知られている。Googleが公開している運用の手引き（SREの本）は、一つの所が落ちると負荷がほかに移り、そこもあふれて落ちる連鎖を「カスケード障害」と呼ぶ。そして、点検で調子の悪いサーバーを外す仕組みが、かえって回復を妨げることがあると注意している。

【10時40分 更新】 Microsoftは10時6分、影響を受けたサーバーで、暗号化した安全な接続を張る処理（利用者の端末とサーバーが、盗み見されない通信を始めるための処理）があふれ、サーバーが要求を処理できなくなっていたと明らかにした。それを直す設定の変更を一部のサーバーで試してから広げるという。あわせて、障害の始まりと時期の合う最近のネットワークの設定変更を、元に戻し始めた。ただし、Microsoftはこの変更を「時期が合う」としているだけで、原因だとはまだ言っていない。

ただし、今回はまだ分からないことがある。点検に落ちたからサーバーが止まったのか、先にサーバーの処理がおかしくなったから点検に落ちたのか、だ。点検が元気なサーバーを誤って外していたのかもしれないし、本当に動けないサーバーを正しく見つけていたのかもしれない。いちばん初めに何が起きたのかは、まだ公表されていない。

04Microsoftは4時18分に見立てを改め、7時3分に復旧のやり方を変えた

Microsoftの対応は、通信の振り分け、変更の停止、点検の仕組みの見直しと進み、7時3分に、設備の一部を切り離して少しずつ戻すやり方へ替わった。7時58分に一部の地域で限られた回復が報告されたが、8時59分には、戻したサーバーがまた応答しなくなると報告された。下の時系列は、画面に入ると、間の長さを実際の時間に比べて、1時17分から順に出来事が現れる。

赤い印は、流れの変わり目だ。3時26分に障害がMicrosoft 365全体に広がり、4時18分に「アクセスが増えた」説を退け、7時3分に、それまでの対策が効いていないとして復旧のやり方そのものを替えた。7時58分に回復の兆しが出たものの、8時59分には、戻したサーバーも通信を受けるとまた応答しなくなると分かり、前のソフトウェアの構成でサーバーを作り直す試みに入った。

05攻撃の見張りの道具と、ChatGPT・Claudeのつなぎ先にも影響

今回の障害が重いのは、メールが使えないことだけではない。同じ基盤の上にある業務のサービス、守りの道具、さらにMicrosoftの外のAIまで、仕事を終えにくくなった。下の図は拡大・縮小でき、図の下の番号のボタンを押すと、その場所が赤く光って大きくなる。「順に見る」を押すと、5つの段が順に動く。

外のAIにも影響が出た。OpenAIは、ChatGPTのMicrosoft 365コネクタで、新しい接続やツールの実行に問題があると報告した。Anthropicも、ClaudeのMicrosoft 365コネクタでメール・予定表・検索の多くが失敗し、Claude for Outlookにも影響があるとして、原因はMicrosoft 365の障害だと明記した。

止まったのはAIそのものではなく、AIがつなぐ先だ。AIエージェントがどれほど正常でも、メールやファイルの置き場が応答しなければ、仕事は終わらない。AIエージェントを仕事に組み込むなら、AIが動くかどうかだけでなく、つなぎ先と、その認証やデータの通り道まで含めて、止まったときにどうするかを決めておく必要がある。

【10時10分 更新】 9時45分の見直しでは、メールやTeamsのリンクを開く前に安全かを確かめるSafe Links（Defender for Office 365）が、リンクを確かめられないおそれがあるとされた。障害のあいだは、届いたリンクを開く前に、いつもより注意したい。

守りの道具に届きにくかったことにも、目を向けたい。Defender XDRやPurviewが影響を受けたのは、攻撃を受けた証拠ではない。ただ、障害のあいだ、見張りの画面や情報漏えいの防止、管理の操作が使えなかった会社では、守りに一時的な空白があったかもしれない。

06攻撃の証拠は出ていない。設定の誤りや不具合が有力な調べの対象

結論から言うと、いま公開されている情報に、攻撃が原因だという証拠はない。米国のセキュリティの専門メディアSecurityWeekも、攻撃の証拠は示されていないと伝えている。ただし、最初の原因がまだ分からない以上、攻撃の可能性が消えたわけでもない。

注意したいのは、特定の重い処理だけを狙う攻撃なら、全体のアクセスは大きく増えないこともある点だ。Microsoftは8時59分の更新で、特定の種類の要求が障害に関わっていないかを、通信の種類を絞って確かめているとした。攻撃とは書いておらず、ソフトウェアの不具合でも同じ確かめ方をする。それでも、「アクセスが増えていない＝攻撃ではない」とまでは言えない。

07点検が障害を広げた例は、AWSやAzureでも起きている

点検の仕組みや設定の変更が連鎖のきっかけになった大きな障害は、Microsoftのほかのクラウドでも、ほかの会社のクラウドでも起きている。

AWSが公開している設計の手引きは、点検を厳しくしすぎると、全部のサーバーが一斉に外れ、小さな不具合が全面的な停止に変わることがあると注意している。今回も同じ仕組みだったかどうかは、Microsoftの原因の報告を待つ必要がある。

08会社がすることは、今日・復旧のあと・ふだんの3段

Microsoftの側の障害なので、会社が今日できることの多くは、復旧のあとに困らないための記録だ。

今日のうちに

• Microsoft 365の管理センターで、自社の環境（テナント）に実際にどんな影響が出ているかを見る
• 障害のあいだに失敗したメール・Teams・SharePointの仕事と、障害のあいだに変えた設定や仮の対策を記録する
• Microsoftの製品のほかに、急ぎの連絡の手段を決めて社内に知らせる

復旧のあとに

• Defender XDRとPurviewの記録、情報漏えいの防止（DLP）の処理、検出の履歴に、抜けがないかを確かめる。止まったのが管理の画面だけか、見張りや検出そのものかを分ける
• 遅れた処理、二重になった処理、送られなかったデータを突き合わせる
• AIエージェントや自動の処理をやり直すときは、同じメールを二度送る、同じ更新を二度かけるといったことが起きないようにする

社員に流す案内は、たとえば次のようにする。

Microsoft 365（Outlook・Teamsなど）で、Microsoftの側の障害が続いています。パソコンやアカウントの不具合ではないので、Outlookの入れ直しやパスワードの変更はしないでください。急ぎの連絡は電話で。「再ログインしてください」といったメールのリンクは開かないでください。障害のあいだに送ったメールは、復旧のあとで相手に届いたかを確かめてください。

自社がDefender XDRやPurviewを契約しているか、管理センターを誰が見られるかが分からない会社も多い。その場合は、今日のうちに契約しているIT業者に、影響と、復旧のあとに確かめることを聞いておく。

ふだんから

自社のどの仕事が、どの基盤に頼っているかを知っておく。下の図は、ある会社の例だ。

メールも会議もファイルも、見張りも情報漏えいの防止も、AIエージェントも、実は一つの基盤の上に乗っている。これを平時に一枚の地図にしておけば、止まった日に「何が止まり、何が動いていて、どの道で代わりをするか」を、すぐに決められる。

09最初の原因はまだ不明。Microsoftの次の発表は12時と12時30分

障害の広がり方はかなり見えてきたが、最初の引き金は分かっていない。今後のMicrosoftの発表で確かめたいのは、次の7つだ。

• 最初にサーバーを点検に落とし始めたのは、何だったのか
• 中核の処理があふれた、直接の理由は何か
• 最近の設定変更と、障害の始まりに関係はあったか
• 地域をまたいだ通信の振り分けや、共通の基盤が、障害を大きくしたか
• 攻撃を示す怪しい通信、権限の操作、侵入の跡は見つかったか
• Defender XDRやPurviewの見張りと情報の保護に、実際の抜けは出たか
• 全面的に復旧した時刻、影響を受けた会社の数、同じことを防ぐ手立ては何か

これらを確かめられる原因の報告は、まだ出ていない。【11時40分 更新】 Microsoftは次の更新を、Microsoft 365全体については日本時間の正午、Outlook（Exchange Online）については午後0時30分としている。新しい発表があれば、この記事を更新する。