Before ordering Codex

Codex作業の停止条件とは？

停止条件は、作業を失敗させないためのブレーキです。Codexに進めてもらう前に、どの状態になったら止めて報告するかを書いておきます。

このページは非公式の実務ガイドです。重要な判断は人間が行い、最新情報やサービス仕様は提供元の情報も確認してください。

decision.md

before_order:
  scope: small
  allowed: clear
  forbidden: clear
  stop_conditions: required
verify:
  human_review: true

このページで分かること

Codex作業の停止条件を整理します。500、大量404、SEOタグ変更、DB変更、cron変更、認証情報が必要な時は、人間確認へ戻します。

停止条件は「AIを信用しない」ためのものではなく、「想定外の状況で作業を続けさせない」ための安全装置です。車のブレーキと同じで、使う予定がなくても付いていないと走り出せません。良い停止条件は、次の5点を満たします。

基準	停止条件の書き方の例	これがないと
壊れた時に止める条件	「エラーが出たら修復を試みず、状態を報告して停止」	AIが善意の修復を重ねて、被害範囲を広げる
人間確認へ戻す条件	「判断が分かれる場面では選択肢を提示して停止」	AIが推測で決めて、意図と違う方向に進む
重要ファイル変更の扱い	「SEOタグ・ads.txt・設定ファイルの変更が必要になったら停止」	本文修正のつもりが重要設定に波及する
公開前後の確認	「反映前に変更一覧を提示、反映後に公開URL確認を報告」	未確認のまま本番が書き換わっていく
停止理由を報告書に書く	「停止した場合は、条件のどれに該当したかを明記」	止まった理由が分からず、同じ停止を繰り返す

停止条件が発動するのは悪いことではありません。むしろ「発動した＝安全装置が機能した」ということです。発動が多い場合は、AIの問題ではなく依頼の範囲設定を見直すサインとして扱ってください。

今回のCodex作業の停止条件を作ってください。HTTP 500、大量404、SEOタグ変更、DB変更、cron変更、認証情報、重要設定、スマホ崩れ、想定外ファイル変更に分けてください。

停止条件が発動した後、「もう一度最初から頼み直す」のはもったいない進め方です。停止時点までの確認結果は活きているので、再開は次の3パターンから選びます。

どのパターンでも共通するのは、停止理由に対して人間が判断を返してから再開することです。理由への回答なしに「続けて」とだけ言うと、同じ場所でまた止まるか、より悪い場合は止まらずに進んでしまいます。