AIが3社相次いで止まった夜｜分けておいたのに、同時に使えなかった

2026年9月3日の夜、Claude が止まりました。ほぼ同じころ Grok も止まり、日付が変わるすこし前には ChatGPT も止まりました。復旧したのは、3社とも9月4日の午前1時16分から2時07分にかけてです。

この出来事が実務にとって重いのは、停止した時間の長さではありません。「AIは1社に頼らず、複数を使い分けておけば安心」という、多くの会社が持っている備えが、その夜は働かなかったという点です。

そして、もうひとつ大事なことがあります。各所の記事には「クラウドの共通障害が原因だろう」という説明が並びましたが、一次情報を当たると、その説明は裏づけられていません。Cloudflare は重大な障害を明確に否定し、主要なクラウドにも関連する障害は出ていませんでした。一方で SpaceX は、自社の計算センターの障害が「影響を受けた計算資源の提携先」にも及んだと認めています。ただし提携先の名前は公表されていません。つまり、3社に共通する単一の原因は確認されないまま、同じ夜に止まったことになります。この記事では、各社の記録を時刻で追いながら、中小企業が今週できることまで整理します。

その夜、ChatGPT・Claude・Grok に何が起きたか

まず、起きたことを時刻で並べます。以下はすべて日本時間です。ITmedia の記事（9月4日0時48分公開、3時10分更新）と、各社が公開しているステータスページの記録を突き合わせました。

ここで押さえておきたいのは、完全に同時ではなかったことです。Claude と Grok が先で、ChatGPT はおよそ1時間15分あとでした。復旧も1時間ほどのあいだにばらけています。「3社が同時にダウン」という見出しをいくつか見かけましたが、正確には同じ夜に相次いでが実際のところです。

Claude はどこまで止まっていたか

Anthropic のステータスページには、この障害の記録が残っています。影響を受けたのは claude.ai・Claude API・Claude Code・Claude Cowork の4つで、モデルでは Mythos 5.1・Fable 5.1・Mythos 5・Fable 5・Opus 5・Opus 4.8・Opus 4.6 に及びました。

時刻の記録を追うと、日本時間の22時26分に調査を開始し、22時41分に原因を特定して修正に着手、翌0時25分の時点では Opus 4.8 と Opus 5 だけに影響が残り、1時06分に修正を展開、最終的に1時16分をもって影響が終わったと記されています。約2時間50分でした。

2026年9月4日時点の各社ステータスページと報道にもとづきます。停止・復旧の時刻は ITmedia、Claude の詳細は Anthropic のステータスページによります。

OpenAI のステータス履歴にも、9月3日付で「ChatGPT と Codex でエラーが増加」という記録が残っています。復旧の告知には、Codex のリモート操作を使っていた人は、携帯端末をもう一度ペアリングし直す必要があるかもしれないという但し書きが添えられていました。止まっただけでは終わらず、戻ったあとに一手間かかる場合がある、という点は覚えておく価値があります。

「共通の原因」は確認されていない

この出来事について、多くの記事が「Cloudflare か Azure の共通障害だろう」と書きました。3社まとめて止まったのだから、下で支えている共通の何かが倒れたに違いない、という推測です。自然な読み方に見えます。

ところが、一次情報を当たるとその推測は支持されていません。The Register の記事によると、Cloudflare は「現時点で重大なサービス障害は発生していない」と述べて明確に否定しました。AWS・Google Cloud・Microsoft Azure といった主要クラウドにも、関連する障害は出ていません。

各社の説明も、そろっていません。OpenAI は経路制御の誤りを挙げました。これは宅配便の仕分け場で、案内板だけが壊れた状態のようなものです。荷物も倉庫も無事なのに、行き先が分からず荷物が滞留します。SpaceX は「本日朝のメンフィス計算センターの障害により Grok でご不便をおかけしました」と謝罪しています。この投稿には「影響を受けた計算資源の提携先にもお詫びします」という一文も添えられており、Grok 以外にも影響が及んだことを SpaceX 自身が認めています。ただし提携先の名前は挙げられていません。そして Anthropic は、ステータスページで「原因を特定した」と記した一方、報道機関には「インフラの問題」とだけ答えており、それが具体的に何だったのかは公表していません。

ITmedia も、9月4日3時10分の更新時点で「原因はいずれも不明」と書いています。整理すると、こういう状況です。

• 共通の原因は確認されていない（「無かった」と証明されたわけでもありません）
• 各社の説明は、内容も詳しさもバラバラ
• 1社は「インフラの問題」とだけで、中身は説明していない

ここで、記事の書き手として正直に書いておきたいことがあります。この件を調べ始めたとき、私たちも当初は「共通の基盤で何かが起きたのだろう」という前提で資料を集めていました。実際、そう書いている記事のほうが多かったからです。ところが Cloudflare の否定と各社の説明を突き合わせた時点で、その前提が崩れました。もっともらしい説明が、いちばん多く出回る——今回はその典型でした。AIの出力を確かめるときと同じで、人が書いた記事も、元になった一次資料まで戻ると話が変わることがあります。

原因が違っても、同じ夜に止まることがある

「共通の原因が見つからなかったのなら、偶然が重なっただけで、大した話ではないのでは」と思われるかもしれません。実は逆です。共通原因が見つからなかったことのほうが、備えの観点では厄介です。

複数のAIを使い分ける備えは、ひとつの前提の上に立っています。「原因が違うのだから、2つが同時に止まることはまずない」という前提です。片方が転んでも、もう片方は無事だろう。だから乗り換えれば仕事は続く。この考え方でリスクを分散します。

今回、その前提が崩れました。しかも共通の原因が特定されていないため、「この部分を避ければ次は大丈夫」という対策の立てようがありません。原因が分かっていれば、そこを迂回する設計ができます。分からないままだと、迂回する先が決められません。

正確に書いておくと、3社すべてが同時に使えなかったのは、ChatGPT が止まった9月3日23時43分から Claude が復旧した9月4日1時16分までの1時間33分です。それより前の時間帯は ChatGPT が動いていました。ただし Claude と Grok は22時30分ごろから一緒に止まっています。つまりこの2つを行き来する備えは、その晩は最初から働きませんでした。切り替え先をどう選んでいたかによって、影響の受け方は変わったことになります。

たとえるなら、通勤の経路を2つ持っておく備えのようなものです。電車が止まってもバスがある。ふだんはこれで十分です。ところが、電車の車両故障とバスの道路工事が、たまたま同じ朝に重なることがある。原因は無関係でも、その朝に困ることは変わりません。そして「次から車両故障を避ける」という対策は、道路工事には効きません。

言い換えると、備えの効き目は「原因が違うこと」ではなく「同時に倒れないこと」で決まるということです。原因を分けたつもりでも、結果が重なれば意味がありません。逆に言えば、原因が同じでも時間がずれてくれれば実務は回ります。私たちが見るべきなのは原因の系統図ではなく、同じ時間帯に全部が使えなくなる可能性がどれくらいあるかのほうです。

ここから導かれる備えは、ひとつです。AIどうしで代わりを用意することに加えて、AIを使わない手順を残しておくこと。徒歩や自転車にあたるものを、どこかに置いておくという話です。

誤解のないように書いておくと、複数のAIを使い分けること自体は有効です。今回のような重なりは、頻繁に起きるものではありません。ツールを比べて選ぶ考え方は中小企業のAIツール選びの3軸に整理しています。ここで言いたいのは、使い分けを唯一の備えにしないということだけです。

AI障害で3時間止まったら、自社の何が止まるか

では、何を備えればよいのか。ここで「あらゆる業務に代替手段を用意しましょう」と書くのは簡単ですが、実際にはできません。中小企業に人と時間の余裕はありませんし、備えを増やしすぎると、その備え自体が使われないまま古びていきます。

現実的なのは、困るまでの時間で仕分けることです。今回の停止は約3時間でした。この3時間という長さを物差しにして、自社の業務を並べてみます。

業務の例は一般的な整理で、あてはまる時間帯は業種や取引条件によって変わります。自社の実情に合わせて置き換えてください。

この仕分けをすると、多くの会社ではいちばん上の行が数件しかないことに気づきます。AIに任せている作業の大半は、3時間待てるものです。備えが必要なのは、待てない数件だけ。そこにだけ手を打てば済むと分かると、着手のハードルが一気に下がります。

これは、火災報知器を家じゅうに付けるより、まず台所と寝室に付けるのと同じ考え方です。備えは危ないところから順に置いていくもので、全部を同時に守ろうとすると、たいてい何も進みません。

もうひとつ、仕分けのときに効く問いがあります。「AIが使えないとき、この作業は遅くなるだけか、それとも止まるか」という問いです。遅くなるだけなら備えは要りません。人が時間をかければ終わるからです。止まるのは、AIしか手順を知らない場合です。たとえば、AIに作らせた文面をそのまま送っている業務で、元になるテンプレートが社内のどこにも残っていない。こうなると、AIが復旧するまで誰も動けません。備えが要るのは、手順そのものがAIの中にしか無い作業だと考えると、対象がさらに絞れます。

止まったことに、誰がいつ気づくか

もうひとつ、見落とされがちな点があります。止まったこと自体に気づくのが遅れるという問題です。

今回の停止は日本時間の深夜でした。日本の多くの会社にとっては就業時間外で、朝には復旧しています。実害はほとんど出なかったはずです。しかし、これが平日の昼間だったらどうでしょうか。しかも、AIを裏側で動かしている仕組み——たとえば問い合わせの自動振り分けや、定期的に走らせている処理——は、止まっても誰も画面を見ていません。気づかないまま、処理されていない案件だけが溜まっていくことになります。

だから、備えの3つ目は「誰がいつ気づくか」を決めておくことです。各社のステータスページを見にいくのでもよいですし、朝いちばんに担当者が結果の件数を確認するのでもかまいません。AIの出力の質がじわじわ落ちていないかを見張る話はAIモデルの挙動変化を監視する設計で扱っていますが、こちらは「動いているかどうか」というもっと手前の話です。

今週できる3つの手順

ここまでを、実際に手を動かせる形にまとめます。3つとも、会議を開かずに1人で始められます。所要は、最初の1回で1時間ほどです。

1. AIを使っている業務を書き出す

まず、社内でAIを使っている作業を書き出します。ここで大事なのは、公式に導入したものだけを書かないことです。担当者が自分の判断で使い始めた作業のほうが、実は多いことがあります。「この作業、AIに手伝ってもらっていますか」と聞いて回るほうが、正確な一覧になります。

そのうえで、それぞれに「止まったら何時間で困るか」を書き添えます。ここは厳密でなくてかまいません。数分・半日・数日の3段階で十分です。

2. 数時間で困るものだけ、代わりの手順を1行で書く

次に、いちばん上の段階に入った業務だけを取り出します。それぞれに、AIを使わない代わりの手順を1行で書きます。長い手順書は要りません。実際に必要になるのは、慌てている最中に読む1行だからです。

たとえば「問い合わせの一次返信」なら、「テンプレート集（共有フォルダの◯◯）から選んで手で送る」。「当日出荷の可否判断」なら、「在庫表を見て、判断に迷ったら◯◯さんに聞く」。この程度で機能します。すでに社内にある手順を、思い出せる場所に書いておくだけ、という場合も多いはずです。

3. 誰がいつ気づくかを決める

最後に、止まったことに気づく人と、そのタイミングを決めます。人が画面の前にいる作業なら、使っている本人がすぐ気づきます。問題は裏で自動的に走っている処理のほうです。

「毎朝9時に、前日ぶんの処理件数を担当者が見る」。この1行を決めておくだけで、気づくまでの時間は最長1日になります。決めていなければ、数日気づかないこともあります。留守番電話のランプのようなもので、点いているかどうかを毎朝見る人がいなければ、伝言はただ溜まり続けます。

戻ったあとに、一手間かかることがある

忘れられがちなのが、復旧してからの確認です。OpenAI のステータス履歴には、今回の復旧告知に「Codex のリモート操作を使っていた人は、携帯端末をもう一度ペアリングし直す必要があるかもしれない」という但し書きが添えられていました。サービスが戻っても、つなぎ直しが要る場合があるということです。

これは停電のあとに、時計を合わせ直す手間のようなものです。電気そのものは戻っていても、機器の側が元の状態に戻っていない。AIを裏側で動かしている仕組みほど、この確認が抜けやすくなります。復旧の知らせを見たら、実際に1件流してみて、最後まで通ることを確かめる。ここまでを1セットにしておくと安心です。

あわせて確認したいのが、止まっていた時間帯の取りこぼしです。自動で処理していたものが止まっていたなら、その間に来た案件は手つかずのまま残っています。復旧の確認と、取りこぼしの拾い直しは別の作業です。同じモデルを使っていても、時期によって答えのばらつき方が変わる話は同じ質問なのに毎回答えが違うのはなぜかで扱っていますが、こちらは出力の質ではなく、そもそも処理が走ったかどうかという手前の確認になります。

私たちの見解｜備えは、時間の短い順に置く

1つ目は、今回の件を「AIは信用できない」という話にしないほうがよい、ということです。電気も水道も止まります。止まる前提で備えるのが当たり前で、AIだけが例外である必要はありません。約3時間の停止は、業務システムの障害としては特別に長いものではありません。問題は長さではなく、止まったときに代わりが用意されていたかどうかだけです。

2つ目は、備えは網羅ではなく順番だ、ということです。「AIが止まったときの対応マニュアル」を作ろうとすると、たいてい途中で止まります。範囲が広すぎるからです。困るまでの時間で並べて、上から数件だけに手を打つ。この形なら1時間で終わります。終わる大きさに刻むことが、備えを実際に存在させる唯一の方法です。

3つ目は、一次情報に戻る習慣そのものが備えになる、ということです。今回、「共通のクラウド障害」という説明が広く出回りましたが、Cloudflare の否定と各社の説明を突き合わせると、その説明は裏づけられていませんでした。代わりに浮かんだのは、SpaceX の計算センターの障害が提携先にも及んだという、別の筋の話です。もし「共通のクラウド障害」という説明を信じて「クラウドを分散させれば解決する」という対策を立てていたら、見当違いのところに手間とお金をかけることになります。対策は、原因の理解の上に立ちます。だから、事実の確認を省くと、備えそのものが的を外します。私たちが記事を書くときに公式の記載だけを土台にしているのは、この理由からです。

まとめ

• 何が起きたか：2026年9月3日22時30分ごろ（日本時間）に Claude と Grok、9月4日0時前ごろに ChatGPT が停止。復旧は1時16分・1時55分・2時07分
• Claude の影響範囲：claude.ai・Claude API・Claude Code・Claude Cowork の4つ。約2時間50分
• 原因：3社に共通する単一の原因は確認されていない。Cloudflare は重大な障害を否定、主要クラウドにも関連する障害なし、OpenAI は経路制御の誤り、SpaceX は自社のメンフィス計算センターの障害と説明し提携先にも影響が及んだと認めた（提携先名は非公表）、Anthropic は「インフラの問題」とのみ説明
• 意味：複数のAIを使い分ける備えは「同時には止まらない」という前提の上にある。その前提が崩れた
• 備え方：困るまでの時間で仕分け、数時間で困る業務にだけAIを使わない手順を1行で用意する
• 見落としがちな点：裏で自動的に走っている処理は、止まっても誰も気づかない。気づく人とタイミングを決めておく
• 戻ったあと：OpenAI の復旧告知には、Codex のリモート操作は端末の再ペアリングが必要な場合があるという但し書きがあった

ここまでの内容は、2026年9月4日時点で各社のステータスページと報道で確認できた範囲にもとづきます。原因については、今後より詳しい説明が出る可能性があります。覚えておく価値があるのは個々の時刻ではなく、「切り替え先も同じ夜に止まることがある」という一点です。その一点だけで、備えの置き方が変わります。

よくある質問

Q1. 2026年9月3日の夜、実際に何が起きたのですか？

日本時間の9月3日22時30分ごろから、ClaudeとGrokが接続しにくい、または接続できない状態になりました。続いて9月4日の0時前ごろからChatGPTでも同じ状態が起きています。復旧は、Claudeが9月4日1時16分、ChatGPTが1時55分、Grokが2時07分でした。Anthropicのステータスページによると、Claudeの影響時間は日本時間で22時26分から翌1時16分までの約2時間50分で、claude.ai・API・Claude Code・Claude Cowork の4つに影響が出ています。ITmediaは同日未明の記事で、3社とも原因は不明だと報じました。

Q2. クラウドの共通障害が原因だったのではないですか？

少なくとも公表された情報の範囲では、そうではありません。The Registerによると、Cloudflareは「現時点で重大なサービス障害は発生していない」と明確に否定しており、AWS・Google Cloud・Microsoft Azureの主要クラウドにも関連する障害は出ていませんでした。OpenAIは経路制御の誤り（ルーティングエラー）を挙げ、SpaceXは自社のメンフィス計算センターの障害だと説明しています。あわせて「影響を受けた計算資源の提携先にもお詫びする」とも述べており、Grok以外にも影響が及んだことを認めていますが、提携先の名前は公表されていません。Anthropicは報道機関に「インフラの問題」とだけ答えています。つまり2026年9月4日時点で、3社に共通する単一の原因は確認されていない、というのが正確な状況です。

Q3. AIを複数使い分けていれば、こうした停止は避けられないのですか？

避けられる場合が多い一方で、今回のように効かないこともある、というのが実際のところです。「片方が止まったらもう片方へ」という備えは、2つが同時には止まらないという前提の上に成り立っています。今回はその前提が崩れました。しかも共通の原因が見つかっていないため、「この部分を避ければ次は大丈夫」という対策も立てにくい形です。重要なのは、AIどうしで代替を用意することに加えて、AIを使わない手順を残しておくことです。頻度は低くても、止まったときの損失が大きい業務ほど、この備えが効きます。

Q4. 中小企業は、まず何をすればよいですか？

3時間止まった場合に何が止まるかを書き出すところから始めるのが現実的です。手順は3つです。1つ目は、AIを使っている業務を洗い出し、それぞれ「止まったら何時間で困るか」を書くこと。2つ目は、そのうち数時間以内に困るものだけを選び、AIを使わない代わりの手順を1行で書いておくこと。3つ目は、止まったことに誰がいつ気づくかを決めておくことです。全部に備える必要はありません。困るまでの時間が短い業務だけに絞れば、多くの会社では数件に収まります。

参照元・出典

本記事は2026年9月4日に確認した各社のステータスページと報道にもとづきます。原因については、確認できた範囲を「確認できた範囲」として書き、推測は書いていません。

• Anthropic ステータスページ（該当インシデント）——影響を受けたサービスとモデル、調査開始から復旧までの各時刻、約2時間50分という影響時間
• OpenAI ステータス履歴——2026年9月3日の「ChatGPT と Codex でエラーが増加」の記録、および Codex のリモート操作に関する但し書き
• ITmedia「ChatGPT、Claude、Grokで一時障害」——日本時間での停止・復旧の時刻、および「原因はいずれも不明」という記述
• The Register「ChatGPT, Claude, and Grok all had outages at the same time」——Cloudflare による否定、主要クラウドに関連する障害がなかったこと、OpenAI の経路制御の誤りという説明、SpaceX の謝罪（影響を受けた計算資源の提携先への言及を含む）