Codex /goal と Claude Code /goal は、どちらも「目標に向かって作業を続ける」ための仕組みですが、同じものとして扱うと危険です。日本語でこの比較を探す読者が本当に知りたいのは、どちらの名前が強いかではなく、長いコーディングタスクをどのループに任せるべきか、そして任せる前に何を決めておくべきかです。
Codex のスレッド、CLI、またはローカル作業の中で、対象リポジトリと変更範囲が小さく、テストや typecheck や diff で完了を証明できるなら Codex /goal を候補にできます。Claude Code の会話内で、信頼済みワークスペース、権限モード、会話に出ている証拠が重要なら Claude Code /goal が合います。判断が揺れる作業、UI の好み、production data、秘密情報、停止条件のない作業は、どちらの goal loop にも渡さないほうが安全です。
まず四つの所有者に分ける
| ルート | 使う場面 | 開始前の証拠 | 停止ルール |
|---|---|---|---|
Codex /goal | Codex 上の bounded task で、reviewable diff を出すことが目的。 | test、lint、typecheck、snapshot、diff inspection で完了を示せる。 | 目標が変わる、diff が広がる、検証が連続失敗するなら pause/clear。 |
Claude Code /goal | Claude Code の local session 内で、permission mode と会話証拠が重要。 | evaluator が tool output や file change を見て条件を判断できる。 | completion condition が曖昧になったら clear か置き換え。 |
| 通常の対話 | 要件、設計、UI、調査方針が途中で変わる。 | 発見のたびに人間の判断が必要。 | agent を plan/chat mode に置き、自動ループさせない。 |
| CI / scheduler | 定期実行、外部トリガー、ログ、retry、通知が必要。 | workflow や cron が自身の status と retry policy を持つ。 | 時間と繰り返しは automation が所有する。 |
この表の目的は、勝者を決めることではありません。/goal は、完了条件が測れるときだけ役に立ちます。「いい感じに直す」「全体を改善する」「原因を探して直す」のような依頼は、agent にとっても reviewer にとっても終点が曖昧です。終点が曖昧なまま長く走らせると、作業量だけが増え、判断の責任が見えなくなります。
日本語の解説では、Codex の goal 永続化、Claude Code の継続実行、AI エージェントの自律性、CLI 比較が混ざりやすいです。実務では、goal という言葉を機能名ではなく作業契約として扱うほうが安全です。目標は完了条件、権限は行動の可否、テストは証明、レビューは受け入れ判断、CI は繰り返しの所有者です。
/goal が変えるもの
OpenAI の Codex slash command ドキュメントでは、Codex /goal は experimental command として扱われ、goals feature flag に紐づいています。確認したコマンドは /goal <objective>、/goal、/goal pause、/goal resume、/goal clear です。このため、すべての Codex 入口で同じ安定仕様だと書くべきではありません。
Claude Code の /goal は completion condition を中心に説明されています。Claude Code は複数ターンで作業し、各ターンの後に evaluator が会話内の証拠から条件が満たされたかを判断します。つまり、よい goal は evaluator が見て判断できる形にする必要があります。会話に出ていない証拠や、実行していないテストを前提にしてはいけません。
共通点は「作業を続けるための目標」です。違いは、その作業がどの surface で動くかです。Codex は app、IDE、CLI、cloud task の境界を持ちます。Claude Code は session、trusted workspace、permission mode、tool evidence の境界を持ちます。どちらを使うかは、モデルの好みよりも、この境界にタスクが合うかで決めるべきです。
仕組みの違いを五つに分ける
| 判断点 | Codex /goal | Claude Code /goal | 実務上の意味 |
|---|---|---|---|
| 有効化 | 確認時点では experimental で goals feature flag が必要。 | 対応バージョンと trusted workspace が必要。 | 利用可否は現在の owner source で確認する。 |
| 作業面 | app、IDE、CLI、cloud で repo boundary が変わる。 | Claude Code session と permission mode が中心。 | goal は別 route の権限を仮定できない。 |
| 完了証拠 | proof command または reviewable diff が強い。 | evaluator は session に出た証拠を見る。 | 曖昧な証拠は誤完了を生む。 |
| 権限 | sandbox や command approval を変えない。 | permission modes は別管理。 | loop は authorization ではない。 |
| 使用量 | 長時間作業は allowance を多く使う可能性がある。 | subscription/API key route も別問題。 | 開始前に active route を確認する。 |
特に Claude Code では、plan mode、default approvals、accept edits、auto mode などの違いが大きいです。/goal はそれらを選んでくれません。Codex でも、branch、setup command、sandbox、review path を人間が確認する必要があります。goal loop は境界を守る機能ではなく、書かれた境界を長く実行する機能です。
開始前のゴール契約
| 項目 | 十分に具体的 | 曖昧すぎる |
|---|---|---|
| 終了状態 | 「packages/billing の date parsing regression を直し、該当テストが通る。」 | 「billing をきれいにする。」 |
| 検証コマンド | 「pnpm test packages/billing -- date が通る。」 | 「動くことを確認する。」 |
| 範囲 | 「parser、fixture、regression test だけを触る。」 | 「必要なら何でも直す。」 |
| 権限 | 「通常編集は可、破壊的 shell command は確認。」 | 「全部任せる。」 |
| 使用量 | 「検証失敗が二回続いたら停止して報告。」 | 「できるまで続ける。」 |
| 停止条件 | 「原因が date parsing 外なら止める。」 | 「うまく判断する。」 |
よい goal は prompt ではなく acceptance contract に近いです。短くても、終点、証拠、範囲、停止条件を含みます。
hljs textGoal: In Codex CLI, update only checkout discount tests and the rounding helper so pnpm test packages/checkout -- discount passes. Stop if payment provider code must change.
hljs textGoal: In Claude Code, fix heading anchors in docs/api/authentication.md; the goal is complete when docs lint passes. Ask before editing outside docs/api/.
この二つは、reviewer が「何が成功で、何が越境か」を見られます。逆に、範囲が広く、証明がなく、停止条件がない goal は、agent の能力ではなく人間側の設計不足です。
/goal が置き換えないもの
/goal は権限承認を置き換えません。Claude Code の permission mode が確認を求めるなら、goal があるからといって自動承認にはなりません。Codex の sandbox や repo access も goal で広がりません。
/goal はテストを置き換えません。「テストが通る」を completion condition に入れることはできますが、実際の test run が必要です。狭いテストだけが通っても、関係ない production risk は残ります。
/goal はコードレビューを置き換えません。goal loop で出た diff は、人間が読む必要があります。変更ファイル、理由、検証コマンド、スコープ外の編集を確認し、契約外の修正は戻すべきです。
/goal は予算管理ではありません。明確な goal は無駄なターンを減らすことがありますが、長い work loop は消費を増やすこともあります。plan、API key、cloud route、subscription allocation は現在の画面で確認してください。
/goal は秘密情報や本番データを守りません。顧客データ、credential、billing migration、不可逆な production action は runbook、backup、staging、approval chain の中で扱うべきです。
通常対話や CI がよい場面
通常対話がよいのは、発見するたびに目標が変わる作業です。設計探索、UI 改善、incident triage、migration planning は、人間が途中で判断を更新する必要があります。goal loop は、その判断点を通り過ぎてしまうことがあります。
CI や scheduler がよいのは、繰り返しと時間が本質の作業です。nightly dependency audit、docs check、deployment verification は、agent session ではなく workflow が所有すべきです。coding agent は workflow を作れますが、workflow の代わりにはなりません。
広い agent 選択がまだ決まっていない場合は /ja/posts/codex-vs-claude-code を先に見るほうが自然です。Claude の subscription と API billing の違いは /ja/posts/claude-api-pricing-vs-subscription が別の判断を扱います。ここでは /goal の所有者だけに絞ります。
実務で使える goal パターン
テスト修復
hljs textGoal: Fix auth/session-expiry without changing public API behavior. Complete only when pnpm test auth/session-expiry passes and the diff touches only session expiry code and tests.
失敗範囲、検証コマンド、変更対象が明確なので goal loop に向いています。
境界のあるリファクタ
hljs textGoal: Rename internal legacyToken helper to sessionToken inside packages/auth only. Complete when typecheck passes and no file outside packages/auth changes.
Codex でも Claude Code でも使えますが、どちらが自然かは現在の作業 surface と permission mode で決まります。
ドキュメント整合性
hljs textGoal: Update three OAuth setup pages so each includes the same redirect URI warning and docs lint passes. Stop if product behavior must change.
docs lint と visible checklist があるため、完了を判断できます。
悪い goal：広い改善
hljs textGoal: Make the dashboard better.
これは completion condition ではありません。まず通常対話で問題を列挙し、空状態、keyboard focus、loading error のような小さい goal に分けます。
悪い goal：本番リスク
hljs textGoal: Fix the production billing migration and keep going until it works.
これは runbook、backup、staging、approval の領域です。goal loop に不可逆な operational risk を所有させるべきではありません。
FAQ
Codex /goal と Claude Code /goal は同じ機能ですか？
同じではありません。どちらも completion condition に向かって作業しますが、Codex は experimental slash command と feature flag の文脈で説明され、Claude Code は session 内の completion condition と evaluator evidence の文脈で説明されています。
先に試すならどちらですか？
Codex 内で bounded diff を作り、proof command で確認できるなら Codex /goal。Claude Code 内で local steering と permission mode が重要なら Claude Code /goal。曖昧または危険なら、どちらも使わず通常対話で計画します。
/goal は shell command や edit を承認しますか？
いいえ。goal completion と permission approval は別です。Claude Code の permission mode、Codex の sandbox、repo access、review settings は別途確認します。
/goal はコストを下げますか？
保証できません。明確な goal は無駄を減らすことがありますが、長時間実行は消費を増やすこともあります。active account と route を確認してください。
よい goal に必要なものは何ですか？
測定できる終了状態、検証コマンドまたは review artifact、狭い scope、既知の permission mode、使用量チェック、abort rule です。
CI や scheduler がよいのはいつですか？
繰り返し、時間指定、外部トリガー、ログ、retry、alerting が必要な場合です。agent は workflow を作る役、workflow は loop を所有する役です。
