Codexの障害を確認する方法｜落ちたか自分側かの見分け方
「Codexが途中で止まったまま返ってこない」「CLIで401が出て先へ進めない」——仕事の途中でCodexが動かなくなると、OpenAI側の障害なのか、自分のログインや設定の問題なのかが分からず、まず手が止まります。
結論から言うと、Codexの障害はOpenAIの公式ステータスページ（status.openai.com）で確認できます。ただしCodexの行はページの2か所に分かれています。「Codex」の欄（Codex Web・Codex API・CLI・VS Code extension）と、「ChatGPT」の欄の中にある「Codex in ChatGPT Desktop」です。片方だけを見て「正常」と判断すると外します。公式が正常なら、次に疑うのはログイン・利用上限・モデル名の3つです。
株式会社Fyveは、Codex CLIを無人の定期処理に組み込み、毎日の作業の一部を任せています。この記事では、公式ページと公開されている障害記録をもとにCodexの障害を確認する手順を整理し、私たちの運用で「障害だと思ったら自分側だった」3つの実例と、止まっても業務を止めないための備えをお伝えします。
結論：Codexが落ちたかは3ステップで確認する
先に手順だけをまとめます。
- status.openai.com を開き、自分が使っている入口の行を見る（下の表。「Codex」の欄と「ChatGPT」の欄の両方を確認する）
- 公式が正常なら、自分側を順に確かめる（ログイン → 利用上限 → モデル名と設定）
- それでも分からなければ、エラーの文言と時刻を控えて切り分ける（同じ時刻に別の入口では動くかを試す）
使っている入口 | status.openai.com で見る行 |
|---|---|
ブラウザのCodex（chatgpt.com のCodex画面） | 「Codex」欄の「Codex Web」 |
ターミナルのCodex CLI | 「Codex」欄の「CLI」 |
VS Codeの拡張機能 | 「Codex」欄の「VS Code extension」 |
APIキーでCodexを使っている | 「Codex」欄の「Codex API」 |
ChatGPTのデスクトップアプリの中のCodex | 「ChatGPT」欄の「Codex in ChatGPT Desktop」 |
2026年10月19日に私たちが確認した時点で、「Codex」の欄には4つの行（Codex Web・Codex API・CLI・VS Code extension）があり、「Codex in ChatGPT Desktop」だけは「ChatGPT」の欄に入っていました。デスクトップアプリでCodexを使っている人は、「Codex」の欄が全部正常でも安心できません。この違いが実際の障害でどう出たかを、次の節で見ます。
2026年10月13日・14日に実際に起きたこと
抽象的な説明より、実際の記録を読むほうが早く理解できます。status.openai.com には、2日続けてCodexに関わる障害が記録されています。時刻はすべて日本時間に直しています。
10月13日：GPT-6.1 Solを使ったCodexだけが重くなった
1件目の掲示のタイトルは「Degraded performance in GPT-6.1 Sol Codex and Work mode」（GPT-6.1 SolのCodexとWorkモードで性能低下）です。公式ページの記録は次のとおりです。
- 17時10分：調査中（Investigating）の掲示
- 17時18分：影響の始まりとして記録された時刻
- 18時30分：緩和策を入れて回復を見守っている（Monitoring）
- 翌14日1時36分：解決（Resolved）
影響を受けた行として挙がっていたのは、「Codex」欄の4つ（Codex Web・Codex API・CLI・VS Code extension）と「ChatGPT Work」です。入口を問わず、Codexのどこから使っても影響が出うる障害でした。
この記録で目を引くのは、タイトルにモデル名が入っていることです。OpenAIは解決の掲示でも「GPT-6.1 Solによる性能低下の原因を解決した」と書いており、モデル単位の障害として扱っていました。公式は「別のモデルなら動く」とまでは書いていません。それでも、急ぎの作業があるときは、使うモデルを切り替えて小さな作業で試してみる価値はあります。
10月14日：「Codex」の欄は正常のままだった
翌日にも「Degraded performance in Codex and ChatGPT Work」（CodexとChatGPT Workで性能低下）という掲示が出ました。
- 16時05分：原因を特定し、緩和策を準備中（Identified）
- 18時19分：緩和策の適用を続けている
- 18時53分：すべて回復（Resolved）
このとき影響を受けた行として挙がっていたのは、「ChatGPT Work」と「Codex in ChatGPT Desktop」の2つだけでした。タイトルには「Codex」と入っているのに、「Codex」の欄の4行は影響を受けた行に含まれていません。
つまり、ChatGPTのデスクトップアプリでCodexを使っていた人にとっては障害でしたが、ページの「Codex」の欄だけを見ていたら、緑のまま見えていたことになります。入口ごとに行が違う、という前の節の表が効くのはこういう場面です。
「緩和策を入れた時刻」と「解決の時刻」は違う
10月13日の記録では、緩和策を入れたのが18時30分、解決の掲示が翌1時36分でした。その間の約7時間は「Monitoring（様子見）」のままです。
Monitoringは「対策は入れたが、戻ったかどうかを確かめている途中」という意味です。この段階で動くようになったと感じても、大きな作業を一気に流し直すのは早すぎます。まず小さな作業で動くことを確かめ、解決の掲示が出てから本来の量に戻すのが安全です。
10月だけで、Codexに関わる掲示は5件あった
公式ページのJSON（機械が読むための形式）の記録から、2026年10月1日〜19日にタイトルへ「Codex」を含む掲示を数えると5件でした。
最初の掲示（日本時間） | 掲示のタイトル（原文） |
|---|---|
10月6日 2時58分 | Elevated error rates in Codex Cloud |
10月8日 1時31分 | Dot in Codex may fail to create new threads |
10月8日 2時21分 | Degraded performance in Codex and Work mode: Dot turn failures, delayed responses, and reduced proactivity |
10月13日 17時10分 | Degraded performance in GPT-6.1 Sol Codex and Work mode |
10月14日 16時05分 | Degraded performance in Codex and ChatGPT Work |
日本の深夜〜明け方に当たる掲示が3件、平日の夕方に当たる掲示が2件です。米国の昼間に起きた障害は、日本では夜中に当たります。夜間にCodexへ任せている処理がある場合、朝に失敗が溜まっていることがある、と考えておくほうが現実的です。
①status.openai.com の読み方
Codexの行は2か所にある
繰り返しになりますが、いちばん大事な点なので整理します。
- 「Codex」の欄：Codex Web・Codex API・CLI・VS Code extension の4行
- 「ChatGPT」の欄：Codex in ChatGPT Desktop（ほかに ChatGPT Work など）
また、掲示のタイトルに出てくる「Codex Cloud」や「Dot in Codex」のように、ページの行の名前と一致しない呼び方が使われることもあります。行の色だけでなく、上に出ている掲示のタイトルも読む習慣をつけると見落としが減ります。
掲示の4つの段階
障害の掲示は、次の4つの段階で更新されていきます。いずれも10月の実際の記録に出てきたものです。
表示 | 意味 | 利用者がすること |
|---|---|---|
Investigating | 調査中。原因はまだ分かっていない | 自分側の設定を触らずに待つ。急ぎなら別の経路へ |
Identified | 原因を特定し、対策を準備中 | 同上。復旧の見込みが立ち始めた段階 |
Monitoring | 対策を入れ、回復を見守っている | 小さな作業で動作を確かめる。大量の流し直しはまだ |
Resolved | 解決 | 止まった作業の後始末（後の節）をしてから再開する |
なお、掲示が「Investigating」から始まるとは限りません。10月6日と10月14日の掲示は、最初から「Identified」でした。
先に気づく：更新の購読とRSS
ページ上部の「Subscribe to updates」から更新を受け取れます。RSSで受け取りたい場合は、status.openai.com/feed.rss が使えます（2026年10月19日に私たちが開いて、更新が配信されていることを確かめました）。
チームでCodexを使っているなら、RSSを社内チャットのチャンネルに流しておくと、誰か1人が気づけば全員に伝わります。ただしRSSにはCodex以外の掲示も流れてくるので、「Codex」を含む掲示だけを通知するように絞ると、通知に慣れて読まなくなるのを防げます。
履歴で後から確かめる
「昨日の夜に止まっていたのは障害だったのか」を後から確かめるときは、status.openai.com/history の履歴ページを開きます。個々の掲示のページには、影響を受けた行・影響の始まりと終わり・更新の記録が残っています。
注意したいのは時刻の表記です。私たちが照合した範囲では、個々の掲示のページの時刻は協定世界時（UTC）と一致していました。日本時間に直すには9時間を足します。たとえば10月13日の掲示は、ページ上では「08:18 AM」から「04:36 PM」と表示されますが、日本時間では13日17時18分から14日1時36分です。
②公式が正常なのに動かないとき：自分側を3つの順で見る
公式ページが正常なら、原因は自分側にある可能性が高くなります。私たちは次の順で確かめています。上から順に、確かめるのが速く、当たる確率が高いものです。
1. ログイン（認証）：codex login status
401（認証エラー）や「ログインし直してください」という文言が出たら、まずログインを疑います。OpenAIの公式ドキュメント「Authentication」によると、CLIでは次のコマンドが使えます。
codex login status：今どの方法でログインしているかを確認するcodex logout→codex login：ログインし直す
同じドキュメントには、ログイン情報は ~/.codex/auth.json かOSの資格情報ストアに保存され、CLIとVS Codeの拡張機能は同じログイン情報を共有すると書かれています。片方でログアウトすると、もう片方もログインし直しになります。
ChatGPTのアカウントでログインしている場合、トークン（ログイン状態を保つための鍵）は期限が切れる前に自動で更新されるので、普段はブラウザでログインし直す必要はありません。逆に言えば、自動更新が失敗したときは、ログインし直すまで直りません。ブラウザの無いサーバーなどでは、公式は codex login --device-auth（デバイスコードでのログイン・ベータ）を第一の方法として案内しています。
2. 利用上限：/status とダッシュボード
エラーではなく「上限に達しました」という趣旨の文言なら、障害ではなく利用上限です。公式の料金ページによると、残りの利用量は次の2か所で確認できます。
- CLIの実行中：
/statusと入力する - ブラウザ：chatgpt.com/codex/settings/usage の利用状況のページ
同じページには、PlusとStandard Businessは5時間ごとの枠で見積もりが示されていること、週ごとの上限がかかる場合もあることが書かれています。上限に達しても、作業中のターンはそのまま続けられ（公正利用の範囲内）、PlusとProではクレジットを追加で購入して続けられる、とも案内されています。プランごとの具体的な回数は変わることがあるので、使う前に公式の料金ページで確認してください（2026年10月19日時点の記述にもとづいています）。
3. モデル名と設定：404「そのモデルは存在しない」
「The model … does not exist or you do not have access to it」（そのモデルは存在しないか、使う権限がありません）のような404が出たら、障害ではなく指定しているモデル名が使えなくなっている可能性があります。設定ファイルやスクリプトにモデル名を書き込んでいる場合、モデルの入れ替わりで突然動かなくなります。
インストール・サンドボックス・ネットワークなど、エラーごとの細かな直し方は次の記事にまとめています。
利用量の見方をもっと詳しく知りたい場合はこちらです。
私たちの運用で起きたこと：3回とも「障害」ではなかった
私たちは、Mac miniで無人の定期処理を動かし、その一部でCodex CLIを使っています。たとえばブログ記事のサムネイル画像は、Codex CLIに頼んで作らせています。毎日動かしているので、Codexが失敗した記録も残っています。
振り返ると、Codexが私たちの処理で失敗した主な原因は3つあり、どれもOpenAI側の障害ではありませんでした。
1回目：401が約6週間続いた（2026年7月15日〜8月27日）
7月15日から、CLIが401で失敗するようになりました。ログに残っていた文言は次のとおりです。
Failed to refresh token: Your access token could not be refreshed. Please log out and sign in again.- 同じ時期には「refresh token already used」「refresh token revoked」（更新用の鍵が使用済み・取り消し済み）という文言も出ていました
同じ期間に、公式ページにはCodexの認証に関する障害が1件だけ記録されています。2026年8月20日の「Elevated Codex API authentication errors」で、影響の時間は日本時間8月21日1時58分から2時15分までの17分でした。対象も「Codex API」の行だけです。私たちの401は約6週間続いていたので、公式の障害とは関係がなく、こちらのログイン情報の問題だったことになります。
直すにはログインし直すしかありませんでした。前の節のとおり、自動更新が失敗した状態は時間がたっても直りません。
そしてこの件で私たちがいちばん反省しているのは、気づくのが遅れたことです。私たちの処理は、Codexが失敗したら別の画像生成（GoogleのGemini API）に切り替えて続ける作りにしていました。そのおかげで仕事は1日も止まりませんでしたが、止まらなかったぶん、失敗が「毎回の報告の1行」に埋もれました。しかも切り替え先は使った分だけ料金がかかる経路で、Codexの経路はサブスクリプションの範囲で使えるはずでした。逃げ道があることと、壊れたまま放置されることは表裏一体です。
2回目：「そのモデルは存在しない」404（2026年9月8日）
ログインし直したあと、9月1日から7日まではCodexの経路が7回続けて成功していました。ところが9月8日に、今度は404で失敗します。
原因は、私たちのスクリプトがCodexに渡していたモデル名でした。指定していたモデルが使えなくなり、「そのモデルは存在しないか、使う権限がありません」と返されていたのです。これも障害ではなく、モデルの入れ替わりにこちらの設定が追いついていなかっただけでした。
今は、モデル名をスクリプトの外から指定できる形にしています。モデルが入れ替わっても、直す場所が1か所で済みます。モデル名を書き込んだ設定は、動いている間は誰も見返さないので、壊れて初めて存在を思い出すものだと考えておくほうが安全です。
3回目：返事は返ってくるのに、頼んだ道具が使われていない
3つ目は、いちばん気づきにくいものでした。Codexにサムネイル画像の生成を頼むと、エラーは出ずに画像ファイルが返ってきます。ところが中身を見ると、頼んだ画像生成の機能を使わず、Codexがプログラムで図形と文字を描いて代わりの画像を作っていたことがありました。
エージェント（自分で手順を考えて動くAI）は、頼んだ方法が使えないとき、止まるのではなく別のやり方で「完了」を返すことがあります。人が見ていれば一目で気づきますが、無人の処理ではそのまま次の工程へ流れてしまいます。
そこで私たちは、Codexが本当に画像生成の機能を使ったかを、出力された記録から確かめるようにしました。使われていなければ、返ってきた画像を捨てて「失敗」として扱います。「エラーが出ていない」ことと「頼んだとおりに動いた」ことは別だ、というのがこの件の教訓です。
3つの実例から作った切り分けの順番
この3件を経て、私たちはCodexが失敗したときに次の順番で確かめるようにしています。
表にすると次のとおりです。
見えている症状 | まず疑うこと | 確かめ方 |
|---|---|---|
公式ページに掲示が出ている | OpenAI側の障害 | 自分の入口の行が影響を受けているかを見る |
401・「ログインし直して」 | ログイン情報 |
|
「上限に達した」 | 利用上限 |
|
404「モデルが存在しない」 | モデル名の設定 | 設定ファイル・スクリプトのモデル名 |
エラーは無いが結果がおかしい | 別のやり方で「完了」した | 成果物と実行の記録を見る |
落ちている間、業務を止めないための備え
経路を2つ持っておく
Codexが止まったときに代わりに使える道具を、あらかじめ決めておきます。私たちの場合、画像生成はGemini API、コードの作業はClaude Codeが代わりの経路です。止まってから探すと、慣れない道具の設定で時間を使ってしまいます。
ChatGPTの障害でも同じ考え方を書いています。
無人の処理は「失敗の回数」を数えて知らせる
1回目の実例のとおり、代わりの経路があると失敗に気づきにくくなります。私たちは今、代わりの経路に切り替えた回数を報告に出し、続けて切り替わっていたら人が見る、という形にしています。逃げ道は、使われたことが見える状態にしてはじめて安全になります。
締切のある仕事ほど、Codexに任せる時間を前に寄せる
10月の記録では、平日の夕方にも障害が起きていました。締切の直前にCodexへ大きな作業を任せると、止まったときに取り返す時間がありません。締切のある仕事は、前日までに一度通しておくのが安全です。
チームで使っているなら、最初にやるのは共有
障害が分かったら、まずチームに「今Codexが止まっている。公式で確認済み」と伝えます。各自がログインし直したり設定を触ったりし始めると、障害が直ったあとに別の問題が残ります。
復旧したあとにやること
Codexは、ファイルを書き換えながら作業を進めます。途中で止まると、書き換えが半分だけ終わった状態のファイルが手元に残っていることがあります。チャットのAIが止まったときとの大きな違いはここです。
- 変更の差分を見る：gitで管理しているなら、
git statusとgit diffで、止まった作業がどこまでファイルを変えたかを確かめる - 同じ指示をそのまま流し直さない：半分終わった変更の上にもう一度同じ作業をさせると、二重に書き換えることがある。差分を確かめてから、元に戻すか、続きから頼むかを決める
- 小さな作業で動作を確かめてから戻す：Monitoringの段階と同じく、いきなり本来の量に戻さない
- 無人の処理は、失敗した回を拾い直す：夜間の処理なら、障害の時間帯に失敗した回を記録から探して流し直す
よくある質問
公式ページが正常なのにエラーが出ます。どちらを信じればいいですか
まず、自分の入口の行を見ているかを確かめてください。デスクトップアプリなら「ChatGPT」の欄の「Codex in ChatGPT Desktop」です。そのうえで正常なら、ログイン・利用上限・モデル名の順に確かめます。障害の掲示は、起きてから出るまでに時間がかかることもあるので、数十分おいてもう一度見るのも有効です。
ChatGPTは使えるのに、Codexだけ動かないことはありますか
あります。10月13日の障害は、GPT-6.1 Solを使ったCodexとChatGPT Workが対象で、ChatGPTの通常の会話は影響を受けた行に含まれていませんでした。CodexとChatGPTは別の行として記録されるので、別々に確かめてください。
401が出ました。障害ですか
障害のこともありますが、私たちの経験では、ほとんどはログイン情報の問題でした。公式ページに認証の障害が出ていなければ、codex login status で状態を確かめ、ログインし直してください。数時間たっても同じなら、待っても直らない種類の失敗だと考えてよいです。
障害で使えなかった時間の分、利用上限は戻りますか
公式の料金ページには、障害のときに上限を戻すという決まりは書かれていません（2026年10月19日時点）。上限が気になる場合は、復旧後に /status か利用状況のページで残りを確かめてください。
過去に障害があったかを後から調べられますか
調べられます。status.openai.com/history の履歴ページに、障害ごとの記録が残っています。個々のページの時刻はUTCなので、日本時間は9時間を足して読んでください。
まとめ
- Codexの障害は status.openai.com で確認する。Codexの行は「Codex」の欄（Codex Web・Codex API・CLI・VS Code extension）と、「ChatGPT」の欄の「Codex in ChatGPT Desktop」の2か所にある
- 2026年10月14日の障害では、デスクトップアプリのCodexだけが影響を受け、「Codex」の欄は正常のままだった
- Monitoringは「対策を入れて様子を見ている途中」。解決の掲示までに7時間かかった例もある
- 公式が正常なら、ログイン → 利用上限 → モデル名の順に自分側を確かめる
- 私たちの運用では、Codexが失敗した主な原因3つ（401・404・頼んだ道具が使われない）は、どれも障害ではなかった
- 代わりの経路を持ちつつ、切り替えた回数が見える状態にしておく。復旧後は、半分書き換わったファイルを確かめてから再開する
株式会社Fyveでは、Codexをはじめとする生成AIを、止まっても困らない形で業務に組み込むお手伝いをしています。
参考にした情報源
- OpenAI Status（2026年10月19日に確認）
- OpenAI Status：履歴（2026年10月19日に確認）
- Degraded performance in GPT-6.1 Sol Codex and Work mode（2026年10月13日の掲示）
- Degraded performance in Codex and ChatGPT Work（2026年10月14日の掲示）
- Elevated Codex API authentication errors（2026年8月20日の掲示）
- SessionWatcher：10月13日のCodexの性能低下（第三者による障害の記録）
- OpenAI：Authentication（Codexのログイン）（2026年10月19日に確認）
- OpenAI：Codexの料金と利用上限（2026年10月19日に確認）
Codexを使い始める前に、「絶対に」見直してほしい5つのこと
学習の設定・確認なしの操作・戻せる状態など。Codexにそのまま貼れる頼み方つき（全9ページ）
Codexは便利な一方で、設定ひとつで「聞かずに動く」ようになります。この資料を作るために自分の設定を開いたら、本番のデータベースを書き換える操作が、覚えのないうちに確認なしで動く状態になっていました。使い始める前に見直してほしい5つを、Codexにそのまま貼れる頼み方と一緒にまとめました。
- 仕事の画面や資料を、AIの学習に使わせない設定
- 取り返しのつかない操作が確認なしになっていないか、Codexに調べさせる頼み方
- AGENTS.mdのいちばん上に書く「絶対にしないこと」の例
- 失敗しても戻せる状態で始める方法と、使えなくなったAIの指定の直し方
メールアドレス登録で他にも様々な資料を閲覧できます
＋8PDF 17点・合計440ページ ＋ すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
御社の業務に合わせたCodex導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。