Codex /goal vs Claude Code /goal:長いタスクを完了条件まで自動で進める

Codex CLI と Claude Code の /goal コマンドを比較する。どちらも長いタスクと完了条件を扱うが、利用状態、有効化方法、評価の仕組み、向いている場面には違いがある。

/goal は、AI コーディングツールにおける重要なコマンドになりつつあります。

これは「モデルにもう少しコードを書かせる」ためのものではありません。より実用的な問題、つまりタスクに明確な完了条件があるとき、毎ターン止まってユーザーの「続けて」を待つのではなく、Agent が条件を満たすまで進み続けられるか、という問題を扱います。

Codex CLI はすでに公式ドキュメントで実験的な /goal を追加しています。Claude Code も独自の /goal ドキュメントを公開し、複数ターンにまたがって作業を続けられる自動化機能として説明しています。名前は同じですが、プロダクトとしての方向性は完全には同じではありません。

/goal は何を解決するのか

通常の AI コーディング対話は、だいたい「一問一答」です。

  1. ユーザーがタスクを出す。
  2. Agent が分析し、コードを変更し、テストを実行する。
  3. Agent が結果を報告する。
  4. ユーザーが次の行動を決める。

この流れは短いタスクには向いています。しかし移行、リファクタリング、テスト修正、issue backlog の整理になると、かなり細切れになります。Agent は少しだけ進めて、また「続けて」と入力されるのを待つことがあります。

/goal の考え方は、タスクを「次に何をするか」ではなく「最終的にどんな状態なら完了か」に変えることです。たとえば:

1
/goal 完成登录模块迁移,所有 auth 测试通过,lint 无报错

この種の目標は長いタスクに向いています。テストが通る、ビルドが成功する、ファイル分割が終わる、キューが空になる、受け入れ条件を満たす、といった明確な終点があるからです。

Codex の /goal:実験機能で、現在のスレッドに紐づく

OpenAI の Codex CLI ドキュメントでは、/goal は実験機能として扱われています。デフォルトの安定機能ではなく、先に features.goals を有効にする必要があります。

有効化する方法は 2 つあります。

1
/experimental

または config.toml に追加します。

1
2
[features]
goals = true

有効化後は、次のように使えます。

1
/goal Finish the migration and keep tests green

よく使うコマンドは次の通りです。

1
2
3
4
/goal
/goal pause
/goal resume
/goal clear

OpenAI のドキュメントによると、Codex は goal を現在の active thread に付与し、より大きなタスクの進行中にその目標を追跡します。

ここで重要なのは、Codex /goal に対する公式ドキュメントの表現がかなり抑制的であることです。「長いタスクに実験的な目標を設定する」「現在のスレッドに目標を付与する」と説明していますが、Claude Code のドキュメントのように、各ターンの終了後に独立した evaluator が自動判定して次のターンへ進む、という説明まではしていません。そのため現時点では、Codex /goal は完全に安定した無人実行モードではなく、実験中の長期タスク向け目標メカニズムとして見るのがよさそうです。

Claude Code の /goal:完了条件で駆動する複数ターン実行

Claude Code の /goal ドキュメントはより明確です。ユーザーが completion condition を設定すると、Claude はその条件が満たされるまで複数ターンにわたって作業を続けます。

例:

1
/goal all tests in test/auth pass and the lint step is clean

Claude Code の仕組みは、おおまかに次のようなものです。

  • 現在の turn が終わっても、すぐに制御をユーザーへ戻さない。
  • 小さく高速なモデルが、目標条件がすでに満たされたかを確認する。
  • 満たされていなければ、Claude が自動で次のターンを開始する。
  • 満たされていれば、goal は自動で解除され、transcript に完了状態が記録される。

つまり Claude Code の /goal は、「完了条件を満たすまで自動で続ける」機能に近いものです。単に会話へ目標を貼り付けるだけではなく、「次のターンへ進むかどうか」を独立した評価ステップに任せています。

Claude Code では、状態を直接確認することもできます。

1
/goal

状態には、目標条件、実行時間、評価済み turn 数、token 消費量、evaluator が最後に出した理由が表示されます。

途中で止めたい場合は、次を使います。

1
/goal clear

stopoffresetnonecancel も解除用の別名として使えます。目標を有効にした後でセッションが中断された場合でも、--resume--continue で再開すると、active な goal を復元できます。ただし、経過時間、turn 数、token の基準値は再計算されます。

最大の違い

Codex と Claude Code はどちらも、AI コーディングを「単発の回答」から「長いタスクの実行」へ押し出しています。ただし /goal の位置づけには違いがあります。

比較項目 Codex CLI /goal Claude Code /goal
状態 experimental 公式ドキュメントで単独ページとして説明
有効化 features.goals を有効化する必要がある 信頼済み workspace で直接利用可能
目標のスコープ 現在の active thread 現在の session
主な操作 set / view / pause / resume / clear set / view / clear
自動判定 ドキュメントは目標の付与と追跡を強調 各ターン後に evaluator が判定すると明記
自動継続 公式表現は控えめ 条件未達なら自動で次のターンへ進む
向いている場面 Codex の長いタスクで目標コンテキストを維持したい場合 完了条件に向けて Claude Code に継続実行させたい場合

簡単に言えば、Codex の /goal は「現在のスレッドに実験的な長期目標を付ける」ものに近いです。Claude Code の /goal は「現在のセッションに検証可能な停止条件を設定し、満たされるまで自動で進める」ものに近いです。

よい /goal の書き方

どちらのツールでも、/goal は曖昧な願望を書く場所ではありません。

あまりよくない例:

1
/goal 把项目优化一下

よりよい例:

1
/goal 将 payment 模块迁移到新 API,npm test -- payment 退出码为 0,git diff 只包含 payment 相关文件

よい目標には通常、次の 3 つが含まれます。

  1. 明確な完了状態。
  2. 実行可能な検証方法。
  3. 守るべき境界。

目標が大きい場合は、停止条件も加えるべきです。

1
/goal 修复 eslint 报错,npm run lint 退出码为 0;如果超过 20 轮仍未完成,停止并总结剩余问题

これは重要です。/goal が強力になるほど、境界が必要になります。そうしないと Agent は「完了」を追い求めて、過剰にファイルを変更したり、長く走りすぎたり、token を使いすぎたり、本来なら質問すべき問題をそのまま進めてしまう可能性があります。

/goal が向いている場面

向いているもの:

  • テスト修正:指定したテストが通るまで。
  • コード移行:すべての呼び出し箇所を変更し、コンパイルが成功するまで。
  • 一括整理:特定の lint や型エラーがゼロになるまで。
  • ドキュメント補完:指定したすべてのモジュールに説明が付くまで。
  • issue キュー処理:特定タグの issue が処理済み、または明確に分類されるまで。

向いていないもの:

  • 要件自体がまだ曖昧。
  • 頻繁なプロダクト判断が必要。
  • 高リスクな削除、データ移行、権限変更を含む。
  • 受け入れ条件が主観でしか判断できない。
  • 大量の無関係なモジュールをまたぐ。

実用的な基準は、「どのコマンドを実行し、どんな結果を確認し、どのファイルに触れてはいけないか」を書けるなら /goal に向いている、ということです。「もっとよくして」としか書けないなら、通常の対話、計画モード、人間のレビューを使うほうが安全です。

AI コーディングツールへの影響

/goal は明確な方向性を示しています。AI コーディングツールは「対話型アシスタント」から「継続実行できる作業単位」へ移りつつあります。

以前は、Agent にタスクを任せるとき、ユーザーが近くで見守る必要がありました。詰まったら促し、テストが終わったら続行させ、エラーが出たらまた命令する。/goal はこのやり取りを完了条件に圧縮し、次のターンで何をするかを Agent 自身に決めさせます。

ただし、これはユーザー側への要求も高めます。これからの prompt はタスクを説明するだけでなく、受け入れ条件、検証コマンド、変更範囲、停止ルールも書く必要があります。言い換えると、ユーザーの仕事は「続けてと促す」ことから「何をもって完了とするかを定義する」ことへ移ります。

Codex と Claude Code が /goal に到達したということは、長いタスクを扱う Agent が、もはやバックグラウンドタスクやクラウドキューだけのものではないということです。ターミナル上のローカルなコーディングツールにも、より強い自律的な進行能力が求められ始めています。

まとめ

Codex CLI と Claude Code はどちらも /goal を持っていますが、現時点では同じ機能として単純に扱わないほうがよいです。

Codex の /goal はまだ実験機能で、features.goals を有効にする必要があり、現在の Codex スレッドで長期目標を維持する仕組みとして見るのが自然です。Claude Code の /goal は、「完了条件」と「自動継続」をより明確に結びつけ、独立した evaluator によって続行可否を判断します。

日常開発では、この種のコマンドは明確な受け入れ基準を持つエンジニアリングタスクに向いています。要件判断やコードレビューを置き換えるものではありませんが、長いタスクにありがちな「続けて」「もう一度実行して」「テストが通るまで直して」という繰り返しを減らせます。

本当に身につけるべきなのは、コマンドそのものではありません。タスクを、明確で、検証可能で、停止できる目標として書く力です。

参考資料

记录并分享
Hugo で構築されています。
テーマ StackJimmy によって設計されています。