Codex /goalの使い方：有効化、編集・停止と完了の確かめ方

Codex /goal は、「この状態になったら完了」という目標を現在のチャットに設定し、複数のターンにわたって作業を続けるための機能です。対応するCodexの入力欄に /goal 目標の内容 と入力して始めます。途中の状況は /goal、変更は /goal edit、一時停止は /goal pause、再開は /goal resume、解除は /goal clear で管理します。現在の公式コマンド説明

コマンドが表示されなければ、CLIのバージョンと config.toml の features.goals を確認します。長く動いたことを成功の根拠にせず、対象ファイルと検証コマンドまで決めてから開始しましょう。以下は2026年10月7日時点の公式文書に基づく操作ガイドです。作業例は説明用に作成したもので、実際のGoal実行結果ではありません。

/goal はどこに入力する？

/goal は、Codexとの会話で使うスラッシュコマンドです。CLIなら、ターミナルで起動した対話中のCodexの入力欄に入力します。通常のシェルに codex /goal ... と書く手順ではありません。

公式の開発者向けコマンドガイドは、CLIに加えてデスクトップアプリとIDEのスラッシュコマンドにも /goal を掲載しています。アプリやIDEを使う場合は、そのCodexのチャット入力欄で / を入力して一覧を確認してください。CLIでコマンドが使えることだけでは、別のアプリや拡張機能でも同じ状態だとは判断できません。

たとえば、修正したい関数とテストが決まっているなら、次のように入力できます。

/goal src/release-date.mjsの日付表示を修正し、tests/release-date.test.mjsの全ケースが通る状態にする。変更はsrc/release-date.mjsに限定し、検証コマンドと結果を報告する。

これは目標の入力例です。実際に使うときは、自分のプロジェクトに存在するファイル名と検証方法に置き換えます。後半では、この例のファイルとテストを具体化します。

/goal が表示されないときの確認と有効化

まず、CLIを使っている場合は通常のターミナルでバージョンを確認します。OpenAIのGoals解説では、Goalsは Codex 0.128.0から利用可能と説明されています。これは導入されたバージョンであり、現在の最新版を意味しません。

codex --version

古いCLIなら、もともと使っていたインストール方法で更新します。npmで入れた場合の公式手順は次です。

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

Homebrewのcaskで入れた場合は、次の手順です。

brew update
brew upgrade --cask codex
codex --version

対応版なのに一覧に出ない場合は、Goalsの機能設定を確認します。 公式のFollow a goalは、config.toml の [features] に次を設定する方法を案内しています。

[features]
goals = true

すでに [features] があるファイルでは、その節に goals = true を追加・変更します。同じ節を重複して作らないようにしてください。別の方法として、通常のターミナルから次のCLIコマンドで有効化できます。

codex features enable goals

設定後は、使用しているCodexの / の一覧を再確認します。ここではGoalsの設定だけを変更すればよく、multi_agent = true を追加する手順ではありません。

有効化設定は、公式に案内された「一覧に出ない場合」の対処です。アプリ固有の不具合や、目標の保存エラーまですべて直ると保証するものではありません。解決しない場合は、使用しているクライアント、バージョン、操作、エラー全文、機密情報を除いた関連ログをそろえると、問題を切り分けやすくなります。

設定・表示・編集・一時停止・再開・解除の使い分け

現在の公式ガイドに記載されている操作は次のとおりです。いずれも目標を設定した同じCodexのチャットで使います。公式の構文と文字数制限

目標は空にできず、上限は4,000文字です。仕様が長い場合は、詳細をプロジェクト内のファイルに保存し、「そのファイルを読んで、何を達成するか」を目標に書きます。長い仕様をすべてスラッシュコマンドに詰め込む必要はありません。

途中で期待する結果が変わったら、/goal edit で目標を修正します。状況を見直すだけなら /goal pause、同じ到達条件で続けるなら /goal resume を使います。作業そのものを取りやめる、または別の目標に移る場合は /goal clear で解除します。

一時停止や解除は、変更の取り消しとは別です。 すでに書き換えたファイル、実行したコマンド、送信済みの要求が元に戻るわけではありません。停止後にも差分を確認し、必要な変更の取り消しは別の操作として扱ってください。

完了を判定できるゴールを作る：日付表示の修正例

「表示をいい感じにして」では、Codexも読者も終わりを判定できません。たとえばリリース日を YYYY-MM-DD から日本語表示へ変える作業なら、正しい日付を表示できること、存在しない日付を受け付けないこと、時差で日付がずれないことを先に決められます。

以下は、node --test が使えるNode.jsをインストール済みの環境で、標準テスト機能を使う説明用の小さな構成です。外部サービスや追加パッケージは不要です。既存プロジェクトに試す際は既存ファイルを上書きせず、空の検証用フォルダーを使ってください。

src/release-date.mjs
tests/release-date.test.mjs

まず src/release-date.mjs に、修正対象となる関数を用意します。この段階では未実装なので、テストは通りません。

export function formatReleaseDate(value) {
  throw new Error('未実装');
}

tests/release-date.test.mjs には、完了条件を表すテストを保存します。

import test from 'node:test';
import assert from 'node:assert/strict';
import { formatReleaseDate } from '../src/release-date.mjs';

test('リリース日を日本語で表示する', () => {
  assert.equal(formatReleaseDate('2026-10-07'), '2026年10月7日');
  assert.equal(formatReleaseDate('2028-02-29'), '2028年2月29日');
  assert.equal(formatReleaseDate('2000-02-29'), '2000年2月29日');
});

test('存在しない日付と指定外の形式を拒否する', () => {
  for (const value of [
    '2026-02-29', '2100-02-29', '2026-04-31',
    '2026-13-01', '2026-00-10', '2026-10-00',
    '2026/10/07', '', null,
  ]) {
    assert.throws(() => formatReleaseDate(value), RangeError);
  }
});

プロジェクトのルートから実行する検証コマンドは次です。

node --test tests/release-date.test.mjs

macOS・Linuxのシェルでは、タイムゾーンを変えた次の2回の検証も行えます。日付だけの文字列を日時へ変換した際に、前日にずれる実装を見つけるためのチェックです。

TZ=Asia/Tokyo node --test tests/release-date.test.mjs
TZ=America/Los_Angeles node --test tests/release-date.test.mjs

このファイル構成を作ったうえで、Codexの入力欄に次の目標を設定します。

/goal src/release-date.mjsのformatReleaseDateを実装する。YYYY-MM-DD形式の実在する日付を「2026年10月7日」の形式で返し、不正な形式・存在しない日付はRangeErrorにする。日付だけを扱い、実行環境のタイムゾーンで日をずらさない。tests/release-date.test.mjsを読み、node --test tests/release-date.test.mjsがすべて成功するまで修正する。macOS・Linuxでは同コマンドにTZ=Asia/Tokyo、TZ=America/Los_Angelesをそれぞれ付け、両方の成功も確かめる。編集できるのはsrc/release-date.mjsだけで、テストの削除・緩和や外部パッケージの追加はしない。各試行では失敗ケースを確認してから修正する。検証コマンドが実行できなければ、完了とせず原因と必要な対応を報告する。最後に変更ファイル、検証結果、残る制約を示す。

この目標では、実装方法を細かく指定していません。一方、出力、不正入力の扱い、変更範囲、検証方法は固定しています。Codexがテストに合わせて仕様を勝手に弱める余地を減らし、失敗したケースから次の修正を選べるようにした形です。

この小さな関数なら通常の依頼でも十分に対応できます。Goalがより役立つのは、同じような明確な判定を保ちながら、既存コードの調査や複数の修正候補を試す必要がある作業です。公式Cookbookの用途と目標設計

「完了しました」を受け取ったあとに確認すること

この例の完了証拠は、長い会話履歴ではなく、関数の変更とテスト結果です。最低限、次を照合します。

1. src/release-date.mjs が実装され、テストや別ファイルが書き換えられていないか。
2. node --test tests/release-date.test.mjs の実行記録があり、成功・失敗が分かるか。macOS・Linuxでは、指定した2つのタイムゾーンでも通ったか。
3. 通常日、うるう日、不正日付の両方が検証されているか。
4. 実行できなかった検証や、対応していない入力が明記されているか。

たとえば通常日だけ通った、失敗するテストを消した、実行せずに成功と述べた状態は、この目標の完了には当たりません。反対に、テストが成功していても、今回の形式以外の日時入力まで対応したと広げて受け取るべきではありません。自分でも同じコマンドを実行できる状態が、確認しやすい成果です。

続行する条件と、予算で止まったときの扱い

Goalは現在のチャットに保存される目標です。プロジェクト全体の共通指示や、別チャットに自動で引き継がれる記憶とは区別します。公式Cookbookによると、継続が検討されるのは、目標が有効で予算内にあり、実行中のターン・待機中の入力・未処理の作業がないタイミングです。目標の保存と継続の説明

同資料は、計画だけの作業では自動継続を起こさないこと、中断で目標が一時停止すること、継続ターンでツールを使わなかった場合は次の自動継続を抑えることも説明しています。したがって、「目標が残っているから、常に無期限で実行される」とは考えないでください。止まった場合は /goal で現在の目標を確認し、完了・一時停止・予算到達・作業上の障害のどれに当たるかを見ます。

予算に達したことは、目標を達成したことではありません。 予算で停止したら、どこまで実装したか、何を検証できたか、何が残っているかを報告してもらいます。上の例なら、未確認の不正日付ケースがある間は「一部実装済み、検証未完了」です。

目標文に「3回試して改善しなければ停止する」と書くこともできます。ただし、それは作業方針の指示であり、実装上の強制的な回数制限や支出上限を設定したことにはなりません。また、今回の公式スラッシュコマンド説明には /goal budget という構文はありません。

開発者向けのapp-server仕様では、thread/goal/set の tokenBudget と、進捗の tokensUsed・timeUsedSeconds が説明されています。これは独自の連携を作るためのAPIで、通常の /goal 有効化に直接呼び出す必要はありません。新しい目標への置き換えでは使用量の計算がリセットされ、同じ未終了の目標の状態・予算の更新では履歴が保持される、と区別されています。

Goalのトークン予算は作業量の管理であり、米ドルの請求額やChatGPTプランの残量にそのまま換算できません。費用の見直しが必要なら、Codex CLIのAPI費用を見積もる方法で、利用枠との違いと未確定の実行分を含む判断を確認できます。

よくある質問

Codex /goal は今も実験的な未公開コマンドですか？

現在の公式ガイドに掲載されています。Goalsは0.128.0から利用可能とされ、設定・表示に加えて編集、一時停止、再開、解除も文書化されています。使っているクライアントでの対応状況は、バージョンとスラッシュコマンド一覧で確認してください。公式Goals解説、現在のコマンド説明

バージョンが新しいのに /goal が出ません。何を設定しますか？

公式の案内は、config.toml の [features] に goals = true を設定するか、CLIで codex features enable goals を実行する方法です。設定後にも表示されなければ、CLIとアプリ・IDEのどれを使っているかを確認します。保存エラーなど、コマンドが見える場合の問題は別に切り分けます。有効化の公式案内

途中で目標を変更できますか？

はい。同じチャットで /goal edit を使います。単に様子を確認したい場合は /goal、作業を止めて見直す場合は /goal pause です。目標自体の変更と、一時停止を分けて使えます。公式の操作一覧

/goal clear でファイルの変更も戻りますか？

戻りません。/goal clear は現在の目標を解除する操作です。ファイルの差分を取り消したい場合は、停止後に変更を確認し、必要な分だけ別途戻します。

目標を設定すれば、パソコンを閉じても一晩中動きますか？

その保証はありません。公式資料が説明するのは、対応環境で目標を保持し、継続条件を満たしたタイミングで作業を続ける仕組みです。電源を切った後の実行や、一定時間の無人実行が保証されるわけではありません。長い作業では、成果の判定方法と途中で確認する区切りを決めてください。継続条件の説明

どんな作業なら通常の依頼で十分ですか？

一つの説明、短い修正、答えを受け取って終わる質問は通常の依頼で十分です。Goalは、完了条件が明確で、調査結果によって次の操作が変わる作業に向いています。目的がまだ「全体を改善する」程度なら、先に期待する結果と検証方法を整理しましょう。Goalsを使わない場面