ChatGPT・Claude・Grokが同時障害、共通基盤説は確認されず

2026年9月3日、OpenAIのChatGPTとCodex、AnthropicのClaude、xAIのGrokで可用性問題が発生し、障害時間の一部が重なった。影響範囲は製品やモデル、利用者によって異なるものの、各サービスは同日中に復旧した。
現時点で確認できる結論は、複数の障害が並行していた一方、三社を停止させた単一の共通基盤は特定されていないということだ。OpenAIは自社のルーティングエラーを説明し、Grok側はメンフィスの計算拠点での障害を挙げたが、三社共通のクラウドやネットワークが原因だったとする公式発表はない。
三社の障害が重なった時間帯
Claudeでは協定世界時13時26分に複数モデルのエラー調査が始まり、Grokでは13時30分に障害調査が始まった。OpenAIの説明ではChatGPTとCodexの問題は14時43分ごろに始まっており、少なくとも14時43分からClaudeの影響が終了した16時16分まで、三社の問題が並行していたことになる。
WIREDが確認した各社の時系列 では、OpenAIの対策適用は太平洋時間8時17分ごろ、Claudeの復旧は9時16分、Grokの復旧は10時05分とされている。同紙は、Cloudflare、AWS、Microsoft Azureなど主要なインフラ事業者が対応する障害を報告しておらず、OpenAIとAnthropicも共通の外部要因を示していないと伝えた。
したがって、ここでいう「同時障害」は、全利用者が同じ瞬間から完全に利用不能になったという意味ではない。確認できるのは、異なる三社が同じ朝にエラー増加や部分停止を記録し、その障害時間が重複したことだ。
OpenAIはChatGPTとCodexのルーティング問題を解消

OpenAIの広報担当者は、太平洋時間7時43分ごろに始まったルーティングエラーにより、複数のプラットフォームで一部利用者がChatGPTとCodexを利用できなくなったと説明した。対策は8時17分ごろに適用され、その後は回復状況の監視に移った。
OpenAIの公式障害記録 は、ChatGPTの15コンポーネントとCodexの4コンポーネントを影響対象として掲載し、協定世界時16時55分に解消を記録している。一部のCodex remote control利用者については、障害後にモバイル端末を再度ペアリングする必要があるとしている。
この説明が特定しているのは、OpenAIのサービスで起きたルーティング上の問題である。ClaudeやGrokまで同じ経路障害で停止したことを示す情報は含まれていない。
ClaudeとGrokも別々の記録で復旧
Claudeでは、Mythos 5.1、Fable 5.1、Opus 5など複数モデルでエラーが増加し、claude.ai、Claude API、Claude Code、Claude Coworkが影響対象となった。Anthropicの記録では協定世界時13時41分に原因を特定し、16時06分に修正を適用、影響は16時16分に終了しているが、公開ページには具体的な技術原因までは記されていない。
Grok in Xでは協定世界時13時30分に調査が始まり、xAIの公式障害記録 が17時05分にトラフィックの正常化を報告した。記録上の継続時間は3時間35分である。別途、Grok側は同日、メンフィスの計算拠点で起きた障害がサービスに影響したと説明した。
三社はいずれも復旧したが、公表内容の粒度はそろっていない。OpenAIは障害の種類を明示し、Grok側は影響した拠点を示した一方、Anthropicの公式記録はモデル、対象サービス、復旧過程の説明にとどまる。
時間の一致は共通原因の証明ではない
複数の生成AIが同時期に停止すれば、共通のクラウド、コンテンツ配信網、認証サービス、DNSなどを疑う余地はある。しかし、時間的な一致は調査の手掛かりであり、それだけで同じ設備や設定変更が原因だったとは断定できない。
今回、主要なクラウド事業者やCloudflareの公開情報から、三社の停止をまとめて説明する広域障害は確認されなかった。OpenAIが示したルーティングエラーと、Grok側が示したメンフィスの計算拠点の障害も、同一の事象だと結び付ける情報は公表されていない。
一方、現段階の情報だけで関連性が完全に否定されたとも言えない。詳細な事後報告が公開されれば、共有する外部サービスやトラフィックの移動など、間接的な接点が判明する可能性は残る。正確な整理は「共通原因が否定された」ではなく、「共通原因を裏付ける情報は確認されていない」となる。
複数契約に加えて必要な三段階の縮退策

今回のように障害時間が重なる可能性を考えると、複数の生成AIを契約するだけでは業務継続策として不十分な場合がある。代替モデルが利用できても、認証、ネットワーク、データ保存先、出力形式や安全基準が異なれば、その場で切り替えられるとは限らない。
業務の縮退方法は、処理の緊急度と再実行の可否に応じて三段階に分けられる。
- 手動処理へ戻す:承認、顧客対応、公開判断など停止できない工程について、人が実行できる最小限の手順と権限を残す。
- 別モデルへ切り替える:平常時から代替モデルで入力形式、出力品質、機密情報の取り扱い条件を確認する。候補の用途差を整理する際は、主要AIの機能比較 も参考になる。
- 要求をキューに保存する:即時性が不要な生成、要約、分類は入力と処理状態を保持し、復旧後に再実行する。重複処理を避ける識別子と再試行上限も必要になる。
代替経路を設計する際は、モデル名の違いだけでなく、認証やクラウド、ネットワークを含む障害領域が実際に分離されているかが重要になる。すべてを即時に別モデルへ送るのではなく、手動で継続する処理、切り替える処理、復旧を待つ処理を事前に分けておく必要がある。
9月5日時点で、ChatGPT/Codex、Claude、Grokの各障害は解消済みであり、三社にまたがる継続中の障害は確認されていない。残る論点は、各社がさらに詳しい事後分析を公開するか、障害時間の重なりを説明する技術的な接点が今後示されるかどうかだ。
関連記事:
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。