Codex作業が止まったら、再実行より先に状態を分ける
Codex作業で止まる原因はひとつではありません。FTP待ち、404、sitemap旧版、スマホ崩れ、PR未mergeは、それぞれ復旧方法が違います。
Codex作業で止まった時は、すぐ再生成するのではなく、FTP待ちなのか、404なのか、sitemap旧版なのか、スマホ崩れなのか、PR待ちなのかを先に分けます。
公開URLが404なら本番採用は保留です。Secretsや設定系が絡む場合は停止して人間確認に戻します。
まず失敗ではなく状態として見る
停止状態を分類すると、再アップでよいのか、CSS最小修正でよいのか、PR待ちとして保留するのかが見えます。
- ローカル実装OK / 本番未アップ: 採用保留、FTP設定確認
- FTP環境変数未設定: 停止、秘密情報を本文に出さず設定を確認
- 公開URL404: 採用保留、パスとアップロード先を確認
- sitemap旧版: 公開側のsitemap中身を確認して再アップ
- 内部リンク404: 未作成URLやパスずれを確認
- スマホ表示崩れ: 再生成せずCSS最小修正を検討
- FAQ JSON-LD不整合: 構文確認と最小修正
- AdSenseコード消失: 停止してバックアップと差分確認
- Search Consoleタグ消失: 停止してバックアップと差分確認
- Secrets検出: 公開せず停止
- PR作成済み / 未merge: GitHub正本化は未完了
- GitHub merge済み / 本番未反映: deployまたはFTP反映待ち
FTP待ちは、ローカル実装OKでも本番採用ではない
FTP_HOST / FTP_USER / FTP_PASS、またはCORE_FTP_HOST / CORE_FTP_USER / CORE_FTP_PASSが未設定ならアップロードできません。FTP情報はチャット本文に貼らず、環境変数や安全な設定欄に入れます。
FTP待ちの状態では、ローカル実装が完了していても本番採用にはしません。再生成せず、同じステージからアップロードだけ再開できる場合があります。
公開URLが404なら、採用ではなく公開待ち
404の時は、URLの末尾スラッシュ、アップロード先ディレクトリ、index.htmlの配置、sitemapだけ先に入っていないか、内部リンクだけ先に入っていないか、FTPアップロードログ、公開URLの実ファイルを確認します。
パス違いなら再アップし、index配置違いなら配置を直します。公開URL200になるまで採用しません。
sitemapが旧版なら、公開側の中身まで見る
ローカルでは更新済みでも、公開側のsitemapが旧版のままのことがあります。sitemap.xml 200 OKだけでは不十分です。
sitemapは開けるかだけでなく、対象URLが掲載されているかまで見ます。重複がないか確認し、必要ならsitemapだけ再アップします。
スマホ崩れは、再生成ではなくCSS最小修正で直す場合がある
スマホ崩れは記事本文の失敗とは限りません。ステージHTMLまたはCSSの最小修正で直る場合があります。
- 390pxでH1が横に逃げる
- 横overflowが出る
- 長い英数字やURLが折り返されない
- FAQや表が横に広がる
- カード幅が固定されている
- 画像やiframeがはみ出す
PR作成とmerge完了は別の状態
branch push済み、PR作成済み、PR未merge、draft PR、merge済み、main同期済み、本番反映済みは分けます。
PRを作った段階と、mergeまで終わった段階は別です。GitHub merge済みでも本番反映済みとは限らず、本番反映済みでもGitHub未mergeならコード正本化は未完了です。
再生成は最後の手段にする
止まったからといって、記事をすぐ作り直すと、既存ステージ、sitemap、内部リンク、バックアップの状態が余計に混ざることがあります。
- FTP待ち
- 公開URL404だがステージは正常
- sitemap旧版
- 軽いCSS崩れ
- 内部リンクの軽微な追加漏れ
- PR待ち
- 報告書の不足
再生成を検討する場合
再生成は最後の手段です。次のように、本文や構造そのものが壊れている時だけ検討します。
- 本文の根本テーマが違う
- 禁止表現が大量にある
- 本文が重複している
- 薄いページになっている
- 構造そのものが崩れている
- Secretsが本文に混入している
- URL設計が大きく間違っている
Codexへ復旧を頼む時のテンプレート
復旧オーダーでは、まず再生成しないこと、最新ステージを確認すること、公開側の状態を見ることを明記します。
/GOAL Codex作業が途中で止まっています。 まず再生成せず、状態確認から始めてください。 確認してほしいこと： ・ローカル実装は完了しているか ・最新ステージはどれか ・本番アップは完了しているか ・公開URLは200 OKか404か ・sitemapは公開側に反映されているか ・sitemapに対象URLが掲載されているか ・内部リンク404はあるか ・スマホ390pxで崩れていないか ・AdSenseコードは維持されているか ・Search Consoleタグは維持されているか ・Secretsは混入していないか ・PRは作成済みか ・PRはmerge済みか ・停止条件は残っているか 復旧方針： ・FTP待ちなら環境変数確認で停止 ・404ならパスとアップロード先を確認 ・sitemap旧版ならsitemapだけ再アップを検討 ・スマホ崩れならCSS最小修正を検討 ・PR未mergeならGitHub正本化未完了として報告 ・Secretsがあれば公開せず停止 不明点があれば、実装せず停止して報告してください。
Codexトラブル復旧チェックリスト
aisafety.jpでは、復旧作業を感覚で進めず、公開URL、sitemap、内部リンク、スマホ、PR、Secretsを順番に確認します。
- 最新ステージが分かる
- 再生成が必要か判断した
- FTP環境変数の状態を確認した
- 公開URLが200 OK
- 404が残っていない
- sitemapに対象URLが掲載されている
- sitemap重複0
- 内部リンク404 0
- スマホ390pxで横はみ出しなし
- title / description / H1 OK
- canonical自己URL
- robots index,follow
- noindexなし
- FAQ JSON-LD OK
- AdSenseコード維持
- Search Consoleタグ維持
- Secrets 0
- mojibake 0
- 禁止表現 0
- PR状態を確認した
- merge状態を確認した
- Cグループを誤公開していない
- 停止条件が残っていない
安全側の切り口
FTP情報、APIキー、token、.env実値、GitHub token、SSH鍵、DB接続情報、会社情報、顧客情報、個人情報は記事やログに出しません。必要な場合は公開せず停止します。
関連ページ
確認した公式情報
このページは公式ページではありません。CodexやGitHubの仕様は変わる可能性があるため、最新の公式情報も確認してください。
FAQ
Codex作業が止まったら、すぐ再生成した方がいい？
いいえ。まずFTP待ち、404、sitemap旧版、スマホ崩れ、PR待ちなど状態を分けます。
ローカル実装OKなら本番採用でいい？
いいえ。公開URLが200 OKになるまでは本番採用ではありません。
FTP情報はチャットに貼っていい？
貼らない方が安全です。環境変数や安全な設定欄を使います。
sitemap.xmlが200 OKなら大丈夫？
開けるだけでは不十分です。対象URLが掲載されているか、重複がないかを確認します。
スマホでH1がはみ出したら記事を作り直す？
まずCSS最小修正で直せるか確認します。再生成は最後の手段です。
PRを作ったらGitHub正本化完了？
mergeされるまでは完了ではありません。draft PRも別件として扱います。
404のままSearch Consoleに出していい？
いいえ。公開URLが200 OKになってからが基本です。
復旧で一番大事なことは？
何が完了していて、何が未完了かを分けて報告することです。