Codex /goalコマンドの使い方｜設定と停止条件の実践

「Codexの/goalコマンドを打っても反応しない」「一晩走らせたら週次の使用量が半分消えていた」——Codex CLIの/goalを試そうとして、設定や使い方の情報が見つからず戸惑った方は少なくないはずです。

結論から言うと、/goalの使い方で押さえるべきは3点です。①有効化はconfig.tomlに2行追加するだけ、②サブコマンドは5つだけ（/goal budgetや/goal statusは存在しません）、③成否は「検証可能な停止条件を書けるか」でほぼ決まります。

株式会社Fyveは中小企業のAI導入を支援する立場から、公式ドキュメント・GitHubの実装・第三者の実測データを突き合わせて本記事をまとめました。私自身AIの自律運用を日常的に回している実務者の視点で、設定から失敗対策までを実践編として解説します。

Codex /goalコマンドとは｜実践編の前提整理

/goalは、Codexに「長時間作業のための持続的な目標」を与えるコマンドです。公式ドキュメントでは「検証可能な停止条件に向けて、ターンをまたいで作業を続けさせたいときに使う」機能と定義されています（OpenAI公式・Follow goals）。

通常のプロンプトとの違いを公式の対比で整理すると、次のようになります。

• プロンプト: 依頼→作業→結果→待機（1ターンで完結）
• ゴール: 作業→検証→継続または完了（スレッド単位の永続状態を持ち、自律的に作業を続ける）

興味深いのはリリースの経緯です。/goalはCodex CLI 0.128.0（2026年4月30日）で初めて出荷されましたが（リリースノート）、当初は公式ドキュメントに記載がなく、GitHubで「実在するのに文書化されていない」と文書化を求めるIssueが立つほどの「隠し機能」状態でした。現在は公式のユースケースページとCookbookが公開され、正式に使える段階に入っています。

「そもそも/goalで何ができるのか」という概念面と、「どんな業務に向くのか」という活用シーンは、以下の2記事で先に解説しています。本記事は3本目として、実際に手を動かす設定・書き方・失敗対策に絞ります。

OpenAI Codex Goal Modeとは｜AIに目標を渡して任せる新しい働き方

CodexCodex Goal Mode の活用｜目標を渡して数時間任せる

Codex /goalの有効化設定｜config.tomlに2行追加

/goalを使うには、まずバージョン要件を満たしているかを確認します。必要なのはCodex CLI 0.128.0以降です。ターミナルで次のコマンドを実行してください。

codex --version

バージョンが古い場合は先に更新します。そのうえで、有効化の方法は2つあります。

方法1: config.tomlに追記する

~/.codex/config.toml に以下の2行を追加します。

[features]
goals = true

方法2: コマンドで有効化する

設定ファイルを直接編集したくない場合は、次のコマンド1つで同じ設定が入ります。実行後はCLIを再起動してください。

codex features enable goals

なお、新しいバージョンではこの有効化作業が不要になっている場合があります。ただし公式ドキュメントは現在もフラグによる有効化手順を記載しているため（2026年7月時点）、/goalが反応しないときはまず上記の設定を確認するのが確実です。バージョン確認・更新の詳しい手順は以下の記事にまとめています。

CodexCodexのバージョン確認と更新方法｜最新化と戻し方

読者特典・無料ダウンロードひとりAI経営 全体マップ無料でダウンロード →↓

Codex /goalのサブコマンドは5つだけ

/goalのサブコマンドは以下の5つがすべてです。

ここで注意したいのが、Web上には存在しないサブコマンドを紹介する記事が出回っている点です。実測レビューで捏造検証を行ったjdhodges氏の記事では、「/goal budget」「/goal status」といったコマンドは実在しないと明言されています。状態確認は引数なしの/goal、トークン予算は後述するtoken_budgetの設定であり、専用サブコマンドはありません。

細かい仕様として、ゴールは1スレッドにつき最大1つです。GitHubの実装を見ると、ゴールは専用のSQLiteデータベースに永続化され、スレッドIDを主キーとして管理されています。新しいゴールを設定すると既存のゴールは置き換えられる仕組みです。

良いゴールの書き方｜公式推奨の6要素と停止条件設計

/goalの成否を分けるのはゴール文の書き方です。公式Cookbookの基本原則は「良いゴールは1つのプロンプトより大きく、無限のバックログより小さい」というものです（OpenAI Cookbook）。

公式が挙げる「強いゴールが定義する6要素」は次のとおりです。

• Outcome（成果）: 完了時に何が真であるべきか
• Verification surface（検証手段）: 成功を証明するテスト・ベンチマーク・成果物
• Constraints（制約）: 作業中に劣化させてはいけないもの
• Boundaries（境界）: 許可するファイル・ツール・リソースの範囲
• Iteration policy（反復方針）: 試行のたびに次のアクションをどう選ぶか
• Blocked stop condition（停止条件）: いつ停止してブロッカーを報告するか

公式のスターター例は「Complete [objective] without stopping until [verifiable end state].（検証可能な終了状態に達するまで止まらずに目的を完遂せよ）」という形です。ポイントは、目的だけでなく終了状態を機械的に判定できる形で書くことです。

悪い例と良い例を比べると違いが明確になります（前述のjdhodges氏の実例より）。

• NG: /goal improve auth（認証まわりを改善して）——何をもって完了か判定できない
• OK: /goal src/authのカバレッジを38%から75%に上げる。編集はsrc/authとテストのみ。npm testが通りカバレッジ閾値を満たしたら停止

同氏は「Codexが自分で証拠に照らして進捗確認できる1行を書けないなら、それは/goalではなくただのプロンプト」と表現しています。日本語圏の実測記事でも、Goal・Context・Constraints・Done when（完了条件）の4要素構造が推奨されており、「/goalの良し悪しは検証コマンドを書けているかでかなり決まる」と結論づけられています（Zenn・Sun*の検証記事）。

なお公式は、向かない用途も明記しています。「無関係な作業の寄せ集めリスト」「単発の編集」「make this better型の検証不能なゴール」は/goalに不向きです。経路は不確実でも終点が明確なタスク——テスト検証つきの大規模リファクタ、ターゲットが定義済みのコード移行、ベンチマーク駆動のチューニングなど——が本来の適用領域です。

Codex /goalの仕組み｜継続ループ・予算・6つのstatus

安全に使うには、内部の動きを知っておくことが役立ちます。GitHubの実装から確認できる仕様は次のとおりです。

継続ループはidle時のみ動く

ゴールの継続ターンはセッションがアイドル状態のときだけ自動起動します。ユーザーの入力が常に優先されるため、作業中に割り込んで指示を出すことは可能です。また、継続ターンがツール呼び出しゼロで終わった場合は自動継続が停止する、無限ループ防止の仕組みも入っています。

トークン予算はソフトストップ

ゴールには任意でtoken_budget（トークン予算・正の整数）を設定できます。予算が尽きるとゴールはbudget_limitedという状態になり、「まとめに入れ」という誘導が注入されます。実行中のターンを強制中断するのではなく、緩やかに着地させる設計です。

statusは6値で管理される

ゴールの内部状態は active / paused / blocked / usage_limited / budget_limited / complete の6値です。Web記事には「5状態」「4状態」と書くものもありますが、GitHubの実装スキーマ上は6値が正です。

モデルは自分を止められない・再開できない

設計として面白いのが権限の非対称性です。モデル（AI側）に与えられているのはゴールの読み取り、ゴールが存在しないときの作成、そして完了マークを付けることだけです。pause・resume・clear・予算の変更はユーザーとランタイムの専権事項で、AIが勝手に自分を再開させることはできません。自律実行の暴走に対する構造的な歯止めと言えます。

トークン暴走の失敗報告と対策｜停止条件と予算で防ぐ

/goalで最も報告が多いトラブルがトークンの大量消費です。Xでは次のような報告が相次いでいます。

• 「一晩で10万行超のPRが生成され、確認したら本人（AI）が無意味と認めて全部消した。週次利用枠の50%を消費した」
• 「起きたら5時間セッションで使用量がすべて消えていた」
• 「数時間走ったのに実際には何も実装されていなかった」

明確な完了ゲートのない/goalは大量のトークンを燃やしやすい、というのが失敗報告に共通する構図です。

一方で、正しく使えたケースの実測データもあります。

成功と失敗を分ける要因は、日本語圏の解説で整理された「失敗3類型」がわかりやすい指針になります（Qiita・森松氏の記事）。

• ①永久実行: 検証コマンドが永久に成功しない条件になっている
• ②無関係ファイルの編集: 触ってよい範囲（スコープ）を定義していない
• ③進捗停滞: ゴールが大きすぎて前に進まない

これらを踏まえた実務上の対策は4つです。

• token_budgetを必ず設定する: 予算枯渇でbudget_limitedに落ち、まとめに入る。事故時の被害を上限で固定できる
• 検証コマンドを先に書く: 「npm testが通る」「ベンチマークがX以下」など、機械判定できる完了ゲートをゴール文に含める
• 途中で/diffを確認する: 長時間走らせる場合も放置しきらず、差分を節目で確認。破壊的変更が必要になりそうなら/goal pauseで止める
• 詰まったらpause→書き直し: 進捗が停滞したら指示を追加するのではなく、/goal pauseで止めてスコープを明確化し、ゴール自体を締め直して再投入する

予算の目安について、Ralphループ（自律ループ実行の設計パターン）の文脈で/goalを解説しているralphableは、小タスク10万〜50万・中規模50万〜200万・大規模200万〜1,000万トークンというレンジを示しています。これは同サイト独自の目安であり公式推奨値ではありませんが、初期値を決める参考にはなります。

私の運用スタンス｜自律実行は「停止条件の設計」がすべて

正直に書くと、私はまだ/goalを本格運用に組み込んでいません。ただ、Codex自体は日常的に使っており（ChatGPT Plusのサブスク枠でcodex exec経由の画像生成を制作フローに組み込んでいます）、Claude Code側では同種の自律運用を毎日回しています。

毎日23時の全リポジトリ自動コミット、1日3回のSNS向け情報配信、5日サイクルのニュースレター予約投稿——いずれも人間が張り付かずに動き続ける仕組みです。

その経験から言えるのは、自律実行で一番事故るのは「停止条件があいまいなまま走らせること」だという点です。私の自動化はすべて「何をもって終わりか」をスクリプト側で固定しています。Xで報告されている「一晩で週次枠50%消費」は、停止条件と予算を設定しないまま走らせた場合の典型例と見られ、実感としても納得できる失敗です。

ひとりで会社を回す立場では、「放置できる作業を切り出せるか」が自律エージェント活用の分水嶺になります。検証コマンドで機械判定できるタスクだけを任せる——この原則は/goalでもClaude Codeの自動化でも変わりません。公式の6要素は、その切り出しができているかのチェックリストとしてそのまま使えます。

まとめ｜Codex /goalの使い方チェックリスト

本記事の要点を整理します。

• 有効化はCodex CLI 0.128.0以降で、config.tomlに[features] goals = trueを追記、またはcodex features enable goalsを実行
• サブコマンドは5つだけ。/goal budgetや/goal statusは存在しない（状態確認は引数なしの/goal）
• ゴール文は公式6要素（成果・検証手段・制約・境界・反復方針・停止条件）を意識し、機械判定できる完了ゲートを必ず含める
• 継続ループはidle時のみ動き、モデルは自分を止められない非対称設計。token_budgetはソフトストップとして機能する
• 失敗3類型（永久実行・無関係ファイル編集・進捗停滞）は、予算設定・検証コマンド・/diff確認・pause→書き直しで防ぐ

/goalは「AIに仕事を任せる」を一段深くする機能ですが、任せ方の設計を省くとトークンだけが溶けていきます。まずは読み取り専用の調査タスクや、テストで完了判定できる小さなリファクタから試し、停止条件を書く感覚を掴むのが安全な始め方です。私たちも中小企業の実務にどう組み込めるか、引き続き検証を続けていきます。