AIツール

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

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

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

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

Codexはdesktop、CLI、IDEで/goalを提供し、現在のリリースではデフォルトで有効です。Claude Codeにも同名コマンドがありますが、製品としての動作は同一ではありません。

/goal は何を解決するのか

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

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

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

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

1

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

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

Codex の /goal：デフォルトで有効、現在のスレッドに紐づく

現在の Codex では features.goals は安定機能で、デフォルトで有効です。/experimental や goals = true の手動設定は不要です。

1

/goal Finish the migration and keep tests green

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

1
2
3
4
5

/goal
/goal edit
/goal pause
/goal resume
/goal clear

Codex は goal を現在の active thread に付与します。目標は空にできず、上限は4,000文字です。安定機能でも、破壊的変更、公開、権限変更、不可逆な移行を無人で安全に実行できるという意味ではありません。

Failed to set goal の切り分け

古い記事では Defender の隔離、キャッシュ破損、実験フラグ不足を原因としていましたが、十分な根拠がなく現在のデフォルト状態とも一致しません。最初に ~/.codex 全体を削除したり、セキュリティソフトを無効化したりしないでください。

  1. Codex desktop、CLI、IDE extensionを更新します。
  2. 新しいスレッドで短い空でない目標を試します。
  3. 4,000文字以内にします。
  4. /goalで確認し、/goal editで変更、必要なら/goal clear後に再設定します。
  5. config.tomlにfeatures.goals = falseが明示されていないか確認します。通常は設定不要です。
  6. IDE extension hostまたはCLIを再起動し、再現する場合はバージョン、利用画面、完全なエラー、最小目標を記録します。

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

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

最大の違い

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

比較項目 Codex CLI /goal Claude Code /goal
状態 安定、デフォルトで有効 公式ドキュメントで単独ページとして説明
有効化 現在のリリースで直接利用可能 信頼済み 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 はデフォルトで有効で、現在の Codex スレッドに長期目標を維持します。Claude Code の /goal は「完了条件」と「自動継続」をより明確に結びつけ、独立した evaluator によって続行可否を判断します。

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

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

参考資料