この記事の目次
Claude Codeに作業を任せても、1ターン終わるたびに「続けて」と打つ羽目になる。その手間を減らすのが /goal です。完了条件を1つ書いておくと、条件が満たされるまでClaudeが自分で次のターンへ進みます。
この記事では、次の3点を扱います。測定できる終点と確認の出力を含む条件文を1本書けること、設定・状態確認・解除ができること、止まったときにどこを見ればよいか分かることです。
内容は公式ドキュメント(https://code.claude.com/docs/en/goal)に沿っています。確認日は2026-10-12で、このページには公開日・更新日の記載がありません。実機では動かしておらず、画面の見た目も ◎ /goal active 以外は確認していません。公式に書かれていない部分は断定しない方針です。
/goalは何をするコマンドで、どうなったら止まるのか?
/goal は、完了条件を1つ置くと各ターンの後に別のモデルが条件の成否を判定し、未達なら次のターンを自動で始めるコマンドです。条件が満たされるか、不可能と判定されるか、直す必要のあるエラーが出るまで続きます。
公式は仕組みを次のように書いています。
After each turn, a model checks whether the condition holds.
ここでいう「ターン」は、Claudeが1回の指示に対して作業し、応答を返すまでの1往復です。通常ならターンが終わるたびに操作が自分に戻りますが、/goal の下では判定が「未達」の間、Claudeが次のターンを始めます。
終わり方は3つある
目標が解除される場面は、公式の説明を整理すると3通りです。
- 条件が満たされたと判定されたとき(達成)
- 条件を満たすことは不可能と判定されたとき
- ユーザー側で直す必要のあるエラーでターンが失敗したとき
前の2つは判定による解除で、3つ目の内訳は後半の「止まったときの逆引き」で扱います。実行中に自分から外したいときは /goal clear を使います。
似た仕組みとの違い
ターンを続けさせる仕組みは /goal だけではありません。公式は、次のターンが始まる契機で3つを分けています。
| 仕組み | 次のターンが始まる契機 | 止まる契機 |
|---|---|---|
/goal |
前のターンが終わったとき(対話セッションでは、アイドル時のcheck-inや自動再試行の期限が来たときも) | モデルが達成または不可能と判定、直すべきエラー、/goal clear |
/loop |
時間間隔が経過したとき | 自分で止める、またはClaudeが作業完了と判断 |
| Stop hook | 前のターンが終わったとき | 自作のスクリプトやプロンプトが決める |
/loop は時間間隔で動き、Stop hookは設定ファイルに書いた自作の判定で動きます。Stop hookを自作したい場合はhooksの解説が入口になります。
自分の仕事に/goalは向いているのか?
向いているのは、終点が数や状態で測れる作業です。公式が挙げる例は、モジュールを新しいAPIへ移行して全呼び出し箇所のコンパイルとテストを通す、設計書の受け入れ基準を満たす、大きなファイルを一定サイズ未満に分割する、ラベル付きissueを空になるまで消化する、の4つです。
見分けるための自問は2つです。
- 終点は、テスト結果・終了コード・ファイル数・空のキューのように測れるか。
- その結果を、Claude自身の出力として会話に出せるか。
反対に、終点が感覚で決まる作業は向きません。「読みやすくなったら終わり」「デザインが良くなったら終わり」は、出力から成否を読み取れないからです。この部分は公式の記載ではなく、本記事の判断です。
評価器は何を見て判定し、どう返すのか?
判定するモデル(評価器)は、会話にすでに出た内容だけを見て成否を決めます。コマンドを実行することも、ファイルを自分で読むこともありません。だから確認結果が出力に現れるよう、条件文の側で求める必要があります。この前提が、以降の条件文の書き方すべての土台です。
公式の記述は次のとおりです。
It doesn’t run commands or read files independently
返ってくる判定は3種類で、それぞれ短い理由が付きます。
- Not yet met(未達): Claudeは理由を次のターンの指針として受け取り、作業を続けます。
- Met(達成): 目標が解除され、達成の記録がtranscript(会話の記録)に残ります。
- Impossible(不可能): 条件が満たせないと判定された場合で、目標が解除され、失敗の記録が理由つきで残ります。自分で解除する必要はありません。
目標が有効な間、transcriptには判定が表示され、Ctrl+Oを押すとその理由が見られると公式は書いています。
評価に使うトークンは、プロバイダー側で設定された小型で高速なモデルの課金になり、通常は本体のターンの費用に比べて無視できる程度とされています。評価モデルは環境変数 ANTHROPIC_DEFAULT_HAIKU_MODEL で変えられますが、この変数は会話の要約などバックグラウンド処理にも効くため、変更は慎重に行ってください。
終わる条件は、どう書けばよいのか?
条件文には、測れる終点を1つ、確認の方法、変えてはいけない制約の3要素を入れます。長さは4,000字までで、回数や時間の上限は条件文の中に書く方式です。評価器は会話に出た内容しか見ないので、確認の指定は「出力に示す」形で書きます。
公式の説明では、効きやすい条件は次の3つを持っています。
- 測れる終点が1つ: テスト結果、ビルドの終了コード、ファイル数、空のキューなど
- 確認の指定: 「
npm testが終了コード0」「git statusがクリーン」のように、どう証明するか - 守るべき制約: 「他のテストファイルは変更しない」のように、途中で変わってはいけないもの
上限については、or stop after 20 turns のようなターン数や時間の句を条件に含めると、Claudeが毎ターンその句に対する進み具合を報告し、評価器も会話から判断する、と公式は書いています。コスト上限として組み込まれた機能とは書かれていないので、費用の歯止めとして頼り切らないほうが安全です。
穴埋め用の雛形を置きます。数値や名前はすべて説明用です。
/goal <終点: 何がどうなっていれば完了か>。
確認として <コマンド> を実行し、<期待する結果> を出力に示す。
<変えてはいけないもの> は変更しない。
<N>ターンを超えたら止まって現状を報告する。あいまいな条件の書き換え3例
あいまいな条件は、評価器が出力だけで成否を決められる形に直します。具体的には、状態を数や終了コードに言い換え、確認コマンドとその結果を会話に出すよう条件に含めます。以下の3例はすべて架空例で、数値は説明用です。
例1: テスト修正
悪い条件は「テストが通ったら終わり」です。これでは、他のテストを書き換えて通した場合も「通った」ことになってしまいます。
/goal test/auth 配下の全テストが通り、lint がエラー0であること。確認として npm test と npm run lint を実行し、どちらも終了コード0であることを出力に示す。最後に git diff --stat を実行し、変更ファイルに test/auth 以外のテストファイルが含まれないことを出力に示す。20ターンを超えたら止まって現状を報告する。「他のテストを変えていない」は、git diff --stat の出力が会話に出ていてはじめて判定できます。
例2: バグ修正
悪い条件は「バグがなくなったら終了」です。「なくなった」は出力に現れません。
/goal 「注文確定ボタンを連続で2回押すと注文が二重登録される」不具合が直ること。確認として、この操作を再現するテスト tests/order_double_submit を追加し、修正前は失敗、修正後は成功した出力を両方示す。npm test 全体が終了コード0であることも出力に示す。15ターンを超えたら止まって現状を報告する。再現手順と期待結果を、修正前後のテスト出力という形で会話に残しています。
例3: ファイル分割
悪い条件は「ファイルがいい感じに整理されたら」です。「いい感じ」は誰にも測れません。
/goal src/utils.ts を機能別に分割し、新しい各ファイルが200行未満になること。確認として wc -l で各ファイルの行数を出力し、tsc --noEmit が終了コード0であることを出力に示す。元のエクスポート名は変えない。20ターンを超えたら止まって現状を報告する。「いい感じ」を行数(数)と型検査の結果(状態)に置き換えています。
設定・確認・解除・再開の操作
/goal <条件> と打つと、条件そのものが指示となってすぐ1ターン目が始まり、進行中は ◎ /goal active が表示されます。状態確認は引数なしの /goal、解除は /goal clear です。
設定した直後
有効にできる目標は1セッションに1つで、すでに目標があるときに新しく設定すると置き換わります。目標は権限モードを変えません。確認なしで進めたい場合は、auto modeで /goal を実行します。Manual modeでは、設定で許可されていないツール呼び出しの前に、これまでどおり確認が入ります。モードの選び方は権限モードの解説にまとめられています。
状態確認
/goal を引数なしで実行すると、条件、経過時間、評価されたターン数、現在のトークン消費、評価器の直近の理由が表示されます。ターン数と理由は初回の評価が済んでから出ます。目標が有効でなくても、同じセッションで以前に達成したものがあれば、その条件と所要時間・ターン数・トークン消費が表示されます。
解除
/goal clear を実行すると、有効な目標が外れます。成功すると Goal cleared: に続けて条件が表示され、目標がなければ No goal set と出ます。stop、off、reset、none、cancel も clear の別名です。新しい会話を始める /clear でも目標は消えます。
再開したとき
セッションを再開すると、終了時にまだ有効だった目標は復元されます。条件は引き継がれますが、ターン数・タイマー・トークン消費の基準は0に戻ります。すでに達成済みか解除済みの目標は復元されません。claude --resume のセッションピッカーからの再開で復元されるのは v2.1.239 以降で、それより前はこの経路だけ復元されませんでした。
非対話で使う場合
claude -p "/goal ..." のように -p を付けると、非対話モードで1回の実行の中でループが最後まで回ります。既定のテキスト出力では終了時に最終応答だけが出るため、ターン数の多い目標は止まって見えることがあります。--output-format stream-json --verbose を足すと、途中のメッセージが順に出力されます。実行を止めたいときはCtrl+Cです。
止まった・動かないときの逆引き
症状ごとに状態が違うので、下の表から該当する行を引いてください。目標が消えたのか、待っているだけなのか、一時停止なのかで、取るべき行動が変わります。/goal に関係しない停止は、途中で止まるときの解説で切り分けられます。
| 症状 | 考えられる状態 | 見る場所・行動 |
|---|---|---|
Goal cleared after an unrecoverable error と出て目標が消えた |
直す必要のあるエラー(認証失敗、クレジット残高切れ、auto-compactionで解消できない文脈あふれ、利用できないモデル) | 原因を直し、/goal <condition> で設定し直す。認証失敗は、デスクトップアプリやクラウドセッションのようにホストが資格情報を管理する環境では解除されない |
Goal still active と出て待っている |
一時的なエラーの自動再試行。3回再試行すると一時停止になる | 待つか、メッセージを送ると次のターンがすぐ始まる(対話セッションで v2.1.269 以降) |
Goal paused と出た |
APIレート制限、claude.aiの使用上限、hookによるターン終了など、再試行しても同じになる失敗 | 原因を解消してからメッセージを送る。使用上限のリセットを自動で待つ設定の場合は、リセット後に作業が再開される |
| 評価が走らない | サブエージェントまたはバックグラウンドのシェルコマンドがまだ実行中 | 実行中の作業がないターンの終わりで評価される。30分待つと確認(check-in)が入る |
| 数ターンツールを使わないまま警告が出て、操作が戻ってきた | 進捗のない応答が続いたため、ループが停止した | 目標は残っている。次のプロンプトを送ると評価が再開する |
/goal が使えない |
hooksが無効、または管理設定で制限されている | 使えない理由はコマンドが画面に表示する |
補足がいくつかあります。バックグラウンド作業のcheck-inは v2.1.234 以降の機能で、最初の確認のあと、間隔は2倍ずつ延び、最初の間隔の4倍が上限です。既定なら最初の確認の1時間後、そのあとは2時間おきになります。間隔は環境変数 CLAUDE_CODE_GOAL_CHECKIN_MINUTES で変えられ、0 にするとcheck-inと自動再試行の両方が止まります。
/goal が使えない場合の背景は、評価器がhooksの仕組みの一部であることです。信頼していないフォルダーでの扱いはhooksと同じ規則に従い、disableAllHooks が true のときや、管理設定で allowManagedHooksOnly が設定されているときも使えません。
AIを自分の手で使えるようになるための学びの場
/goal の条件文は、自分の作業に当てはめて使うことで感覚がつかめてきます。
手を動かしながら学べる場として、月額1,980円からの学習コミュニティ「AI駆動ラボ」があります。AIを自分の手で使えるようになることを目的にした学びの場です。
まとめ
/goal は、完了条件を書いてターンを続けさせるための道具です。条件文には、測れる終点、出力に示す確認、変えてはいけない制約の3つを入れます。
止まったときの見方の要点は次のとおりです。
Goal cleared after an unrecoverable errorは目標が消えているので、原因を直して設定し直すGoal still activeとGoal pausedは目標が残っており、待つか、原因を解消してメッセージを送る- 評価が走らないときは、バックグラウンド作業が終わっていないか確かめる
最初の1本は、20ターン程度の上限を付けた小さな作業で試すのがよいでしょう。この記事は公式ドキュメントの整理であり、表示文言の完全一致は実機で確かめていません。料金プランごとの可否、初回提供バージョン、地域、提供段階も公式ページに記載がなく、確認できていません。お使いの環境で使えるかは、実際に /goal を実行して確かめてください。