ChatGPT・Codexが落ちた・動かない時の対処方法|障害・利用上限・認証を切り分ける

ChatGPTの会話が開かない、Codexが処理中のまま止まる、APIだけエラーになる。いずれも「OpenAIが落ちた」と見えますが、利用上限、認証、端末内の実行待ちでは必要な対応が違います。最初に作業を保護し、どこまで使えるかを比較してから設定を変更しましょう。

【要点】ログアウトより先に確認すること

• 送信前の文章と、Codexが変更したファイルを保存します。
• 古い会話だけか、新しい短い会話でも失敗するかを調べます。
• Codexは承認待ち・ターミナルの入力待ち・利用上限を確認します。
• 再ログインは認証の問題が疑われ、ログイン手段を確保できた時だけ行います。

公式サービス障害モニターほかのサービスの障害・メンテナンス・復旧履歴を確認

このモニターはOpenAIの公開情報を表示します。ChatGPT、Codex、APIのどの機能が対象かは個別の発表で確認してください。正常表示でも、特定モデルやアカウントだけの問題、まだ公表されていない障害は否定できません。

症状から調べる場所を選ぶ

ChatGPTの画面を安全に切り分ける

1. 入力欄の文章を社内で許可された保存先へコピーします。元の会話URLとエラー文、発生時刻も残します。
2. 新しいタブでChatGPTを開き、同じアカウント・ワークスペースか確認します。既存の長い会話を再送する代わりに、機密情報を含まない短い質問を1回試します。
3. 新規会話は動くなら、会話単位の問題や添付・連携機能を疑います。元の会話を削除する必要はありません。
4. 許可された別ブラウザでも同じか比較します。シークレット画面は既存Cookieを使わないため、追加認証が必要になることがあります。会社のSSO制限にも従ってください。

一方のブラウザだけ失敗する場合は、自分で追加した拡張機能を一つずつ止めて比較します。会社指定の保護機能やVPNは勝手に解除しません。別回線で試せる場合も社内規程を優先し、比較結果を管理者に渡します。「スマートフォンでは動く」は原因を絞る材料であり、全体障害がないという証明ではありません。

Codexが止まった時は実行待ちを見落とさない

承認ボタンや追加質問が出ていないか、実行しているコマンドが入力を待っていないかを確認します。画面の返答が止まっていても、ファイルの生成・テストが裏で継続している場合があります。同じ作業を別の会話で直ちに再開すると、二重編集や二重実行につながります。

Git管理の作業場所なら、ターミナルで読み取り中心の git status を実行し、変更の有無と作業ディレクトリを確認できます。表示確認のために reset --hard や未追跡ファイルの削除を行わないでください。コマンドも動かない時は、既存処理の状態を確認してからターミナルを開き直します。これらはOpenAIのデスクトップアプリのトラブルシューティングでも案内される確認です。

モデルとの会話は成立し、特定の外部連携だけ失敗するなら、その連携先の認証や障害を調べます。アプリ再起動は進行中の作業が終了したか、安全に中断できるかを確認した後です。未保存ファイル、直前の指示、実行結果を残しておくと再開しやすくなります。

APIの401・429・5xxを同じ扱いにしない

APIでは画面への再ログインより、実際のレスポンスが重要です。401は認証情報や組織設定、429はリクエスト頻度だけでなく残高・支出上限なども確認します。500や503は一時的なサーバー側の問題を含みます。OpenAI公式のエラーコード一覧と本文のコードを照合し、Retry-Afterがあれば指定時間を守ります。上限設定は管理者の承認なく引き上げません。

通信が切れた場合、処理が受理されていないとは限りません。ファイル作成や外部操作を伴う処理は、実行履歴を確認してから再試行します。リクエストID、利用モデル、発生時刻、エラー種別を記録し、APIキーや会話本文を公開掲示板へ貼らないでください。

ログアウトを試す条件と復旧の確認

認証ループが続き、別ブラウザでは同じアカウントに正常に入れる場合などに、問題のある画面だけでログアウト・再ログインを試します。Google・Microsoft・Apple・会社SSOなど、普段の方式と二要素認証が使えることを先に確認します。全端末からの強制ログアウトやアカウント削除は、障害確認のための手順ではありません。

復旧後は小さな質問を一度送信し、保存済みの会話、Codexの変更差分、APIの失敗ジョブを別々に確認します。生成結果が戻っただけで、途中の処理まで完了したと判断しないことが大切です。

まとめ

ChatGPT・Codexの不調は、公開障害、アカウントの制限、端末側の実行状態を分けて確認します。作業を保護してから小さな比較テストを行い、認証の根拠がある時に再ログインへ進む順番なら、復旧作業そのものによる損失を防ぎやすくなります。

国内の通信・アプリ・企業システム障害のまとめを見る