北京時間9月3日夕、Anthropic、xAI、OpenAIのモデルサービスが1時間半のうちに相次いで障害状態に入った。Anthropicのステータスページは21時26分（北京時間、UTC13時26分）に最初の告知を掲載し、xAIのGrok全系列は21時41分に下流プラットフォーム側でサービス低下と表示された。OpenAIは22時56分前後からChatGPTとCodexのエラー率上昇を報告し始めた。23時15分の時点でも3社のインシデントはいずれも「調査中」または「修正中」のままで、復旧を宣言した社は一つもなかった。
同じ時間帯、GoogleのGeminiとVertex AIにはインシデントの記録がなく、サードパーティのステータス集約ボードでもGoogleの欄は緑色の「All services operational」のままだった。
タイムライン：3社が相次いで障害に
最も早かったのはAnthropic。21時26分、ステータスページには「Claude Mythos 5.1、Fable 5.1、Opus 5のリクエストエラー率上昇を調査中」と表示された。15分後には「原因を特定、修正中」に変わった。21時50分には完全なリストが追加され、MythosとFableの5.1・5の両世代、Opus 5、Opus 4.8、Opus 4.6がすべて影響を受けたことが判明。HaikuとSonnetはリストに含まれていなかった。22時49分の更新は「引き続き修正中」の一文のみだった。
xAIがすぐ後に続いた。xAI自身のステータスページは取得時に403が返り、直接確認することはできなかった。確認できたのは、Cursorい21時41分に「サービス低下を調査中」と発表し、影響範囲を「全Grokモデル、Automations、Cloud Agents、Grok Bot、Review Agents」と明記していたことだ。集約ボード上で「Down」（赤）と表示されたのは4社の中でxAIだけだった。
OpenAIは最も遅く、ユーザーへの影響が最も大きかった。22時56分前後、ステータスページに「Elevated errors across ChatGPT and Codex」が表示され、説明は「調査中」の一文のみ。この時間帯、chatgpt.comを開いたユーザーの一部はHTTP 404を受け取った。このエラーコードは通常、エッジノードがルートを見つけられない場合に発生するもので、モデル側の5xxエラーとは性質が異なる。
下流の方が先に気づいた
Cursorのステータスページには、この夜2件のインシデントが同時に掲載されていた。1件は21時41分のGrok低下、もう1件は22時17分の「Anthropicモデルのエラー率上昇」で、後者は「上流のAnthropicの問題」によりFable 5.1、Fable 5、Opus 5、Opus 4.8、Opus 4.6のリクエストがエラーになったと明記し、「一部のユーザーがエラーやエージェントターンの失敗に遡遇する可能性がある」としていた。
このリストはAnthropicが自ら公開したものと一致しており、Cursorがもともと接続していないMythosが含まれていない点だけが異なる。AIコーディングツールにとって、一晩のうちに2つの上流プロバイダーが同時に問題を起こしたことは、「マルチモデル冗長性」という売り文句のフェイルセーフ機能を半分失わせたことになる。
中国国内の開発者はより受け身の立場に置かれた。多くは中継APIやアグリゲーターサービスを経由しており、障害情報は一段階の伝達を経て届く。中継業者は通常「上流異常」としか表示せず、どの会社のどのモデルかは区別しない。この夜、ClaudeのHaikuとSonnetは影響リストに含まれておらず、Geminiも終始利用可能だった。それを知っている人はすぐにモデルを切り替えられたが、知らない人は更新して待つしかなかった。
Googleは無事——手がかりか、それとも偶然か
中国語圈の技術コミュニティで最初に浮上した推測は「上流回線かDNSに問題が起きたのではないか」というものだった。この推測は現時点で検証できない。反証となる材料は2つある。Google Cloudのインシデント一覧には当日新規の記載がなく、Geminiは終日正常だったこと。そしてAnthropicの表現が「原因を特定」であり、自社内部を指す言い回しである点だ。共有インフラの障害であれば通常「上流プロバイダー」という表現になる。
肯定的な材料もある。Anthropicで影響を受けたのはすべて大規模モデルで、小規模モデルは無事だった。xAIが明記したのは「全Grokモデル」。OpenAIが挙げたのはChatGPTとCodexのみで、APIの欄は緑のままだった。3社の被害範囲はいずれも推論側の大規模モデルに集中しており、これは特定リージョンの計算資源プロバイダーで問題が起きたケースに近く、DNSのように「すべてが一日にアクセスできなくなる」パターンとは異なる。
第三者の可用性モニターも比較材料になる。北京時間23時37分（UTC 15時37分）時点で9つのサービスに障害フラグが立ち、Cursor、Claude、OpenAIのほか、Cloudflare、Supabase、GitHub、Notion、SendGrid、Twilioに部分的な機能低下が表示されていた。一覧だけ見ると上流共有説を裏付けるように見えるが、Cloudflare公式ステータスページにこの夜の新規インシデントはなく、掲載されていたのは8月末から残るR2とWARPの2件で、他社の機能低下が今回の事象と関係するという根拠もない。同じページでGrokは23時37分に正常稼働に戻っていた。
これらの手がかりから言えるのは「3社それぞれの大規模モデルの推論が同じ時間帯に問題を起こした」ということだけであり、それ以上は推測の域を出ない。3社とも障害報告書はまだ公開しておらず、公開されている更新情報にも第三者への言及はない。どちらの説明が正しいかは、各社の事後検証を待つ必要があり、通常3〜5営業日かかる。
参考資料：Anthropicステータスページ、OpenAIステータスページ、Cursorステータスページ、Google Cloudインシデント一覧、CocoLoopコミュニティユーザーのスクリーンショット。各社の影響モデル一覧とインシデントの段階はステータスページの原文に照らして確認した。xAI自身のステータスページは取得時に403を返したため、その影響範囲はCursorのステータスページとサードパーティ集約ボードに基づく。