Microsoft 365検索障害「MO1456424」で何が起きたのか

Microsoft 365のインシデント MO1456424 は、2026年8月17日 8時46分14秒（UTC） に始まりました。Microsoftはこれを、SharePoint Online、OneDrive、Outlook on the web、Outlookデスクトップの検索機能に影響する 「サービス低下（service degradation）」 と分類しています。公開されているインシデント記録には終了時刻が記載されていません。

影響を受けたサービスとユーザー

影響が出たのは、対象インフラ経由でサービスを利用し、上記のMicrosoft 365アプリでコンテンツを検索しようとした一部のユーザーです。Microsoftの告知は「一部のユーザー」への影響と説明していますが、影響を受けた顧客数は公表していません。また、確認できる資料には対象国や地域の記載もないため、特定地域で発生した障害、あるいは世界規模の障害と断定することはできません。

今回の問題は、各アプリのすべての機能が停止したというものではなく、検索機能に集中していました。ただし、メールや文書、保存済みのファイルを検索で見つけられない状態は、複数の業務サービスをまたいで日常の作業を妨げる可能性があります。

原因は最近のデプロイによる「リソース使用効率」の問題

Microsoftによると、最近のデプロイによって、検索リクエストを処理するインフラに「リソース使用効率の問題（resource utilization inefficiency issue）」が発生したことが原因でした。平たく言えば、その変更によって対象の検索インフラでリソースが非効率に消費され、一部の検索クエリを処理する能力が低下したということです。

ただし、公開情報では、具体的にどのコード経路、リソースの種類、しきい値、デプロイ内容が問題だったのかまでは明らかにされていません。

このため、現時点で裏付けられているのは、デプロイに関連した検索インフラのリソース効率の問題です。サイバー攻撃や、特定地域のネットワーク障害、Microsoft 365全体の容量不足が原因だったとする情報はありません。

Microsoftが展開した修正とは

Microsoftは、リソースへの圧力を軽減し、検索機能を回復させるための修正を開発し、展開を開始したと説明しています。報道でも、非効率なリソース使用を是正し、影響を受けたサービスを通常運用に戻すための修正とされています。

一方、提供されたインシデント記録には終了時刻がないため、すべての影響ユーザーでいつ復旧が完了したのかは確認できません。ロールバックを実施したのか、恒久的なアーキテクチャ変更を行ったのかといった、より詳しい対応内容も公表資料には記載されていません。

なぜ「障害」なのにサービス低下という分類なのか

MO1456424は、Microsoft 365のサービス正常性情報で serviceDegradation として記録されています。これは、Microsoft 365全体が完全に停止したという意味ではありません。

それでもインシデントとして追跡されたのは、複数の製品にまたがる顧客向けの中核機能、つまり検索が一部ユーザーにとって利用できなくなったためです。Microsoftは、この分類を選んだ理由を別途説明していません。したがって、最も慎重な理解は「Microsoft 365の複数サービスに影響した検索機能の低下」であり、Microsoft 365の全サービス停止ではない、というものです。

同日のGitHub障害とは別の問題

発生時期が近かったため、MO1456424はMicrosoft関連サービスで相次いだ障害の一つとして扱われがちです。しかし、確認されている原因はそれぞれ異なります。

GitHubでは7時間47分の大規模な障害

Microsoft傘下のGitHubでは、2026年8月17日13時28分から21時15分（UTC）まで、7時間47分にわたる別の障害が発生しました。Issues、プルリクエスト、API、Actions、Copilotなどでエラーや遅延が増加し、ピーク時にはウェブとAPIのエラー率が約20％、アーカイブおよびrawコンテンツのダウンロードでは約50％に達しました。

GitHub側の説明や報道では、ロードバランサーの飽和、誤ったオートスケーリングポリシー、Visual Studio Codeに潜在していたリトライ関連のバグが要因として挙げられています。これは、MO1456424のデプロイに起因する検索インフラの問題とは異なる仕組みです。

過去にもMicrosoft 365の検索障害

Microsoft 365では、過去にも検索関連のインシデントが発生しています。2025年4月には、Outlook on the webとSharePoint Onlineで検索の遅延や失敗が起きました。検索リクエストを処理するインフラコンポーネントが、許容される性能しきい値を下回っていたことが原因とされています。

OneDriveでも、ユーザーがアップロードしたことを把握しているファイルを検索しても、結果が空白になったり、結果が表示されなかったりするファイル検索の問題が報告されています。ただし、これら過去の問題がMO1456424と同じ根本原因だったとする証拠は、提供資料からは確認できません。

7月のAzure・Microsoft 365障害はネットワークが原因

2026年7月23日の障害は、今回より広範囲で、技術的にも別の問題でした。Azureのステータス履歴によると、14時44分から19時41分（UTC）にかけて、米国西部（West US）リージョンでホストされるサービスにアクセスする一部顧客が、接続障害や遅延、アクセス困難に見舞われました。影響したのはリージョンに出入りするネットワーク通信で、リージョン内にとどまる通信は影響を受けませんでした。

Microsoftは、定期的なネットワーク保守を自動化する仕組みの不具合により、意図した範囲を超えて複数の機器からIPルートを削除したと説明しています。これはネットワークの制御プレーンにおける障害であり、検索サービスのデプロイが引き起こしたMO1456424とは異なります。

3つの障害から何が分かるのか

今回の事例を並べると、障害が異なるレイヤーで発生していることが分かります。

• MO1456424：最近のデプロイが検索インフラで非効率なリソース使用を引き起こした。
• 2026年8月17日のGitHub障害：ロードバランサーの飽和、オートスケーリングの不具合、リトライによる負荷増幅が関係した。
• 7月のAzure障害：ネットワーク保守の自動化処理が、必要以上にIPルートを削除した。

つまり、アプリケーションのデプロイ、容量・自動スケーリング、ネットワーク自動化という異なる層で、それぞれ運用上のリスクが表面化したということです。これらが一つの共通原因から発生したことを示す証拠はありません。

また、提供されたインシデント記録からは、AIによる需要増がMO1456424、GitHub障害、7月のAzure障害を引き起こしたとは判断できません。GitHubはパブリッククラウドへの移行やマルチクラウド化への方針に言及していますが、それだけで特定の障害との因果関係が証明されるわけではありません。

より限定的で確実な教訓は、クラウドサービスやAI関連ワークロードの重要性が増すほど、デプロイ時の安全策、容量計画、リトライの連鎖を防ぐ仕組み、障害分離、ネットワーク自動化のテストが重要になるということです。マルチクラウドは一部のインフラリスクを分散できますが、サービス自身の制御プレーン内部で起きる障害を自動的に防ぐものではありません。