パイソンエンジニア部
毎朝 9 時、出社して最初の 30 分が毎回同じ手作業で消えていく。「ステージング環境のヘルスチェック回して」「昨日マージされた PR のレビューコメントに返信して」「CI が落ちていないか確認して」を Claude Code に投げ直すだけで、もう半分が終わっている。
シリーズ #06 毎朝同じ呪文を 1 行に圧縮する で /morning-check を 8 行のスキルに縮め、シリーズ #07 部品はあるのに毎回つなぎ直す で /morning-report を Command と Agent と Skill の 3 役に分割しました。プロンプトの形は整いました。残るは 「これを毎朝定刻に勝手に動かす」 の部分です。
本記事ではその時間軸の自動化を、公式の 3 ルート Scheduled Tasks・Desktop scheduled tasks・Routines で扱います。
TL;DR
- Claude Code には時間軸で勝手に動かす公式ルートが 3 つある。セッション内なら
/loop、マシンの電源が入っていてセッションは閉じてよいなら Desktop scheduled tasks、マシンも閉じるなら Routines（Anthropic のクラウドで動く） - 選び方の軸は 2 つだけ。「マシンの電源が入っていないと困るか」「セッションが開いていないと困るか」
/loopは v2.1.72 以上で動くバンドルスキル（/loop 5m check the deploy形式）。間隔を省くと Claude が動的に間隔を選び、プロンプトも省くと組み込みメンテナンスプロンプト（PR のお守りと後片付け）が走る- Routines は研究プレビュー（research preview）。スケジュール / API / GitHub の 3 種類のトリガーを 1 つのルーティンに複数組み合わせられる。Pro / Max / Team / Enterprise プラン + Claude Code on the web 有効が必須
- 罠 4 つ: 全部
/loopでやってセッションを閉じたら止まる / Routines に何でも入れて 1 日の実行枠を食い潰す / 最小間隔と 7 日失効の勘違い / クラウドの Routines は毎回まっさらに複製するのでローカル前提のプロンプトが動かない - 今週やる 1 つ: PR のお守りを
/loop check whether CI passed and address any review commentsで当てて、軌道に乗ったら Routines のスケジュールトリガーに昇格させる
朝の 30 分、同じプロンプトを 3 回書いていませんか
私自身の朝のルーティンを白状します。
- 9:00 出社してマシンの蓋を開ける
- 9:02 Claude Code を起動、
/morning-checkを叩く - 9:05 出力を見ながら別のターミナルで PR を眺める
- 9:10 「昨日の PR のレビューコメント返信して」を貼り直す
- 9:20 「ステージングの直近 30 分のエラーログだけ要約して」を貼り直す
- 9:30 ようやく自分の作業に入る
毎日同じ 30 分です。/morning-check のようなスキルにしておけば 1 行で済みますが、それでも私が 「定刻にマシンの蓋を開けて、Claude に最初の指示を投げる」 という人間トリガーから抜けられていません。
似た構造は他にもあります。長く走る CI を待つ間、5 分おきに「CI 通った？」と Claude に聞く。マージ済み PR の Codecov コメントを待ちながら、10 分おきに「カバレッジ降りた？」と聞く。デプロイ後のスモークチェックを 15 分後に走らせたいから、リマインダーを別アプリにセットする。
人間がストップウォッチを握ってトリガーを引く構造です。スキルを作っただけでは、この構造は解けません。
時間軸の自動化は公式に 3 ルートある
Claude Code には公式に、Claude を時間軸で繰り返し起こすルートが 3 つあります。公式ドキュメントの比較表から要点を日本語に整理するとこうなります。
| Routines（クラウド） | Desktop scheduled tasks | /loop | |
|---|---|---|---|
| どこで動くか | Anthropic のクラウド | 自分のマシン | 自分のマシン |
| マシンの電源 | 切れていてもよい | 入っている必要あり | 入っている必要あり |
| Claude Code セッション | 不要 | 不要 | 開いている必要あり |
| 再起動を超えて生き残るか | はい | はい | --resume で復元（未失効のもののみ） |
| ローカルファイルへのアクセス | できない（毎回まっさらに複製） | できる | できる |
| MCP サーバ | タスクごとにコネクタを設定 | 設定ファイルとコネクタ | セッションから継承 |
| 権限プロンプト | なし（自律実行） | タスクごとに設定可能 | セッションから継承 |
| 最小間隔 | 1 時間 | 1 分 | 1 分 |
選び方は 2 段階の質問でほぼ片付きます。
- マシンの電源が落ちている時間にも動かしたいか: はいなら Routines（クラウド）。いいえなら 2. へ
- Claude Code のセッションを開きっぱなしにできるか: できないなら Desktop scheduled tasks。できるなら
/loop
図にすると 1 枚に収まります。
flowchart TD Start(["定期的に Claude を<br/>動かしたい"]) --> Q1{"マシンの電源が<br/>落ちていてもよいか?"} Q1 -- "はい<br/>(夜間も動かす)" --> R["Routines<br/>(Anthropic クラウド)"] Q1 -- "いいえ<br/>(自分のマシンで動かす)" --> Q2{"セッションは<br/>開きっぱなしにできるか?"} Q2 -- "できる" --> L["/loop<br/>(セッション内)"] Q2 -- "できない" --> D["Desktop scheduled tasks<br/>(マシン側)"] R -. 最小間隔 1h .-> Note1[("Pro/Max/Team/<br/>Enterprise + Web版")] L -. 最小間隔 1m .-> Note2[("v2.1.72+<br/>7 日で勝手に終わる")] D -. 最小間隔 1m .-> Note3[("マシンの電源 ON 必須")]イベントが起きた瞬間に反応したい（CI 失敗の通知が来た瞬間にセッションへ送り込みたい）場合は Channels のほうが向きます。条件を満たすまで会話を続けたい場合は /goal です。本記事はあくまで 時間軸の繰り返し に絞ります。
/loop ─ 開いているセッションの中でだけ動く
/loop は Claude Code v2.1.72 以上で使えるバンドルスキルです。claude --version で確認してください。
公式ドキュメントにこう書いてあります。
Scheduled tasks let Claude re-run a prompt automatically on an interval. Use them to poll a deployment, babysit a PR, check back on a long-running build, or remind yourself to do something later in the session.
スケジュール済みタスクを使用すると、Claude は一定の間隔でプロンプトを自動的に再実行できます。デプロイメントをポーリングしたり、PR を監視したり、長時間実行されるビルドをチェックバックしたり、後でセッション内で何かを実行するようにリマインダーを設定したりするために使用します。
/loop の主な形は 3 つです。
| 渡し方 | 例 | 動き |
|---|---|---|
| 間隔 + プロンプト | /loop 5m check the deploy | 指定の間隔で固定（cron 式に変換される） |
| プロンプトだけ | /loop check the deploy | 各回終了後に Claude が次の間隔を 1 分〜1 時間で動的選択 |
| 何も渡さない | /loop | 組み込みメンテナンスプロンプト（PR のお守り + 後片付け）が動く |
形 1: 間隔を自分で決める
/loop 5 分後にデプロイが完了したかどうかを確認し、何が起こったか教えてください
間隔はプロンプト前後どちらに置いてもよく、30m のようにも every 2 hours のようにも書けます。単位は s m h d。秒は cron の分粒度に丸められ、7m や 90m のような中途半端な間隔はもっとも近い cron ステップに丸められ、Claude が選んだ実際の間隔を教えてくれます。
形 2: 間隔を Claude に任せる
/loop CI が合格したかどうかを確認し、レビューコメントがあれば対処します
間隔を省くと、Claude が各回終了後に 観察した状況に応じて次の遅延を 1 分〜1 時間で動的に決定 します。ビルドが走っている間は短く、PR が静かになったら長く、自動で間隔が伸び縮みします。
公式ドキュメントはこの動的版でしばしば Monitor tool が直接使われると注記しています。バックグラウンドのスクリプトを動かし、新しい出力行が出るたびに通知が返ってくる仕組みで、ポーリングを置き換える方がトークン効率も応答性もよい場合がある、という設計です。
形 3: 何も渡さない（組み込みメンテナンスプロンプト）
/loop
裸の /loop は組み込みメンテナンスプロンプトを走らせます。各回でやる順序は公式ドキュメントにこう列挙されています。
新しい初動には踏み込まず、プッシュや削除のような取り消せない操作は会話の中ですでに認められたものだけ進めます。文字どおり「PR のお守りと、空き時間のお掃除」を勝手に回す装置です。
ただし /loop には 2 つの制約があります。1 つは セッションが閉じれば止まる こと、もう 1 つは 作って 7 日経つと定期タスクは勝手に終わる ことです（7 日失効）。--resume で復元できるのは失効していないものだけです。
Bedrock / Vertex AI / Microsoft Foundry を使っている場合は、間隔なしの動的版は使えず、固定 10 分間隔に置き換わる点も覚えておきます（公式ドキュメントの注記）。
Desktop scheduled tasks ─ マシンが起動していればセッションは閉じてよい
/loop を「マシンは起動しているがセッションは閉じている時間にも動かしたい」へ伸ばしたものが Desktop scheduled tasks です。Claude Code Desktop アプリの Routines → New routine → Local から作ります。
特徴は次の通りです。
- マシンの電源が入っていないと動かない（昼休みも夜間も含めて）
- Claude Code セッションは閉じていてよい。Desktop アプリがバックグラウンドで起動を担う
- ローカルのファイル・MCP サーバ・ssh 鍵にアクセスできる
- 最小間隔は 1 分
- 権限プロンプトはタスクごとに設定できる
セッションに閉じこもらないので「夜中の 3 時にバックアップの差分を要約させる」のような使い方ができます。逆に、ノート PC を持ち帰って蓋を閉じると動かない点は Routines と差が出ます。
Routines ─ クラウドで自律的に動く
Routines は Anthropic のクラウドで動く保存済み Claude Code 設定です。公式ドキュメントの定義はこうです。
A routine is a saved Claude Code configuration: a prompt, one or more repositories, and a set of connectors, packaged once and run automatically. Routines execute on Anthropic-managed cloud infrastructure, so they keep working when your laptop is closed.
ルーティンは保存された Claude Code 構成です。プロンプト、1 つ以上のリポジトリ、および一連のコネクタをパッケージ化して、1 回定義し、自動的に実行します。ルーティンは Anthropic が管理するクラウドインフラストラクチャで実行されるため、ラップトップを閉じても動作し続けます。
研究プレビューで、Pro / Max / Team / Enterprise プラン + Claude Code on the web の有効化が前提です。作成と管理は claude.ai/code/routines の Web 画面、Desktop アプリのサイドバー、または CLI の /schedule のいずれからでもでき、すべて同じクラウドアカウントを書き換えます。
ルーティン 1 件には トリガーを複数組み合わせて貼り付けられる のが Scheduled Tasks との大きな違いです。トリガーは 3 種類。
| トリガー | 何が起きたら動くか | 使い所 |
|---|---|---|
| スケジュール | 指定した周期（cron 形式）、または特定の未来時刻に 1 回 | 毎晩のバックログ整理、週次のドキュメントずれ点検 |
| API | ルーティンごとのエンドポイントに、ベアラートークン付きの HTTP POST が来たとき | 監視ツールや CD パイプラインからの呼び出し |
| GitHub | リポジトリの pull_request.opened などのイベント | 独自のコードレビュー、ライブラリ移植 |
公式ドキュメントが並べている使い所の例を 6 つほど引きます。バックログ整理（毎晩）、アラートの振り分け（API）、独自のコードレビュー（GitHub）、デプロイ検証（API）、ドキュメントずれ点検（毎週）、ライブラリ移植（GitHub）。1 件のルーティンにスケジュール + API + GitHub を同時に貼れば、「毎晩走らせつつ、デプロイ時にも CD から叩け、PR の度にも反応する」のような筋に組み立てられます。
ただし重要な制約があります。Routines は、実行のたびにリポジトリをまっさらに複製し直し、人手を介さず自律的に動くセッションです。
- ローカルのファイル・MCP サーバ・ssh 鍵にはアクセスできない
- リポジトリは実行のたびにデフォルトブランチから複製される。Claude が変更を加えるときは
claude/で始まる名前のブランチを切る - 最小間隔は 1 時間。
/loopや Desktop scheduled tasks の 1 分とは桁が 2 つ違う - 個人の claude.ai アカウントに紐付き、1 日あたりの実行枠を消費する。チームメンバーとは共有しない
- 権限プロンプトはなし。すべて自律的に進む
コネクタ・環境変数・ネットワークアクセスは、ルーティンの作成時に「環境」（既定の環境は Trusted ネットワーク）としてまとめて設定する仕組みです。
4 つの罠
罠 1: 全部 /loop でやって、ターミナルを閉じた瞬間に止まる
/loop はセッションの中だけで生きる仕組みです。ターミナルを閉じる、別の claude セッションを起動する、ラップトップを再起動する、のいずれかで停止します。--resume で復元できるのは「失効していない」もの、つまり 7 日以内に作った定期タスクと、まだ実行時刻が来ていない 1 回限りのタスクだけです。
「夜中にも動いて欲しい」のに /loop を選ぶと、寝ている間に何度もセッションが落ち、朝起きたら止まっていた、という事故が起きます。
判断基準は 1 行で書けます。自分が見ているターミナルの中だけで動けば十分なら /loop、それを超えるなら Desktop scheduled tasks か Routines。
罠 2: Routines に何でも入れて 1 日の実行枠を食い潰す
公式ドキュメントはこう注意しています。
Routines belong to your individual claude.ai account. They are not shared with teammates, and they count against your account’s daily run allowance.
ルーティンは個別の claude.ai アカウントに属します。チームメイトと共有されず、アカウントの日次実行許容量に対してカウントされます。
Routines は個人アカウントの 1 日の実行枠を消費します。「ついでに全部クラウドで動かそう」とルーティンを 10 件並べると、肝心の PR レビューが枠不足で動かない夜が来ます。
クラウドに置く判断基準を 1 行持っておきます。「マシンの電源が落ちている時間に動かないと困るか」。落ちている時間でなくてもよいなら、最小間隔 1 分の Desktop scheduled tasks に降ろします。
罠 3: 最小間隔と 7 日失効を勘違いする
3 ルートの最小間隔は揃っていません。
/loop: 1 分- Desktop scheduled tasks: 1 分
- Routines: 1 時間
「30 分おきに監視したい」を Routines でやろうとすると弾かれます。逆に「1 時間おきで十分」を /loop でやると、/loop 1h ... と書けてしまうので、誤ってセッションの中だけに縛られたまま気づかない事故が起きやすい。
加えて /loop の定期タスクは 7 日で勝手に終わる。これは公式ドキュメントに明記された挙動です。
Recurring tasks automatically expire 7 days after creation. The task fires one final time, then deletes itself. This bounds how long a forgotten loop can run.
定期的なタスクは作成後 7 日で自動的に期限切れになります。タスクは最後に 1 回実行され、その後自身を削除します。これにより、忘れられたループが実行できる期間が制限されます。
「ずっと動かし続けたい監視」を /loop で建てると、8 日目から黙って止まります。長く動かす運用は最初から Routines / Desktop scheduled tasks にしておきます。
罠 4: クラウドの Routines は毎回まっさらに複製するので、ローカル前提のプロンプトが動かない
Routines のセッションは毎回、まっさらな複製から始まります。これが何を意味するかというと、
- ローカルにしかない非公開の依存パッケージ（社内 PyPI に取りに行かないと動かない）
- ローカルの
~/.ssh/id_ed25519（手元の鍵に依存した git のプッシュ） - ローカルのファイルパス（
/Users/me/scratch/notes.mdのような絶対パス） - ローカルの MCP サーバ（手元で立ち上げている自作サーバ）
これらに依存したプロンプトを Routines に貼ると、初回の実行で「権限がない」「ファイルがない」と落ちます。Routines が触れるのは、選んだリポジトリ、選んだ環境のネットワーク設定と環境変数、そして選んだコネクタの 3 点だけです。
対策は、ローカル前提を切り出して環境変数かコネクタに寄せる。たとえば ANTHROPIC_API_KEY のようなトークンは環境変数で、社内の課題管理ツールは専用のコネクタ経由で渡します。ローカルのファイルパスはリポジトリ内の相対パスに書き換えるか、そもそも Routines に向かない作業として Desktop scheduled tasks か /loop で受け取ります。
今週やる 1 つ ─ /loop で PR のお守りを当てて、Routines に昇格させる
今週、私が最初に試すなら次の 1 行です。
/loop CI が合格したかどうかを確認し、レビューコメントがあれば対処します
これだけで Claude が CI と PR コメントを巡回し、状況に応じて間隔を 1 分〜1 時間で動的に決めながら走ります。Monitor tool でイベントをストリームに置き換える判断も Claude が必要に応じてやってくれます。
3 日試して挙動が安定したら、同じ意図のプロンプトを Routines のスケジュールトリガー（たとえば平日朝 9 時）に貼り直します。これで「マシンの蓋を開ける」「セッションを起動する」工程まで Claude に外注できます。
Routines を業務で使う前に、Claude Code on the web を自分のプランで有効化する必要があります。Team / Enterprise の場合は 管理画面の設定 で Routines が有効になっているかも確認しておきます。無効だと既存のルーティンも停止します。
まとめ
毎朝同じ 30 分を Claude に投げ直す生活を抜けるためのルートは、Claude Code 側に 3 つ用意されています。セッションに縛られない /loop、セッションは閉じてよい Desktop scheduled tasks、マシンも閉じてよい Routines。選び分けの軸は「マシンの電源が入っていなくてよいか」「セッションが開いていなくてよいか」の 2 つだけです。
シリーズ #06 スキルの手動呼び出し と #07 ワークフロー で組んだスキル群は、/loop か Routines のトリガーに貼れば、そのまま時間軸の自動化に化けます。/morning-check を毎朝勝手に走らせ、/morning-report を毎週金曜の終わりに勝手に集計させる、という運用が遠くなくなります。
直前のシリーズ #13 Agent Teams は「同じ瞬間に複数の Claude を並列で動かす」という横軸でしたが、本記事は「同じ Claude を別の時刻に繰り返し起こす」という縦軸です。横軸と縦軸が揃ったところで、Claude Code はようやく「呼ぶ道具」から「巡回するエージェント」に近づきます。Routines がまだ研究プレビューと明記されているうちは大袈裟な役割を任せきらず、PR のお守りの 1 件から始めて、勝手に動く時間と実行枠の感覚を掴むのが現実的な現在地です。
