Codex自動化の停止条件をどこに置くか¶
対象 / ポイント
対象: Codexに長時間作業やPR作成を任せたいが、暴走、品質ぶれ、レビュー負荷を避けたい実務者。
ポイント:
- 停止条件は「失敗したら止める」では遅い。作業前、差分作成後、PR前、CI後、人間判断前に分ける。
- Codex CloudとCodex Localは実行場所と権限統制が違うため、同じ停止条件で扱わない。
- PR本文とログに「なぜ止めたか」を残すと、翌日の自動化が同じ失敗を繰り返しにくい。
公開日: 2026-07-12
Codexに長時間の修正を任せると、失敗は最後に見つかるとは限らない。 むしろ危ないのは、途中で止める理由が明確なのに、そのままPRまで進む状態だ。 この記事の問いは1つだ。Codex自動化の停止条件は、どこに置けばレビュー負荷を増やさずに済むのか。
結論は単純だ。 停止条件は権限設定だけでなく、作業前、差分、PR、CI、レビューの5か所に置く。
OpenAIの説明では、Codexのローカルワークフローは利用者の端末上で動き、クラウドタスクはOpenAI管理環境で動く。ワークスペース管理者はCodex LocalとCodex Cloudを別々に統制できる。1
つまり「Codexを許可したか」だけでは、どこで止めるかを決めたことにならない。
止める場所を5つに分ける¶
停止条件は、Codexが失敗した後の非常ボタンではなく、作業を次段階へ進めるための関門だ。
たとえば記事生成やコード修正を自動化する場合、最初に止めるべきなのは「根拠がない候補」だ。 次に、差分が出た時点で「対象外ファイルを触った」「同じslugを再利用した」といった逸脱を止める。 PR作成前には、本文やテストが足りない状態を止める。
CI後には、失敗ログが読まれていないPRを止める。 最後に、人間レビューで「設計判断を自動承認しない」境界を残す。
運用上は、次の5層に分けると扱いやすい。
| 層 | 止める対象 | 例 |
|---|---|---|
| 作業前 | そもそも着手しない候補 | 重複、根拠不足、高リスク、権限不足 |
| 差分 | Codexが触った範囲 | 対象外ディレクトリ、意図しない削除、巨大差分 |
| PR前 | 人間に渡す最低条件 | 記事ペア欠落、テスト未実行、自己チェック失敗 |
| CI後 | 機械検証の結果 | required status checks失敗、ログ未確認 |
| レビュー前 | 自動化しない判断 | merge、公開、例外承認、仕様変更 |
朝の自動実行を例にすると、停止条件は次の順で効く。
- Topic planで既存記事と衝突したら、記事を書かずに候補を替える。
- 差分が
docs/blog/以外へ広がったら、PR前に作業範囲を確認する。 - CIが落ちたら、失敗ログを読んだ証跡が出るまで人間レビューへ回さない。
この順番なら、止まった場所そのものが次の改善対象になる。
GitHubのpull requestでは、差分、会話、commit、checksがPR上で確認できる。Checksタブにはpush時に走る自動テストやビルドの状態が表示される。2 この仕組みに停止条件を合わせると、Codexの出力を「あとで読む大量の差分」ではなく、「次へ進めるかを判断する証跡」に変えられる。
権限で止めるだけでは足りない¶
権限は必要だが、十分ではない。
Codex Cloudを使うか、Codex Localを使うかで、危険の形が変わる。 クラウドタスクはOpenAI管理環境で実行されるため、接続サービス、リポジトリ権限、ワークスペース権限が停止条件になる。 ローカルワークフローでは、端末上のファイル、ローカル認証、未コミット差分が停止条件になる。
同じ「CodexがPRを作る」でも、止める条件は違う。
- Cloud側: 接続リポジトリ、ブランチ、外部サービス、ワークスペース権限を確認する。
- Local側: cwd、git root、未コミット差分、ローカルsecret、生成物の保存先を確認する。
- 共通: merge、公開、credential要求、人間承認の代替を禁止する。
ここで大事なのは、権限を広く与えたうえで「あとでレビューする」形にしないことだ。 権限は入口を絞る。 停止条件は、入口を通った後の各段階を区切る。
CIは合否だけでなく停止理由に使う¶
CIは「赤なら直す」だけの仕組みではない。 Codex運用では、CIを停止理由の分類器として使う。
GitHubのstatus checksは、commitがリポジトリの条件を満たしているかを示す。3 branch protection ruleでは、レビュー承認やstatus checks通過などのワークフローを強制できる。4 この2つを使うと、CodexのPRを人間レビューへ渡す前に、最低限の機械的な停止条件を置ける。
ただし、CI失敗をそのまま人間に投げるとレビュー負荷は減らない。 Codex側のrunbookには、少なくとも次の分類を持たせる。
- 自己修復: formatter、リンク接尾辞、軽い構文崩れのように決定論的に直せる失敗。
- 要調査: テスト失敗、依存変更、仕様不一致のようにログ確認が必要な失敗。
- 停止: 認証、secret、外部権限、人間判断が必要な失敗。
- 修正PR: 同じ停止が繰り返され、仕組み側を直すべき失敗。
この分類がないと、Codexは毎朝同じところで止まる。 人間はアクティブなPRしか見ないため、skip artifactだけに理由を残しても改善されない。 構造的な詰まりは、記事PRではなく保守PRに変えるべきだ。
PR本文に残すべき証跡¶
PR本文は説明文ではなく、停止条件を通過した証跡である。
人間レビュアーが知りたいのは、Codexが何を頑張ったかではない。 どの候補を採用し、何を捨て、どの検証を通し、どこを手で見るべきかだ。 その情報がなければ、レビュアーは差分を最初から読み直すことになる。
PR本文には、最低限この5項目を置く。
| 項目 | 目的 |
|---|---|
| Lane / 対象読者 | 何の実験かを固定する |
| 採用候補と非採用理由 | 重複や根拠不足を再確認できる |
| 実行したチェック | 自己チェック、品質ゲート、CIの状態を示す |
| 残る手動確認点 | 人間が読むべき箇所を絞る |
| 停止時の次アクション | skip、修正、保守PRのどれかを示す |
停止条件を通ったPRは、レビュアーに「読む順番」を渡せる。 停止条件で落ちた作業は、翌日の自動化に「同じ失敗を避ける理由」を渡せる。 この2つを分けることが、長時間Codex運用の基本になる。
最後に残す境界線¶
Codex自動化の成熟度は、どれだけ自動で進めたかでは測れない。 どれだけ早く、説明可能に止まれるかで決まる。
最後に残す境界線は、人間のmerge判断だ。 Codexは候補を作り、検証し、停止理由をartifactに残せる。 しかし、どのPRを採用するか、どの例外を許すか、どの失敗を組織の方針変更にするかは、人間の判断として残す方がよい。
自動化は速さを増やす。 停止条件は、速さが品質保証を追い越す瞬間を止める。 Codexに任せる前に決めるべきなのは、作業範囲だけではない。 止まったときに次の判断を変える仕組みである。