2026.09.06

Microsoft障害の確認方法｜公式と外部情報で影響を切り分ける

Q: Microsoft 365にログインできないとき、障害かアカウント問題かを見分けるには？

ログイン不可は、障害・設定変更・アカウント侵害対策が同じ症状になりやすいため、比較で切り分けます。特に侵害対策としてパスワードリセットやアカウント無効化、セッショントークンの強制リセットを行うと、正規ユーザーも一斉にサインインを求められるため、事前周知がないと障害と誤認されやすいです。

経営リスクナビ編集部

Microsoft 365障害が疑われる場面では、Teamsやメールが使えない原因が「全体障害」なのか「自社の設定変更・端末起因」なのかを、短時間で切り分けられるかが初動の成否を分けます。判断を先送りすると、不要な設定変更や社内問い合わせの増加で復旧判断が遅れ、事業継続の代替策（連絡手段の切替え等）も後手に回りがちです。平時から最低でも3か月のログ参照可否や、公式情報・外部監視・SNSの使い分けを押さえておけば、影響評価と社内周知の出し分けを具体的に決めやすくなります。本稿では、障害か自社固有かを見極める初動と情報収集の要点を、順を追って確認していきます。

Microsoft 365障害の切り分け
サービス正常性の見方
Microsoft 365の情報源を広げる
Xで障害情報を確かめる
- X検索で速報を集める観点を絞る
- 投稿の真偽と影響範囲を見極める
主要サービスの影響と初動対応
復旧後の記録と運用改善
よくある質問
Microsoft 365の判断に必要な要点

Microsoft 365障害の切り分け

障害確認の初動フローを決める

Microsoft 365の不調が疑われたら、最初に「公式障害か／社内起因か／端末個別か」を短時間で切り分ける初動フローを決めておくことが重要です。特に、セキュリティインシデント（アカウント侵害など）でも「障害のように見える症状」（サインイン不可、メール不達、Teams利用不可）が起きるため、情シス内で障害対応とインシデント対応の分岐点を明文化しておく必要があります。

初動で集める情報と確認順序

発生時刻・影響サービス（Teams／Exchange Online／SharePoint等）・影響ユーザー（部署、役職、拠点）を一次情報として記録します。
同一症状が複数ユーザーに出ているかを確認し、影響範囲（全社／一部部署／個人）を仮置きします。
管理者は管理センターのサービス正常性を確認し、インシデントやアドバイザリが出ていないかを見ます。
直近の変更（条件付きアクセス、MFA、プロキシ、ファイアウォール、メール転送ルール等）と一致していないかを時系列で当てます。
侵害疑い（不審サインイン、身に覚えのない転送設定等）がある場合は、障害調査と並行してパスワードリセット／アカウント無効化などの封じ込めに移ります。

また、調査に必要なログが確保できないと切り分けが止まるため、参照できるログの保管方針として「最低でも3か月、望ましくは半年〜1年程度」を確保できているか、平時から確認しておくと実務上の事故が減ります。

サインインと設定変更の影響を確認する

Microsoft側の障害を疑う前に、まずはサインイン（認証）周りと直近の設定変更を確認します。Microsoft 365は認証基盤（Azure AD／Entra ID）と各サービスが密接に連動しているため、設定変更や認証エラーが「全サービスが落ちた」ように見えることがあります。

直近変更で確認するポイント（例）

条件付きアクセスや多要素認証（2要素認証）の導入・例外設定変更が直前に入っていないかを確認します。
侵害対策としてセッショントークンの強制リセットを実施した場合、既存セッションが切れて一時的にサインイン要求が増える前提で周知します。
2要素認証を導入できない事情がある場合は、窃取の可能性がある認証情報を強固なパスワードへ一斉変更し、機密情報を扱う部署の利用を一時停止する判断軸を持ちます。
Firewall／PROXYを迂回できる経路（例：ExpressRoute等）があると、ネットワーク側の想定と異なる挙動になり得るため、経路の実態を押さえます。

設定変更の事実確認は、変更管理（誰が・いつ・何を変えたか）と突き合わせて行います。社内側の変更が原因のときに闇雲に追加変更を重ねると、影響範囲が拡大し、復旧判断が遅れます。

同時発生の台数と拠点数で「全社障害」か「端末個別」かを判定する

障害か自社固有かを急いで切り分けるには、「同時発生の台数」と「拠点の広がり」が最も強い手掛かりになります。加えて、障害の裏にマルウェア感染端末が紛れている場合もあるため、端末個別の事象でもEDRアラート有無を同時に確認します。

観測	考えやすい原因	初動アクション
1台のみで発生	端末固有（キャッシュ、ローカル設定、端末障害、感染端末など）	端末のネットワーク・時刻同期・クライアント更新状況を確認し、EDRアラートがあれば隔離も検討します。
同一フロア／同一拠点で複数台	拠点ネットワーク（無線、スイッチ、PROXY、回線）	拠点NWの死活、PROXY/FWログ、DNS疎通を優先確認します。
複数拠点で同時多発	Microsoft側障害／外部回線／認証基盤	管理センターのサービス正常性と外部監視の急増を照合し、社内変更がないかを再確認します。

影響範囲の目安と初動アクション

EDRでアラート検知された機器がある場合は、調査の前段としてネットワーク隔離を行い、マルウェアなど不審ファイルがあるときはEDR機能で取得・隔離を検討します。なお、フォレンジック調査を想定する機器は、取得操作の前に保全が必要になる点に注意します。

サービス正常性の見方

管理センターで障害を確認する手順

「今起きているのがMicrosoft 365側の障害か」を最短で判断するには、管理者がMicrosoft 365管理センターのサービス正常性を見に行く手順を標準化しておくことが重要です。公式情報を先に押さえることで、社内側の不要な切り戻し・設定変更を避けられます。

管理センターでの確認手順（サービス正常性）

管理者権限のアカウントでMicrosoft 365管理センターにサインインします。
「正常性」から「サービス正常性」を開き、対象サービス（Teams／Exchange Online等）の状態を確認します。
未解決のインシデント／アドバイザリがあれば、影響内容（対象ユーザー、影響機能、回避策）と更新時刻を読み、社内周知の材料にします。
管理センターに表示がなくても症状が広域な場合は、後述の外部監視・SNS情報で裏取りしつつ、サポートへの報告準備（発生時刻、影響ユーザー数、エラー画面等）を進めます。

障害か侵害かが曖昧なケースでは、管理センター確認と並行してメール監査ログ等の確認が必要になる場合があります（例：不審なメール転送設定の有無）。

現在の状態と履歴の違いを読む

サービス正常性では、「現在進行中の事象」と「過去に解決した事象」を読み分ける必要があります。現在の表示だけでは、回復傾向か悪化傾向か、再発パターンかの判断が難しいためです。

画面の読み分けで見る観点

現在の状態では、未解決のインシデント／アドバイザリの有無、影響範囲、回避策、更新時刻を追います。
履歴では、過去の経緯や根本原因の記載を確認し、今回の症状（例：サインイン不可、遅延、特定機能のみ不可）が既視感のあるパターンかを判断します。
切り分けにログが必要な運用であれば、最低3か月、望ましくは半年〜1年のログが参照可能か（検索の可否も含む）を、障害時に再確認します。

管理センターに出ていないとき、いつ社内調査を優先し、いつMicrosoft報告に切り替えるか

管理センターに障害表示がない場合でも、実害が出ていれば「社内調査をどこまでやるか」「いつMicrosoft報告に切り替えるか」を決めておく必要があります。表示のタイムラグや、テナント局所の問題があり得るためです。

状況	優先する動き	理由
直近の認証・NW・セキュリティ設定変更の直後に発生	社内調査を優先	自社変更起因の可能性が高く、原因特定が速いことが多いです。
複数拠点・複数ユーザーで同時発生、外部監視でも報告増	Microsoft報告へ切替	自社要因だけでは説明しづらく、提供側調査が必要になる確度が上がります。
サインイン不審・転送設定など侵害兆候がある	封じ込めと報告を並行	侵害時は時間経過で被害が拡大し得るため、パスワードリセット／アカウント無効化／セッショントークン強制リセット等の実施可否を先に確認します。

管理センターに出ていない場合の切替基準（例）

特に侵害疑いでは、攻撃者が盗んだ認証情報を悪用してもクラウドにアクセスできない状態（例：2要素認証の有効化）を作れているかが、影響最小化の重要ポイントになります。

Microsoft 365の情報源を広げる

公式ステータスと地域情報を照合する

障害の全体像は、公式ステータスだけでなく、テナントや地域に紐づく情報と突き合わせて判断します。グローバルでは軽微でも、自社の接続地域や経路に局所化すると業務影響が大きくなります。

照合のしかた（実務）

管理センターのサービス正常性で、対象サービスのインシデント／アドバイザリを確認します。
自社ネットワークの出口（PROXY／FW）を跨いだ通信経路の実態を押さえ、想定外経路（例：ExpressRoute等でPROXYを経由しない経路）がある場合は影響判定に織り込みます。
地域限定の影響が疑われるときは、拠点別に「同一操作で再現するか」を取り、拠点差が出るかで仮説を絞ります。

Downdetectorなど外部監視を使い分ける

外部監視サイトは、公式発表のタイムラグを埋める補助線として有効です。ただしユーザー投稿ベースのため、単独では確定情報になりません。調査のトリガー、影響範囲の当たり付けに使い、最終判断は管理センターや自社観測と突き合わせます。

外部監視の使いどころ

直近24時間など短い時間窓で報告がスパイクしているかを見て、広域事象の可能性を推定します。
地域分布の偏りがある場合、地域障害・経路障害の仮説を置きます。
社内のPROXY/FWログや端末観測と突き合わせ、単なる体感投稿ではなく自社影響に繋がるかを確認します。

日本だけの報告急増と海外同時多発で、テナント影響か地域障害かを切り分ける

「日本だけ急増」か「海外でも同時多発」かは、復旧見通し・代替策の選び方に影響します。日本だけなら国内経路や接続点の問題、海外も同時ならサービス基盤側の問題の確度が上がります。

観測	推定しやすいこと	社内の次アクション
日本の報告のみ突出	国内経路・国内接続点の影響の可能性	拠点別再現性、回線/PROXY経路差、ISP障害の有無を確認します。
海外でも同様の報告が同時多発	基盤側・広域障害の可能性	管理センター更新待ちと並行で、周知・代替運用（電話、別チャネル）へ移行準備します。
特定テナントだけ影響が濃い	構成変更・ポリシー・侵害対策の影響の可能性	直近のポリシー変更、セッショントークン強制リセットの実施有無、アカウント状態を確認します。

報告傾向からの推定（確定ではない）

Xで障害情報を確かめる

X検索で速報を集める観点を絞る

X（旧Twitter）は、公式発表より早く「同じ症状の人が増えている」兆候を見つけられる場合があります。ただしノイズも多いため、検索観点を固定して情報収集の質を上げます。

検索語の作り方（例）

「Teams 障害」「Outlook 送受信できない」「Microsoft 365 サインインできない」のようにサービス名＋症状で検索します。
「エラーコード」「認証」「MFA」「条件付きアクセス」など、原因に近い語を追加して絞り込みます。
投稿から拾うのは、再現条件（地域、回線、端末種別）や具体的なエラー表示で、感想だけの投稿は一次切り分けでは重視しません。

投稿の真偽と影響範囲を見極める

SNS情報は、真偽や鮮度のブレが大きい前提で扱います。特に企業アカウント運用では、乗っ取りや誤情報拡散のリスクがあるため、障害時こそ情報統制が必要です。

真偽確認のチェックポイント

投稿時刻が現在の事象と一致しているか（過去事例の再掲でないか）を確認します。
同様の症状が複数投稿で独立に出ているか、地域や回線が偏っていないかを見ます。
「設定を変えれば直る」系の断定は、管理センター情報や自社検証が取れるまで社内展開しません。
公式／従業員個人アカウントいずれも、ID・パスワードの使い回しや2段階認証未設定は乗っ取りリスクを高めるため、緊急時の発信権限・手順を平時に決めておきます。

主要サービスの影響と初動対応

Teamsとメールで起きやすい不具合

Teamsとメール（Exchange Online）は業務影響が大きいため、起きやすい不具合を「障害」と「侵害疑い」の両面で見立てられるようにします。特にメールは、障害でも侵害でも「届かない」「遅れる」「勝手に転送される」など見え方が似るため、ログで裏取りできる設計が重要です。

代表症状と切り分け観点

Teamsで会議作成・参加不可や音声品質劣化が出る場合、Web版で再現するかで端末依存かを当てます。
メールの送受信遅延やタイムアウトが出る場合、管理センターのExchange系インシデントの有無と、自社回線・PROXY経路の影響を並行確認します。
「身に覚えのないメール転送設定」などが疑われる場合、障害として片付けず、監査ログ（メールボックス監査）で確認できる体制があるかを見直します。

メンテナンス起因の不具合に備える

計画メンテナンスや仕様変更は、環境依存の不具合を誘発することがあります。情シスが内製でない企業ほど、事前通知を見落とすと「突然動かない」状態になりやすいです。

平時に備える確認項目

管理者はメッセージセンター等で、認証方式変更・機能廃止・接続要件変更の情報を定期的に確認します。
Firewall／PROXYの設計が前提の環境では、PROXYを迂回できる経路（例：ExpressRoute等）があると検知や制御が想定通りにならないため、経路の棚卸しを行います。
EDR導入をこれから検討する場合、参照情報として「決裁・検証で導入まで早くて1か月、遅いと数か月かかることがある」点を織り込み、障害時の代替手順（隔離手順、連絡網）を先に整備します。

ユーザー周知と業務継続策を整える

大規模障害時の混乱は「情報不足」と「代替手段不在」で拡大します。周知は、障害そのものよりも問い合わせ爆発を抑える効果が大きいため、テンプレートと代替手順を平時に固めます。

BCP観点で事前に決めること

代替連絡手段（電話、別チャット等）を確保し、定期的に接続テストします。
オフサイト・バックアップがある業務は、処理能力が業務継続に足りるかを業務部門と連携してテストし、性能面のボトルネックを把握します。
オフサイト・バックアップがない業務は、手作業処理や切替え時の追いかけ入力・照合を手順に含めます。
災害等では「モノ」「情報」があっても「ヒト」が参集できない場合があるため、重要業務に必要な要員とスキルを見積もり、拠点分散（デュアルオペレーション）などの分散策を検討します。

会議停止・メール遅延・認証障害で変えるべき社内周知文の出し分け

周知文は、現象に合わせて行動を具体化しないと逆効果になります。特に認証障害では、ユーザーが設定変更や再試行を繰り返して状況を悪化させやすいため、やってはいけない行動まで含めて書き分けます。

障害タイプ	周知で必ず入れる要素	避けたい表現
会議停止（Teams会議不可）	代替手段（電話等）への切替え、会議作成・参加の保留、影響範囲	「各自で色々試してください」
メール遅延（Exchange遅延）	遅延の前提、緊急連絡は別手段、送受信確認の注意	「メールは復旧しています（未確認）」
認証障害（サインイン不可）	設定変更の禁止、再試行の注意、復旧待ちの行動、問い合わせ窓口	「パスワードを何度も変えてください」

周知文の出し分け（要素）

侵害疑いがある場合は、周知文に「パスワードリセットやアカウント無効化を実施する可能性」と、その際の影響（再サインインが必要等）を織り込むと現場混乱を抑えられます。

復旧後の記録と運用改善

復旧までの経緯を記録して残す

復旧直後は、次回に効く情報が最も揃っています。障害報告書は「原因分析」だけでなく、切り分けの意思決定が後追いできる粒度で残します。

記録に残す具体項目

検知時刻、最初の報告者、影響サービス、影響ユーザー数（概数でも可）、拠点を時系列で整理します。
管理センター確認の時刻と、インシデント／アドバイザリ表示の有無、更新内容を記録します。
侵害疑いがあった場合、パスワードリセット／アカウント無効化／2要素認証の有効化状況／セッショントークン強制リセット実施の有無を、実施者と時刻付きで残します。
EDRアラートが絡んだ場合、端末のネットワーク隔離、不審ファイルの取得・隔離、保全の有無を残します。

障害履歴をBCPと監視体制に反映する

障害履歴は、BCPと監視設計に落とし込んで初めて価値が出ます。特に「見えていなかった」ことを減らすため、ログ・監視の前提を更新します。

反映で見直すポイント

調査に必要なログが、最低3か月、望ましくは半年〜1年保管できていたか、すぐ検索できたかを検証し、不足があれば保管・検索性を改善します。
PROXY/FWで既知の不正通信先をブラックリスト登録し、ブロックログから機器を特定できる運用になっているかを点検します。
Active Directory環境は侵害拡大の標的になりやすい前提で、監視を強化し早期発見の可能性を上げます（必要に応じてAzure ATP等の選択肢を検討します）。
ログのカラム（出力されるデータ項目）の意味を運用側が理解できているかを確認し、読めないログを増やさないようにします。

次回に備え、情シス・管理部・経営層でいつ何を報告するかを事後に決め直す

次回の初動を早くするには、事後に「誰が誰へ何を出すか」を決め直し、テンプレート化するのが実務的です。技術詳細をそのまま上げるのではなく、判断に必要な情報に要約する役割分担が重要です。

宛先	最低限の報告内容	更新頻度の例
管理部（総務・人事・法務等）	影響サービス、影響範囲、代替手段、社内周知の文面案	状況変化時に更新します。
経営層	業務停止の範囲、顧客影響の有無、復旧見込み、追加コスト見込み（発生していれば）	節目（拡大・収束）で更新します。
情シス内	切り分け結果、次アクション、実行禁止事項、ログ取得・保全の状況	作業単位で更新します。

報告ルールを決め直す観点

侵害が疑われる場合は、封じ込め（例：アカウント無効化やセッショントークン強制リセット）が業務影響を伴うため、管理部・経営層への報告条件を明確にしておくと判断が速くなります。

よくある質問

Microsoft 365の障害情報は一般ユーザーでも確認できますか？

一般ユーザーは、管理センターのサービス正常性画面にアクセスできないのが通常です。管理センターは組織の構成・ユーザー管理を扱うため、管理者ロールが必要です。

一方で、一般ユーザー側でも「社内起因ではない可能性」を当たり付けることはできます。たとえば、同僚にも同様の症状が出ているか、拠点差があるかを確認し、情シスに伝える情報（発生時刻、エラー表示、影響範囲）を揃えると切り分けが早まります。

Microsoft 365にログインできないとき、障害かアカウント問題かを見分けるには？

ログイン不可は、障害・設定変更・アカウント侵害対策が同じ症状になりやすいため、比較で切り分けます。特に侵害対策としてパスワードリセットやアカウント無効化、セッショントークンの強制リセットを行うと、正規ユーザーも一斉にサインインを求められるため、事前周知がないと障害と誤認されやすいです。

切り分けの観点

同一組織で複数ユーザーが同時に同じ認証エラーになるかを確認します。
直近で2要素認証や条件付きアクセスを変更していないかを確認します。
侵害が疑われる兆候（身に覚えのない操作、転送設定など）がある場合は、障害ではなくインシデントとして扱い、封じ込め（パスワード変更等）を優先します。

Downdetectorの報告増加は、すぐ社内周知すべきですか？

報告増加だけを根拠に全社周知すると、誤報や過剰反応で問い合わせが増えるリスクがあります。外部監視はユーザー投稿ベースのため、まずは社内で再現性と影響範囲を確認し、管理センター情報と照合してから周知するのが安全です。

実務での扱い方

外部監視の急増は「調査開始のトリガー」として扱います。
自社の複数ユーザー・複数拠点で再現するかを確認します。
周知に切り替える場合は、ユーザーに求める行動（代替手段、やらないこと）をセットで出します。

Microsoft 365の判断に必要な要点

Microsoft 365障害の切り分けは、公式障害・社内起因・端末個別のどれに近いかを、発生時刻・影響サービス・拠点の広がりといった一次情報で揃えることが出発点です。判断の軸としては、管理センターのサービス正常性を先に確認し、直近の認証・NW・セキュリティ設定変更や侵害兆候（不審サインイン、転送設定等）と突き合わせて、社内調査とMicrosoft報告の切替基準を持つことが重要です。あわせて、最低3か月（望ましくは半年〜1年）のログが参照できるかは、障害・侵害いずれでも調査の詰まりどころになりやすいため、平時に点検しておくべき前提条件になります。次アクションとしては、周知文の出し分け（会議停止・メール遅延・認証障害）と代替手段の準備をセットで整え、必要に応じて情シス・管理部・経営層の報告ルールを見直します。個別環境の設計や権限、インシデント対応の要否で最適解が変わるため、迷う場合は社内の責任者や外部の専門家に相談しつつ進めるのが安全です。