ChatGPT、Claude、Grok はなぜ同時に落ちたのか？大規模 AI 障害の技術的理由

9 月 3 日のタイムライン：各社が実際に報じたこと

「共有事故」を発明する前に、各社自身のステータスに揃える。xAI が先だった。東部 9:30 頃、Grok は Android、iOS、Web で同時に壊れ、X 上の返信は過負荷で後で試すか別モデルを選べ、と書いた。事後、xAI は曖昧な調査中ではなく Memphis データセンターに結び付けた。この一文は残す。少なくとも一社は建屋レベルの説明を出しており、後からの Azure 物語に丸飲みされてはいけない。

Anthropic はインフラ問題による部分障害とした。一般向け Claude、開発者向け Claude Code、公開 API が同じ時間帯でエラーを上げた。公開タイムラインでは約 15 分で原因を特定したとし、12:15 頃に回復、その後単一モデルで短い elevated errors があった。OpenAI は少し遅い。10:43–11:00 頃、ステータスは ChatGPT と Codex のエラー率上昇と性能低下を書いた。影響はチャット窓だけではなく、ログイン、ファイルアップロード、音声、検索、Deep Research、画像生成が列挙された。その日 OpenAI は新モデル Astra を予告しており、ベース負荷はすでに高い。緩和のあと、12:55 頃に復旧とマークされた。

同じ午前、Claude と Grok に依存する Cursor などのコーディングエージェントも障害を出した。第四のフロンティアモデルが死んだのではなく、下流ランタイムがバックエンドを二つ失った。Gemini は苦情の尖りを見たが公式確認の停止は出していない。Ars Technica が四社を重ねたのは苦情曲線が重なったからであり、Google が事故通報を出したからではない。重なりは同一根因ではない。DownDetector の尖りは公式確認ではない。

公式事実、インフラの手がかり、根因にできない推測

「なぜ同時か」の前に証拠を三層に分ける。第一層は公式だ。三社とも自窓の故障を確認した。Grok は Memphis、Claude は infrastructure issue、ChatGPT / Codex は elevated errors。本稿執筆時点で共同 RCA はなく、互いに名指しもない。The Verge の更新は復旧と、統一説明がないことだけを確認した。

第二層はインフラの手がかり。複数媒体と監視集約は、近い時間に Microsoft Azure の苦情尖りを記した。一部は太平洋時間約 10:26（東部約 13:26）の Azure East US で ingress 失敗と書いた。East US は企業 AI トラフィックの主地域であり、OpenAI、Anthropic、xAI はいずれも Azure 上で意味のある推論とネットワークを走らせている。入口、負荷分散、地域ルーティングが揺れると、アプリが違っても 502、タイムアウト、ログイン失敗として同時に見える。これが「同時に見えた」理由になり得る。それでも手がかりであり、署名済み RCA ではない。

第三層は設計に使ってはいけない推測だ。Azure が競合を意図的に絞った、三社が合同メンテを組んだ、Memphis と East US を一つの事故に確定した、など。公開資料はそれを支えない。残る工学の文は二つ。第一に、大衆 AI の運命はすでに少数のクラウド地域と少数の入口に縛られている。第二に、最初の一社が倒れたあと、乗り換えとクライアント再試行は、次の建屋が健全でも次の一社へ負荷を押し付ける。

共有クラウドと入口：なぜ「同時」に見えたか

2026 年のフロントドアモデルは三社、三製品、三つの Tokenizer に見える。下ではアカウント、地域、GPU 枠、グローバル anycast 入口、身分、計量を共有しがちだ。学習は自前建屋でもよい。推論はユーザーに近く、弾性で、調達可能である必要があり、Microsoft Azure が最頻の公約数になった。Gemini がほぼ落ちなかった最もきれいな説明は「Google のモデルがより安定」ではない。主経路が Google Cloud であり、同じ East US 入口を奪い合わなかった、という事実だ。

だから「同時障害」は、三つの Transformer が同時に計算崩壊した言語ではなく、入口と制御面の言語であることが多い。ChatGPT が Codex、アップロード、音声、Deep Research をまとめて報じたのは、共有ゲートウェイか身分層の故障に見える。Claude がチャット、Claude Code、API を一つの infrastructure issue に縛ったのも同じ信号だ。製品名は多く、入口は少ない。公式 RCA を待たなくても設計は変えられる。入口層は地域単位で同時に失敗する、と仮定すれば足りる。

カスケード、再試行嵐、Memphis

共有クラウドは「なぜ重なるか」を説明し、カスケードは「二番目、三番目がなぜより惨いか」を説明する。ChatGPT が使えなくなると、次の既定動作は待機ではなく Claude か Grok を開くことだ。数千万セッションが数分でベンダーを変えるのは、すでに傷んでいるかもしれない共有入口への突発だ。クライアントと Agent 枠はさらに悪い。タイムアウトですぐ再試行し、キーを回し、モデルを変え、jitter もなく、「これはインフラだから打つな」という信号もない。古典的な再試行嵐だ。最初の一社の故障は、二番目のログでは「理由のない過負荷」になる。

Grok の Memphis 説明は別柱で残す。xAI は自前データセンターに結び、時間も ChatGPT のステータスより早い。独立事故が重なっただけかもしれないし、より広い電力や上流接続と関係するかもしれない。共同タイムラインがないうちは並列に書き、合併しない。工学の含意はかえって明確だ。フェイルオーバー名簿が「OpenAI が落ちたら xAI」だけなら、その朝その方針は先に Grok で死ぬ。

Cursor の障害はその日のカスケードの製品形だ。エディタはモデルを訓らない。Claude と Grok をランタイムとして使う。上流が揺れると補完、Agent、ツール呼び出しが同時に止まる。2026 年の内部 Agent の多くがこう見える。MCP ツール、A2A タスク、自前の HTTP JSON、最後は二、三のクラウドモデルに落ちる。単点は業務コードではなく、既定の model フィールドだ。背景は MCP と JSON Schema、ステートレス MCP。

制御面はモデル本体より脆い

GPU クラスタが健全でも、ユーザーのリクエストは成功しない。ログイン、アップロード、音声、検索が同時に失敗するなら、壊れたのはゲートウェイ、身分、オブジェクトストレージ入口、共有エッジであり、一つの decoder ではない。画面の「モデル過負荷」はしばしば偽症状だ。本当に過負荷なのは入口接続数、証明書検証、トークンサービスである。ステータスページは遅れる。ユーザーは先に DownDetector の尖りを見る。切り分けではモデル名だけを見ない。エラー封筒の httpStatus、code、そして retryable かどうかだ。

各社のばらばらなエラーを一つの封筒に正規化する方が、「AI が失敗した」というトーストより役に立つ。下の JSON は、どの社か、何の状態か、再試行できるか、だけを書く。業務層は各社の原文を解析しない。原文はログへ。封筒はブレーカへ。

{
  "ok": false,
  "provider": "openai",
  "httpStatus": 503,
  "code": "elevated_errors",
  "retryable": true,
  "occurredAt": "2026-09-03T15:00:00Z",
  "message": "ChatGPT and Codex are returning elevated errors"
}

同じ午前に OpenAI の elevated errors、Anthropic の infrastructure issue、xAI の overloaded が同時に来うる。フィールド名は違う。判断は同じであるべきだ。再試行可は冷却へ、不可はベンダー切替、Schema に合わない封筒は硬失敗。HTML エラーページを正規表現で掏らない。実失敗サンプルを JSONVue へ。整形でフィールドを見、検証で構文を見、JSON Schema で必須キーを固定し、Diff で三社の封筒の欠けを見る。クラウド生成層が消えても、ローカル解析は動く。ブラウザ内ツールの価値はそこだ。

Agent / JSON パイプライン：マルチベンダーは標語ではない

スライドの「マルチクラウド」はその朝助けにならない。効くマルチベンダーは実行時方針だ。主経路、明示の fallback 順、閾値、全社が埋める一つのエラー封筒。同じ社を二十回叩かない。fallback を「生き残りのランダム選択」にしない。Gemini がその日使えたのは、同じ入口運命にいなかったからだ。だから予備名簿には主経路が違う一社が必要であり、Azure East US に全部落ちる三つの名前ではない。

方針そのものを JSON にし、業務 Schema と別バージョンにする。下の設定はモデル商標を気にしない。先に誰を打つか、失敗後に誰か、どの誤り率で切るか、封筒のどのキーが硬門か、だけを気にする。

{
  "policy": "failover",
  "primary": "openai",
  "fallbacks": ["anthropic", "xai", "google"],
  "circuitBreaker": {
    "errorThreshold": 0.3,
    "windowSeconds": 60,
    "cooldownSeconds": 120
  },
  "errorEnvelope": {
    "required": ["ok", "provider", "code", "retryable"]
  }
}

漏れやすい一点。ツール引数 JSON と最終回答 JSON は別ホップだ。MCP tools/call、OpenAI の function arguments、自前の HTTP body は、モデルが消えたとき違う形で失敗する。「モデル利用不可」と「引数が Schema 不合」を同じトーストにすると、事後は間違ったつまみを回す。ローカル検証はまだ必要だ。理由は Structured Output と同じ。形の層と可用性の層は別だ。クラウドが戻ったら、その朝の失敗封筒をフィクスチャとして残す。振り返りメールより役に立つ。

よくある質問

まとめと次の一手

9 月 3 日は一文に圧縮できる。大衆 AI はすでに共有クラウド上の入口サービスだ。商標は違う。運命は同じ地域経路で重なり得る。Memphis、East US ingress、ユーザー乗り換えは三本の線かもしれないし、交わるかもしれない。公式 RCA の前に陰謀へ潰さず、無関係な不運にもしない。

次は具体的だ。失敗を JSON に集め、フェイルオーバーを方針として書き、ブレーカ閾値を再生可能な設定にする。モデルは戻り、ステータスは緑になる。次の地域入口の揺れで Agent がまた全員沈黙するかは、いま "model": "唯一の一社" がコードに固定されているかにかかる。