01 仕事は、つながっている。
本LPは公開情報の分析です。公式公開ページを実ブラウザで取得した時刻は2026年11月14日12:40 JST。掲載されていた更新時刻は11月13日22:00:36 UTC（11月14日07:00:36 JST）です。取得時刻と情報自体の更新時刻を分けています。各テナントの管理センターや個別ログは確認していません。
このページの全文をテキストで読む
- 現在地｜公式情報
- 公式はサービス低下の表示を継続。
復旧の持続性とメール滞留の処理を監視。
「正常化の兆候」と「完全解消」は分けて読む。 - 何が影響を受けたか
- Exchange Onlineを利用するメール・予定表と、
それに依存するMicrosoft 365の一部機能。
各サービスの全機能が停止したわけではない。 - 業務をつなぐ判断材料
- 影響サービス／日本時間の時系列／AI連携の波及
原因の確認範囲／初動／代替運用／復旧判定
事実・分析・推奨を分けた12枚の実務レポート。 - 調査対象
- EX1550543 / MO1550821
情報確認：2026年11月14日 12:40 JST
独立した解説資料。Microsoft公式資料ではありません。
図表のテキストを読む
- 影響の区分
- Exchange Online／メール／予定表／その他の一部機能
- 時系列の概要
- 発生（確認）→復旧に向けた対応→現在（監視継続）
- 状態を読む際の注意
- 「正常化の兆候」と「完全解消」は異なるため、公式情報の更新を続けて確認してください。
02 復旧は進む。監視は続く。
時系列は日本時間（UTC+9）に統一しています。Anthropicの事象の影響期間は、11月12日16:03 UTC〜11月13日16:40 UTC（JSTでは11月13日01:03〜11月14日01:40）と後から説明されています。初回調査投稿は11月12日17:52 UTCなので、投稿時刻と障害の影響開始時刻には差があります。順番は説明上のグループ化で、全イベントの発生順ではありません。公式ページの次回更新予定は取得時点で経過済みであり、更新内容の掲載を確認できたという意味ではありません。
このページの全文をテキストで読む
- 11/13 02:00頃 JST｜国内の影響
- 宮崎大学はポータル、Teams、Outlook、
Copilotのログイン異常等の可能性を告知。
これは同大学が示した発生期間に基づく。 - 11/13 02:52 JST｜外部にも波及
- AnthropicがMicrosoft 365コネクターを調査。
メール・検索・予定表などの要求に失敗。
開始時刻の説明は後の解消報告で更新された。 - 11/14 06:49 JST｜外部側は解消報告
- Anthropicは同コネクターの事象をResolvedに。
ただしMicrosoft側の復旧は継続中と説明。
外部連携の解消を全体復旧と読み替えない。 - 11/14 07:00:36 JST｜公式掲載更新
- Microsoftは継続的な回復を確認し、長めの監視へ。
メール滞留が正常に処理されるかも確認。
多くの依存機能の影響は対処済みとの認識。 - 11/14 12:40 JST｜本レポート確認
- 公開ページの表示はService degradation。
ページ記載の次回予定は11/14 11:30 JST。
予定時刻経過だけで状態変更とは判断できない。
03 ひとつの基盤から、複数の業務へ。
公式の列挙は、Exchange Onlineやメールサービスとの相互作用を持つ機能を対象にしています。したがって「影響サービスの一覧に名前がある」ことは、そのサービスの全機能・全利用者が停止したことを示しません。自社への影響を把握するときは、会議参加、会議招待、ファイル閲覧、外部共有、ラベル付き出力のような操作単位に分解します。依存先の異なる経路を準備することが業務継続上の論点です。
このページの全文をテキストで読む
- 中心｜Exchange Online
- Outlookのメールボックス接続や配信が不安定。
ブラウザ、デスクトップ、モバイルの接続を含む。
画面が開いても、送受信の完了は別に確かめる。 - 連携｜Teams・Copilot・Graph
- 予定表・会議招待、業務データを使うAI応答、
メール・予定表・連絡先を扱うAPIへ影響。
アプリが違っても共通の依存先があり得る。 - 管理・保護｜Purview・Defender
- 情報保護、ラベル、DLP、監査や管理画面など、
保護と運用の判断に関わる機能にも影響。
「メールだけの障害」とは整理しきれない。 - 文書・出力｜SharePoint・Power BI
- 外部共有や依存機能、ラベル付きの出力など、
特定の操作で障害が出るケースが記載された。
全ファイルへのアクセス停止とは区別する。 - 分析｜把握する単位を変える
- サービス名 → 機能 → 業務 → 代替手段で棚卸し。
どこが止まったかと、何を続けられるかを整理。
図の線は理解のための整理で、原因の断定ではない。
図表のテキストを読む
- メール
- 送受信・配信・メールボックス
- 予定表
- 予定・会議招待・スケジュール連携
- AI
- AI応答・データ連携・API
- 管理
- 情報保護・ラベル・DLP・監査・管理画面
- 凡例
- 中心＝基盤となるサービス。連携先＝主な影響領域の例。依存関係＝影響が広がるつながりの例。
04 使える機能を、切り分けよう。
TeamsではLive／Virtualイベントの作成、連絡先の追加・同期、アプリチャットへの移動、プライベート／共有チャネルの作成・削除にも影響が記載されています。これを既存会議すべての参加不能と解釈しないようにします。SharePointは組織・サイトの双方で外部共有を許可している場合の一部操作に関する記載です。代替手段が使えるかは組織の設定と実際の操作で確認します。
このページの全文をテキストで読む
- Outlook／Exchange Online
- 影響：メールボックス接続、メール配信の遅延。
Web、デスクトップ、EAS、REST接続を含む。
復旧確認：社内・社外の送受信を別々に確認。 - Teams
- 影響：予定表、招待、会議編集などの依存機能。
公式では通話・会議参加・通常チャットの大半と、
標準チャネルは影響対象外と説明されている。 - SharePoint Online
- 影響：許可されている外部共有の一部や依存機能。
保存ファイルへの直接アクセスは機能すると説明。
共有リンク発行と既存ファイル閲覧を分けて検証。 - Copilot 365
- チャットの読み込み・応答や、業務メール、
予定表、ファイル等へのアクセスに影響。
回答の有無だけでデータ参照の健全性を判断しない。 - 推奨｜連絡は到達確認まで
- 急ぎの案件は、承認済みの電話等で補完する。
繰り返し再送する前に、保留・遅延・重複を確認。
個人アカウントへの業務情報転送は避ける。
05 守る機能にも、影響が及ぶ。
公式はFabricの一部操作について、組織のデータ保護ポリシーで許可される場合に限りラベルを外す回避策に触れています。本LPはこれを一般的な推奨手順にはしません。障害を理由とした一律の保護解除は、組織内の承認や取り扱い規則を欠くおそれがあるためです。また、今回の公開情報のみでは情報漏えいの有無や各社の監査ログ欠落を判定できません。障害の事実から侵害を推定しないよう区別します。
このページの全文をテキストで読む
- Purview｜情報保護・監査
- DLP、ラベル、自動ラベル、権限管理、
監査検索、eDiscoveryなどに影響の記載。
障害中に確認できない情報は未確認として残す。 - Defender｜可視性・統制
- ポータルやタブの読み込み、保護情報を使う
評価・ガバナンス処理などに遅延や失敗。
画面の空欄を「脅威なし」の根拠にしない。 - Fabric／Power BI｜ラベル付き操作
- 秘密度ラベルを伴う出力や更新などに影響。
PDF・PowerPoint出力を含む特定の操作が対象。
機密ファイルの保護を外す判断は独断でしない。 - Windows 365｜条件付きの影響
- Purview Customer Keyを使う構成では、
Cloud PCへ接続できない利用者が出る可能性。
Windows 365全利用者の停止とは限らない。 - 推奨｜例外操作を記録する
- 責任者・理由・対象・期限・復元手順を残す。
保護を弱める回避より、承認された代替を優先。
復旧後は操作履歴と未処理の保護業務を確認。
06 管理画面の外にも、見落としがある。
Power Apps／Field Serviceについて、公式はサインイン済み利用者がサインアウト、アプリデータ削除、再インストールを避けることで影響を回避できる可能性を挙げています。これは対象アプリの条件付きの説明です。全製品で再起動・再認証を禁じる意味ではありません。自動化の再実行は重複処理を起こすことがあるため、実務上は処理ID・完了状態・再試行回数を確認してから行います。この再実行判断は本レポートの推奨です。
このページの全文をテキストで読む
- 管理センター／Microsoft 365 Apps
- 管理ページの一部、Cloud Update、Cloud Policy、
Inventoryなどに影響。最近使ったファイルの
表示も対象。管理画面の可用性も監視に含める。 - Graph API
- メール・予定表・連絡先の取得がタイムアウト。
Teams関連の管理や通知にも影響の記載。
連携ジョブは成功・失敗・処理待ちを分けて記録。 - Intune／教育機能
- 登録・チェックイン・準拠ポリシーの一部が不安定。
教育では課題、Reading Progress等に影響。
端末や課題の個別不具合と即断しない。 - Planner／To Do／Universal Print
- タスク操作、アプリ読み込み、印刷ジョブや
管理機能にも失敗が記載されている。
未反映タスクと未出力文書を別に確認する。 - Power Apps／Field Service
- モバイルのサインインが断続的に不安定。
公式はWeb版が回避手段になる場合を説明。
既存サインインの維持が有効なケースもある。
07 AIも、接続先に依存する。
この事例で確認できるのは、Anthropicが自社のMicrosoft 365コネクターとClaude for Outlookに対して説明した影響です。Claude全体や、他社AIのすべての障害の原因を説明するものではありません。BCPでは、代替ツールが利用する認証・メール・文書保存・ネットワーク・通知先を点検します。異なる製品でも共通の依存先が残る場合がある、というのが本レポートの分析です。
このページの全文をテキストで読む
- 一次情報｜Anthropicの事例
- Microsoft 365コネクターとClaude for Outlookで、
メール・予定表・検索の多数の要求が失敗。
上流のMicrosoft 365障害に起因すると説明。 - 影響期間｜後日の説明
- 11/13 01:03 → 11/14 01:40 JST
これはAnthropicが説明した当該連携の期間。
Microsoft 365全体の障害期間を表してはいない。 - 解消報告｜11/14 06:49 JST
- AnthropicはResolvedとした一方、Microsoftの
復旧継続に伴う一時的な遅延等の可能性も説明。
接続側の状態と接続先の状態は個別に追う。 - 分析｜代替AIだけでは足りない
- AIを変更しても、参照するメールや予定表が
同じ基盤なら業務は回復しないことがある。
代替は「アプリ名」だけでなく依存先で考える。 - 注意｜別の障害を混ぜない
- 同日に起きたAIサービス側の別事象を、
すべてMicrosoft 365起因と結び付けない。
コネクター事象の報告だけを根拠に整理する。
図表のテキストを読む
- 接続先の概念図
- ユーザー → AIアシスタント → Microsoft 365データ
08 原因は、断定を急がない。
最終原因の確定には事後報告や管理センターの詳細が必要です。本LPでは、取得できた公開ページの現状説明にない過去の技術的経緯を確定事実として再構成しません。障害で接続できないこと、データが消えたこと、不正アクセスがあったことは別の事象です。現時点で未確認の項目は未確認と表示し、根拠が揃ったときに更新できる構成とします。
このページの全文をテキストで読む
- 確認済み｜取得した公式説明
- サービスは継続的に回復し、長めの監視を実施。
メール滞留を処理し、多くの依存機能は対処済み。
影響範囲の説明はExchange Online依存を区別。 - 未確認｜最終的な根本原因
- 取得した最新表示だけでは、確定した原因分析や
事後報告の内容までは確認できない。
設定変更・容量不足等を最終原因として断定しない。 - 未確認｜規模と損害
- 全世界の停止人数、各社の損失、情報消失、
全テナントの復旧時刻は確認していない。
投稿数や障害報告数を被害人数に置き換えない。 - 分析｜復旧に時間差が生じる理由
- 接続回復、安定稼働、滞留処理、依存機能確認は
それぞれ別の確認事項として扱う必要がある。
これは運用上の整理で、公式の原因説明ではない。 - 今後確認すること
- 事後報告の起点・変更内容・検知と緩和の経緯。
再発防止策と、自社の業務停止に関係する依存先。
暫定説明は更新履歴を残して差し替える。
09 最初の対応を、5つに。
記録の最小項目は、日時・影響業務・機能・対象範囲・確認方法・結果・担当者・次回確認時刻です。利用者に無関係な操作を一斉実施させる前に、公式の対象機能と自社の症状を確認します。電話や別のチャットも、組織が承認した範囲で使用し、個人のメールアドレスへ情報を移す前提にはしません。
このページの全文をテキストで読む
- 01｜切り分ける
- 公式ステータスと自社の症状を突き合わせる。
部署・地域・端末・操作・発生時刻を記録。
社内原因とサービス側原因の両方を保留できる形に。 - 02｜連絡する
- 障害の対象・利用できる機能・代替連絡先・
次の社内更新時刻を、承認済みの経路で周知。
止まっているメールだけに連絡を依存しない。 - 03｜優先順位を決める
- 顧客連絡、期限付き申請、重要な承認を先に整理。
待てる作業と継続が必要な作業を分ける。
代替操作の責任者と完了の記録場所を決める。 - 04｜情報を保全する
- エラー時刻、処理ID、送信結果、未反映を残す。
未送信データやローカル編集は保存を確認。
再送・再実行による二重処理も点検する。 - 05｜復旧確認を用意する
- 社内外メール、予定表、共有、連携処理の
代表ケースを決め、結果を同じ記録表に集める。
「使えた人がいる」だけで全社復旧にしない。
図表のテキストを読む
- 5つの行動の目的
- 業務継続
10 代替手段は、業務から選ぶ。
代替手段の候補は、実行可能性・情報の機密性・期限・記録の残しやすさ・復旧後の戻し方で比較します。クラウド障害中に新しい製品へ移行することが常に最適とは限りません。認証や承認に同じMicrosoft 365基盤を使う代替は、独立した経路になっていないことがあります。業務ごとに共通の依存先を確認する、という判断枠組みを示しています。
このページの全文をテキストで読む
- 顧客との連絡
- 支障：メールの未達・遅延。
代替：承認済みの電話や別経路で要件確認。
注意：担当・時刻・連絡済みの事実を残す。 - 会議・調整
- 支障：予定表、招待、編集の不具合。
代替：既存会議の参加可否と代替連絡を確認。
注意：Teamsの通話まで一律停止と決めつけない。 - 文書・承認
- 支障：共有や依存する操作の一部が不安定。
代替：承認された保存先と手動の承認記録。
注意：版の競合とアクセス権、後からの反映を管理。 - 自動化・帳票
- 支障：API・タスク操作・出力が不安定。
代替：処理待ちの一覧化と必要部分の手動対応。
注意：重複実行・二重送信・保護解除を避ける。 - 管理・セキュリティ
- 支障：管理画面や確認機能の一部が不安定。
代替：承認済みの連絡系統と既存の記録を活用。
注意：見えない時間を「問題なし」にしない。
11 「戻った」を、業務で確かめる。
公式の回復表示と自社の業務再開判断は異なる対象を確認しています。自社では、代表ケースの合否、継続観測の時間、未処理件数、例外操作の残件、責任者の承認を判断材料にします。数値の基準は業務の許容度に合わせて決めます。本LPに一律の待機時間・可用性・復旧保証を置かないのは、公開情報のみでは各組織の条件を決められないためです。
このページの全文をテキストで読む
- 01｜メールの往復
- 社内・社外の送受信と遅延、未達通知を確認。
滞留メールが届く順番や重複にも注意する。
テスト用の非機密データを使う。 - 02｜会議とファイル
- 予定表の表示・招待・更新を代表ケースで確認。
共有・閲覧・編集など必要な操作も点検。
権限や端末による差を記録する。 - 03｜連携とタスク
- API要求、AIのデータ参照、タスク、帳票出力を確認。
止まったジョブの再開は完了状態と照合する。
一度の成功だけで安定と判断しない。 - 04｜保護と管理
- 管理画面、ラベル、DLP、監査等の必要操作を確認。
保留した確認と例外措置は担当者が回収。
セキュリティ設定を戻す必要も点検する。 - 05｜業務を通常運転へ
- 未処理・未達・重複の一覧を照合して解消。
部署ごとの責任者が復旧範囲を承認。
未確認を残す場合は対象と次回確認を明記。
12 次の停止に、備えを残そう。
Microsoft Learnは、管理センターの「正常性 → サービス正常性」で自社に関係する事象を確認し、管理センターへサインインできない場合は公開のサービス状態ページを利用する流れを説明しています。このLPからデータ送信や登録は行いません。ボタンはMicrosoftの公式ステータスへ遷移します。最新情報の確認に加え、組織内の担当者が自社への影響と代替運用を更新してください。
このページの全文をテキストで読む
- 平時に整える5つの備え
- 連絡網：メール以外の承認済み経路を準備。
業務一覧：許容停止時間と優先順位を整理。
依存関係：認証・メール・文書・AI・通知を棚卸し。 - 復旧後に残すもの
- 記録：未達・滞留・例外操作・手動対応を回収。
振り返り：検知・周知・代替・復旧判定を検証。
公式の事後報告と、自社で起きた事実を照合。 - 情報を追う順番
- 自社向けの管理センター「サービス正常性」。
入れないときはMicrosoftの公開ステータス。
外部連携の不具合は、その提供元の告知も確認。 - このレポートの前提
- 確認時点：2026/11/14 12:40 JST。
その後の状態は、公式情報で確認してください。
全機能停止・原因確定・復旧保証を意味しません。 - 主な一次情報
- Microsoft公式ステータス／Microsoft Learn
宮崎大学の障害告知／Anthropicの障害報告
詳細な分析と出典リンクはHTML版に収録。
図表のテキストを読む
- 事後確認5項目：連絡網
- 見るべき点：代替連絡の有無と承認済みの経路。
判断の基準：主要連絡が1つに依存していない。
次のアクション：メール以外の経路を準備し、周知と訓練を実施。 - 事後確認5項目：業務一覧
- 見るべき点：業務と許容停止時間、優先順位の整理。
判断の基準：重要業務の停止時間が許容範囲内。
次のアクション：業務一覧を更新し、優先順位を再確認。 - 事後確認5項目：依存関係
- 見るべき点：認証・メール・文書・AI・通知の依存。
判断の基準：依存先と影響範囲が可視化されている。
次のアクション：依存関係を棚卸しし、代替手段を検討。 - 事後確認5項目：記録
- 見るべき点：未達・滞留・例外操作・手動対応の有無。
判断の基準：影響と対応の事実が抜けなく記録されている。
次のアクション：記録を整理し、再発防止に活用。 - 事後確認5項目：振り返り
- 見るべき点：検知・周知・代替・復旧判定の妥当性。
判断の基準：一連の対応が適切で改善点が明確。
次のアクション：検証結果を反映し、手順と連絡体制を見直し。
出典と確認範囲
取得時点の公式表示は復旧継続・監視中です。最新状況は公式ページで確認してください。原因の確定、全利用者の停止、全社の復旧完了を示す資料ではありません。対応案は本レポートの推奨です。写真はAIで生成した概念表現です。
- Microsoft service health status
公式ページの本文と詳細フレームを2026/11/14 12:40 JSTに実ブラウザで取得。掲載更新2026/11/13 22:00:36 UTC。取得資料：status-source.txt・status-source.png。
- 宮崎大学 情報基盤センター：Microsoft365の障害発生について
2026年11月13日付。国内の影響認識の一次情報。同大学の告知であり全世界の正確な発生時刻を示すものではない。
- Anthropic：Elevated errors affecting the Microsoft 365 connector
解消報告2026/11/13 21:49 UTC。連携固有の事象の期間とMicrosoft側の継続復旧を区別。
- Microsoft Learn：How to check Microsoft 365 service health
管理センターの確認と、入れないときの公開ステータスの利用方法。
