2026.09.22 2026.09.22

ルーティンで Claude Code を留守番させる — クラウドで回る定期実行・API・GitHub トリガーの設計

ゲンキ

※本記事にはアフィリエイト広告（PR）が含まれます。

毎週月曜の朝、先週の記事に壊れたリンクが無いかを確かめる。毎晩、印刷の失敗率を集計する。こういう作業は、やること自体は決まっているのに、始めるためには人が席に着いて、ターミナルを開いて、コマンドを打たなければならない。始める手間のほうが作業より重い。

Claude Code のルーティンは、この「始める手間」を無くすための機能だ。プロンプトとリポジトリと接続先を一度だけ包んでおくと、時刻・HTTP の呼び出し・GitHub のイベントを起点に、Anthropic のクラウド上でセッションが勝手に立ち上がって仕事をする。自分の PC は閉じていてよい。

本記事は公式文書の記述と、当サイトが実際に作って走らせた1本のルーティンの記録の両方で書く。ルーティンは 2026年9月17日時点で研究プレビューであり、挙動・上限・API の形は変わりうると文書に明記されている。数値と版番号はその日に取得したものだ。

「留守番」ができるのはクラウド側だけ — 3層の定期実行
ルーティンとは何か
3種のトリガー
最短1時間と、数分のずれ
承認が無い、という設計
既定で全部つながる — 当サイトが実際に踏んだ罠
当サイトで作ったルーティン — 週次ゲート
無人で走るプロンプトの書き方
走らせた結果 — 48秒で終わり、リンク検査は遮断された
緑は「落ちなかった」の意味 — 実行ログの読み方
ネットワークの許可リスト
使用量と上限
3Dプリントの作業台で何を留守番させるか
まとめ
出典・参考

忍者AdMax

「留守番」ができるのはクラウド側だけ — 3層の定期実行

Claude Code には定期実行の面が三つある。文書の比較表から主要な行を抜粋する。

項目	ルーティン（クラウド）	Desktop の定期タスク	`/loop`
実行場所	クラウド（既定は Anthropic 管理）	自分の PC	自分の PC
PC の電源	不要	必要	必要
セッションを開いておく	不要	不要	必要
再起動後も残る	残る	残る	再開時に復元（例外あり）
ローカルファイル	使えない（新規クローン）	使える	使える
承認プロンプト	無し（自律実行）	タスクごとに設定	セッションを継承
最短間隔	1時間	1分	1分

三つの違いは、突き詰めると「自分の PC が要るか」と「誰が承認を押すか」の二点に集約される。/loop はセッションの中で回る仕組みで、ターミナルを閉じれば止まる（セッションをバックグラウンド化した場合は引き継がれる）。しかも定期タスクは作成から7日で自動的に失効し、1セッションに持てるのは50件までだ。Desktop の定期タスクは、Desktop アプリが開いていて PC が起きている間だけ動き、スリープ中の回は飛ばされる（復帰時に直近の1回だけ追いつく）。

PC の電源が要らず、セッションも要らないのはルーティンだけである。留守番という言葉が当てはまるのはこの層だけだ。その代わり、ローカルのファイルには触れず、承認を押す人もいない。この二つの制約が、以下の設計のすべてを決める。

ルーティンとは何か

文書の定義は簡潔だ。ルーティンは保存された Claude Code の設定であり、プロンプト、一つ以上のリポジトリ、そして接続先（コネクタ）の組を一度だけ包んで、自動で実行するものだと書かれている。実行は Anthropic が管理するクラウド上で行われ、組織によっては自前のホスティング環境に振り向けられる。

提供対象は Pro・Max・Team・Enterprise の各プラン。作成は claude.ai/code/routines の Web 画面、Desktop アプリ、そして CLI の /schedule コマンド（別名 /routines）の三つの面から行え、どこで作っても同じアカウントに書かれる。CLI では /schedule daily PR review at 9am のように自然文で頼むと、Claude がスケジュール・リポジトリ・プロンプトを聞き返して保存する。

ここで一つ注意がある。/schedule は claude.ai のサブスクリプションでログインしているときだけ現れる。Console の API キー（またはプロファイル／フェデレーションの資格情報）でログインしていて feature flag の取得が有効なら、送信時に「Claude for Enterprise で利用できる」という案内が返り、Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry 経由では「Unknown command」になる。ルーティンはアカウントに紐づく機能であって、API の機能ではない。

三つの面は同じアカウントに書くが、できることは少し違う。API トリガーの追加とトークンの発行・失効は Web 画面でしか行えず、逆に「2時間ごと」「毎月1日」のような定型外の cron は Web フォームにプリセットしか無いため、CLI の /schedule update で設定する。

3種のトリガー

一つのルーティンには、次の3種類のトリガーを組み合わせて付けられる。

スケジュール。 毎時・毎日・平日・毎週の定型か、特定の時刻に1回だけ。時刻は自分のタイムゾーンで入力すると自動で変換される。

API。 ルーティンごとに専用の HTTP エンドポイントが発行され、Bearer トークンを付けて POST すると新しいセッションが始まり、セッションの URL が返る。監視ツールの警報や、デプロイの後処理から呼ぶ用途が想定されている。トークンは表示が1回きりで、後から取り出せない。

GitHub。 接続したリポジトリの Pull Request と Release のイベントで起動する。作者・タイトル・本文・分岐元と分岐先のブランチ・ラベル・下書きかどうか・マージ済みかどうかの8項目でフィルタでき、Claude GitHub App（github.com/apps/claude）のインストールが要る。CLI から GitHub トリガーを足せるのは v2.1.225 以降だ。

API トリガーには設計上の防御が一つ入っている。呼び出しに添えた本文（text）は、そのままプロンプトとして届くのではなく、「信頼できないデータ」であることを示す包みに入って届く。ルーティンのプロンプト側で「その包みの中身を調べよ」と明示していない限り、Claude はその内容に従わない。トークンが漏れて誰かに勝手に呼ばれても、呼び出し側の文面が命令として通らないようにするための仕組みである。

最短1時間と、数分のずれ

スケジュールには二つの制約がある。

一つ目は最短間隔が1時間であること。それより短い cron 式は拒否される。5分ごとの監視のような用途は、ルーティンの守備範囲ではなく、/loop か Desktop の定期タスクの範囲だ。

二つ目は開始が数分ずれること。文書は、stagger（開始をずらす仕組み）により指定時刻から数分遅れて始まることがあり、そのずれはルーティンごとに一定だと書いている。当サイトが作ったルーティンでは、UTC の 22:00 を指定したところ、次回実行の予定は 22:01:24 と表示された。84秒のずれである。「月曜 07:00 ちょうどに結果が要る」という前提は置かないほうがよい。

1回きりの実行は少し扱いが違う。指定時刻に1回だけ動いて自動的に無効化され、画面には「Ran」と表示される。そしてこの単発実行は、後述する日次の実行上限に数えられない。

承認が無い、という設計

ルーティンの文書で最も重要な一文は、機能の説明ではなく制約の説明にある。ルーティンは完全に自律的なクラウドセッションとして走り、権限モードの選択肢は無く、実行中の承認プロンプトも無い。

対話セッションで Claude Code を使っている人は、ファイルの書き換えやコマンドの実行のたびに承認を押している。あるいは Claude Code 2026春アップデート総まとめ — auto mode・/ultrareview・xhigh effortの使いこなし（2026-04-22 公開）で扱った auto mode で、分類器に任せている。ルーティンにはそのどちらも無い。セッションはシェルを実行でき、リポジトリに含まれるスキルを使え、含めたコネクタのあらゆるツールを、書き込みも含めて、確認なしに呼べる。

だから、ルーティンが何に触れられるかは、プロンプトの丁寧さではなく、渡したものの範囲で決まる。選んだリポジトリ、環境のネットワーク許可と環境変数、含めたコネクタ。この三つを必要最小限に絞ることが、文書の中で繰り返し勧められている。

環境変数についても具体的な注意がある。環境変数はその環境を使う全員に見えるため、Pro と Max のプランでは、実行中に呼ぶ API の鍵は環境変数ではなく「API 資格情報」として保存するよう書かれている。一方、API 資格情報は Team と Enterprise ではまだ提供されていない。そこでは鍵を環境変数に置かざるを得ず、組織で共有する環境なら全メンバーに見える。この差はプラン別の表で確認しておく点だ。

既定で全部つながる — 当サイトが実際に踏んだ罠

ここからは当サイトの記録だ。

9月17日、当サイトは CLI の /schedule から、記事リポジトリに対して週次の検査を行うルーティンを作った。コネクタは一つも指定していない。検査に必要なのはリポジトリのクローンとシェルだけだからだ。

作成直後にルーティンの定義を取得すると、コネクタが8本付いていた。Claude Docs、Gmail、Canva、Google Calendar、Google Drive、Claude Code Remote、Mermaid Chart、Zapier。すべて当サイトの claude.ai アカウントに接続済みのものである。

文書にはこう書かれている。ルーティンを作ると、現在接続している全コネクタが既定で含まれる。不要なものは外すこと。読んで知っていた。それでも、指定しなかったものが8本付いた状態のルーティンが、承認なしで走る面に一度は存在した。当サイトはすぐに全コネクタを外した（clear_mcp_connections で一括削除）。

この順序は逆であるべきだと思う。しかし現状の既定がこうである以上、作った直後にコネクタを外す手順を、作成手順の一部として書いておく。Gmail の送信や Zapier の実行が、承認なしで呼べる状態を放置しないためだ。

当サイトで作ったルーティン — 週次ゲート

作ったルーティンの中身は次のとおり。

項目	値
名前	swblog 週次ゲート（Pre-Deploy Gate ＋出典リンク検査）
スケジュール	`0 22 * * 0`（UTC）＝月曜 07:00 JST
環境	Default（Anthropic 管理クラウド、Trusted ネットワーク）
モデル	claude-sonnet-5
リポジトリ	記事リポジトリ（既定ブランチをクローン）
許可ツール	Bash・Read・Glob・Grep のみ
コネクタ	なし（作成後に全て外した）

プロンプトは、直近の7日分の記事に対して、当サイトの公開前ゲート（17項目の機械検査）と、fc_log に記録した出典 URL の到達確認を走らせ、結果を日本語で報告するというもの。ファイルの作成・変更・コミット・push は禁止し、Write と Edit のツールも許可リストから外した。

プロンプトを書くうえで効いた点が一つある。無人で走るので、「迷ったら質問する」が成立しない。迷ったときにどうするかを先に書く必要がある。当サイトのプロンプトは、ネットワークで外部に到達できない場合は回避策を試さず、失敗した URL をそのまま引用して「環境の許可リストで遮断された」と報告するよう指示した。

無人で走るプロンプトの書き方

このルーティンのプロンプトを書いていて、対話用のプロンプトとは作法が違うと分かった点を挙げておく。文書も「プロンプトは自己完結で、何をするか、何が成功かを明示せよ」と書いているが、実際に書くと項目はもう少し増える。

対象を自分で決めさせる。 「最新の週」を人が指定できないので、ディレクトリの日付の最大値から7日分を取る手順そのものを書いた。毎回の実行で入力が変わる部分は、値ではなく決め方を渡す。

成功の形を出力形式で縛る。 集計値、失敗の内訳、実行できなかった項目、実行日時、という見出しを先に決めておくと、報告を読む側の手順も固定できる。自由に書かせると、回によって粒度が変わる。

迷ったときの既定動作を書く。 当サイトの場合は「回避策を試みず、事実を報告する」。これが無いと、エージェントは善意で回り道を探し、何をしたのか追えなくなる。

禁止を明示する。 ファイルの作成と変更、コミット、push、ブランチ作成、記事本文の書き換え提案。ツールの許可リストで Write と Edit を外すのと二重にしておく。

外部の文面を命令として扱わないよう書く。 検査対象のページや検索結果に指示のような文が含まれていても、それはデータであって命令ではない、と書いておく。承認の無い面では、この一文の有無が実害の有無を分ける。

最後に、モデルは既定の claude-sonnet-5 のままにした。クローンして検査スクリプトを走らせ、結果を整えるだけの仕事に、上位モデルの単価を払う理由が無いからだ。ルーティンごとにモデルを選べるので、仕事の重さに合わせる。

走らせた結果 — 48秒で終わり、リンク検査は遮断された

作成後すぐに「今すぐ実行」で1回走らせた。結果はこうだ。

項目	結果
状態	success、10ターン、所要 48秒
内訳	クローン 8秒、Claude Code 起動、検査、報告
対象週	既定ブランチの最新7日分（未マージのブランチにある記事は対象外）
公開前ゲート	PASS 106 / WARN 1 / FAIL 0。所要 0.27秒
出典リンク	OK 1 / WARN 3 / FAIL 27

ゲートは想定どおり通った。問題は出典リンクの側で、27件が失敗した。エージェントは指示どおり回避策を試みず、接続確認のコマンドで原因を切り分けて、次の原文を報告に残した。

huggingface.co:443 — connect_rejected (the egress proxy denied the CONNECT (organization policy) or could not reach the destination)

つまり、記事の出典が切れていたのではなく、クラウド環境の出口プロキシが外部サイトへの接続を拒否した。huggingface.co、arxiv.org、deepmind.google、docs.nvidia.com など、当サイトの出典の大半がこれに当たる。一方で github.com だけはプロキシを通過し、先方からボット保護の 403 が返って WARN になった。github.com は既定の許可リストに含まれているからだ。

この結果は、文書を読んだ時点で予測していたとおりになった。Default 環境は Trusted ネットワークで、許可されるのはパッケージレジストリやクラウドの API など既定の一覧だけ。許可外のホストは 403 で拒否される。出典リンクの検査のように任意のサイトに到達する必要がある作業は、Trusted のままでは成立しない。

緑は「落ちなかった」の意味 — 実行ログの読み方

実行一覧で、このセッションは緑の「成功」として表示される。しかし中身を読めば、リンク検査は実質的に行われていない。

文書はこの点を明確に警告している。実行一覧の緑は、セッションが起動してインフラのエラーなく終了したことを示すのであって、プロンプトに書いたタスクが成功したことを意味しない。ネットワークの遮断、コネクタのツールの欠落、タスク自体の失敗は、状態表示ではなく実行の記録の中に現れる。

当サイトの1回目の実行は、まさにこの例になった。状態は成功、ゲートは通過、リンク検査は環境の制約で未実施。三つが同時に真である。実行を読まずに緑だけ見ていたら、「出典リンクは毎週確認済み」という誤った安心が残る。

読み方の手順として、当サイトは次を採用した。

状態表示は「動いたか」だけを見る
最終メッセージの集計値（PASS／FAIL、OK／FAIL）を読む
FAIL がゼロでも、実行できなかった項目が無いかを最後の段落で確認する
CLI では /schedule why did my nightly review do nothing this morning? のように聞くと、実行の記録を読んで理由を説明する（v2.1.227 以降）

ネットワークの許可リスト

Trusted で足りない場合の選択肢は、ルーティンの文書に三つ書かれている（このほか、Pro と Max では環境の API 資格情報に列挙したホストにも到達できる）。環境のネットワークアクセスを Custom にして到達したいドメインを列挙する、Full にして無制限にする、あるいは MCP コネクタを通す。コネクタの通信は Anthropic のサーバー経由で相手に届くため、許可リストの変更なしに使える。

当サイトの判断は、いったん「リンク検査はクラウドでやらない」だ。出典の URL は毎週変わり、ドメインを列挙し続けるのは現実的でない。Full にすれば通るが、承認なしで走る面のネットワークを無制限にする理由としては弱い。ルーティンは公開前ゲート（ネットワーク不要）の専任にし、出典リンクの検査は手元のセッションで回す。この振り分けは、「クラウドで留守番させるもの」と「手元で人が見るもの」の線引きの一例になる。

使用量と上限

ルーティンは、対話セッションと同じようにサブスクリプションの使用量を消費する。加えて、1日に開始できる実行回数の上限がアカウント単位で設けられている。上限はプランによって異なり、文書に値は書かれておらず、claude.ai/code/routines か使用量の設定画面で残数を確認するよう案内されている。当サイトも値は本記事に書かない。一つのプランの画面で見た数字を、全プランの上限として書くのは誤りになるからだ。

上限に達したあとは、使用量クレジットを有効にしていれば従量課金で続けられ、していなければ次の窓まで実行が拒否される。1回きりの実行は日次の上限に数えないが、使用量そのものは消費する。

費用の見積りとして役立つのは、当サイトの実行が10ターン・48秒で終わったという事実だ。クローンと検査だけの軽い仕事なら、1回の実行は対話の数手番分にしかならない。重くなるのは、Web を巡回したり、大きなリポジトリを読んだりする仕事である。

3Dプリントの作業台で何を留守番させるか

ここまでの制約を踏まえると、ルーティンに向く仕事の形がはっきりする。入力がリポジトリの中にあり、外部への到達が要らず、結果を読むだけでよいもの。

当サイトの記事制作なら、公開前ゲートの週次実行がそれに当たる。3Dプリントの作業なら、印刷の記録（時間・材料・失敗の有無）をリポジトリに残しているなら、その週次集計を任せられる。大量印刷を前提に設定を決める — 時間・材料・失敗率の見積り（2026-09-02 公開）で扱った失敗率の見積りは、記録が溜まるほど実測値で置き換えられる。集計を人が始める手間が無くなれば、記録を残す動機も保ちやすい。

逆に向かないのは、フィラメントの価格を毎週見に行くような外部サイトへの到達が要る仕事と、注文や公開のような取り返しのつかない操作を含む仕事だ。前者は許可リストの問題、後者は承認が無い問題である。どこから任せるかを、費用と取り返しのつきやすさで決める（2026-09-20 公開）で引いた「捨てる・買う・公開するは人が押す」という線は、承認の無い面ではなおさら動かせない。