- 公開日
マイクロソフトは15日間で2度ダウンし、2度目には決算発表日を変更した。
- 著者

- 名前
- AbnAsia.org
- @steven_n_t
Listen in English · マイクロソフトは15日間で2度ダウンし、2度目には決算発表日を変更した。
0:00 / 0:00
Watch in English · マイクロソフトは15日間で2度ダウンし、2度目には決算発表日を変更した。
Microsoft 365、Outlook、Teams、Copilot、Storeは11月13日ハノイ時間午前1時ごろから障害が発生し、米国だけでOutlookに関する報告が13万件に上った。マイクロソフトは当初、負荷が原因だとしていたが、その後サーバーが異常な動作をしていたと説明した。OpenAIとAnthropicはともにコネクタの障害を報告し、電気トラックメーカー1社はその影響で四半期決算の発表を延期した。
11月13日のハノイ時間午前1時ごろから、ベトナムやその他の地域のユーザーは、Microsoft 365、Outlook、Teams、Copilot、Microsoft Storeを利用できなくなった。Downdetectorは、米国だけでもOutlookについて13万件以上の報告を記録し、Microsoft 365については4万5,000件、Storeについては1万件を記録した。その大半は接続やメールの送受信に関するものだった。
興味深いのは障害そのものではない。二次的な被害だ。
Microsoftが述べたこと、そして何が変わったか
同社の最初の声明は、インフラの一部が「高負荷」状態にあると説明していた。その後それを修正し、過負荷はトラフィックの急増によるものではなく、一部のサーバーが**「予期せず正常に動作していなかった」**ことによって、まだ正常なサーバーに負荷がかかったためだと述べた。
その区別は重要だ。トラフィックの急増はキャパシティプランニングの問題だ。サーバーが異常に故障するのは信頼性の問題であり、Microsoftが説明した復旧方法がその証拠だ。可能な場合はトラフィックを代替のネットワーク経路にリダイレクトし、残りのサーバーを復旧させるプロセスを最適化する。ユーザーは「段階的に」アクセスを取り戻す。
言い換えれば、システムは残っているものに負荷を逃がすことで自己防衛したが、それはまさに1つの障害ノードを世界的なインシデントに変える振る舞いだ。
連鎖反応こそが核心だ
米国のAI研究所2社は、マイクロソフトの障害が自分たちにも及んだと公に述べた。
サーバーが正常に動作しなくなる
マイクロソフトは、需要が容量を超えて増えたのではなく、一部のサーバーが異常に動作し始めたと述べている。
残りが負荷を引き受ける
トラフィックは残存するインフラと代替のネットワーク経路に流され、稼働を続けるマシンは想定された容量を超える負荷を負うことになる。
コネクタが1層上で故障する
OpenAIは、Microsoftコネクタの問題を調査中で、新規接続が失敗し、一部のツールが誤動作していると述べた。Anthropicは、Microsoft 365コネクタの障害を上流プロバイダーに帰した。
企業が提出期限を逃す
米電動トラックメーカーのWorkhorse Groupは、障害が「業務を混乱させた」ため、第3四半期決算の発表を11月12日から11月16日に延期した。
ワークホースの詳細は強調に値する。なぜなら、日付が付されている唯一のものだからだ。ユーザーを単にいら立たせるだけの障害はサポートコストだ。上場企業の四半期開示を4日遅らせる障害は重大な依存関係である——そして、その企業のリスクカレンダーに、業績が遅れる理由として「マイクロソフト」を書き込んだ人は誰もいなかった。
2件の障害、15日間
これは孤立した朝ではない。
- サービスだけでなく、コネクタを把握せよ。 ここで最も打撃を受けたチームはExchangeを運用していたのではなく、Microsoft経由で認証する製品を運用していた。自社スタックがMicrosoftを「メール」の下にしか挙げていないなら、そのマップは間違っている。
- 何が失敗するかではなく、何が劣化するかを書き出せ。 「Outlookが落ちている」は耐えられる。「新しい連携を作れず、四半期提出が遅れる」は耐えられない。練習すべきは後者の文だ。
- ベンダーの言い訳に備えて練習せよ。 Workhorseは正しいことをした——公表し、期日を動かし、理由を述べた。
2週間のうちに2件のグローバル障害が、同じベンダーの環境で、異なる症状と同じ形を伴って起きた。あるコンポーネントが劣化し、健全な残りの部分がそれを吸収することを求められ、下流のすべてがその問題を引き継ぐ。
これを基盤に構築する人にとって変わること
実践的な教訓は「別のクラウドを選べ」ではない。大規模プロバイダーはどこも、ひどい2週間を経験したことがある。教訓は、プラットフォームへの依存は、その障害モードへの依存であるということであり、それらのモードは今やマッピングできるほど可視化されている。
次が起きる前にやっておく価値のある3つのこと:
ほとんどの企業は、インシデントの最中になって、その判断に責任を持つ者が誰もいないことに気づく。
当社はデータと推論のシステムを構築しているが、クライアントが軽視しているのはこの点だ。プラットフォームの停止はITイベントではなく、スケジュールが付きまとう事業継続上の出来事である。うまく対処する組織は、自社のどの約束が他社のサーバーに依存しているかをすでに把握しており、サーバーが正常に動作しなくなる前に、そうであると書面で明言していた組織である。
出典:VnExpress、2026年11月13日。Downdetectorの数値、MicrosoftのReutersへの声明、およびOpenAI、Anthropic、Workhorse Groupの公開声明を報じたもの。10月29日のAzure障害の詳細はVnExpressの報道による。報告件数は苦情を訴えたユーザー数を示すものであり、インシデントの深刻度や原因を測るものではない。
日本語版は Ai 支援を使用しているため、小さな間違いが存在する可能性があることをご了承ください。
著者
Ai-Banking-NetworkSecurity (ABN), ABN ASIAは、アカデミアに深く関わり、アメリカ、オランダ、ハンガリー、日本、韓国、シンガポール、ベトナムでの仕事経験を持つ人々によって設立されました。ABN ASIAは、学問とテクノロジーが機会と出会う場所です。最先端のソリューションと優れたソフトウェア開発サービスにより、ビジネスがレベルアップし、グローバルシーンに挑戦できるよう支援しています。 私ちの取り組み: より速く。 より良い。 より信頼性が高くなります。 ほとんどの場合、価格も安くなります。
いつでも、ITサービス、デジタルコンサルティング、既製のソフトウェアソリューション、または提案依頼書(RFP)をお探しの際は、お気軽にお問い合わせください。お問い合わせ先は[email protected]です。お客様のテクノロジーに関するニーズにお応えします。

© ABN ASIA