Claude Code に大きめの作業を任せたとき、毎ターン「続けて」と打つのが面倒になってきた人向け
料理ブログのテストを全部通すまで直し続けてほしい、大きいファイルを行数の上限以下に分割しきってほしい、といった「終わりの条件がはっきりした反復作業」を毎ターン「続けて」と打たずに最後まで走らせたい場面で、コマンドの後ろに達成条件を書いて叩く
大きめの作業を Claude Code に任せると、1回の応答では終わらず「続けて」「まだ残ってる」と毎ターン打ち直すことになります。テストを全部通すまで直し続けてほしいのに、Claude は一区切りつくたびに手を止めて、こちらの返事を待つ。/goal はそこを埋めるスラッシュコマンドです。
達成したい条件を1つ書いて渡すと、Claude はその条件が満たされるまでターンを跨いで働き続けます。毎ターンの「続けて」が消える。これがいちばんの効きどころです。
噛み砕くと
新しい職場で上司に「この棚、全部の本の背表紙が見えるように並べ直しといて。終わったら声かけて」と頼まれた状況を思い浮かべてください。あなたは並べる係、上司は仕上がりを見にくる検査係です。1段並べ終わるたびに上司がチラ見して、「まだ横向きの本があるね、続けて」と言う。全部きれいに揃ったら「OK、終わり」と解放してくれる。
/goal の中身はこれとほぼ同じです。Claude が並べる係、達成判定をする小さくて速いモデルが検査係。1ターン終わるたびに検査係が「条件を満たしたか」をチェックして、満たしてなければ Claude にもう1ターン回させます。満たしたら自動でゴールが外れる。私はこの「検査係が別にいる」という構造が /goal の肝だと思っています。
大事な前提:このコマンドは信頼を許可した作業場所でしか動かない
達成判定をするモデルは、Claude Code のフックという仕組みの一部として動いています。だから /goal は、その作業場所で最初に出る信頼ダイアログを承諾済みの場所でしか使えません。
使うには Claude Code v2.1.139 以降が要ります。それと、フックを丸ごと止める設定 disableAllHooks がどこかのレベルで入っていたり、管理側で allowManagedHooksOnly が指定されていると動きません。使えない時は黙って無視されるのではなく、コマンドが「なぜ使えないか」を表示してくれます。
「料理ブログのテストを全部通す」を例に、実際の手順を見る
料理ブログのサイトを作っていて、レシピ投稿まわりのテストが何本か落ちている状況だとします。1本直すと別の1本が落ちる、みたいなイタチごっこを Claude に任せきりにしたい。ここで /goal の出番です。
ステップ1: まず条件を1行で決める
達成判定モデルは Claude が会話に出した内容しか見られません。なので「テストが通った」とモデルが画面の出力から確認できる形で書きます。今回は「test/recipe のテストが全部通って、文法チェックもきれいな状態」をゴールにします。
達成しやすい条件には型があります。公式が挙げる要素は3つです。
- 計測できる終わりの状態: テストの結果、ファイルの数、残作業ゼロ、など数字や状態で確認できるゴールにする
- 確認のやり方: Claude がどうやってそれを画面に出すか。「
npm testが 0 で終わる」「git statusがきれいな状態」のように出力の形まで書くと判定の精度が上がります - 変えてはいけない約束: 「他のテストファイルは触らない」のように、途中で壊してはいけないことも条件に入れておく
条件は最大4,000字まで書けます。長い作業ほどこの3つを揃えるのが効きます。
ステップ2: /goal の後ろに条件を書いて送る
コマンドの後ろに、達成したい条件をそのまま日本語か英語で書きます。
/goal all tests in test/recipe pass and the lint step is clean
送った瞬間に、その条件を指示そのものとして1ターン目が走り始めます。「じゃあ直して」と別途お願いする必要はありません。ここ、地味だけど便利です。
ステップ3: ◎ /goal active 表示で走っているのを確認する
ゴールが動いている間は画面に ◎ /goal active という印が出て、ゴールが何分回り続けているかを見せてくれます。Claude はテストを走らせ、落ちたところを直し、また走らせる、を勝手に繰り返します。
ステップ4: ターンが終わるたび検査係が判定する
Claude が1ターン終えるたび、条件とそれまでの会話が小さくて速いモデル(初期設定では Haiku)に送られます。モデルは「達成したか/してないか」のイエスかノーと、短い理由を返す。ノーなら理由を次のターンへの手がかりとして添えて、Claude にもう1ターン回させます。
ステップ5: ここで初心者がやりがちな勘違い
「検査係のモデルが自分でテストを走らせて確認してくれる」と思いがちですが、これは違います。検査係はファイルを読んだりコマンドを動かしたりしません。Claude が画面に出した結果だけを見て判定する。だから条件は「Claude の出力が証明できる形」で書く必要があります。「全テストが通った」が成立するのは、Claude が実際にテストを走らせて結果を画面に出すからです。
ステップ6: 条件達成で自動的にゴールが外れる
検査係がイエスを返すと、ゴールは自動で外れて「達成した」という記録が会話の履歴に残ります。あなたはずっと「続けて」を打たずに、最後の合格だけ見届ければいい。
つまり /goal は何をしてくれるのか
- やってくれる: 1つの条件が満たされるまで、毎ターン「続けて」を打たずに Claude を走らせ続ける。ターンが終わるたび別のモデルで達成判定する
- やってくれない: 達成判定のモデルはファイルを読んだりテストを自分で走らせたりしない。Claude が会話に出していない事実は判定できない
- 意味が薄い場面: 1ターンで終わる小さな作業。区切りで毎回こちらが内容を確認したい慎重な作業も、止まらず進むぶん向かない
使いどころ3シナリオ(具体題材で再現)
シナリオ1: 料理ブログのテストを全部緑にしたいとき
レシピ投稿のテストが12本中4本落ちている。/goal test/recipe のテストが全部通り、lint も指摘ゼロになる と渡せば、Claude は落ちたテストを直しては走らせ直す、を全部緑になるまで自分で繰り返します。あなたは ◎ /goal active を眺めながらコーヒーを淹れてればいい。私はこういう「終わりが明確な反復作業」が /goal のいちばんの得意分野だと感じています。
シナリオ2: 家計簿アプリの大きいファイルを分割したいとき
1ファイル2000行になった家計簿アプリの画面コードを、1ファイル300行以下になるまで分けたい。/goal どのファイルも300行以下になる、ただし他の画面の見た目は変えない のように、ゴールに「途中で壊してはいけない約束ごと」も入れておきます。これがないと、行数だけ減らして見た目が崩れる事故が起きます。
シナリオ3: 今週取り込まれたPR全部を変更履歴に書き起こしたいとき
画面に張り付かずに一発で回したい時は、-p をつけて画面なしで実行できます。公式が出している例がそのまま使えます。
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"
これでゴールのループが1回の実行の中で達成まで走りきります。途中で止めたければ Ctrl+C を押す。デスクトップアプリや Remote Control(遠隔操作)でも同じように /goal は動きます。
/goal と /loop は似て非なるもの(必ず押さえる違い)
「/goal って /loop と同じでは」と聞かれることが多いですが、別物です。次のターンが始まるきっかけと、止まる理由が違います。
- /goal: 前のターンが終わると次が始まる。止まるのは「条件を満たした」とモデルが確認したとき
- /loop: 一定の時間が経つと次が始まる。止まるのは自分で止めたとき、または Claude が「もう終わった」と判断したとき
- Stop フック: 前のターンが終わると次が始まる。止まるのは自分で書いたプログラムや指示文が決めたとき
auto mode と混同されることもあります。auto mode はツールの実行許可を自動で通すモードで、1ターンの中のツール承認を消すだけ。新しいターンは始めません。/goal は毎ターン条件を判定する検査係を別に足すので、達成したかどうかを「作業をしたモデルとは別の、新しいモデル」が決める。この2つは喧嘩せず、むしろ合わせて使うと「ツールごとの確認」も「ターンごとの確認」も両方消えます。
初心者が踏みやすい落とし穴
- 上限句を入れないと延々回り続ける。条件に「or stop after 20 turns」のような「20ターンで打ち切る」「○分で止める」の一句を足しておかないと、達成できない条件だと無限に走ります。今いくら使ったかは
/goalと後ろに何も書かずに打てば確認できます。 - 会話に出ない事実を条件にすると永遠に達成しない。検査係はファイルを直接読みません。「○○が直っている」だけだと、Claude がその結果を画面に出さない限りいつまでもノー判定になります。
- /goal stop は「ゴール解除」であって作業の停止ではない。
stopはclearの言い換えの1つです。バックグラウンドのセッションを止める/stopコマンドとは別物なので混同しないこと。 - /clear で会話をリセットするとゴールも一緒に消える。新しい会話を始めるつもりで
/clearすると、走っていたゴールも外れます。 - セッション再開で数えるものが一部リセットされる。
--resumeや--continueで再開すると条件は引き継がれますが、ターン数・経過時間・使った量の集計はゼロから数え直しです。すでに達成済み・解除済みのゴールは復元されません。 - 1つのセッションでアクティブにできるゴールは1個だけ。新しく
/goalで条件を渡すと、前のゴールは上書きで置き換わります。 - フックを止めた環境では使えない。
disableAllHooksが入っている、または管理側でallowManagedHooksOnlyが指定されていると動きません。理由はコマンドが教えてくれます。
書き方
/goal <達成したい条件>
/goal (後ろに何も書かず叩くと現在の状態を表示)
/goal clear (走っているゴールを途中で解除。stop / off / reset / none / cancel も同じ意味)
やってみるとこうなる
入力
/goal all tests in test/recipe pass and the lint step is clean
出力例
条件を渡した瞬間に1ターン目が走り始め、画面に「◎ /goal active」と経過時間が表示される。ターンが終わるたび小さくて速いモデル(初期設定は Haiku)が達成判定し、未達なら理由を添えてもう1ターン回す。条件達成で自動的にゴールが外れ、履歴に「達成」記録が残る。後ろに何も書かず /goal だけ叩くと、条件・経過時間・評価済みターン数・現在の使用量・直近の判定理由が見られる
このページに出てきた言葉
- ターン
- Claude が指示を受けて作業し、いったん手を止めて返事を返すまでのひとまとまり。普段は1ターンごとにこちらの入力待ちになる
- フック
- Claude Code の特定のタイミング(ターンが終わった時など)で自動で動く仕掛け。<code>/goal</code> の達成判定もこの仕組みに乗っている
- 信頼ダイアログ
- あるフォルダで Claude Code を初めて開いた時に「このフォルダの中身を信頼して動かしていいか」を聞いてくる確認画面
- Haiku
- Anthropic の小さくて速いモデルの名前。<code>/goal</code> の達成判定の初期設定がこれになっている
- 文法チェック(lint)
- コードの書き方のルール違反やケアレスミスを自動で洗い出す確認。「clean」は指摘ゼロの状態
- PR
- 「この変更をプロジェクト本体に取り込んでほしい」という提案のまとまり。GitHub 上で一覧できる
- auto mode
- ツールの実行許可を毎回聞かずに自動で通すモード。1ターン内の確認を消すが、新しいターンは始めない