ChatGPTの障害を確認する方法｜Workが止まった時の手順

「ChatGPTが動かない。うちのネットワークの問題だろうか」「さっきまで進んでいたタスクが、途中で止まったまま返ってこない」——業務のなかでAIが応答しなくなったとき、誰もが最初にこの不安を抱えます。

結論から言うと、確認は公式ステータスページ → 外の声 → 自分側の順で3ステップに固定するのがいちばんの近道です。そして、いま重要度が上がっているのはその先で、「エージェントが止まった場合は、復旧しても作業が元に戻らない」という点を先に知っておく必要があります。

株式会社Fyveは、中小企業のAI導入支援を行いながら、自社でも毎日AIに無人で処理を任せる運用を続けています。この記事では、2026年8月31日に実際に起きたChatGPT Workの障害を教材にしながら、私が普段どの順番で切り分け、止まっている間に何をしているかをそのままお伝えします。

結論：ChatGPTが落ちたかどうかは、3ステップで確認する

急いでいるときほど、人は自分の設定を疑うところから始めてしまいます。しかしこれは順番が逆です。自分側の確認はいちばん手数が多く、いちばん時間を溶かすからです。

私が固定しているのは次の3ステップです。

• ①公式ステータスページを見る——status.openai.com を開き、どのコンポーネントに何が起きているかを確認する
• ②掲示が出ていなければ、外の声を見る——ダウン検知サイトや公式SNSで、同じ症状の報告が同じ時間帯に集まっているかを見る
• ③そこまでで確証がなければ、自分側を1つずつ外す——別の回線・別のブラウザ・別のアカウントで再現するかを試す

この順番にしておく理由は単純で、①と②は数十秒で終わり、③だけが数十分かかるからです。先に自分の設定を30分いじった後で「全社的な障害でした」と分かるのが、いちばん取り返しのつかない30分になります。

2026年8月31日に実際に起きたこと

手順の話に入る前に、直近の実例を見ておきます。抽象的な手順書より、実際の掲示がどう動いたかを知っているほうが、次に同じ場面が来たときに迷わないからです。

公式に記録されたタイムライン

2026年8月31日、OpenAIの公式ステータスページに「ChatGPT Work seeing elevated errors and latency（ChatGPT Workで遅延とエラーの増加）」というインシデントが記録されました。影響を受けたコンポーネントは ChatGPT です。掲示は次のように進みました（時刻はUTC）。

開始から全面復旧まで約5時間24分です。BleepingComputerの報道（2026年8月31日）では、この開始時刻は米東部時間の午前11時4分と伝えられており、公式の記録と一致します。またSQ Magazineの記事（同日）によれば、ダウン検知サイトのDowndetectorには2,000件を超える報告が寄せられていました。

なお、OpenAIは原因についての公式な説明を出していません。復旧の掲示はありますが、「なぜ起きたか」「再発しうるか」は公表されていない、というのがこの記事の執筆時点の状況です。

日本時間では「9月1日の未明」だった

ここが日本で働く私たちにとって重要なポイントです。UTCの15時04分は日本時間の9月1日0時4分、全面復旧の20時28分は同5時28分にあたります。

つまりこの障害は、日本ではほぼ全員が寝ている間に起きて、始業前に終わっていたことになります。海外発のサービスに業務を預けている以上、これは珍しいことではなく、むしろ標準的なパターンです。

この構造から導かれる実務上の結論が2つあります。

• 夜間に無人で走らせている処理は、誰にも気づかれずに失敗しうる。人が見ていない時間帯こそ、後から確認する手段が要ります
• 「障害が起きたか」を後から調べる手段を知っておく必要がある。リアルタイムで見に行けない時間帯の事象は、履歴でしか追えません

朝、前夜の処理結果がおかしいと気づいたとき、「自分の設定を変えたせいだ」と思い込んで原因を探しはじめる——これがいちばんありがちな遠回りです。まず履歴を見る、が正解になります。

落ちたのはチャットではなく「タスクを開始・継続する部分」だった

この障害の性格を正確に押さえておきます。公式の掲示にあるとおり、影響は「ChatGPT Workでタスクを開始・継続できない」というものでした。SQ Magazineも、通常のチャット機能は障害中も部分的に使える状態だったと報じています。

ChatGPT Workは、質問に答えるチャットではなく、目標を渡すと自律的に手順を分解して進めるエージェントです。この違いが、障害の意味を大きく変えます。

CodexChatGPT Workとは？できること・使い方・Chatとの違いを解説【2026年最新】

チャットが止まっただけなら、直ってからもう一度同じ質問を打てば済みます。しかしエージェントが途中で止まった場合、すでに進んだ工程の結果が外の世界に残っている可能性があります。この点は後半で詳しく扱います。

読者特典・無料ダウンロードAIを「入れたのに使われない」を防ぐ導入ガイド無料で資料を受け取る →↓

①公式ステータスページ status.openai.com の読み方

最初に見るべき場所です。ただ「緑か赤か」を見るだけではもったいないので、実務で効く読み方を整理します。

コンポーネント単位で見る

ステータスページは、サービス全体をひとかたまりで扱っていません。ChatGPT、API、その他の提供面がそれぞれ独立した状態を持っています。

ここを見落とすと判断を誤ります。よくあるのが、APIは正常なのにChatGPTだけが不調、あるいはその逆というケースです。8月31日の事例も、影響コンポーネントはChatGPTであり、しかもそのなかのWork機能に症状が集中していました。

ですから確認するときは、「OpenAIが落ちているか」ではなく「自分が使っている面が落ちているか」という問いに変換してください。社内でAPIを組み込んだ仕組みを動かしている場合と、ブラウザでChatGPTを使っている場合とでは、見るべき行が違います。

4つの段階が意味すること

インシデントの掲示には段階があり、これを読めると「いま待つべきか、代替に切り替えるべきか」の判断ができます。

8月31日の事例では、Identified の掲示が4時間以上続いた後にMonitoringへ移り、その27分後にResolvedになりました。これは実感として重要な情報です。「Identifiedが出た＝もうすぐ直る」ではありません。原因を特定してもなお、数時間かかることがあるという前提で動くべきです。

通知を購読して「先に気づく」

ステータスページには通知の購読機能があります。障害に気づくきっかけが「自分で操作して失敗したとき」だと、必ず後手に回ります。

私は、業務の中心に据えているサービスについては通知を受け取るようにしています。設定の手間は一度きりで、効果は「気づくのが早くなる」という形で毎回返ってきます。特に、朝いちばんに前夜の状況が分かる状態にしておくと、原因調査の空振りが減ります。

履歴ページで「後から」確かめる

あまり使われていませんが、実務ではこれがいちばん効く場面があります。ステータスページには過去のインシデント履歴が残ります。

「昨夜の処理が失敗していた」「先週の火曜、やたらエラーが多かった」というとき、履歴を見れば障害と時間帯が重なっていたかどうかが分かります。重なっていれば、自分の設定を疑う必要はありません。

1つ注意点があります。ステータスページの時刻表示は、閲覧している環境のタイムゾーンで表示されることがあります。日本時間で見ているのか、UTCで見ているのかを取り違えると、9時間ずれた比較をしてしまいます。自分のログと突き合わせるときは、必ずどちらの時刻で見ているかを確認してください。

②ステータスページに出ていないときの読み方

エラーが出ているのに、ステータスページは正常と表示している——これは頻繁に起こります。このとき「じゃあ自分のせいだ」と即断するのが失敗の入口です。考えられるのは3パターンあります。

パターン1：まだ掲示されていない

ステータスページは自動で光るわけではなく、提供者側が検知し、確認し、掲示するまでのラグがあります。利用者が気づいてから公式に掲示されるまでに数十分空くことは普通にあります。

ただし、8月31日の事例は逆でした。公式の最初の掲示は米東部時間の11時4分で、SQ Magazineが伝える利用者側の報告の増加（同11時25分ごろ）より前に出ています。つまりこのときは、公式のほうが先に異常を認めていたわけです。

これは、ステータスページを最初に見る順番が正しいことの裏づけでもあります。掲示が先に出ることもあれば、遅れることもある——だからこそコストの低い確認を先に済ませるのが合理的です。

いずれにせよ、掲示がないことは「障害がない」の証明にはなりません。数分待ってもう一度見る、が有効な対処になります。

パターン2：全体障害ではなく、部分的な劣化

ステータスページに載るのは、ある程度の規模で影響が出た事象です。特定の機能だけ、特定のプランだけ、特定の地域だけといった限定的な劣化は、掲示の基準に届かないことがあります。

8月31日の事例は、この点で示唆的です。SQ Magazineによれば、掲示のなかには「Plusの利用者が特に影響を受けており、Workモードが利用できない」と影響範囲を限定して記した時点があり、その後に公式の記録では「複数の契約プラン」へと表現が広がっています。自分のプラン・自分の使っている機能が、掲示の文面に含まれているかまで読む必要があり、しかもその範囲は時間とともに変わりうるということです。

パターン3：本当に自分側の問題

①②を通ってなお症状が続くなら、自分側を疑う番です。よくある原因は次のあたりです。

• 社内ネットワークやセキュリティ製品による通信の遮断
• ブラウザの拡張機能との衝突、キャッシュやCookieの不整合
• アカウントの契約状態・権限の変更
• 利用量の上限に到達している

最後の項目は見落とされがちです。上限に達したときの挙動は「エラー」に見えることがあり、障害と区別がつきにくいためです。プランごとの使用量の考え方は、契約している範囲を一度確認しておくと、この種の混乱を減らせます。

③障害か自分側かを見分ける手順

ここまでで確証が得られない場合、切り分けは「条件を1つずつ変えて、再現するかを見る」に尽きます。順番はこうです。

• 別の回線で試す——スマートフォンのモバイル回線に切り替える。これで動くなら、社内ネットワーク側が原因
• 別のブラウザ、またはシークレットウィンドウで試す——動くなら、拡張機能かキャッシュが原因
• 別のアカウントで試す——動くなら、アカウントの契約状態か利用量が原因
• 別の端末で試す——動くなら、端末固有の設定が原因

コツは、1回に1つだけ変えることです。同時に2つ変えると、動いたときにどちらが効いたのか分からなくなります。急いでいるときほど複数を一度に変えたくなりますが、結局もう一度やり直すことになります。

そして、どれを試しても同じように失敗するなら、それは自分側ではありません。この結論に自信を持って到達できることが、この手順の価値です。原因が自分にないと分かれば、やるべきことは調査ではなく、業務を止めないための段取りに切り替わります。

エージェントが止まった時は「使えない」だけでは終わらない

ここからが、8月31日の障害がとりわけ示唆的だった理由です。落ちたのはチャットではなく、タスクを開始・継続する部分でした。

途中まで実行された作業が、外の世界に残る

チャットが止まっても、失われるのは「返事」だけです。まだ何も起きていないので、復旧後に同じことをもう一度頼めば済みます。

エージェントは違います。目標を渡すと、複数の工程に分解して順に実行します。ファイルを作る、情報を集める、下書きを保存する、といった結果を伴う動作が途中まで進んでいる可能性があります。そこで止まると、「半分だけ終わった状態」が残ります。

私はこれを、無人で処理を回すようになってから何度も経験しました。止まったこと自体より、止まった位置が分からないことのほうが厄介です。最初からやり直していいのか、続きから進めるべきなのかが判断できず、確認のほうに時間を取られます。

「もう一度お願い」が二重実行になる

止まったタスクをそのまま流し直すと、すでに完了していた工程がもう一度実行されます。読み取りや下書きの生成なら実害は小さいのですが、送信・登録・課金・通知といった外部に作用する動作が含まれていると、二重に起きます。

私が自分の運用で置いている原則は、「何回流し直しても結果が同じになる形にしておく」ことです。途中から再開できる仕組みを作り込むより、いつ落ちても最初から流し直せるほうが、個人や小さな会社の運用では現実的です。この考え方は別の記事で詳しく書いています。

AIの長時間タスクは"落ちても流し直せる"設計にする

「全面復旧」の掲示は、あなたのタスクの復旧ではない

ここが最も誤解されやすい点です。8月31日20時28分の掲示は「影響を受けた全サービスが完全に回復した」でした。これはサービス提供者側の話です。

止まったあなたのタスクが自動的に再開する、という意味ではありません。復旧後にやるべきことは「動くようになったか」の確認ではなく、「どこまで終わっていて、どこから残っているか」の確認です。

この違いを意識していないと、復旧を確認して安心し、中途半端な成果物をそのまま次の工程に流してしまいます。止まる失敗は気づけますが、止まらずに中途半端に進んだ失敗は気づけません。後者のほうが後で高くつきます。

落ちている間、業務を止めないための備え

障害そのものは防げません。防げるのは「障害が業務の停止に直結すること」のほうです。私が実際にやっていることを挙げます。

経路を2つ持っておく

いちばん効く備えがこれです。用途の近いAIサービスを2系統使える状態にしておくと、片方が落ちてももう片方で当日の仕事は進みます。

ポイントは、障害が起きてから乗り換え先を探さないことです。普段からどちらも触っていて、ログインできる状態にしてあることに意味があります。障害の最中に新規登録や支払い設定をやるのは、いちばん不利な条件での作業になります。

他社サービスの障害確認についても、同じ考え方で手順を持っておくと安心です。

Claudeの障害を確認する方法｜落ちた時に業務を止めない手順

締切のある仕事ほど、時間を前に寄せる

提出期限の当日に、AIに依存した工程を残さないという段取りの話です。当たり前に聞こえますが、5時間半止まるという事実を知った上で予定を組んでいる人は多くありません。

8月31日の障害は約5時間24分でした。半日は動かないかもしれないという前提を1回でも経験しておくと、締切前日にまとめて片付ける組み方をしなくなります。

無人で回す処理は「流し直せる」形にしておく

夜間や早朝に自動で走らせている処理がある場合、失敗を前提に設計してください。具体的には次の3点です。

• 途中で失敗したら、中途半端に進めずに止める——曖昧な状態で先に進ませない
• やったことを追記の記録に残す——後から「どこまで進んだか」を人が読める形にする
• 1回の実行を小さく切る——長い処理ほど、途中で落ちたときの復旧が難しくなります

この3つがあると、朝に結果を見たとき「失敗した」と「途中まで成功した」を区別できます。区別できることが、そのまま復旧の速さになります。

チームで使っているなら、最初にやるのは共有

複数人で同じサービスを使っている場合、障害だと分かった時点で全員に伝えるのが最優先です。伝えないと、全員が同時にそれぞれ自分の設定を疑い始めます。5人いれば、同じ調査が5回行われることになります。

共有する内容は、「落ちている」「公式に掲示が出ている」「復旧見込みは不明」「今日はこちらで代替する」の4点で十分です。詳しい原因を待つ必要はありません。

復旧したあとにやること

掲示がResolvedになったら、次の順で確認します。

• 止まっていたタスクの状態を見る——完了しているのか、途中なのか、消えているのか
• 途中だったものは、どこまで進んだかを確認する——特に外部に作用する動作（送信・登録・保存）が実行済みかどうか
• 流し直す前に、二重に実行されて困るものがないかを見る——ここを飛ばすと二重送信が起きます
• 障害の時間帯と、自社の処理の実行時刻を突き合わせる——影響範囲を確定させる
• 時間帯が重なっていた失敗は、原因調査をしない——障害由来と分かっているものを調べるのは時間の無駄です

最後の項目は、地味ですが効きます。「なぜ失敗したのか分からない」を1件でも減らせると、次に本当に自分側の問題が起きたときに、それが目立つようになります。

よくある質問

ステータスページが正常なのにエラーが出ます。どちらを信じればいいですか

まずは数分待って、もう一度ステータスページを見てください。掲示にはラグがあります。それでも変わらず、かつ別の回線・別のブラウザ・別のアカウントでも同じように失敗するなら、掲示の基準に届いていない部分的な障害の可能性があります。焦って自分の設定を大きく変えないでください。復旧後に、変えた設定のほうが問題を引き起こします。

ChatGPT Workだけが止まって、チャットは使えることはありますか

あります。2026年8月31日の障害がまさにそれで、公式の掲示は「ChatGPT Workでタスクを開始・継続できない」という内容であり、通常のチャットは部分的に使える状態でした。ですから「ChatGPTは開けるから障害ではない」という判断は誤りになりえます。自分が使っている機能が動くかで見てください。

障害はどのくらい続くものですか

事象によりますが、8月31日の例では開始から全面復旧まで約5時間24分でした。原因を特定した旨の掲示（Identified）が出てからも4時間以上かかっています。「原因が分かった＝もうすぐ直る」ではないと考えておくのが安全です。復旧見込みの時刻が公表されないことも珍しくありません。

過去に障害があったかを後から調べられますか

調べられます。ステータスページには過去のインシデント履歴が残るので、日付と時間帯を突き合わせれば、自社の失敗が障害と重なっていたかを確認できます。夜間に自動処理を走らせている場合はこの確認が特に有効です。時刻の表示がどのタイムゾーンかだけ、注意して見てください。

復旧したら、止まったタスクは自動で再開しますか

期待しないほうが安全です。復旧の掲示はサービス側が回復したという意味であって、個々のタスクの再開を保証するものではありません。まず状態を確認し、外部に作用する動作が実行済みでないかを見てから、流し直すかを決めてください。

まとめ

ChatGPTが動かないときの確認は、公式ステータスページ → 外の声 → 自分側の3ステップに固定します。順番を守るだけで、無駄な調査時間が大きく減ります。

そして2026年8月31日のChatGPT Work障害が教えてくれたのは、エージェントの障害はチャットの障害と性質が違うということです。タスクを開始・継続できない状態では、途中まで進んだ作業が残ります。復旧の掲示を見て安心するのではなく、「どこまで終わっていて、どこから残っているか」を確認する——これが、AIに仕事を任せる時代の復旧手順になります。

備えとして効くのは、経路を2つ持つこと、締切前日にAI依存の工程を残さないこと、無人の処理を流し直せる形にしておくことの3つです。どれも障害が起きてからでは間に合わないので、動いているうちに整えておいてください。

AIを業務に組み込むとき、「止まったらどうするか」まで含めて設計しておきたい——そうお考えの場合は、私たちの伴走支援でご一緒できることがあります。

AI導入・活用の伴走支援について見る

参考にした情報源

• OpenAI Status — ChatGPT Work seeing elevated errors and latency（公式インシデント記録・2026年8月31日）
• BleepingComputer — OpenAI confirms ChatGPT outage as users report errors（2026年8月31日）
• SQ Magazine — OpenAI Confirms ChatGPT Outage Hitting Paid Work Mode Users（2026年8月31日）