ChatGPT障害が7月24日に再発　API・Codexにも広がった影響と復旧状況

2026年7月24日07時00分JST時点で、ChatGPT(チャットGPT)を含む主な障害は完全復旧を示すResolvedへ進んでいません。OpenAIの主インシデントは一度Monitoringへ進んだ後にInvestigatingへ戻り、05時22分JSTに再びMonitoringとなりました。

仕事でChatGPT、API、Codexを使っている場合は、一度つながっただけで完全復旧と判断しないことが先決です。
重要処理の再実行を連打せず、公式Statusと自社側の正常性を分けて確認してください。

ChatGPT障害は7月24日07時時点もResolvedではない

今回のタイトルにある「再発」は、完全復旧後に別の障害が起きたという意味ではありません。
緩和策の適用後、状態がMonitoringからInvestigatingへ戻ったことを指します。
その後、05時22分JSTに再びMonitoringへ進みました。

具体的な根本原因と完全復旧時刻は未公表です。OpenAIは下流インフラ提供者と緩和策を実装していると説明しましたが、提供者名を特定企業へ結び付ける根拠は出ていません。

出典: OpenAI Status「Elevated Error Rates」(英語)

ChatGPT・API・Codex障害の公式時系列

主インシデントの更新

JST	公式状態	要点
00:36	Investigating	調査開始
00:56	Identified	緩和策へ
01:48	Identified	下流基盤と対応
03:50	Monitoring	回復を監視
04:37	Investigating	再び調査
05:22	Monitoring	再び回復を監視

見るべき変化は、03時50分から04時37分への逆戻りです。過去のCodexのGitHub障害でも、公式時系列と自分の症状を分けて見ると復旧判断を誤りにくくなります。

ChatGPT限定の別インシデント

同じ時間帯には、ChatGPTだけを対象とする別の障害も掲載されました。
02時56分JSTにIdentified、03時22分JSTにMonitoringへ移り、05時41分JSTにResolvedとなりました。

2件の公式ページは原因が同じだと発表されていません。
一つの原因でまとめて説明しないことが正確です。

出典: OpenAI Status「Some users may experience elevated error rates in ChatGPT」(英語)

ChatGPT障害の影響範囲はどう読むか

主インシデントの影響対象は、APIが12、ChatGPTが4、Codexが4コンポーネントです。これは公式Status上の対象部品数で、全リクエストの失敗率や全利用者の停止率ではありません。

画像生成だけで失敗する場合は、過去のChatGPT画像生成障害の切り分けも参考になります。
症状が限定機能だけか、ChatGPT全体かを先に分けてください。

ChatGPTでエラーが出た時の切り分け

今日のChatGPTエラーは、最初にOpenAI Statusを見るのが近道です。掲載中なら利用者側の設定変更を繰り返すより、入力内容を保存して待機します。

• Status掲載中なら、30〜60秒待って生成停止、再生成、新しいチャットを一度ずつ試す
• Statusが正常なら、アプリ再起動、ハードリロード、別ブラウザ、VPN停止、別回線の順に試す
• 複数環境で続くなら、発生時刻、モデル、会話URLまたはID、画面表示を保存する

再読み込みや送信を何度も連打するのは避けます。
個別エラーの切り分けは、Codexのアクセス拒否障害で紹介した「公式状態とローカル環境を分ける」考え方も共通です。

出典: OpenAI Help Center「Troubleshooting ChatGPT Error Messages」(英語)

API・Codex障害で企業が止めること

OpenAI APIやCodexを業務に組み込んでいる企業は、AI障害を「画面が使えない問題」ではなく業務継続の問題として扱う必要があります。
受付、顧客対応、承認、請求へつながる処理から先に守ってください。

• モデル、サービス階層、プロジェクトを分けて集計する
• エラー件数ではなくエラー率を平常時と比べる
• request ID、時刻、タイムゾーン、HTTPステータスを保存する
• 保留データの重複防止を確認してから再処理する

APIのエラー件数が増えても、通信量自体が増えた可能性があります。
公式ヘルプは、件数ではなく割合を見るよう案内しており、モデル・階層・プロジェクトを混ぜないことも確認事項です。

Codex側の障害対応は、Codexのサーバー過負荷と復旧状況も合わせておくと、再試行を止める判断軸が揃います。
自動処理を止められない設計のまま復旧を待つのは避けてください。

出典: OpenAI Help Center「Troubleshooting API Errors and Latency」(英語)

ChatGPT障害で業務を戻す判断

ChatGPT障害の復旧判断とは、公式の状態と自社の正常性を二段階で確かめ、滞留処理を少しずつ戻すことです。
公式がResolvedになっても、すぐ全件を再投入しないでください。

「使えたから復旧」と「業務を安全に戻せる」は別です。
短時間の全面停止から復旧したSora API障害の事例も、公式時刻と自社側の再開手順を分ける参考になります。

ChatGPT障害に関するFAQ