Claude Code loopとは？/loopの使い方・間隔・注意点を解説

「デプロイが終わったか、何度も画面を見に行くのが面倒」「プルリクエストへのコメントやCIの結果を、気づいたら確認しておいてほしい」と感じたことはないでしょうか。

Claude Codeの/loopは、同じ依頼を、決めた間隔でくり返し実行してくれる機能です。「5分ごとにデプロイの状況を確認して、終わったら教えて」と頼んでおけば、Claude Codeを開いたまま別の作業ができます。ポーリング（一定の間隔で状況を確かめること）を、人が画面を見に行く代わりにClaudeにやらせる使い方です。

この記事では、/loopの書き方と動き方、依頼文の例、止め方と制限、似た機能（/goal、クラウドのルーティン、デスクトップの定期タスク）との使い分け、費用と権限の注意点までを順に解説します。内容は2026年10月時点のClaude Code公式ドキュメントをもとにしています。数値や仕様は変わることがあるので、使う前に公式ページもあわせて確認してください。

Claude Codeの/loopとは

/loopは、Claude Codeに最初から入っている「スキル」（Claudeに詳しい手順を与える仕組み）のひとつです。公式ドキュメントでは「セッションを開いたまま、依頼をくり返し実行する」ためのものと説明されています。別名として/proactiveでも呼び出せます。

たとえば、次のように入力します。

/loop 5m check if the deployment finished and tell me what happened

日本語で書いても問題ありません。「/loop 5m デプロイが終わったか確認して、結果を教えて」のように、間隔のあとに依頼を続けるだけです。Claudeはこの間隔を内部で「cron式」（決まった時刻に実行する予定を表す書き方）に変換して予定を登録し、周期とジョブID（予定の番号）を返してくれます。

3通りの書き方

/loopは、間隔と依頼のどちらを書くかで動きが変わります。公式ドキュメントでは、次の3通りが紹介されています。

つまり、「何分ごとに何をするか」を自分で決めたければ間隔と依頼の両方を書き、「様子を見ながら間隔を調整してほしい」なら依頼だけを書きます。何も書かなければ、プルリクエストの面倒を見る汎用の依頼が動きます。それぞれの詳しい動きは、次の「使い方」で説明します。

どんな仕事に向いているか

公式ドキュメントでは、使い道として「デプロイの状況を確かめる」「プルリクエストを見守る」「長いビルドの終わりを確かめに行く」「あとで何かをやり直すための覚え書き」が挙げられています。共通しているのは、自分が張りつかなくても、時間が経てば状況が変わる仕事です。

一方、「Webサイトを毎朝チェックして、結果をメールで送る」のように、パソコンやClaude Codeを閉じていても動いてほしい仕事は、/loopの得意分野ではありません。/loopはセッション（Claude Codeを開いている間の会話）の中でだけ動くためです。この違いは、のちほど「他の方法との使い分け」で詳しく説明します。

向いていない仕事

/loopは便利ですが、何でも任せられるわけではありません。次のような仕事は、別の方法を選んだ方が確実です。

1日の流れで見る使い方

更新作業を公開する担当者が、午後にWebサイトの更新を反映する場面を例に、時系列で追ってみます。画面の表示は環境によって異なりますが、使い方の流れはこのようになります。

1. 公開の作業を始めるいつもの手順で、更新を本番に反映する作業を始めます。反映が終わるまで数十分かかる環境だとします。
2. 確認の依頼を出すClaude Codeに「/loop 5m 本番への反映が完了したか確認して。完了したら結果を1行で報告して、この予定を取り消して」と入力します。
3. 別の作業に戻る反映を待つあいだは、同じセッションで別の質問をしたり、次の作業の下書きを頼んだりできます。5分ごとの確認は、Claudeの手が空いたときに実行されます。
4. 完了の報告を受ける反映が終わると、Claudeが結果を報告し、予定を取り消します。
5. 予定が残っていないか確かめる「いま動いている予定を一覧で教えて」と頼み、取り消されていることを確かめます。

この使い方のよい点は、確認のためだけに画面の前に張りつかなくてよいことです。反対に、確認が終わったあとも予定が残ると、使用量を消費し続けます。終わりの条件と取り消しを、依頼の中に書いておく理由がここにあります。

/loopが動く仕組み

/loopの裏側では、Claude Codeの「スケジューラ」が動いています。スケジューラは1秒ごとに「実行する時刻になった予定があるか」を確かめ、あれば順番待ちの列に入れます。ここで押さえておきたいのは、次の2点です。

• Claudeが回答を作っている最中には割り込まない：実行時刻になったときにClaudeが作業中なら、その回答が終わるまで待ちます
• 時刻は、使っているパソコンのタイムゾーンで解釈される：0 9 * * *は、世界標準時ではなく、手元の時計の朝9時です

予定の登録・一覧・取り消しには、CronCreate・CronList・CronDeleteという3つのツールが使われます。ふだんは意識する必要はなく、「いま動いている予定を教えて」「デプロイ確認のジョブを止めて」と日本語で頼めば、Claudeが内部でこれらを使って操作します。

間隔を省略した/loopは、固定の間隔のcronとは別の仕組みで動きます。Claudeが各回の最後にScheduleWakeupというツールを呼び、「次はいつ起こすか」を1分〜1時間の範囲で予約します。作業が終わったと判断したときは、停止の指定つきで呼び出し、予約を取り消してループを終えます。このため、予定の一覧には、次の実行が「1回きりの予約」として1件だけ表示されます。

使い方

ここでは、Claude Codeが入っている状態から、/loopを動かして止めるまでの流れを説明します。インストールがまだの場合は、先にインストールの手順を済ませてください。

基本の手順

1. Claude Codeを起動する作業するフォルダでターミナル（黒い画面）を開き、claudeと入力して起動します。バージョンを確かめたいときは、claude --versionを実行します。
2. /loopを入力する入力欄に/loop 5m デプロイが終わったか確認して、結果を教えてのように、間隔と依頼を書いて送信します。
3. 登録の内容を確認するClaudeが、設定した周期とジョブIDを知らせます。「7分」のように割り切れない間隔を書いたときは、近い間隔に丸めた結果もここで報告されます。
4. 別の作業を続けるセッションは開いたまま、ほかの質問や作業を頼めます。決めた時刻になると、Claudeの手が空いたタイミングで依頼が実行されます。
5. 終わったら止める「デプロイ確認のジョブを止めて」と頼むか、依頼の内容で達成したら止めるよう書いておきます。止め方の一覧は、後ろの「管理・止め方」にまとめています。

間隔の書き方

間隔は、依頼の前に30mのような短い記号で書くか、依頼の後ろにevery 2 hoursのような言い回しで書きます。使える単位は次のとおりです。

ただし、書いた間隔がそのまま使われるとは限りません。公式ドキュメントには、次のように書かれています。

• cronは1分単位でしか動かないため、秒は1分に切り上げられます（30sは1分ごとになる）
• 7mや90mのように、cronのきれいな間隔にならないものは、近い間隔に丸められます。丸めた結果はClaudeが知らせてくれる

短い間隔にこだわる必要がある場面は多くありません。デプロイやCIの確認なら、数分おきで十分なことがほとんどです。細かすぎる間隔は、あとで説明する費用の面でも不利になります。

間隔の決め方の目安

公式ドキュメントには、確認対象ごとの推奨の間隔は書かれていません。次の表は、実行回数と待てる時間のバランスから考えた、筆者の目安です。

目安は、「結果が出てから気づくまでに、何分遅れても困らないか」で決めます。5分で足りる確認を1分おきにしても、気づくのが早くなるだけで、使用量は5倍になります。

間隔を省略したとき

間隔を書かずに依頼だけを書くと、Claudeが1回の実行が終わるたびに、次の実行までの待ち時間を自分で決めます。公式ドキュメントでは、待ち時間は1分〜1時間の範囲で、状況に応じて選ばれると説明されています。ビルドの終わりぎわやプルリクエストが動いているあいだは短く、何も待っていないときは長くなります。

/loop CIが通ったか確認して、レビューのコメントが来ていれば対応して

選んだ待ち時間と、その理由は、各回の終わりに画面へ表示されます。予定の一覧にも「1回きりの予約」として次の実行が表示されます。

この形のとき、ClaudeはMonitorツール（バックグラウンドでコマンドを動かし、出力された行をClaudeに伝えるツール）を使うことがあります。定期的に依頼を繰り返す代わりに、変化があったときだけ知らせてもらう仕組みで、公式ドキュメントでは「トークン効率がよいことが多く、反応も早い」とされています。

依頼を省略したとき

依頼を書かずに/loopだけを入力すると、内蔵の「保守の依頼」が動きます。実行のたびに、次の順番で作業します。

1. 途中の作業を続ける会話の中で、やりかけになっている作業があれば続きを進めます。
2. プルリクエストの面倒を見るいまのブランチのプルリクエストについて、レビューのコメント、失敗したCI、競合（コンフリクト）に対応します。
3. 掃除をするほかにやることがなければ、不具合探しや整理（簡素化）をします。

公式ドキュメントでは、この依頼は「範囲の外で新しいことを始めない」「pushや削除のような取り消せない操作は、すでに許可された作業の続きの場合だけ行う」と説明されています。間隔を足して/loop 15mとすれば、固定の間隔で動かせます。

練習：1分おきで動きを確かめる

本番の依頼を書く前に、害のない依頼で動きを確かめておくと安心です。次の手順で、予定の登録から取り消しまでを一通り体験できます。

1. 短い依頼を登録する/loop 1m いまの時刻を日本語で1行だけ報告してと入力します。
2. 登録の報告を読む周期とジョブIDが返ってきます。ジョブIDをメモしておきます。
3. 2〜3回、実行されるのを待つ1分ごとに、時刻の報告が出ます。ジッター（意図的なずれ）のため、ぴったり60秒おきにならないことがあります。
4. 予定を一覧にする「いま動いている予定を一覧で教えて」と頼み、IDと周期、次回の実行時刻を確かめます。
5. 取り消す「このジョブを取り消して」と頼み、もう一度一覧にして、予定が消えたことを確認します。

この練習をしておけば、「いつ動くのか」「どうやって止めるのか」が分かった状態で、本番の依頼を書けます。

スキルを依頼として渡す

依頼の代わりに、スキルを渡すこともできます。たとえば/loop 20m /review-pr 1234と書くと、20分ごとにそのスキルが動きます。ただし、実行できるのは、Claudeが自分の判断で呼び出せるスキルだけです。次のものは実行されず、ただの文字として届きます。

思ったとおりに動かないときは、まずこの表にあたらないかを確かめてください。

依頼文の例・loop.md

/loopに渡す依頼は、くり返し実行されるぶん、普段の依頼より少し丁寧に書いておくと失敗が減ります。ここでは、依頼の書き方のコツと、そのまま使える例、そしてloop.mdに既定の依頼を書いておく方法を紹介します。

依頼文に入れておきたい4つのこと

1回ごとの実行は、前の回を覚えている保証がない前提で書くのが無難です。次の4つを入れておくと、何度実行しても同じ基準で動いてくれます。

依頼文の例

そのまま使える形で、場面ごとの例を紹介します。ブランチ名やコマンドは、自分の環境に合わせて書き換えてください。

デプロイの終わりを待つ

/loop 5m 本番へのデプロイが完了したか確認して。完了したら結果を1行で報告して、この予定を取り消して。失敗していたら、ログから原因を調べて報告して（ファイルの変更はしない）。

固定の間隔を指定した例です。終わったら予定を取り消すように書いておくと、7日間のあいだ動き続けることがありません。

CIとレビューコメントを見守る

/loop いまのブランチのプルリクエストについて、CIの結果とレビューのコメントを確認して。新しいコメントがあれば内容に対応して、対応した内容を報告して。何も変わっていなければ「変化なし」とだけ書いて。

間隔を省略した例です。Claudeは、プルリクエストが動いているあいだは短い間隔、静かになったら長い間隔に自動で切り替えます。

長いテストの経過を見る

/loop 10m テストの実行ログの末尾を見て、失敗しているテストがあれば名前を一覧で教えて。全部終わったら、成功と失敗の件数を報告して、この予定を取り消して。

ログのエラーを見張る

/loop 15m アプリのログの直近15分を確認して、前回より増えているエラーがあれば種類と件数を報告して。増えていなければ何も書かなくていい。

「増えていなければ何も書かない」と明示しておくと、画面が静かなまま、必要なときだけ知らせてもらえます。

公開しているサイトの表示を確かめる

/loop 30m 公開しているサイトのトップページとお問い合わせページが表示できるか確認して。表示できないページがあれば、ページ名とエラーの内容を報告して。問題がなければ何も書かない。

状況を見るだけの依頼なので、権限の面でも安心です。サイトを更新した直後の見張りに使えます。

ドキュメントの更新漏れを探す

/loop 1h 直近のコミットを確認して、READMEや手順書の更新が必要になりそうな変更があれば、更新が必要な箇所を一覧で報告して（ファイルの変更はしない）。なければ何も書かない。

作業中のブランチの遅れを確かめる

/loop 1h mainブランチに新しいコミットが入っていないか確認して。入っていれば、いま作業しているブランチと競合しそうなファイルを報告して（取り込みや変更はしない）。

スキルを定期的に呼ぶ

/loop 30m /review-pr 1234

手順をスキルとして用意してあるなら、依頼を書く代わりにスキルを渡すのが最も簡単です。前の章で説明したとおり、Claudeが自分で呼び出せるスキルに限られます。

依頼文の型

慣れないうちは、次の型に当てはめて書くと、抜けが減ります。

【対象】○○を確認して。
【条件】△△になっていたら、□□して。
【やらないこと】ファイルの変更とpushはしない。
【終わり】××になったら、この予定を取り消して。
【報告】変化がなければ何も書かない。あれば3行以内で。

何度も使う型になったら、次に説明するloop.mdに移すと、毎回書かずに済みます。

動かしてみて、思ったとおりでないとき

一度で完璧な依頼が書けることは多くありません。数回動かして、出てきた報告を見ながら、依頼文を直していきます。よくある不満と、直し方の目安は次のとおりです。

依頼文を直したら、いまの予定を取り消して登録し直します。loop.mdの場合は、ファイルを編集するだけで、次の回から新しい内容になります。

loop.mdで、引数なしの/loopの動きを決める

引数なしの/loopで動く内蔵の保守の依頼を、自分の依頼に置き換えるのがloop.mdです。決まった確認作業を、毎回書かずに呼び出せるのが利点です。置き場所は次の2か所で、先に見つかった方が使われます。

書式は決まっていません。普通のMarkdownで、/loopの後ろに書く依頼と同じ気持ちで書きます。公式ドキュメントの例を日本語にすると、次のようになります。

release/nextのプルリクエストを確認する。CIが赤ければ、失敗したジョブのログを取り、原因を調べて、最小限の修正をpushする。新しいレビューコメントがあれば、一つずつ対応して、スレッドを解決済みにする。すべて緑で変化がなければ、その旨を1行で書く。

使うときの注意点は、次のとおりです。

• 1つの既定の依頼しか書けない：loop.mdは、複数の予定を並べるファイルではありません。別の予定を足したいときは、/loop 依頼で追加するか、Claudeに直接頼みます
• コマンドラインで依頼を書いたときは無視される：/loop 5m ...と書けば、そちらが優先されます
• 編集は次の回から反映される：ループが動いている最中にファイルを直しても、次の実行から新しい内容になります
• 25,000バイトを超えた部分は切り捨てられる：短くまとめておくのが前提です
• ファイルがなければ内蔵の依頼に戻る：どちらの場所にもなければ、先ほどの保守の依頼が動きます

loop.mdの書き方の例

loop.mdは、自由に書けるぶん、何を書けばよいか迷いがちです。依頼文の型と同じく、「対象・してよいこと・してはいけないこと・報告の形」の4つを入れておくと整います。

例1：朝の状況確認

作業中のブランチについて、次を確認して報告する。
1. CIの状態（成功・失敗・実行中）
2. 未対応のレビューコメントの件数
3. mainブランチとの競合の有無
ファイルの変更とpushはしない。報告は3行以内にする。変化がなければ「変化なし」とだけ書く。

例2：リリース前のチェック

release/nextブランチについて、公開前の確認をする。テストが通っているか、未解決のレビューコメントがないか、更新履歴（CHANGELOG）に今回の変更が書かれているかを確かめる。足りない項目があれば、項目名だけを一覧で報告する。修正はしない。すべてそろったら「公開できる状態」と1行で書き、この予定は取り消す。

どちらも、「見て報告する」ことを軸にした例です。変更を許す場合でも、まずは報告だけの形で数日動かし、内容に問題がなければ、変更を許す範囲を少しずつ広げるのが安全です。

一回きりの予約も頼める

くり返しではなく、1回だけ実行したいときは、/loopを使わず、自然な言葉で頼みます。

15時に、リリース用のブランチをpushするよう知らせて

45分後に、結合テストが通ったか確認して

Claudeは時刻を特定の「分」と「時」に固定して予約し、実行後は予定が自動で消えます。ここで1つ、細かい点があります。00分と30分に予約した1回きりの予定は、最大で90秒ほど早く実行されることがあります。正確な時刻が大事なときは、「3 9 * * *」（9時3分）のように、00分と30分を外して予約します。

管理・止め方

くり返し実行される予定は、止め忘れると、気づかないうちに使用量を消費し続けます。一覧の見方、止め方、そして「いつ・どうなると勝手に終わるのか」を整理しておきましょう。

予定を一覧する・取り消す

予定の確認も取り消しも、日本語で頼めば足ります。

いま動いている予定を一覧で教えて

デプロイ確認のジョブを取り消して

それぞれの予定には、8文字のIDが付いています。Claudeに「IDがxxxxxxxxのジョブを取り消して」と頼むこともできます。ひとつのセッションに登録できる予定は、最大50個です。

次回の実行時刻の表示（next run）は、Claude Code v2.1.299以降で見られます。登録時の画面や、一覧の行に出てくるので、「いつ動くのか」を確かめたいときに使えます。

cron式の読み方

登録時の報告や予定の一覧には、*/5 * * * *のような「cron式」が表示されます。読めなくても使えますが、意味が分かると、Claudeが登録した内容の確認がしやすくなります。cron式は、分・時・日・月・曜日の5つの欄を、空白で区切って書きます。

使える書き方には、次の決まりがあります。

• 使える記号：ワイルドカード（*）、単独の値（5）、間隔（*/15）、範囲（1-5）、カンマ区切りの列挙（1,15,30）
• 曜日の数字：日曜は0または7、土曜は6
• 使えない書き方：L・W・?、MONやJANのような名前の省略形は使えない
• 日と曜日の両方を指定したとき：どちらかに当てはまる日に実行される（標準的なvixie-cronと同じ）

cron式を自分で書く必要はありません。「平日の朝9時に」と日本語で頼めば、Claudeが式に直して登録します。式を読めるようになるのは、「思っていた時刻と違う」ときに原因を探すためです。

止め方の早見表

止める方法は、/loopの種類によって少し違います。

間隔を省略した/loopでは、実行が終わったのに、次の予約も停止の指示もなかった場合、Claude Codeが約20分後に1回だけ予備の実行を入れます。その回でも予約しなければ、ループは終わります。

CLAUDE_CODE_DISABLE_CRONを設定すると、/loopとcronのツールが使えなくなり、すでにある予定も実行されなくなります。会社として定期実行を使わせたくない場合の選択肢です。

実行時刻は少しずれる

予定の時刻ぴったりに実行されるとは限りません。多くの人の予定が同じ時刻にAPIを呼ぶと負荷が偏るため、Claude Codeは実行時刻を意図的にずらします（ジッター）。ずれ方は、予定の間隔によって決まります。

ルールは「次の実行までの間隔の半分まで、ただし最長で30分」です。均等な間隔の予定は、毎回同じ分数だけ遅れます。5分ごとだけは、公式ドキュメントによると、5分前後でプロンプトキャッシュ（直前の会話を安く読み込み直すための記憶）の期限が切れるため、15秒だけ早めて実行されます。

「毎朝9時ちょうどに必ず動いてほしい」という使い方には向きません。時刻に厳密な仕事は、後ろの章で紹介するクラウドやデスクトップの定期実行も検討してください。

7日で自動的に終わる

くり返しの予定は、作成から7日後に自動で期限切れになります。期限が来ると、最後に1回実行されてから削除されます。止め忘れたループがいつまでも動き続けないようにするための仕組みです。

7日を超えて続けたいときは、期限が来る前に取り消して作り直すか、ルーティンやデスクトップの定期タスクのような、長く動かす用の仕組みに移します。間隔を省略した/loopも、この7日の期限の対象です。

閉じたとき・再開したときの扱い

/loopの予定はセッションの中にだけある、というのが大前提です。公式ドキュメントでは、次の制約が挙げられています。

パソコンを閉じてもセッションを動かし続けたいときは、セッションをバックグラウンドに回す方法があります。公式ドキュメントでは、バックグラウンドにすると/loopの予定が引き継がれ、ターミナルがなくても動き続けると説明されています。claude agentsで開く「エージェントビュー」では、/loopのセッションに専用の印（✢）が付き、実行回数と次回までのカウントダウンが表示されます。

セッションをバックグラウンドにするには、入力欄で/backgroundを実行するか、←キーを押します。公式ドキュメントでは、現在の会話を丸ごと移す/backgroundと、コピーを送って自分は手元で作業を続ける/forkの2つが紹介されています。

他の方法との使い分け

「同じことをくり返したい」という場面には、/loopのほかにも手段があります。公式ドキュメントでは、「何が次の実行のきっかけになるか」で選ぶよう整理されています。時刻なら定期実行、条件の達成なら/goal、出来事ならイベントでの起動です。

定期実行の3つを比べる

時刻をきっかけに動かす方法は、Claude Codeに3つあります。公式ドキュメントの比較表を、日本語でまとめました。

公式ドキュメントのひとことでの使い分けは、「パソコンなしでも確実に動かしたいならクラウド、手元のファイルやツールが必要ならデスクトップ、セッション中のちょっとした確認なら/loop」です。

クラウドのルーティン

ルーティンは、プロンプト・リポジトリ・コネクタを1つにまとめて保存し、クラウド上で自動実行するものです。パソコンを閉じていても動きます。公式ドキュメントでは「リサーチプレビュー（試験提供）」とされており、動きや上限、APIが変わることがあります。

• 使えるプラン：Pro・Max・Team・Enterprise
• 作る場所：Webのclaude.ai/code/routines、デスクトップアプリ、またはCLIの/schedule（別名/routines）
• 起動のきっかけ（トリガー）：スケジュール、APIの呼び出し、GitHubのイベントを、1つのルーティンに組み合わせられる
• スケジュールの最短間隔：1時間。それより短い式は受け付けられない
• 実行中の許可：許可の確認はなく、自律的に動く。つまり、プロンプトを具体的に書く必要がある

注意したいのは、実行の範囲が、選んだリポジトリ・環境のネットワーク設定・コネクタで決まる点です。初期状態では、つないであるコネクタがすべて含まれ、書き込みも許可なしに実行されます。公式ドキュメントも、必要のないコネクタは外すよう案内しています。ルーティンは個人のアカウントに属し、実行結果（コミットやSlackの投稿など）は自分の名前で残ります。

ルーティンの作り方

Webから作る場合の流れは、次のとおりです。CLIからは、/scheduleに続けて「毎日9時にPRをレビューして」のように書くと、Claudeが質問しながら作ってくれます。

1. 作成画面を開くclaude.ai/code/routinesを開き、「New routine」を選びます。
2. 名前とプロンプトを書く実行のたびに使う依頼を書きます。自律的に動くため、「何をするか」「何をもって成功とするか」を、その依頼だけで読み取れるように具体的に書きます。
3. リポジトリを選ぶ作業対象のGitHubのリポジトリを1つ以上選びます。実行のたびにクローンされ、変更はclaude/で始まるブランチに作られます。
4. 環境を選ぶネットワークの範囲、環境変数、セットアップのスクリプトを決める環境を選びます。標準の「Default」は、許可リストの範囲に限った「Trusted」のネットワークです。
5. トリガーを選ぶスケジュール（毎時・毎日・平日・毎週、または指定した1回）、GitHubのイベント、APIのどれか、または組み合わせを選びます。
6. コネクタを見直す標準ではつないであるコネクタがすべて入っています。使わないものは外します。
7. 作成して試す「Create」で保存し、詳細画面の「Run now」で、すぐに1回実行して動きを確かめます。

スケジュールを毎時ちょうど（9:00など）にすると、数分遅れて始まることがあります。公式ドキュメントでは、近い時刻に動かしたい場合は、9:07のように、少しずらすよう案内されています。

ルーティンの使い道の例

公式ドキュメントでは、人が見ていなくても、繰り返し同じ成果を出せる仕事に向くとして、次のような例が挙げられています。

1つのルーティンに複数のトリガーを付けられます。たとえば、PRのレビューを、毎晩の定期実行・デプロイ後の呼び出し・新しいPRの3つで動かす、という組み合わせです。

デスクトップの定期タスク

Claude Codeのデスクトップアプリには、パソコン上で動く「ローカル」の定期タスクを作る画面があります。/loopと違って、セッションを開いていなくても、予定の時刻になると新しいセッションが自動で始まります。

スリープでスキップされるのを避けるには、「設定」→「このコンピューター」→「システム」の「Keep computer awake」をオンにします。ただしノートPCのふたを閉じると、スリープに入ります。

/goal：条件を満たすまで続けさせる

/loopとよく並べて語られるのが、/goalです。時間の間隔ではなく、「終わりの条件」を決めて、それを満たすまでClaudeに作業を続けさせる機能です。各ターン（Claudeの1回の作業）が終わるたびに、別のモデルが「条件を満たしたか」を判定します。満たしていなければ、Claudeが次のターンに進みます。

/goal test/auth のテストがすべて通り、lintもエラーなしになる

条件の書き方の要点は、公式ドキュメントでは「測れる終わりの状態を1つ」「確認の方法（npm testが0で終わる、など）」「守る制約」とされています。回数や時間を区切りたいときは、「20ターンで止める」のように、条件の中に書きます。

判定を行うモデルは、コマンドを実行したりファイルを読んだりはしません。会話の中に出てきた内容だけで判断します。したがって、条件は「テストが通る」のように、Claudeの出力で示せる形にしておきます。-pオプションを使った非対話の実行でも、/goalは使えます。

なお、/goalは内部でフック（特定のタイミングで動く自動処理）の仕組みを使っているため、フックが無効化されている環境や、管理者設定で組織管理のフックのみが許可されている環境では使えません。

/goalの判定と止まり方

判定を行うモデルは、各ターンの終わりに、次の3つのうちのどれかを返します。

Claudeが何も進まないまま、判定への返事だけを何ターンも続けた場合は、ループが止まって、目標が設定されたまま自分に操作が戻ります。また、認証の失敗、クレジットの残高切れ、自動圧縮で解決できない文脈の溢れ、使えないモデルの指定といった「自分で直す必要があるエラー」が出たときは、目標が自動的に解除されます。もう一度/goalで条件を設定し直します。

サブエージェントやバックグラウンドのコマンドが動いているときは、そのターンの判定が後回しになります。待機が30分続くと「チェックイン」が入り、Claudeに動いている作業の状態を確かめさせます。この間隔は、環境変数CLAUDE_CODE_GOAL_CHECKIN_MINUTESで変えられます。

出来事に反応させる：Channels・Monitor・GitHub Actions

「一定の間隔で見に行く」より、「変化があったときだけ知らせてもらう」方が効率のよい場面もあります。公式ドキュメントでは、次の手段が紹介されています。

• Channels：CIの失敗など、外部の出来事をセッションに直接送り込む仕組み。ポーリングの代わりに使う
• Monitorツール：コマンドをバックグラウンドで動かし、出力された行をClaudeに伝える。ログの監視やPR・CIの状態の変化に向く。見張りには期限があり、標準は5分、最大30分（-pでの単発実行では最大10分）
• GitHub Actions：scheduleトリガーで、CIの中でClaudeを定期実行できる

Monitorは、Amazon Bedrock・Google Cloudのエージェントプラットフォーム・Microsoft Foundryでは使えません。また、DISABLE_TELEMETRYやCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICを設定している場合も使えません。Windowsでは、Git Bashが入っている場合だけ使えます。

動的ワークフロー：大きな作業を分担させる

関連する言葉として「ワークフロー」もよく検索されています。ただし、これは「くり返し」ではなく、たくさんのサブエージェントを、Claudeが書いたスクリプトで一斉に動かす仕組みです。コードベース全体の点検、数百ファイルの移行、複数の情報源を突き合わせる調査などに使います。公式ドキュメントでは、サブエージェントやスキル、エージェントチームとの違いは「次に何を動かすかをスクリプトが決める」点だと説明されています。

1回の実行で使うトークンが多くなりやすいため、小さな範囲で試してから広げるのが前提です。また、Proプランでは、/configの「Dynamic workflows」の行でオンにする必要があります。

目的別の選び方

迷ったら、「自分のパソコンを閉じても動いてほしいか」を最初に決めます。動いてほしいならクラウド、そうでなければデスクトップか/loop、という順で絞れます。

費用・権限の注意点

くり返し実行される依頼は、1回ずつは小さくても、積み重なると使用量が大きくなります。また、見ていないあいだに動くため、権限の決め方も大切です。

使用量の増え方

公式の費用のページでは、長いセッションで使用量が増える理由のひとつに、「定期実行の予定は、セッションが何もしていないときでも、その間隔で実行され、毎回会話の全体を送る」ことが挙げられています。画面を見ていなくても、使用量は増えていきます。

もう1つ関係するのが、プロンプトキャッシュです。会話の全体を毎回送るときの料金を抑える仕組みですが、休みが「キャッシュの有効時間」を超えると、次の依頼でキャッシュが効かず、全体を読み直します。有効時間は、サブスクリプションでは1時間、追加の使用量（クレジット）を使っている間や、APIキー・クラウド経由の利用では、標準で5分です。間隔が有効時間より長いループは、毎回、全体を読み直すことになります。

ルーティンの回数の上限

クラウドのルーティンには、サブスクリプションの使用量とは別に、実行のきっかけごとに「1時間あたりの回数」の上限があります。公式ドキュメントの内容は次のとおりです。

上限を超えたスケジュール実行は、上限が戻るまで待たされます。「Run now」やAPIの呼び出しは、上限が戻るまで失敗します。どの上限にも、超過分を追加料金で使える仕組みはありません。サブスクリプションの使用量に達した場合は、使用量のクレジットを有効にしている組織なら、従量課金で実行を続けられます。

実行回数の目安

固定の間隔で動かしたとき、実行回数はおおよそ次のようになります。間隔が短いほど、回数は一気に増えます。

これは、止めずに動かし続けた場合の単純な計算です。実際には、Claudeが作業中の時間や、セッションが閉じている時間には実行されません。それでも、「5分ごと」を1日動かすと数百回、毎回会話の全体を送ることになる、という感覚は持っておくとよいでしょう。

使用量を抑えるコツ

• 間隔を長くする：数分おきが必要な確認は、実はそう多くありません。「30分おき」で足りることが多いはずです
• 終わったら取り消す依頼にする：「完了したらこの予定を取り消して」と、依頼の中に書いておきます
• 変化がなければ何も書かない依頼にする：出力が減ります
• ループ専用の新しいセッションを開く：長く作業した会話の上でループを動かすと、毎回その全体を送ります。新しいセッションなら、送る量は少なくて済みます
• 間隔を省略する：状況に応じて待ち時間が長くなるため、静かなときは実行が減ります。さらにMonitorが使われれば、変化があったときだけ動きます

権限の考え方

/loopは、セッションの権限設定を引き継ぎます。公式ドキュメントの比較表でも「許可の確認：セッションのものを引き継ぐ」と書かれています。つまり、普段の作業と同じ許可の仕組みが、くり返しの実行にも効きます。

見張りの依頼なら、必要な操作は「読み取り」と「状況を確かめるコマンドの実行」くらいです。確認に使うコマンドだけを許可ルールに入れておくと、手動モードのままでも、確認待ちで止まらずに済みます。ファイルの変更やpushまで任せるなら、変更の範囲を依頼に書き、変更内容を毎回報告させます。

チームで使い始める進め方

個人で試した/loopを、チームの使い方として広げるときは、次の順番で進めると、トラブルが少なくなります。

1. 見るだけの依頼で、1週間試すファイルを変更しない依頼から始めます。/usageの「Loops」の行で、使用量も確かめます。
2. うまくいった依頼を、loop.mdにまとめるプロジェクトの.claude/loop.mdに入れ、チーム全員が同じ依頼で動かせるようにします。
3. 許可の範囲を決める確認に使うコマンドだけを許可ルールに入れ、変更や公開は人が行う、といった線引きを決めます。
4. 長く動かす仕事を、別の方法に移す7日を超える仕事や、パソコンなしで動かしたい仕事は、ルーティンやデスクトップの定期タスクに移します。
5. 定期的に見直す使われていない予定、使用量の多い予定がないかを見直します。仕様や上限は、公式ドキュメントで確かめます。

くり返しで起きやすい失敗

うまく動かないとき

/loopが思ったとおりに動かないときは、症状から原因を探すのが早道です。多くは、仕様どおりの動きを知らなかったことによるものです。

バージョンによって変わる点

公式ドキュメントには、機能ごとに「このバージョン以降」という注意書きがあります。「書いてあるのに動かない」ときは、まずclaude --versionで版を確かめてください。

この記事に出てきた用語

よくある質問

まとめ

/loopは、「画面を見に行く」作業を減らすための小さな道具です。まずは、状況を見て報告するだけの依頼を5〜10分おきに動かしてみて、結果と使用量を見ながら範囲を広げていくのがおすすめです。

チームでClaude Codeを使い始める段階では、権限の決め方、定期実行を動かしてよい範囲、クラウドとデスクトップのどちらに任せるかなど、決めることが増えます。INTERCREATE JAPANでは、Claude CodeやCodexの導入から、社内で使い続けられるルールづくりまでをお手伝いしています。