🕌

Claude Code の /goal で「完了まで自律実行」を実現する

に公開
AI
自動化
Claude
Claude Code
tech

はじめに：毎ターン「続けて」と打つのが面倒

Claude Code でテスト修正やモジュール移行のような長い作業をしていると、こんな体験をしませんか。

Claude がテストを1つ直して止まる → 「続けて」 → もう1つ直して止まる → 「続けて」 → まだ3つ残ってる → 「続けて」…

auto mode はツール呼び出しの承認を省いてくれますが、ターンが終わるたびに止まるのは変わりません。10個のテストを直す作業に、10回「続けて」と打つのは人間のほうがボトルネックです。

この壁を取り払うのが /goal です。「全テストが通るまで」と完了条件を1行書くだけで、Claude が条件達成まで自律的にターンを繰り返します。本記事は /goal の仕組み・使い方・効果的な条件の書き方・類似機能との使い分けまで解説します。

/goal とは何か

/goal は、完了条件を設定して Claude をゴールに向かって走らせ続けるコマンドです（v2.1.139 で追加）。

/goal test/auth のテストがすべて通り、lint もクリーンになること

これだけで Claude は「テストを実行 → 失敗を修正 → 再実行」を人間の入力なしで繰り返し、全テストが通ったら自動で止まります。

イメージは、通常の Claude Code が「1歩進むたびに指示を待つ犬の散歩」だとすると、/goal は「ゴールラインを引いてドッグランで自由に走らせる」感覚です。条件が満たされた瞬間にリードが引かれて戻ってきます。

仕組み

裏側では、Claude がターンを終了するたびに、条件と会話の内容があなたが設定した小さく高速なモデルに送信されます（デフォルトは Haiku）。このモデルが条件の成否を判定します。

評価器はツールを呼び出さず、Claude が会話中に表示した内容（テスト結果、ビルド出力など）だけを見て判定します。つまり条件は「Claude の出力で実証できるもの」でなければ機能しません。

似た機能との使い分け

Claude Code には「セッションを実行し続ける」方法が複数あります。選び方は「次のターンが始まるトリガー」と「止まる条件」の2軸で決まります。

アプローチ 次ターンの開始トリガー 止まる条件 向く用途
/goal 前のターンが終了 評価器が条件達成を確認 テスト修正、移行、バックログ消化
/loop 時間間隔（例: 5分ごと） ユーザーが停止 or Claude 判断 定期監視、CI ウォッチ
Stop hook 前のターンが終了 自作スクリプト/プロンプトが判断 カスタム評価ロジック
auto mode ―（ターン内のツール承認を省く） Claude の判断 ツール承認の省略

使い分けのポイント:

  • 検証可能なゴールがある → /goal（「全テスト通過」「ビルド成功」）
  • 定期的に繰り返す → /loop（「5分ごとに CI チェック」）
  • 独自の判定ロジックが要る → Stop hook（スクリプトで exit code を返す）
  • ツール承認だけ省きたい → auto mode

/goal と auto mode は併用可能で相互に補完的です。auto mode がツールごとの承認を省き、/goal がターンごとの承認を省くので、組み合わせると完全に自律的な実行が実現します。

使い方

Step 1: ゴールを設定する

Claude Code のプロンプトで /goal の後に完了条件を書きます。

/goal test/auth のテストがすべて通り、lint もクリーンになること

設定した瞬間にターンが開始されます。別途プロンプトを送る必要はありません。ゴールがアクティブな間は ◎ /goal active インジケーターが表示されます。

セッションごとに1つのゴールだけがアクティブになります。新しいゴールを設定すると前のゴールは置き換わります。

Step 2: 進捗を確認する

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

/goal

以下の情報が表示されます。

項目 内容
条件 設定したゴール文
実行時間 ゴール設定からの経過時間
評価ターン数 評価器が判定した回数
トークン支出 ゴール実行中に消費したトークン量
最新の理由 評価器が「なぜまだ未達成か」を説明するメッセージ

「最新の理由」は Claude が何に詰まっているかの手がかりになります。方針転換したいときは次のステップでクリアしてやり直せます。

Step 3: 必要に応じてクリアする

条件達成前に止めたいとき、または方針を変えたいときはクリアします。

/goal clear

以下のサブコマンド・エイリアスが使えます。

コマンド 動作
/goal <条件> ゴールを設定（既存があれば置き換え）
/goal 現在のステータスを表示
/goal clear アクティブなゴールを削除
/goal stop clear のエイリアス
/goal off clear のエイリアス
/goal reset clear のエイリアス
/goal none clear のエイリアス
/goal cancel clear のエイリアス

/clear で新しい会話を開始した場合もゴールは削除されます。条件が達成された場合は自動でクリアされるため、手動クリアは不要です。

Step 4（任意）: セッション再開で継続する

セッション終了時にアクティブだったゴールは、--resume や --continue で再開すると復元されます。

claude --resume

ただし、ターン数・タイマー・トークン支出はリセットされます。既に達成またはクリアされたゴールは復元されません。

Step 5（任意）: 非対話的に実行する

-p フラグと組み合わせると、1コマンドでゴールを設定して完了まで走らせられます。

claude -p "/goal 今週マージされた全 PR の CHANGELOG エントリが追記されていること"

CI/CD パイプラインやスクリプトから使う場合に便利です。Ctrl+C で中断できます。

効果的な条件の書き方

評価器は Claude が会話で表示した内容だけを見て判断します。評価器自身がコマンドを実行したりファイルを読んだりすることはありません。この制約を理解すると、効果的な条件が書けます。

良い条件の3要素

要素 説明 例
測定可能な終了状態 テスト結果、ビルド終了コード、ファイル数など npm test が終了コード 0 で完了する
述べられたチェック Claude がどう証明すべきかを明示 git status で未コミットの変更がないこと
重要な制約 過程で壊してはいけないもの 他のテストファイルは変更しないこと

良い例と悪い例

# 良い例: 測定可能で Claude が実証できる
/goal test/auth のテストがすべて通り、lint もクリーンになること

# 良い例: 制約付き
/goal Date.parse の呼び出しをすべて dayjs に移行する。テストが通り、他のファイルは変更しないこと

# 悪い例: 主観的で測定できない
/goal コードをもっと良くして

# 悪い例: 評価器が確認できない（Claude の出力に現れない）
/goal 本番サーバーのレスポンスが 100ms 以内になること

暴走防止: ターン/時間制限

条件にターンや時間の上限を含めると、達成できない場合の暴走を防げます。

/goal 認証テストがすべて通ること。20ターンで達成できなければ停止

Claude は各ターンで進捗を報告し、評価器が会話から上限到達を判断します。

実測：じゃんけんモジュールを /goal で自律実装させてみた

実際に /goal を使って、テスト駆動でじゃんけんロジックを実装させました。

準備

テストを先に8本書き、実装は throw new Error("not implemented") だけの空スタブを用意。

test/janken.test.ts
describe("judge", () => {
  it("グーはチョキに勝つ", () => {
    expect(judge("グー", "チョキ")).toBe("win");
  });
  it("チョキはパーに勝つ", () => { /* ... */ });
  it("パーはグーに勝つ", () => { /* ... */ });
  it("グーはパーに負ける", () => { /* ... */ });
  it("チョキはグーに負ける", () => { /* ... */ });
  it("パーはチョキに負ける", () => { /* ... */ });
  it("同じ手は引き分け", () => { /* 3パターン */ });
});
describe("randomHand", () => {
  it("グー・チョキ・パーのいずれかを返す", () => { /* ... */ });
});

この状態で全8テストが失敗することを確認し、/goal を実行。

/goal janken/ 配下のじゃんけんモジュールを実装し、npm test がすべて通ること

結果

項目 値
所要時間 38秒
ターン数 1ターン
コード変更 10行追加、4行削除
コスト合計 $1.43

/usage で確認したトークン内訳は以下の通りです。

モデル input output cache 読込 cache 書込 コスト
Opus 4.6（作業本体） 230 1.5k 541.6k 176.9k $1.42
Haiku 4.5（ゴール評価） 3 169 0 8.2k $0.01

1ターン・38秒で全8テストが通りました。Claude は空のスタブを読み、テストケースから仕様を理解し、勝敗判定テーブルと乱数生成を一度に実装。評価器（Haiku）が npm test の出力を見て「全テスト通過」を確認し、ゴールを達成としてクリア。

実測：コストの大半はシステムプロンプトや対象ファイルのキャッシュ読み書き（約718kトークン）です。Haiku による条件判定のコストは $0.01 で、/goal の仕組み自体にかかるオーバーヘッドは無視できます。

実践 Tips

  • auto mode と併用する: /goal だけだとツール承認で止まることがある。auto mode を有効にすると各ターンも無人で実行され、完全自律になる
  • エージェントビューと組み合わせる: claude agents で複数セッションを管理しながら、各セッションに /goal を設定すると並列自律実行ができる
  • -p でスクリプトに組み込む: claude -p "/goal ..." は CI/CD や定時バッチと相性が良い
  • 条件の途中経過を活用する: /goal で表示される「評価器の最新の理由」を見ると、Claude が何に詰まっているか分かる。詰まりが見えたら /goal clear してプロンプトで方針を修正し、再度 /goal を設定する

前提条件と制約

  • バージョン: v2.1.139 以降が必要
  • hooks の有効化: /goal は内部的に Stop hook として動作するため、disableAllHooks が設定されていると使えない（理由がメッセージで表示される）
  • allowManagedHooksOnly: 管理設定でこれが有効だと /goal は利用不可
  • 条件の最大長: 4,000 文字
  • 評価器のモデル: デフォルト Haiku。設定で変更可能
  • セッションスコープ: ゴールは現在のセッションでのみ有効。設定ファイルには保存されない

まとめ

/goal は「検証可能な終了状態がある作業」で真価を発揮します。

  • テスト修正 → 「全テストが通るまで」
  • モジュール移行 → 「全コールサイトがコンパイルされるまで」
  • バックログ消化 → 「キューが空になるまで」

判断基準はシンプルで、「何をもって完了とするか」を1文で書けるか?——書けるなら /goal、書けないならインタラクティブ、定期実行なら /loop です。auto mode と組み合わせれば、ツール承認もターン継続も不要な完全自律実行が手に入ります。まずはテスト修正のような小さな作業から試してみてください。

参考リンク

Discussion