Claude Code /goal コマンド完全活用ガイド — アウトカム駆動でAIに丸投げする

はじめに

Claude Codeに「全テストを通してから止めて」と頼んだのに、3回目のターンあたりで「完了しました」と言われてテストを確認したら実は2件失敗していた、という経験はないでしょうか。自分でコードを書いて自分で「できた」と判断するモデルに任せている限り、この問題は構造的に起きる。

VentureBeatは2026年5月、Claude Codeの新機能を紹介する記事でこう表現している。「*separates the agent that works from the one that decides it's done*（作業するエージェントと、完了を決めるエージェントを分ける）」。/goal コマンドの設計思想を一言で突いた表現だ。

Claude Code v2.1.139（2026年5月12日リリース）で追加された /goal は、「作業者」と「審判」を別モデルに分離することで、このセルフ完了宣言問題を解決する。使い方を理解すると、離席中に複数ターンの自律作業を回せるようになる。

/goal が解いた問題: セルフ完了宣言

従来の Claude Code は、各ターンを人間が起動し、出力を見て「もう一度やって」と追加指示する形でした。テストが通るまでリファクタを続けてほしいケースでも、毎回「まだ失敗してるから続けて」と入力し直す必要がありました。

/goal はこのループを自動化する。仕組みはシンプルで、各ターンが終わると別の軽量モデル（デフォルトはClaude Haiku）が会話履歴を読み、「条件は満たされたか」を yes/no で判定する。no ならその理由を次ターンへのヒントとして渡して継続し、yes でgoalがクリアされる。

評価器はツールを呼び出さない。Claudeが会話に出力した内容だけで判定する。つまり、テスト結果やビルドの exit code は Claude に出力させておく必要があり、この制約が後述する「condition の書き方」に直結する。

コマンドの基本操作

# goal を設定する
/goal <条件文>

# 現在の goal の状態を確認する（経過時間・ターン数・トークン消費・直近の評価理由）
/goal

# goal を解除する
/goal clear

/goal clear の代わりに stop、off、reset、none、cancel でも同じ動作をする。中断したい場合は Ctrl+C だ。

セッションに同時にアクティブな goal は1つだけで、新しい条件を /goal <新条件> で入力すれば既存の goal は上書きされる。条件文字列の上限は4,000字なので、複合条件をかなり詳細に記述できる。

一点注意として、/goal はhooksシステムの一部として動作するため、workspaceでtrustダイアログを受諾している必要がある。disableAllHooks が有効な環境では動かない。

効果的な condition の書き方

条件が曖昧だと評価器が判定できず、goalが永遠にクリアされないか、逆に中途半端な状態でクリアされる。公式ドキュメントが示す構成要素を押さえておくと、評価器の精度が別物になる。

測定可能な終了状態を書く

「コードをきれいにする」ではなく、「npm test が exit 0 で終わる」「git status がクリーン」のように、機械的に確認できる状態を書く。評価器はClaudeの出力から判定するので、Claudeがターン内でその状態を出力できる形にしておく必要がある。

証明方法を書く

終了状態だけでなく、それをどう確認するかも書いておくと評価精度が上がる。

/goal All TypeScript errors are resolved.
  Proof: `tsc --noEmit` exits 0 with no output.

守るべき制約を書く

「他のテストファイルを変更しない」「本番コードにコンソールログを残さない」など、達成の過程で破ってはいけないルールを添える。これがないと、テストを削除してテストを通す、という抜け道が生まれることがある。

暴走防止のターン上限

条件が難しい場合や不確実性が高い場合は、condition に or stop after 20 turns のように上限を書いておく。

/goal All npm audit vulnerabilities are patched and CI is green,
  or stop after 15 turns.
  Constraint: do not change any test files.

実際のユースケース

モジュール移行

古いAPIへの呼び出しを新APIに全て置き換えるタスクだ。数十ファイルにわたる場合、手動で確認しながら進めるより goal に任せた方が安定する。

/goal All calls to legacyHttpClient have been replaced with fetchClient.
  Proof: `grep -r "legacyHttpClient" src/` returns no results.
  `npm test` exits 0.
  Constraint: do not modify files under src/test/.

issueバックログ消化

GitHub issueにラベルを付けておき、それを順番に処理させるパターンだ。

/goal All issues labeled "chore" in the backlog are closed.
  Proof: `gh issue list --label chore --state open` returns an empty list.
  Constraint: each fix must have a corresponding passing test.

test-driven リファクタ

既存テストをアンカーにしながら内部実装を整理したいときに使います。

/goal auth.ts is refactored to use dependency injection.
  Proof: `npm test -- auth` exits 0, coverage for auth.ts >= 90%.
  Constraint: the public interface of AuthService must not change.

コードスニペットを書きながら気づくのですが、日本語で条件を書いても動きます。ただし、grep や tsc などのコマンド出力を証明に使う場合は、Claudeがターン内でそのコマンドを実行して結果を出力する必要があるため、英語のほうが誤解が少ないという印象です。

暴走リスクと使うべきでない場面

無限ループ

評価器が「まだ条件を満たしていない」と判定し続けているのに、Claudeが同じアプローチを繰り返すケースがある。前述の or stop after N turns が最も手軽な対策で、/goal でターン数とトークン消費を定期確認する習慣も持っておきたい。

条件が主観的なケース

「読みやすくする」「パフォーマンスを改善する」のような条件は評価器が判定できない。Lighthouseスコアや実行時間のミリ秒など、数値で表現できる終了状態に変換してから使う。

# NG: 主観的で評価不能
/goal Make the code more readable.

# OK: 測定可能
/goal Lighthouse performance score >= 95 on the top page.
  Proof: Lighthouse CLI report shows Performance: 95 or above.

コストへの注意

メインターンが複数回走るので、長時間goalを回すとトークン消費が積み上がる。評価器自体はHaikuで動くので低コストだが、メインモデルのコストは通常通りかかる。離席前に /goal で現在のトークン消費を確認しておくと予算管理しやすい。

本番環境への副作用があるタスク

本番DBへの書き込みや外部APIへの大量リクエストを含むタスクには使わないほうがいい。goalが想定外の方向に進んでも、自動で止まる保証はない。

/loop・Auto mode との使い分けと、離席中タスクへの応用

/goal、/loop、Auto mode は似ているようで役割が違う。

	次のターンが起動する条件	停止する条件
`/goal`	前ターンが終了	評価モデルが条件成立と判定
`/loop`	時間間隔が経過	ユーザーが停止、またはClaudeが完了と判断
Auto mode	ー（新ターンを起動しない）	ツール承認ダイアログを省略するだけ

Auto mode と /goal は補完的な関係だ。Auto mode はツール承認の確認ダイアログを省略し、/goal はターン間の人手介入を省略する。両方を組み合わせると、「完全に離席したまま条件クリアまで回す」という運用が現実的になる。

さらに /goal は -p フラグ（非対話モード）にも対応しているので、次のようにヘッドレスで単発起動できる。

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week. Proof: file contains today's date and at least one PR number."

Channelsでバックグラウンドセッションを立ち上げてこれを実行し、完了をDiscordに通知させる構成にすると、朝起きたら作業が終わっている、という運用が組める。このブログでも近いうちに試してみたい。

まとめ

/goal の本質は、「自分で書いて自分で完了と判断するAI」という構造を崩したことだ。Haikuによる外部評価を挟むことで、中途半端な完了宣言が減り、複数ターンの自律作業が現実的になった。

結局のところ、使いこなせるかどうかは condition の書き方にかかっている。終了状態・証明方法・制約の3点を書くだけで評価器の精度が別物になる。小さなリファクタやバックログ消化から試してみると、条件の書き方の感覚がつかめてくる。