ChatGPT・Claude・Grokの障害はなぜ重なったのか

9月3日、主要な生成AIサービスが数時間のうちに相次いで利用しにくくなった。OpenAIのChatGPTとCodex、AnthropicのClaude、xAIのGrokでユーザー影響が報告されたこと自体は事実だ。とはいえ、「AI全体が一斉に落ちた」「単一の障害が原因だった」とまでは言えない。公開情報が示しているのは、原因説明の異なる個別インシデントが時間的に重なったという点であり、共通の根本原因は確認されていない。334148

何が、いつ起きたのか

各社のステータス更新時刻と外部報道の時刻には差があるため、完全に同じ基準で比較することは難しい。ただし、障害時間帯の重なりが、利用者に「同時障害」と受け止められた理由は明確だ。

• Grok：xAIのインシデント記録では、13時30分UTCに始まり、17時05分UTCに終了したと報じられた。xAIは後に、メンフィスのコンピュートセンターで発生した障害が影響したと説明した。48
• Claude：Anthropicは、Claude.ai、API、Claude Code、Claude Coworkを含む複数の製品・モデルでリクエストエラーが増加したと報告。障害はおよそ3時間続き、16時16分UTCまでに解消した。104148
• ChatGPTとCodex：OpenAIによれば、太平洋時間7時43分ごろに内部のルーティングエラーが発生し、一部ユーザーが各プラットフォームでChatGPTとCodexを利用できなくなった。対策は同8時17分ごろに実装され、その後も監視が続けられた。41

ユーザー側では、ログイン不能、チャットの読み込み失敗、プロンプト送信・応答の失敗、アプリおよびWebでのアクセス障害などが報告された。Downdetectorを基にした報道では、インド標準時20時ごろにChatGPTの問題報告が4万3,000件超に達した。Claudeでは一般ユーザー向け画面だけでなく、開発者向けAPIやコーディングツールも影響を受けた。2339

各社が説明した原因

障害が一つの共通原因だったと決めつけられないのは、各社が示した説明が異なるためだ。

OpenAIは、ChatGPTとCodexの問題について、自社インフラ内のルーティングエラーだったと説明した。41

Anthropicは、Claudeの問題をインフラストラクチャ上の障害と位置付け、複数モデル・サービスでエラーが増えたことを確認した。ただし、どの具体的なコンポーネントが故障したかは、提供された公開情報からは分からない。3948

xAIは、Grokの障害をメンフィスのコンピュートセンターでの障害に結び付け、影響を受けたコンピュートパートナーに謝意と謝罪を示したと報じられた。48

これらの説明は、共有依存関係が存在しなかったことを完全に証明するものではない。一方で、共通の根本原因があったことを示すものでもない。

Azureなど共有クラウドが原因だったのか

Microsoft Azure、ネットワーク事業者、CDN、認証サービスなど、共有されうる外部基盤が9月3日の全障害を引き起こしたと確認する公開証拠は、ここで確認できる資料にはない。

当時の報道では、3社にクラウドサービスを提供しているAzureが注目点として挙げられた。しかし、それは因果関係の証明ではない。42 ユーザー報告を中心に把握される障害は、別々のシステムで独立して起きても、時間帯が重なって見えることがある。

したがって現時点で妥当な結論は、共有インフラが共通原因だったかどうかは未確認、というものだ。Azureの特定リージョン障害がすべてを引き起こしたとする主張は、各社による直接の説明や技術的な事後報告がない限り、確定情報として扱うべきではない。

AnthropicのColossus 1利用がClaude障害を説明するのか

報道されたAnthropicによるxAI／SpaceXAIのColossus 1施設へのアクセスについても、利用範囲や、障害当時にClaudeの本番推論経路がその設備に依存していたかを判断するには情報が足りない。メンフィスでのGrokの障害が、直ちにClaude障害の原因を意味するわけではない。48

信頼性を考えるうえでは、仮に計算資源に関する商業契約が確認されても、それだけで「その時点で特定の対ユーザーサービスがその設備上で動いていた」ことの証拠にはならない、という区別が重要になる。

9月7日にインドで報告されたChatGPTの問題

9月7日には、インドのユーザーを中心とするChatGPTの不具合報告も伝えられた。主な訴えはコンテンツ生成ができないというもので、アプリやブラウザでの問題を挙げるユーザーもいた。ある報道では問題報告は約261件で、その大半がコンテンツ生成に関するものだったという。19

ただし、この情報だけでは、インド全国に及ぶ継続的な障害、確定した原因、あるいは9月3日の障害との関連は立証されない。同日03時07分UTCには、外部監視サービスがChatGPTへ通常どおり到達でき、異常な応答時間やエラーは検知しなかったと報告している。22 これは、全国規模で継続する障害の証拠というより、部分的・断続的、または地域差のある問題だった可能性と整合的だ。

企業への示唆：マルチベンダー化だけでは十分ではない

今回の事例は、顧客対応、ソフトウェア開発、調査、文書処理、エージェント型の業務フローが、AIサービスの停止によって短時間で滞ることを示した。複数のAIサービスを契約すれば、単一ベンダーの障害には強くなる。しかし、クラウド、ネットワーク、認証、ブラウザ、業務連携といった経路が重なる場合、停止リスクを完全に解消できるわけではない。

より耐障害性の高い運用には、次の備えが有効だ。

• 手作業への切り替えと永続キュー：重要な処理が失敗時に消えないようにし、復旧後に再実行できる設計にする。
• プロバイダー間フェイルオーバー：条件に合うタスクは別のモデル事業者へ振り分ける。ただし、相関した障害は起こりうる前提で考える。
• 防御的なAPI処理：上限付きタイムアウト、指数バックオフを伴うリトライ、サーキットブレーカー、冪等なジョブ処理を採用し、一時的な障害で重複処理が起きないようにする。
• 縮退運転の定義：高性能モデルが使えないときに何を継続するかを事前に決める。ルールベースの振り分け、キャッシュ済み回答、処理の後送り、人による確認などが選択肢になる。
• 独立した監視とインシデント記録：ベンダーのステータスページだけに依存せず、自社の合成監視も行う。どの事業者、モデル、連携部分で失敗したのかを追えるログを残す。

要点は、「同時障害には必ず隠れた共通原因がある」ということではない。そうした可能性も含めて、次の障害が起きる前に代替手段が実際に機能するかを検証しておくべきだ、ということだ。