ゴールを決めて任せる

/goal は完了条件を設定するコマンドです。条件を決めると、毎ターンの指示がなくても Claude が作業を続けます。各ターンの後にモデルが条件を満たしたかを判定し、まだなら Claude が次のターンを始めます。条件を満たす、評価モデルが「達成不可能」と判断する、直す必要のあるエラーでターンが失敗する、のどれかでゴールは自動で消えます。

• 検証できる終わりの状態がある大きな作業向け：モジュールを新しい API へ移行して全呼び出し箇所のコンパイルとテストを通す、設計書の受け入れ条件を全部満たす、大きなファイルを各サイズ以内のモジュールに分ける、ラベル付きの課題をキューが空になるまで片づける
• 1 セッションに有効なゴールは 1 つだけ。新しく設定すると置き換わる
• /goal の条件を書いて実行すると、その場で最初のターンが始まる
• 条件が合っているかを判定する評価モデルは、コマンドを実行せずファイルも読まない。Claude が会話に出した内容だけで判断する
• ゴールは /goal clear でいつでも消せる

継続の方法の比較#

セッションをプロンプトの合間も動かし続ける方法は 3 つあります。何を次のターンの引き金にしたいかで選びます。

• /goal と Stop フックは、どちらも毎ターンの後に動く。/goal は現在のセッションだけで有効な手軽な設定で、条件を打てばそのセッションの間だけ効く。Stop フックは設定ファイルに置き、その範囲のすべてのセッションに適用され、決定的な検査のスクリプトか、モデルによる評価のプロンプトを動かせる
• 権限モードの auto モードだけでは、1 ターンの中のツール呼び出しを承認するだけで、新しいターンは始めない。Claude は作業が終わったと判断したところで止まる。/goal は、毎ターンの後に条件を検査する別の評価モデルを足すので、完了を、作業しているモデルではなく新しいモデルが決める。auto モードがツールごとの確認をなくし、/goal がターンごとの確認をなくす
• 開いているセッションと無関係に動かす予定の作業（夜間のテスト・朝のトリアージなど）は、ルーティンやデスクトップの定期実行タスクが使える

/goal の使い方#

同じコマンドが、引数によってゴールの設定・確認・解除を行います。

ゴールを設定する#

/goal の後に、満たしたい条件を書きます。すでにゴールがあれば、新しいもので置き換わります。

/goal all tests in test/auth pass and the lint step is clean

• 設定すると、条件そのものを指示として、すぐにターンが始まる。別のプロンプトを送る必要はない
• ゴールが有効な間は、◎ /goal active の表示が、ゴールが動いている時間を示す
• ゴールは権限モードを変えない。ゴールのターンを無人で動かすには、auto モードで /goal を実行する。Manual モードでは、設定がまだ許していないツール呼び出し（上の例のテストコマンドなど）の前に、Claude が引き続き確認する
• ゴールが有効な間、記録に評価モデルが返した判定が毎回出る。Ctrl+O で、その理由を見られる。状態の表示にも直近の理由が出るので、Claude が次に何を目指すかが分かる

効果的な条件の書き方#

評価モデルは、Claude が会話に出したものに照らして条件を判定します。コマンドを実行することも、ファイルを自分で読むこともしないので、Claude 自身の出力で示せる形で条件を書きます。「test/auth のテストがすべて通る」が機能するのは、Claude がテストを実行し、その結果が記録に出て評価モデルが読めるからです。多くのターンにわたって通用する条件には、たいてい次が入っています。

• 測れる終わりの状態を 1 つ：テスト結果・ビルドの終了コード・ファイル数・空のキュー
• 確かめ方の明示：Claude がどう証明するか（「npm test が 0 で終わる」「git status がきれい」）
• 大事な制約：そこへ至る途中で変えてはいけないもの（「ほかのテストファイルは変更しない」）

条件は 4,000 文字までです。

状態を確認する#

引数なしで /goal を実行すると、現在の状態が出ます。

/goal

ゴールが有効なときの表示：

• 条件
• 動いている時間
• 評価されたターンの数
• 現在のトークン消費
• 評価モデルの直近の理由

ターン数と直近の理由は、最初の評価が走った後に出ます。有効なゴールがなくても、セッションの前のほうで達成したものがあれば、達成した条件と、所要時間・ターン数・トークン消費が出ます。

ゴールを消す#

解決する前に消すには /goal clear を実行します。

/goal clear

確認として、Claude が Goal cleared: に条件を続けて出し、有効なものがなければ No goal set と出します。

• stop・off・reset・none・cancel も clear の別名として受け付けられる
• 新しい会話を始める /clear を実行しても、有効なゴールは消える

ゴールが有効なまま再開する#

セッションを再開すると、終了時にまだ有効だったゴールが復元されます。--continue、セッション ID・名前・記録ファイルのパスを付けた --resume、セッションピッカーのすべてで復元されます（v2.1.239 より前は、claude --resume のピッカーを除くすべての経路で復元されていた）。再開の方法はセッションの再開と管理を参照してください。

• 条件は引き継がれるが、ターン数・タイマー・トークン消費の基準はリセットされる
• すでに達成した、または消したゴールは復元されない

非対話で動かす#

/goal は、ヘッドレス実行（-p）・デスクトップアプリ・リモートコントロールとモバイルでも動きます。-p でゴールを設定すると、ループが 1 回の呼び出しの中で完了まで動きます。

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

• 既定のテキスト出力では、実行が終わるまで何も出ないので、多くのターンを動かすゴールは止まって見えることがある。ループの途中で各メッセージを出すには、--output-format stream-json --verbose を足す
• 解決する前に非対話のゴールを止めるには、Ctrl+C でプロセスを中断する

評価のしくみ#

/goal は、セッション単位の、プロンプトによる Stop フックのラッパーです。Claude がターンを終えるたびに、Claude Code は条件とそこまでの会話を、設定された小さな高速モデルに送ります。モデルは次の 3 つの判定のどれかを、短い理由つきで返します。

• Claude が進まないまま評価モデルに答え続けると（数ターン続けてツールを使わない）、Claude Code はループを止め、警告を出し、ゴールを設定したまま制御を返す。評価は次のプロンプトの後に再開する。仕組みはフックの使い方にある

ターンが失敗したとき#

ターンが失敗したとき、直す必要のあるエラーなら Claude Code はゴールを消し、それ以外のエラーの後はゴールが残ります。

直す必要のあるエラーで消えるときは、原因を示す警告が Goal cleared after an unrecoverable error で始まり Run /goal again to continue で終わります。原因を直してから、/goal <条件> でゴールを設定し直します。次の 4 種類の失敗でゴールが消えます。

• 認証の失敗（Claude Code が自分で認証情報を管理しているとき）。デスクトップアプリやクラウドセッションのように、ホストが認証情報を管理する場合は、ホストが自分でアクセスを戻すので、ゴールは有効なまま
• クレジット残高の枯渇
• 自動圧縮でも解消できなかったコンテキストの溢れ
• 使えないモデル

それ以外の失敗の後はゴールが残ります。v2.1.269 以降の対話セッションでは、Claude Code が原因を示す行も出し、自動で再試行するか、あなたを待ちます。

• いつでもメッセージを送れば、すぐに次のターンが始まる
• 自動の再試行をオフにするには CLAUDE_CODE_GOAL_CHECKIN_MINUTES を 0 にする（待機中の確認もオフになる）。エラーはエラー一覧を参照

バックグラウンドの作業は評価を遅らせる#

ターンの終わりにサブエージェントやバックグラウンドのシェルコマンドがまだ動いていると、Claude Code はそのターンの評価を飛ばします。バックグラウンドの作業が動いていない状態で終わる次のターンの終わりに評価します。バックグラウンドの作業が終わると、Claude Code が結果を新しいターンとして Claude に渡すので、プロンプトを送る必要はありません。

• バックグラウンドの作業のためにゴールが 30 分待たされると、確認（check-in）の時刻が来る。確認では、Claude Code が動いているタスクを一覧にし、Claude に出力を読み、進んでいれば待ち、詰まっているものは直すか止めるよう求める。最初の確認の後は、後の確認までの待ち時間が倍になり、最初の間隔の 4 倍まで延びる（既定では、最初の確認の 1 時間後、その後は 2 時間ごと）。確認は v2.1.234 以降が必要
• 来た確認（最初のものを含む）は、2 通りのどちらかで届く。ターンの終わり：作業がまだ動いたまま終わる次のターンの終わりに届く。-p で始めた非対話のセッションでは、これが確認が届く唯一の方法。セッションがアイドルの間：対話セッションでは、次のプロンプトを待たずに、Claude Code が自分でターンを始めて確認を届ける。バックグラウンドの作業が結果を報告せずに止まっていたら、Claude Code は Claude にゴールへ向けて続けるよう求める。あなたのプロンプトの間に始めるアイドルの確認は、ゴールにつき最大 3 回で、3 回目で、次のプロンプトまでアイドルの確認を止めると伝える（v2.1.246 より前は上限がなかった。アイドルの確認は v2.1.236 以降が必要）
• v2.1.239 より前は、アイドルの確認だけがこのように間隔を延ばし、ターンの終わりで届く確認は最初の間隔で繰り返された
• 最初の間隔を変えるには CLAUDE_CODE_GOAL_CHECKIN_MINUTES を設定する。値が 30 分の間隔の代わりに使われ、後の間隔もそれに合わせて伸び縮みする。0 で、確認と自動の再試行をオフにする

評価モデルと費用#

別のモデルで評価させるには、ANTHROPIC_DEFAULT_HAIKU_MODEL を設定します。

• 評価モデルは、セッションに設定されたプロバイダーで動く。ツールを呼ばないので、Claude がすでに会話に出したものしか判定できない
• 評価のトークンは、プロバイダーに設定された小さな高速モデルで課金され、通常はメインのターンの支出に比べて無視できる程度

要件#

評価モデルがフックのしくみの一部なので、/goal は、設定ファイルのフックと同じ、ワークスペースの信頼の規則のもとで使えます。設定の優先順位を適用した後で disableAllHooks が true のとき、または管理設定で allowManagedHooksOnly が設定されているときも、/goal は使えません。どちらの場合も、コマンドは黙って何もしないのではなく、理由を伝えます。