結論：/goalには作業名ではなく検証可能な終了条件を書く
Claude Codeの/goalは、目的だけを渡して放置する機能ではありません。「何が、どの確認で、どの制約を守って完了したと言えるか」を一文へ固定し、各turnの後に別の評価modelが達成可否を判定する仕組みです。
一つの測定可能な状態、確認command、変更禁止範囲、turnまたは時間の上限を入れ、権限確認と費用監視は別gateとして残します。
読者の具体的な困りごとは、長い移行やtest修正を任せたいのに、途中で止まるか、逆に「できるまで続けて」という曖昧な指示で作業範囲と費用が広がることです。この記事を読むと、goalを設定してよい作業、通常promptへ戻す作業、Stop hookへ移す作業を判断し、達成証拠を残せます。
次の行動：候補作業を一つ選び、「npm testがexit 0、対象外fileは変更しない、20turnで未達なら停止」のように、結果・確認・制約・上限を一行へ書いてください。
/goalの正式な動作と提供条件を確認する
Anthropic公式guideでは、/goal 条件を実行すると条件そのものをdirectiveとして最初のturnが始まり、turn終了ごとに小さく高速なmodelが会話を評価します。未達なら理由を次のturnへ渡して継続し、達成ならgoalを解除します。一sessionでactiveにできるgoalは一つで、新しく設定すると置き換わります。条件は最大4,000文字です。
評価modelはcommandを実行したりfileを独立して読んだりしません。Claudeがtest結果、buildのexit code、件数、差分などを会話へ出した内容だけで判断します。そのため「品質を高くする」のような主観条件ではなく、「認証testが全件passしlintがclean」「未処理labelのissueが0件」のように、作業側が証拠を表示できる条件が必要です。
/goalはpermissionを変更しません。既定modeでは未許可のcommandやwriteに確認が残ります。auto modeと組み合わせるとtool確認を減らせますが、auto modeは一turn内の許可、goalは次turnを始める条件で役割が違います。workspace trustを受け入れ、hook機構が利用可能であることも要件です。disableAllHooksが有効、またはmanaged settingsでallowManagedHooksOnlyが有効な環境では利用できません。
料金面では、main turnの通常利用に加え、各turn後の評価tokenが小さく高速なmodelで計上されます。公式guideはmain turnより通常小さいと説明しますが無料とはしていません。Claude APIでは既定がHaiku系で、第三者providerではproviderの既定modelを確認します。ANTHROPIC_DEFAULT_HAIKU_MODELの変更はgoalだけでなく要約など他のbackground機能にも影響するため、goal専用料金設定だと誤解しません。
/goal・/loop・Stop hookを7軸で比較する
- 開始条件：goalは前turn終了、loopは時間間隔、Stop hookは自作scriptまたはpromptの判定後に次を始めます。
- 終了条件：goalはmodelが一文の条件を評価します。loopは停止操作またはClaudeの完了判断、hookは自社のdeterministic checkも選べます。
- 適用範囲：goalは現在sessionだけです。Stop hookはsettingsのscopeへ保存し、複数sessionへ同じruleを配れます。
- 時刻要件：定刻実行や夜間起動が目的ならgoalではなく、scheduled taskやcloud routineを選びます。
- 証拠：goal evaluatorは会話しか見ません。厳密なexit codeや署名検査を強制したい場合はscript型hookとCIを残します。
- 権限：goalはpermissionを広げません。無人化の前にallow、ask、denyとsandboxを小さく固定します。
- 費用：goalはmain turnと評価turnを重ねます。時間・turn上限、token表示、異常時のclear責任者を決めます。
一回の修正、答えが主観的な設計相談、外部承認待ち、秘密へのaccessが都度必要な作業は通常promptが向きます。大規模migrationのように検証可能な終点があり、途中の小さな失敗を直しながら進む作業はgoal候補です。全projectに同じ停止判定を強制したい場合はStop hook、時刻で再実行したい場合は/loopやscheduled taskへ分けます。
安全に設定して監視する8手順
- 対象を一repository・一migration・一backlogへ絞り、外部承認待ちや本番deployをgoalから外します。
- 完了状態を一つに絞り、test名、build command、残件数、file数など観測可能な値で書きます。
- Claudeが結果を会話へ表示する確認方法を入れます。単に「確認済み」ではなくcommandと期待exitを指定します。
- 変更してはいけないdirectory、生成物、契約、database、network先を条件またはpermissionで固定します。
- 「20turnまたは60分で未達なら原因を報告して停止」のように、継続の上限を条件へ入れます。
/goal 条件を設定し、最初のturnで作業範囲、test、権限askが想定どおりか確認します。- 引継ぎ時は
/goalのstatusで条件、経過、turn、token spend、直近評価理由を確認し、曖昧なら/goal clearします。 - 達成後は実際のtest、git diff、対象外変更、残件0を人間またはCIが再確認し、goal達成表示だけでmergeしません。
sessionを終了してもactive goalは--resumeまたは--continueで復元されます。ただしturn数、timer、token spendの基準は再開時にresetされます。再開を上限回避に使わないよう、開始時刻と累計を外部台帳にも残します。達成済みやclear済みのgoalは復元されません。
導入チェックリストとHOLD条件
- 一つの測定可能な終了状態にした
- 確認commandと期待結果を書いた
- 対象外変更を明記した
- turnまたは時間上限を入れた
- workspace trustを確認した
- Hooksの組織設定を確認した
- permissionとsandboxを固定した
- 評価modelと費用計上先を確認した
- status確認者を決めた
- clear方法を共有した
- resume時のresetを記録する
- 最終CIと人間reviewを残した
HOLDするのは、完了が主観語だけ、評価証拠を会話へ出せない、本番操作を無人承認する、停止上限がない、token予算がない、Hookが組織policyで無効、対象外fileを守れない場合です。長く動いたことを成果とせず、条件の明確さと検証可能性で採否を決めます。
よくある質問と次の行動
/goalを設定すれば必ず完了しますか？
保証ではありません。権限不足、外部待ち、誤った条件、環境故障では未達が続きます。上限とHOLD条件を先に置きます。
非interactiveでも使えますか？
公式guideではclaude -p "/goal ..."に対応します。標準text出力は達成まで何も表示せず停止に見えるため、監視時はstream JSON等の公式optionを確認します。
goalを途中で止めるには？
/goal clearを使います。clearのaliasもありますが、運用手順は一つに統一し、停止理由を台帳へ残します。
正式な設定、評価、費用、要件はClaude Code公式Goal guide、resume時に復元される状態は公式Sessions guide、権限の選び方は公式Permission modesで公開直前にも確認してください。
通常の権限設計はClaude Codeの権限設定、全体へ同じ停止ruleを置く場合はHooksの使い方、継続中の判断記録は監査ログへつなげます。Miraigentの無料診断では、対象、完了条件、確認command、権限、上限、reviewを一枚の運用表へ整理します。