Claude Code v2.1.139 で追加された `/goal` コマンド 〜/loop・Stop hook・Ralph Wiggumとの使い分けを整理〜
はじめに
Claude Code v2.1.139で/goalというコマンドが追加されました。
Claudeが1ターン作業するたびに、別のモデル（Haiku）が「条件は満たされた？」かを自動で判定してくれます。OKなら止まる、NGならまた動く、を条件が満たされるまで繰り返してくれる仕組みです。
これまでClaude Codeで「テストが通るまで直し続けてほしい」を実現するには、自分でプロンプトを送り続けるか、/loop やStop hook等を駆使する必要がありました。/goalはその手間を解決する新しい手法です。
今回はこの/goalコマンドの仕様を整理しながら、/loop・Stop hook・Ralph Wiggumとの使い分けもまとめてみます。
4つの自律実行アプローチを整理する
Claude Code には「自分でプロンプトを送らずにClaudeを動かし続ける」方法が、公式・非公式合わせて4つあります。
/goal（v2.1.139〜）
設定した完了条件を、ターン終了のたびにHaiku（小型モデル）が判定します。条件成立でそのまま自動停止します。
/loop
時間間隔を指定して同じプロンプトを繰り返す公式機能です。「5分おきにPRをチェックして」のような定期タスクに使います。
Stop hook
ターン終了時に任意のスクリプトやプロンプトを走らせて、継続・停止を自分で判断させる仕組みです。/goal はこの Stop hook をセッションスコープで使いやすくラップしたものとして実装されています。
Ralph Wiggum（サードパーティ製プラグイン）
Geoffrey Huntley 氏が開発したプラグインで、Claudeが止まろうとしても強制的に続行させるループ機構を持ちます。完了条件の判定はなく、人間が止めるまで動き続けます。トークン消費が非常に多く、すぐにRate Limitに到達しやすいという報告を確認しています。
| アプローチ | 次のターンが始まるタイミング | 止まるタイミング | 向いているケース |
|---|---|---|---|
/goal |
前のターンが終わったら即 | 設定した条件をHaikuが「OK」と判定したとき | テスト通過・ビルド成功など検証可能な完了状態がある |
/loop |
設定した時間間隔が経過したら | 自分が止めるか、Claudeが完了と判断したとき | 定期的にチェックしたい・間隔を空けて繰り返したい |
| Stop hook | 前のターンが終わったら即 | 自分のスクリプトやプロンプトが判断したとき | カスタムロジックで止まる条件を制御したい |
| Ralph Wiggum | 前のターンが終わったら即 | 人間が止めるまで止まらない | とにかく動かし続けたい・完了条件が定義しにくい |
完了条件が明確に定義できるタスクには /goal を、条件を決めにくいが動かし続けたい場合は Ralph Wiggum が選択肢になりますが、トークン消費の面では /goal の方が効率的です。評価に Haiku を使うこと・条件成立で即停止することが主な理由で、詳細は後述の評価にかかるコストは？で整理しています。
/goalの基本的な使い方
設定する
/goal [完了条件]
例えば、テストが全件通るまで直し続けてほしい場合はこう書きます。
/goal test/auth のテストがすべてパスし、lintがcleanであること
このように入力すると、Claudeは条件を達成しようと動き始めます。追加でプロンプトを送る必要はありません。画面上に ◎ /goal active のインジケーターが表示され、経過時間・ターン数・トークン消費量が確認できます。
状況を確認する
引数なしで/goalを実行すると、現在のステータスが表示されます。
/goal
- 条件の内容
- 経過時間とターン数
- 評価器（Haiku）の最新判定理由
最後の「判定理由」がなかなか便利で、「まだ2件のテストが失敗しています」などClaudeの現状認識が一文で見えます。
止める
/goal clear
stop/off/cancelもエイリアスとして使えます。
効果的な完了条件の書き方
公式ドキュメントでも強調されているのですが、評価器（Haiku）はコマンドを自分で実行するのではなく、会話のトランスクリプトを読んで判断します。そのため、「Claudeが作業の証跡を会話に残す形」で条件を書く必要があります。
/goal test/authのテストが全件passすること。他のテストファイルは変更しないこと。
npm testの出力がトランスクリプトに残るので、テスト結果の判定はできます。一方「ファイルがきれいになっているか」のような、コマンド出力が会話に表れない状態は判定が難しいです。「最後に git statusを実行して確認すること」のように確認コマンドを条件に含めておくと確実です。
公式ドキュメントによると、効果的な条件には次の3要素が含まれることが多いとされています。
- 測定可能な終了状態：テスト結果・ビルド終了コード・空のキューなど
- 確認方法の明示：「
npm testが0で終了する」「git statusがクリーン」など - 変えてはいけない制約：「他のテストファイルは変更しない」など
条件の上限は4,000文字まで指定できるようです。
ループの上限を設けるには
/goal test/authが全件passすること、または20ターン経過したら停止すること
「または〇〇ターン後に止まる」という一文を条件に足すだけで、終わらないループのリスクを防げます。長い作業を任せるときは入れておくと安心です。
/goalと/loop・Stop hook・Ralph Wiggumの使い分け詳細
/goal が向いている場面
- テストを全件通す、ビルドを成功させる、ファイル数を一定以下にするなど、判定できる終了状態があるとき
- 何ターンかかるか分からないが、終わったら自動で止まってほしいとき
/loop が向いている場面
- 「5分おきに進捗を報告して」のような時間間隔ベースの繰り返し
- ポーリングや定期チェック
Stop hook が向いている場面
- 「特定のファイルが存在したら止まる」など、スクリプトで制御したいカスタムロジックがある場合
- より細かく制御したい場合は
/goalのラップ元である Stop hook を直接書く選択肢もあります
Ralph Wiggum が向いている場面
完了条件が定義しにくいタスクや、とにかく止めずに動かし続けたい場面に使われてきたプラグインです。ただし完了判定の仕組みがないため、無駄なターンが積み重なりやすく、すぐにRate Limitに到達するという報告を確認しています。/goal で完了条件を定義できるタスクであれば、/goal を使う方がトークン効率の面でも有利です。
評価にかかるコストは？
/goalの評価器は Haiku（小型・高速モデル）で動きます。判定するのは「Yes/No + 一言理由」だけなので、公式ドキュメントにも「メインのターン消費と比較して無視できるレベル」と明記されています。
Ralph Wiggum がメインモデルで全ターンを走らせ続けるのと比べると、/goalは評価コストが安い上に、条件が満たされた時点で止まるため、余分なターンが発生しません。
まとめ
/goalは完了条件を設定することで、Claude に自律的に作業を続けさせる仕組みです。ポイントをまとめると：
- 評価器（Haiku）は会話のトランスクリプトを読んで条件判定するため、Claudeに確認コマンドを実行させる形で条件を書く
- ターン上限を条件に含めておくと予期しない長時間実行を防げる
/loopは時間間隔ベース、Stop hook はカスタムロジックが必要な場合、Ralph Wiggum は完了条件が定義しにくい場合の選択肢- トークン効率では
/goalが最も優れている
おわり！
