Claude Codeの/goalコマンドの使い方

こんにちは、AIニュースアプリ Morning AI 開発者の矢野哲平です。この記事ではClaude Codeに新しく追加された /goal コマンドについて触れます。

Keep Claude working toward a goal - Claude Code Docs

/goalの概要

/goal は2026年5月11日リリースの Claude Codeの新バージョンで追加された組み込みコマンドです。完了条件を渡しておくと、Claudeがその条件を満たすまでターンを越えて作業を続けてくれます。

仕組みはシンプルで、各ターンの終わりに小さくて速いモデル（デフォルトはHaiku）が「条件は満たされたか？」を判定します。なおClaude Codeそのものの概要は別記事で解説しています。Yesなら自動的にゴールを解除して人間に戻し、Noならその理由を次ターンの指針として渡してClaudeに作業を継続させます。

通常のClaude Codeだと「続けて」と何度も打つ必要がある長時間のタスクが、/goal を使うと「終わったら教えて」だけで回るようになります。

/goal の使い方

使い方は至って簡単で、完了条件を後ろに付けて実行するだけです。

/goal test/authのテストが全て通り、lintもクリーンであること

これで条件をゴールとした最初のターンがすぐに始まります。

ターミナルに/goalと入力して表示されない場合は最新のClaude Codeにアップデートしてください。

実行中はターミナルに ◎ /goal active の表示が出て、経過時間が確認できます。

各ターンの終わりに評価器が「達成／未達成」と短い理由を返し、未達成なら理由が次ターンへのガイドとして渡されます。

ちなみに、許可されていない挙動はいつものようにClaude Codeが確認を求めてきます。こうなると/goalを使う意味が薄れるのでその点だけ注意しましょう。

サブコマンド

clear のエイリアスとして stop / off / reset / none / cancel も受け付けます。/clear で新しい会話を始めた場合もゴールは外れます。

ヘッドレスモードでも利用可能

-p（ヘッドレス）でも使えます。1コマンドでゴール達成までループしてくれるので、CI的な使い方もできます。

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

例えば、対話ではなく何かしらの条件をトリガーにgoalループを回すような使い方もできそうです。(例：0:00を回ったらtestループを回す) こうしたスケジュール実行はルーティン機能と組み合わせると一段と自動化しやすくなります。

途中で止めたい場合は Ctrl+C で中断します。

こういう時に使える

公式ドキュメントが挙げているのは「検証可能な終了状態を持つ、まとまった作業」です。

具体的にどのようなシーンで利用できるか公式のサンプルを引用します。

1. API移行を全call siteで終わらせる

「paymentsV1 のすべての呼び出しを paymentsV2 に置き換え、ビルドとテストが通るまで」のような移行作業に強いです。

通常は「次の箇所を直して」「次の箇所を直して」と人間が打ち続けないといけませんが、/goal で「移行後にビルドとテストが通る」を条件にしておけば、Claudeが残り箇所を探しながら自走してくれます。

2. デザインドキュメントを受け入れ基準まで実装する

「このdesign docの全ての受け入れ基準が満たされるまで」をゴールにすると、Claudeが受け入れ基準を1つずつ潰しながら実装を進めます。

途中で関連するファイルや依存関係の修正が出てきても、ゴールに沿った範囲ならClaude側で判断して対応してくれます。仕様の検証も含めて任せたいときに便利です。

3. 巨大ファイルを分割する

「src/legacy.ts を分割し、どのファイルも300行未満にする」のように、定量的な終了条件があるリファクタに向いています。

評価器は「ファイルサイズ」のような具体的な数字に対しては判定がブレにくく、回しているうちに勝手に収束していく体験になります。

4. バックログを空になるまで処理する

「bug ラベルが付いた issue が0件になるまで、優先度の高い順に1件ずつ修正PRを作る」のような、キューを枯らすタイプの作業に使えます。

/loop だと「時間ごとに発火」なので空振りが出ますが、/goal は「終わったから判定」なので無駄なターンがありません。

向かない用途

逆に、評価器が「Claudeの会話に出てきた情報」だけで判定する点には注意が必要です。

例えば、終了条件が主観的なもの（「読みやすくなったら」「ユーザー体験が良くなったら」など）は /goal 単体だと向きません。

効果的な条件の書き方

公式ドキュメントが推奨している条件の構成は次の3点です。

• 1つの測定可能な終了状態（テスト結果、ビルドの終了コード、ファイル数、キューが空、など）
• どう証明するかを明示（npm test が exit 0、git status がクリーン、など）
• 道中で壊してはいけない制約（「他のテストファイルは触らない」など）

評価器は自分でコマンドを実行したりファイルを読んだりはしません。Claude自身が会話の中で示した内容だけを材料に判定するので、「Claudeが結果を会話に出せる形」で条件を書くのが重要です。

ちなみに条件は最大4,000文字まで書けます。

無限ループを避けたいときは、条件にターン数や時間の上限を含めておくと安心です。or stop after 20 turns のように書いておくと、Claudeが毎ターンその上限に対する進捗を報告し、評価器も判定材料にしてくれます。

注意点

/goalコマンドは便利な反面、押さえておきたい挙動がいくつかあります。

評価器が「会話に出ていない事実」は判定できない

何度も触れていますが、これが一番大事です。テストやビルドの結果はClaudeにコマンドを実行させて出力をターミナルに残させる、外部APIの状態はリクエスト結果を会話に貼らせる、といった「会話に証拠を残す」ステップを条件に含めるとブレません。

評価器のコストは小さいが0ではない

判定は small fast model（デフォルトHaiku）で行われ、メインターンと比べれば誤差レベルですが、毎ターン走るのでターン数が多いタスクではそれなりに積み上がります。/goal を叩いたあと放置するときは、たまに /goal で現在のトークン消費を確認しておくと良いです。

1セッション1ゴール

同時に複数のゴールは持てません。新しい条件で /goal を叩くと、現在のゴールはそのまま置き換えられます。並列でやりたい場合は別セッションを立てるか、ゴールに複数条件をまとめて書く運用になります。

まとめ

/goal は「完了条件を渡しておくと、Claudeがそこに到達するまで自走する」というシンプルながら面白いコマンドです。直感的に利用できるのではないでしょうか。

条件を会話の中で検証可能な形に書く、というコツさえ掴めば、API移行・大規模リファクタ・バックログ消化などの定量的なゴールが見える作業はかなり楽になりそうです。