「みなづちAI」はリンクフリーです。リンクを行う場合の許可や連絡は不要です。引用する際は、引用元の明記と該当ページへのリンクをお願いします。
ChatGPTとClaudeとGrokが同時に落ちた。3社とも原因を書いていない
みなづちです。
日本時間9月3日の夜から4日の未明にかけて、ChatGPTとClaudeとGrokが相次いで止まりました。
日本のメディアでは、ITmedia AI＋が9月4日0時48分に第一報を出しています。見出しは「複数のAIサービスで障害発生」。本文の締めは「原因はいずれも不明」でした。
海外では「3社ともAzureを使っているから共通のクラウド障害ではないか」という説明が広まりました。
ところが、その説をCloudflareの広報が名指しで否定しています。
Cloudflare is not experiencing any significant service disruptions at this time. Our services are operating normally, and any reporting that deviates from this is incorrect.
「当社は現在、重大なサービス障害を起こしていない。当社のサービスは正常に稼働しており、それと異なる報道はすべて誤りである」。The Registerの取材に対する回答です。
そこで3社のステータスページのJSONとRSSを直接取得して、秒単位で並べ直しました。
3社が同時に落ちていたのは、1時間33分だけでした。
そして原因についてです。3社とも、自社のステータスページに原因を書いていません。1社だけが公式Xで「場所」を明かしました。クラウド事業者ではなく、テネシー州メンフィスにある自社の計算センターです。
本記事では、以下のポイントから解説します。
- 3社の障害が始まった時刻と終わった時刻を、秒単位で突き合わせた結果
- 「共通のクラウド障害」説が、4社のステータスを全部見ても裏づけられないこと
- 1社だけが「原因」ではなく「場所」を書き、メンフィスの名前を出したこと
- そのメンフィスの拠点群を、Anthropicが月12.5億ドルで借りていること
- 「Azureが原因」と断定した記事の典拠が、利用者の投稿1件だったこと
- 3社の障害報告に、謝罪の言葉が1語もないこと
目次
結論：3社とも原因を書かず、1社だけが場所を書いた
先に結論を書きます。3社の対応は横並びではありませんでした。
3社とも、自社のステータスページには原因（root cause）を書いていません。
xAI（現在の社名表記はSpaceXAI）だけが、日本時間9月4日4時38分16秒に公式Xで謝罪し、「メンフィスの計算センターの障害」と書きました。ただしこれは障害が起きた場所であって、何が壊れたのかは明かしていません。同じ投稿で、影響を受けた「コンピュートパートナー」にも謝っています。
OpenAIとAnthropicは、報道各社に配った広報コメントで「ルーティングエラー」「インフラの問題」と述べただけです。
そしてAnthropicは、SpaceXのメンフィス圏の計算資源に月12.5億ドルを払っています。SpaceXが証券取引委員会に出した目論見書に、GPU約32万5,000基分と書かれています。
ただし「同じ建物が落ちて2社が止まった」とは書けません。Anthropic自身がClaudeを3種類のハードウェアと3つの経路に分散していると公表しており、Anthropicは9月3日の障害とメンフィスの関係について何も述べていないからです。
筆者の視点：「共通のクラウド障害」で書こうとして4回崩れた
この記事も、最初に立てた見立てが検証のたびに崩れました。結果として正確になりました。
「AzureかCloudflareが落ちたのだろう」から始めた
3社がほぼ同時に止まったと聞いたとき、最初に思ったのは「どこか1社のインフラが落ちたのだろう」でした。海外メディアの多くも同じ書き方をしています。
Cloudflareのステータス履歴を開いて、最初の見立てが崩れました。9月3日に始まった障害は4件あり、そのどれも障害の時間帯と重なっていません。8月から継続していた2件がまたがってはいましたが、R2とWARPに限られた話でした。
そのうえ広報が「それと異なる報道はすべて誤り」とまで言っていました。
「では3社とも原因を隠している」も崩れた
次に「3社とも原因を書いていない」という軸で書こうとしました。ステータスページを読むかぎり、そう見えたからです。
xAIの公式Xを開いて崩れました。SpaceXAIは原因の場所を名指しし、しかも他社に謝っていました。「3社とも隠している」は成立しません。
「メンフィスが3社を落とした」も成立しなかった
3つ目です。「メンフィスの1拠点が3社を落とした」と書こうとしました。ここも止まりました。
OpenAIの障害が始まったのは、Grokの1時間13分後です。しかもOpenAIの被害はChatGPTとCodexに限られ、api.openai.comの12コンポーネントは影響対象に入っていません。メンフィスと結びつける根拠が見つかりませんでした。
「Colossus 1という同じ1棟」も崩れた
4つ目です。AnthropicがColossus 1を全量借りているなら、そこにGrokは載っていないことになります。
SpaceXの目論見書を開いて確定しました。Grok-5が学習中なのはColossus 1ではなくCOLOSSUS IIで、Anthropicの契約はその両方にまたがっていました。「1棟が落ちて2社が止まった」という絵は描けません。
残ったのは「2社はメンフィス圏の同じ拠点群でつながっている。ただし単一拠点では説明できない」という、歯切れの悪い形です。
障害は日本時間9月3日21時37分から4日2時9分まで続いた
まず時系列です。3社のステータスAPIから、秒単位で取り出しました。
Claudeは9月3日だけで3回エラー増加を報告している
Anthropicのステータス履歴を全件取得すると、日本時間9月3日にClaudeは3回エラー増加を報告しています。
- 9月3日6時5分から6時19分（Sonnet 5、影響時間は自己申告）
- 9月3日21時37分31秒から21時56分26秒（Sonnet 5、18分55秒）
- 9月3日22時26分4秒から9月4日1時16分（複数モデル、2時間49分56秒）
3件目が今回の大きいほうです。1件目と2件目はどちらもSonnet 5だけの障害で、3件目にSonnet 5は含まれていません。
Grokは22時30分ちょうど、Claudeの3分56秒後に始まった
xAIのステータスRSSを見ると、9月3日に立ったインシデントは8サービス分あります。
8件とも開始時刻が「Thu, 03 Sep 2026 13:30:00 GMT」ちょうどで、秒がゼロです。日本時間では22時30分00秒。Claudeの3件目（22時26分4秒）の3分56秒後にあたります。
なお秒がぴったりゼロなのは、監視システムの自動検知ではなく、人が丸めて入力した可能性を示しています。
ChatGPTは1時間13分遅れて23時43分から
OpenAIの障害は、公式ページの表示で日本時間9月3日23時43分に始まっています。Grokの1時間13分後です。
復旧は9月4日1時55分49秒。3社のうちいちばん早く終わりました。
最後まで残ったのはxAIで、8サービスの復旧は9月4日2時4分59秒から2時9分14秒にかけて段階的でした。全体では4時間31分42秒にわたって、どこかが落ちていたことになります。
3社が同時に落ちていたのは1時間33分。4時間半ではない
「4時間半ダウン」ではありません。重なっていた時間はもっと短いです。
各社が自分で認めた影響時間を重ねる
3社が公式に認めている影響時間を、そのまま重ねます。
- Anthropic：9月3日22時26分4秒から9月4日1時16分
- xAI：9月3日22時30分から9月4日2時4分59秒以降
- OpenAI：9月3日23時43分から9月4日1時55分49秒
いちばん遅く始まったのはOpenAIの23時43分、いちばん早く終わったのはAnthropicの1時間16分です。
その差は1時間33分。これが3社そろって落ちていた時間です。
定義を変えると1時間18分から1時間40分まで動く
ここは定義で数字が動きます。ステータスページに投稿された時刻（OpenAIは23時58分23秒）を起点にすると1時間17分37秒。Anthropicの解決記録（1時間23分12秒）を終点にすると1時間40分12秒です。
記事では「各社が自ら認めた影響時間の重なり＝1時間33分」を採ります。どの定義でも「4時間半」にはなりません。
2社ずつなら重なりはもっと長い
AnthropicとxAIの2社は、22時30分から1時間16分まで2時間46分重なっています。OpenAIとxAIは23時43分から1時間55分49秒まで2時間12分49秒。
3社そろっていた時間だけが、突出して短いことになります。
SpaceXAIが書いたのは原因ではなく、障害が起きた場所だった
3社のなかで唯一、自分の発信で障害の中身に触れたのがこの投稿です。
SpaceXAI公式Xの謝罪投稿の全文
日本時間9月4日4時38分16秒、公式アカウント@SpaceXAIの投稿です。
We are sorry for the issues you may have experienced with Grok following an outage at our Memphis compute center this morning. We’d also like to apologize to our impacted compute partners.
All systems have now been restored and are functioning nominally.
「今朝、当社のメンフィスの計算センターで障害が発生し、Grokでご不便をおかけしたことをお詫びします。影響を受けたコンピュートパートナーの各社にもお詫びします。すべてのシステムは復旧し、正常に稼働しています」
その24分43秒後、日本時間5時2分59秒にイーロン・マスク氏が続けています。
And we are taking corrective action to ensure this does not happen again
「そして再発しないよう是正措置を取っています」。
書かれているのは場所であって、原因ではない
ここは正確に区別する必要があります。
投稿にあるのは「メンフィスの計算センターで障害が発生した」という場所だけで、何が壊れたのかは書かれていません。Engadgetも「SpaceXAI didn’t disclose what caused the issue in Memphis」と書いています。
3社のうち、原因そのものを自分で公表した会社は1社もありません。
ステータスページには「メンフィス」の文字がない
ここは主語を分けて書く必要があります。
xAIのステータスページ（status.x.ai）の9月3日の8件には、「Memphis」も「compute」も1件も出てきません。更新は各サービス2回だけで、文面は「Grokに問題が発生しています。できるだけ早く復旧させます」と「復旧しました。トラフィックは正常に戻りました」のみです。
原因が書かれているのはXの投稿のほうで、ステータスページではありません。
「コンピュートパートナー」が誰なのかは書かれていない
投稿は「impacted compute partners」としか書いておらず、相手を名指ししていません。
xAIから計算資源を借りている側なのか、xAIに貸している側なのかも書き分けていません。読み手が補うしかない一文です。
AnthropicはSpaceXに月12.5億ドル払って計算資源を借りている
その「コンピュートパートナー」の候補として、公表されている契約があります。
5月6日の発表は300メガワット超・22万GPU
Anthropicは2026年5月6日に、自社ニュースでこう発表しています。
We’ve signed an agreement with SpaceX to use all of the compute capacity at their Colossus 1 data center. This gives us access to more than 300 megawatts of new capacity (over 220,000 NVIDIA GPUs) within the month.
「SpaceXと契約し、同社のColossus 1データセンターの計算容量を全量使うことになった。これにより300メガワット超（NVIDIA GPU 22万基超）の新規容量を今月中に確保する」。
SECの目論見書では32万5,000基・2拠点にまたがる契約
ところが、SpaceXがアメリカ証券取引委員会に提出した新規株式公開の目論見書（Form 424B4、2026年6月12日提出）を開くと、話が大きくなります。
in May 2026, we entered into Cloud Services Agreements with Anthropic PBC (“Anthropic”) … with respect to access to compute capacity across COLOSSUS and COLOSSUS II. Compute capacity provided includes approximately 325,000 NVIDIA GPUs … the customer has agreed to pay us $1.25 billion per month through May 2029
契約は「Colossus 1の全量」ではなく、COLOSSUSとCOLOSSUS IIの両方にまたがっています。GPUは約32万5,000基、金額は月額12.5億ドル、期間は2029年5月までです。財務注記によれば署名日は5月3日でした。
1ドル160円で換算すると、月額はおよそ2,000億円になります。
発表文にはClaude ProとClaude Maxの名前が出てくる
同じ5月6日の発表の目的部分にこうあります。
This additional capacity will directly improve capacity for Claude Pro and Claude Max subscribers.
Colossus 1に紐づけて書かれているのは、Claude ProとClaude Maxの提供容量の改善です。APIのレート上限の引き上げは、SpaceX以外の複数の契約との合算成果として書かれています。
用途についても、xAI側は「学習・微調整・推論・高性能計算」と幅広く書いており、推論専用とは書かれていません。
発表2ページに「メンフィス」の文字はないが、別ページにはある
ここは主語を分ける必要があります。
Anthropicの発表ページ（151,621バイト）とxAIの発表ページ（168,630バイト）の生HTMLを取得して検索しました。両ページとも「Memphis」「Tennessee」が0件です。どちらも「Colossus 1」としか書いていません。
ただし「会社として伏せている」わけではありません。xAIには「x.ai/memphis」というページがあり、「Memphis is home to Colossus」と書かれています。SECの目論見書にも住所まで載っています。書いていないのは、5月6日の発表2ページだけです。
「同じ1棟が落ちた」は成立しない。SpaceX自身の記述で
ここまで来て、いちばん書きたかった筋書きが崩れました。
Colossus 1は全量がAnthropic向けだと書かれている
Anthropicの発表は「Colossus 1の計算容量を全量使う」と書いています。全量がAnthropicに貸し出されているなら、その建物にGrokは載っていないことになります。
「Colossus 1が落ちて、ClaudeとGrokが同時に止まった」という説明は、ここで論理的に成立しなくなります。
Grok-5はCOLOSSUS IIで学習中だとSECに書いてある
同じ目論見書に、こう書かれています。
We have the ability to use compute resources to support our proprietary AI applications (such as Grok-5, which is currently being trained at COLOSSUS II)
SpaceX自身の次期モデルが動いているのは、Colossus 1ではなくCOLOSSUS IIのほうです。
そしてAnthropicの契約は、そのCOLOSSUS IIにもまたがっています。両社が同居しうるのは、Colossus 1ではなくCOLOSSUS IIの側ということになります。
「メンフィスの計算センター」に該当する棟は2つある
目論見書の用語定義と物件の記述はこうです。
“COLOSSUS” refers to our flagship data center, located on Paul R. Lowry Road in Memphis, Tennessee.
the COLOSSUS II facilities are located on Tulane Road in Memphis, Tennessee and on Stateline Road in Southaven, Mississippi
メンフィス市内に該当する棟は、Paul R. Lowry RoadのCOLOSSUSと、Tulane RoadのCOLOSSUS IIの2つです。ミシシッピ州なのはSouthavenの棟だけです。
SpaceXAIの投稿は「our Memphis compute center」としか書いていないので、どちらの棟なのかは特定できません。
Anthropicは3種類のハードと3つの経路を公表している
単一拠点で説明しようとすると、もう1つ壁に当たります。
技術ポストモーテムに書かれている構成
Anthropicが公開している技術ポストモーテムに、提供の構成が書かれています。
We serve Claude to millions of users via our first-party API, Amazon Bedrock, and Google Cloud’s Vertex AI. We deploy Claude across multiple hardware platforms, namely AWS Trainium, NVIDIA GPUs, and Google TPUs.
自社API・Amazon Bedrock・Google Cloud Vertex AIの3経路、AWS Trainium・NVIDIA GPU・Google TPUの3種類のハードウェアです。
5月6日の発表にも「AWS Trainium、Google TPU、NVIDIA GPUという幅広いAIハードウェアでClaudeを学習・実行している」と書かれています。
落ちたモデルの並びも、拠点説と合わない
影響を受けたのはOpus 5・Opus 4.8・Opus 4.6で、そのあいだのOpus 4.7と下位のOpus 4.5は無事でした。
世代とハードウェアが単純に対応しているなら、この飛び石の並びにはなりにくいはずです。0時25分の時点でOpus 4.8とOpus 5だけが残ったという段階的な回復も、建物ごと止まった動き方とは違って見えます。
なお利用者側には、HTTP 529の「Overloaded」エラーが出ていたという報告があります。容量が足りない側の症状です。
ステータスページが見ているのはAnthropic運営分だけ
もう1点。status.claude.comのコンポーネントは6つで、claude.ai・Claude Console・Claude API・Claude Code・Claude Cowork・Claude for Governmentです。
Amazon Bedrock経由やGoogle Vertex AI経由のClaudeは、この監視の対象外です。「Claudeが落ちた」と書くときの主語は、ここまでが限界になります。
落ちたClaudeのモデルは5行の一覧に書かれていた
Anthropicは影響したモデルを、途中で明示的に列挙しています。
Anthropicが挙げた「網羅的な一覧」の逐語
日本時間9月3日22時50分26秒の更新です。
An exhaustive list of affected models: Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8, Opus 4.6.
スラッシュを展開すると、Mythos 5.1、Fable 5.1、Mythos 5、Fable 5、Opus 5、Opus 4.8、Opus 4.6の7モデルです。
Sonnet 5、Haiku 4.5、Opus 4.7、Opus 4.5は入っていません。Opus系が全滅したのではなく、飛び石で落ちています。
最後まで残ったのは上位2モデル
9月4日0時25分20秒の更新はこうです。
The only affected models right now are Opus 4.8 and Opus 5. The rest of the models have recovered to baseline error rate.
「現時点で影響が残っているのはOpus 4.8とOpus 5だけ。ほかのモデルはベースラインのエラー率に戻った」。
最上位のモデルほど回復が遅れました。ただしその理由は、Anthropicのステータスページの7つの更新にも、報道各社に配られた広報コメントにも書かれていません。
影響したのは4つのコンポーネント
インシデントに紐づくコンポーネントは、claude.ai、Claude API（api.anthropic.com）、Claude Code、Claude Coworkの4つです。
Anthropicのステータスページには全部で6つのコンポーネントがあり、Claude Console（platform.claude.com）とClaude for Governmentは影響対象に入っていません。
また状態の遷移先は「partial_outage」であって「major_outage」ではありません。全断ではなく部分障害という扱いです。
OpenAIの被害はChatGPTとCodexの19コンポーネントに限られた
OpenAI側の構図はまったく違いました。
19のコンポーネントが影響を受けた
インシデントページの表示は「ChatGPT 15 affected components」「Codex 4 affected components」です。
ChatGPTグループは会話、ログイン、ChatGPT Work、検索、ファイルアップロード、音声モード、GPTs、画像生成、Deep Research、Agent、ChatGPT Atlas、Sites、コネクター／アプリなど15項目すべて。Codexグループも4項目すべてです。
api.openai.comの12件は影響対象に入っていない
一方、api.openai.comのAPIsグループ（Chat Completions、Responses、Realtimeなど12コンポーネント）は、影響対象として掲示されていません。
ただし「APIは無傷」と書くと言い過ぎになります。落ちた19件のなかには、Codexグループの「Codex API」と、ChatGPTグループの「Compliance API」が含まれています。無傷だったのは、いわゆるOpenAI APIプラットフォームのほうです。
AnthropicとxAIがAPIそのものを明示的に被害に含めたのとは対照的です。APIを業務で叩いていた日本企業への影響は、3社で非対称でした。
自己申告の深刻度も3社でばらばら
Anthropicはimpactを「major」、xAIは全8サービスを「outage」としています。
OpenAIは「minor」でした。ページの表示ラベルは「Degraded performance」です。Downdetectorへの報告数はOpenAIが桁違いに多かったのに、自社の分類はいちばん軽いという形になっています。
OpenAIのステータスは表示時刻が15分23秒巻き戻されている
OpenAIのJSONを読むと、表示時刻と記録時刻が食い違っていました。
display_atとcreated_atが違う
最初の更新は、記録が9月3日14時58分23秒（協定世界時）、表示が14時43分00秒ちょうどです。差は15分23秒。
2番目の更新は、記録が15時50分41秒、表示が15時17分00秒ちょうど。差は33分41秒です。
OpenAIの障害の開始時刻は3つある
やっかいなのは、OpenAI自身のデータが別のことも言っている点です。
インシデントの内部データには、コンポーネントの状態の推移が記録されています。そこには「14時43分00秒から14時58分23秒907の間は、どのコンポーネントも operational だった」と書かれています。影響コンポーネントの表示欄も「14時58分から16時55分」です。
つまりOpenAIの障害開始には3つの数字があります。表示上の14時43分、機械記録の14時58分23秒、そして第三者監視のStatusGatorが最初に異常を検知した14時47分です。どれを採るかで、障害の長さは1時間57分から2時間13分まで動きます。
広報コメントの時刻と表示時刻が一致する
OpenAI広報のコメントはこうでした。The RegisterとDecryptに同じ文言が渡されており、各社への定型コメントです。
A routing error starting around 7:43 am PT on Thursday, September 3 made ChatGPT and Codex unavailable for some users across platforms. As of about 8:17 am PT on Thursday, a solution was successfully implemented and is continuing to be monitored.
米太平洋夏時間の7時43分は協定世界時14時43分、8時17分は15時17分です。ステータスページの表示時刻と分単位で一致します。
つまりOpenAIは影響開始時刻も原因も把握していて、時刻だけをステータスページに反映し、原因は書かなかったことになります。
「ルーティングエラー」は自社のどこにも書かれていない
ここも主語を明示します。
status.openai.comの当該インシデントの更新3件、公式ブログ、公式Xのいずれにも「routing error」という語はありません。この説明が存在するのは、報道各社に配られた広報コメントの中だけです。
OpenAIには事後報告を出す運用がある
ただし「OpenAIは原因を書かない会社」ではありません。
ステータスページの履歴を見ると、直近80件のうち9件に、Summary・Impact・Root Cause・Resolution・Prevention and Improvementsという形式の正式な事後報告が後から添付されています。8月19日から20日の認証障害では「デプロイの際に、認証を支える系に互換性のない2つの設定が適用された」と書かれています。
9月4日時点で、9月3日の障害にはまだ添付されていません。続報はこの履歴ページに出ます。AnthropicとxAIには、同等の公開事後報告の仕組みが見当たりません。
Cloudflareは「その報道は誤り」と広報が明言した
共通原因説の中心にあったのがCloudflareでした。
当日始まった障害は4件で、いずれも時間帯が外れる
CloudflareのインシデントAPIを取得しました。9月3日（協定世界時）に始まった障害は次の4件です。
- 1時49分18秒（R2の503エラー、西北米）
- 5時30分から6時30分（シアトルのHTTP 522エラー）
- 9時21分19秒から9時36分2秒（香港のHTTP 5xxエラー）
- 23時35分48秒から（Workers Buildsのキュー遅延）
障害の時間帯は13時26分から17時9分です。この4件はどれも重なっていません。
ただし8月から継続中の2件が時間帯をまたいでいた
ここは正確に書く必要があります。8月から続いていたインシデントが2件、障害の時間帯にまたがっていました。
1件目はR2のカスタムドメインで、Firefoxからの接続がHTTP/3で失敗する件です。8月31日18時47分5秒に始まり、9月3日15時14分39秒に監視中へ移り、19時32分54秒に解決しています。監視中に移った時刻は、障害の時間帯のちょうど真ん中です。
2件目はWARPの位置情報の誤判定で、8月27日から未解決のままでした。
どちらもR2とWARPに限られ、3社のAPIが通る経路の話ではありません。「重なるものはなかった」ではなく「重なったが無関係だった」が正確です。
なお同じ時間帯には、Cloudflareのエッジ拠点の計画メンテナンスが4件動いていました。そのうち1件はテネシー州ナッシュビル（BNA）です。xAIの計算センターと同じ州ですが、単一拠点の定期メンテナンスであって、両者に関係はありません。
Cloudflare広報の否定は名指しに近い
冒頭にも引いた回答をもう一度置きます。
Our services are operating normally, and any reporting that deviates from this is incorrect.
「それと異なる報道はすべて誤りである」。企業広報のコメントとしてはかなり強い言い方です。
それでもCloudflareは3社の経路に入っている
念のため書き添えます。Anthropicの公式ドキュメントには、リクエストサイズ超過について次の記述があります。
On the direct Claude API, Cloudflare returns this error before the request reaches the API servers.
Claude APIの前段にCloudflareがいることは、Anthropic自身が書いています。Cloudflareを使っていないという話ではなく、Cloudflareが落ちていないという話です。
AWS・Google Cloud・Azureの当日のステータスを全部見た
残る3つのクラウドも、一次情報で確認しました。
Google Cloudは9月1日の1件だけ
Google Cloudのインシデント一覧（incidents.json）を取得しました。9月2日から4日の記録は0件です。直近は9月1日14時44分から18時52分のus-central1-bのネットワーク劣化で、これは2日前の別件です。
AWSは同じ日に落ちているが、時間帯が4時間ずれている
AWSのステータスRSSには、9月3日の項目が4件あります。ただし内容はこうです。
Between 2:12 PM and 3:18 PM PDT, we experienced increased API error rates affecting the STS AssumeRoleWithSAML and AssumeRoleWithWebIdentity APIs in the US-WEST-2 Region.
米太平洋夏時間14時12分から15時18分は、協定世界時21時12分から22時18分。AI3社の障害が終わった4時間3分あとです。
そしてもう1点。同じ通知にはこう書かれています。
The root cause was determined to be due to an issue with an STS subsystem responsible for communicating with external identity providers.
「根本原因は、外部のIDプロバイダーとの通信を担うSTSのサブシステムの問題であると判明した」。
AWSは解決の通知に、原因まで書いています。ただし投稿時刻は米太平洋夏時間9月3日17時7分54秒で、協定世界時では9月4日0時7分54秒。日本時間では9月4日9時7分です。SpaceXAIがメンフィスの障害を公表したのは協定世界時9月3日19時38分16秒なので、xAIのほうが4時間29分早いことになります。
Azureは「載っていない」と「なかった」を分けて書く必要がある
Azureのステータスフィードは、9月4日2時33分時点で項目が0件でした。事後レビュー（PIR）の一覧にも、9月3日の記載はありません。最新のPIRは7月23日の米国西部の件です。
ただしAzureは、広範囲の障害に限ってPIRを公開する運用です。PIRがないことは障害がなかったことの証明になりません。
さらに厄介なことに、障害の最中のAzureのステータス表示は、いま誰にも確認できません。Internet Archiveに残る9月3日のスナップショットは18時58分59秒の1件だけで、障害の時間帯（13時26分から17時9分）の保存記録が存在しないからです。その1件では「現在アクティブなイベントはありません」と表示されていました。
The Register自身も、クラウドのステータスに留保をつけている
同じことをThe Registerも書いています。原文はこうです。
Meanwhile, the three major US cloud computing providers – AWS, Google Cloud, and Microsoft Azure – show no sign of relevant technical difficulties on their respective status pages, which don’t always reflect problems in a timely manner.
「一方、米国の主要クラウド3社（AWS、Google Cloud、Microsoft Azure）は、それぞれのステータスページに関連する技術的問題の兆候を示していない。ただしそれらのページは、問題を必ずしも遅滞なく反映するわけではない」。
後半の留保をつけたまま引くのが正確です。ステータスページの沈黙は、無罪の証明ではありません。
第三者の観測網にも、この時間帯の異常はない
念のため、企業のステータスページ以外も見ました。
インターネットの障害観測プロジェクトIODA（ジョージア工科大学）のAPIから、9月3日13時26分から17時50分のアラートを全件取得しました。317件のうち、Microsoft・Amazon・Google・CloudflareのASNに該当するものは0件です。米国分は小規模なISPの平常時のノイズだけでした。
ただしこれも「探して見つからなかった」であって、「存在しないことを確認した」ではありません。
「Azureが原因」説の出所は、ユーザー投稿1件だった
この説がどこから生まれたのかを、遡って確かめました。
Tech Timesの見出しは「Azure Is at Fault」
米メディアTech Timesが9月3日に出した記事の見出しがこれです。
Gemini Survived When ChatGPT, Claude, and Grok Collapsed: Azure Is at Fault
副題は「Azure East US failed Thursday; Gemini stayed up on Google Cloud, confirming Azure dependency」。「Azureのせいだ」「Azure東USが落ちた」と断定しています。
本文にはこうも書かれています。
ChatGPT, Claude, and Grok all run on Microsoft Azure.
Anthropic自身が5月にColossus 1の全量借り上げを発表していることには、触れていません。
典拠はStatusGatorへのユーザー投稿1件だけ
その断定の根拠として挙げられているのが、次の一文です。
StatusGator recorded a user-submitted report on September 3 stating that Azure’s East US region experienced ingress failures at 10:26 a.m. PT (1:26 p.m. ET).
StatusGatorに寄せられた利用者の投稿1件です。Microsoftの発表でも、Azureのステータス記録でもありません。
引用された時刻が、記事の公開より20分57秒あと
ここが引っかかりました。
記事のHTMLに埋め込まれた公開日時は「2026-09-03T17:05:03+00:00」、米東部夏時間で13時5分3秒です。一方、典拠として引かれた事象の時刻は13時26分（米東部夏時間）。記事の公開より20分57秒あとです。
更新日時も公開日時と同じ値で、あとから書き足した記録は残っていません。
StatusGatorの直近24時間の投稿は3件だった
そのStatusGatorのAzureのページを開きました。9月4日時点の表示は「3 outage reports in the last 24 hours」です。
内訳はこうでした。
- 英国：「Virtual machiens are not powering on」（原文ママ）
- アラブ首長国連邦：「says “can’t reach the page”」
- フィリピン・マニラ首都圏：「claude」
3件目の投稿は、本文が「claude」の一語だけです。Claudeが使えなくて困った人が、Azureの報告フォームに書き込んだように見えます。
これが「Azureへの障害報告」として集計されます。利用者の自己申告を集めた数字が何を意味するのか、この1件がよく表しています。
Googleは9月3日のGemini障害を1件も記録していない
4社目のGeminiがどうだったかは、書き方に注意が要ります。
Googleの公式の記録には1件もない
Google Cloudのインシデント記録にも、Google Workspaceのステータスダッシュボードにも、9月3日のGemini関連の記録は1件もありません。9to5Googleも「Geminiは影響を受けていないようだ」と書いています。
ただしGoogleは、落ちたとも落ちていないとも表明していません。公式に否定したわけではないので、「Geminiは無事だった」と断定はできません。
報告はむしろGrokより40分早く始まっている
Downdetectorには同じ日、Geminiについても約500件の報告が出ていました。ChatGPTは3万7,000件超、Claudeは約1,324件、Grokは約1,365件です。
そしてGulf Newsによれば、Geminiの報告が増え始めたのは協定世界時12時44分ごろ、日本時間21時44分ごろです。Claudeの2件目（22時26分）やGrok（22時30分）より40分以上早いことになります。
「メンフィス起点で3社が同時に落ちた」という単線の筋書きとは、むしろ合いません。
落ちていないサービスにも報告は出る
Downdetectorの数字は利用者の自己申告であって、障害の証拠ではありません。「ChatGPTが落ちている」と気づいた人が、ついでに他のサービスも報告する動きが混ざります。
ChatGPTだけ桁が2つ違うのは利用者数の差であって、障害の深刻さの差ではありません。OpenAI自身の分類は「minor」、Anthropicは「major」です。
「10月開始だから9月は無関係」とも書けない
もう1つ、時期の話があります。
SpaceXがアメリカ証券取引委員会に提出した書面（Form FWP）によれば、Googleとの契約は約11万基のNVIDIA GPUを対象に、2026年10月から2029年6月まで月額9億2,000万ドルです。
ただし同じ文に「9月まで割引料金で容量を立ち上げていく」と書かれています。9月3日時点でGoogleがSpaceXのGPUを一部使っていた可能性は、原文から排除できません。「だからGeminiは無事だった」という説明は成立しません。
巻き込まれたのはCursorとGitHub Copilotだった
上流が落ちると、下流のサービスが止まります。当日の記録が残っていました。
Cursorは3社を別々のインシデントとして記録した
先に断っておくことがあります。Cursorは2026年8月にSpaceXに買収されており、いまはSpaceXの傘下です。OpenAIは9月3日の6日前、8月28日に「SpaceXによるCursor買収を受けた当社の判断」という文書を出し、Cursorへのモデル提供を11月12日で打ち切ると通知しています。中立の第三者ではありません。
そのうえで、CursorのステータスAPIを取得すると、9月3日に3件のインシデントが立っています。
- Grokの全モデル：13時41分から17時7分（critical）
- Anthropicのモデル：14時17分7秒から16時31分46秒（major）
- OpenAIのモデル：15時17分5秒から17時5分20秒（minor）
Cursorは3社を1つの事象として扱っていません。3つの別々の上流障害として記録しています。
Anthropic分の説明文はこうです。
An upstream Anthropic issue is causing elevated errors for Fable 5.1, Fable 5, Opus 5, Opus 4.8, and Opus 4.6 requests.
Anthropicが出した一覧とモデル名が一致します。
GitHubはGrokだけを記録した
GitHubのステータスには「Incident with Grok Copilot AI Model Provider」が1件だけあります。14時17分27秒から17時11分47秒、impactはminorです。
We are experiencing degraded availability for the Grok 4.6 model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider.
GitHub Copilotで落ちたのはGrok 4.6とGrok 4.5だけで、ClaudeとOpenAIのモデルは記録されていません。
原因分析を約束したのはGitHubだけ
そのGitHubの最後の更新がこれです。
This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.
「詳細な原因分析は、まとまり次第共有します」。巻き込まれた側が、原因を出した側より先に説明を約束しています。
3社のステータス更新に、謝罪の言葉は1語もなかった
文面そのものを機械的に数えました。
謝罪に関する6つの語を数えた結果
3社の9月3日のステータス更新の本文だけを抜き出して、語を数えました。Anthropicが1,087文字、OpenAIが430文字、xAIが8,552文字（8サービス分）です。
「sorry」「apologize」「regret」「inconvenience」「thank」「patience」は、3社とも0件でした。
Anthropicに1件だけあった「cause」は「We have identified the cause」の1語で、中身は書かれていません。
GitHubのほうが謝意を書いている
一方、巻き込まれたGitHubの解決通知には「Thank you for your patience and understanding」があります。
上流の3社は謝らず、下流のGitHubが謝意を書いた形です。
なおSpaceXAIの謝罪はXの投稿にあり、ステータスページにはありません。ステータスページだけを見ていた人には届いていません。
「異例」なのか。3社の34日分のインシデントを数えた
多くの記事が「異例」「rare」と書いています。数えてみました。
8月1日から9月3日までの件数
3社のステータスAPIから、2026年8月1日から9月3日（協定世界時）の34日分を数えました。
- Anthropic：31件（major 10件、critical 1件）
- OpenAI：24件（major 2件）
- xAI：実質2事象
AnthropicとOpenAIは、ほぼ毎日どこかで障害を出しています。「異例」なのは、xAIが障害を公表する日が34日中2日しかないことのほうです。
2社同時なら週1回のペースで起きている
直近1か月で、AnthropicとOpenAIが同時に落ちていた時間帯を計算しました。6区間、合計約6時間です。今回を除いても5回あります。
「2社同時」は日常茶飯事でした。
3社同時も初めてではない。6月以降で4日ある
一次データが連続してそろう2026年6月8日以降で、3社が同一日にインシデントを出したのは4日あります。6月17日、7月2日、7月7日、そして9月3日です。
ただし前の3回は、xAI側がAPIや画像生成のエンドポイントだけでした。Grok本体（Web・iOS・Android・X内）まで落ちたのは9月3日だけです。
重なった時間も、前3回が16分から26分だったのに対し、今回は1時間33分でした。
優先枠を買っていた顧客のモデルも、9月3日に落ちている
「優先枠を買って備える」という定番の対策を確かめました。逆の結果が出ました。
Anthropicは新規購入を止めている
Anthropicのサービスティアのドキュメントの冒頭に、警告があります。
Priority Tier capacity commitments are no longer available for purchase.
優先枠の容量コミットは、もう購入できません。いつから購入不可になったのかをAnthropicは公表しておらず、アーカイブで挟み込むと2026年6月15日にはこの警告がなく、6月30日にはありました。
稼働率の数字は「目標」であって保証ではない
同じページにはこうあります。
Priority Tier targets 99.5% uptime with prioritized computational resources.
日本語版のドキュメントも「99.5%の稼働率を目標としています」と訳しています。targetsであって、契約上の保証ではありません。クレジットなどの救済手段の記載もありません。
そもそも優先枠の効能は、混雑時の「server overloaded」エラーを減らすことです。インフラ障害のときの可用性を約束したものではありません。
Opus 4.8とOpus 4.6は優先枠の対象なのに落ちた
ここが逆でした。除外リストの逐語はこうです。
Priority Tier is supported on all available Claude models except Claude Fable 5.1, Claude Mythos 5.1, Claude Mythos 5, Claude Mythos Preview, Claude Opus 5, and Claude Sonnet 5.
除外されているのはFable 5.1、Mythos 5.1、Mythos 5、Mythos Preview、Opus 5、Sonnet 5の6つです。
9月3日に落ちたOpus 4.8とOpus 4.6は、この6つに入っていません。つまり優先枠の対象モデルです。しかも0時25分の時点で最後まで残っていたのが、そのOpus 4.8でした。
最新のモデルは優先枠の対象外、対象内のモデルは落ちる。どちらを選んでも、可用性の約束は手に入りません。
Anthropicの公式フォールバックは障害では発火しない
「別のモデルに自動で切り替えればいい」という対策も、確認が要ります。
Anthropicのドキュメントに発火条件が書かれている
Anthropicのフォールバック機能のドキュメントに、こうあります。
Only a safety classifier decline triggers the fallback. A rate limit, overload, or server error on the requested model is returned to you as-is.
フォールバックが起きるのは安全性の分類器が拒否したときだけで、レート上限・過負荷・サーバエラーはそのまま返ってきます。
つまり9月3日のような障害では作動しません。
障害で効くのはClaude Code側の設定
一方、Claude Codeにはこう書かれた機能があります。
When the primary model is overloaded, unavailable, or returns another non-retryable server error, Claude Code can switch to a fallback model
主モデルが過負荷・利用不能・再試行不能なサーバエラーを返したとき、フォールバックモデルに切り替わります。指定できるのは最大3モデルで、切り替えはそのターンかぎりです。
フォールバックは負荷がかかると拒否に劣化する
同じドキュメントには、退避先が混んでいたときの挙動も書かれています。
If a fallback model is rate limited or overloaded, the fallback attempt is not made and the preceding refusal is returned instead.
退避先がレート上限や過負荷に当たっていると、フォールバックは試みられず、もとの拒否がそのまま返ります。混んでいるときほど効かない仕組みです。
SDKは2回まで自動で再試行する
APIのエラードキュメントにはこうあります。
The official SDKs automatically retry transient failures (such as connection errors, rate limits, and 5xx server errors) with exponential backoff, twice by default
公式SDKは既定で2回まで指数バックオフ付きで再試行します。3時間の障害では足りませんが、数分の障害なら吸収されます。
3社のステータスページに日本語版はなく、通知も英語だけ
深夜に落ちたとき、日本の担当者が一次情報にたどり着けるかという話です。
3社ともlang属性は英語だけ
3社のステータスページのHTMLを取得しました。status.claude.comはlang=”en”、status.openai.comはlang=”en-US”、status.x.aiはlang=”en”で、言語切替のUIも0件です。
インシデントの本文もすべて英語です。
通知の購読手段は7種類・4種類・1種類と差がある
購読の窓口を並べます。
- Anthropic：メール、SMS（国番号にJapan +81あり）、Slack、Microsoft Teams、Webhook、Atom、RSSの7種類
- OpenAI：メール（コンポーネント単位で指定可）、Slack、Atom、RSSの4種類
- xAI：RSSの1種類のみ
Webhookが使えるのはAnthropicだけです。社内のSlackや監視に自動連携するなら、現実的な選択肢はここになります。OpenAIはSMS購読が設定上オフになっており、Webhookもありません。
なおAnthropicのSMSは「インシデントの作成時と解決時」だけを送ります。9月3日に「どのモデルが落ちているか」が分かったのは22時50分の中間更新なので、SMSだけを購読していた人にはその情報が届きません。コンポーネントの状態変化まで拾うのはWebhookだけです。
日本語のヘルプはあるが、リアルタイムの通知はない
「日本語の情報が皆無」と書くのは言い過ぎでした。AnthropicとOpenAIには日本語のヘルプセンターがあります。
ないのは、リアルタイムの障害通知のほうです。ステータスページ本体も、そこから購読するメール・SMS・Slack・Webhook・RSSも、3社とも英語だけです。日本語で障害の発生をその場で知る手段は、9月4日時点でありません。
公式Xで障害に触れたのはSpaceXAIだけ
3社の公式Xアカウントを確認しました。障害について投稿したのは@SpaceXAIだけで、@OpenAIと@AnthropicAIと@grokは触れていません。日本語での投稿は3社とも0件です。
なおOpenAIは、障害の最中である日本時間9月4日0時1分にもXに投稿しています。内容は障害と無関係でした。
日本時間の深夜だった。ただし朝9時にも6分落ちている
日本の読者にとっての実害を整理します。
3社同時の時間帯は日本の営業時間と重ならない
障害の全体は日本時間9月3日21時37分から9月4日2時9分です。完全に深夜帯で、日本の営業時間とは一切重なっていません。
夜に作業していた人と、深夜バッチを回していたシステムが影響を受けた形になります。
同じ日の朝9時に別の障害があった
見落とされがちな1件があります。OpenAIは日本時間9月3日9時4分23秒から9時10分45秒に「ChatGPT Work Mode High Error Rates」というインシデントを出しています。
6分22秒と短いですが、impactは「major」です。日本の始業時間に重なっており、こちらのほうが実害はあったかもしれません。
日本語の報道はITmediaとその配信だけ
日本語で報じたのは、確認できた範囲ではITmedia AI＋（9月4日0時48分公開、3時10分更新）と、そのYahoo!ニュース配信だけでした。
ITmediaは「ClaudeとGrokは3日午後10時30分ごろから」と書いていますが、これはClaudeの3件目だけを指しています。21時37分に始まった2件目は入っていません。
読者が今日できること。購読の設定とフォールバックの指定
最後に、一次情報で裏づけられる対策だけを挙げます。
3社のステータス通知を購読しておく
3社ともステータスページから通知を購読できます。AnthropicはWebhookまで対応しており、コンポーネントの状態変化を社内の監視へ自動で流せます。OpenAIはメール・Slack・RSS・Atomの4種類、xAIはRSSだけです。
Anthropicのステータスは、いまはstatus.claude.comです。旧アドレスのstatus.anthropic.comは恒久転送になっています。ブックマークが古いままなら直しておくとよいです。
いずれも英語配信です。
Claude Codeにフォールバックモデルを指定する
Claude Codeを使っているなら、フォールバックモデルを指定できます。主モデルが過負荷や利用不能になったとき、指定したモデルに切り替わります。
ただし切り替わるのはそのターンだけで、次のメッセージでは主モデルに戻ります。最大3モデルまでです。
障害を理由に返す規定は、3社とも書かれていない
3社の公開規約を確認しました。
Anthropicの商用規約に稼働率条項もサービスクレジット条項もありません。OpenAIのBusiness Termsにある「Service Credits」は前払いクレジットのことで、ダウンタイム補償ではありません。xAIには公開のSLA文書自体がありません。
正確に言うと、3社とも「障害が起きたら返す」とも「返さない」とも書いていません。正面から規定した条項が存在しないのです。
OpenAIの99.9%という稼働率SLAは、Scale TierとFast modeに付くもので、脚注に「エンタープライズ顧客のみ」と明記されています。しかもScale Tierの対象は「GPT-5.6より前にリリースされたモデル」に限られます。
日本にはEEAと英国のような返金の枠がない
Anthropicの日本語のサポート記事に、こう書かれています。
消費者利用規約に明示的に記載されている場合または法律で要求される場合を除き、すべての支払いは払い戻し不可です。
同じ記事によれば、欧州経済領域と英国には14日以内の日割り返金がありますが、日本にはその枠がありません。日本の読者にとっては、ここがいちばん具体的な差になります。
単純計算では3社とも99.9%を割っている
参考までに月間可用性を計算しました。9月は30日、43,200分です。
- Anthropic：約188.9分の障害で99.563%
- OpenAI：約132.8分で99.693%
- xAI：約219.2分で99.493%
3社とも99.9%（月43.2分）を大きく割っています。ただしこれはステータス上のサービス全体の障害時間であって、実際のエラー率とは異なります。OpenAIのステータスページ自身が「可用性の指標は全ティア・全モデル・全エラー種別を横断した集計値である」と注記しています。
総括：AI業界は互いの建物を借り合う段階に入っている
ここまでの事実を、1つの流れとして置きます。
9月3日に起きたことは、3社が同時に落ちたという表面の下に、もう少し込み入った構造を持っています。ClaudeとGrokは3分56秒差で始まり、ChatGPTは1時間13分遅れて別の理由で始まりました。3社そろって落ちていたのは1時間33分です。
そしてSpaceXAIだけが、名指しの先としてクラウド事業者ではなく自社のメンフィスの計算センターを挙げました。同じ投稿で「影響を受けたコンピュートパートナー」にも謝っています。
SpaceXは、いまや計算資源の貸し手でもあります。Anthropicは月12.5億ドルでCOLOSSUSとCOLOSSUS IIの容量を借り、Googleは月額9億2,000万ドルで約11万基を借ります。Cursorは今年SpaceXに買収されました。
「どのクラウドを使っているか」だけでは、もう障害の連鎖を説明できません。競合どうしが同じキャンパスに間借りする段階に入っているからです。
ただし、だから単一拠点で全部説明がつく、という話でもありません。Anthropicは3種類のハードウェアと3つの経路に分散していると公表しており、落ちたモデルの並びも飛び石です。公開情報からは、ここまでしか言えません。
そして原因を自分の言葉で書いたのはSpaceXAIだけで、その中身も「場所」だけでした。
障害のときに読者が確認できる情報は、増えていません。3社のステータスページは英語だけで、原因は書かれず、謝罪の言葉もありません。書いてあったのは、巻き込まれたGitHubの「原因分析を共有します」という一文でした。
まとめ：9月3日のAI3社同時障害で確定していること
一次情報で確認できた事実だけを並べます。
日本時間9月3日21時37分から9月4日2時9分にかけて、Claude・Grok・ChatGPTが順に障害を起こしました。全体で4時間31分42秒ですが、3社が同時に落ちていたのは1時間33分だけです。Claudeの3件目とGrokは3分56秒差で始まり、ChatGPTはその1時間13分後でした。
「共通のクラウド障害」説は、一次情報で裏づけられません。Cloudflare・Google Cloud・AWS・Azureのいずれの公式ステータスにも、3社の障害を説明できる記録がありません。Cloudflareの広報は「それと異なる報道はすべて誤りである」と述べています。この説を最初に見出しに掲げたTech Timesの典拠は、StatusGatorに寄せられた利用者の投稿1件でした。
3社とも、自社のステータスページに原因を書いていません。SpaceXAIだけが公式Xで「メンフィスの計算センターの障害」と場所を明かし、「影響を受けたコンピュートパートナー」にも謝罪しました。何が壊れたのかは、いまも公表されていません。
そのメンフィス圏の拠点群では、Anthropicが月12.5億ドルで約32万5,000基分の容量を借りています。SpaceXの目論見書によれば、契約はCOLOSSUSとCOLOSSUS IIの両方にまたがります。
ただし「同じ1棟が落ちた」とは書けません。Grok-5が動いているのはCOLOSSUS IIで、Anthropic自身はClaudeを3種類のハードウェアと3つの経路に分散していると公表しています。
OpenAIは別の構図でした。被害はChatGPTの15コンポーネントとCodexの4コンポーネントに限られ、api.openai.comの12コンポーネントは影響対象に入っていません。自己申告の深刻度も「minor」です。広報は報道各社に「ルーティングエラー」と答えましたが、自社のどのページにも書いていません。
3社の障害報告に、謝罪の言葉は1語もありません。「sorry」「apologize」「regret」「inconvenience」「thank」「patience」がすべて0件です。原因分析を約束したのは、巻き込まれたGitHubだけでした。
日本の読者にとっては、リアルタイムの障害通知が3社とも英語だけであること、日本語の報道が実質1本だったこと、そして障害を理由に返金する規定が3社とも書かれていないことが実務に効きます。Anthropicは欧州経済領域と英国にだけ14日以内の日割り返金の枠を置いており、日本にはありません。
そして9月3日に落ちたOpus 4.8とOpus 4.6は、優先枠（Priority Tier）の対象モデルでした。優先枠を買っていても落ちています。しかもその優先枠は、いま新規に買うことができません。
あなたが業務で使っているAIサービスは、どこの建物で動いているか調べたことがありますか。
よくある質問（FAQ）
Q1. 結局、3社が同時に落ちた原因は何だったのですか。
2026年9月4日時点で、原因は3社とも公表していません。SpaceXAI（旧xAI）だけが公式Xに「メンフィスの計算センターの障害」と書きましたが、これは場所であって、何が壊れたかは明かしていません。AnthropicとOpenAIは報道各社への広報コメントで「インフラの問題」「ルーティングエラー」と述べただけで、自社のステータスページ・ブログ・公式Xには書いていません。なおSpaceXAIは「影響を受けたコンピュートパートナー」にも謝罪しており、Anthropicは同社のメンフィス圏の拠点群（COLOSSUSとCOLOSSUS II）に月12.5億ドルを払っています。ただしAnthropicは9月3日の障害との関係について何も述べておらず、同社はClaudeを3種類のハードウェアと3つの経路に分散していると公表しているため、単一拠点で説明することはできません。
Q2. 「AzureやCloudflareの障害が原因」という記事を読みましたが、本当ですか。
一次情報では裏づけられません。Cloudflareの広報はThe Registerに「当社のサービスは正常に稼働しており、それと異なる報道はすべて誤りである」と回答しています。Cloudflareの公式ステータスで9月3日に始まった障害4件はいずれも時間帯が外れており、またがっていた2件はR2とWARPに限られた別の話でした。Google Cloudは9月2日から4日の記録が0件、AWSの同日の障害は4時間ずれた別件（us-west-2のSTS）です。Azureは当日のステータスフィードが空でしたが、Azureは広範囲の障害に限って事後レビューを公開する運用のため、「記録がない＝障害がなかった」とまでは言えません。なお「Azureが原因」と断定した記事の典拠は、StatusGatorに寄せられた利用者の投稿1件で、Microsoftの発表ではありませんでした。
Q3. こういう障害に、利用者側で備える方法はありますか。
一次情報で裏づけられる手段は限られます。まず3社ともステータス通知を購読できます（Anthropicはメール・SMS・Slack・Microsoft Teams・Webhook・Atom・RSSの7種類、OpenAIはメール・Slack・Atom・RSSの4種類、xAIはRSSのみ、いずれも英語）。コンポーネントの状態変化まで拾えるのはAnthropicのWebhookだけです。Claude Codeを使っているならフォールバックモデルを指定でき、主モデルが過負荷や利用不能のときに切り替わります（最大3モデル、切り替えはそのターンかぎり）。一方、Claude APIのフォールバック機能は安全性の分類器が拒否したときにしか発火せず、障害では作動しません。返金は3社とも障害を理由にした規定がなく、Anthropicの優先枠（Priority Tier）は新規購入が停止しています。しかも9月3日に落ちたOpus 4.8とOpus 4.6は、その優先枠の対象モデルでした。
筆者より
この記事は、書こうとした軸が4回変わりました。
最初は「共通のクラウド障害が3社を落とした」で書くつもりでした。3社がほぼ同時に止まったと聞けば、まずそう考えます。海外メディアの多くもその線で書いていました。
Cloudflareのステータス履歴を開いて崩れました。9月3日に始まった障害4件は、どれも時間帯が重なっていません。そのうえ広報が「それと異なる報道はすべて誤りである」と答えていました。企業広報の言い回しとしてはかなり強いほうです。
次に「3社とも原因を隠している」で書こうとして、これも崩れました。SpaceXAIは公式Xで場所を名指しし、しかも他社に謝っていました。ステータスページだけを見ていると、この投稿には気づけません。
3つ目に「メンフィスの1拠点が3社を落とした」で書こうとして、止まりました。OpenAIの障害はGrokの1時間以上あとに始まり、被害もChatGPTとCodexに限られています。しかもOpenAIは9月3日の6日前に、SpaceXの傘下に入ったCursorへのモデル提供を打ち切ると公表していました。つながる根拠がありません。
4つ目に「ClaudeとGrokは同じColossus 1で動いていた」で書こうとして、これも崩れました。Colossus 1は全量がAnthropicに貸し出されています。そこにGrokは載っていないはずです。SpaceXの目論見書を開くと、Grok-5が学習中なのはCOLOSSUS IIで、Anthropicの契約はその両方にまたがっていました。1棟の話ではありませんでした。
残ったのは「2社はメンフィス圏の同じ拠点群でつながっている。ただし単一拠点では説明できない」という、歯切れの悪い形です。Anthropic自身が3種類のハードウェアと3つの経路への分散を公表している以上、これ以上は言えません。
いちばん驚いたのは、3社の障害報告に謝罪の言葉が1語もなかったことです。「sorry」も「apologize」も「thank」も「patience」も0件でした。数えてみるまで、そこまでとは思っていませんでした。
かわりに謝意を書いていたのは、巻き込まれたGitHubのほうです。「Thank you for your patience and understanding」。そして原因分析を約束したのもGitHubだけでした。
もう1つ引っかかったのは、優先枠の話です。最初は「今回落ちたモデルは優先枠の対象外だった」と書きかけました。除外リストを1つずつ照合して逆だと分かりました。Opus 4.8とOpus 4.6は対象モデルです。お金を払って優先枠を確保していた顧客のモデルも、同じように落ちています。しかもその優先枠は、いま新規に買えません。
参考資料
- Anthropic ステータスページのインシデントAPI（status.claude.com のJSONを全件取得し、8月1日〜9月3日の31件と9月3日の2件の更新本文を逐語で確認。旧ドメイン status.anthropic.com は恒久転送）
- OpenAI ステータスページのインシデントAPI・インシデント個別ページ・履歴（created_at と display_at の差、影響コンポーネント19件の内訳、過去の事後報告9件の書式を確認）
- SpaceXAI ステータスページのRSSフィード（status.x.ai/feed.xml、全114項目。9月3日の8サービス分の開始・解決時刻を秒まで確認）およびGrok (Web) のサービスページ
- SpaceXAI 公式X（@SpaceXAI）の謝罪投稿、およびイーロン・マスク氏の続報投稿（報道経由）
- SpaceX 新規株式公開の最終目論見書 Form 424B4（2026年6月12日提出。Anthropicとの契約範囲・GPU数・月額、COLOSSUSとCOLOSSUS IIの所在地、Grok-5の学習拠点を逐語で確認）
- SpaceX がアメリカ証券取引委員会に提出したForm FWP（Googleとの Cloud Service Agreement の条件）およびForm 10-Q（契約の解約条件）
- Anthropic「Higher usage limits for Claude and a compute deal with SpaceX」（2026年5月6日。生HTML 151,621バイトを取得して全文検索）
- SpaceXAI「New Compute Partnership with Anthropic」（2026年5月6日。生HTML 168,630バイトを取得して全文検索）およびx.ai/memphis
- Anthropic Engineering の技術ポストモーテム（Claudeの提供経路とハードウェア構成の逐語）
- Anthropic 公式ドキュメント（platform.claude.com のサービスティア・APIエラー・フォールバックの各ページ、英語版と日本語版）およびClaude Code のフォールバックモデルの仕様
- Anthropic 商用規約（稼働率条項・サービスクレジット条項の有無を全文検索）および日本語サポート記事の返金規定
- OpenAI 公式ページ（api-scale-tier、api-fast-mode、Business Terms、Production best practices、Codexのモバイル連携ドキュメント、Cursorに関する2026年8月28日の判断）
- SpaceXAI 法務ページ一覧およびエンタープライズ利用規約（SLA文書の有無を確認）
- Cloudflare ステータスのインシデントAPI・計画メンテナンスAPI・コンポーネントAPI・履歴（9月3日に始まった4件と、8月から継続していた2件を確認）
- Google Cloud ステータスのインシデントJSONおよびGoogle Workspace ステータスダッシュボード（9月1日〜4日を全件確認）
- AWS ステータスRSSおよび公開ヘルスイベント（9月3日の4項目の逐語を確認）
- Microsoft Azure ステータスフィード・事後レビュー（PIR）一覧、およびInternet Archiveに残る9月3日のスナップショット
- IODA（ジョージア工科大学のインターネット障害観測）のアラートAPI（9月3日13時26分〜17時50分の317件を全件確認）
- Cursor ステータスページのインシデントAPI（9月3日の3件の時刻・深刻度・逐語を確認）
- GitHub ステータスページのインシデントAPI（Grok Copilot AI Model Provider の全更新を逐語で確認）
- StatusGator の Azure ページ（直近24時間の投稿3件を確認）
- The Register「True AI-pocalypse as ChatGPT, Claude, and Grok all go down at once」（2026年9月3日19時24分・協定世界時、23時8分に追記。3社およびCloudflareの広報コメント）
- Tech Times「Gemini Survived When ChatGPT, Claude, and Grok Collapsed: Azure Is at Fault」（2026年9月3日17時5分3秒・協定世界時）
- Engadget、Decrypt、9to5Google、Gulf News、Forbes、Axios、MacRumors、Quartz
- ITmedia AI＋「複数のAIサービスで障害発生 ChatGPT／Claude／Grok【復旧済み】」（日本時間2026年9月4日0時48分公開・3時10分更新）およびYahoo!ニュース配信
この記事が気に入ったら
フォローしてね！
お気軽にコメントどうぞ