Skip to content
Microsoft 365 大規模障害のあとで:日本企業が業務を止めないためのマルチクラウド設計

Microsoft 365 大規模障害のあとで:日本企業が業務を止めないためのマルチクラウド設計

画像: xAI Grok生成
19 分で読めます
0
0 件のコメント
30 回表示

2026 年 11 月 12 日、Microsoft 365 で大規模障害が発生し、Outlook や Teams が約 10 時間にわたって使えなくなり、日本時間 13 日の午後になっても安定していません。公開報道をもとに経緯を整理し、SLA で補償されるもの・されないものを確認したうえで、重要な業務にだけ別の経路を用意する、日本企業向けのマルチクラウドによる事業継続策を提案します。

はじめに

2026 年 11 月 12 日(米国東部時間)、Microsoft 365 で大規模な障害が発生し、Outlook や Teams などのサービスが使えなくなりました。原因の中心は Exchange Online です。ロイターによると、同日の障害は約 10 時間に及び、日本時間 13 日の午後になっても、Microsoft は構成のロールバックや容量の拡張を続けており、サービスは不安定なままです。日本時間 13 日(金)の早朝からは、日本でも障害の報告が出ています。

今年に入って、こうした障害は初めてではありません。私の結論はシンプルです。止まらないクラウドはありません。しかし、「クラウドが止まっても、仕事までは止まらない」ように業務を設計することはできます。マルチクラウドとは、すべてのシステムを二重にすることではありません。止まると本当に困るもの、つまり連絡、メール、データ、ID、そして AI との連携にだけ、前もって別の経路を用意しておくことです。

本記事の事実に関する記述は、日本時間 2026 年 11 月 13 日 15 時時点の公開報道に基づいています。

1. 何が起きたのか

時刻(米国東部 / 日本)出来事
11/12 12:54 / 11/13 02:54Microsoft 365 Status アカウントが X で、米州のユーザーが複数の接続方法で Exchange Online のメールボックスにアクセスできない問題を確認
13:00 ごろ / 03:00 ごろDowndetector で Outlook の障害報告がピークに達し、約 138,058 件
14 時以降 / 4 時以降Microsoft の説明:負荷の上昇はトラフィックの増加によるものではなく、一部のサーバーが予期せず利用できなくなり、残りの設備に負荷が集中したため。すべてのデプロイを停止し、トラフィックの移動とサーバーの再起動を進めている
18:00 ごろ / 8:00 ごろ一部のサーバーは復旧して安定しているが、復旧は限定的。可能な範囲でトラフィックを代替経路に移し、残りのサーバーを復帰させる手順を簡素化している
20:18 / 10:18Microsoft によると、安全な接続を確立するプロセスに過大な負荷がかかり、サーバーが要求を処理できなくなっていた。障害の開始時刻と一致する最近のネットワーク構成変更のロールバックを開始
21:30 / 11:30米国では Outlook の障害報告がなお 2.5 万件を超える
22:17 / 12:17Microsoft は、この変更が想定どおりの効果を上げておらず、容量を増やす別の方法を探っていると発表。その後、悪意ある活動の兆候はないとも説明
11/13 0:04 / 14:04調整したリージョンで一部回復したが持続せず。容量を増やして負荷を下げるため、仮想マシンを増強している

日本時間 13 日(金)の早朝からは、日本、インド、オーストラリアなどアジア太平洋でも障害の報告が出ています。Microsoft はこれに先立ち、容量が戻りクライアントが再接続するにつれて、ユーザーは段階的に回復すると説明していました。

影響はメールにとどまりません。Exchange Online に依存する場面、たとえば予定表、会議の設定、情報バリア(Information Barriers)を有効にしている組織での Teams チャットの作成などが失敗する可能性がありました。Microsoft が影響の可能性があるとしたサービスには、Copilot、SharePoint Online、Microsoft Defender、Planner、To Do も含まれています。Downdetector によると、障害報告は約 1 時間で 74 の国と地域に広がりました。企業だけでなく、米国下院のユーザーや、オーストラリアの情報機関と連邦警察も影響を受けました。

AI サービスにも影響が及びました。OpenAI は Microsoft コネクタの問題を調査中で、新しい接続が失敗する可能性があり、一部のツールが正常に動いていないとしました。Anthropic は、上流のプロバイダーの問題が自社の Microsoft 365 コネクタに影響していると説明しています。報道で取り上げられた影響は、これらの AI サービスと Microsoft をつなぐ部分に集中していました。

企業経営にも直接影響が出ました。米国の電動トラックメーカー Workhorse は、11 月 12 日の米国東部時間午後 4 時 30 分に予定していた第 3 四半期決算の電話会議を、「世界的な Microsoft の障害による業務の混乱」を理由に 11 月 16 日へ延期しました。

同様の障害は今年すでに何度も起きています。1 月 22 日には Microsoft 365 と Outlook が主に北米で停止し、7 月 23 日には米国西部リージョンのネットワーク障害が Azure と複数の Microsoft 365 サービスに波及しました。8 月 31 日には Outlook と Exchange Online で障害が発生し、11 月 9 日には欧州・中東・アフリカの一部のユーザーが Web 版 Outlook でメールボックスにアクセスできない状態が約 4.5 時間続きました。さらに遡ると、2025 年 10 月 29 日には Azure Front Door の構成変更による世界規模の障害が Microsoft 365 にも波及しています。

2. SLA が返してくれるのは料金であって、時間ではない

Microsoft 365 の Exchange Online や Teams などの SLA は、月間稼働率 99.9% です。稼働率が 99.9%、99%、95% を下回ると、それぞれ 25%、50%、100% のサービスクレジットを受けられますが、利用者自身が申請する必要があります。99.9% で計算すると、1 か月に約 43 分の停止までは SLA の範囲内です。

クレジットは該当サービスのその月の料金に対するもので、事業上の損失を埋めてくれるわけではありません。延期された決算発表、返信が遅れた受注メール、開けなかった Teams 会議は、SLA の計算には含まれません。

もう一つの現実は、利用の集中です。日本のガバメントクラウドでは AWS、Microsoft Azure、OCI、Google Cloud、さくらのクラウドの 5 つが認定されていますが、実際の利用は大きく偏っています。デジタル庁の資料によると、3 月 31 日時点で国の情報システムの約 85% が AWS 上で稼働しています。デジタル庁の担当者は 6 月の説明会で、地方自治体でも約 80% が AWS を採用していると述べ、複数の事業者が切磋琢磨してバランスを保つことが望ましいとしました。ベンダーのリストに複数の名前が並んでいても、業務に本当の意味での別経路があるとは限りません。

3. マルチクラウドの正しい使い方:すべてを二重にしない

すべてを二重化すれば、コストも運用の負担も倍になり、中小企業には現実的ではありません。より現実的なのは、まず「止まったらどうなるか」で業務を分類し、重要度の高い業務にだけ別の経路を用意することです。次の表は、私たちが提案する分類の例です。

業務1 時間止まると1 日止まると用意したい別経路
社員同士・顧客との緊急連絡困る深刻Microsoft 365 以外の連絡手段
メールの送受信(受注、見積、顧客対応)我慢できる深刻メール継続サービス、主要取引先向けの予備の連絡先
ファイルと資料我慢できる困る別のクラウド上のバックアップ
管理者のサインインと権限問題発生時は深刻深刻緊急アクセス用アカウント
AI エージェントと業務の自動化我慢できる困る複数のモデル経路、縮退できるワークフロー

4. 6 つの技術的な対策

  1. 代替の連絡手段。 Microsoft 365 に依存しない連絡手段を平時から用意しておきます。別ベンダーのチャットツール、電話や SMS の連絡網、そして Microsoft 365 の外に保管した緊急連絡先リストです。アラートや通知も、障害を起こしているプラットフォームに依存しない経路で届くようにします。
  2. メールの継続性。 ドメインの DNS(MX レコードを含む)は自社で管理できる DNS サービスに置き、TTL の設定を把握しておきます。メール継続サービスやアーカイブサービスを使って、受信メールのコピーを別のシステムにも配送しておけば、Exchange Online が使えない間も重要なメールを確認し、返信できます。主要な取引先や仕入先には、予備の連絡先も伝えておきましょう。
  3. ID の非常口。 Microsoft は、2 つ以上の緊急アクセス用アカウントを作成するよう推奨しています。クラウド専用で onmicrosoft.com ドメインを使い、フェデレーションや同期を行わないこと。日常の管理者アカウントとは異なる認証方式を使うこと(Microsoft は FIDO2 パスキーや証明書ベース認証のようなフィッシング耐性のある方式を推奨)。そしてこれらのアカウントのサインインを監視し、使われたら他の管理者に通知することです。Exchange の障害中に社員がメールを受け取れるようになるわけではありませんが、認証や設定に問題が起きたときに管理者が締め出されることを防げます。
  4. データのコピーを別のクラウドへ。 Exchange、OneDrive、SharePoint の重要なデータを、AWS や Google Cloud の国内リージョンへ定期的にバックアップし、できれば変更できない(イミュータブルな)コピーとして保管します。障害や誤削除のときにも、重要な資料を読み出せます。
  5. AI エージェントの冗長化。 今回は OpenAI と Anthropic の Microsoft コネクタにも影響が出ました。AI エージェントを業務フローに組み込むときは、上流は必ず止まるものと考えて設計します。タスクはまずキューに入れ、失敗したら自動で再試行して担当者に通知する。エージェントが使うナレッジベースは Microsoft 365 の外にも 1 部保管する。モデルの呼び出しには複数の経路を用意する。たとえば Amazon Bedrock の日本国内クロスリージョン推論は、リクエストを東京と大阪のリージョンだけにルーティングします。
  6. 監視、判断、訓練。 ベンダーのステータスページ、Downdetector のような外部の監視、自社の合成監視を組み合わせます。別経路に切り替える判断基準と手順書を事前に決めておきます。たとえば、重要業務が 30 分以上止まったら切り替えを開始する、といった基準です。訓練は少なくとも年に 1〜2 回行います。ここで挙げた 30 分や訓練の頻度は私たちの提案であり、何らかの基準で定められたものではありません。

5. どこから始めるか:投資の小さい順に

  • 今週: 緊急連絡先リストと代替の連絡手段を Microsoft 365 の外に用意する。緊急アクセス用アカウントで実際にサインインできるか確認する。Microsoft のサービス正常性の通知を購読する。
  • 今月: 業務を分類し、それぞれ許容できる停止時間(RTO)とデータ損失の範囲(RPO)を決める。メール継続とバックアップの方式を選ぶ。
  • 今四半期: AI エージェントと自動化フローに、縮退の経路と複数のモデル経路を加える。切り替え訓練を 1 回実施する。

おわりに

止まらないクラウドはありません。今回の障害が日本企業に問いかけているのは、「どのクラウドがいちばん信頼できるか」だけではなく、「それが止まったとき、自社の業務に残る経路はどれか」ということです。

その経路を前もって整えておく費用は、多くの場合、1 日業務が止まる損失よりずっと小さく済みます。緊急連絡先リストを 1 枚用意するだけでも、多くの企業より一歩先に進めます。

ソラナリンク株式会社について

ソラナリンク株式会社(SolanaLink Co., Ltd.)は東京の IT サービス企業で、クラウドソリューション、Web・モバイル開発、IT 運用、AI エージェント導入を提供しています。業務の重要度の整理、AWS・Google Cloud・Microsoft 365 にまたがる事業継続策の設計、縮退できる AI エージェントのワークフロー構築などでお手伝いが必要でしたら、info@solanalink.jp までお気軽にご連絡ください。

参考資料

11 月 12 日の障害

これまでの障害

SLA、ガバメントクラウド、ID

AI と国内推論

コメント

コメント (0)