Claude Code の作業を「テストが全部通るまで」「ドキュメントの全項目が埋まるまで」と条件付きで自走させたい。これまでは /loop で時間間隔ごとに走らせるか、Stop フックを自前で書くしかなかった。2026年5月11日リリースの Claude Code 2.1.139 で追加された /goal コマンドは、その間を埋める3つ目の選択肢だ。
/goal の役割はシンプルで、セッションに1つだけ完了条件を登録し、各ターンの終わりに別モデル(既定では Haiku)が条件を満たしたかを判定する。満たしていなければ Claude が自動で次のターンを始める。満たした瞬間にゴールはクリアされ、入力待ちに戻る。
何ができるのか
公式ドキュメントが挙げる代表的なユースケースは次の4つ。
- 旧 API から新 API への移行を、全コール箇所がコンパイルとテストを通るまで続ける
- 設計ドキュメントの受け入れ条件をすべて満たすまで実装する
- 巨大ファイルを目標サイズに収まるまで分割する
- ラベル付き issue のキューが空になるまで処理し続ける
いずれも「終わり方が明確に決まっている」作業だ。判定モデルはコマンドを実行したりファイルを読んだりはしない。会話に出てきた情報だけを材料に判断するので、条件文の側で「npm test が exit 0 を返す」のように判定材料の示し方まで書いておく必要がある。
使い方
セッション内で完了条件を渡すだけで起動する。条件文は日本語でそのまま書ける。判定モデル(既定では Haiku)は多言語対応していて、英語と同じ精度で yes/no を返す。
| |
条件を渡した瞬間にターンが始まる。別途プロンプトを送る必要はない。実行中は ◎ /goal active インジケーターで経過時間が表示され、ターン数とトークン消費もパネルで追える。
引数なしで /goal を実行すると現在の状態が出る。条件・経過時間・評価済みターン数・トークン消費・直近の評価理由が並ぶ。終わらせたいときは次のとおり。
| |
stop off reset none cancel も clear のエイリアスとして受け付ける。/clear で新しい会話を始めた場合もゴールは消える。
ノンインタラクティブモード(-p)でも動く。
| |
このコマンドはループが完了するまで戻ってこない。途中で止めたければ Ctrl+C で抜ける。
条件の書き方
ドキュメントは「測定可能な終了状態」「判定材料の示し方」「変えてはいけない制約」の3点を条件に含めるよう勧めている。たとえば「test/auth のテストがすべて通る」だけだとモデルの解釈に幅が残るが、「npm test が exit 0 を返し、その出力がトランスクリプトに残っていること」まで書けば判定がぶれにくくなる。
条件は最大4,000文字。ターン数や時間で上限を切りたい場合は条件文に「20ターンで停止」「30分以内」のような制約を入れる。判定モデルが会話の中身からそれを判断する。
/loop・Stop フックとの違い
公式ドキュメントの比較表を見ると、3つの方式は「次のターンが始まる条件」と「停止する条件」で住み分けている。
| 方式 | 次のターンが始まる条件 | 停止する条件 |
|---|---|---|
/goal | 直前のターンが終わったとき | 別モデルが条件達成を確認したとき |
/loop | 時間間隔が経過したとき | ユーザーが止めるか、モデルが終了判断したとき |
| Stop フック | 直前のターンが終わったとき | 自前スクリプトかプロンプトが判断したとき |
/goal と Stop フックはどちらも「ターンの終わり」で動く点が共通している。違いはスコープと書きやすさ。/goal はそのセッションだけ有効な使い捨てショートカットで、コマンド1行で条件を渡せる。Stop フックは設定ファイルに常駐させて全セッションに適用するもので、スクリプトでの厳密な判定や複雑なロジックを書きたいときに向く。
Auto mode との関係も整理されている。Auto mode は1ターン内のツール呼び出しを自動承認するが、新しいターンを始めるわけではない。/goal は各ターン後に別評価器を回して条件をチェックするので、両者は組み合わせて使える。Auto mode が「ツールごとの確認」を消し、/goal が「ターンごとの確認」を消すという棲み分けになる。
評価モデルの仕組み
/goal の正体はセッションスコープのプロンプトベース Stop フックだ。ターンが終わるたびに、条件文とそれまでの会話が 軽量・高速なモデル(small fast model、既定では Haiku)に送られる。返ってくるのは yes/no と短い理由だけ。
- no → 「まだ達成していない理由」をガイダンスとして次のターンに渡し、Claude が作業を続ける
- yes → ゴールをクリアし、トランスクリプトに達成エントリを記録する
判定モデルはツールを呼ばないので、Claude が会話に出していない情報は判断材料にできない。「ファイルの中身を直接見て判定してくれる」というのは誤解で、Claude がテスト結果や git status を会話に出していなければ評価器は何も判断できない。/goal 運用で一番つまずきやすいのがここで、条件文の中に「判定材料の示し方」まで書いておきたい。
評価で消費するトークンは、メインモデルの消費に比べれば誤差レベルとされている。Haiku のような小型モデルが既定値になっているのはこのためだ。
セッションを跨ぐ挙動
達成前にセッションを終了した場合、--resume や --continue で再開するとゴールが復元される。条件は引き継がれるが、ターン数・タイマー・トークン消費の基準値はリセットされる。すでに達成済みか手動でクリアしたゴールは復元されない。
使えない条件
/goal はフックシステムの一部として動くので、ワークスペースで信頼ダイアログを承認していないと起動しない。設定で disableAllHooks が有効になっている場合や、Managed Settings で allowManagedHooksOnly が指定されている場合も使えない。いずれもコマンド側が理由をその場で返すので、原因不明で止まることはない。
同じリリースの周辺機能
/goal と一緒に 2.1.139 で入った機能のうち、ゴール運用と相性のいいものを2つ挙げておく。
- Agent View(Research Preview):
claude agentsで全セッションを一覧表示できるビュー。実行中・ユーザー待ち・完了の状態が並ぶ。/goalを回している複数セッションを横並びで監視するのに向いている - transcript view navigation: トランスクリプトを
{}でユーザープロンプト単位に移動できる。ゴール実行中にどのターンで何が起きたかを後追いするときに有用
どこから使うか
Claude Code 2.1.139 以降であれば追加インストール不要で /goal が使える。claude --version で確認できる。ローカルで 2.1.139 未満なら以下で更新する。
| |
最初の1回は短めの条件で試すといい。「README.md に H2 セクションが5つ以上ある状態にする」のような30秒〜数分で終わる条件なら、評価モデルの判定挙動とインジケーター表示を手軽に確認できる。慣れてきたら「テストが通るまで」「issue キューが空になるまで」のような本格的な長期ゴールに移る、という順序が安全だ。
ノンインタラクティブモードで CI に組み込めば、ナイトリービルドで失敗したテストを翌朝までに直しておく、という運用も可能になる。Auto mode を併用するとツール承認も自動になるので、夜寝る前に claude -p "/goal ..." を仕掛けて朝結果を確認するワークフローが現実的な選択肢になる。
参考
- Keep Claude working toward a goal - Claude Code Docs
- Changelog - Claude Code Docs
- Claude Code v2.1.139: Agent View, Goal Setting, and Enhanced Workflow Control - ClaudeWorld
- Tuesday 12 May — Claude Code 2.1.139
この記事は Claude Opus 4.7 が執筆しました。
