ChatGPT、Claude、Grokはなぜ同日に障害？ 9月3日に「共通していたこと」と未確認の点

9月3日にChatGPT、Claude、Grokで障害が重なった。しかし、3サービスが同じ原因で停止したと結論づける証拠はない。現時点で最も慎重かつ妥当な整理は、Grokはメンフィスの計算センター障害、ChatGPTとCodexは別のルーティングエラー、Claudeは詳細未公表のインフラ問題というものだ。3540

公表情報から確認できること

Grokの運営会社は、メンフィスの計算センターで発生した障害がGrokに問題を起こしたと説明し、影響を受けた「コンピュートパートナー」にも謝罪した。報道によると、Grokの障害は米太平洋時間午前6時30分ごろに始まり、約3時間半続いた。40

一方、OpenAIがChatGPTとCodexについて示した原因は異なる。米太平洋時間午前7時43分ごろにルーティングエラーが始まり、一部の利用者が複数のプラットフォームで利用できなくなった。午前8時17分ごろまでに対策を実施し、監視を続けたとしている。35

Claudeでもエラー率上昇が起きた。報道時点のステータス情報では、インシデントの継続時間は3時間6分で、AnthropicはClaudeサービスに影響した「インフラ問題」と説明した。ただし、故障した構成要素は公表されておらず、Claudeがメンフィス施設でホストされていた、あるいは同施設に依存していたとの情報もない。3545

したがって、メンフィス施設の障害はGrokについて確認済みである一方、ChatGPT/Codexは別のルーティング問題、Claudeとメンフィスのつながりは未証明、という区別が重要になる。

同時多発に見えても、障害の形は同一ではなかった

この出来事は「約5時間にわたるAI障害」と表現されることがある。ただしこれは、主要なAIサービスで利用者が問題に遭遇し得た時間帯を表す略称としては有用でも、各社が5時間にわたり完全停止したという意味ではない。

報道では、Claudeのエラー増加は米太平洋時間午前6時23分ごろ、Grokは午前6時30分ごろ、ChatGPTのルーティングエラーは午前7時43分ごろとされる。Claudeは午前9時16分までに復旧し、Grokは約3時間半の障害だった。354045

影響は小さくない。消費者向けチャット、モデルAPI、コーディング製品、AIを組み込んだ業務フローが同じ時間帯に使えなくなる可能性があった。通常なら「別の有力モデルに切り替える」という代替策も、重複する障害時間帯には機能しにくくなる。3538

Claudeもメンフィス障害の影響を受けたのか

この説が注目された理由はある。Grokの運営会社は、メンフィスでの事象が名称を明かしていない「コンピュートパートナー」にも影響したと述べ、Claudeも近い時間帯にインフラ障害を起こしていた。4045

ただし、可能性と確認は別だ。提供された報道の範囲では、運営会社は影響先としてAnthropicやClaudeの名前を挙げていない。Anthropic側も、障害原因をメンフィスだとは公表していない。結論は次のとおりとなる。

• 確認済み： Grokはメンフィスの計算センター障害の影響を受けた。40
• 確認済み： Claudeではインフラ関連の障害が発生した。3545
• 未確認： Claudeの障害がメンフィス施設に起因した、または同施設を経由していたこと。

時間が重なったという事実だけで因果関係まで断定すれば、証拠のない推論になってしまう。

AzureとCloudflareを「完全に除外」できない理由

公開情報だけでは、AzureやCloudflareが絶対に無関係だったとは言えない。根拠があるのは、各社が示した説明が別の箇所を指している、という限定的な結論だ。OpenAIはサービス停止をルーティングエラーに、Grokの運営会社は障害をメンフィスに帰している。3540

提供された情報のなかに、これらの障害原因として広範なAzureまたはCloudflareの障害を示すものはない。単一のクラウド事業者全体の障害だった可能性は低くなるが、地域ネットワーク、DNS、認証、トランジット回線、容量、共有サプライヤーなどを通じた間接的な依存まで否定することはできない。明確に除外するには、より詳細な依存関係情報と技術的な事後検証が必要だ。

教訓は「ベンダーを増やす」だけでは足りないこと

この事例は、モデル提供者を複数採用するだけでは事業継続計画にならないことを示した。顧客からは別々に見えるAIサービスでも、物理的な計算基盤、リージョン、ネットワーク、認証、モデルホスティング、ハードウェア供給、運用体制などに共通の依存先を持ち得る。1つの層の障害が、名目上は別の選択肢を同時に使えなくすることがある。

特にAIが単発のチャットではなく業務システムに組み込まれている場合、影響は広がる。モデルが利用不能になると、ジョブキュー、ツール呼び出し、承認フロー、顧客対応、開発パイプライン、監視業務が止まり得る。復旧時の再試行も、外部操作を二重に実行したり、再開に必要な状態を失ったりする二次障害になり得る。

AI停止に備えるレジリエンステスト

本番環境でAIを使う組織は、少なくとも次の障害モードをテストしておきたい。

1. 提供者の全面停止： モデルAPIとチャット画面の双方が使えない。
2. 部分的な性能劣化： エラー増加、遅延、ストリーミング失敗、ツール利用不可。
3. 認証・ネットワーク障害： サインイン、DNS、ルーティング、特定リージョンへの接続が壊れる。
4. 相関した複数ベンダー障害： 独立しているはずの複数提供者が同じ時間帯に停止する。
5. 復旧時の危険： 再試行、キュー処理、ツール呼び出し、承認処理で重複実行や状態喪失が起きないか。

テストでは、復旧時間、滞留した処理の扱い、人による引き継ぎ、データ整合性、そして冪等性（同じ操作を繰り返しても意図しない二重の結果を生まない性質）を測定すべきだ。

事業者側には、時系列、影響した構成要素とリージョン、根本原因、緩和策、再発防止策を分けて記す技術的な事後報告が求められる。9月3日の公開情報は、Grokのメンフィス障害とChatGPT/Codexのルーティングエラーを区別するには十分だ。しかし、Claudeがメンフィスへの依存を共有していたことや、重複障害の背後にあるインフラ関係を証明するには十分ではない。354045