01 — どう動くのか
実行する Claude と、完了を判定する評価者を分ける
ターンが終わるたび、条件と会話ログが小さく速いモデル（既定は Haiku）へ渡される。評価者は Yes / No と短い理由 を返すだけ。No なら理由を手がかりにもう1ターン、Yes ならゴールを自動クリアしてあなたに制御が戻る。
🧑あなた条件をセット
→
⚙Claude（実行）1ターン作業する
→
◎評価者 Haiku会話ログで判定
→
⟂条件は達成？
No → もう1ターン
Yes → 制御を返す
02 — 触って試す
ゴール・シミュレーター
事例を選んで「実行」を押すと、/goal のループを擬似的に再生します。ターンごとに作業し、評価者が判定し、達成したら ✓。実際の挙動のイメージを掴むためのデモです。
GOAL
03 — カタログ
/goal 活用事例 10選
「検証可能な終了状態のある、まとまった作業」に /goal は効く。各カードの ▶ シミュレート を押すと、その事例をデモで再生します。
04 — 効く条件の書き方
良い終了条件は、会話ログだけで証明できる
評価者はコマンドを実行せず、ファイルも独自には読まない。Claude が会話に出した内容だけで判定する。だから「Claude の出力で示せる形」で条件を書く。下の各パーツにカーソルを合わせてみてください。
/goal
test/auth が全部パスし lint がクリーンになるまで。
npm test が exit 0 を返すことで確認する。
他のテストファイルは変更しない。
または 20 ターンで停止。
- 測れる終了状態テスト結果・ビルドの exit code・ファイル数・空のキュー など、1つの計測可能なゴール。
- 証明の方法「npm test が exit 0」「git status がクリーン」など、達成をどう示すか。
- 守るべき制約途中で壊してはいけないもの。「他のテストは変更しない」など。
- 上限（任意）「20ターンで停止」「90分で停止」。暴走とコスト超過の歯止め。
DO
会話で示せる条件にする
「テストを実行してその出力を報告し、全部 green であること」。評価者は出力を読んで判定できる。
DON'T
ログに出ない条件は避ける
「ファイルが存在する」など、評価者が独自に確かめられない断定はNG。会話に現れないものは判定できない。
CAP
夜間ゴールには必ず上限
ハードなトークン上限は無い。条件に「Nターン / N分で停止」を入れ、auto mode で確認待ちの停止を防ぐ。
05 — 似た仕組みとの使い分け
次のターンを始めるのは 何か？で選ぶ
セッションを走らせ続ける方法は複数ある。「いつ次のターンが始まり」「いつ止まるか」で選ぶ。
| 方法 | 次のターンが始まる契機 | 止まるとき | 向いている用途 |
|---|---|---|---|
/goal |
前のターンが終わったとき | モデルが条件の達成を確認 | 検証可能な終了状態のある作業 |
/loop |
一定の時間間隔ごと | 手で止める / 完了とClaudeが判断 | 定期ポーリング・繰り返し実行 |
| Stop hook | 前のターンが終わったとき | 自作のスクリプト/プロンプト次第 | 全セッション共通の独自判定 |
| auto mode | （新ターンは始めない） | Claude が作業完了と判断 | ツール承認の自動化。/goalと併用 |
◎
auto mode と /goal は補完関係。 auto mode が「ツールごとの確認」を消し、/goal が「ターンごとの確認」を消す。重ねると、無人で条件まで走り切る。