💡 結論（要点まとめ）
今日Microsoft 365（Teams/Outlook/Office）で障害・不具合が発生しているか1分で確認する方法を解説。管理センターでのサービス正常性の見方から、一般ユーザー向けの公式X・Downdetector活用、自社環境とク
この記事でわかること
- 管理者権限がなくても、Microsoft 365の障害情報を確認できますか？
- Microsoft 365 管理センターの障害情報はどこから確認できますか？
- 「インシデント」と「アドバイザリ」の違いは何ですか？
結論：今日Microsoft 365で障害が疑われるなら、①管理者は管理センターの「サービス正常性」、②一般社員は公式X（@MSFT365Status）とDowndetectorで1分以内に確認できます。
朝一番でTeamsが開かない、Outlookの送信トレイからメールが動かない、Excelのクラウド保存で延々とスピナーが回る——そんなとき最初にやるべきは、再起動でもキャッシュ削除でもなく「これはMicrosoft側の障害か、自分（自社）側の問題か」の切り分けです。ここを最初に判定できると、無駄な30分を失わずに済みます。
この記事は、情シス担当としてMicrosoft 365テナントの運用・障害一次対応に携わってきた編集部が、Microsoft Learn（公式ドキュメント）と総務省の公開ガイドラインという一次情報をもとに、権限あり／なしの両方の立場で使える確認ルートを整理したものです。なお画面名称や仕様は変わるため、実際の判断時は必ず公式ページで最新の表示を確認してください（本記事は執筆時点の仕様に基づきます）。
🔎 編集部リアルタイム確認（当サイトによる実測）
2026年9月8日 06:26 JST時点で Microsoft 365 へ実際に接続を試みたところ、サーバーは正常に応答しました（応答 2004ms）。現時点で当サイトからは広範な障害は確認できませんでした。つながらない場合は回線・アカウント・アプリなど個別環境が原因の可能性があります。
※この確認は当サイトからの接続応答（サーバーが応答したか）を調べたもので、ログインや請求書の表示など個々の機能が正常に動作しているかまでは判断できません。最終的な状況は公式ステータスページをご確認ください。
Microsoft 365で「今日」障害が発生しているか？即時確認する4つのルート
確認ルートは①管理センターのサービス正常性 ②Microsoft 365 Statusの公式X ③Downdetector ④社内チャット/同僚への確認の4つが存在し、精度重視なら①、速報性重視なら②③が適しています。
確認ルート比較一覧表（速報性・正確性・対象者）
| 確認ルート | 対象者 | 速報性 | 正確性 | 特徴 |
|---|---|---|---|---|
| Microsoft 365 管理センター「サービス正常性」 （admin.microsoft.com） |
管理者権限あり | △（公式検知後） | ◎ | 自テナントへの影響範囲・インシデントID・復旧見込みまで確認できる公式一次情報 |
| Microsoft 365 Status（公式X／旧Twitter） | 誰でも | ◯ | ◯ | 大規模障害時に英語で速報。管理者不在でも状況を追える |
| Downdetector など障害検知サイト | 誰でも | ◎ | △ | ユーザー報告の急増グラフで「自分だけではない」を数分で把握 |
| 社内チャット・隣席の同僚に確認 | 誰でも | ◎ | △ | 拠点・部署単位のネットワーク障害の切り分けに有効 |
どの確認方法を最初に使うべきか
- 管理者権限がある人：迷わず管理センターの「正常性」＞「サービス正常性」へ。ここでインシデントの有無を見れば社内周知の可否を判断できます。
- 一般社員：まずDowndetectorのグラフ、次に公式Xの投稿。この2つが一致していれば全体障害の可能性が高い状況です。
- どこにも情報がない：自社ネットワーク／端末側の要因を疑い、後述の5分切り分けフローへ進みます。
ありがちな失敗：Xの検索結果に出てきた個人アカウントの「Teams落ちてる！」という投稿だけを根拠に、全社メールで「Microsoft側の障害です」と断言してしまうケース。数分後に「うちの拠点だけ回線が落ちていた」と判明し、報告の信頼を落とす典型パターンです。SNSは“気づきのトリガー”、判断根拠は公式情報と役割を分けて運用します。
【管理者向け】Microsoft 365 管理センターで「サービス正常性」を正確に把握する手順
管理者アカウントでadmin.microsoft.comにサインインし、左メニュー「正常性」＞「サービス正常性」を開くのが確実なルートです。ここに表示されるのは全世界の一般論ではなく自分のテナントに影響している事象である点が、外部サイトとの決定的な違いになります。
サービス正常性ダッシュボードへのアクセスとステータス見方
- 管理者権限のあるアカウントで管理センターにサインイン
- 左メニューの「正常性」＞「サービス正常性」を選択
- Exchange Online／Microsoft Teams／SharePoint Online など、サービスごとの状態一覧を確認
- 問題があるサービス名をクリックし、インシデントID・影響範囲・最新更新時刻・次回更新予定を控える
- 控えた内容をそのまま社内周知の文面に転記する
Microsoft Learnのドキュメント「Microsoft 365 サービス正常性を確認する方法」および「サービスの正常性および継続性」に、この画面の役割と表示項目が公式に定義されています。判断に迷った際は、このドキュメントを基本指針とします。
「インシデント」と「アドバイザリ」の違い
インシデント（Incident）：サービス利用に著しい影響を及ぼす広範囲の障害。多くのユーザーが主要機能を利用できない状態を指します。
アドバイザリ（Advisory）：影響範囲が一部機能や限られた利用者にとどまる軽微な事象、または回避策が存在する通知事項です。
（出典: Microsoft Learn「サービスの正常性および継続性 – Service Descriptions」による公式定義）
この違いを押さえておくと、社内報告の温度感を誤りません。アドバイザリ段階で「全社障害が発生中」と流すと業務が過剰に止まりますし、逆にインシデントを見落とすと問い合わせが殺到します。
障害履歴（過去7日間・30日間）とメッセージセンターの活用法
解決済みの事象は「問題の履歴」タブから確認できます。Microsoft Learnの記載では、過去7日間および30日間に解決されたインシデント／アドバイザリが保持される仕様です。「先週の木曜にも同じ症状が出た」という報告の裏取りに役立ちます。
またメッセージセンターは障害ではなく変更・計画メンテナンスの通知窓口です。Microsoft Learnの公式ドキュメントによると、計画メンテナンスの事前通知は原則として最低5日前までに管理者へ送られる仕様になっています。「障害だと思ったら事前告知済みのメンテナンスだった」という事故は、ここを週次でチェックしていれば防げます。
【一般ユーザー向け】管理者権限なしでリアルタイム障害を調べる3つの方法
管理センターに入れなくても、公式X・Downdetector・パブリックステータスページの3点により、今日の障害状況を素早く把握できます。
Microsoft 365 Status（公式X / 旧Twitter）の速報チェック
Microsoftが運用する公式アカウント@MSFT365Statusでは、広域障害の発生・調査状況・復旧見込みが投稿されます。投稿は基本的に英語ですが、「We’re investigating（調査中）」「mitigation（緩和策の適用）」といった単語を追うだけでも状況を掴めます。ブラウザで検索すればログイン不要で閲覧できるため、会社支給PCしか触れない環境でも確認しやすい方法です。
Downdetector（ダウンディテクター）でユーザー報告の急増を確認
Downdetectorは利用者の「使えない」報告を集計してグラフ化するサービスです。直近数十分でグラフが跳ね上がっていれば、広域障害の可能性が高いと判断できます。Microsoft 365／Teams／Outlookはそれぞれ別ページに分かれているため、症状の出ているサービス名で個別に見るのがコツです。
注意点：Downdetectorはユーザー報告ベースの非公式データであり、報告数が少ない時間帯（早朝・深夜）は障害中でもグラフが伸びない場合があります。逆に無関係な話題でスパイクする場合もあるため、単独の確定根拠にはしない運用が安全です。
Microsoft 365 サービス正常性パブリックページの活用
Microsoftは管理者以外でも参照できるサービス状況ページを公開しています。検索エンジンで「Microsoft 365 Service Status」と調べ、microsoft.com ドメインのページであることを確かめてアクセスします。障害を装った偽サイトへ誘導する外部リンクを踏まないよう、URLのドメイン確認は毎回行う習慣をつけます。
個別アプリの症状であれば、Excelが開かない・動かない場合の具体的な対処法やTeamsの招待リンクが開けない・参加できない場合の対処法もあわせて参照すると、原因の絞り込みが早まります。
障害か自社ネットワークの問題か？5分でできる切り分け手順
公式に障害情報が出ていない場合、原因として疑うべきは自社プロキシ・Wi-Fi・端末側の設定です。以下の順に試すことで、5分程度で当たりがつきます。
Microsoft 365 Network Connectivity Testの活用
Microsoftはconnectivity.office.comでネットワーク接続診断ツールを提供しています。ブラウザからアクセスしてテストを実行すると、拠点からMicrosoft 365への経路の状態や、プロキシ／DNSまわりの問題点がレポート出力されます。管理者に報告する際、このレポートを添付すると原因究明が一気に進みます。
Web版（ブラウザ）とデスクトップアプリの動作比較
- デスクトップアプリで再現する症状を、ブラウザ版（Outlook on the web / Teams Web）で試す
- ブラウザ版は動く → アプリ側のキャッシュ・サインイン情報・バージョンが原因の可能性
- 両方ダメ → 端末やネットワーク、またはクラウド側の可能性
- スマホのモバイル回線（テザリング／4G・5G）で同じ操作を試す
- モバイル回線なら動く → 社内ネットワーク・プロキシ・ファイアウォールが濃厚
この手順により「自分だけ／自拠点だけ／全社／全世界」のどの範囲に起因しているかが明確になります。スマホでの検証は通信環境を分離できるため切り分け精度が高く、外出先の営業担当からの問い合わせ時にも活用できます。
総務省ガイドラインから見る「設定ミス・自社回線」問題の可能性
総務省の『クラウドの設定ミス対策ガイドブック』（令和6年4月26日公表）によると、クラウドトラブルの一定割合は事業者側の障害ではなく利用者側の設定ミスや通信環境に起因しており、迅速な切り分け手順の確立が復旧遅延を防ぐ要素とされています。
さらに総務省の『クラウドサービス利用・提供における適切な設定のためのガイドライン』（令和4年10月）では、SaaS利用における責任共有モデルをあらかじめ理解し、障害時の一次確認フローをマニュアル化することが推奨されています。「まず何を見るか」を明文化しておくだけで、障害当日の組織的な混乱を抑えられます。
Microsoft 365 障害発生時の社内周知・業務継続（BCP）対応ガイドライン
障害と確定した段階で、情シスおよび管理者の役割は「正確な情報を一発で流し、無駄な問い合わせを抑える」ことにシフトします。曖昧な文面は現場の不安を煽り、問い合わせ件数を増やします。
全社アナウンスのテンプレと記載すべき要素
- 影響サービス（例：Teamsのチャット送受信、Outlookのメール送信）
- 確認時刻と情報源（例：10:15時点、Microsoft 365 管理センターのサービス正常性にてインシデントを確認）
- インシデントID（一意の識別コード。表示されている場合は記載）
- 現在の状況（調査中／緩和策適用中／復旧作業中）
- 暫定的な代替手段と、推奨されない行動（不要な問い合わせや無謀な再設定の防止）
- 次回の情報更新予定時刻（時刻を明記することで個別の進捗照会が劇的に減ります）
復旧見込みについてはMicrosoft側の発表内容を引用するにとどめ、独自判断で「◯時には完全復旧します」と断言しない運用を徹底します。見込みが外れた際の業務混乱や信用低下を回避するためです。
代替ツールの運用ルール（個人SNS利用の禁止・代替ファイル送信）
障害時に最も懸念されるのが代替手段の暴走です。「Teamsが使えないから個人LINEで連絡を取り合おう」「SharePointが開かないから野良ファイル転送サイトで送ろう」という現場判断が、重大な情報漏えい事故につながります。障害時に許可する代替ツールや手順は平常時に策定し、アナウンス内で明示します。
緊急時のファイル送信は、アクセス制限や保管期限の観点でセキュリティリスクが高まります。緊急時のファイル共有ルールについてはMicrosoft 365障害時の緊急ファイル送信・ビジネスリスク対策で、業務利用時の注意点を詳しくまとめています。
実際、過去の現場事例では「Outlook障害の発生時、営業部門が個人フリーメールで見積書を誤送信し、事故対応に多大な工数を割かれた」という事態も起きています。ルール外の行動を禁じる注意喚起を先回りして流すことが、二次被害の防止につながります。
恒久対策：障害復旧後のデータ保護・SaaS監視サービスの活用
障害から復旧した後に検討すべきは、次回障害時の業務停滞やデータ消失を防ぐ恒久対策です。Microsoft 365の標準機能だけに頼るのではなく、SaaS対応クラウドバックアップツールを導入してExchangeやSharePointのデータを二重保持したり、SaaS稼働状況の自動監視ツールを配置して障害検知から社内周知までを自動化するソリューションの活用が進んでいます。事業継続計画（BCP）の観点から、これら専用ツールの比較・導入を進めておくことで、クラウドリスクへの耐性を大幅に高められます。
よくある質問（FAQ）：Microsoft 365の障害確認・不具合に関する疑問
管理者権限がなくても、Microsoft 365の障害情報を確認できますか？
確認できます。公式Xアカウント（@MSFT365Status）、Downdetectorなどの障害検知サイト、Microsoft 365 Service Statusのパブリックページを活用すれば、一般ユーザーでもリアルタイムに近い情報を把握可能です。自社テナント固有の影響範囲を知りたい場合は、管理センターを参照できる社内管理者へ問い合わせてください。
Microsoft 365 管理センターの障害情報はどこから確認できますか？
管理者権限のあるアカウントで管理センター（admin.microsoft.com）にサインインし、左メニューの「正常性」＞「サービス正常性」を開くことで確認できます。サービスごとのステータス、インシデントの詳細、影響を受けるユーザー範囲、最新の対応状況がリアルタイムで反映されます。
「インシデント」と「アドバイザリ」の違いは何ですか？
インシデントは、多くのユーザーや主要機能に著しい影響を及ぼす広範囲な障害を指します。アドバイザリは、影響範囲が局所的であったり回避策が存在したりする軽微な事象や運用上の通知です（Microsoft Learnの公式定義に基づく）。
自分だけがTeamsやOutlookに接続できない場合はどうすればいいですか？
全体の障害情報が出ていない場合、自社ネットワーク・プロキシ設定・アプリやブラウザのキャッシュが原因になっているケースが多く見られます。まずはWeb版（ブラウザ）でのアクセスを試し、改善しない場合は connectivity.office.com でネットワーク診断を実施します。モバイル回線で正常接続できる場合は社内回線側の要因が濃厚です。
障害の履歴はどこまでさかのぼれますか？
管理センターの「問題の履歴」タブにて、過去7日間および30日間に解決されたインシデント／アドバイザリを確認できます（Microsoft Learnの記載による）。長期間の監査ログや障害記録が必要な場合は、社内で履歴ログを保存・管理する運用が推奨されます。
計画メンテナンスは事前に分かりますか？
管理センターの「メッセージセンター」に対し、原則として最低5日前までに通知が届く仕様です。障害と誤認して無駄な調査を行わないよう、情シス部門では週次でメッセージセンターの内容を確認する運用が効果的です。
今日の障害確認、最短でたどるべき順番
最後に、障害発生時に取るべき対応順序をチェックリスト形式で整理します。トラブル発生時は以下の優先順位で確認を進めます。
- 管理者：admin.microsoft.com ＞ 正常性 ＞ サービス正常性 → インシデントIDと影響範囲を確認
- 一般社員：Downdetectorのグラフ → 公式X（@MSFT365Status）の順で状況を把握
- 公式情報なし：Web版での再現テスト → モバイル回線テスト → connectivity.office.com で接続診断
- 障害確定後：影響範囲・情報源・次回更新時刻・禁止事項を含めたテンプレートで社内周知
- 平時の備え：メッセージセンターの定期チェック、代替手段のルール化、SaaSバックアップ・監視ツールの導入検討
個別アプリ側の動作不具合が疑われる場合は、Excelが開かない・動かない場合の具体的な対処法やTeamsの招待リンクが開けない・参加できない場合の対処法の手順を試すことで早期解消につながります。
参考にした一次ソース
- Microsoft Learn「サービスの正常性および継続性 – Service Descriptions」
- Microsoft Learn「Microsoft 365 サービス正常性を確認する方法」
- 総務省『クラウドの設定ミス対策ガイドブック』（令和6年4月26日公表）
- 総務省『クラウドサービス利用・提供における適切な設定のためのガイドライン』（令和4年10月）
画面構成・名称・保持期間などの仕様は変更される場合があります。実際の判断時は、各公式サイトで最新の情報を確認してください。本記事は企業のITインフラ・情シス運用に携わった編集部が、公的情報および公式ドキュメントに基づき中立にまとめています。
📚 参考・出典（編集部が確認した一次ソース）
- soumu.go.jp （soumu.go.jp）
- microsoft.com （learn.microsoft.com）
※本記事の作成にあたり、上記の公開情報・一次ソースを確認しています。
