Codexが動かない時のstatus確認

このページで整理すること

• 公式statusの位置づけ
• OpenAI公式情報の見方
• 障害情報とchangelog
• 古い情報への注意
• SNS情報だけで判断しないこと

最初に見るところ

Codexが止まる、遅い、動かないと感じた時は、原因を決めつけず、サービス側の状態、自分の環境、ログ、報告書を分けて確認します。

Codexで確認できること

1. 表示されたエラー文を確認する
2. 公式statusや公式情報を見る
3. codex doctorでauth、network、configを確認する
4. ログの更新時刻や最後の処理を見る
5. 追加実装せず、止める条件に当たるか判断する
6. 確認結果を報告書にまとめる

Codexだけに任せないこと

status確認やdoctor結果だけで、本番設定、DB、cron、.htaccess、AdSense、Search Console確認タグを変更しないようにします。障害、認証、通信、設定、作業範囲は人間が切り分けて判断します。

止める条件

statusページの読み方のコツ

公式statusページを開いた時、確認すべきポイントは3つあります。

• 「全体」ではなく「自分が使う機能」の行を見る：statusページはサービスごと・機能ごとに行が分かれていることが多く、全体が正常表示でも特定機能だけ障害中のことがあります。逆に、どこかで障害が出ていても自分の使う機能と無関係なら影響しません。
• 「現在」と「過去のインシデント履歴」を区別する：statusページには過去の障害記録も並びます。日付を見ずに「障害が出てる！」と読むと、数日前に解決済みの記録を今の障害と誤読します。
• 復旧表示後もしばらくは不安定なことがある：「Resolved」と表示された直後は、残った影響で調子が悪い場合があります。復旧表示を見たのに不調が続く時は、少し時間を置いてから再確認すると無駄な設定変更を避けられます。

そして最重要の順番は「公式statusで障害が出ているなら、自分の環境は触らない」です。サービス側の障害中に手元の設定を変更すると、障害が復旧した後に「自分が変えた設定」が新しい不調の原因として残ります。障害中にやることは、待つことと、確認した内容を記録しておくことだけで十分です。

公式statusが「正常」なのに動かないとき

実際に多いのはこちらです。公式statusはサービス提供側の障害しか示しません。自分の側で止まっている場合、statusは最後まで正常のままです。次の順に見ると、たいてい2つ目までで当たります。

上限と障害は画面の見え方が似ています。どちらも「急に応答しなくなる」ので混同しやすいのですが、障害は待つしかなく、上限は時刻で戻ります。ここを取り違えると、戻るはずのものを諦めたり、逆に戻らないものを待ち続けたりします。

公式の反映には時間差がある

もう一つ紛れやすいのが、障害が起きている最中でもstatusがまだ更新されていないことです。掲載は人の確認を経るため、実際の発生より遅れます。

• 発生直後は「正常」のまま。数分から数十分の差が出ることがあります
• 復旧の表示が先に出ることもある。解決と書かれた直後は、残った影響で不安定なことがあります
• 掲載されない規模もある。一部の利用者だけに出る不具合は、履歴に残らないことがあります

したがって「statusが正常だから自分の設定が悪い」とは限りません。10分ほど間を置いて同じ操作をもう一度試すのが、いちばん安上がりな切り分けです。それで直るなら、手元は何も変えなくて済みます。

待っている間に記録しておくこと

障害だと分かったら手元は触らないのが原則ですが、何もしないのと、記録を取るのは違います。次の4つを控えておくと、復旧後に「本当に直ったのか」を自分で判定できます。

1. 最初に失敗した時刻。後で公式の履歴と突き合わせられます
2. エラー文をそのまま。要約すると、別の原因と区別できなくなります
3. 直前にやった操作。自分の変更が原因でないことの根拠になります
4. 失敗が毎回か、たまにか。毎回なら自分側、たまになら提供側の可能性が上がります

4番目は特に効きます。再現率は、障害と設定ミスを分ける手がかりです。設定が原因なら基本的に毎回失敗し、提供側の不調なら成功と失敗が混ざります。記録を取らずに設定を変えてしまうと、この判断材料そのものが消えます。

関連ページ

FAQ