Blog
ブログ
Teams障害が起きたとき情シスは何を確認する？原因切り分けと初動対応
2026.10.09
「Teamsでメッセージが送れない」「会議に参加できない」「ファイルが開かない」。
朝一番に現場から問い合わせが殺到した際、情シスが真っ先にすべきことは、設定をいじることでも端末を再起動させることでもありません。「障害の範囲と原因を正確に切り分けること」です。
この記事では、Teams障害発生時に情シスが確認すべきポイント、Microsoft側の障害か自社環境の問題かを見極める方法、そしてユーザーへの迅速な初動対応のフローを実践的に解説します。
結論：初動対応は「Microsoftか、自社か、個人の環境か」の切り分け
Teamsが使えなくなった場合、原因は大きく分けて3つのレイヤーに存在します。情シスは問い合わせに個別対応する前に、まずは以下の順番で全体状況を把握する必要があります。
- ステップ1：Microsoft 365 側の障害（M365管理センターの「サービス正常性」、X等での情報収集）
- ステップ2：自社のネットワーク・インフラ（社内プロキシ、VPN、特定の拠点だけの問題か）
- ステップ3：ユーザーの端末・アプリ環境（Teamsキャッシュ、OSのアップデート、ブラウザ版での動作確認）
- ステップ4：アカウント・ライセンス（対象ユーザーのEntra ID、ライセンス状態、条件付きアクセスのブロック）
大規模障害の場合は情シス側で直すことは不可能です。いかに早く「Microsoft側の障害です」と全社アナウンスを出し、ヘルプデスクのパンクを防ぐかが初動の鍵になります。
Teams障害時の情シスの役割とは？
TeamsはSaaS（Software as a Service）であるため、サーバーやバックエンドのシステムはMicrosoftが管理しています。そのため、システムそのものがダウンした場合、情シスにできるのは「復旧を待つこと」だけです。
しかし、現場のユーザーにとっては「Teamsが使えない＝業務が止まる」という一大事です。情シスの役割は、問題を自力で解決することではなく、原因を迅速に特定し、代替案（メールや別のWeb会議ツール等）を提示して業務影響を最小限に抑えることにあります。
情報がないままユーザーを待たせるのが一番の悪手です。「現在調査中」「Microsoft側の障害と判明、復旧待ち」といったこまめな情報発信が求められます。
切り分けを誤ると起こる“詰み”パターン
初動を間違えたときのトラブル
- 無駄なトラブルシューティング： Microsoft側のグローバル障害なのに、ユーザーに「アプリの再インストール」や「PCの再起動」を指示し、現場の時間を奪う。
- ヘルプデスクのパンク： 全社アナウンスが遅れたため、同じ内容の問い合わせ電話やメールが殺到し、情シスの業務が麻痺する。
- 重大な自社ネットワーク障害の見落とし： 「きっとMicrosoftの障害だろう」と放置していたら、実は自社のVPNやプロキシサーバーのダウンが原因だった。
焦って個別の対応を始める前に、「障害の範囲（全社か、一部か、1人か）」を見極めるルーティンが必要です。
よくある誤解の整理
よくある誤解（現場と情シスの認識ギャップ）
- 「Teamsが繋がらないから情シスで直して！」→ ❌（SaaSの障害はMicrosoft側での対応を待つしかありません）
- 「管理センターのサービス正常性がグリーンならMicrosoftは正常」→ △（管理センターへの反映が遅れることも多いため、X（旧Twitter）等のリアルタイム情報も確認が必要です）
- 「ファイルが開けないのもTeamsの障害」→ △（Teamsのチャットはできても、裏側のSharePoint/OneDriveがダウンしていてファイルが開けないケースがあります）
情シスが確認すべき4つのポイント（原因切り分け）
① Microsoft 365 側の障害確認（クラウドの問題）
- M365管理センターの「正常性」＞「サービス正常性」でインシデント情報を確認。
- X（旧Twitter）で「#Teams障害」「Microsoft 365 Status (@MSFT365Status)」を検索し、他社でも起きているか確認。
② 自社のネットワーク・インフラ確認（経路の問題）
- 社内のプロキシサーバーやファイアウォールで、Teams向けの通信（IP/URL）がブロックされていないか。
- VPN経由でのみ発生しているか（VPNの帯域逼迫やスプリットトンネルの設定漏れ）。
③ クライアントアプリ・端末の問題（環境の問題）
- 特定のユーザーのみの場合、Teamsアプリの「キャッシュクリア」を実施する。
- デスクトップアプリではなく、ブラウザ版Teams（Teams on the Web）でログインし、動作するか確認（アプリ側の問題かどうかの切り分け）。
④ アカウント・権限の問題（認証の問題）
- Entra IDのサインインログを確認し、条件付きアクセスでブロックされていないか。
- ライセンスの期限切れや、割り当てが外れていないか。
障害範囲ごとの原因と対応方針（比較表）
問い合わせを受けた際、まずは「どれくらいの人数に影響が出ているか」を把握することが重要です。
| 障害の範囲 | 想定される原因 | 切り分け方法 | 情シスの対応 |
|---|---|---|---|
| 全社（または広範囲） | Microsoft側の障害、自社のコアネットワーク（プロキシ等）の障害 | M365管理センター、SNS情報の確認。社外ネットワークから繋がるか。 | 即座に全社へメール等でアナウンス |
| 特定の拠点・部門 | 拠点ルーター、VPN、特定部門に適用したセキュリティポリシー | 他拠点のユーザーは正常か確認。ネットワーク機器のログ確認。 | ネットワーク部門との連携調査 |
| 特定の1名（または数名） | Teamsアプリの不具合、アカウントのライセンス切れ、パスワード失効 | ブラウザ版でログインできるか。Entra IDのサインインログ確認。 | 個別トラブルシューティング（キャッシュクリア等） |
障害発生時のリスクと対策（情シス向け対応表）
障害対応時に情シスが陥りやすいミスと、事前の対策です。
| リスク（事象） | 起きやすい状況 | 情シスが行うべき対策 |
|---|---|---|
| シャドーITの横行 | Teamsが使えないため、現場が勝手に個人のLINEや無料ツールで業務連絡を始める | 障害時の代替連絡手段（全社メールや会社指定の別ツール等）を事前にルール化しておく |
| M365管理センターへのアクセス不可 | Entra IDの認証障害が起き、情シス自身が管理センターにログインできず状況確認ができない | SSOやMFAに依存しない、非常用の「Break-glass（緊急アクセス）」アカウントを用意しておく |
| 連絡手段の喪失 | Exchange（メール）も同時に障害を起こし、全社アナウンスが送れない | 社内ポータルサイト（オンプレミス）や、一斉配信用の別システム（安否確認システム等）を活用する |
インシデント発生から復旧までの初動フロー
「Teamsがおかしい」という第一報を受けてから、情シスが動くべき標準手順です。
情シスの1日の運用例（大規模障害発生時）
例：朝9時に「Teamsでメッセージが送信できない」と複数から連絡が来た場合
- 09:00：問い合わせ急増。情シスメンバーもメッセージ送信遅延を体感。
- 09:05：M365管理センターを見るが「正常」表示。しかしX（Twitter）で「Teams 障害」がトレンド入りしているのを確認。
- 09:10：Microsoft側の障害と判断。全社メールで「現在Teamsに障害発生中。緊急の連絡はメールを使用してください」と第一報を送信。
- 10:30：M365管理センターにインシデント（TMxxxxx）が登録されたことを確認。適宜、社内へ状況をアップデート。
- 14:00：管理センターで「解決済み」表示。情シス内でテスト送信し、正常動作を確認。
- 14:15：全社へ「復旧のお知らせ」を送信。まだ繋がらないユーザーにはアプリの再起動を案内。
特徴：情シスの仕事は「直すこと」ではなく、「迅速な状況判断と的確な情報伝達」にシフトします。
30日 障害対応マニュアル整備ロードマップ
いざという時に焦らないため、平時に準備しておくべきステップです。
あなたの組織のインシデント対応準備度チェック
障害発生時に迅速に動けるか確認しましょう。
- 情シス担当者がM365管理センターの「サービス正常性」ダッシュボードをすぐに見られる権限を持っている
- Teamsが使えない時の全社アナウンス手段（メーリングリストなど）が確立されている
- 「アプリ版でダメならブラウザ版で試す」という切り分け手法をヘルプデスク全員が知っている
- Teamsのキャッシュをクリアする手順（Windows/Mac）をユーザー向けに案内できるマニュアルがある
「いいえ」がある場合は、まずはアナウンス用のメールテンプレートを作成しておくことをおすすめします。
対応に必要なスキルと知識
必須になりやすい領域
- Microsoft 365 管理センターの操作（サービス正常性の確認）
- Teamsのアーキテクチャ理解（チャット＝Exchange、ファイル＝SharePoint等）
- ネットワークの基礎知識（プロキシ、VPN、DNS、TCP/UDPポートの要件）
- OS（Windows/Mac）におけるアプリのキャッシュクリアと再インストール手順
役立つツール・情報源
日頃からチェックすべきリソース
- Microsoft 365 Status（Xアカウント）： @MSFT365Status（公式のリアルタイム障害情報）
- Downdetector： ユーザーからの障害報告を集計している外部サイト。管理センターより早く異変に気付ける。
- Microsoft 365 管理センター アプリ： スマートフォンに入れておくと、出先でもインシデント状況が確認可能。
障害対応ルールをどう整備するか？
初めて障害対応のルールを作る場合、完璧を求めず、まずは「パニックを防ぐ」ことを最優先にします。
おすすめの順番
目指すべき運用体制
- 障害時、情シスが原因究明に没頭するのではなく、広報（社内アナウンス）に徹する体制
- 現場が「情シスに言えばすぐ直る」と誤解しないよう、SaaSの特性を日頃から啓蒙しておく
高度なインシデント管理への展開
初動対応の仕組み化ができれば、より影響を最小限に抑えるプロアクティブな監視へ発展できます。
- 事後対応 → Microsoft Graph API 等を用いたサービス正常性の自動監視と情シスへのアラート通知（Slack/Teams以外の手段で）
- 障害発生時のBCP（事業継続計画）策定への貢献
よくある質問（FAQ）
全社的な問題でなければ、まずは「ブラウザ版Teams（Web版）」でログインして送信できるか確認させてください。ブラウザで送れるならデスクトップアプリの不具合（キャッシュの破損など）です。Teamsアプリからサインアウト→再サインインするか、キャッシュのクリア手順を案内してください。
そのユーザーのネットワーク環境（自宅のWi-Fiや、社内の特定フロアの無線LAN）が原因である可能性が高いです。有線LANへの切り替えや、Teams管理センターの「通話品質ダッシュボード (CQD)」でパケットロス等のデータを確認して原因を切り分けます。
自社のプロキシやファイアウォールで、Teamsが必要とするエンドポイント（URLやIPアドレス、UDPポート）の通信がブロックされたり、セッション数が上限に達したりしている可能性があります。ネットワーク担当者と連携し、Teamsの通信トラフィックが適切にバイパス（除外）されているか確認してください。
Teams障害発生時、情シスに求められるのは復旧作業そのものではなく、「影響範囲の迅速な見極め」と「全社への情報発信」です。
Microsoft側のグローバル障害であれば、ユーザーに無駄な作業をさせず、代替手段を案内することが最大の支援となります。
まずは“情シス内で、障害時の全社アナウンスのメールテンプレートを用意する”ところから始めてみてください。
※本記事は一般的な情報提供を目的としています。実際の障害対応にあたっては、組織のインシデント管理プロセスや運用規程に沿って対応を行ってください。
▼ITフリーランス・エンジニア案件をお探しの方
ジェイテックフリーランスへ →
▼ 採用情報はこちら
採用情報ページへ →
▼ Microsoft 365 / AI導入のご相談
お問い合わせフォームへ →