何が起きたら止めるかを、仕組みを動かす前に決める。今回の起点はここだ。
第3部までで、差分でレビューし、仕事をループに分解するところまで来た。ここから先の風景は少し変わる。今までは、あなたが「やって」と言うたびに1つの仕事が始まっていた。朝起きたらPRのレビューコメントが済んでいる。夜間にログを見て回っている。誰かが呼ばなくても、決まった条件で始まる仕事が増えていく。これがステップ3の入口、仕事のほうが先に動き出す状態だ。
これは便利であると同時に、危険でもある。人が起動するあいだは、暴走しても止める人がその場にいた。仕組みが起動するようになると、止める人がその場にいない時間が生まれる。だからこの段に入る最初の作業は、新しい機能を覚えることではない。今日はその決め方を、2つの起動方式に分けて見ていく。
二つの起動方式: /loopと/goal
Claude Codeが自律的に次のターンを始める仕組みには、性格の違う2つがある。/loopは時間で動き、/goalは条件で動く。
| 方式 | 次のターンが始まる条件 | 止まる条件 |
|---|---|---|
| /loop | 決めた時間間隔が経過したとき | ユーザーが止める、またはClaudeが完了と判断する |
| /goal | 前のターンが終わったとき | 評価モデル（既定はHaiku）が完了条件の達成を確認したとき |
/loopには2つの使い方がある。/loop 5m ... のように間隔を固定するやり方と、間隔を書かずに任せるself-pacing dynamic modeだ。後者では、Claude自身が1分から1時間の範囲で次に起きる時間を毎回選び、ScheduleWakeupという仕組みで次の起床を予約する。
プロンプトなしで /loop とだけ打つと、未完了作業の確認・PR対応・クリーンアップをこなす組み込みのメンテナンスループが動く。これは .claude/loop.md で上書きできる。
/goalはもっと単純だ。完了条件を1つだけ決める。ターンが終わるたびに小さなモデルがその条件を満たしたかを判定し、満たしていなければ次のターンを自動で始める。中身は「セッションスコープのprompt-based Stop hook」に近い。
視点
定期点検と閾値対応の関係に近い
設備保全に例えると分かりやすい。/loopは定期点検に近い。決まった間隔で、状態を見ずに実行される。/goalは閾値対応に近い。「在庫が10個を切ったら発注する」のように、条件が満たされたときだけ動く。
どちらが優れているという話ではない。定時の巡回が要る仕事には/loop、ある状態に到達するまで粘る仕事には/goalが向いている。
/loopがやろうとしていることを、もっと粗い形ですでに実践していた人がいる。Geoffrey Huntleyが名付けた「Ralph Wiggum」という技法だ。中身は、while :; do cat PROMPT.md | claude-code ; done のような、プロンプトファイルをbashの無限ループで流し込み続けるだけの、驚くほど単純な仕組みにすぎない。
“There's no way in heck would I use Ralph in an existing code base. This works best as a technique for bootstrapping Greenfield.”
筆者訳既存のコードベースでRalphを使うことは絶対にない。これはグリーンフィールド、つまり何もないところからの立ち上げの技法として最も機能する。
考案者本人がここまで明確に線を引いている。/loopや/goalを、すでに動いている本番コードに向けるときほど、この限界を思い出したほうがいい。
/loopが向く仕事、/goalが向く仕事
向き不向きは、仕事の性質で決まる。
- 夜間のログ監視、定期的な健康チェック
- 「1時間ごとに未マージPRを確認する」のような巡回作業
- 終わりが明確でない、継続そのものが目的の仕事
- 「全テストがgreenになるまで直す」のような到達点が明確な仕事
- リファクタリングや移行作業など、完了の定義ができる仕事
- 何度もターンを重ねてでも、条件を満たすまで粘ってほしい仕事
見分け方は単純で、「終わったと分かる条件を1文で書けるか」を自分に聞くだけでいい。書けるなら/goal、書けずに「とにかく定期的に見ておいてほしい」としか言えないなら/loopだ。
実際の起動イメージ
書いてしまえば、どちらも数秒で起動する。
$/loop 1h "未マージのPRを確認し、CIが通っていて差分が小さいものにレビューコメントを書く"
Loop scheduled. Next run in 1h. Stop anytime with /loop stop.
$/goal "npm run typecheck のエラーが0件になる"Goal set. Evaluator: Haiku (default). Checking after each turn.
問題は、起動した後に何が起きるかを、起動する前に想像できているかどうかだ。
Boris Chernyは、自分の日常の使い方についてこう語っている。
“I don't prompt Claude anymore. I have loops prompting Claude and figuring what to do.”
筆者訳もう自分でClaudeにプロンプトを送っていない。ループがClaudeにプロンプトを送り、何をすべきか判断している。
Borisは自分の働き方の変化を、3段階の推移として語ったとされる。最初は自分でコードを書いていた。次にClaudeへプロンプトを書くようになった。そして今は、cronでスケジュールされた繰り返しジョブ、つまりループのほうがClaudeにプロンプトを送り続けている。今の自分の仕事は「ループを書くこと」だと表現しているという。
ここで見落としてはいけないのは、この状態にいきなり到達したわけではないということだ。ループがプロンプトを送るようになる前に、そのループが何をどこまでやっていいか、いつ止まるべきかの設計が先にある。順番を逆にすると、ループはただ暴走するだけの装置になる。
権限モードは変わらない、という罠
ここが初学者がいちばんつまずく場所だ。/loopも/goalも、権限モード自体は変えない。
注意
夜間ループが朝まで止まっている罠
/loopや/goalを設定しても、Claudeが実行しようとした操作が許可を必要とするものであれば、許可プロンプトでそのまま止まる。人が寝ている間は、誰も許可を出さない。
朝になって「何も進んでいない」と気づいたとき、原因の大半はこれだ。ループの設計は正しくても、権限設計が追いついていなかった。無人で回すつもりのループは、autoモード（第10回で扱った許可設計）と必ず組みで考える。
これはステップ2までの感覚が通用しなくなる典型例でもある。第10回で見た「事前許可の設計」は、ステップ2ではレビューの手間を減らすための工夫だった。ステップ3に入ると、それはループが夜通し動けるかどうかを決める前提条件になる。同じ機能でも、意味の重さが変わる。
Routines・Desktop scheduled tasks・/loopの違い
自律継続には3つのスケジューリング手段があり、動く場所が違う。
表の「クラウド実行」は、もう少し中身を見ておく価値がある。Routinesは、1つのプロンプトと1つ以上のリポジトリ、使うconnector群をひとまとめにして保存し、Anthropicが管理するクラウド側で動かす仕組みだ（現時点ではresearch preview扱いで、仕様は今後変わりうる）。起動のきっかけは3種類あり、併用もできる。Scheduled（定期実行、または未来の一回だけの実行）、API（bearerトークン付きのPOSTで即時起動し、応答にセッションのURLが返る）、GitHub（プルリクエストやリリースなどのイベントに反応し、フィルタで対象を絞り込める）。
公式ドキュメントが挙げている使いどころは、幅が広い。
/loopには制約もある。セッションスコープで、7日で失効し、間隔には最大30分のジッターが入る。「毎日決まった時刻に必ず」を求めるなら、/loopではなくRoutinesかDesktop scheduled tasksの領分になる。
設計の手順
ループを組む前に、4つを先に決める。
4番目の「上限を刻む」は、次の第17回（コスト規律）でさらに深く扱う。ここでは、上限のないループは存在しないということだけ覚えておけばいい。
よくある誤解と罠
- 「ループにすれば止まらない」と思っている: 実際には/goalも/loopも、評価のたびに止まれる。止まらないのではなく、止まる判断を仕組みに預けているだけだ
- auto modeにすれば安心だと思っている: 権限を広げるほど、ガードレールの設計の重責が増す。これは楽になることと同義ではない
- /goalの評価が甘いと勘違いする: 既定の評価モデルはHaikuで、単純な判定に向いている。複雑すぎる完了条件を渡すと、評価自体が不安定になる
今日のまとめ
- /loopは時間駆動、/goalは条件駆動。終わりを1文で書けるかで使い分ける
- 権限モードは変わらない。無人運用はautoモードとの組み合わせが前提
- ループを組む前に、目的・終了条件・権限・上限の4つを先に決める
明日のアクション
自分が今、手作業で繰り返している仕事を1つ選んでください。
その仕事について次の3つを書き出します。(1) /loopと/goalのどちらに向くか (2) 終了条件、または巡回間隔 (3) 無人で走らせる場合に引っかかりそうな許可プロンプトが何かないか
書けなければ、まだループにする段階ではありません。曖昧さが残っているということです。
次回、第14回では、この仕組みが今度は自分で別のClaudeを起動する場面に入ります。