Codex /goal は0.128.0系で実在する機能ですが、自分のCLIと現在の画面で使えるかは別に確認する必要があります。
2026年5月4日時点では、OpenAIの公開CLI slash command文書にはまだ /goal が載っていません。より強い根拠は0.128.0のrelease/source treeと、experimental扱いのapp-server goal APIです。
目的が成果物、対象ファイル、テスト、予算、停止条件に落とせる場合だけ /goal を使い、コマンドが見えない場合や目的がまだ曖昧な場合は先に /plan で整理します。
まず答え：/goal は本物だが、今の環境で使えるとは限らない
/goal は、単に「続けて」と長く書くためのpromptではありません。Codexのスレッドに長めの目的を固定し、continuation、pause、resume、budget limit、completion checkの間も同じ目的へ向かわせるためのworkflowです。OpenAI Codexの 0.128.0 release では persisted /goal workflows、app-server APIs、model tools、runtime continuation、TUI controls が触れられています。
ただし、公開文書とローカル実装は同時に更新されるとは限りません。2026年5月4日に確認したOpenAI Developersの CLI slash-command page には /plan、/status、/resume、/compact、/ps、/stop などがありましたが、/goal はありませんでした。IDE slash-command page でも /goal はIDEコマンドとして説明されていません。つまり、機能の存在と、あなたの端末で使えることは分けて判断します。
最初の確認はこの表で十分です。
| 状況 | 考えられる意味 | 次の操作 |
|---|---|---|
codex --version が0.128.0以上で、CLIのslash menuに /goal がある | goal workflowを試せる | 小さく監査できる目的で始める |
| ローカルCLIが0.128.0未満 | そのbinaryに機能がない可能性 | 更新してから再確認する |
| 公開文書にはないがCLIにはある | 文書がrelease/sourceに遅れている可能性 | 使う場合も日付つきで判断する |
| IDEや別画面にない | CLIと同じコマンド面とは限らない | 画面ごとに確認する |
| 目的をファイル、テスト、停止条件にできない | /goal には早い | /plan で目的を固める |
今回の検証環境では codex --version が codex-cli 0.125.0 でした。そのため、ローカル実行だけでは /goal の可用性を証明できません。新しい機能がrelease lineに入っていても、手元のCLIがまだ古いという状況は十分に起こります。
0.128.0の証拠から見る /goal の役割
現時点でユーザー側に教えるべき最小形は次です。
text/goal <objective>
0.128.0の slash command source では、Goal が "set or view the goal for a long-running task" と説明されています。inline argsを受け取り、task実行中にも使えることが示されています。別のTUI action sourceでは、現在のgoalがなくobjective textもないとき、Usage: /goal <objective> が返ることも確認できます。
ここで重要なのは、未確認のサブコマンドを増やさないことです。/goal set、/goal audit、/goal complete のような形を、手元のバージョンが明示していないのに運用に組み込むべきではありません。確認できるのは、/goal <objective> と、その背後にあるmanaged lifecycleです。
内部的には、/goal は長いpromptというより保存される作業契約に近いものです。
- スレッドに現在のgoalが保持される。
- runtime continuationが同じgoalに沿って進む。
- tokenとwall-clock accountingがbudget判断に関わる。
- budget limitに達したら、新しい大きな作業を始めずwrap upする。
- app-serverには
thread/goal/set、thread/goal/get、thread/goal/clearがある。 - TUIにはcreate、pause、resume、clearに対応する制御がある。
安全面でも重要な設計があります。continuation templateはobjectiveをuntrusted user dataとして扱い、完了を宣言する前に実際の成果物と証拠を確認するよう求めます。budget-limit templateは、予算に達したら作業を広げずに整理する方向へ誘導します。したがって /goal は「放っておけば終わる」機能ではなく、継続、監査、予算停止を組み合わせた仕組みです。
/goal が見つからない理由
コマンドが出てこない時は、まずバージョンを見ます。
bashcodex --version
codex-cli 0.128.0 より古いなら、文法を疑う前に更新します。更新後にterminalやCodex sessionを開き直し、slash menuを再確認します。
次に、どの画面で作業しているかを分けます。CLI、IDE、desktop app、app-server integrationは同じものではありません。公開文書は参考になりますが、実際に入力できる命令を決めるのは、今走っているbinaryとUIです。
さらにapp-serverを混同しないことも必要です。app-server API overview には thread/goal/set、thread/goal/get、thread/goal/clear があり、capabilities.experimentalApi の後ろにあります。これはgoalがthread conceptとして存在する証拠ですが、一般ユーザーがexperimental APIを直接使うべきだという意味ではありません。
実務では次の順で確認します。
codex --versionを実行する。- CLI sessionでslash command一覧を開く。
- CLI、IDE、app、app-server integrationのどれかを確認する。
/goalがなければ、先に/planで目的を監査可能にする。- 更新後またはCLIへ戻った後、もう一度command surfaceを確認する。
「この画面では確認できていない」と考えるのが安全です。「機能が存在しない」と決めつける必要はありません。
/goal に渡す目的の書き方
/goal が効果を出すのは、objectiveが監査できる場合だけです。曖昧な目的を渡すと、エージェントは長く動いても成果を判定できません。最低限、結果、対象ファイル、検証、報告すべき証拠、停止条件を入れます。
使いやすい形は次です。
text/goal <対象ファイルまたはmodule>で<具体的な結果>を実装する。 Acceptance criteria: - User-visible behavior: <何が変わるか> - Files in scope: <編集してよいpath> - Verification: <test、command、screenshot、log、manual check> - Evidence to report: <diff summary、test output、risk、残件> - Stop rule: <budget、credential不足、依存の失敗、未決定の仕様>
弱い目的は次のようなものです。
text/goal dashboardを改善する
実務向けに直すと次のようになります。
text/goal billing usage tableにCSV exportを追加する。 Acceptance criteria: - export actionを既存filterの横に置く。 - 編集範囲はapp/billingとshared CSV utilitiesに限定する。 - CSVにはaccount id、period、model、tokens、cost、statusを含める。 - npm test -- billing と npm run lint を実行する。 - billing APIがraw row dataを返さない場合は停止して不足を報告する。
後者は、Codexが勝手にproduct decisionを作らずに進めるだけの境界を持っています。ここまで具体化できない場合は /plan が先です。ログイン経路や請求が気になる場合は Codex APIキーとChatGPTサブスクの違い を確認し、長いrunの予算や上限は OpenAI Codex usage limitsガイド と合わせて見ます。ローカル設定の問題なら Codex config.toml が次の確認先です。
長い作業での安全な流れ
基本の流れは plan、set、monitor、verify、clear or continue です。UIごとの名称は変わっても、監査の考え方は変えません。
| 段階 | 何をするか | 残す証拠 |
|---|---|---|
| Plan | scope、acceptance criteria、verification、stop ruleへ分解する | objective textとscope notes |
| Set | 目的が監査可能になってから /goal <objective> を使う | version、command surface、objective record |
| Monitor | active、paused、resumed、budget-limitedを観察する | progress notes、changed files、command output |
| Verify | deliverablesと照合して完了を判断する | tests、screenshots、logs、diff summary |
| Clear or continue | 完了ならclear、未完ならobjectiveを修正する | remaining risks、next action |
最も危険なのは、長いtranscriptを完了証拠と勘違いすることです。受け入れる前に次を確認します。
- 変更ファイルは宣言したscope内か。
- 約束したtestは実行されたか、実行できない理由はあるか。
- summaryだけでなく実際のartifactがあるか。
- 関係ないrefactorや隠れたproduct decisionをしていないか。
- budget-limitedの時に新しい作業を始めずwrap upしたか。
- 続ける理由が明確か、それともgoalをclearすべきか。
どれか弱いなら未完了として扱います。/goal は継続を助ける機能であって、review基準を下げる機能ではありません。
/goal を使わない方がよい場面
問題がまだ曖昧な時、/goal を最初の操作にしない方が安全です。広いbrainstorming、未知のcodebase調査、success conditionのない探索、production権限が必要だが許可されていない操作、予算が読めない長時間runには向きません。
避けるべき状況は次です。
- credential、production access、policy decisionが必要だが境界が未確認。
- 変更範囲が広すぎてreviewできない。
- stop ruleを言えない。
- 完了をどう判定するか自分でもわからない。
- 弱いpromptを長い実行時間で補おうとしている。
小さい作業なら通常のpromptで十分です。分解が必要なら /plan、会話の継続なら /resume や /compact を使います。/goal は、持続性が必要なほど大きく、監査できるほど具体的な作業に向いています。
他のcoding agentとの使い分けは Claude Code vs Codex で比較できます。ここで重要なのは自律性の雰囲気ではなく、最終状態が基準と一致したことを証明できるかです。
よくある質問
Codex /goal は利用可能ですか？
2026年5月4日に確認した0.128.0のrelease/source evidenceでは存在します。ただし公開CLI/IDE command文書は遅れていたため、ローカルのversionとcommand surfaceを確認してください。
構文は何ですか？
信頼できる最小形は /goal <objective> です。追加のsubcommandは、手元のバージョンが明示しない限り前提にしません。
CLIに /goal が出ないのはなぜですか？
古いCLI、別の画面、または公開文書と実装のずれが主な理由です。codex --version とslash menuを確認します。
/goal は /plan と同じですか？
違います。/plan は目的を分解する段階、/goal は監査可能になった目的を持続させる段階で使います。
放置して一晩走らせてもよいですか？
標準運用にはしません。budget、acceptance criteria、file scope、reviewable evidenceが必要です。budget-limited wrap-upは成功ではありません。
app-server goal APIを使うべきですか？
experimental app-server integrationを明示的に作る場合だけ検討します。通常の利用ではCLI command surfaceから確認します。