Claude Codeの/goalコマンド — 完了条件を渡して目標達成まで自走させる仕組み

背景

Claude Codeは長らく「1ターンで1つの応答を返す」という対話型ツールとして設計されてきました。長尺の作業をさせたいときは、複数ターンにわたって人間が「次は」「もう少し進めて」と介入する必要があり、CIや非対話運用と相性が悪い場面がありました。

v2.1.139で導入された/goalコマンドは、この前提を覆します。完了条件を1行で渡すと、Claudeがターンをまたいで作業を継続し、条件を満たしたところで自走を止める。「いつ止めるか」を条件として宣言的に書ける、ターン継続を条件で制御する初の組み込みコマンドです。

CI / -p(非対話)/ Remote Controlの3経路で動くため、「ESLintエラーが0件になるまで修正する」「テストが全部通るまでデバッグする」のような完了条件付きタスクを、人間の介在なしに走らせる用途が一気に現実的になりました。

本記事は/goalの内部実装を読み解き、評価可能な条件の書き方、3モードでの使い分け、運用上の落とし穴を扱います。

仕様の掘り下げ

コマンド構造

clear には stop / off / reset / none / cancel のエイリアスがあり、どれを使っても同じ意味になります。また /clear(新規会話の開始)を実行した場合もアクティブなゴールは自動的に削除されます。

1セッションにつき同時に保持できるゴールは1つ。新しい/goalで上書きすると、前のゴールは置き換えられます。

動作モード

3つの動作経路があり、それぞれ典型的なユースケースが違います。

非対話モードでの実例:

claude -p "/goal 今週マージされた全PRがCHANGELOG.mdに記載されている"

これをCIで走らせると、Claudeがgit log等を実行してマージ済みPRを列挙し、CHANGELOGに不足エントリがあれば追記、全て揃ったら自走を止めます。

ステータス表示

ゴールが有効な間、Claudeのプロンプト下に常時インジケータが表示されます。

◎ /goal active   経過 12m 04s

/goalを引数なしで実行すると、より詳しい状態が出ます:

• 現在の完了条件(設定時の文言)
• 経過時間
• 評価が走ったターン数(後述する評価モデルの実行回数)
• 累計トークン消費(評価モデル分を含む)
• 直近の評価モデルからの理由文(なぜ未達と判定したか)

--resume / --continueでセッションを再開した場合、ゴール自体は復元されますが、経過時間とターン数、トークン消費はリセットされます(同じゴールの「2セッション目」として扱われる)。

なお、既に達成されてクリアされたゴールは復元されません。ただし同じセッション内であれば、/goal引数なし実行で達成された条件・要した期間・ターン数・トークン消費を遡って確認できます。「どのゴールがどれくらいで達成できたか」の事後分析に使えます。

実装イメージ / 内部動作の推察

公式ドキュメントによると、/goalはprompt-based Stop hookのセッションスコープラッパー として実装されています。Claude CodeのHooksシステムを応用した形です。

評価フローの仕組み

1. /goal <条件> 実行: 条件文をセッションに登録。内部的にStop hook相当の評価ロジックが有効化される
2. Claudeが通常通り応答: 各ターンで指定タスクを進める
3. ターン終了時(Stop hook発火): 会話履歴と条件文を小型高速モデル(small fast model、既定はHaiku)に渡し、yes/noと短い理由を返させる
4. no応答: 評価モデルが返した理由を次ターンへのガイダンスとしてClaudeに渡し、作業を継続
5. yes応答: ゴール達成として記録され、自走終了。インジケータが消える

重要な制約:評価モデルはツールを呼ばない

ここが/goalの運用で最も重要なポイントです。

評価モデル(small fast model)は会話履歴を読むだけで、BashやRead等のツールは呼びません。つまり、条件文が「Claudeの出力に実証可能な情報が現れる形」でなければ判定できない。

NG例:

/goal mainブランチのCIパイプラインが通っている

→ 評価モデルはCIを叩けないので、会話に「CIが通った」という痕跡が出るまで永久に未達と判定される。

OK例:

/goal `npm test` が exit 0 で `npm run lint` がエラーを出さない

→ Claudeがコマンドを実行した結果が会話に残り、評価モデルはそれを根拠に判定できる。

条件文を書くときは、「Claude自身がコマンドを実行して、結果を会話に残す」フローを設計することが成功の鍵です。

モデル選択とコスト

評価モデルは既定でClaude Haiku系列の小型高速モデルが使われます。これは2つの理由から合理的です。

• 判定タスクがyes/noと短い理由のみ:推論能力より速度・コストが重要
• ターンごとに毎回走る:重いモデルだと累計トークン消費が膨らむ

実運用では、メインのClaude(Opus / Sonnet)の応答1ターンあたり、評価モデルのトークン消費は数百〜数千程度に収まることが多いです(条件文と会話履歴の長さによる)。長時間自走させても、評価モデル自体がコスト要因になることは稀です。

/goalを使いこなすための運用設計

条件文に「停止条件」を組み込む

評価モデルが判定できない条件をうっかり渡すと、Claudeは延々と自走を続けます。これを防ぐため、条件文に明示的な打ち切りラインを組み込むのが定石です。

/goal TypeScriptのエラーが全て解消、もしくは20ターン経過したら停止

/goal /docs/api/* の全エンドポイントに使用例が記載されている、もしくは5ターン進捗がなければ停止

評価モデルは「20ターン経過」「5ターン進捗なし」を会話履歴から判定できるので、この形だと暴走を防げます。

CIとの組み合わせ

非対話モード(-p)とCIの組み合わせは、/goalが最も効く場面です。

# .github/workflows/claude-autofix.yml(概念的な例)
- name: Run Claude until lint passes
  run: |
    claude -p "/goal \`npm run lint\` のエラーが0件、もしくは30ターン経過で停止" \
      --max-turns 30
  env:
    CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

ESLintやTSCのエラーが残るたびにClaudeが自動修正を試み、ゼロになったら止まる。失敗しても--max-turnsで打ち切られる。CI / オートフィックスの実装が大幅に簡単になりました。

Claude Code RoutinesによるGitHub triggerと組み合わせると、PR作成時に/goalで「テストが全部通るまで修正」を自動実行する流れも組めます。

制限事項

これらの制限に該当して/goalが動かない場合、コマンドは無言で失敗せず理由を伝えて停止します。disableAllHooks と allowManagedHooksOnly は組織レベルで一律設定されていることが多いため、企業導入環境では事前確認が必要です。

「いつ止めるか」を宣言できることの意味

/goalが運用に与える本質的な変化は、Claudeの自走範囲を条件(condition)で縛れるようになったという点に尽きます。

これまでのClaude Codeは「1ターン応答」が単位で、長尺タスクは人間がループを回す必要がありました。/goalはそのループをClaude側に内包させ、人間は**「達成したいゴール」だけを宣言**すればよくなります。

これは/loopコマンドとも似た目的に見えますが、本質的に違います。/loopは「N回繰り返す」「定刻に走る」のような回数 / 時刻ベースの繰り返し。/goalは条件達成ベースの繰り返し。前者は反復作業、後者は探索作業に向きます。

自律ワークフロー4種の役割マップ

/goalは、Claude Codeに既にあった3種の自律ワークフロー機構と並列に位置付けると役割が見えやすくなります。

/goalとStop hookはどちらもターン終了時に評価が走る共通基盤を持ち、/goalはセッションスコープのプロンプトベースStop hookとして実装されています(本記事「評価フローの仕組み」節を参照)。Stop hookが「設定ファイルにあらかじめ仕込むカスタム判定」だとすると、/goalは「セッション中にその場で仕込む条件」と整理できます。

自動モードと/goalは補完関係で、自動モードが「ツール承認のプロンプトを削減」するのに対し、/goalは「ターン継続のプロンプトを削減」します。両方を組み合わせると、人間の介在をツール承認とターン継続の両面で自動化できます。

評価モデルがツールを呼ばない制約の意味

評価モデルがツールを呼ばない制約は一見不便ですが、これは設計上のトレードオフです。評価モデルがツールを呼べる設計だと判定モデルの権限が肥大化し、料金 / セキュリティリスクも増えます。「Claude自身の出力で判定可能な条件を書け」というルールは、ユーザーに自走の境界を自覚させる効果もあります。

まとめ

/goalは、Claude Codeを「対話ツール」から「条件達成型のオートメーション基盤」に拡張する変化点です。CI / Routine / -pからの起動が可能になり、人間の介在なしに長尺タスクを完走させられるようになりました。

成功の鍵は3つ:

• 条件文を「Claude自身が実証できる形」で書く(「npm test がexit 0」のように)
• 暴走防止の打ち切りラインを必ず添える(「20ターン経過したら停止」のように)
• モード選択を用途に合わせる(対話 / CI / Routine)

評価モデルがHaiku系列でコスト軽微なため、長時間自走しても料金は通常セッションと大差ありません。disableAllHooks管理下の企業環境を除き、明日からのワークフローに組み込める実用性があります。

更新はclaude updateで取得でき、claude --versionで2.1.139以降になっていれば/goalが使えます。