2026年8月31日の夜、Microsoft 365全体で広範な障害が始まり、管理センターではEX1464935として記録され、その後MO1465074として範囲が拡大されました。影響はメールにとどまりませんでした。Exchange OnlineがTeams、SharePoint Online、OneDrive for Businessとともにダウンし、それとともにPurviewとDefender XDRのガバナンスおよびセキュリティツールも止まりました。メールで顧客とやり取りし、社内はチャットで調整し、ファイルをクラウドに置き、ダッシュボードでセキュリティを監視していた企業は、その四つすべてを同じ瞬間に失いました。

Microsoftは原因を、Exchange Onlineインフラ内の複数の内部サービスが使用する中核的な認証構成の問題と説明し、認証コンポーネントをまずインフラの一部サンプルに再適用してから範囲を広げる段階的な緩和策を実施しました。メールフローと検索は9月1日に復旧し、ごく一部のユーザーへの限定的な影響は9月2日まで続きました。完全な中断は一日を超え、その余波は二日に及びました。

これはMicrosoftについての記事ではありません。大手プロバイダーにはどこでも障害があり、私たちは以前にも他のAIサービスの中断を取り上げてきました。これは、今回の障害が浮き彫りにしたものについての記事であり、それは一見したよりも危険なものです。

六つのシステムと数えているものが一つかもしれない

どの管理者にシステムを挙げてもらっても、リストが返ってきます。メールシステム、チャットシステム、ファイルシステム、セキュリティシステム。四つの名前、四つのアイコン、たいていは契約書上の四つの行です。自然な想定は、一つが落ちても他は道連れにならない、なぜなら別々のものだから、というものです。

しかし、名前はシステムの境界ではありません。本当の境界は、それらのサービスが裏側で共有しているものです。誰があなたの本人確認をしているのか、セッションはどこに保持されているのか、どのネットワークを通っているのか。四つのサービスが一つの認証レイヤーを共有しているなら、請求書の上でどれほど別々に見えても、リスクの観点では一つのサービスです。

厄介なのは、この共有が平常時には決して表に出ないことです。むしろ、便利なシングルサインオンや、メールとファイルのスムーズな連携をもたらしているのはまさにこの共有です。あなたは毎日その利便性を買い、数年に一度、長い一日でその代償を払うのです。

これは中堅のサウジ企業にもグローバル企業にも同じように当てはまります。自社のサービスのうちどれだけが、一つのGoogleアカウント、一つのWhatsApp番号、一つのホスティング事業者、あるいはパスワードを握る一人の社員にぶら下がっているか考えてみてください。そのそれぞれが単一障害点です。違いは、あなたの単一障害点のほうが小さく、はるかに直しやすいということです。

一時間で依存関係を洗い出す

ツールもコンサルタントも要りません。必要なのは紙一枚と一時間、そして正直な答えです。最初の列には、丸一日なしでは回らない業務をすべて書きます。受注、請求書の発行、顧客対応、給与計算、サービスの提供。次に、それぞれについて三つの質問をします。

  • この業務はどの外部サービスに依存しているか？商用名をそのまま書きます。このメールプロバイダー、あのECプラットフォーム、あの決済ゲートウェイ、あのメッセージングプロバイダー。
  • どのアカウントやIDでサインインしているか？たいていここで驚きが待っています。一つのアカウントで入っている四つの異なるサービスや、認証コードのために一つの携帯番号に紐づいた三つのサービスが見つかるでしょう。
  • これが今すぐ止まったら、一時間以内の代替手段は何か？答えが「なし」なら、理論上ではなく現実の単一障害点を見つけたことになります。

書き終えると、一つか二つの項目がほとんどの行で繰り返し出てくるはずです。それが共有依存です。すべてを取り除こうとしないでください。それは現実的でも経済的でもありません。売上を止める行を選び、まずそれに対処しましょう。

最も防ぎやすい種類の障害：有効期限

障害はどれも同じではありません。自分では制御できない複雑さから生じるものもあれば、誰も読まない場所に書かれた日付から生じるものもあります。後者は最も防ぎやすく、そして最も繰り返し起きる種類です。必要なのはフォローアップだけだからです。

次に挙げるのは、あなたのビジネスを静かに動かしている有効期限であり、どれも名指しの担当者とともに一つのカレンダーに載せるべきものです。

  • ウェブサイトの暗号化証明書。期限が切れると、サイトは遅くなるのではなく、訪問者に入室をためらわせる明確なセキュリティ警告を表示します。売上への影響は即時かつ全面的です。
  • ドメイン登録。ドメインの更新を忘れると、ウェブサイトとメールが一緒に止まります。メールが同じドメインで動いているからです。説明に使うはずだったチャネルそのものを断ってしまうため、最悪の障害の一つです。
  • 電子インボイスのスタンプ証明書。ザカート・税・関税庁（ZATCA）の電子インボイス詳細技術ガイドラインは、納税者が請求書発行ユニットの暗号スタンプ識別子を、既存のものが失効する前に更新すること、そして更新には古い識別子の失効と新しい識別子の発行が伴うことを定めています。この期間を逃せば、それは単なる通知ではなく請求業務の問題になります。
  • システム間の連携キー。ストアと在庫システム、あるいは自社システムと決済ゲートウェイをつなぐアクセストークンには、決められた有効期間があります。その期限切れはどちらのシステムも止めず、両者の間の橋を止めます。注文は入り続ける一方で、同期は静かに止まります。これは発見が遅れるタイプの障害です。
  • アプリの署名証明書と登録済みカード。署名証明書が切れるとストアにアップデートを出せなくなり、サブスクリプションのカードが切れるとサービスそのものが止まります。どちらも最悪のタイミングでやって来がちです。

実務上のルールはシンプルです。有効期限のあるものには三つが必要です。六十日前のアラート、部署ではなく名前で決めた担当者、そして担当者が不在のときに更新方法を知っている代理担当者。三つのうち一つでも欠ければ、誰かの記憶頼みに逆戻りです。

プロバイダーがダウンした日にすべきこと

障害が起きたとき、プロフェッショナルに見える企業と慌てて見える企業の違いは復旧の速さではありません。そもそも復旧はあなたの手の中にはないのです。違いは、事前に準備しておいた三つのことです。

  • 落ちたレイヤーの外にある連絡チャネル。社内の調整がすべて一つのツールの中にあるなら、それが落ちたときには調整の手段がありません。本当に別のチャネル上のバックアップグループと、システムの外に保管した連絡先リストがあれば十分です。
  • 重要業務のための手動モードの明文化。システムなしで、どうやって注文を受け、支払いを記録し、サービスを提供しますか？今日それを一ページに書き、チームに渡してください。そのページを書いた企業は数時間を失い、書かなかった企業は一日を失います。
  • 顧客向けに用意したメッセージ。顧客を怒らせるのは障害そのものより沈黙です。何が影響を受けているか、回避策は何か、次の更新はいつかを伝える短いお知らせが、障害を管理された状況に変えます。自分で制御できない復旧時刻を約束してはいけません。

終わった後は、一つだけ質問をしてください。それ以上は要りません。今日、自分たちの依存関係について、知らなかった何を学んだか？その答えはどんな報告書よりも価値があり、たいていは一つの変更に値する一行です。

Origamiの視点

私たちの仕事の中で、経営者を最も驚かせるのは障害そのものであることはまれです。独立していると信じていたシステムが一緒に落ちたと気づくことです。「代替手段はある」という思い込みの上に築かれた判断は、すべての代替手段が同じ扉を通っていると判明した瞬間に崩れます。だからこそ私たちは、継続性に関するどんな話し合いも、ツールの購入ではなく依存関係の洗い出しから始めます。購入したツールが同じレイヤーの上に乗っていて、リスクを下げるどころか高めてしまうことも十分あり得るからです。

また私たちは、このような障害への正しい対応はクラウドから逃げることではないと考えています。信頼できるプロバイダーのクラウドインフラは、ほとんどの企業が自前で構築・運用できるものより信頼性が高く、まれな中断があってもそれは変わりません。正しい対応は、自社のどの業務が止まり、どの業務が続くのかを正確に把握し、それを悪い日に初めて知るのではなく、意図的に選んでおくことです。継続性は購入するシステムではありません。何のプレッシャーもないうちに下しておく、小さな決断の積み重ねです。

まとめ

共有の認証レイヤーで起きたたった一つの障害が、世界中の企業で六つの製品を一日以上止めました。教訓はプロバイダーを乗り換えることではなく、自社のシステムが表面の下で実際に何を共有しているかを知ることです。依存関係をあぶり出す三列の表から始め、すべての有効期限を名指しの担当者とともに一つのカレンダーにまとめ、必要になる前に手動モードのページを書いておきましょう。それはあなたと丸一日の麻痺の間に立つ約三時間の作業であり、だからこそ最も安上がりな継続性への投資なのです。

出典