2026/08/05Copilot

導入・運用AI活用

Copilotの障害・稼働状況を確認する方法

「Copilotが急に応答しなくなった」「自分の環境が悪いのか、Copilotの障害なのか判断がつかない」——動かなくなった瞬間に一番知りたいのは、原因より先にこれは待てば直るのかです。

結論から言うと、稼働状況の確認先は決まっています。Microsoft 365管理センターのサービス正常性ページ、サインイン不要の公式サービス状態ページ、公式のSNSアカウント——この3つを見る順番さえ覚えておけば、毎回検索し直す必要はありません。

株式会社Fyveは中小企業のAI活用を支援しています。この記事は特定の日の障害を報じるものではなく、いつ何が起きても同じ手順で確認できるようにするための常設の手順書として書いています。

結論：確認は3ステップで固定する

障害が疑われるときにやることは、毎回同じです。順番を先に決めておくと、慌てずに済みます。

ステップ1：影響範囲を確認する——自分だけか、社内の複数人か。ここで方向が決まる
ステップ2：公式の稼働情報を見る——管理センターのサービス正常性、またはサービス状態ページ
ステップ3：出ていなければ社内側を疑う——ネットワーク・アカウント・端末を切り分ける

順番が逆になると時間を無駄にします。1人だけで起きている現象を障害情報で探しても、当然何も見つかりません。逆に社内の複数人で同時に起きているなら、個人の設定をいじる意味はありません。

いま開くページを1つだけ挙げるなら、公式のサービスの状態ページ（status.cloud.microsoft）です。管理者権限もサインインも不要で、管理センターに入れない状況でも見られます。まずここを開いてから、以下を読み進めてください。

ただし、このページだけで判断を終えないでください。テナント固有の問題はここには出ませんし、予定されていた変更もここには出ません。それぞれ見る場所が違います——本記事の後半で、その使い分けを整理します。

障害確認を影響範囲の特定・公式情報の確認・社内切り分けの3ステップで固定する流れ

①Microsoft 365管理センターの「サービス正常性」で確認する

組織で契約しているMicrosoft 365の稼働状況は、管理センターのサービス正常性ページで確認します。自分のテナントに影響している問題だけが表示されるのがこのページの価値です。

場所と必要な権限

公式ドキュメントによると、確認の入口は次の通りです。

Microsoft 365管理センター（admin.microsoft.com）に管理者アカウントでサインインする
左側のナビゲーションで「正常性」→「サービス正常性」に移動する。またはホームダッシュボードの「サービス正常性」カードを選択する

権限については、サービスサポート管理者とヘルプデスク管理者のロールが割り当てられている人はサービス正常性を表示できると明記されています。全体管理者でなくても見られる、という点は覚えておく価値があります。障害確認のためだけに全体管理者権限を配る必要はありません。

管理センターの画面構成は変更されることがあります。メニューの位置が記載と違う場合は、最新の公式ドキュメントで確認してください。

ページに表示される4つの区分

公式の説明では、サービス正常性ページは次のように構成されています。どこを見るかで意味が変わります。

概要タブ（既定のビュー）——すべてのサービス、現在の正常性状態、アクティブなインシデントまたはアドバイザリが表示される
「組織が処理する問題」——自社の環境で検出された、アクションが必要な問題。該当がなければこのセクションは表示されない
「Microsoftが取り組んでいるアクティブな問題」——Microsoftが解決に取り組んでいるインシデントとアドバイザリの一覧
「問題の履歴」タブ——過去7日または30日以内に解決されたインシデントとアドバイザリ

ここで重要なのが1つ目と2つ目の違いです。「組織が処理する問題」に出ているなら、Microsoftの復旧を待っても直りません。自社側でアクションが必要だという意味です。

インシデントとアドバイザリの違い

同じ「問題あり」でも、この2つは深刻度がまったく違います。公式の定義は次の通りです。

アドバイザリ——一部のユーザーに影響を与える問題は認識されているが、サービスは引き続き利用できる。多くの場合は回避策があり、問題が断続的だったり、影響範囲が限定的だったりする
インシデント——重大な問題で、サービスまたはサービスの主な機能が使用できない。ユーザーに顕著な影響を与える

社内に周知するときは、この区別をそのまま使うのが早いです。アドバイザリなら「使えるが不安定」、インシデントなら「使えない」——伝え方が変わります。

状態を表す言葉の意味

問題の詳細ページには、進行状況を示す状態が表示されます。公式が定義しているものを、実務で意味が大きい順に並べると次のようになります。

調査中——潜在的な問題は認識され、現状と影響範囲の情報を収集している段階
サービスの低下——使用に影響する可能性のある問題を確認済み。通常より遅い、一時的に中断する、一部機能が動かない、など
サービスの中断——問題がサービスへのアクセスを妨げると判断された状態。常に再現する
サービスの復元——原因が特定され、対応策が分かっており、正常な状態に戻している段階
拡張復旧——復旧作業は進行中だが、すべての環境に適用されるまで時間がかかる状態
サービスが復元されました——根本的な問題が解決し、正常な状態に戻ったことが確認された
調査の中断——潜在的な問題の詳細な調査にあたって、Microsoft側が利用者からの追加情報を求めている状態。必要なデータやログの提出を求められる
誤検知——調査の結果、サービスは正常で設計どおりに動作していたと確認された
インシデントの事後レポートを発行済み——根本原因と、同様の問題が再発しないようにするための次の手順を含むレポートが公開された状態

実務で意味が大きいのは、両端の2つです。「調査の中断」は自社がボールを持っている——待っていても進みません。逆に「インシデントの事後レポートを発行済み」は経営や現場への説明材料になります。同じ障害が再発したときに「前回はこう説明されていた」と参照できる形で残るのは、社内の納得感がまるで違います。

「調査中」の段階では復旧見込みは分かりません。この時点で社内に復旧時刻を約束しない——これは運用側の実務として大事な線引きです。

問題の詳細ページで確認する項目

一覧から問題のタイトルを選ぶと詳細ページが開きます。ここに何が載っているかを知っておくと、社内への周知文をそのまま組み立てられます。公式が挙げている項目は次のとおりです。

タイトル——問題の概要
ID——問題の数値識別子
最終更新時刻——サービス正常性メッセージの最後の更新時刻
推定開始時刻——問題が開始された推定時間
影響を受けるサービス——影響を受けるサービスの名前
問題の種類——重大度（インシデントまたはアドバイザリ）
問題の発生元——問題がMicrosoft側で見つかったか、自社の環境で見つかったかを示す
状態——現在の状態
ユーザーの影響——エンドユーザーへの影響の簡単な説明
すべての更新プログラム——解決に向けた進捗のメッセージ

周知に使うべきは「ユーザーの影響」と「推定開始時刻」です。前者は「何ができないのか」を、後者は「いつからの作業が影響を受けたか」を答えてくれます。技術的な詳細を転記するより、この2つを日本語で言い換えて流すほうが、現場は動けます。

もう1つ、見落としやすいのが「問題の発生元」です。ここが自社の環境になっているなら、待っていても直りません。前述の「組織が処理する問題」と同じ意味を持ちます。

更新の粒度は2種類ある

詳細ページに流れてくるメッセージにも種類があります。公式の定義では次の2つです。

簡単な更新——広範囲に影響を及ぼすインシデントに対して、短期間で頻繁に増分更新を行う。すべての利用者に提供される
追加の詳細——技術的な情報や解決方法の詳細を提供し、処理状況をより深く可視化する。Exchange Online監視と同じ要件を満たすテナントで利用可能

つまり、同じ障害でも会社によって受け取れる情報の深さが違います。「他社はもっと詳しい情報を持っているらしい」という話が出たときの答えがここにあります。

履歴と表示のカスタマイズ

復旧したあとの振り返りにも使えます。公式によれば、「問題の履歴」タブには過去7日または30日以内に解決されたインシデントとアドバイザリが表示され、履歴ビューでは過去30日間の履歴を確認できます。

「先月あたり、なんとなく不安定だった気がする」という曖昧な記憶を、事実に変えられるのはこの範囲までです。それより古い記録が必要なら、自社側で控えておくしかありません。障害のたびに日付とIDだけメモしておく——それだけで、契約更新時の判断材料になります。

また表示するサービスを絞ることもできます。公式は「カスタムビュー」から、ダッシュボードのビューに含めないサービスのチェックを外す手順を案内しています。使っていないサービスの通知に埋もれると、肝心なものを見落とします。監視対象は絞ったほうが機能します。

投稿は英語で書かれている

これは知らないと混乱します。公式は「サービス正常性投稿は、投稿する情報のタイムラインのために英語で書かれています」と説明しています。速報性を優先しているためです。

優先言語を英語以外に設定していると、投稿を自動翻訳するかどうかを切り替えるボタンが表示されます。ただしこれは機械翻訳であり、また優先言語の設定は各ユーザーが自分で行う必要があると明記されています。管理者がまとめて指定することはできません。

判断に迷う表現に当たったら、翻訳をオフにして英語のまま読むほうが確実です。社内に周知する文面を作るときは、なおさら原文に当たる価値があります。

②管理センターを開けないときの確認先

障害の内容によっては、管理センターそのものにサインインできないことがあります。この場合の代替手段も公式に案内されています。

サインイン不要の公式サービス状態ページ

公式ドキュメントは、管理センターにサインインできない場合の確認先としてサービスの状態ページ（status.cloud.microsoft）を案内しています。テナントにログインできない既知の問題を、サインインせずに確認できる位置づけです。

管理者アカウントを持たない一般の利用者でも見られるため、「まずここを見る」を社内の共通ルールにしておくと、問い合わせが減ります。ただしテナント固有の問題は表示されないため、ここに何も出ていないことは自社が無事である証明にはなりません。

公式SNSアカウント

同じく公式ドキュメントは、X（Twitter）の@MSFT365Statusを購読して特定のイベントに関する情報を確認するよう案内しています。速報性という点では、この経路が一番早く動くことがあります。

一方で、SNS上の一般利用者の投稿は扱いに注意が必要です。「自分も落ちている」という投稿が並んでいても、それぞれ原因が別ということは普通に起こります。参考にはしても、判断の根拠は公式の稼働情報に置いてください。

モバイルアプリという選択肢

公式は、モバイルデバイスのMicrosoft Adminアプリでもサービス正常性を表示でき、プッシュ通知で最新情報を入手できる、と案内しています。PCが使えない状況で確認できる経路を1つ持っておくと安心です。

③通知を設定して「先に気づく」ようにする

ここまでは起きてから調べる方法ですが、通知を設定しておけば順序が逆になります。問い合わせが来る前に把握できるのは、運用上かなり違います。

公式の説明によると、サービス正常性ページの「カスタマイズ」→「Email」から「サービスの正常性に関する電子メール通知を送信する」を選び、次を指定できます。

メールアドレスは最大2つ
インシデントの通知を希望するか、警告（アドバイザリ）の通知も希望するか
通知を希望するサービス

また、サービス全体ではなく個別の問題だけを追うこともできます。追跡したいアクティブな問題を選んで「この問題の通知を管理」から指定する形です。

設定は管理者アカウントごとに保持され、上記のメールアドレス2つという制限も管理者アカウント単位、と説明されています。担当者が1人しかいない会社では、その1人が休んだ日に誰も気づけません。複数の管理者アカウントで設定を分散させておくのが現実的です。

メッセージセンターのメールは別設定

ここを混同している会社が多い部分です。後述するメッセージセンターにも、サービス正常性とは別のメール通知があります。片方だけ設定して「通知は入れてある」と思い込むと、予定された変更の告知だけが誰にも届きません。

公式によると、メッセージセンターの週次ダイジェストは既定でオンになっており、プライマリのメールアドレスに届きます。設定は「ユーザー設定」の「Email」タブから行い、こちらも最大2つのメールアドレスをセミコロンで区切って指定できます。

さらに、ダイジェストとは別枠で制御されるものが2つあると明記されています。

メジャー更新プログラムのメール通知——週次ダイジェストとは別のチェックボックスで制御される
データプライバシーメッセージのメール通知——同じく別制御。公式は「データプライバシーメッセージは週次ダイジェストには含まれません」と注記しています

つまり週次ダイジェストをオンにしただけでは、重要な2種類が漏れる設計です。ここは一度、管理者アカウントごとに設定を開いて確認しておく価値があります。

もう1点。公式は「週刊ダイジェストやメールで送信されるその他の投稿は英語でのみ提供されます」と記載しています。画面上は日本語で読めても、メールは英語で届くということです。受け取ってから翻訳する前提で運用を組んでください。

プログラムから取り込むという選択肢

通知メールが埋もれるなら、届ける先そのものを変える手もあります。公式は、リアルタイムのサービス正常性情報とメッセージセンター通信をプログラムから取得する方法としてMicrosoft Graphのサービス通信APIを案内しています。

ここは踏み込みすぎない書き方をします。私はこの実装をCopilot向けに手がけたわけではありません。ただ、社内の連絡がチャットに集約されている会社では、メールより既存のチャットへ流すほうが確実に読まれる——という一般則は、他のツールでも繰り返し確認してきたことです。

やるとしても順番があります。まず人の運用で回してみて、それでも見落とすなら自動化する。最初から仕組みを作ると、通知だけが届いて誰も見ない状態になりがちです。

「障害情報に出ていない」ときの読み方

確認して何も出ていなかった場合、そこで終わらせないでください。出ていない理由は3つ考えられます。

まだ検知されていない

障害の発生と、それが「調査中」として掲示されるまでには時間差があります。出ていない＝正常、とは限りません。10分後にもう一度見る価値があります。

計画メンテナンスはサービス正常性に出ない

これは知らないと必ず誤解します。公式は「計画済みメンテナンスイベントはサービス正常性には表示されません」と明記し、追跡にはメッセージセンターを確認するよう案内しています。「変更の計画」として分類されたメッセージに絞り込めば、いつ変更が起き、どんな影響があり、どう準備するかが確認できるという説明です。

つまり、「予定されていた変更」と「予期しない障害」は見る場所が違います。片方だけを見て「何も起きていない」と判断すると、原因を見落とします。メッセージセンター側の見方は、次の節でまとめます。

自社だけで起きている

広範囲の障害ではなく、自社の環境に起因している可能性です。公式は、Microsoft 365のサービスで問題が発生していてサービス正常性ページに一覧されていない場合、「問題を報告する」から短いフォームに記入できると案内しています。報告された内容は他組織の関連データと照合され、該当すれば新しいインシデントまたはアドバイザリとして追加されるという流れです。報告した問題とその状態は「報告された問題」タブで確認できます。

予定された変更はメッセージセンターで確認する

ここが本記事でもっとも見落とされやすい部分です。「障害は出ていないのに、先週までと挙動が違う」という相談の答えは、たいていメッセージセンター側にあります。

サービス正常性が「予期しない障害」を扱うのに対し、メッセージセンターは「予定されている変更」を扱います。新機能の追加、既存機能の更新、廃止、そして計画メンテナンス——影響が出るものはすべてこちら側に事前告知されます。

場所と、見られる人・見られない人

公式によると、入口は管理センターの「正常性」→「メッセージセンター」です。サービス正常性と同じ階層に並んでいます。モバイルのMicrosoft 365管理者アプリからも表示できます。

権限で注意が要るのはここです。公式は「Microsoft 365で管理者ロールが割り当てられているほとんどのユーザーは、メッセージセンターの投稿を表示できます」としつつ、アクセスできないロールを明示しています。挙げられているのは次のとおりです。

コンプライアンス管理者／条件付きアクセス管理者／カスタマーロックボックスアクセス承認者
デバイス管理者／ディレクトリ閲覧者／ディレクトリ同期アカウント／ディレクトリ製作者
Intuneサービス管理者／特権的役割管理者／レポート閲覧者

「管理者権限を渡したのに見えないと言われる」という行き違いは、ここから生まれます。公式は解決策も示していて、他の管理者権限を持たせずに投稿を読んで共有できる「メッセージセンターの閲覧者」ロールを割り当てられると案内しています。情報共有のためだけに強い権限を配る必要はありません。

3つのカテゴリで読み分ける

投稿は3つのカテゴリのいずれかに分類されます。読む優先度がここで決まります。

問題の防止または修正——自社に影響する既知の問題の通知。サービスの中断を避けるためにアクションが必要になる場合がある。公式は「問題を回避するために積極的な対応を促すため、サービスの正常性メッセージとは異なる」と説明しています
変更の計画——対処が必要になり得る変更の通知。システム要件の変更や削除される機能など。計画メンテナンスの通知もここに含まれます
最新情報——新機能または更新された機能の通知

公式は、サービスの正常な実行を維持するために管理者が対応する必要があるすべての変更について30日以上前に通知するようにしていると記載しています。逆に言えば、放置している会社は毎回30日分の猶予を捨てているということです。

タグと関連性で絞る

投稿量は多く、全部読むのは現実的ではありません。公式はタグでの絞り込みを案内しています。選べるのは管理影響／データプライバシー／機能更新プログラム／メジャー更新プログラム／新機能／廃止／ユーザーへの影響／更新されたメッセージです。

このうち「メジャー更新プログラム」は、少なくとも30日前に通知されるものだけが集まります。公式が例に挙げているのは、日常の生産性への変更、テーマやWebパーツなどのカスタマイズへの影響、ストレージや項目数といった容量の増減、URLやブランドの変更、既定でオンになる新サービスの展開、データが格納・アクセスされる場所の変更など。読む時間が限られているなら、このタグだけ追うのが費用対効果として一番高いと考えていいでしょう。

また新しい投稿には関連性の推奨（高・中・低）が付きます。「高」は、サービスの中断を回避するために直ちに対処する必要があるものとされています。判断の入口として使えます。

重要な変更の通知先を分散させる

投稿は他の管理者へ共有できます。公式は、メッセージを開いて「共有」からメールアドレスを指定して送る手順と、「リンクのコピー」で共有リンクを作る手順を案内しています。ただしリンクを渡す相手は、メッセージセンターにアクセスできる人である必要があります。前述のロール制限に引っかかると、リンクを送っても開けません。

加えてPlannerと連携し、メッセージセンターの投稿をタスクとして追跡する仕組みも公式に用意されています。「読んだが誰も対応しなかった」を防ぎたいなら、この線を検討する価値があります。

障害か社内側の問題かを見分ける手順

公式情報に何も出ていない場合、自社側の切り分けに入ります。順番は次の4軸で固定してください。1つずつ条件を変えて、どこで症状が変わるかを見るのが原則です。

人を変える——別のユーザーでも起きるか。1人だけならアカウントかライセンスの問題
ネットワークを変える——テザリング等で試す。社内ネットワークだけで起きるなら通信側の問題
端末を変える——別のPCでも起きるか。特定端末だけなら端末側の問題
経路を変える——デスクトップアプリとWeb版で違いが出るか

ネットワークが原因の場合、公式のネットワーク要件が手がかりになります。Copilotの一部の統合はWebSocket（WSS）を利用しており、ネットワーク境界でのWSSブロック、ネットワーク機器によるTLS検査、プロキシサーバーの短い接続タイムアウトがアプリケーションエラーの原因になり得る、と明記されています。社内ネットワークだけで再現するなら、この線が濃厚です。

なお、無料で使えるCopilotと法人向けの有料版では、そもそも参照している仕組みが違います。片方だけが動かない場合、障害ではなく仕様の可能性もあります。