Codex /goalの使い方：有効化、コマンド、objective実例¶

対象 / ポイント

対象: Codex CLI の goals feature を有効化したが、/goal に何を渡せばよいか迷っている開発者。

ポイント:

/goal に渡すobjectiveは、願望ではなくAIに設計させた検証可能な作業指示書にする
受入基準、変更範囲、検証、証拠、Stop rule の5要素を入れると止まり方が改善する
抽象指示は便利に見えるが、audit が壊れるため長時間タスクほど危険になる

/goal を有効化した直後に一番困るのは、「結局、何を書けばいいのか」だ。 Make the codebase better. と打つと動き出しそうに見える。だが、Codex は何をもって「better」と判定すればよいのか分からない。

この記事では、/goal に貼る全文を objective と呼ぶ。問いは、その objective を人間が気合いで書くのではなく、AIに設計させ、人間が承認するにはどうするかである。仕組みの解剖は Codex /goal解剖で扱った。ここでは、日常開発でそのまま使える書き方に絞る。

objective はAIに設計させる¶

実際の運用では、objectiveを毎回手で綺麗に書くのは現実的ではない。「続けて」と打ち続けてきた人が、いきなり受入基準、変更範囲、検証、 Stop ruleを過不足なく書けるとは限らない。むしろ、/goal を使うなら、最初にAIへobjective設計を任せるべきだ。

OpenAI の /goal use case も、まず作りたいものを会話し、その後に Codexへgoal設定と作業開始を頼む流れを示している。³ つまり、公式の考え方でも /goal は「雑な依頼をそのまま貼る場所」ではない。実行前に、AIとの対話でobjectiveを契約書の形へ変換する。

同じCodexセッションで事前相談してもよいし、別のAIやSkillでobjectiveだけを作ってからTUIに貼ってもよい。重要なのは、実行する前に曖昧な依頼を「どこを触り、何を検証し、どこで止まるか」へ分解することだ。

公式の OpenAI Skills catalog には、現時点で /goal objective 専用のcurated skillは見当たらない。OpenAI の openai/skills はCodex向けSkillの公開カタログだが、一覧上はdeploy、Figma、Playwright、security、GitHub作業などが中心で、 goal / objective 専用のSkillは確認できなかった。⁵

一方で、第三者公開の goal-prompt-builder のようなSkillは出始めている。これはClaude Skillとして配布され、粗い依頼から /goal に貼れる形式のプロンプトを作ることを目的にしている。READMEでは、5区分テンプレート、プロジェクト種別の自動検出、AGENTS.md / CLAUDE.md の読み取り、 auditしやすさの採点を行うと説明されている。⁶

ベストプラクティスは、次の3段階である。

AIまたはObjective生成用Skillに「やりたいこと」を雑に渡す
AIに /goal 用のobjective、Scope、Verification、Stop ruleへ分解させる
人間が危険な範囲だけ確認し、Codex CLI のTUIに貼り付けて実行する

この流れなら、objective設計の面倒さをかなり減らせる。注意点は、AIや第三者Skillの出力をそのまま信じないことだ。最後に責任を持つのは、/goal を実行する人間である。

/plan と /goal は役割が違う¶

ここで自然に出る疑問は、「それなら /plan と同じではないか」だ。結論から言えば、/plan は実行前の設計モードで、/goal は設計済みobjectiveを持って実行を続けるライフサイクルである。

/plan は、何をするかを整理するために使う。受入基準、変更範囲、検証コマンド、リスクを洗い出すには向いている。だが、/plan 自体は「このobjectiveが完了するまで複数ターン継続し、証拠を監査し、budget到達時に状態をまとめる」機能ではない。

/goal は、そこが違う。objectiveをthreadに保持し、次のターンでも同じ完了条件に戻って作業を続ける。完了前には要件を証拠に対応させ、足りない要件があれば未達として扱う。つまり、/plan が作るのは計画で、/goal が担うのはその計画を使った継続実行と停止判断である。

実務では、競合させるより組み合わせるほうがよい。まず /plan や通常チャットで objective案を作る。次に、その案を /goal に貼れる契約へ整える。最後に /goal <objective> で実行する。この順番なら、/plan は設計、 /goal は継続実行と完了監査、という分担になる。

コマンド	主な役割	出力	向いている場面
`/plan`	実行前の整理	手順、論点、リスク、受入基準	まだ何をするか固まっていない時
`/goal`	長時間実行の保持	進捗、検証結果、完了または停止状態	何を達成すべきか固まった後

goal に工程全体を含めてよいか¶

では、/goal のobjectiveに「計画して、レビューして、実装して、検証して、必要なら繰り返す」と書いてよいのか。これは、書いてよい。ただし、スラッシュコマンドをそのまま内部で実行させる、という意味ではない。

公式の slash commands docs では、/plan はユーザーが入力してplan modeへ切り替えるコマンドであり、作業中は一時的に使えないと説明されている。⁷ /goal も同じく TUIでユーザーが設定、確認、pause、resume、clearするコマンドである。⁷ つまり、/goal の中に「/plan を実行せよ」と書くより、「最初に実装計画を作り、チェックポイントごとにレビューし、検証が通らなければ修正する」と工程を自然文で指定するほうが堅い。

公式の /goal use case も、checkpointで進め、progress logを残し、検証コマンドや成果物で進捗を証明するよう勧めている。³ ここから見ると、現時点の実用形は「slash commandをネストするgoal」ではなく、「plan、review、implementation、 verificationを工程として含むgoal」である。

たとえば、次のように書く。

/goal Checkout APIの認可バグを、計画、実装、検証、レビューまで完了する。

Behavior:
期限切れカードと認可失敗の注文が成功扱いにならない。

Checkpoints:
1. まず関連ファイルと既存テストを読み、実装計画を短く作る。
2. 計画に対して、認可、既存API互換性、テスト不足の観点で自己レビューする。
3. 計画が妥当なら、payment validationと関連テストだけを変更する。
4. npm test -- checkout を実行し、失敗したら原因を特定して修正する。
5. 完了前に、変更ファイル、テスト結果、未検証リスクを監査する。

Stop rules:
gateway仕様が未文書、認可責務が不明、本番credentialが必要なら止める。

このobjectiveは /plan を内側で呼んでいるわけではない。だが、計画、レビュー、実装、検証、完了監査を /goal の長時間ループに含めている。この形なら、 /goal は /plan の代替ではなく、planを含む実行契約になる。

objective生成プロンプト¶

AIに頼む時は、単に「いい感じの /goal を作って」と言わない。粗い依頼を渡したうえで、出力形式を固定する。

次の依頼を、Codex CLI の /goal に貼れるobjectiveへ変換してください。
/goal は experimental な長時間実行機能で、検証可能な停止条件が必要です。

依頼:
[ここに雑な依頼を書く]

出力は次の形にしてください。

/goal [1文のObjective]

Behavior:
Scope:
Non-goals:
Canonical sources:
Checkpoints:
Verification:
Review:
Commit / push: （コード変更まで任せる場合）
Evidence to report:
Stop rules:

条件:
- 曖昧な表現を、ファイル、振る舞い、コマンド、証拠へ置き換える
- 不明点は推測せず Stop rules に入れる
- 本番操作、credential、danger-full-access が必要なら明示的に止める
- まず小さく完了できる範囲へ切る

このプロンプトの価値は、雑な依頼を「一気通貫で進める契約」に変換する点にある。 /goal は長く動けるぶん、入口のobjectiveが曖昧だと長く迷う。人間の役割は、最初から完璧なobjectiveを書くことではなく、 AIが作ったobjectiveの境界、検証、Stop ruleを承認することだ。

最小形は5行objective¶

毎回フルテンプレートを書く必要はない。小さなタスクなら、次の5要素だけでもかなり安定する。/goal のobjectiveは、短い仕様書として書くとよい。

objectiveは日本語で書いてよい。ただし、ファイルパス、コマンド、Issue番号、API名のような照合対象は、実際の表記のまま書く。自然文は日本語、検証対象は正確なリテラル、という分け方が読みやすい。

/goal Orders管理画面にCSVエクスポートを追加する。
振る舞い: 管理者が既存のOrders画面から、絞り込み済み注文をCSVでダウンロードできる。
変更範囲: src/admin/orders/*、src/api/orders/*、関連テストだけを変更する。
検証: npm test -- orders と npm run typecheck を実行する。
報告する証拠: 変更ファイル、実行したテスト、CSVヘッダー例を報告する。
Stop rule: 認可要件、CSV列定義、既存APIの責務が不明なら作業を止める。

この形なら、Codex は「何を作るか」「どこを触るか」「何を実行すれば完了か」を持てる。「報告する証拠」は人間のレビュー時間を減らすための指定だ。Stop rule は、止まってよい条件を先に許可するために入れる。

/goal は自律性を増やす機能だが、放任する機能ではない。人間が最初に境界線を承認するほど、Codex は途中で迷いにくくなる。

抽象指示はどう壊れるか¶

抽象指示の問題は、Codex が動かないことではない。むしろ動いてしまう。continuation.md は proxy signals だけで完了判定しないよう求めるため、曖昧なobjectiveほど「まだ何かできる」と判断しやすい。²

悪いobjective	起きやすいこと	書き換え例
`Make the codebase better.`	改善範囲が無限になり、audit が閉じない	`Fix the top 3 ESLint errors in src/payments and run npm run lint -- src/payments.`
`Refactor the API layer.`	振る舞い維持の証拠が不足する	`Split src/api/orders.ts into route, validation, service files without changing responses. Run existing API tests.`
`Improve UX.`	何を見れば改善か分からない	`Reduce checkout form error recovery from 3 visible errors to inline field messages for email and card fields.`
`Make tests better.`	テスト追加が目的化する	`Add regression tests for issue #123 so the failing case passes before implementation and remains green after fix.`

抽象指示は、探索や相談には向いている。だが /goal は相談モードではない。完了判定まで自動化するなら、抽象語を検証可能な名詞とコマンドに置き換える必要がある。

「よくして」ではなく「どのファイルで、どの振る舞いを、どのコマンドで確認するか」を渡す。これだけで /goal の失敗率は大きく下がる。

動かない時だけ確認すること¶

/goal が使えない時は、まず入力場所を疑う。/goal は通常の shell サブコマンドではなく、Codex CLI の対話TUI内で使うスラッシュコマンドだ。 Codex CLI 0.128.0 の release note は /goal workflow、継続処理、 TUI controls の追加を明記している。¹

ただし、/goal は公式ドキュメント上でも experimental 扱いであり、手元のビルドや設定によって goals feature flag が有効かどうかは変わる。バージョンとfeature flagの両方を確認してからTUIを開く。

codex update
codex features list | grep goals
codex features enable goals
codex features list | grep goals
codex

codex features enable goals は config.toml に feature flag を書く操作である。もう一度 codex features list | grep goals を実行し、goals ... true になっているか確認する。起動後はTUIの入力欄で /goal ... を使う。

codex exec "/goal ..." のような非対話実行では、TUIのスラッシュコマンドとして動かない可能性がある。使えない時は、バージョン、feature flag、TUI内での候補表示を確認する。

内部テンプレートは作らない¶

continuation.md と budget_limit.md は、ユーザーがプロジェクトに置く設定ファイルではない。 OpenAI の Codex リポジトリに同梱されている /goal 用の内部プロンプトテンプレートである。²⁴ 普段の利用で、これらを作成、編集、コピーする必要はない。

ユーザーはTUIで /goal <objective> を入力する。Codex側は、そのobjective、使用時間、 token budget、残りtokenを状態として保持する。次のターンへ進む時に、 continuation.md の内容を「続きの作業指示」としてエージェント側へ差し込む。

予算に到達した時は budget_limit.md 側の指示で、新しい作業を始めずに進捗と残作業をまとめる。内部テンプレートを知る目的は、それを編集することではない。 objectiveに、監査できる要件と止まる条件を入れるためである。

向いているタスク、向かないタスク¶

検証コマンドがある仕事ほど、/goal に向いている。途中で何度も検査しながら進められるからだ。OpenAI の /goal use case でも、明確な成功条件と検証ループを持つ長時間のcoding work、code migrations、large refactors、 deployment retry loops、experiments、games、side projects が向く用途として挙げられている。³ /goal はこの往復にobjective保持と予算終了を足す。

タスク	相性	理由
既知の移行作業	高	対象範囲、成功条件、検証コマンドを定義しやすい
失敗テストの修復	高	赤から緑への証拠が明確
機能追加	中	仕様、権限、UI確認方法が書ければ強い
調査レポート	中	evidence と出典を指定すれば使える
設計方針の相談	低	完了条件より意思決定が中心になる
大雑把な品質改善	低	改善の上限がなく、budget を消費しやすい

迷ったら、/goal の前に /plan を使う。計画段階で受入基準が出ないなら、その仕事はまだ /goal に渡す形になっていない。/plan で出た受入基準、検証コマンド、Stop rule を /goal objective に写してから始めるほうが堅い。

止まった時は失敗ではなく状態を見る¶

/goal が途中で止まる時、まず見るべきなのは「なぜ止まったか」だ。ここでは止まり方を4分類で読む。budget_limit.md は token budget 到達時に、新しい実作業を始めず、進捗、残作業、ブロッカー、次の手順をまとめるよう指示する。⁴ これは失敗ログではなく、次の判断材料である。

終わり方	読み方	次の一手
`achieved`	audit が通り、完了処理まで到達	証拠だけ確認してレビューへ進む
`budget_limited` / `budget-limited`	予算内では終わらなかった	残作業を絞り、追加budgetで再goal化する
`unmet`	ブロッカーや不確実性が残った	足りない情報、権限、依存関係を人間が補う
`paused`	人間判断や割り込みで止めた	objective を修正して resume する

内部テンプレートでは budget_limited と表記される。この記事では読みやすさのために budget-limited とも書いている。大事なのは、これを「Codexがダメだった」と読まないことだ。残タスクが明確なら、むしろ健全に止まっている。危険なのは、何を完了したかも何が残ったかも分からない終了である。

そのまま使えるサンプル¶

最初は、小さく閉じたobjectiveから始める。1回目からリポジトリ全体の改善を任せるより、30分から2時間でレビューできる単位に切るほうが、/goal の癖をつかみやすい。

最初に試すなら、ドキュメント更新かテスト追加がよい。変更範囲が狭く、検証コマンドも書きやすい。機能追加や移行作業は、止まり方を理解してから任せるほうが安全だ。

用途	objective例
バグ修正	`/goal issue #123 の「期限切れカードをcheckoutが受け付ける」不具合を修正する。変更範囲はpayment validationとテストのみ。npm test -- checkoutで検証し、変更ファイルと失敗前/成功後の証拠を報告する。gatewayの仕様が未文書なら止める。`
テスト追加	`/goal CSVエクスポートでカンマ、ダブルクォート、改行を正しくescapeする回帰テストを追加する。実バグが見つからない限りproduction codeは変更しない。npm test -- csvで検証し、追加したケースを報告する。`
小規模移行	`/goal app/schemas/user*.py の非推奨Pydantic v1 validatorをv2 field_validatorへ置換する。API挙動は変えない。pytest tests/schemas と mypy app/schemas を実行する。実行環境がPydantic v2でない場合は止める。`
ドキュメント更新	`/goal Codex setup docsに、goals feature flagとTUI内スラッシュコマンドである点を追記する。変更範囲はdocs/generative-ai/chatgptのみ。Markdownリンクチェックを実行し、変更したリンクと実行コマンドを報告する。`

この粒度なら、Codex が止まった時にも人間が差分を読める。逆に、この表のobjectiveをさらに抽象化して短くすると、レビュー不能な自律作業に近づく。

まとめ¶

チーム運用では、/goal を誰でも何にでも使える長時間実行ボタンにしないほうがよい。最初に許可するのは、検証コマンドが存在し、変更範囲を限定でき、credentialや本番操作を必要としないタスクだ。

推奨する運用ルールは3つである。

すべての /goal objective に Scope、Verification、Stop rule を必須にする
danger-full-access や本番操作を含むgoalは、別の承認フローに分ける
budget-limited の出力を次のgoalに貼る前に、人間が範囲を削る

/goal のメリットは、人間の「続けて」を減らすことだ。デメリットは、曖昧な依頼を長く実行してしまうことでもある。だから活用の鍵は、Codexを強く信じることではない。 AIにobjectiveを設計させ、人間が境界とStop ruleを承認することにある。