Codex Appでゴールを設定して完成まで持っていく方法

Codex Appでやりたいのは、細かい指示を何度も投げることではありません。
最初に「完成できること」を置いて、そこまで一緒に進むことです。

たとえば、この記事ならこうです。

/goal この記事が完成できること

この一文だけでも、向きは決まります。
ただ、最後まで持っていくなら条件も足したほうがいいです。

きっかけは、Riley BrownさんのX投稿です。
「when /goal in codex app?」という短い投稿でした。

この投稿を見て、ぼくがCodex Appでやりたいことがはっきりしました。

Codex Appでも、作業の最初に「今回の完成形」を置きたい。
途中で迷ったら、そのゴールに戻る。
最後は、完了条件と検証結果で終わらせる。

これができると、Codexは相談相手というより、完成まで一緒に進む相手になります。

Codex Appでは最初の一文をゴールにする

Codex Appで新しい作業を始めるとき、最初にこう書きます。

/goal この記事が完成できること

この記事の完成条件:
- Codex Appでゴールを設定する方法がわかる
- 読者がそのまま真似できる入力例がある
- /goal のCLI機能紹介だけで終わらない
- Codex Appから完成を目指す流れが中心になっている
- 参照元リンクがある
- アイキャッチ画像プロンプトがある
- 公開前にdry-runで確認できている

もう少し実務寄りに書くなら、こうです。

このスレッドのゴール:
posts/codex-goal-implementation-method.md を、Codex Appでゴールを設定して完成まで進める方法の記事として完成させる。

完了条件:
- 読者がCodex Appで真似できる手順になっている
- /goal の話はCLI機能の紹介に寄せすぎない
- Codex Appでの進め方を中心にする
- 参照元リンクを入れる
- アイキャッチ画像プロンプトを入れる
- 公開はしない
- dry-runで変換確認する

ここで大事なのは、いきなり「記事を書いて」と頼まないことです。
先に完成形を固定します。

Codex Appでは、途中で追加指示を出せます。
でも、最初のゴールが弱いと、話が広がります。
だから最初に「どこまで行けば完成か」を置きます。

Codex Appでの進め方

順番	やること	Codexに渡す内容
1	ゴールを書く	何を完成させたいか
2	完了条件を書く	何ができたら終わりか
3	触る範囲を書く	編集してよいファイル
4	確認方法を書く	テスト、dry-run、ブラウザ確認
5	最後に報告させる	変更点、確認結果、未完了

この順番にすると、Codex Appでの会話がぶれにくくなります。

特に大事なのは、確認方法です。
「完成したと思う」では弱いです。
「このコマンドが通った」「このURLで見た」「このファイルを変えた」まで残します。

/goal はCLIで確認できる機能

GitHubのCodex 0.128.0リリースでは、/goal は「残るワークフロー」「自動継続」「作成・停止・再開・削除の操作」を持つ機能として説明されています。

これはCLIの話です。
この記事では、Codex Appで /goal が正式コマンドとして使える、とは書きません。
確認できる事実は、Codex CLI 0.128.0に /goal ワークフローが入ったことです。

ただ、考え方はCodex Appでも使えます。

つまり、こうです。

目的を先に置く
完了条件を明確にする
途中で止まっても目的に戻る
最後は検証で終える

Riley Brownさんの投稿が面白いのは、ここです。
CLIに /goal があるなら、Codex Appでも同じようにゴールから始めたくなる。
ぼくが目指したいのもそこです。

まずCodexを0.128.0以上にする

CLIの /goal も試すなら、Codexを0.128.0以上にします。

npm install -g @openai/codex
codex --version

2026年5月6日に確認した npm の latest は @openai/codex 0.128.0 でした。
GitHub releaseでも rust-v0.128.0 が2026年4月30日に公開されています。

手元のCodexが古いままだと、CLIで /goal を打っても使えない可能性があります。

Codex Appに渡す実装依頼の形

Codex Appで使うなら、こういう形が使いやすいです。

弱い例です。

この画面を改善して

これだと、何をもって終わりなのかが曖昧です。
AIは動けます。
でも、完了判断が弱くなります。

実装向きにすると、こうです。

/goal この実装が完成できること

具体的なゴール:
管理画面の売上ダッシュボードにCSV出力を追加する。

完了条件:
- 売上一覧の右上にCSV出力ボタンがある
- 現在の絞り込み条件を反映してCSVを出せる
- 対象ファイルは app/admin と lib/csv だけ
- 既存のCSVユーティリティがあればそれを使う
- テストを追加し、npm test で通ることを確認する
- できない場合は、理由と未完了箇所を報告する

ポイントは5つです。

書くこと	なぜ必要か
目的	何を作るのかを固定する
完了条件	どこで終わるかを決める
編集範囲	関係ない場所を触らせない
検証方法	動いたと言える根拠を作る
止まる条件	権限不足や外部APIエラーで暴走させない

ブログ記事づくりではこう使う

Codex Appは、ブログ記事づくりにも向いています。
調査、下書き、修正、変換確認まで同じ流れで進められるからです。

たとえば、WordPress記事更新ならこう書けます。

/goal この記事が完成できること

対象:
posts/codex-goal-implementation-method.md を公開前下書きとして完成させる。

完了条件:
- X投稿とGitHub releaseを参照元として入れる
- 読者がCodex Appでゴール設定を真似できる実装例を入れる
- アイキャッチ生成プロンプトを front matter に入れる
- 公開はしない
- npm run publish -- posts/codex-goal-implementation-method.md --dry-run で変換確認する
- 最後に、変更ファイルと未公開であることを報告する

この形にすると、「調べる」「書く」「確認する」「公開しない」が同時に伝わります。
ぼくはここがいちばん大事だと思っています。
Codexに任せる範囲と、自分が決める範囲が分かれるからです。

途中で追加指示するときもゴールに戻す

Codex Appでは、作業中に「ちょっと違う」と思ったら追加で言えます。

そのときも、単に「違う」ではなく、ゴールに戻して言うのがよいです。

今回のゴールは「Codex Appで完成まで持っていく方法」です。
/goal のCLI機能紹介に寄りすぎています。
Codex Appでの作業手順を中心に書き直してください。

これは、今回ぼくが直したかったところです。
ただの機能紹介ではなく、Codex Appからどう完成を目指すか。
そこを中心にしたい。

Codex App用ゴールテンプレート

ぼくなら、まずこの形で使います。

/goal <この記事・実装・修正>が完成できること

具体的なゴール:
<対象>で<完成させたい結果>を作る。

背景:
- 背景: <なぜ必要か>
- 触ってよい範囲: <ファイルやディレクトリ>
- 触らない範囲: <壊したくない場所>

完了条件:
- <ユーザーから見える変化>
- <データや仕様の条件>
- <エラー時の扱い>

確認方法:
- <テストコマンド>
- <ビルドコマンド>
- <ブラウザ確認やURL確認>

止まる条件:
- 認証情報が足りない場合は止める
- 外部APIが落ちている場合は止める
- 仕様判断が必要なら勝手に決めずに聞く

最後の報告:
- 変更ファイル
- 実行した確認
- 残ったリスク

このテンプレートの良いところは、話が勝手に広がりにくいことです。
目的は広い。
でも、編集範囲と完了条件は狭い。
これが長い実装では効きます。