Codexを長時間動かす前に作るべき安全設定¶

対象 / ポイント

対象: Codexに大きめの修正やPR準備を任せたいが、暴走や品質ぶれを避けたい実務者。

ポイント:

最初に狭めるのはモデルではなく作業範囲
sandboxとapprovalを別のつまみとして決める
AGENTS.mdと終了条件で、毎回の口約束を減らす

Codexを長く動かすときの不安は、モデルの賢さだけでは消えない。むしろ先に決めるべきなのは、どこを読ませ、どこを書かせ、どこで止めるかだ。

この記事の問いは、Codexに数十分以上の作業を渡す前に、どの境界線を作るかである。 Codex CLIは選んだディレクトリ内でコードを読み、編集し、コマンドを実行するローカルのエージェントとして説明されている¹。だからこそ、依頼文だけでなく作業場所、承認、レビューの条件をセットで設計する必要がある。

最初に狭めるのは作業範囲¶

長時間の実行で最初に決めるのは、どのモデルを使うかではなく、どのファイルを触ってよいかだ。対象が広いままだと、Codexは正しそうな近道を見つけても、その近道が運用上よいとは限らない。

まずは対象を1つのディレクトリ、1つのテーマ、1つの完了条件に絞る。たとえば記事作成なら、docs/blog/の日英ペアだけを対象にする。リポジトリ全体の整理、記事生成、設定ファイル更新、PR作成を同じ依頼に詰め込まない。

この線引きは、失敗時のレビューを軽くする。差分が対象範囲に閉じていれば、人間は「何を直したか」より先に「触ってよい場所だけか」を確認できる。長時間運用では、成果物の良さと同じくらい、差分の狭さが効く。

sandboxとapprovalを分けて決める¶

sandboxはCodexが触れる技術的な境界で、approvalはその境界を越えそうな操作を人に聞くかどうかの運用ルールだ²。この2つを混ぜると、「狭くしたつもりなのに外部操作が通る」か「毎回止まりすぎて運用できない」のどちらかに寄りやすい。

OpenAIの説明では、CLIやIDEの既定ではネットワークを使わず、書き込み先もワークスペース内に寄せる構成が示されている³。実務では、この既定を出発点にして、必要な操作だけを明示するほうが扱いやすい。

決める項目	初期値の考え方	レビューで見る点
作業場所	対象ディレクトリを1つに絞る	差分が範囲外に出ていないか
sandbox	ワークスペース内の編集を中心にする	外部ファイルやネットワークに寄っていないか
approval	外部操作や大きな削除で止める	承認なしに進めた操作がないか
終了条件	品質ゲート失敗ならPR前で止める	失敗を成功扱いにしていないか

重要なのは、強い権限を与える前に「止まる場所」を作ることだ。毎回の確認が面倒なら、承認をなくすのではなく、承認が必要な操作を減らす。

AGENTS.mdで口約束を減らす¶

長時間実行では、最初のプロンプトだけに頼らないほうがよい。作業が伸びるほど、最初の依頼から外れた判断が混ざりやすい。

Codexは作業前にAGENTS.mdを読み、リポジトリ内の場所に応じた指示を重ねて扱うと説明されている⁴。つまり、毎回のチャットで繰り返す注意事項は、リポジトリ側の恒久ルールに寄せられる。

AGENTS.mdには、次のような判断基準を置く。

触ってよいディレクトリ
実行してよいチェック
実行しない重いコマンド
日付、言語ペア、公開前確認のルール
git操作で必ず守るハーネス

この役割分担があると、プロンプトは短くできる。「このルールに従って、候補1件だけ実行」と書くだけで、背景の運用契約はAGENTS.mdに残る。

出口条件を先に書く¶

長時間実行の弱点は、途中の判断が積み重なったあとで止めにくくなることだ。だから、作業前に出口を先に書く。

出口条件は、完成形ではなく停止条件として書く。たとえば「テストが落ちたら修正を1回だけ試す」「根拠が取れない主張は保留に送る」「品質ゲートが落ちたらPRを作らない」といった形だ⁵。

OpenAIのCodex向けベストプラクティスでは、作業をレビュー可能な単位にし、テストやチェックを使って結果を確認する考え方が示されている⁵。これは長時間実行でも同じだ。最後に人間が見るのは、Codexが頑張った量ではなく、条件を満たした差分だけでよい。

実運用では、完了時に次の4点を残す。

何を対象にしたか
何を実行したか
何を実行しなかったか
次に人間が見るべき差分

この4点が残っていれば、長時間の作業でもレビューは短くなる。逆に、ここが残っていない実行は、成果物がよく見えても次回に複製しにくい。

まとめ¶

Codexを長く動かす前に作るべきものは、巨大なプロンプトではない。作業範囲、sandbox、approval、AGENTS.md、出口条件を組み合わせた小さな運用契約だ。

この契約があると、Codexは「何でもやる作業者」ではなく、狭い範囲でPR候補を整える実行者になる。そのほうが、レビューしやすく、失敗理由も残しやすい。

まず1件だけで試し、品質ゲートとレビューで回帰しないことを確認する。複製するのは記事本文ではなく、この運用契約と評価セットである。