Codexの/goalコマンドとは？永続ゴール機能の使い方・サブコマンド・既知の不具合まで徹底解説
Codexの/goalコマンドは、OpenAI Codex CLI 0.128.0（2026-04-30リリース）で追加された永続ゴール機能です。ターンをまたいで持続するゴールをCodexに与え、達成・一時停止・解除・予算到達のいずれかになるまで、Codexが計画・実装・テストを自走で進める仕組みになっています。
結論から言うと、/goalは単発タスクを処理する従来型のslash commandではなく、ゴール状態をCodexランタイム側で持ち続ける動作モードです。2026年5月3日時点の公開情報では、公式のSlash commands in Codex CLIには未掲載で、ドキュメント整備を求めるissue（#20536）と、初版で/goalが動かない不具合報告（#20591）の両方が立っています。Changelogでは0.128.0の主要新機能として「app-server APIs、model tools、runtime continuation、TUI controlsで持続的ゴールを管理できるようにした」と説明されています。
本記事のポイント
- Codexの/goalは、ターンをまたいで持続するゴールを与え、達成・一時停止・解除・予算到達まで自走させる永続ゴール機能です。
- サブコマンドは/goal <objective>・pause・resume・clearの4種類、状態はpursuing・paused・achieved・unmet・budget-limitedの5種類で、TUIから操作できます。
- Codex CLI 0.128.0で追加されたばかりで、公式slash-commandsドキュメントには未掲載、初版で動作不良の報告（issue #20591）もあるため業務投入前にバージョン固定と運用ルールが必要です。
この記事で扱うテーマ
関連キーワード
- Codex /goal
- Codex goal コマンド
- Codex CLI /goal
- Codex 永続ゴール
- Codex goal pause resume
- Codex 0.128.0 /goal
このページで答える質問
- Codexの/goalコマンドとは何ですか？
- /goalのサブコマンドとライフサイクル状態はどうなっていますか？
- /goalと/planは何が違いますか？
- /goalを業務で使うときの注意点は何ですか？
Codexの/goalコマンドとは何か
Codexの/goalは、Codex CLI 0.128.0で導入された「永続ゴール（persisted goal）」を扱うslash commandです。Codex CLIのChangelogでは、0.128.0の項目として"Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls for create, pause, resume, and clear."
と記載されています。
従来の/planはその場で計画案を提示してユーザーの確認を待つ動作でした。これに対して/goalは、与えた目的をCodexのランタイム側に保存し、ターン（ユーザー入力＝Codex応答の1往復）の境界をまたいで保持し続けます。Codexは内部的に「現在追跡中のゴール」を持ち、各ターンで作業を進め、テストや検証を行い、必要な追加実装を提案・実行していきます。
言い換えると、/goalはCodexを「単発タスクの実行係」から「ゴール達成まで作業し続ける担当者」に切り替えるためのコマンドです。会話の流れがそれても、Codexは保持しているゴールに沿った提案を続けます。
| 確認対象 | 確認できる内容 | 2026-05-03時点の状況 |
|---|---|---|
| Codex CLI Changelog | 0.128.0で /goal workflows を追加した旨と関連PR番号 | 主要新機能として記載あり |
| Slash commands in Codex CLI（公式ドキュメント） | /plan, /resume, /status, /compact 等のslash command一覧 | /goal は未掲載 |
| openai/codex issue #20536 | /goal CLI commandと Goals lifecycle の公式ドキュメント整備依頼 | open |
| openai/codex issue #20591 | 0.128.0で /goal が status 400 で動作しないという報告 | open（macOS/Pro/gpt-5.5 high） |
/goalの4つのサブコマンドと使い方
/goalは引数で挙動が変わります。issue #20536で議論されているCLIの実装と、Changelogで明示されている「create, pause, resume, and clear」の4操作を整理すると、次の使い方になります。
1. /goal <objective> — ゴールを設定する
ゴール本体を設定するときは、/goalのあとに目的を自然文で書きます。Codexはこの目的を「現在追跡中のゴール（pursuing）」として保存し、以後のターンではこのゴールに沿って作業を進めます。
/goal リファクタ後にすべての既存テストを緑にし、CIをグリーンにする目的は、ターンをまたいで再評価され続けるため、判定可能な完了条件（テスト緑、エラーゼロ、特定のコマンドが成功する、など）を含めると、Codex側で「達成（achieved）」を認識しやすくなります。
2. /goal pause — 追跡を一時停止する
ゴールは保持したまま、追跡だけを止めます。状態は「paused」に遷移し、Codexは以後のターンでゴールに紐づく自走を行いません。会議や別作業で割り込みが入ったときに、ゴールを破棄せずに待機させたい場面で使います。
3. /goal resume — 一時停止を解除する
pause中のゴールを「pursuing」に戻します。Changelogの0.128.0には"Use /goal resume for paused goals"
がbug fixとして明記されており、resume操作は当初の実装で課題があり後から修正された経緯がうかがえます。
4. /goal clear — ゴールを解除する
追跡中のゴールそのものを破棄します。pauseとは異なり保存状態を消去するため、別のゴールに切り替える前や、長時間放置していたゴールを片付ける目的で使います。
5つのライフサイクル状態
/goalには「pursuing」「paused」「achieved」「unmet」「budget-limited」の5つの状態があります。issue #20536で議論されている遷移を整理すると、以下のように読めます。
| 状態 | 意味 | 主な遷移元 |
|---|---|---|
| pursuing | ゴール追跡中。各ターンで作業が進む | /goal <objective> 直後 / /goal resume直後 |
| paused | ゴールは残ったまま追跡を停止 | /goal pause |
| achieved | ゴール達成と判定された | pursuing中にCodex側で完了条件を確認 |
| unmet | ゴール未達のまま終了した | pursuing中にブロック・断念で終了 |
| budget-limited | 設定した予算（時間・トークン等）に到達して打ち切り | pursuing中の自動停止 |
ここで重要なのは、budget-limitedの存在です。ゴールが終わらない限り走り続けるエージェントはコスト制御が難しい一方、/goalには予算到達で安全に止める出口が組み込まれています。AIエージェントを業務に組み込む際の権限・監査の議論と同じで、自走させる範囲と止め方を最初に設計することが前提になります。
/goalと/planの違い
Codex CLIには似た方向性のコマンドとして/planがあります。/planは計画モードに入って実行手順を提示する機能で、ユーザーの承認を待ってから実装に移ります。/goalはそもそも会話モデルが変わり、ゴールの追跡をランタイム側に持たせます。
| 観点 | /plan | /goal |
|---|---|---|
| 主目的 | その場で計画案を提示する | ターンをまたいで目的に向けて自走する |
| 状態保持 | 計画はそのターン中心、保存はしない | ゴール状態をapp-serverで保持 |
| 停止条件 | ユーザー判断で計画から実装に移行 | 達成・pause・clear・budget-limited・unmet |
| 再開 | 会話を続ければ自然に進む | /goal resume で明示的に追跡再開 |
| 典型ユースケース | 新規実装の最初のステップを設計する | 長時間の検証・修正・テスト緑化を任せる |
つまり/planは「これからやることの設計図」を出すのに使い、/goalは「設計図のうちエージェントに走らせ続ける部分」を担う、という補完関係で考えると整理しやすいです。
アーキテクチャ — 0.128.0で何が増えたか
Changelogでは、0.128.0の/goal機能が以下4つの実装層から成ることが示されています。
- app-server APIs: ゴールの作成・取得・更新・削除を扱うサーバー側API。Codex CLIから出るリクエストを受けて、ゴールを永続化する
- model tools: モデル側がゴールを参照・更新するためのツール定義。Codexがターンをまたいでゴールにアクセスできるのはここを通じて
- runtime continuation: 1ターンで完了しないゴールを次のターンに引き継ぐランタイム機構。pursuing状態を保ち続ける本体
- TUI controls: ターミナルUIから create / pause / resume / clear を操作できるコントロール
この4層構成が、/goalを「単なるslash commandの追加」ではなく「Codexのランタイム拡張」として位置づける根拠になっています。issue #20591では0.128.0の初版でこの連携にバグが残り、ゴール作成時にstatus 400が返るケースが報告されています。
業務で使うときの設計ポイント
/goalは便利な反面、ターンをまたいで自走するため、業務に組み込むときは以下の設計を最初に決めておく必要があります。
1. 完了条件を判定可能な形で書く
「より良いコードにする」は判定できないため、Codex側がいつまでもachievedにできません。「npm testが緑」「特定のlintルールでerror 0」「curlでHTTP 200を返す」のように、機械的に確認できる完了条件をゴール本文に含めます。
2. 予算と作業範囲を先に決める
budget-limited状態が用意されているとはいえ、走り続けるエージェントはコストとリスクの両面で管理対象になります。実装に着手する前に、対象ファイル範囲・許容実行時間・許容トークン量・サンドボックス権限を明確にしておきます。これはAIエージェント ガバナンスとは？権限、監査ログ、承認フローの設計を整理すると同じ考え方です。
3. pause前提の運用にする
会議、レビュー、別作業の割り込みは必ず入ります。/goal pauseと/goal resumeを前提に運用設計をすると、ゴールを破棄して作り直す手間がなくなります。逆に「resumeを使わずにずっとpursuingで走らせる」運用は、長期で必ず破綻します。
4. ログと監査の保存先を決めておく
ターンをまたいで自走するということは、ユーザーが見ていないところで変更が入ることを意味します。ゴール単位の作業ログをCIや監査ログに残す運用にしておくと、トラブル時の原因特定が速くなります。テンプレートはAIエージェント監査ログテンプレートとは？権限・履歴・運用ルールの整理を参照してください。
既知の不具合とドキュメント未掲載の論点
2026-05-03時点で押さえておくべき2つの公開issueがあります。
issue #20591 — 0.128.0で/goalが動かない
macOS、Codex Pro、gpt-5.5 highの環境で、/goal実行時にstatus 400が返るというreproductionが2026-05-01に報告されています。バージョン固定で運用していると初版を引いてしまう可能性があるため、本番運用では「/goalが想定どおり動くバージョン」を一度確認してから採用するのが安全です。
issue #20536 — 公式slash-commandsドキュメントに未掲載
公式のSlash commands in Codex CLIには、/plan・/resume・/status・/compactなどは掲載されていますが、/goalは未掲載です。issue #20536はこの掲載とlifecycleドキュメント整備を求めるもので、現時点では「公式ドキュメントだけを根拠に運用ルールを書く」のは難しい状態です。Changelog、issue、リリースノートを補助情報として参照することになります。
公式情報と観測情報の読み分け
取り扱う情報源を整理しておくと、社内に展開する文書でも齟齬が起きにくくなります。
- 公式: Codex CLIのChangelog（0.128.0で /goal を追加）、Codex CLIリポジトリのリリース、PR番号
- 観測: issue #20536（ドキュメント整備依頼）、issue #20591（status 400報告）、コミュニティの利用報告
- 未公開: 公式slash-commandsドキュメントへの掲載、各サブコマンドのオプション一覧、予算（budget）の具体的な設定方法
未公開部分は、社内ドキュメントでも「2026-05-03時点では公式に明記されていない」と注記したうえで、実環境で確認した挙動を記録する形が安全です。
よくある質問
Codexの/goalコマンドとは何ですか？
Codex CLI 0.128.0で追加された永続ゴール機能で、ターンをまたいで持続するゴールを与え、達成・一時停止・解除・予算到達まで自走させるコマンドです。
/goalのサブコマンドは何がありますか？
ゴール設定の/goal <objective>、追跡を止める/goal pause、再開する/goal resume、破棄する/goal clearの4種類です。
/goalと/planは何が違いますか？
/planはその場で計画案を提示して止まりますが、/goalはゴールをランタイムに保持してターンをまたいで自走します。設計と実行を分けて使うのが整理しやすい運用です。
業務で使うときの注意点は何ですか？
判定可能な完了条件を書く、予算と作業範囲を先に決める、pauseとresumeを前提に運用する、監査ログを残すの4点が出発点です。0.128.0で動作不良の報告（issue #20591）があるため、バージョン確認も必要です。
関連ページと関連記事
- Codex petsとは？/petの使い方とカスタムpetの作り方を解説
- Codex 自動化（オートメーション）完全ガイド
- Codex for (almost) everythingとは？Computer Use・OpenClaw・Claude Codeとの違いを整理する
- AIエージェント ガバナンスとは？権限、監査ログ、承認フローの設計を整理する
- AIエージェント監査ログテンプレートとは？権限・履歴・運用ルールの整理
CodexやAIエージェントの社内運用を整理したい場合
Codexの/goalのように、ターンをまたいで自走するエージェント機能を業務に取り込むときは、機能を試すだけでなく、完了条件、予算、権限、監査、運用ルールを同時に決める必要があります。ファネルAiでは、業務にAIエージェントを組み込む前提整理から、運用フローとガバナンス設計まで相談できます。
