2026年7月24日午前、日本を含むアジア太平洋地域でMicrosoft Teamsの会議や通話が利用しにくくなる障害が発生した。利用者からは、会議に参加できない、「接続中」のまま進まない、参加後に切断される、音声が途切れるといった報告が相次いだ。
今回の問題は「Teamsの全機能が完全に停止した」という単純なものではない。会議には参加できない一方でチャットは利用できた、通常のTeams会議は開けないが個別通話や一部のグループ通話は使えたなど、利用者や機能によって症状が異なっていた。この部分的な障害こそが、利用者や企業の情報システム部門を混乱させた大きな要因である。
障害はすでに復旧している。しかし今回の出来事は、Teamsという一つのサービスの不具合にとどまらない。オンライン会議、社内連絡、電話、ファイル共有などを一つのクラウド基盤へ集約する企業が増えるなか、業務の効率化と事業継続性をどう両立させるかという課題を改めて突きつけた。
障害の発生時間・影響範囲・原因
Microsoftが管理者向けに案内した障害番号は「TM1437780」である。東海国立大学機構がMicrosoftの通知を転載した障害情報によると、障害時間は日本時間の2026年7月24日午前9時54分から午後0時13分までと記録されている。
午前10時2分の段階で、Microsoftは「Teams会議に参加できない、または接続が切れる可能性がある問題」を調査していた。午前10時59分には大半が回復しつつあることを確認し、午後0時8分にサービス復元を発表した。ただし、障害発生中に開始した会議や通話については、復旧後も接続状態が正常に戻らず、一度終了してから入り直す必要がある場合があった。東海国立大学機構の障害記録
初期の影響分析では、次の機能が影響を受ける可能性があるとされた。
- Teams会議への参加
- 会議の作成・スケジュール設定
- 1対1の通話
- グループ通話
- 通話中の文字起こし
- Teamsと公衆電話網を接続するPSTN通話
Microsoftの最終説明によると、原因は「サービスの耐障害性を高める取り組みに伴って行われた最近の変更」が、トラフィック管理プロセスを過負荷状態にしたことだった。つまり、利用者の自宅回線や社内LANが一斉に故障したのではなく、Microsoft側で通信を振り分ける仕組みに問題が発生したと考えられる。クイーンズランド大学が転載したMicrosoftの障害情報
「耐障害性を高めるための変更が、別の障害を発生させた」という点は重要である。大規模なクラウドでは、設備そのものの故障だけでなく、経路制御、負荷分散、設定変更、自動化された保守処理などが新たな障害原因になり得る。安全性を高める変更であっても、検証範囲や段階的展開、異常時の自動停止機能が不十分であれば、広い範囲へ影響が波及する可能性がある。
なお、今回のTeams障害とほぼ同じ時期の報道では、北米を中心とした別のMicrosoft 365障害「MO1437424」も取り上げられている。こちらは米国西部のネットワーク設定変更により、OneDrive、SharePoint、Teamsのチャット画像、Microsoft 365管理センター、Power Automateなどへ影響した障害である。
後の調査では、自動化されたネットワーク保守処理の不具合により、想定より多くの機器からIP経路が削除されたことが原因と報じられた。Microsoftの通知を保存したペンシルベニア大学の記録、BleepingComputerの原因報道
両方ともMicrosoftのネットワークやトラフィック制御に関係するが、障害番号、主な地域、影響機能、原因説明が異なる。したがって、現時点で二つを同一障害と断定するのは適切ではない。また、サイバー攻撃や情報流出が原因だったことを示す公式情報も確認されていない。
企業が取るべき現実的な対応と落としどころ
今回の障害から導かれる結論は、「クラウドは危険だからオンプレミスへ戻す」でも、「大手サービスの障害なら仕方がない」で終わらせることでもない。必要なのは、業務の重要度に応じて対策の強さを変えることである。
顧客対応、採用面接、医療・金融・公共サービス、障害対応会議など、延期による損失が大きい業務には、別ベンダーの会議サービスや電話会議を事前に用意する。一般的な社内会議は、障害時にチャットやメールへ切り替えるか、復旧後に延期する。情報共有だけが目的の会議は、資料や録画、議事メモで代替できないかを平常時から検討する。このように分類すれば、全業務に高額な二重環境を用意する必要はない。
実務上は、少なくとも次の準備が求められる。
- Teamsとは別系統の連絡手段を決め、障害情報を一元的に通知する
- 重要会議用の代替ツールを会社として承認し、参加権限やセキュリティを設定する
- 「何分接続できなければ延期または切り替えるか」を会議招集時に明示する
- 復旧後もつながらない場合は、影響を受けた会議や通話を一度終了して再開する
- 情報システム部門はMicrosoft 365のサービス正常性通知をメールやアプリで受け取る
- 障害後は影響人数、停止した業務、代替手段が機能したかを記録し、手順を更新する
代替サービスは導入するだけでなく、定期的に接続テストを行う必要がある。アカウントが失効していた、外部参加者を招待できなかった、社内ネットワークからアクセスが禁止されていたという状態では、緊急時に役立たない。また、Microsoftアカウントによるシングルサインオンに代替サービスまで依存させると、認証基盤の障害時に両方が利用できなくなる可能性がある。システム名が異なっていても、認証、回線、クラウド基盤などの依存先が同じなら、実質的な冗長化にはならない。
2026年7月24日のTeams障害は約2時間余りで復旧した。しかし、発生したのが多くの企業で朝会や午前の打ち合わせが始まる時間帯だったため、短時間でも影響を実感した利用者は多かった。
障害を完全になくすことはできない。今回の本質的な教訓は、特定の製品を批判することではなく、「止まらない仕組み」だけを期待する運用から、「止まっても重要業務を続けられる仕組み」へ移行する必要があるという点にある。全面的なマルチクラウド化と無対策の中間に、業務の重要度に応じた代替手段、明確な切り替え基準、迅速な社内連絡という現実的な着地点がある。
コメント