MicrosoftのAIアシスタント「Copilot」が2026年6月11日、今月2度目となる大規模な障害を起こし、北米・欧州の企業ユーザーの業務に支障をきたした。障害の根本原因は認証レイヤーへの誤ったソフトウェア展開とされており、Microsoftは6月14日までに詳細な分析報告を公表する予定だ。一方、Copilotには現時点でExchange Onlineのようなサービス品質保証（SLA）が存在しておらず、大規模展開を検討・推進中の企業IT部門からはSLAの明文化を求める声が高まっている。
■ 障害の概要――2つの役割が同時に止まった
MicrosoftのAIアシスタント「Copilot」が現地時間2026年6月11日（木）午後、今月2度目となる重大な障害に見舞われ、北米・欧州の企業ワークフローを広範に混乱させた。折しもMicrosoftのCEOが年次開発者会議（Build 2026）でCopilotを「初の真のエージェント型オペレーティングシステム」と位置付けた直後のことだった。
この障害は、ピーク時間帯に発生したソフトウェア展開の不具合によるものだ。CopilotのフロントエンドとMicrosoft Graph、Azure OpenAIをつなぐ「フェデレーション認証レイヤー」（複数サービス間でユーザー認証情報を共有する仕組み）が切断され、「トークン交換」サービスが正規ユーザーの認証情報を拒否し始めた。これにより発生した大量の再試行（リトライストーム）が残存する正常ノードに集中し、エンジニアが設定をロールバックして中間キャッシュレイヤーを増強するまで負荷が収まらなかった。
Downdetector（障害報告プラットフォーム）では太平洋時間午後2時3分時点のスナップショットで4,500件超のインシデント報告が集まり、別の監視データでは太平洋時間午後2時15分（日本時間6月12日午前7時15分）にかけてピーク1万2,000件超を記録したと報じられている。
さらに注目すべきは、Copilotの認証レイヤーが止まると同時に「portal.office.com」へのアクセスも失われた点だ。「AIアシスタント」として導入したはずのツールが、Webベース生産性スイート全体の玄関口をも遮断してしまったことになる。
■ なぜ1つの障害が連鎖するのか――Copilotの構造的な依存関係
Microsoft 365 Copilotはスタンドアロンの（単独で動作する）チャットボットではない。複数のサービスが密接に連動した構造になっている。具体的には、Microsoft Entra IDがすべてのユーザーセッションを認証し、Microsoft Graphがメール・ファイル・カレンダーからデータを取得し、Azure OpenAIが推論処理を行い、Word・Outlook・TeamsのクライアントがAIの応答を画面に表示する。どのレイヤーで設定ミスが生じても、下流のすべてのレイヤーに影響が及ぶ。
ワシントン大学でクラウドの信頼性を研究するElena Torres博士はこう述べている。「Azureの1リージョンで認証障害が起きると、Microsoft IDグラフに依存する全く別のプロバイダーがホストしているフォーラムさえ沈黙することがある。密結合が引き起こす連鎖的な障害の典型例だ」
6月11日の障害は数時間続いた後、エンジニアがロールバックを完了した。ただし、すべてのCopilot機能が同等の影響を受けたわけではない。消費者向け「Bing Chat Enterprise」は別の認証フローで稼働しているため、今回の障害中も正常に動作し続けていた。Microsoftによる正式な根本原因分析は2026年6月14日（日）までに公表される予定だ。
■ 6月に3度の障害――Q1 2026の稼働率は過去最低水準
6月11日の障害は孤立したインシデントではない。5月末から続く一連のパターンを見ると、単なる偶然とは言い難い。
まず5月29日、Azure OpenAIバックエンドで負荷分散アルゴリズムの設定ミスが発生し、6時間に及ぶ速度低下を招いた。ピーク時のDowndetector報告数は4,200件超で、IT管理者はビジネス側へ原因を説明するのに追われた。次に6月1日（Build 2026の3日前）、雷雨により東米（East US）リージョンのAzureデータセンターで主・副両系の電源が断たれ、米国東部時間午前11時15分（日本時間深夜0時15分）に報告件数が1万4,000件に達した。影響を受けたユーザーの72%がCopilotパネルを全く表示できなかったとされる。そして6月11日、またも別の根本原因によるデプロイメント障害が発生した。
累積的な影響はMicrosoft自身が公開したデータにも現れている。Microsoft 365の2026年第1四半期（Q1）稼働率は99.526%にとどまり、アナリストが2013年から追跡を始めて以来、四半期ベースで最低の数値を記録した。これは単一四半期で614分超のサービス停止に相当する。メールサービスのExchange Onlineには財務的裏付けのある99.9%稼働保証（月あたりの許容停止時間は約43分）が設けられているが、Copilotには現時点で同等の保証が存在しない。この「SLAの空白」に対し、企業のIT担当リーダーが公然と異議を唱え始めている。
■ Fortune 500企業もCopilot展開を一時停止――信頼性への懸念から
企業顧客が今問うているのは「Copilotは信頼できるか」ではなく、「Microsoftは既存インフラと同等の契約上の保証をCopilotに課す意思があるか」という点だ。
Build 2026の場では、複数の大口顧客がCopilotのインフラ成熟度について非公式に懸念を示した。Fortune 500に名を連ねる金融大手のCIOはWindows Newsに対し、信頼性への懸念を理由にCopilotの展開規模拡大を延期したと明かした。
「市場が動くイベントの最中にAIが突然使えなくなる可能性がある状況で、トレーダーのワークフローにAIを組み込むわけにはいかない。MicrosoftはCopilotをExchange OnlineやAzure Active Directoryと同等に扱うべきだ。あれらのサービスはファイブナイン（99.999%）の信頼性がDNAに刻み込まれている。Copilotはまだそのレベルに達していない」と、このCIOは述べた。
■ サイレント障害という新たなリスク――エラーが見えないまま業務が止まる
懸念は数字の問題だけではなく、構造的な問題でもある。今回の障害中、あるリーガルテック（法律業務特化型テクノロジー）ベンダーのドキュメントレビューツール――Copilot Graph APIで動作するもの――は契約書の処理を静かに止めた。エンドユーザーへの警告はなく、気づかないうちにバックログが積み上がり、解消に数時間を要した。
メールやファイルストレージの停止であれば、従来のビジネス継続計画（BCP）の枠組みで対処できる。しかし、下流インテグレーションが機能しなくなっても待っている人間には何のエラーメッセージも届かない「サイレントなAI障害」は、ほとんどの企業がまだランブック（対応手順書）に書き込んでいない障害モードだ。
■ 現状と対応策――今すぐできる「被害の最小化」
6月13日現在、Copilotは正常稼働中だ。認証ループや空白ペインが続いているユーザーは、木曜日のキャッシュされたセッションデータが原因の可能性があり、ブラウザキャッシュの完全クリアで症状が解消されることが多い。今後の障害発生時は、admin.microsoft.comのMicrosoftサービス正常性ダッシュボードの確認が推奨されている。
Copilotを大規模展開済み、または展開を検討している企業のITリーダーに向けて、業界では以下の対策が推奨されている。いずれも低コストで実施可能だが、次回障害時の「被害半径」を大きく縮小できるとされる。
第一に、Microsoft 365サービス正常性通知をITオペレーションチームに直接ルーティングするよう設定することだ。6月の障害では、通知メールがフィルタリングされたり古いアドレスに届いたりしていた企業が多かった。
第二に、Copilot Graph APIを呼び出している社内ツールおよびサードパーティ連携を洗い出し、それぞれに明示的なフォールバック手順を整備することだ。前述のリーガルテックベンダーのケースは孤立した例外ではない。
第三に、一部のCIOはハイブリッドアーキテクチャの検討を始めている。センシティブな業務や時間的制約が厳しいワークフローはローカルGPUホスト型モデルにルーティングし、停止を許容できる低優先度のクエリをCopilotで処理するという考え方だ。Microsoftもこの方向性を加速させており、Build 2026ではSnapdragon X EliteおよびIntel Lunar Lakeチップ上でネイティブ動作するオンデバイス推論モデル「Phi-4」シリーズが発表された。
SLAで約束される99.9%稼働率とは、月あたり約43分の停止を許容するという意味だ。しかし市場変動イベント中、M&A成立の瞬間、あるいは取締役会プレゼン中に発生した1回の障害が、その数字が示す以上のコストをもたらす可能性がある。ランブックを整備すべき時は次の障害が起きてからではなく、今だ。契約更新や規模拡大の交渉においてCopilot固有のSLAをまだMicrosoftに求めていない企業は、今月の記録を踏まえて交渉を始めることを検討すべきだろう。
■注目ポイントQ&A ●2026年6月11日のMicrosoft Copilot障害の原因は何か？
Microsoftによると、直近のソフトウェア展開の不具合により、CopilotのフロントエンドとMicrosoft Graph・Azure OpenAIをつなぐフェデレーション認証レイヤーが切断された。認証サービスが正規のユーザー認証情報を拒否し始め、リトライストームが発生して残存する正常ノードが過負荷状態に陥った。エンジニアは旧ビルドへのロールバックと中間キャッシュレイヤーの増強によって解消した。詳細な根本原因分析は2026年6月14日までに公表予定だ。
● なぜ2026年6月にCopilotは繰り返し障害を起こしているのか？
今月発生した3件の障害は、それぞれ異なる根本原因を持つ。5月29日の負荷分散アルゴリズムの設定ミス、6月1日のAzureデータセンター停電、そして6月11日のデプロイメント障害だ。共通しているのは、Microsoft 365 CopilotがEntra ID認証、Microsoft Graph、Azure OpenAI推論など複数サービスが密接に連動した構造を持っており、どこか1か所で障害が発生すると連鎖的に広がる点だ。Microsoft 365の2026年Q1稼働率は2013年の追跡開始以来最低の99.526%を記録しており、これは単発の異常ではなくパターンである可能性が高いと言える。
● Microsoft CopilotにはSLAによる稼働保証はあるか？
MicrosoftのMicrosoft 365向け標準クラウドSLAは、Exchange Onlineのようなコアサービスに対して99.9%稼働率を保証し、未達の場合はサービスクレジットが付与される。一方、Copilot固有の信頼性保証は現時点で策定中の段階にあり、企業顧客はメールやファイルストレージと同等の財務的裏付けのあるSLA保護をまだ受けていない。ITリーダーは、いかなる契約更新・規模拡大交渉においても、Copilot固有のSLA条件をMicrosoftに明示的に求めることを推奨している。
● 2026年6月11日の障害はどのくらい続いたか？
最初のユーザー報告は米国東部時間午後4時8分（日本時間6月12日午前5時8分）頃に届き始め、米国東部時間午後7〜8時頃（日本時間6月12日午前8〜9時頃）に復旧した。停止時間はおおよそ3〜4時間とされている。なお6月1日の障害はより長く広範囲に及び、米国東部時間午前11時15分（日本時間深夜0時15分）時点でのDowndetectorのピーク報告件数は1万4,000件に達した。
元記事: Microsoft Copilot Fails Twice in June: Enterprise IT Has No SLA Protection for AI Downtime