ChatGPT・Claude・Grokが同時障害｜2026年9月3-4日のAI大規模ダウンの原因・各社の説明・業務を止めない備え

2026年9月3日（日本時間9月3日夜〜9月4日未明）、ChatGPT・Claude・Grokの3サービスが相次いで障害を起こし、いずれも同日中に復旧しました。ただし3社に共通する単一の原因は、現時点で公式には特定・公表されていません。各社の説明はバラバラで、ネット上で広まった「Microsoft Azure障害が共通原因」「Cloudflare障害が原因」という説は、Azure・Cloudflare双方の公式ステータス履歴では裏取りできません。

この記事は、各社の公式ステータスページAPI（Statuspage v2 JSON）から直接取得した一次データをもとに書いています。

この記事でわかること：

3社の障害を日本時間（JST）で分単位に並べたタイムラインと、公式アップデートの原文
各社が公表した原因説明の食い違いと、どこまでが確認済みでどこからが推測か
「Azure原因説」「Cloudflare原因説」を公式記録で検証した結果
ClaudeとGrokがほぼ同時刻に落ちたことの技術的な接点（留保付き）
障害中、実際に有効だった回避策（モデル別の復旧差からわかること）
AIサービスの障害頻度の実データと、業務を止めないための具体的な備え

こんな方向けの記事です： 業務でChatGPT・Claude・Grokを使っていて「また止まったらどうするか」を決めたい方、社内のAI利用ルールやBCPを設計する立場の方、AI APIを本番システムに組み込んでいる開発者の方。

結論｜3サービスとも復旧済み、共通原因は公式に特定されていない

現時点（2026年9月4日）の状況は次の通りです。

項目	現時点の事実
障害の対象	ChatGPT（OpenAI）／Claude（Anthropic）／Grok（SpaceXAI・旧xAI）
発生日時	日本時間 2026年9月3日 21:37頃〜 9月4日 02:07頃
復旧状況	3サービスとも9月4日未明までに復旧済み
共通原因	公式には特定・公表されていない
各社の説明	OpenAI＝ルーティングエラー（広報コメント）／SpaceXAI＝メンフィスの計算設備の障害／Anthropic＝「原因は特定したが内容は非公表」
Gemini	Googleは公式に障害を認めていない（Downdetectorへの報告増加のみ）
障害報告件数	ChatGPT単体で約3万5,000件、3社合計で約3万5,000〜4万件規模（Downdetector・ユーザーの自己申告ベース）

特に押さえておきたいのは次の3点です。

「3社が同時に落ちた＝1つの共通原因がある」とは公式には言えない。 ClaudeとGrokはほぼ同時刻（JST 22:26〜22:30）に始まっていますが、ChatGPTの障害開始は約1時間半後（JST 23:58）です。
Anthropicは「原因を特定した」と書いたが、原因の内容自体は公表していない。 ここを「不明」で片づけている記事が多いですが、公式表現は「特定済み・非公表」です。
Claudeはモデルによって復旧時間が3倍以上違った。 Sonnet 5は約18分で復旧した一方、Opus 4.8とOpus 5は約3時間残りました。これは「業務を止めない備え」を考えるうえで最も実用的な事実です。

なお、翌9月4日16:00（JST）には、OpenAIのステータスページにAPAC（アジア太平洋）リージョンのユーザーでChatGPT・Work・画像生成・ファイルアップロード・音声・Codex Cloudのエラーが増加する可能性があるという別のインシデントが掲載されました。2026年9月4日時点で、このインシデントは「調査中（investigating）」のままです。9月3日の障害とは別事象ですが、日本からのアクセスが含まれるリージョンのため、「今つながらない」場合はこちらの可能性もあります。

日本時間の分単位タイムライン（公式ステータスページの一次記録）

3社の障害を日本時間で1本に並べると、次のようになります。UTCは各社公式ステータスページの記録値、JSTはUTC+9で換算した値です。

JST（2026年）	サービス	出来事
9/3 21:37	Claude	「Elevated errors for Claude Sonnet 5」発生（1件目）
9/3 21:56	Claude	1件目が復旧（所要約18分）
9/3 22:26	Claude	「Elevated errors for multiple models」発生（2件目・本命）
9/3 22:30頃	Grok	障害発生（米西海岸時間 6:30 AM PT／報道ベース）
9/3 22:41	Claude	「原因を特定し修正に取り組んでいる」と更新（原因の内容は非公表）
9/3 22:50	Claude	影響モデルを列挙：Mythos/Fable 5.1、Mythos/Fable 5、Opus 5、Opus 4.8、Opus 4.6
9/3 23:58	ChatGPT	「Elevated errors across ChatGPT and Codex」発生（impact: minor）
9/4 00:25	Claude	残る影響はOpus 4.8とOpus 5のみ、他モデルは通常のエラー率に回復と更新
9/4 00:50	ChatGPT	「緩和策を適用し復旧を監視中」と更新
9/4 01:06	Claude	修正をデプロイし監視中
9/4 01:16	Claude	影響終了（公式表記：9:16 AM PT／16:16 UTC）
9/4 01:23	Claude	インシデントを「resolved」に変更（発生から約2時間57分）
9/4 01:55	ChatGPT	「resolved」に変更（発生から約1時間57分）
9/4 02:05〜02:07	Grok	復旧（10:05 AM PT前後／報道ベース）

Claude（Anthropic）の公式アップデート原文

Anthropicのステータスページに実際に掲載された文面は次の通りです（時刻はJST）。

JST	ステータス	公式本文（要旨）
9/3 22:26	investigating	"We are investigating elevated errors on requests to Claude Mythos 5.1, Claude Fable 5.1, and Claude Opus 5."
9/3 22:41	identified	"We have identified the cause ... and are working on a fix."（原因の内容は書かれていない）
9/3 22:50	identified	影響モデルの完全なリストを提示
9/3 23:49	identified	"We are continuing to work on a fix for this issue."
9/4 00:25	identified	"The only affected models right now are Opus 4.8 and Opus 5."
9/4 01:06	monitoring	"A fix has been deployed ... and we are monitoring for recovery."
9/4 01:23	resolved	"Impact has ended as of 9:16 PT / 16:16 UTC."

影響を受けたコンポーネントは、claude.ai・Claude API（api.anthropic.com）・Claude Code・Claude Cowork の4つです。つまり、ブラウザで使っている人もAPI利用者もターミナルでコーディングしていた人も、まとめて影響を受けています。

ChatGPT（OpenAI）側の記録と、復旧後に必要な後処理

OpenAI側は「investigating」→「monitoring」→「resolved」の3更新のみで、ステータスページ本文に原因の記載はありません。ただし復旧報告に、実務上見逃せない一文が入っています。

"Some Codex remote control users may need to pair their mobile device again following this incident."
（Codexのリモートコントロール利用者は、このインシデント後にモバイル端末の再ペアリングが必要になる場合がある）

Codexをスマホから操作していた方で「復旧したはずなのに繋がらない」場合は、障害の継続ではなく端末の再ペアリングが必要なだけ、というケースがあります。日本語の速報記事ではほとんど触れられていない後処理です。

なお同じ9月3日には、JST 9:04発生・約6分で復旧した「ChatGPT Work Mode High Error Rates」（impact: major）という別インシデントも記録されています。時間帯がまったく違うため、今回の同時障害とは別事象です。

Grokについては一次情報が取得しにくい

Grok（SpaceXAI）の公式ステータスページ（status.x.ai）は、Cloudflareのボット保護によって機械的な取得ができません。そのため上記タイムラインのGrokの時刻は報道ベースであり、他2社のようにステータスページの原文を確認できていません。

これは記事の都合というだけでなく、実務上の差でもあります。ChatGPTとClaudeは公開JSON APIで社内監視に組み込めますが、Grokは同じ方法では監視しにくい、ということです。Grok自体の機能や料金はGrokとは？Agent Mode・Grok Imagineの使い方と料金で整理しています。

各社の説明は食い違っている｜どこまでが確認済みか

Claudeを提供するAnthropicの公式ロゴ。今回の障害でAnthropicは「原因は特定したが内容は非公表」と説明した

出典：Anthropic公式サイト（anthropic.com）

3社の説明を並べると、「共通原因が公表されていない」ことがはっきりします。

事業者	ステータスページ上の原因記載	広報・報道での説明	確認状況
OpenAI	記載なし（investigating → 緩和策適用のみ）	広報が「ルーティングエラーが 7:43 AM PT 頃に発生、8:17 AM PT 頃に解決策を適用」とコメント	広報コメントのみ。ステータスページの記録と時刻が一致しない
Anthropic	「原因を特定した」とのみ記載し、内容は非公表	追加説明なし	原因未公表
SpaceXAI（xAI）	取得不可	「メンフィスの計算センターでの障害」と公式に認め、影響を受けた提携先にも謝罪	3社で唯一、インフラ起因を明言

OpenAIの「時刻の食い違い」に注意

OpenAI広報が語ったとされる「7:43 AM PT 発生／8:17 AM PT 解決」は、同社ステータスページの記録（14:58 UTC＝7:58 AM PT 発生／16:55 UTC＝9:55 AM PT 解決）と一致しません。広報が「内部で異常を検知した時刻」と「緩和策を投入した時刻」を語り、ステータスページが「公開インシデントとして立てた時刻」と「監視完了時刻」を記録している、という解釈は可能ですが、公式に説明されていません。

現時点ではどちらが正しいと断定できないため、この記事では両方を併記しています。障害の影響時間を社内報告する場合は、公式ステータスページの記録（JST 23:58〜翌01:55）を使うのが無難です。

Anthropicの「特定したが非公表」をどう読むか

「We have identified the cause」と書きながら中身を出さないまま resolved にした点は、利用者からするともどかしいところです。原因を出さない理由はセキュリティ・契約・調査継続中など複数あり得ますが、公表されていない以上、推測を事実として扱うべきではありません。

なお、大規模インシデントの後に事後報告（Post-Incident Review）が出るケースもあります。2026年9月4日時点でAnthropicのインシデント記録に事後報告は掲載されていませんが、AnthropicまたはSpaceXAIが後日に根本原因を公表した場合、その内容が今回の見方を変える可能性は残っています。

「Azure障害が共通原因」説・「Cloudflare障害が原因」説は公式に裏取りできない

Cloudflare公式ブログのイメージ。Cloudflareの公式ステータス履歴に該当時間帯の大規模障害記録はなかった

出典：Cloudflare公式ブログ（blog.cloudflare.com）

障害直後、SNSや一部記事で「Microsoft Azureの東US（East US）リージョン障害が共通原因ではないか」「Cloudflareが落ちたせいではないか」という説が流れました。両社の公式ステータス履歴を実際に確認した結果は次の通りです。

疑われた基盤	公式記録の確認結果
Microsoft Azure	公式のステータス履歴に、2026年9月3日の該当インシデントの記載が見当たらない
Cloudflare	9月3日の記録は「香港でHTTP 5xx増（09:21 UTC・約15分）」「シアトルでHTTP 522増（05:30 UTC）」など軽微・地域限定のみ。障害時間帯（13:00〜17:00 UTC）に該当インシデントなし

したがって、「Azureが原因」「Cloudflareが原因」と書くことは、現時点では公式情報で支持できません。

ただし「公式ステータスに記載がない＝障害が一切なかった」とも断定できない点には注意が必要です。ハイパースケーラーのステータスページは、影響範囲が限定的な事象を掲載しないことがあります。正確に言えば「公式には確認できない」が結論です。

ClaudeとGrokがほぼ同時に落ちた理由｜メンフィスの計算基盤という接点

公式情報だけを積み上げると、単一原因とは別の構造が見えてきます。ただし因果関係として公式に確認された内容ではないため、留保付きで読んでください。

確認できている事実は4つあります。

SpaceXAIは「メンフィスの計算センターでの障害」を公式に認め、あわせて「影響を受けた計算リソースの提携先（compute partners）」にも謝罪した。つまり、自社サービス以外にも影響が及んだことを自ら認めている。
Anthropicは2026年5月、SpaceXがメンフィスで運用するAIスーパーコンピューター「Colossus 1」の計算容量をフルレンタルする契約を締結。SpaceXがSEC（米証券取引委員会）に提出したS-1で、月額12.5億ドル・2029年5月まで・総額最大450億ドルと開示されている。＝Anthropicはメンフィス設備の最大級の提携先である。
ClaudeとGrokの障害開始はほぼ同時（ともに JST 9/3 22:26〜22:30）。
一方、ChatGPTの障害開始は約1時間半後（JST 23:58）で、OpenAIはメンフィス設備とは無関係のインフラを使っている。

この4点を並べると、「3社同時＝単一原因」ではなく、「メンフィス起因で説明しうる2社（Claude・Grok）＋時間差で発生した別事象（ChatGPT）」という2層構造として見るのが、公式情報とは最も整合的です。

ただし、SpaceXAIは提携先の具体名を公表しておらず、Anthropicも原因を公表していません。「メンフィスの障害がClaudeを止めた」と断定することはできず、あくまで「そう解釈しても矛盾しない」という水準にとどまります。AnthropicとSpaceXの契約の中身はAnthropic × SpaceX Colossus提携とは｜月額12.5億ドル・契約期間・GPU規模で詳しく整理しています。

この構造が示すことは重要です。UI上はまったく別のサービスでも、下層の計算基盤を共有していれば同時に落ちる。つまり、複数のAIサービスを並べるだけの冗長化は、期待したほど効きません。

被害規模｜約3万5,000件の障害報告、Geminiは「落ちた」と言い切れない

Downdetectorに寄せられた報告件数は、報道ベースで次の通りです。

サービス	ピーク時の報告件数
ChatGPT	約35,000件（一部報道は37,000件超）
Claude	約1,300〜1,400件
Grok	約1,200〜1,365件
Gemini	約500件
合計	約3万5,000〜4万件

数値は媒体によって幅があり、ピークの定義も統一されていません。またDowndetectorはユーザーの自己申告ベースであり、実際の被害ユーザー数ではありません。ChatGPTの件数が突出しているのは、単純に利用者数が桁違いに多いためで、「ChatGPTの障害が最も深刻だった」ことを意味しません。実際、OpenAI自身は今回のインシデントの影響度を「minor」に分類しています。

Geminiについては報告件数の増加が観測されたものの、Googleは公式に障害を認めていません。「Geminiも同時に落ちた」と書いている記事がありますが、公式ステータス上の根拠はありません。Google CloudはSpaceXのメンフィス設備とは別系統で稼働しており、今回の障害の「対照群」として見るのが妥当です。

実は「今回だけ」ではない｜AIサービスは月20〜25回止まっている

OpenAI公式開発者ドキュメントのエラーコード解説ページ。APIの障害・エラーは日常的に発生している

出典：OpenAI公式開発者ドキュメント「Error codes」（developers.openai.com）

今回の同時障害は目立ちましたが、AIサービスの障害自体は珍しくありません。各社の公式ステータスAPIから実際に集計した件数は次の通りです（2026年9月4日取得）。

Anthropic / Claude のインシデント件数

期間	件数
2026年7月21日〜31日	19件
2026年8月（1ヶ月）	25件
2026年9月1〜3日	6件

OpenAI はステータスAPIの返却上限である25件を取得した時点で期間が約1ヶ月（2026年8月4日〜9月4日）に収まっており、実際のインシデント数はこれ以上の可能性があります。

Claudeの直近インシデントの継続時間を見ると、規模感がつかめます。

発生（UTC）	継続時間	内容
09-03 13:26	177分	Elevated errors for multiple models（今回）
09-03 12:37	18分	Elevated errors for Claude Sonnet 5
09-02 21:17	26分	Elevated errors for Claude Sonnet 5
09-01 23:26	117分	クレジット購入の遅延
09-01 17:05	61分	platform.claude.com / Microsoft 365 連携の性能劣化
08-31 19:21	74分	claude.ai と Claude Code の性能劣化
08-28 17:22	179分	Claude Code / Claude Cowork のエラー増加
08-24 05:06	204分	複数モデルのエラー増加

つまり、2026年の実態は「月に20〜25件、数分〜3時間程度の障害が起きる」です。ほとんどは軽微・短時間で、多くの利用者は気づかないまま終わります。だからこそ、備えの考え方は「障害が起きないようにする」ではなく「月に何度か止まる前提で業務を組む」になります。

障害中に実際に効いた回避策｜モデルを下げると復旧が早い

今回の障害で最も実用的な事実は、Claudeのモデルによって復旧時間が大きく違ったことです。

モデル	状況
Claude Sonnet 5	21:37発生の1件目は約18分で復旧。2件目でも早期に通常のエラー率へ回復
Mythos/Fable 5.1、Mythos/Fable 5、Opus 4.6	JST 9/4 00:25時点で通常のエラー率に回復済み
Opus 4.8 / Opus 5	最後まで残り、影響終了は JST 9/4 01:16（約3時間）

Anthropicは9月4日00:25の更新で「現在影響を受けているのはOpus 4.8とOpus 5のみ」と明記しています。上位モデルほど復旧が遅く、下位モデルは先に戻るという構図です。

ここから導ける実践的な対処は次の通りです。

上位モデル固定運用はリスクが高い。 常にOpus系を使う設定にしていると、障害の影響を最も長く受けます。
障害時はまずモデルを下げる。 Claude CodeやAPIでモデルを切り替えられる環境なら、/model 等で下位モデルに退避すると、作業を続行できる可能性があります。今回はこれが実際に有効なケースでした。
「全部落ちた」と判断する前に1段階試す。 体感としては「Claudeが落ちた」でも、実際には特定モデルだけが落ちていることが多くあります。

モデル別の復旧差はほとんど報じられていませんが、障害中に最初に試すべき行動として最も費用対効果が高い対処です。

エラーコードの読み方｜529は課金では回避できない

Claude公式プラットフォームドキュメントのAPIエラー解説ページ。529は過負荷（overloaded_error）を示す

出典：Claude Platform Docs「Claude API errors」（platform.claude.com）

障害時に画面やログに出るエラーコードには、それぞれ明確な意味があります。Anthropic公式のAPIエラーリファレンスに基づく定義は次の通りです。

コード	公式のtype	意味	対処
429	`rate_limit_error`	組織のレート制限・利用ティアの月次上限・ワークスペースの支出上限に到達	上位プラン・上限引き上げが有効
500	`api_error`	提供側システム内部の予期しないエラー	指数バックオフでリトライ。続く場合はrequest IDを添えてサポートへ
504	`timeout_error`	処理中のタイムアウト	長時間処理はストリーミングAPIの利用を検討
529	`overloaded_error`	APIが一時的に過負荷。公式に「全ユーザー横断で高トラフィックが発生した際に起きうる」と明記	待つ／別経路へ退避

429と529の決定的な違いは、課金で解決できるかどうかです。429は自分のアカウント側の制限なのでプラン変更に意味がありますが、529はサービス全体の過負荷なので、上位プランに課金しても回避できません。障害中に慌ててプランをアップグレードしても、529には効きません。Claudeの料金プランを見直すこと自体は有用ですが、可用性の問題とは切り分けて考えてください。

529エラーの詳しい意味と対処法は、Claude大規模障害まとめ｜529 Overloadedエラーの意味・対処法で個別に解説しています。

業務を止めないための備え｜今日できることから順に

OpenAI公式Python SDKのイメージ。リトライやフォールバックの実装は公式SDKの標準機能で対応できる

出典：OpenAI公式Python SDK（github.com/openai/openai-python）

1. まず障害を「知る」仕組みを作る（全員向け・所要5分）

障害時に最も時間を無駄にするのは「自分の環境の問題か、サービス側の問題か」を切り分ける時間です。ステータスページを購読しておくだけで、この判断が数秒で終わります。

サービス	ステータスページ
Claude（Anthropic）	status.claude.com
ChatGPT（OpenAI）	status.openai.com
Grok（SpaceXAI）	status.x.ai

ClaudeやOpenAIが使っているStatuspageベースのページは、メール／SMS／Slack／Microsoft Teams／Webhookでの通知購読に対応しています。チームで使っているなら、Slackの共通チャンネルに通知を流す設定が最も効果的です。「使えないんだけど？」という問い合わせが来る前に、全員が状況を把握できます。

2. 非エンジニアがやるべきこと

締切直前の工程にAIを置かない。 今回の障害は約2〜3時間でした。1日の余裕があれば致命傷にはなりません。
作業をこまめに保存する。 長い出力を画面に出しっぱなしにせず、都度ドキュメントへ移す。
代替サービスのアカウントを平時に作っておく。 障害中に新規登録・支払い設定をするのは非効率です。どのサービスを控えにするかは生成AIツールおすすめ比較やClaude vs ChatGPT 徹底比較で選び方を整理しています。
人力の代替手順を1つ決めておく。 「AIが使えなければ手作業でここまでやる」という下限を決めておくと、障害時の判断が速くなります。

3. 開発者・API利用者がやるべきこと

公式SDKのリトライ設定を先に確認する。 Anthropicの公式SDKは、接続エラー・レート制限・5xxエラーに対してデフォルトで2回まで指数バックオフで自動リトライし、retry-after ヘッダーがあれば尊重します。この挙動を知らずに自前のリトライループを重ねると、二重リトライで障害をさらに悪化させます。
リトライ回数はクライアントのオプションで設定・無効化できる。 自前実装をするなら、まずSDK側を無効化してから。
request-id を必ずログに残す。 全レスポンスに request-id ヘッダー（例：req_018EeWyXxfu5pfWkrYcMdjWG）が付き、Python/TypeScript SDKでは _request_id プロパティで取得できます。サポート問い合わせ時にほぼ必須です。
経路を分散させる。 同じClaudeモデルでも、Anthropic直APIとAWS Bedrock、Google Vertex AIは別インフラプールとして運用されており、過去には直APIが落ちてもBedrock側は無影響だった事例が報告されています。
ただし経路分散は万能ではない。 今回のようにモデル自体のエラー率が上昇している場合、経路を変えても回避できない可能性があります。この限界を理解したうえで、モデルを下げる退避策と併用するのが現実的です。
フォールバック設定は必ず実地テストする。 一部のエージェントツールでは、HTTP 529がフォールバックの発動条件（429・408のみ）に含まれておらず、529でモデル切り替えが発動しない不具合が報告されています（OpenClawのGitHub Issue #49079）。「フォールバックを設定してあるから大丈夫」は、実際に発火させて確認していなければ根拠になりません。

4. 監視に組み込む（社内システム向け）

Statuspageベースのサービスは、機械可読のJSONを返すエンドポイントを公開しています。この記事の一次データもこの方法で取得しました。

Claude: https://status.claude.com/api/v2/incidents.json
OpenAI: https://status.openai.com/api/v2/incidents.json
Cloudflare: https://www.cloudflarestatus.com/api/v2/incidents.json

/api/v2/summary.json を定期取得して社内の監視ダッシュボードやSlackに流せば、公式アナウンスより先に異常を検知できるケースもあります。なお status.x.ai はボット保護により機械取得ができないため、Grokは同じ方法で自動監視できません。Grokを業務のクリティカルパスに置く場合は、この監視性の差を織り込む必要があります。

「複数のAIを併用していれば安心」は誤り

今回の障害が示した最も重要な教訓は、ベンダーを分けるだけの冗長化は機能しないということです。

ClaudeとGrokは、UI上はまったく別の会社の別サービスです。しかし障害開始時刻はほぼ同時で、SpaceXAIは「影響を受けた計算リソースの提携先」に謝罪しています。表面のブランドが違っても、下層の計算基盤を共有していれば同時に落ちます。

冗長化を設計するときの考え方は次の通りです。

冗長化の考え方	有効性
ベンダーを分ける（Claude＋Grok など）	不十分。今回のように基盤を共有していれば同時に落ちる
インフラ系統を分ける（Anthropic系＋Google Cloud系など）	有効。今回はGoogle Cloud上で動くGeminiが公式インシデントなしだった
提供経路を分ける（直API＋Bedrock／Vertex）	部分的に有効。ただしモデル自体の障害には効かない
モデルの階層を分ける（上位モデル＋下位モデル）	今回は有効だった。上位モデルほど復旧が遅い

もっとも、どの企業がどのデータセンター・どのクラウドを使っているかは、常に公表されているわけではありません。実務では「完全に系統を分ける」ことは難しく、複数の冗長化手段を重ねるのが現実的な落としどころです。

法人でAI利用ルールを作る立場の方へ

社内でAIの利用ルールやBCPを設計している場合、今回の障害から取り込むべき論点は次の3つです。

1. AIをクリティカルパスに置いてよい業務／避けるべき業務を切り分ける

業務の性質	AIをクリティカルパスに置く可否
社内向けの下書き作成・要約・調査補助	置いてよい。数時間止まっても遅延で済む
定期レポート・バッチ処理（時間の余裕あり）	置いてよい。リトライ設計は必須
顧客向けリアルタイム応答（チャットボット等）	慎重に。人力エスカレーション経路が必須
決済・与信・医療判断など不可逆な処理	単独では置かない。人の確認を挟む
締切直前・当日納品の工程	避ける。今回の障害時間（2〜3時間）で間に合わなくなる

2. 可用性を社内ルールに明文化する

多くの企業のAI利用ルールは、情報漏洩や著作権といった「入力してよいデータ」の話に偏っており、可用性（止まったときどうするか）の記載がありません。「主要AIサービスは月に20回以上、数分〜3時間の障害が発生する」という前提を共有し、業務ごとの代替手順を決めておく必要があります。可用性以外のリスク全体像は生成AIのセキュリティリスクとは？、エージェント運用の観点はAIエージェントのセキュリティ対策で整理しています。

3. SLAの内容を契約前に確認する

エンタープライズ契約では稼働率のSLAが提示される場合がありますが、一般的な個人向け・チーム向けプランには保証がないのが通常です。「有料プランだから止まらない」という期待は、契約書上の根拠がなければ成立しません。

こんな方は今すぐ備えるべき／急がなくてよい

今すぐ対策すべき方

AI APIを本番システムに組み込んでいる開発者 — リトライ設定・フォールバック条件（特に529）・request-id のログ保存を今日中に確認する価値があります。
顧客対応にAIを使っている事業者 — 人力へのエスカレーション経路が未整備なら、障害時に顧客対応が止まります。
AI前提で納期を組んでいるチーム — 3時間止まる前提でスケジュールに余裕があるか、一度見直してください。
社内AI利用ルールの担当者 — 可用性の項目が抜けている可能性が高いです。

いま慌てて対応しなくてよい方

個人でチャット用途に使っている方 — 障害時は別サービスに切り替えるか、数時間待てば十分です。多重のフェイルオーバー設計は過剰投資になります。
AIを補助的にしか使っていない業務 — 下書き・要約・アイデア出し程度なら、止まっても遅延で済みます。
障害の直後に契約を見直そうとしている方 — 529は課金で回避できません。プラン変更を可用性対策と勘違いしないよう注意してください。

よくある質問

Q. 障害中に書きかけだったチャットの内容は消えますか？

一般的には、送信済み・保存済みの会話は残り、送信中に失敗したメッセージのみ届かない扱いになります。ただし障害の内容によって挙動は変わるため、長文を入力しているときは送信前に手元へコピーしておくのが確実です。

Q. 自分だけ繋がらないのか、障害なのか、どう見分ければいいですか？

まず各社のステータスページを開くのが最短です。ステータスが正常でエラーが続く場合は、ブラウザのキャッシュ・拡張機能・VPN・企業ネットワークのプロキシ設定を疑います。特定リージョンのみの障害（2026年9月4日にOpenAIで発生したAPACのケースなど）は、ステータスページのトップに大きく出ないこともあるため、インシデント一覧まで確認してください。

Q. 障害中に失敗したAPIリクエストの料金は請求されますか？

一般的に、エラーレスポンス（5xx／529など）で処理が完了しなかったリクエストは課金対象になりません。ただしストリーミング中に途中まで生成されたトークンの扱いは提供元・状況によって異なります。金額に無視できない差が出た場合は、request-id を添えてサポートに照会するのが確実です。

Q. 障害があった場合、返金やSLAクレジットは受けられますか？

エンタープライズ契約で稼働率SLAが定められている場合は、規定に沿ってクレジットが適用されることがあります。一方、個人向け・一般的なチームプランでは稼働率の保証がないのが通常で、短時間の障害に対する返金は期待できません。契約形態を確認してください。

Q. VPNで別の国から接続すれば回避できますか？

リージョン限定の障害であれば結果的に繋がることはありますが、今回のような提供元側のモデル障害には効果がありません。また、サービスによっては規約上VPN経由のアクセスが推奨されていない場合があります。安定的な対策としては勧められません。

Q. どのAIサービスが一番落ちにくいですか？

現時点で「このサービスは落ちない」と言える根拠のあるデータはありません。公表されているインシデント件数は、そのサービスの品質だけでなく、ステータスページの運用方針（どこまで細かく掲載するか）にも左右されます。件数だけで優劣を判断するのは適切ではありません。各サービスの特性はChatGPTとは・Claudeとはで整理しています。

まとめ

2026年9月3〜4日の障害について、現時点で確実に言えることを整理します。

ChatGPT・Claude・Grokの3サービスが相次いで障害を起こし、いずれも9月4日未明までに復旧済み。
3社に共通する単一の原因は公式に特定・公表されていない。 各社の説明はルーティングエラー（OpenAI広報）／メンフィスの計算設備の障害（SpaceXAI）／原因は特定したが非公表（Anthropic）とバラバラ。
「Azure障害が原因」「Cloudflare障害が原因」は公式記録では裏取りできない。
ClaudeとGrokはほぼ同時、ChatGPTは約1時間半後の発生であり、「メンフィス起因で説明しうる2社＋別事象の1社」という2層構造として見るのが公式情報と整合的。ただし断定はできない。
Claudeは下位モデルが先に復旧し、Opus 4.8／Opus 5が最後まで残った。 障害時はモデルを下げる退避が有効。
529は課金では回避できない（サービス全体の過負荷のため）。429はアカウント側の制限なのでプラン変更に意味がある。
AIサービスの障害は月20〜25回起きているのが2026年の実態。「起きない前提」ではなく「起きる前提で業務を組む」のが正しい構え。
ベンダーを分けるだけの冗長化は機能しない。 冗長化はインフラ系統・提供経路・モデル階層で分けて設計する。

生成AI全体の仕組みやリスクの全体像を押さえたい方は生成AIとは？仕組み・できること・主要ツール・活用事例・リスクもあわせてご覧ください。

なお、AnthropicやSpaceXAIが後日に根本原因を公表する可能性は残っています。公式の追加発表があれば、内容は見直しの対象になります。