/scheduleコマンドで日次のPRレビューやイシュートリアージを動かしたい人向け
毎週月曜のGitHub Issuesトリアージ、毎日のPRレビュー、本番デプロイ後のスモークテスト、Sentry等の監視ツールからのWebhook起動など、ラップトップを閉じても勝手に動いてほしい定期処理・イベント駆動処理をClaude Codeに任せたい場面で、ユーザーは /schedule コマンドを自然言語で叩く。裏側で RemoteTrigger がRoutineを作る。
RemoteTriggerは、claude.aiの「Routines（ルーティン）」を作成・更新・実行・一覧する内蔵ツールです。普段は /schedule コマンドの裏側で勝手に動くので、ユーザーが RemoteTrigger という名前を直接叩くことはまずありません。Claude Codeが「定期実行を作って」「あのRoutine回して」と頼まれた瞬間、内部でこのツールを呼びます。
Routinesは、Anthropicのクラウドで動く「保存済みのClaude Code設定」です。プロンプト・対象プロジェクト・コネクタを1セットにまとめて、決まった時刻やGitHubイベントをきっかけに自動で走らせる仕組み。ラップトップを閉じても動き続けます。
噛み砕くと
普通のClaude Codeは、目の前のパソコンで対話しながら動かすものです。Routinesはそれを「会社の自動掃除ロボット」に置き換えた感じ。掃除内容（プロンプト）・掃除エリア（プロジェクト）・使う道具（コネクタ）を最初に登録しておく。あとはタイマー・ボタン・センサーの3種類のスイッチでロボットが勝手に起動する。
RemoteTrigger自体は、そのロボットの登録窓口・起動スイッチ・状態確認パネル全部を担当する内部の事務員みたいなものです。表からは見えない。
大事な前提：使えるプランと使えない経路が決まっている
RemoteTriggerは、claude.aiのインフラがそのまま使える契約じゃないと動きません。具体的には次の条件です。
- OK: Pro / Max / Team / Enterprise プラン（claude.aiの個人アカウントまたは組織アカウント）
- NG: Freeプラン
- NG: Amazon Bedrock、Google Vertex AI、Microsoft Foundry経由でClaude Codeを使っている場合
会社が「Bedrock契約しかしてない」とか「Vertex経由でしかClaudeを通せない」状態だと、RemoteTriggerは画面上にも出てきません。これは公式ドキュメントのツール一覧表にも明記されている制限です。
もうひとつ、Team / Enterpriseの場合は管理者が組織全体でRoutinesをOFFにしていることがあります。その時は /schedule を叩いても「Routines are disabled by your organization's policy」と返ってきて、自力では復旧できません。管理者に頼むしかない。
「料理ブログのIssuesを毎週月曜朝9時にトリアージ」を例に、実際の手順を見る
私が運営している料理ブログのGitHubプロジェクトには、コメント欄から自動で起票されるバグ報告・要望Issuesが毎週20〜30件たまります。これを月曜朝9時にClaudeに見せて、ラベル付け・担当者割り当て・Slackへの要約投稿までやらせるRoutineを作ってみます。
ステップ1: /schedule を自然言語で叩く
Claude Codeを起動して、対話画面の中で /schedule と打ち、続けて自然な日本語で何をしたいか伝えます。
> /schedule 毎週月曜の朝9時に cooking-blog プロジェクトのオープンIssuesを読んで、内容に応じてラベルを付けて、担当者を割り当てて、Slackの #blog-ops チャンネルに要約を投稿するするとClaudeが「どのプロジェクトを使う？」「Slack連携は入ってる？」「タイムゾーンはJSTでいい？」と順に聞いてきて、5〜6往復で全部埋まります。最後にこんな確認メッセージが返ります。
Routine created: "Weekly Cooking Blog Triage"
Schedule: Every Monday at 09:00 JST
Repository: yourname/cooking-blog
Connectors: GitHub, Slack
Next run: 2026-05-25 09:00 JST裏側ではこの瞬間、RemoteTriggerが「Routineをひとつ作る」操作を実行しています。
ステップ2: claude.aiの管理画面で見えるか確認する
ブラウザで claude.ai/code/routines を開くと、いま作ったRoutineが一覧に出ています。クリックすると、プロンプト・対象プロジェクト・コネクタ・トリガー・過去の実行履歴が全部見える詳細ページに飛びます。
ここで重要なのが、CLIから作ったRoutineもWeb管理画面に即座に表示される、ということ。逆もそう。CLI・Web・Desktopアプリのどこから作っても、同じクラウドアカウントに保存されます。
ステップ3: 月曜を待たずに「Run now」で動作確認
Routineを作った直後は、月曜まで待たずに今すぐ動かして挙動を確認したい。Web画面の「Run now」ボタンを押すか、CLI側で /schedule run を叩きます。
> /schedule run Weekly Cooking Blog Triage
Triggering routine...
Session started: https://claude.ai/code/session_01HJKL...このURLをブラウザで開くと、Claudeがクラウド上で実際に動いている様子をリアルタイムで観察できます。Issuesを1件ずつ読んで、ラベルを付けて、Slackに投稿するまでの全工程が流れる。
ステップ4: ここで初心者がやりがちな勘違い
「Routineを動かしてる間、手元のパソコンが何かしているはず」と思いがちですが、違います。実行は全部Anthropicのクラウドで完結します。私のMacBookは閉じてても、電源OFFでも、関係なく月曜朝9時に動きます。これがRemoteTriggerと、よく似た名前のCronCreateの決定的な差です。
ステップ5: GitHub eventトリガーを追加する（Web限定）
月曜の定期実行に加えて、「新しいPull Requestが立ったら自動でレビューも回したい」とします。これはCLIからは追加できません。/schedule CLIで作れるのは時刻ベースのトリガーだけだからです。
追加方法はWeb限定。claude.ai/code/routines でRoutineを開いて、鉛筆アイコンから「Add another trigger」→「GitHub event」と進みます。対象プロジェクトを選んで、イベントは pull_request.opened、フィルタで「is draft: false」を指定すれば、下書きPRは無視されて完成版だけがClaudeに飛んでいきます。
ステップ6: APIトリガーで監視ツールから叩く（応用）
料理ブログのアクセスが急増した時にSentryから通知が飛んでくるとしたら、その通知をフックにRoutineを起動することもできます。「Add another trigger」→「API」を選ぶとRoutine専用のURLとトークンが生成されます。SentryのWebhook設定にこのURLとトークンを入れておけば、エラー発生時にClaudeが自動でログ調査して修正PRまで作る流れが組める。
curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCD.../fire \
-H "Authorization: Bearer sk-ant-oat01-xxxxx" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'トークンは生成時に1度だけ表示されて、後から見直せません。SentryやPagerDutyの秘密ストアに即座に貼り付けるのが安全。
RemoteTrigger でできること・できないこと
- できる: claude.aiのRoutinesを作る・更新する・即時実行する・一覧する4つの操作。
/scheduleコマンドの裏側で自動的に呼ばれる - できる: ラップトップを閉じてもクラウドで動き続ける。手元のパソコンの稼働状態と完全に切り離される
- できない: ユーザーがRoutine実行中に「これやって」と途中で割り込むこと。実行は自律的で、許可プロンプトも出ない
- できない: GitHub event / API トリガーの追加。CLIからは時刻ベースのトリガーしか作れない、Web画面に行く必要がある
- 意味が薄い場面: 手元のローカルのファイルを毎日ちょっといじりたいだけの用途。その場合はDesktop scheduled taskか
/loopの方が向いている
使いどころ3シナリオ（具体題材で再現）
シナリオ1: 料理ブログのIssuesを毎週月曜9時にトリアージ
料理ブログを個人運営していて、読者コメントからGitHub Issuesに自動転送されるバグ報告と要望が毎週20〜30件たまる。月曜朝9時の30分を「Issues整理タイム」に消費していた。/schedule 毎週月曜9時にcooking-blogプロジェクトのIssuesをトリアージしてSlackに要約 でRoutine化すれば、月曜朝には整理済みの状態でSlackに通知が届く。私はそれを見るだけ。週30分が週5分に縮みます。
シナリオ2: 家計簿アプリのPRをClaudeに事前レビューさせる
友人と2人で開発している家計簿アプリで、お互いのPull Requestを「機械的なチェック（型ミス、セキュリティ、コードスタイル）」と「設計レビュー」に分けたい。GitHub eventトリガーで pull_request.opened をフックに、Claudeがインラインコメントで型ミス・SQL injection疑惑・スタイル違反を全部指摘する流れになる。人間レビュアーは設計の議論だけに集中できます。
シナリオ3: 本番デプロイ後の自動スモークテスト
家計簿アプリを本番デプロイした直後、CI/CDパイプラインの最後にRoutineのAPIエンドポイントを叩く。Claudeが新バージョンに対してログイン・支出登録・グラフ表示のスモークテストを自動で回して、エラーログに新しい例外が出ていないかチェック。問題なければSlackに「go」、おかしければ「no-go」が投稿される。リリース当番が0時に張り付かなくて済む。
初心者が踏みやすい落とし穴
- CronCreateと混同する。名前が似てるけど完全に別物。CronCreateは「いま開いてるClaude Codeセッションの中で動く・閉じたら消える・最短1分間隔」。RemoteTriggerが司るRoutinesは「クラウドで動く・閉じても継続・最短1時間間隔・自律実行」。永続させたいならRoutines、ちょっとした実験ならCronCreateと使い分け
- Bedrock / Vertex / Foundry経由では使えない。会社がクラウドプロバイダ契約でしかClaude Codeを許可してない場合、RemoteTriggerは選択肢に入りません。これは公式が明記しているハードな制限で、回避策はなし
- CLIからGitHub / APIトリガーは追加できない。
/scheduleで作れるのは時刻ベースのトリガーだけ。「PR立ったら起動」や「Webhookで起動」を足したいならclaude.ai/code/routinesのWeb画面で編集する必要がある。CLIに固執して時間を溶かさないこと - 管理者が組織でOFFにしているケース。Team / Enterprise契約だと、組織のadminがRoutinesトグルをOFFにしていることがある。
/scheduleを叩いて「Routines are disabled by your organization's policy」と返ったら自力では復旧不能、管理者に頼むしかない - GitHub identity / connectors が「あなた」として動く。RoutineがGitHubに立てるPRの作成者欄には Routine オーナーのGitHubユーザー名が入る、Slack投稿も同じく Routine オーナー名義で飛ぶ。Routinesはチームメイトと共有されない個人アカウント単位の仕組みなので、「立てたRoutineが本人の名前で勝手に動き回る」前提で組む。退職時のRoutine引き継ぎは要注意
- 「Run now」のステータス緑＝成功ではない。Routines一覧の緑バッジは「セッションがインフラエラーなく終了した」という意味だけ。「プロンプトに書いたタスクが成功した」とは限らない。最初の数回は必ずセッションURLを開いて、Claudeが実際に何をやったか中身を読むこと。盲信しない
- APIトークンは1度しか表示されない。Generateボタンを押した直後に出るトークン文字列を、その場でSentryやPagerDutyの秘密ストアに貼り付けないと、二度と見えません。失くしたら Regenerate で作り直し
- Research previewなので仕様が変わる。
/fireエンドポイントはexperimental-cc-routine-2026-04-01という日付付きベータヘッダーを必須にしている時点で、近い将来に仕様変更が来る可能性が高い。本番ワークフローに深く埋め込む時は、ベータヘッダーのバージョン管理を運用の前提に入れる
書き方
ユーザーが直接叩くのではなく、/schedule コマンドの裏側で Claude が自動的に呼び出す内蔵ツール。表向きの書き方は次の通り：
/schedule <自然言語の指示>
/schedule list
/schedule update
/schedule run <routine name>
例: /schedule 毎週月曜9時にcooking-blogプロジェクトのIssuesをトリアージしてSlackに要約やってみるとこうなる
入力
/schedule 毎週月曜の朝9時に cooking-blog プロジェクトのオープンIssuesを読んで、内容に応じてラベルを付けて、担当者を割り当てて、Slackの #blog-ops チャンネルに要約を投稿する出力例
Routine created: "Weekly Cooking Blog Triage"
Schedule: Every Monday at 09:00 JST
Project: yourname/cooking-blog
Connectors: GitHub, Slack
Next run: 2026-05-25 09:00 JSTこのページに出てきた言葉
- Routines
- claude.aiのクラウドで動く「保存済みのClaude Code設定」のこと。プロンプト・対象プロジェクト・コネクタを1セットにして自動実行する仕組み
- Research preview
- 研究段階での先行公開のこと。仕様や上限が今後変わる可能性があると公式が明言している状態
- コネクタ
- claude.aiが外部サービスと連携する仕組み。RoutineからSlackに投稿したり、Linearにチケットを切ったりできる
- ベアラートークン
- 「これを持っている人が正規ユーザーです」という証明書代わりの文字列。HTTPリクエストの <code>Authorization: Bearer xxxxx</code> ヘッダーに入れて送る
- Webhook
- 外部サービスでイベントが起きた瞬間に、こちらが指定したURLへ自動でデータを送り込む仕組み。SentryやGitHubが「事件起きたよ」と能動的に通知する
- cron
- 「毎週月曜9時に実行」のような時刻指定を <code>0 9 * * 1</code> という書式で表す古典的な記法。Routinesも内部ではcron式を使う
- プロジェクト
- GitHub上で見える「ファイル一式と変更履歴をまとめて保管した箱」のこと。英語管理画面では Repository と表示される
- トリアージ
- たくさん溜まったIssuesやチケットを優先度・担当・種類で振り分ける作業。元々は救急医療の患者振り分け用語