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広報が説明した「問題発生から対策実施まで」と、ステータスページ上でインシデントが「解決」になるまでを分けた。
| サービス | 公式記録の開始（日本時間） | 対策・影響終了 | 公式上の解決 | 公表された範囲 |
|---|---|---|---|---|
| Claude | 9月3日 22:26 | 9月4日 1:16 | 1:23に終了を告知 | Claude.ai、Claude Code、Cowork、APIの一部。複数モデル |
| Grok | 9月3日 22:30 | 9月4日 2:07 | 2:07 | Grok.comのモデル障害。X内Grokも2:05まで影響 |
| ChatGPT | 9月3日 23:43 | 9月4日 0:17に対策 | 1:55 | ChatGPTの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カ国の単純合算 |
|---|---|---|---|
| ChatGPT | 37,908件 | 9,674件 | 47,582件 |
| Claude | 1,324件 | 630件 | 1,954件 |
| Grok | 1,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％だ」とは言えない。使えるのは、利用者が感じた異常の集中度を示す補助指標としてだけだ。
過去事例と比較――本物の「共通インフラ障害」は別の顔を見せる
真の共通基盤障害では、AIに加えて認証、決済、ストレージなど異業種のサービスにも、同じ時刻に似た症状が広がることが多い。
| 事例 | 起きたこと | 今回との違い |
|---|---|---|
| 2024年6月：ChatGPT、Claude、Perplexity | ChatGPTは接続プール設定に起因するデータベース停止。ほかの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の詳細な障害報告を待つ必要がある。原因が確定するまでは、「確認済み」「推論」「未確認」を混ぜないことが重要だ。
利用者側の備えも、サービス名を複数並べるだけでは足りない。次に確かめたいのは、障害時に予備サービスが本当に別の道を通れるかである。
主な出典
原因未公表の部分は推測で補わず、公式ステータス、公式発表、事後報告を優先して検証した。
- OpenAI：Elevated errors across ChatGPT and Codex
- Anthropic：Elevated errors for multiple models
- SpaceXAI：Grok.com incident
- SpaceXAI：Anthropic compute partnership
- WIRED：Nobody Is Saying Why OpenAI and Anthropic Had Outages Today
- The Register：ChatGPT, Claude, and Grok outages
- Cloudflare：Status history
- Cloudflare：2025年6月12日の障害事後報告
- Cloudflare：2025年11月18日の障害事後報告
コメントを送信