Claude CodeとCodex両方に存在するとんでも機能 /goal に違いはあるのか

シンジです。AIコーディングエージェントには数多くのスラッシュコマンドがありますが、その中でも「完了条件を一度伝えるだけで、達成までエージェントが自律的に走り続ける」/goal は頭ひとつ抜けた“とんでも機能”です。しかもこの /goal、Claude Code にも Codex にも同名で存在します。この2つは明確に違う動作をするので、今回はその解説です。

まずスラッシュコマンドの世界から

Claude Code も Codex CLI も、プロンプト（コーディング指示）とは別に、セッションそのものを操作する「スラッシュコマンド」を多数備えています。プロンプトが「このコードをリファクタして」という作業依頼なら、スラッシュコマンドは「会話履歴を圧縮する」「使用量を見る」「リモートセッションを開始する」といったセッションの制御に使います。

代表的なものを並べるとイメージが掴めます。

この一覧の最後、両者がそろって持っている /goal が本記事の主役です。

/goal の共通コンセプト

/goal を一言でいうと、「keep going」を人間が連打する作業を消す機能です。

Claude Code でも Codex でも、複雑なタスク（モジュール移行、テスト全緑化、ファイル分割、Issue 消化など）を投げると、エージェントは1ターン分だけ動いて制御を返してきます。そこで人間が「続けて」と打ち、また1ターン、また「続けて」……を延々と繰り返すことになります。

/goal はここを変えます。検証可能な完了条件を一度だけ宣言すれば、エージェントは条件が満たされるまでターンをまたいで自律的に走り続ける。両ベンダーが2026年春、数か月のうちに相次いで同じ発想の機能を実装しました。発想は同じですが、中身の作りは明確に違います。順に見ていきます。

Claude Code の /goal

目的

単一セッションの中で、明確な「完了の合図」が定義できるまとまった作業を、人間の介入なしに最後まで走らせること。

使い方

Claude Code の /goal は v2.1.139 で追加されました。条件を引数として渡すだけです。

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

• 目標をセットした瞬間に1ターン目が走り始めます（別途プロンプトを送る必要はありません）。
• 実行中は ◎ /goal active のインジケータで経過時間が表示されます。
• /goal（引数なし）で、消費ターン数・トークン・evaluator の直近の判定理由を確認できます。
• /goal clear（stop off reset none cancel も別名）で達成前に中止できます。
• ヘッドレス実行も可能です。

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

仕組み（ここが重要）

/goal は セッションスコープの prompt-based Stop hook のラッパーです。各ターンが終わるたびに、完了条件とそれまでの会話が「configured small fast model（既定では Haiku）」に送られ、yes/no と短い理由が返ります。

• 「no」なら理由を次ターンの指針として注入し、Claude が作業を続行。
• 「yes」なら目標を自動クリアし、達成エントリを transcript に記録。
• evaluator はツールを呼ばない。つまり Claude が会話上に既に出力した内容（テスト結果など）だけで判定します。
• 評価トークンは small fast model 側に課金され、メインターンの消費に比べれば通常はごくわずかです。
• 動作にはワークスペースの trust dialog の承認が必要で、disableAllHooks（どの設定レベルでも）または管理設定の allowManagedHooksOnly が設定されていると利用できません（hooks 基盤の一部のため）。
• セッション終了時にアクティブだった目標は --resume / --continue で復元されますが、ターン数・タイマー・トークン基準値はリセットされます。

ベストプラクティス

• 完了条件は「Claude の出力で証明できるもの」にする。evaluator はファイルやコマンドを独自に叩かないため、「test/auth の全テストが通る」は Claude がテストを実行して結果が transcript に出るので機能します。
• 条件には測定可能な終端状態（テスト結果・終了コード・ファイル数・空のキュー）と、その証明方法（npm test が 0 で終了 等）を含める。条件は最大4,000文字。
• 走りすぎを防ぐには条件内に上限節を入れる（例：or stop after 20 turns）。ただしこれは機械的停止ではなく、モデルが会話から判断する点に注意。
• auto mode と併用すると、ターン内のツール承認も自動化され、無人で各ターンが回ります。
• 「達成」を鵜呑みにしない。evaluator は transcript しか読まないので、壊れた作業の自信ありげな要約を「OK」と誤判定し得ます。人間がPRレビューと同じ要領で結果を監査してください。開きっぱなしの目標を一晩放置するのは避けるべきです。

Codex の /goal

目的

スレッドに紐づく永続的な目標として、数時間〜数日に及ぶ長時間タスクを、中断・再開をまたいで継続させること。

使い方

Codex の /goal（Goal mode）は、2026年5月21日リリースの Codex CLI 0.133.0 で既定有効になり、experimental ではなくなりました。それ以前の版では config.toml の [features] goals = true、または codex features enable goals での有効化が必要でした。

/goal Finish the migration and keep tests green

• /goal（引数なし）で現在の目標を表示。
• 長い指示はファイルに入れて目標から参照できます。
• ライフサイクルを明示的に操作できます。

/goal pause     # いったん止める
/goal resume    # 再開する
/goal clear     # 破棄する

アプリ版では目標がアクティブな間、composer の上に進捗が表示され、ボタンから pause / resume / 目標テキストの編集 / clear が可能です。目標の実行中もフォローアップメッセージで Codex を誘導し続けられます。

仕組み（ここが重要）

Codex の目標は スレッドに紐づく first-class オブジェクトとして永続化されます。一時的なプロンプトではなく、ターン・compaction・/clear をまたいで生き残るスレッド状態です。

• モデルが見るのは create_goal / update_goal（complete または blocked をマーク）/ get_goal の3ツール。モデル自身は pause/resume できず、それらはユーザーまたはシステムが制御します。
• モデルは「目標が実際に達成され、残作業がない場合にのみ」complete とするよう指示されています。予算がほぼ尽きた、作業を止めたい、という理由だけで complete にしてはいけません。
• ランタイムがターンのライフサイクルにフックし、トークンと実時間の増分を会計。中断時に自動 pause、スレッド再開時に自動再アクティブ化し、予算超過時にはモデルの応答ストリームに budget-limit のステアリングを注入します。
• TUI のステータスバーに目標状態が表示されます。公式実装（footer.rs の GoalStatusIndicator）の表示文字列は次のとおりです。

ベストプラクティス

• 数時間〜数日級の長丁場タスクに向く。途中で別作業を挟みたいときは /goal pause → /goal resume で制御する。
• トークン予算を設定すると、超過時に機械的に budget-limited 状態へ落ちるため、暴走コストを抑えられる。
• Plan mode と Goals を同時に有効にすると、目標が active 表示でも自律継続が始まらず「固まったように見える」既知の挙動があるため、長時間タスクは Plan mode を外して走らせる。
• Codex 側も、モデルの自己 complete 判定を鵜呑みにせず、達成内容は人間が監査する。

両者の /goal の違い

結論から言うと、発想は同じでも実装思想がはっきり違います。一番の差は「状態をどこまで作り込んでいるか」です。

ざっくり整理すると：

• Claude Code = Stop hook ベースの「完了条件ループ」。軽量で、別モデル（Haiku）による客観判定が組み込みになっているのが特徴。
• Codex = スレッド永続型の「Goal mode」。pause/resume/edit といったライフサイクル管理と、トークン予算による機械的停止を備えた、長時間タスク管理モード。

どんな目的なら、どっちで /goal を使うべきか

違いがわかったところで、実務での使い分けを具体例で挙げます。

Claude Code の /goal が向くケース

「単一セッションで一気に終わらせたい、完了条件が transcript で証明できるタスク」

• 例1：test/auth のテストを全部緑にする。→ /goal all tests in test/auth pass and lint is clean。Claude がテストを実行し、結果が会話に出るので Haiku が正しく判定できる。
• 例2：今週マージされた全PRが CHANGELOG に載っているか。→ ヘッドレスで claude -p "/goal ..." を回し、CIの一部として使う。
• 例3：レビュー観点を変えたいとき。判定役が actor と別モデル（Haiku）なので、「書いた本人が見落とすもの」を拾いやすい。Anthropic スタックで完結させたい場合に素直。

Codex の /goal が向くケース

「数時間〜数日かかる、途中で止めたり再開したりしたい長丁場のタスク」

• 例1：大規模な API クライアント移行を半日かけて進める。→ 途中で一時停止したいときは /goal pause、続けるときは /goal resume。スレッドに状態が残るので、/clear や compaction をまたいでも目標が生き続ける。
• 例2：コストを機械的に縛りたい。→ token_budget を設定し、超過したら budget-limited で自動的に止める。「気づいたら大量トークン消費」を構造的に防ぐ。
• 例3：日をまたぐ移行作業。→ スレッドを resume すれば目標が復元され、長期の objective を保持したまま再開できる。

両者に共通する鉄則

どちらの /goal も、完了判定は基本的に「エージェントが会話に出した証跡」や「モデルの自己申告」に依存します。「達成」と出ても、それは人間の最終確認の代わりにはなりません。重要な変更ほど、PRレビューと同じ目線で結果を必ず自分で監査してください。

まとめ

• /goal は Claude Code・Codex の両方に存在し、発想（完了条件を宣言して自律実行）は共通。
• ただし実装思想は別物。Claude Code は Stop hook ベースの軽量な完了条件ループ、Codex はスレッド永続型で pause/resume/予算管理を備えた Goal mode。
• 使い分けの軸はシンプル。単一セッションで一気に終わらせる検証可能タスクなら Claude Code、中断・再開・トークン管理が要る長丁場なら Codex。
• そして両方に共通する最重要事項として、達成判定は人間の監査を置き換えない。

と、ここまで見るとCodexすごいなと思いますが、実務的にシンジはあまり/goal は使ってません。AIと壁打ちしながら作り込むことが多いのです。

一方で、目的が明確な場合は使えます。ご利用は計画的に。

出典（すべて一次情報で確認）

• Claude Code /goal の挙動：Anthropic 公式ドキュメント code.claude.com/docs/en/goal
• /goal の追加バージョン（v2.1.139）：Anthropic 公式 CHANGELOG（anthropics/claude-code）
• Codex Goal mode の experimental 解除・既定有効化：OpenAI 公式 GitHub リリース 0.133.0（PR #23732「Make goals feature on by default and no longer experimental」、2026-05-21）および OpenAI 公式 changelog
• Codex の目標を専用ストレージへ永続化（dedicated goal DB）：OpenAI 公式 GitHub PR #23300
• Codex の TUI 状態表示文字列：OpenAI 公式リポジトリ実装 codex-rs/tui/src/bottom_pane/footer.rs の GoalStatusIndicator
• Codex のモデル向けツール仕様：OpenAI 公式リポジトリ実装 codex-rs/ext/goal/src/spec.rs（ツール名・スキーマ定義）および codex-rs/core/src/tools/handlers/goal/（create_goal.rs / get_goal.rs / update_goal.rs・goal_spec.rs）