Codex CLIの /goal は、長い作業を「終わるまで進める」ために目標を固定する機能です。
単なる計画モードではありません。
達成すべき目標をスレッドに固定します。Codexは、その目標に向かって作業を続けます。
たとえば、こう使います。
/goal この記事を調査、下書き、アイキャッチ作成、公開確認まで完了するこれでCodexは「いま何を終わらせるべきか」を見失いにくくなります。
/goal は完了条件を固定する機能
/goal は、Codex CLI 0.128.0で追加された新機能です。
OpenAIのリリースでは、/goal workflowとして説明されています。
作成、一時停止、再開、解除に対応しています。
できることは、主に次の5つです。
/goal <目標>
/goal
/goal pause
/goal resume
/goal clear/goal <目標> で目標を設定します。 /goal だけ打つと、現在の目標や状態を確認できます。
pause は一時停止。 resume は再開。 clear は解除です。
小さい修正と長い作業の切り分けまで知りたいなら、Codexで記事更新できた喜びと、成功した理由 や Codexで記事更新を続けるなら、止まりやすい原因を先に潰したほうがいい もつながります。 /goal は「最後まで進める」側の道具で、止まりにくい運用とセットで効きます。
Codex goalで探している人はpauseとresumeまで覚える
codex goal で検索している人は、設定だけでなく止め方も知りたいはずです。
長い作業では、途中で予定が変わることがあります。
そのときは /goal pause で止め、続けるときに /goal resume を使います。
解除したいときは /goal clear です。
この3つを知っておくと、長い作業でも目標を抱えたまま暴走しにくくなります。
Plan modeとの違い
Plan modeは、作業前に方針を整理するためのものです。
/goal は、完了条件を持たせるためのものです。
違いはここです。
| 機能 | 役割 | 向いている作業 |
|---|---|---|
| Plan mode | 先に考える | 方針整理、設計、作業分解 |
| /goal | 終わりを固定する | 実装、検証、公開、長時間作業 |
今までは「まず計画を立てて、それから実行」が定石でした。
でも /goal が入ると、先に細かい計画を書かなくてもよい場面が増えます。
重要なのは、計画ではなくゴールです。
ブログ記事で使う例
ブログ運営なら、こう使えます。
/goal Codex CLIの /goal 機能について調査し、例つきで記事化し、アイキャッチを作り、公開URLを確認するこの書き方だと、Codexが見るべき完了条件ははっきりします。
- 最新情報を調べる
- 記事を書く
- アイキャッチを作る
- 公開する
- URLで表示確認する
「記事を書いて」だけだと、下書きで止まるかもしれません。
「公開URLを確認する」まで入れると、最後の確認まで作業に含まれます。
開発作業で使う例
コード修正なら、こうです。
/goal ログイン画面のエラー表示を修正し、関連テストを通し、差分を確認できる状態にするこの場合、Codexは実装だけで終わりません。
テストと差分確認までがゴールになります。
もっと本番寄りなら、こう書けます。
/goal トップページの表示崩れを原因調査から修正、本番反映、公開ページ確認まで完了するこの書き方は強いです。
「調べた」「直したつもり」で終わりにくくなります。
途中で止めたいとき
作業を止めるなら、こうです。
/goal pause再開するなら、こうです。
/goal resume別の目標に切り替えるなら、まず確認してから解除します。
/goal
/goal clear長い作業では、まず /goal だけ打って状態を見るのが安全です。
目標は短く、完了条件は具体的に書く
/goal は、長く書けばよいわけではありません。
よい目標は短いです。
でも、終わり方が具体的です。
よい例です。
/goal この記事を公開し、公開URLで本文とアイキャッチを確認する弱い例です。
/goal いい感じに記事を作る「いい感じ」は完了条件になりません。
Codexに任せるなら、最後に何を確認するかまで書くのがコツです。
/goal で変わる作業の感覚
/goal が入ると、Codexの使い方は少し変わります。
いままでは、作業を細かく切って人間が運転していました。
これからは、目標を渡して、途中の確認を見ながら進める使い方が増えそうです。
特に効くのは、次の作業です。
- 調査から公開まである記事作成
- 修正からテストまである開発作業
- 本番反映と表示確認が必要な作業
- 長くなりやすいリファクタリング
- PRレビュー対応
短い質問には不要です。
でも「最後までやって」がある作業には、かなり合います。
まず試すならこの一文
最初に試すなら、これで十分です。
/goal この依頼を、実装、確認、結果報告まで完了するブログなら、こうです。
/goal この記事を下書きから公開URL確認まで完了する開発なら、こうです。
FAQ
毎日3本ずつ記事を直す運用でも `/goal` を使ったほうがいいですか？
/goal この不具合を原因調査、修正、テスト確認まで完了する/goal は、Codexに「何を考えるか」ではなく「どこまで終わらせるか」を渡す機能です。
ここが、かなり大きいです。
公開確認やブラウザ操作まで含める仕事なら、Codexアプリでブラウザ操作を使うなら、内部ブラウザとChromeプラグインをどう選ぶか も合わせて見ると流れを組みやすいです。
どこまでを /goal に入れるかが見えやすくなります。
FAQ
`/goal` は毎回使ったほうがいいですか？
短い質問や1回で終わる確認なら不要です。調査、実装、確認が続く作業だけに使うほうが軽いです。
Plan mode と一緒に使っていいですか？
はい。最初に Plan mode で方針を整えて、そのあと /goal で完了条件を固定するとぶれにくいです。
`/goal` にブラウザ確認まで入れたほうがいいですか？
公開ページ確認や管理画面確認までが実作業に入るなら、入れたほうが止まりにくいです。逆に短い確認だけなら、そこまで広げなくても十分です。
`automations` と `/goal` はどう使い分けますか？
毎日やる型 は automations、今回の1本を終わらせる線 は /goal が近いです。繰り返し作業の入口を見るなら OpenAIのCodexが大型更新。Mac操作、画像生成、自動継続まで一気に広がった 、その作業をあとで整理するなら Codexの最近の作業を見直して、スキルとサブエージェントに分ける考え方 もつながります。
毎日3本ずつ記事を直す日に、`/goal` は3本まとめるべきですか？
まとめてよいですが、3本とも同じ軽さのときだけです。1本だけ重いなら分けたほうが止まりにくいです。残量確認は Codex Usage URLはどこ？使用量を見るページとBillingとの違い 、依頼文の切り方は Codexの消費量は短文で減る？ 迷わせない依頼文の作り方 もつながります。
