/goal を使い倒す

コース構成

このコースで学ぶこと

1. 01

   /goal とは何か

   完了条件を渡すと、評価モデルが yes/no 判定 → 達成まで自動で次のターンを始める。Claude Code v2.1.139 で追加された機能。

   `/goal <条件>` で完了条件を渡すと、各ターン終了後に小さな評価モデル（既定: Haiku）が条件成立を判定します。no なら Claude が自動的に次のターンを開始、yes なら完了として transcript に残り、ゴールはクリアされます。

   要するに「ここまで行ってね」と一度言うだけで、達成するまで自動で走り続けるモード。**`/loop`（時間駆動）や Stop hook（毎ターン任意処理）と相補的**で、`/loop` は時間で再実行、`/goal` は完了条件で再実行、という違い。

   用語: /goal の詳細

   理解度チェック

   1. Q1.`/goal` の各ターン終了後、次のターンに進むか判定するのは？

      Aユーザーが手動で承認するBメイン Claude 自身が判定するC小さな評価モデル（既定: Haiku）が transcript を読んで yes/no を判定するDGitHub Actions が判定する
   完了条件の書き方
2. 02

   完了条件の書き方

   評価モデルは Claude の transcript を読んで yes/no を判定します。Claude 自身の出力で『証明できる』形に書くのがコツ。

   条件は最大 4000 字まで。「`npm test` exits 0」「`git status` is clean」のような検証コマンドを含めると、評価モデルが安定して判定できます。

   抽象的な条件（「うまく動くこと」）だと判定が揺れて goal が完了しません。**具体的な検証コマンドと観測可能な事実を必ず入れる**のが成功の鍵。

   • ✅ 1 つの測定可能な end state — テスト結果・ビルド終了コード・空キュー・ファイル数
   • ✅ 確認手順を明示 — 「`npm test` exits 0」「`git status` is clean」
   • ✅ 制約事項を明示 — 「他のテストファイルは変更しない」
   • ❌ 抽象的すぎる — 「うまく動く」「品質が高い」「読みやすい」

   text

   # 良い例（具体）
   /goal all tests in test/auth pass and `pnpm lint` exits 0
   
   # 良い例（範囲限定）
   /goal `src/api/users.ts` を 200 行以内に分割。新ファイルにのみ書き、既存テストは全 green を維持
   
   # 悪い例（抽象的）
   /goal バグを直す
   
   # 悪い例（検証手段なし）
   /goal ユーザー登録フローが綺麗になる

   公式: /goal の書き方

   理解度チェック

   1. Q1./goal の完了条件として最も“良い”書き方は？

      A「綺麗になる」「品質が高い」B「`pnpm test` が exit 0、`pnpm lint` が exit 0、test/auth が全 pass」のように検証コマンドと観測事実で書くC「うまく動くこと」D「ユーザーが満足するまで」
   /goal とは何か暴走防止の三段防御
3. 03

   暴走防止の三段防御

   条件が緩いと永遠にループするリスクがあります。3 つの安全弁を必ず張ります。

   • **条件文の中に上限句**: 「or stop after 20 turns」を入れる。評価モデルが「20 ターン到達」を yes と判定して止まる
   • **Auto モードの分類器**: ツール結果を見ないので、注入された指示で誘導されない
   • **deny ルール**: `.claude/settings.json` の deny で致命操作を予めブロック

   text

   # 上限句つき goal
   /goal all e2e tests pass
   or stop after 30 turns
   or stop if any test in test/critical/** fails

   FAQ: /goal の暴走防止

   理解度チェック

   1. Q1./goal を初めて試すときの安全な権限モードは？

      Aauto + sandbox なしBplan モードで読み取り中心の動きを観察してから、auto + sandbox に段階移行C全権限フリーDdeny を全部外す
   完了条件の書き方/loop と Stop hook との使い分け
4. 04

   /loop と Stop hook との使い分け

   3 つの自動化方式の違い。次のターンが「何をきっかけに」始まるかで選ぶ。

   • 🕒 `/loop <interval> <cmd>` — **時間間隔**ごとに再実行。PR の CI 監視・夜間バッチ向き
   • 🎯 `/goal <条件>` — **条件達成**まで再実行。テスト全 green・移行完走・バックログ消化向き
   • ⚓ Stop hook — **毎ターン任意処理**。lint・テスト走らせ・通知。決定論的な処理向き

   FAQ: /goal vs /loop

   理解度チェック

   1. Q1.「PR の CI ステータスを 5 分おきに見続けてほしい」というユースケースに最適なのは？

      A`/goal` で完了条件を渡すB`/loop 5m '...'` で時間間隔ごとに再実行するCStop hook で毎ターン後に実行するDSubagent を起動する
   暴走防止の三段防御実例 5 つ — 条件文サンプル
5. 05

   実例 5 つ — 条件文サンプル

   実際に動く条件文のサンプル集。コピペで使えます。

   text

   # 1. テストカバレッジ底上げ
   /goal `pnpm test --coverage` が 80% 以上、test/legacy/** は除外
   or stop after 40 turns
   
   # 2. レガシー API 全移行
   /goal すべての `getUserById_v1` の呼出元を `getUser({id})` に置き換え、
   `grep -r 'getUserById_v1' src/` の結果が空になる
   or stop after 30 turns
   
   # 3. 大きいファイルを分割
   /goal `src/api/users.ts` を 200 行以内に分割。
   `wc -l src/api/users.ts` が 200 未満、`pnpm test` exits 0
   
   # 4. CHANGELOG.md を埋める
   /goal 今週マージされた全 PR について CHANGELOG.md にエントリを追加
   `git log main --since='1 week ago' --grep='Merge'` の各 PR がカバーされる
   
   # 5. Issue バックログを消化
   /goal label:bug かつ priority:high の Issue を全部修正済みにする
   `gh issue list -l 'bug' -l 'priority:high' --state open` の出力が空
   or stop after 50 turns

   理解度チェック

   1. Q1.`/goal` の条件文に必ずセットで書きたい“安全弁”は？

      A実行モデルを Haiku に固定するB`or stop after N turns` のようなターン上限C結果を全部 Slack に投げるD`/clear` を毎ターン呼ぶ
   /loop と Stop hook との使い分け