Codex に大きめの実装、移行、調査、UI改善を任せるとき、困るのは「最初の指示文」だけではありません。数時間かかる作業で、どこまで自走してよく、どの時点で止まり、何を検証したら完了なのかが曖昧だと、途中経過は進んでいるように見えても、最後にレビュー不能な差分が残ります。
この記事では、2026年8月1日時点の OpenAI 公式ドキュメントを前提に、Codex Goal mode を長時間タスクの運用単位としてどう設計するかを整理します。定期実行の設計は Codex Automations 実践ガイド、成果物を受け入れる前の確認は Codex レビュー完了ゲート設計ガイド、run 単位のコスト上限は AIエージェント予算ガードレール設計ガイド、独自クライアントや長時間 session の扱いは Codex App Server ガイド に分けています。
今回扱うのは、/goal に渡す objective、停止条件、検証ループ、checkpoint、pause / resume の設計です。
先に結論: Goal mode は「長い作業」ではなく「検証できる目標」に使う
OpenAI の Goal mode docs では、/goal は Codex が複数ターンにわたって、検証可能な停止条件へ向けて作業を続けるための機能として説明されています。つまり、単に「時間がかかるから goal にする」のでは弱いです。
私なら、Goal mode を使う条件を次の3つに絞ります。
- 完了状態を1文で言える
- 進捗を確認するコマンドや成果物がある
- Codex が次の一手を自分で選んでもよい範囲がある
逆に、次のような依頼は Goal mode に向きません。
- 未整理の backlog をまとめて片付ける
- 仕様判断が毎回変わる
- 本番操作や外部送信の承認が頻繁に必要
- 成功条件が「いい感じ」だけ
- 複数 repo や複数 PR に同時に触る
Goal mode は、長時間働かせるスイッチではありません。Codex が自分で進捗を判定できる work contractです。
Automations / Routines / review gate と何が違うか
Codex クラスターでは、似た言葉が増えています。ここを混ぜると、記事も運用もぼやけます。
| 近いテーマ | 扱うこと | Goal mode で扱うこと |
|---|---|---|
| Codex Automations | 定期実行、inbox、worktree分離 | 1つの durable objective を完了まで追う |
| Claude Code Routines | cloud 側の unattended run | Codex app / CLI / IDE での goal 管理 |
| Codex review gate | 完了後に受け入れるか | 完了前に done 条件を固定する |
| AIエージェント run control | pause / resume / cancel の状態設計 | /goal の状態操作を実務手順に落とす |
| 予算ガードレール | token / tool / 外部API の上限 | goal ごとの時間・試行回数・検証回数を決める |
Goal mode の主語は「いつ走るか」ではありません。何を達成したら止まるかです。
たとえば毎朝 SEO レポートを出すなら automation です。1本の記事を、調査、執筆、内部リンク、build、PR まで完了させるなら Goal mode の方が自然です。どちらも長く動きますが、運用単位が違います。
依頼文は objective / constraints / verification に分ける
OpenAI の long-running work docs では、Goal mode の text が最初の prompt と completion criteria の両方になると説明されています。だから、/goal ブログを書いて では足りません。
私なら、最小形はこうします。
/goal Complete the Codex Goal mode guide.
Objective:
- Add one article about Codex Goal mode.
- Keep the topic limited to stopping conditions, verification loop, checkpoints, and pause/resume.
Context:
- Read data/seo/keyword-plan.md.
- Read the blog SEO overhaul plan.
- Check existing Codex Automations, review gate, App Server, and budget guardrail articles.
Constraints:
- Do not write a generic Codex introduction.
- Do not duplicate Automations or browser-use articles.
- Keep unrelated root changes untouched.
Verification:
- Run pnpm seo:update-llms.
- Run pnpm run build.
- Open a PR with only article, SEO plan, learnings, and llms changes.日本語で依頼するなら、構造だけ残せば十分です。
/goal Codex Goal mode の記事を1本公開可能なPRにする。
目的:
- /goal の使い方ではなく、長時間タスクの停止条件と検証ループを解説する
- Automations / review gate / App Server との違いを明示する
制約:
- 既存記事と検索意図を重ねない
- root の未追跡ファイルに触らない
- build 成功だけで完了扱いにしない
完了条件:
- 記事、keyword-plan、learnings、llms が更新されている
- pnpm seo:update-llms と pnpm run build が通っている
- PR が作成されている重要なのは、作業内容より先に done 条件 を書くことです。Goal mode はそこへ向かって動くので、done 条件が曖昧だと途中で広がります。
停止条件は「成功」「中断」「人間確認」に分ける
長時間タスクでは、成功条件だけでは足りません。途中で止まる条件も必要です。
私なら、停止条件を3種類に分けます。
| 種類 | 例 | Codex にしてほしいこと |
|---|---|---|
| success stop | build と主要テストが通り、diff が scope 内 | 最終報告と PR 化 |
| blocked stop | 仕様不明、権限不足、外部サービス未接続 | 何が足りないかだけ返す |
| safety stop | 本番操作、課金、削除、秘密情報、scope 逸脱 | 進めず人間承認へ戻す |
たとえば、次のように書いておくと運用しやすいです。
Stop and ask before:
- changing production configuration
- deleting user data
- widening sandbox or network permissions
- touching files outside the planned diff
- continuing after the same blocker appears twiceGoal mode は同じ目標を追い続けられるので、停止条件が弱いと「もう少し試す」が積み上がります。特に外部 write、権限拡張、依存追加、認証付きブラウザ操作は、goal の中でも別承認に分けるべきです。
検証ループは1回で終わらせない
Goal mode が向いている仕事は、多くの場合、一度の build では終わりません。OpenAI の docs でも、code migration、large refactor、experiment のように validation loop がある作業が例に挙げられています。
私なら、Codex に次の loop を持たせます。
Loop:
1. Inspect current state.
2. Make one focused change.
3. Run the smallest relevant check.
4. Record what changed and what failed.
5. Continue only if the next step is still inside the goal.大事なのは「毎回全部の build を回す」ことではありません。最初は小さい check で方向を見て、節目で full build を回します。
例:
| 作業 | 小さい検証 | 最終検証 |
|---|---|---|
| 記事追加 | frontmatter確認、内部リンク確認 | pnpm seo:update-llms、pnpm run build |
| UI修正 | 対象 route のスクリーンショット | build、Playwright確認 |
| 移行作業 | 1 module の test | 全 test、型check |
| 調査レポート | source list と論点確認 | report と根拠リンクの整合 |
長時間タスクで危ないのは、最後にだけ検証することです。失敗の原因が10個前の変更にあると、差分が救いにくくなります。
checkpoint log を残させる
Goal mode の信頼性は、途中で何を見たかにかなり依存します。チャットの流れだけに頼ると、長時間 run では見落としが増えます。
私なら、次のような progress log を要求します。
Keep a short progress log:
- current checkpoint
- files changed
- checks run
- latest failure
- next checkpoint
- stop condition statusこれは長い議事録ではありません。人間が status を聞いたときに、次をすぐ判断できる粒度で十分です。
- どこまで終わったか
- 何が検証済みか
- 何が未検証か
- 今止めると何が残るか
- 次に触るファイルはどれか
Codex が曖昧な status を返すなら、goal 自体が大きすぎる可能性があります。その場合は、goal を「移行全体」から「1 module の移行」へ縮めた方がよいです。
pause / resume は人間側の運用として使う
OpenAI の docs では、/goal pause、/goal resume、/goal clear のような制御が示されています。これは便利ですが、実務では「一時停止ボタン」以上の意味があります。
私なら次のように使います。
| 操作 | 使う場面 | 再開前に見ること |
|---|---|---|
| pause | 承認判断、外部確認、長時間離席 | 最新 checkpoint、未検証項目 |
| resume | 条件が満たされた | 前提が古くなっていないか |
| clear | 方針変更、scope変更、別タスク化 | 新しい goal を作り直す |
特に resume は雑にしない方がよいです。長時間止まった task は、branch、依存、外部サービス、PR コメントが変わっている可能性があります。再開前に git status、最新コメント、失敗ログ、承認対象を見直すべきです。
parallel goals は worktree で分ける
OpenAI の long-running work docs では、並列に動かす場合は同じファイルを触らせないこと、local work では worktree を使うことが示されています。ここはかなり重要です。
私なら、parallel goal のルールをこうします。
Parallel goal rules:
- one branch per goal
- one worktree per branch
- no shared SEO files unless one goal owns them
- no two goals modify the same route or article cluster
- merge order is decided before starting the second goalこのサイトのブログ運用でも、記事本文だけなら衝突しにくいですが、data/seo/keyword-plan.md、data/seo/learnings.md、public/llms.txt、public/llms-full.txt は衝突しやすいです。Goal mode を複数走らせるなら、shared SEO files をどちらが持つかを先に決めるべきです。
実務テンプレ: Goal mode に渡すチェックリスト
最後に、私が実務で使うならこのテンプレートにします。
/goal [one durable objective]
Context to read first:
- [files]
- [docs]
- [tickets]
Scope:
- allowed files:
- forbidden files:
- expected output:
Definition of done:
- behavior:
- tests/checks:
- review artifact:
Loop:
- checkpoint size:
- command after each checkpoint:
- full verification command:
Stop and ask if:
- missing requirement:
- permission expansion:
- production or external write:
- repeated blocker:
Progress log:
- current checkpoint
- verified
- remaining
- blocked_by
- next actionこのテンプレートを毎回すべて埋める必要はありません。ただし、Definition of done と Stop and ask if だけは省かない方がよいです。
よくある失敗
1. 「できるところまで」で始める
Goal mode に「できるところまで」と渡すと、止まる基準がありません。時間が切れるか、Codex が自信を失うまで続きます。長時間タスクほど、最初に完了条件を狭めるべきです。
2. build 成功だけを完了条件にする
build 成功は必要ですが、十分ではありません。記事なら重複意図、内部リンク、frontmatter、llms 更新まで見ます。実装なら仕様、テスト、レビュー容易性、rollback 条件まで見ます。詳しくは Codex レビュー完了ゲート設計ガイド に分けています。
3. automation と混ぜる
毎週走らせたいなら automation です。1つの大きな作業を最後まで進めたいなら Goal mode です。繰り返しと完了追跡を混ぜると、inbox に戻すべき仕事と、同じ chat で深掘りすべき仕事が混ざります。
4. shared files を複数 goal に触らせる
SEO ファイル、package lock、schema、route index のような shared files は衝突しやすいです。複数 goal を並列に走らせるなら、最初から worktree と ownership を分けます。
5. 途中 status を成果物扱いする
progress log は便利ですが、成果物ではありません。最後は diff、テスト、生成物、PR、外部資料との整合を見ます。Goal mode の status がきれいでも、review gate は別です。
まとめ
Codex Goal mode は、長時間タスクを雑に丸投げする機能ではありません。/goal に objective、constraints、verification、stop condition をまとめ、Codex が同じ目標へ向けて検証しながら進むための運用単位です。
使いどころは、code migration、large refactor、UI改善、記事作成、調査からPRまでのように、完了条件は明確だが1ターンでは終わらない仕事です。
私なら、Goal mode を使う前に次の3つだけ確認します。
- 完了条件を人間と Codex が同じ意味で読めるか
- 途中で回す検証コマンドや成果物があるか
- 止まるべき条件を明文化しているか
ここが揃っていれば、Goal mode はかなり強いです。逆にここが曖昧なら、まず /plan や小さな通常タスクで scope を固めてから goal にした方が、結果として早く終わります。