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で見た」「このファイルを変えた」まで残します。
Appはスレッドよりプロジェクト起点で始めると迷いにくい
公式のCodex App案内では、最初のタスクは thread だけでも始められます。
ただ、実務では project を先に作って、そのフォルダの中で進めたほうがぶれにくいです。
- thread: 会話の箱
- project: 作業フォルダと履歴の箱
- goal: その中で今回どこまで終えるか
この3つを分けると、会話 と 作業範囲 と 終わり方 が混ざりません。
Codex Appで最後まで持っていきたい人ほど、最初に project を切ってから goal を置く流れのほうが安定します。
/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 --version2026年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は、ブログ記事づくりにも向いています。
FAQ
毎日3本ずつ改善する運用なら、完了条件はどこまで書くとちょうどいいですか？
毎日3本ずつ記事を直すなら、App用ゴールテンプレートの最初の1行はどう書くと近いですか？
毎日3本ずつ記事を直すなら、3本目を外す判断も goal に入れていいですか？
毎日3本ずつ記事を直すなら、goal の確認方法は3本とも同じでいいですか？
毎日3本ずつ記事を直すなら、goal に `今日は2本で止めるかもしれない` と書いてもいいですか？
毎日3本ずつ記事を直すなら、1本だけ重い日に goal は最初から書き分けたほうがいいですか？
書き分けたほうが楽です。1本目は少し深く、残り2本は軽く を最初に置くだけで迷いにくくなります。入口を軽くするなら Codex Mac appの使い方を初心者向けに解説 、依頼文の軽さ調整は Codexの消費量は短文で減る？ 迷わせない依頼文の作り方 もつながります。
毎日3本ずつ記事を直すなら、持ち越す1本の最初の一手も goal に書いておくといいですか？
書いておくと楽です。明日はこの1本から再開する を一行だけ残すと次の着手が速くなります。入口を軽くするなら Codex Mac appの使い方を初心者向けに解説 、依頼文の軽さ調整は Codexの消費量は短文で減る？ 迷わせない依頼文の作り方 もつながります。
毎日3本ずつ記事を直すなら、翌日に戻した1本だけ goal を作り直してもいいですか？
大丈夫です。翌日はその1本だけ少し深く直す日にしても回ります。入口を軽くするなら Codex Mac appの使い方を初心者向けに解説 、依頼文の軽さ調整は Codexの消費量は短文で減る？ 迷わせない依頼文の作り方 もつながります。
毎日3本ずつ記事を直すなら、翌日に深くやる1本が決まった日は残り2本の goal は1行でもいいですか？
1行でも大丈夫です。深くやる1本だけ詳しくして、残り2本は FAQを1問足す くらいで十分回ります。入口を軽くするなら Codex Mac appの使い方を初心者向けに解説 、依頼文の軽さ調整は Codexの消費量は短文で減る？ 迷わせない依頼文の作り方 もつながります。
調査、下書き、修正、変換確認まで同じ流れで進められるからです。
たとえば、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 CLIの /goal の使い方。長い作業を「終わるまで進める」新機能 と合わせて読むと、CLIの正式機能と、Appで先に使える考え方の差が見えやすくなります。
公式機能の確認と、実務での使い方を分けて考えると迷いにくいです。
FAQ
Codex Appで `/goal` が正式コマンドとして使えるのですか？
この記事では、そこまでは言っていません。確認できる事実は CLI 0.128.0 に /goal ワークフローがあることです。Appでは、その考え方を先に使う形で整理しています。
最初に書くゴールは短いほうがいいですか？
短いほうがいいです。ただし、完了条件は具体的に足したほうがぶれません。最初の一文で方向を決めて、その下に終わり方を書く形が使いやすいです。
ぼくはここがいちばん大事だと思っています。
Codexに任せる範囲と、自分が決める範囲が分かれるからです。
途中で追加指示するときもゴールに戻す
Codex Appでは、作業中に「ちょっと違う」と思ったら追加で言えます。
そのときも、単に「違う」ではなく、ゴールに戻して言うのがよいです。
今回のゴールは「Codex Appで完成まで持っていく方法」です。
/goal のCLI機能紹介に寄りすぎています。
Codex Appでの作業手順を中心に書き直してください。これは、今回ぼくが直したかったところです。
ただの機能紹介ではなく、Codex Appからどう完成を目指すか。
そこを中心にしたい。
Codex App用ゴールテンプレート
ぼくなら、まずこの形で使います。
/goal <この記事・実装・修正>が完成できること
具体的なゴール:
<対象>で<完成させたい結果>を作る。
背景:
- 背景: <なぜ必要か>
- 触ってよい範囲: <ファイルやディレクトリ>
- 触らない範囲: <壊したくない場所>
完了条件:
- <ユーザーから見える変化>
- <データや仕様の条件>
- <エラー時の扱い>
確認方法:
- <テストコマンド>
- <ビルドコマンド>
- <ブラウザ確認やURL確認>
止まる条件:
- 認証情報が足りない場合は止める
- 外部APIが落ちている場合は止める
- 仕様判断が必要なら勝手に決めずに聞く
最後の報告:
- 変更ファイル
- 実行した確認
- 残ったリスクこのテンプレートの良いところは、話が勝手に広がりにくいことです。
目的は広い。
でも、編集範囲と完了条件は狭い。
これが長い実装では効きます。
使用量や止まり方を先に切り分けたいなら、Codex使用量の確認方法 や Codexで止まりやすい原因まとめ も先に見ておくと、ゴールの粒度を決めやすいです。
完成を目指すならログより完了条件を見る
Codex Appで大事なのは、途中の会話を全部読むことではありません。
見るべきなのは、最後の3つです。
- 何を変えたか
- どう確認したか
- まだ残っていることは何か
ここが揃えば、完成に近いです。
逆に、ここが曖昧なら、まだ終わっていません。
ゴール設定は魔法ではなく、依頼文の質がそのまま出る
強くなるのは、こういう依頼です。
- 終了条件がある
- 確認コマンドがある
- 触ってよいファイルが決まっている
- 失敗時の止まり方が決まっている
- 最後に報告してほしい証拠が決まっている
つまり、Codex Appで完成を目指すなら、「うまいプロンプトを書く」より「小さな仕様書を書く」に近づきます。
Codexに任せる仕事が長くなるほど、最初のゴール設定が効きます。
人間が見るべき場所は、途中の作業ログではなく、完了条件と検証結果です。
FAQ
`/goal` を先に使うべきなのはどんな作業ですか？
複数ファイルにまたがる修正や、確認コマンドまで含めて終わらせたい作業です。1回で終わらない仕事ほど効きます。
`/goal` を書いたあと次に何を決めると進めやすいですか？
確認方法 を先に決めると進めやすいです。どのコマンドが通れば終わりか どのURLを見ればよいか があるだけでぶれにくくなります。Appの入口から見直すなら Codex Mac appの使い方を初心者向けに解説 、短く言い切る依頼文に寄せるなら Codexの消費量は短文で減る？ 迷わせない依頼文の作り方 もつながります。
