こんにちは。もるふぉです。
Claude Code の /loop というスラッシュコマンドの話をします。
Claude Code を作った Boris Cherny さんが、あるインタビューでこう語っています。
「自分はもう Claude に直接プロンプトを打っていない、代わりに loop を書くのが仕事になった」
え、Claude Code の生みの親が Claude Code にプロンプトを打ってない?って二度見しますよね。
毎回プロンプトを打ち直して、CI を待ちながらターミナルを眺め続けて、レビューコメントが来たら通知を確認して……そのループ、全部 Claude に回させられます。
この記事では、/loop の何が cron と決定的に違うのか、なぜ Boris さんがそう言うのか、そして実務で使える設計パターンを 3 つ紹介します。
Claude Code /loop とは何か — cronジョブとの決定的な違い
/loop はセッション内で同じプロンプトを繰り返し実行するスラッシュコマンドです。
/loop 5m check if the deployment finished and tell me what happenedこれだけで「5 分ごとにデプロイ状況を確認して報告する」ループが走ります。
間隔は s(秒)m(分)h(時)d(日)で指定でき、別のコマンドを引数に渡すこともできます(例: /loop 20m /review-pr 1234)。
cron との決定的な違いは「セッションの文脈を保持したまま回り続ける」点です。
cron は毎回新しいプロセスを立ち上げ、文脈ゼロから処理をやり直します。
一方 /loop は同じ会話セッションの中で動くので、前回の調査結果、前回読み込んだ CLAUDE.md、前回見た PR のコメント、すべて引き継いだ状態で次のイテレーションに入ります。
cron が「忘れっぽい掃除機」だとしたら、/loop は「ずっと現場にいる秘書」です。
仕様で押さえておきたい点はこちらです。
- セッションが開いている間だけ動く(ターミナルを閉じると止まる)
- 7日のセッション有効期限がある(公式は recurring task の自動消滅期限を 7 日と定めている)
--resume--continueで復元可能(有効期限内であれば)- 1 セッションに最大 50 タスクまで保持可能
定期実行であって永続実行ではない。
この前提は押さえておく必要があります。
仕様はわかった、でも「なぜ Boris さんはループを書くのが仕事だと言うのか」——そこに踏み込みます。
Borisが「loopを書くのが仕事」と言う理由
Boris さんは WorkOS × Acquired の対談で、自分はもう Claude にプロンプトを直接打っていない、代わりに自分のためにプロンプトを打ち、次に何をビルドするかまで決めてくれる loop を書いている、と語っています。
これは省力化の話ではありません。
エンジニアの仕事の定義を書き換える話です。
同じインタビューで Boris さんは Anthropic 社内の働き方にも触れています。
本来必要だと思う人数よりあえて少ない人手でプロジェクトを組む。
トークンは潤沢に渡す。
あとは何とかしろ、というスタンスだそうです。
さらに
「全員がビルダーになる。デザイナーもコードを出す。財務担当もコードを出す。チーフオブスタッフもコードを出す」
とも語っています。
AI を「指示待ち作業者」ではなく「自走するチームメンバー」に変えるための仕掛けが /loop です。
人間がやるのは「ループをどう設計するか」「どんな条件で止めるか」を決めることだけ。
実行は AI がセッションの中で回す。
「プロンプトを打つ仕事」から「ループを設計する仕事」への転換です。
ここまで来ると「で、実際どう書けばいいの?」ってなりますよね。
次がその核心部分です。
セルフペーシング(self-pacing) — /loop の真の使い方
/loop には固定インターバルの他に、インターバルを省略するパターンがあります。
/loop check whether CI passed and address any review comments間隔を書かずプロンプトだけ渡すと、Claude が次の起動タイミングを自分で決めます。
ビルドが終わりかけなら短い間隔で、PR が静かなら長い間隔で。
1 分から最大 1 時間の範囲で、内部の ScheduleWakeup が delaySeconds として次の起動タイミングを決定します。
つまり「今は待つべきか、今すぐ確認すべきか」をClaude が空気を読んで判断する、ということです。
固定インターバルとの使い分けはシンプルです。
- 固定インターバル: チェック間隔そのものに意味があるとき(例: 監査ログを 1 時間ごとにスナップショット)
- セルフペーシング: 完了判定が必要なとき、状況に応じて待ち時間を変えたいとき(例: CI 監視、PR 監視、デプロイ確認)
セルフペーシングのもう一つの強みは、Claude が「タスク完了した」と判断したらループを自然終了できる点です。
固定インターバルだと自分で Esc を押すか有効期限切れを待つしかありません。
セルフペーシングを使うとループが「監視」から「判断付き作業」になり、人間が「貼り付き作業」から解放されます。
「わかった、使いたい。具体的には何を走らせればいい?」——3 パターンで整理します。
自律ループ設計の3パターン(実務でそのまま使える)
パターン1: 監視・ポーリング型ループ
CI 待ち、デプロイ待ち、長時間バッチの完了確認。固定インターバルが向きます。
/loop 3m check the staging deploy status and notify me when it finishes業務システムの長めの集計バッチを回すとき、終わったらすぐ次の作業に移りたい場面で使います。
「貼り付かなくていい」「忘れていい」が手に入ります。ターミナルを眺め続ける時間が、設計を考える時間に変わります。
パターン2: セルフペーシング型ループ
PR 監視、レビューコメント対応、不安定なテストの追跡。「終わったら止めてほしい」場面に向きます。
/loop check whether CI passed and address any review comments私はクライアント案件の PR を出した後、ローカルの Claude Code でこれを走らせっぱなしにしておきます。
CI のフィードバックが返ってきたら自動でコメントを読みに行き、必要ならパッチを書く。
すべて静かになったら自分で止まる。
レビュアーが「ここ直して」と書いた瞬間にローカルが反応する感じです。
人間は別のタスクに集中していていい。
パターン3: スキル連携型ループ
事前に作っておいたスラッシュコマンドを定期実行するパターンです。
/loop 30m /babysit-prs/babysit-prs のような自作スキルを ~/.claude/skills/ に置いておけば、ループのプロンプトとして直接呼び出せます。
プロジェクトごとに .claude/loop.md を置けば、/loop 単体実行時のデフォルトプロンプトを書き換えることもできます。
複数のクライアント案件を並行で走らせていると、PR の数がすぐ二桁になります。
「PR 全部を見守るスキル」をループに乗せておくと、自分は別の設計タスクに集中できます。
いわば「PR 番人」を Claude Code に任命する感覚です。
3 パターンを使いこなすには、/loop と似た機能との違いを押さえておく必要があります。
/loop と Routines・Desktopタスクをどう使い分けるか
/loop: ローカルセッション内で動く。マシン稼働&セッションオープン必須。文脈を保持- Routines: Anthropic クラウド上で動く。マシンオフでも回る。文脈は毎回リセット
- Desktop scheduled tasks: ローカルマシン上で OS スケジューラ的に動く。セッション不要だが文脈はリセット
判断基準は「同じ会話の続きとして回したいか」です。
文脈を捨てていいならクラウド(Routines)かデスクトップ、捨てたくないなら /loop です。
/loop を「永続スケジューラ」として使うとセッション切断で止まります。Routines を「文脈付き作業」に使うと、毎回フレッシュなセッションで似た確認をやり直すことになる。役割が違う、と覚えておけば事故りません。
まとめ — 「ループを設計する」が次のエンジニアの本業になる
Claude Code /loop の本質は「文脈を保持したまま、AI が自分で次の起動タイミングを決め、完了したら自分で止まる」仕組みにあります。
人間がやるのは「どんな条件で動かし、どんな条件で止めるか」を設計することだけです。
冒頭の Boris さんの話に戻ります。
自分はもうプロンプトを打っていない、loop を書くのが仕事だ、という話。
エンジニアの仕事がコードを書くことから設計に移ったのが過去 10 年の流れだとしたら、これからは「ループを設計すること」が本業になります。
プロンプトを 100 回打つより、止め方まで決めた 1 本のループのほうが、桁違いに仕事が進むからです。
まずは今開いているセッションで /loop check the deploy か /loop 5m /babysit-prs を 1 本走らせてみてください。
コマンド 1 行です。
CI 待ちでターミナルを眺める時間、PR コメントを 5 分ごとに確認する時間、デプロイログを追い続ける時間——その「貼り付き時間」が、設計や別の案件に使える時間に変わります。
参考リンク:





💬 コメント
ログイン か 会員登録 するとコメントできます