Codex status

Codexが止まった時の報告書の書き方

Codexが止まった時の報告書は、何を確認し、どこで止めたかを残すための記録です。

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

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

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

不具合が起きた時の報告書は、原因の推測を書く場所ではなく、確認した事実を並べる場所です。推測から書き始めると、その推測に引きずられて確認漏れが起きます。

項目	書く内容	書かない方がよいこと
症状	画面に出た文言、いつから、どの操作で起きるか	「たぶんサーバーが重い」などの推測
確認したこと	公式statusを見た結果、doctorの結果、ログの最終更新時刻	確認していないのに「問題なし」と書く
直前に変えたこと	不具合の前に自分が行った変更（心当たりがなくても「なし」と明記）	関係ないと決めつけて省略する
まだ確認していないこと	時間や権限の都合で見ていない箇所	空欄のまま放置する

特に「直前に変えたこと」は、自分では関係ないと思っていても切り分けの決め手になることが多い項目です。心当たりがない場合も「直前の変更：なし」と書くことで、後から読んだ時に「確認済みでなし」なのか「書き忘れ」なのかが区別できます。

止まったときの記録は、後から自分が読み返して判断できることが目的です。感想ではなく、次の5つを事実として残してください。

最初に失敗した時刻	公式の障害情報と突き合わせるのに要ります
エラーの文言	そのまま写します。要約すると別の原因と区別できなくなります
直前にやったこと	自分の変更が原因でないことの根拠になります
毎回か、たまにか	再現率。設定の問題なら毎回、提供側の不調なら成功と失敗が混ざります
試したことと結果	効かなかったことも書きます。次に同じ手を試さずに済みます

4番目がいちばん効きます。再現率は、自分側の問題かどうかを分ける手がかりです。ここを記録せずに設定を変えてしまうと、判断材料そのものが消えます。

診断の出力やログには、公開できない情報が混ざります。報告書を人に見せる、あるいはどこかに貼る前に、次を外してください。

安全な形は、必要な部分だけを一般化して書くことです。「接続に失敗した」「認証が通らなかった」まで書けば、切り分けには足ります。出力を丸ごと貼るのは、楽ですが取り返しがつきません。

codex statusだけ見れば原因が分かりますか？

分かるとは限りません。サービス側の状態、自分の環境、network、auth、config、ログを分けて見ます。

doctor結果をそのまま貼ってよいですか？

そのまま公開しない方が安全です。認証情報、パス、ユーザー名、内部情報が混ざる可能性があるため、必要部分だけ一般化します。

止まったらすぐ設定を消してよいですか？

危険です。設定削除やリセットは停止条件として扱い、人間確認を挟みます。

/statusという検索は何を見たい人ですか？

Codexが動いているか、障害があるか、止まっている時にどこを見るかを知りたい検索として捉えます。