ChatGPT・Claude・Grokが同時障害　共通インフラ障害だったのか？

AI , , , , , , ,

2026年9月3日、ChatGPT、Claude、Grokで相次いで障害が発生した。3大AIが同じ時間帯に使いにくくなったため、SNSでは「共通のクラウド基盤が落ちたのではないか」「大規模なサイバー攻撃ではないか」といった見方も広がった。

結論から言えば、3サービスすべてを止めた単一の共通インフラ障害は、9月4日時点で確認されていない。 OpenAIはChatGPTについて「ルーティングエラー」と説明した。一方、Grokを運営するSpaceXAIは米テネシー州メンフィスの計算拠点で障害が起きたと公表している。Claudeの運営元Anthropicは「インフラの問題」としたものの、具体的な設備名や事業者名は明らかにしていない。

ただし、ClaudeとGrokに限れば話は別だ。両者の公式記録の開始は4分しか違わず、障害時間の大半が重なった。さらにAnthropicは、SpaceXAIのメンフィスにある「Colossus 1」の計算資源を利用する契約を公表済みだ。したがって本稿では、「3社共通説は証拠不足だが、ClaudeとGrokの一部に同じ障害領域があった可能性は残る」と評価する。

更新：3社の当該障害はすべて復旧済み。OpenAIではその後、9月4日にアジア太平洋地域のChatGPTやCodexなどで別の障害が発生したが、これも復旧している。時刻と対象が異なるため、本稿の「3社同時障害」とは分けて扱う。

障害の時系列――公式記録は93分重なり、対策前は34分

各社の公式インシデント記録は93分間重なったが、ChatGPTで対策が入る前の重複は34分間だった。

以下は、OpenAI、Anthropic、SpaceXAIの公式ステータスを日本時間に換算した比較だ。ChatGPTについては、OpenAI広報が説明した「問題発生から対策実施まで」と、ステータスページ上でインシデントが「解決」になるまでを分けた。

サービス公式記録の開始（日本時間）対策・影響終了公式上の解決公表された範囲
Claude9月3日 22:269月4日 1:161:23に終了を告知Claude.ai、Claude Code、Cowork、APIの一部。複数モデル
Grok9月3日 22:309月4日 2:072:07Grok.comのモデル障害。X内Grokも2:05まで影響
ChatGPT9月3日 23:439月4日 0:17に対策1:55ChatGPTの15コンポーネント、Codexの4コンポーネント

開始時刻だけを見ると、最初のClaudeと最後のChatGPTには77分の差がある。「3社が同時に落ち始めた」という表現は正確ではない。公式インシデントの重複は、ChatGPTが始まった23時43分からClaudeの影響が終わった翌1時16分までの93分。このうち最初の34分でOpenAIは対策を実施し、残る59分は回復を監視していた。対策後も一部利用者への影響が残った可能性はあるため、本稿では34分を「完全な復旧までの時間」とは扱わない。

出典：OpenAI Status、Claude Status、SpaceXAI Status、WIREDのOpenAI広報回答

結論――「3社共通」と「2社共通」を分けて考えるべきだ

公開情報に最もよく合うのは、「ChatGPTは別件で、ClaudeとGrokには共通原因の可能性がある」という二層構造だ。

障害原因を考える際は、「同じクラウド会社を取引先に持つ」ことと、「障害時に同じ設備・同じ経路を使っていた」ことを区別しなければならない。前者は公開資料で確認できても、後者は通常、各社の詳細な障害報告がなければ分からないからだ。

ClaudeとGrokは166分間重なり、公式記録の開始差は4分

Claudeの公式記録170分のうち166分、率にして97.6％がGrokの障害時間と重なっていた。

計算は各社が公表した調査開始・影響終了時刻を使った。両者の共通時間帯である22時30分から翌1時16分までは166分。これをClaudeの170分で割ると97.6％、Grokの217分で割ると76.5％になる。偶然だけでも同時障害は起こり得るが、公式記録の開始差4分とこの重複率は、共通要因を検討するだけの材料にはなる。

さらにAnthropicとSpaceXAIは2026年5月、計算資源の提携を公式発表した。Anthropicは、22万基超のNVIDIA製GPUを備えるメンフィスのColossus 1を、Claude ProやMaxの処理能力拡大に使うとしている。今回、SpaceXAIは同じメンフィス拠点の障害と「compute partners（計算資源の提携先）」への影響を認めた。

この二つを合わせると、Claudeの一部処理がColossus側の障害に巻き込まれた可能性はある。ただし、Anthropicは今回影響を受けたClaudeの処理がColossus 1で動いていたとは公表していない。これは一次情報から導いた推論であり、確認済みの原因ではない。

出典：AnthropicとSpaceXAIの計算資源提携、SpaceXAIの障害説明

ChatGPTまで同じ原因とみる証拠は弱い

ChatGPTの公式記録はClaudeより77分遅れて始まった。OpenAIが示した原因はルーティングエラーだった。

OpenAIの公式ステータスではChatGPTとCodexの複数機能が影響を受けた。広報説明によると、問題は米太平洋時間7時43分に始まり、8時17分に対策が入った。ChatGPTがSpaceXAIのColossusを利用しているという公式発表も見当たらない。

もちろん、メンフィスの障害でClaudeやGrokからChatGPTへ利用者が移り、その急増がOpenAI側のルーティング上の弱点を表面化させた可能性は否定できない。2024年にも、ChatGPT停止中の移動先としてClaudeやPerplexityに負荷が集中したとの見方が出た。ただし今回は、流入量や経路別負荷のデータが公表されていないため、ここから先は仮説にとどまる。

各社の情報開示を比較――原因の粒度には差がある

3社とも復旧時刻は示したが、障害の根本原因、再発防止策、依存先まで公開した事業者はまだない。

運営会社公表内容分かったことまだ分からないこと
OpenAIステータス更新、広報がルーティングエラーと説明影響機能、対策時刻どの経路・構成変更が原因だったか
Anthropic影響モデルを段階的に列挙、「インフラの問題」と説明モデル別の復旧過程、影響終了時刻障害設備、外部事業者、根本原因
SpaceXAIメンフィスの計算拠点と提携先への影響を説明物理拠点との関連、Grokの復旧時刻故障箇所、Claudeへの具体的な波及経路

Anthropicのステータスは影響モデルの変化まで追える点で細かい。OpenAIは原因の種類を一語で示した。SpaceXAIは物理拠点を明示した一方、技術的な故障箇所は示していない。透明性を「更新回数」だけで測ると実態を見誤るため、原因、影響範囲、復旧判断、再発防止策の4項目で比べる必要がある。

反証検証――Cloudflare、Azure、サイバー攻撃説は成り立つか

共通事業者の名前が資料に載っているだけでは、今回の共通障害を証明できない。

OpenAIとSpaceXAIの公開する外部委託先一覧には、AWS、Google Cloud、Oracle、Cloudflareなど共通する事業者がある。AnthropicもCloudflareや複数のクラウド基盤を利用している。しかし、委託先一覧は「利用可能性」を示すだけで、9月3日の該当リクエストが同じ設備を通った証拠にはならない。

仮説支持材料反証・不足本稿の評価
Cloudflareの世界障害3社はいずれもCDNなどでCloudflareとの接点がある当該時間帯に世界規模の障害報告はなく、Claudeはモデル別、Grokはメンフィス拠点という症状可能性は低い
Microsoft Azureの障害OpenAIとAnthropicはAzureとの関係を公表Grok側はメンフィスを明示。Azureの広域障害を裏付ける一次情報もない3社共通説としては弱い
メンフィス障害がClaudeにも波及公式提携、開始差4分、166分の重複、SpaceXAIの「提携先」への言及Anthropicが利用経路を確認していない2社に限れば有力候補
利用者の避難による連鎖Claude・Grokの後にChatGPTが停止。過去にも類似の観測流入量と負荷データが非公開あり得るが未確認
大規模サイバー攻撃複数社の同時障害という見た目3社とも攻撃や侵害を報告していない裏付けなし

Cloudflareの同日履歴には個別の障害が記録されているが、香港の5xxエラーはAI各社の障害より約4時間前に終了している。R2カスタムドメインのHTTP/3問題も、一部Firefox利用者の読み込み遅延が中心で、3社のAIモデル障害とは範囲も症状も合わない。少なくとも「Cloudflare全体が落ちた」という説明とは整合しない。

出典：OpenAIの外部委託先一覧、SpaceXAIの外部委託先一覧、Anthropicの外部委託先一覧、Cloudflare Status履歴

障害報告数はChatGPTに集中――ただし利用者比率ではない

米国とブラジルのピーク報告を単純合算するとChatGPTが全体の93.4％を占めるが、これは障害の深刻度や市場シェアを示す数字ではない。

Downdetectorの数値を報じたブラジル紙Folhaによると、確認されたピーク報告は次の通りだった。国ごと、サービスごとにピーク時刻が異なるため、同一瞬間の比較ではない。

サービス米国のピーク報告ブラジルのピーク報告2カ国の単純合算
ChatGPT37,908件9,674件47,582件
Claude1,324件630件1,954件
Grok1,365件53件1,418件

合計50,954件に占めるChatGPTの比率は、47,582÷50,954＝93.38％。Claudeは3.84％、Grokは2.78％となる。ChatGPTの報告はClaudeの約24.4倍、Grokの約33.6倍だ。

ただし、Downdetectorは利用者による自発報告である。利用者数、地域での知名度、障害に気づく時間帯、同じ人の複数報告などに左右される。したがって、この数字から「ChatGPTの障害が33倍深刻だった」「ChatGPTのシェアが93％だ」とは言えない。使えるのは、利用者が感じた異常の集中度を示す補助指標としてだけだ。

出典：FolhaによるDowndetector集計

過去事例と比較――本物の「共通インフラ障害」は別の顔を見せる

真の共通基盤障害では、AIに加えて認証、決済、ストレージなど異業種のサービスにも、同じ時刻に似た症状が広がることが多い。

事例起きたこと今回との違い
2024年6月：ChatGPT、Claude、PerplexityChatGPTは接続プール設定に起因するデータベース停止。ほかのAIへの利用者移動も疑われた同時に見えても、単一の共通基盤だったとは確認されなかった
2025年6月：Google CloudからCloudflareへ波及CloudflareのWorkers KVが第三者クラウドに依存し、障害時は要求の90.22％が失敗。AccessのID認証ログインは100％失敗依存関係と失敗率が事後報告で明示され、AI以外にも世界規模で波及した
2025年11月：Cloudflare世界障害権限変更で重複データを含む設定ファイルが肥大化し、ソフトウェア上限を超過。CDNや認証など広範囲で5xxエラー共通入口の障害らしく、多数の無関係なサービスに同型の症状が出た

今回の3社障害は、開始時刻が最大77分ずれ、ChatGPTはルーティング、Grokは特定の計算拠点、Claudeは特定モデル群という違いがある。主要クラウドやCDNで同時刻の広域障害も確認されていない。過去の共通基盤障害と比べると、3社を一本の線で結ぶより、部分的な連鎖と独立障害が重なったとみる方が説明力は高い。

出典：OpenAIの2024年6月障害報告、Cloudflareの2025年6月事後報告、Cloudflareの2025年11月事後報告

独自分析――「3つのAIを契約」は、そのまま障害対策にならない

サービス名が違っても、CDN、クラウド、計算拠点、認証基盤が重なれば、見かけ上の3系統が実際には一つの障害領域になる。

企業のAI事業継続計画（BCP）では、モデルの性能表だけで代替先を選びがちだ。今回の教訓は、「どこまで経路が独立しているか」も調べる必要があることだ。最低でも、AI事業者、接続経路、クラウドと地域、認証、基盤モデルの5層を確認したい。

予備ルート防ぎやすい障害防げない可能性がある障害
同じ事業者の別モデル特定モデルだけの停止ログイン、課金、共通API、ルーティング障害
別のAI事業者へ直接接続1社固有のアプリ・API障害共通CDN、共通クラウド、共通計算拠点の障害
同じモデルをBedrock、Vertex AI、Azure経由でも用意公式Webや一部制御面の障害モデル提供元の中核障害
ローカルまたは自社運用モデル外部回線、外部クラウドの停止自社電源、GPU、運用体制の障害。品質差

APIを使うシステムなら、単なる自動再試行も危険だ。一斉再試行は復旧中の設備へ負荷を集中させ、別サービスへの切り替えも「避難先」を混雑させる。指数バックオフとランダムな待ち時間、サーキットブレーカー、処理待ちキュー、二重実行を防ぐ冪等性キーを組み合わせるべきだ。メール送信、発注、公開、削除など副作用のあるAIエージェント処理は、復旧後に同じ命令が重複実行されない設計が欠かせない。

停止コストは人数と依存率を掛けて見積もる

AI障害の損失は、「影響人数×時給×AIがないと止まる割合×停止分÷60」で概算できる。

例えば、20人、1時間当たり人件費4,000円、AIが使えないと作業の40％が止まる職場を考える。3社の公式記録が重なった93分なら、20×4,000×0.4×93÷60＝49,600円。Claudeの障害と同じ170分なら約90,667円になる。これは売上損失や復旧作業を含まない例示だが、予備経路にいくら払えるかを判断する基準にはなる。

全員分の高額な予備AIを常時契約するより、止まる業務だけを洗い出し、少数の緊急アカウントやローカルモデルを用意する方が安い場合もある。逆に、顧客対応やコード配備がAIに直結しているなら、月額費用だけで冗長化を見送る方が高くつく。

利用者と企業への影響――障害時に取るべき行動

まず公式ステータスを確認し、送信・購入・公開を伴う操作は、結果が分かるまで同じ指示を繰り返さないことが重要だ。

  • 個人利用者：長いプロンプトや下書きはAI画面だけに残さず、手元にも保存する。エラー時は再読み込みを連打せず、公式ステータスで復旧を待つ。
  • 業務利用者：回答の生成元と時刻を記録し、代替AIに移した際の品質差をレビューする。機密情報を予備サービスへ貼る前に、契約と保存条件を確認する。
  • 開発者：タイムアウト、再試行上限、待ち行列、代替モデルへの切り替え条件を事前に決める。障害中に本番設定を即席で変えない。
  • 管理者：「ChatGPTが止まったらClaude」の一行で終わらせず、共通のCDN、クラウド、認証、決済、接続地域まで依存関係を台帳化する。

復旧後にも注意がいる。障害中に保留された会話やジョブが一気に流れ始めると、遅延や二重処理が続く場合がある。公式表示が「復旧」になっても、重要処理は小さなテストから戻すのが安全だ。

よくある疑問

「同じ時間帯だった」という事実だけでは、原因の同一性までは証明できない。

3社はCloudflareを使っているのに、なぜ共通障害ではないのか

利用契約が共通していても、同じ時刻に同じ経路を使っていたとは限らないからだ。 しかもCloudflare側に当該時間帯の世界規模障害は記録されておらず、各社の症状も一致していない。

ClaudeとGrokの原因は同じだったのか

可能性はあるが、Anthropicの確認がない以上、断定はできない。 Colossus 1の提携、開始差4分、166分の重複、SpaceXAIによる提携先への謝罪は状況証拠になる。一方、影響を受けたClaude処理の配置先は公表されていない。

別のAIへ切り替えれば安全か

一社障害には有効だが、共通クラウドや利用者の一斉移動による連鎖までは防げない。 本当に止められない業務では、別会社に加えて別経路・別地域、必要ならローカル処理も検討したい。

今回の障害が示したこと

今回の核心は「AI大手3社が一つの事故で倒れた」ことではなく、独立して見えるAIサービスの裏側に、見えにくい依存関係が増えていることだ。

現時点の一次情報を整理すると、ChatGPTを含む3社共通の単一原因説は支持しにくい。ClaudeとGrokには共通の計算基盤が関与した可能性があるものの、決め手はAnthropicの詳細な障害報告を待つ必要がある。原因が確定するまでは、「確認済み」「推論」「未確認」を混ぜないことが重要だ。

利用者側の備えも、サービス名を複数並べるだけでは足りない。次に確かめたいのは、障害時に予備サービスが本当に別の道を通れるかである。

主な出典

原因未公表の部分は推測で補わず、公式ステータス、公式発表、事後報告を優先して検証した。

タグ

Related Posts

コメントを送信

You May Have Missed