はじめに
2026年4月14日に Claude Code Routines がリリースされました。スケジュールや GitHub イベントをきっかけに、無人で Claude Code を走らせられる機能です。
筆者は個人事業の業務ファイル（タスク管理・トレンド収集・経理記録など）をひとつの Git リポジトリで管理しています。日々のタスクやトレンド収集、経理確認などを Claude Code に任せていたので、「これ全部 Routines に寄せたらどうなるのか」が気になりました。
そこで4月15日から17日までの3日間、4本のルーチンを24時間走らせてみました。結論から言うと、便利でした。ただ、止め忘れで課金が想定より増えたり、通知が深夜に連発したり、思わぬ事故も起きました。
この記事はその実録です。成功談だけでなく、失敗した箇所や止め方のオペレーションまで正直に書きます。これから Routines を試す方の参考になれば幸いです。
補足1: 本記事は単一環境・単一運用者（筆者1名）による N=1 の事例です。別プラン・別用途では傾向が変わり得ます。
補足2: 金額や契約条件など、業務機密に触れる部分はぼかしています。あくまで「筆者環境の目安」としてお読みください。
Routines の前提をざっくり整理
まず仕様面の整理です。公式ドキュメント（Routines 公式 docs）とAnthropic 公式ブログを踏まえると、ポイントは次の3点です。
3種類のトリガー
| トリガー | 内容 | 主な用途 |
|---|---|---|
| schedule |
hourly / nightly / weekly などの定期実行 |
朝の定型作業、夜間バッチ |
| API | Webhook やスクリプトからの呼び出し | 既存の業務フローへの組み込み |
| GitHub | issue / PR / push 等のイベント | 自動トリアージ、CI補助 |
プラン別の実行回数
| プラン | 1日あたりの実行回数 |
|---|---|
| Pro | 5回 |
| Max | 15回 |
| Team / Enterprise | 25回 |
「多い」と感じるか「少ない」と感じるかは運用次第です。筆者は Max プランですが、トリガーを4本まで絞って運用しました。1日15回あれば、hourly を回さない限り十分足ります。
クラウドで実行される
ここが /loop や Desktop Scheduled Tasks との大きな違いです。ルーチンは Anthropic のクラウド側で走ります。そのため、Mac がスリープ中でも、外出中でも実行されます。その反面、ローカルファイルを前提にしたワークフローは動きません。筆者のようにローカルの output/ ディレクトリに成果物を置く運用では、クラウド側から GitHub リポジトリに commit してもらう形にしました。
/loop や Desktop Scheduled Tasks との違い
以前から使っていた定期実行系の機能と並べてみます。
| 項目 | Routines | /loop | Desktop Scheduled Tasks |
|---|---|---|---|
| 実行場所 | Anthropic クラウド | ローカル端末 | ローカル端末 |
| 起動条件 | schedule / API / GitHub | セッション内でモデル自律 | 時刻指定（cron 風） |
| 端末スリープ時 | 動く | 動かない | 動かない |
| 実行回数制限 | プランごとに上限あり | なし（トークン消費次第） | なし |
| 状態の永続性 | セッションが残る | その場限り | その場限り |
| 向いている用途 | 無人の定期バッチ | 短時間のポーリング | ローカル資産が前提の処理 |
筆者の棲み分けはこうなりました。
- 朝のトレンド収集や夜の経理チェックのような「自分が見てなくても回したい」業務 → Routines
- デプロイ後の様子を5分おきに確認するような「今だけ回したい」処理 → /loop
- ローカルの Docker や大きなデータを触る処理 → Desktop Scheduled Tasks
この切り分けは、Zenn の aria3 氏の整理記事とも近い結論でした。
実装した4つのルーチン
今回動かしたのは次の4本です。どれも既に Skill 化してあった業務を Routines に移植しました。
1. 毎朝のトレンド収集（schedule / daily 08:00）
目的は、朝のコーヒーを入れる前に今日のネタ帳を埋めておくことです。/trend-check Skill を呼び、AI・Claude Code 界隈の1次情報を output/trends/YYYY-MM-DD.md に保存させます。
ルーチンの設定は Web UI から行いますが、筆者は手元のメモに擬似的な YAML で構成を残しています（公式スキーマではなく、あくまで筆者の整理用です）。
# 筆者メモの擬似YAML（公式仕様ではありません。正確なスキーマは公式 docs を参照）
name: morning-trend
schedule: daily 08:00 JST
prompt: |
/trend-check を実行してください。
AI / Claude Code / 生成AI 関連の直近24時間の1次情報を収集し、
output/trends/[実行日付].md に保存してください。
収集後、git add → commit → push までお願いします。
最初は git push を忘れていて「クラウド側で commit だけして終わり、手元で pull するまで成果物が見えない」状態になりました。これは初日の学びです。
2. 毎晩の経理入金確認（schedule / daily 22:00）
/update-finance Skill を夜に走らせます。Google Sheets に置いた請求管理シートを MCP 経由で読み、入金ステータスを照合します。未入金の行があれば Slack へ通知します。
これは地味ですが効果が大きく、「請求書を出したまま忘れる」ミスが3日間でゼロになりました。以前は月末にまとめてチェックしていたので、見落とすとその分キャッシュフローに響きます。
3. GitHub Issue 自動トリアージ（trigger / issue.opened）
GitHub トリガーで、新しい issue が立ったらラベル付けと優先度判定を行わせます。
# 筆者メモの擬似YAML（公式仕様ではありません。正確なスキーマは公式 docs を参照）
name: issue-triage
trigger: github issues.opened
prompt: |
/issue-triage スキルで対象の issue を処理してください。
タイトル・本文・ラベル候補から重要度を判定し、
優先度ラベル（P0/P1/P2/P3）を1つ付けてコメントを残してください。
ただしこれが一番「事故りやすい」ルーチンでした。詳しくは後述します。
4. 週次活動レポート（schedule / weekly Mon 07:00）
/weekly-activity-report Skill で、開発プロジェクトの git 履歴と会話履歴を横断して週報を生成します。月曜の朝、シャワーを浴びている間に Slack へ届いている状態を目指して登録しました。
週1回しか動かないので Routines の実行枠には優しいのですが、そのぶん1回の生成に40〜50分かかる想定です。ここはトークン消費が最も大きい処理になる見込みで、実運用の結果は次回の記事でまとめます。
3日間のタイムライン
時系列で起きたことを記録しておきます。数字は筆者環境の目安です。
Day 1（4/15 水）─ 導入とミス
朝にトレンド収集ルーチンを登録。動作確認のつもりで短周期のテスト用ルーチンも動かしたまま就寝してしまいました。翌朝 Max の1日15回枠を使い切っていました。
テスト用は必ず「1回だけ動かして削除」が鉄則です。
Day 2（4/16 木）─ Opus 4.7 との組み合わせ
ちょうど Opus 4.7 が GA された日でした（Anthropic公式）。Routines のモデル設定を Opus 4.7 に切り替えると、長時間タスクの出来が目に見えて上がりました。ただしトークン消費も1.4倍くらいに増えた体感です。
Day 3（4/17 金・午前時点）─ issue トリアージが暴走
本稿執筆時点（4/17 午前）での出来事です。朝方、社外のコラボレーターが依存リポジトリに大量の issue を立てたタイミングで、トリアージ用ルーチンが連続発火しました。1件ごとに Slack 通知が鳴り、気づいた時には15件分のセッションが並んでいました。
プラン上限に達した時点で自動停止してくれたのが唯一の救いです。午後以降の経過は、後日別途追記する予定です。
翌日以降の運用計画（4/18 以降）
本稿は3日間の運用で得た学びをまとめた中間報告です。翌日以降は次の方針で運用を続ける予定です。
- 4/18（土）以降: Day 3 の事故を受けて、issue トリアージ側に PreToolUse hook を噛ませ「1時間に3件まで」の上限を足す。詳細は後述します。
- 週末（4/18 土、4/19 日）: 開発を止めるため、トレンド収集と経理確認だけを回す想定。
- 週明け（4/20 月）: 週次レポートが月曜朝に届くことを期待。1週間分の結果は別途まとめる予定です。
事故事例 3件
ここが Routines を使う上で一番お伝えしたい部分です。3件とも自分でやらかしました。
コスト実績（概算）
筆者環境の3日間の目安です。金額の実数は伏せます。
| 項目 | 消費量（目安） |
|---|---|
| トレンド収集（3日） | 中（1日あたり低） |
| 経理入金確認（3日） | 低 |
| issue トリアージ（15件 / Day 3に集中） | 中 |
| テスト用ルーチン暴走（Day 1） | 高（全体の約3割） |
感覚値ですが、「安定運用の2日間」に対する「事故った1日分」のコスト比率は、ほぼ同じオーダーでした。つまり、事故をゼロにできれば費用対効果はかなり良い、というのが正直なところです。
Max プラン内に収まる前提で設計すればランニングの追加課金は出ませんが、事故があれば簡単に跳ねます。ここは他の SaaS の従量課金と同じ感覚で扱ったほうが安全です。
監視・停止オペレーション
3日間の運用を通じて固まった、筆者のオペレーションをまとめます。
毎朝のチェック
-
/schedule listで登録中のスケジュール一覧を確認 - 直近24時間の実行ログを確認（失敗 / 暴走がないか）
- 不要なテスト用ルーチンが残っていないか確認
/schedule は list / update / run を扱えます（公式 docs）。シンプルですが、ここを朝の儀式にしておくと事故が減ります。
緊急停止の手順
想定外の挙動に気づいたら、筆者はこの順で止めています。
- Claude Code の Web UI（ブラウザ）から該当ルーチンを停止、または
/schedule updateで無効化 - 念のため全ルーチンを順に無効化（ワンコマンドでの一括停止は公式機能として提供されていないため、事前に一覧をメモしておく）
- Slack / GitHub 側の通知 webhook も一時的に止める
- 落ち着いてから原因調査
肝心なのは「停止手順をスクリーンショット付きで事前に用意しておく」ことです。焦った深夜に手順を組み立てる余裕はありません。
hook によるガード
事故2の再発防止として、PreToolUse hook でレート制御を仕込みました。概念コードですが次のような形です。
#!/usr/bin/env bash
# .claude/hooks/pre-tool-use-routines.sh
# issue トリアージの発火を1時間3件までに制限
LOG=/tmp/claude-routines-triage.log
touch "$LOG"
NOW=$(date +%s)
COUNT=$(awk -v now="$NOW" 'now-$1 < 3600' "$LOG" | wc -l)
if [ "$COUNT" -ge 3 ]; then
# PreToolUse hook の公式仕様では hookSpecificOutput.permissionDecision を使う
# （旧来の {"decision":"block"} / exit 2 は deprecated）
cat <<'JSON'
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "triage rate limited (3/hour)"
}
}
JSON
exit 0
fi
echo "$NOW" >> "$LOG"
exit 0
Hooks については拙著の【完全ガイド】Claude Code Hooks で開発ワークフローを自動化するも合わせて参考にしてみてください。
週に1度の棚卸し
週1で次のような棚卸しをしています。
- 実行されなかった / 失敗したルーチンを確認
- 使っていないルーチンは削除（ゴミを残さない）
- コストをプラン枠と比較して、翌週の構成を調整
ルーチンは増えやすい一方で、止めるのは億劫になります。「追加したら1週間後に必ず再評価する」ルールにしておくと、ルーチンの肥大化を防ぎやすいです。
所感・学び
3日間で感じたことを4つに絞ります。
1. 使いどころは「自分が見ていない時間」
Routines の価値は「端末が動いていなくても実行される」点に尽きます。筆者の場合、移動中や就寝中の時間が明確に稼働時間に変わりました。逆に、見ていたほうが早いタスクには向きません。対話しながら試行錯誤する作業は、従来通りの TUI でやるのが結局速いです。
2. 事故は「設計の粗さ」から起きる
3件の事故はいずれも、筆者が「何件まで走らせるか」「どこで止めるか」を最初に決めていなかったのが原因でした。ルーチン定義と同時に、発火回数の上限と停止手順もセットで書いておくのが安全です。
3. Skill 化済みの作業との相性が良い
もともと /trend-check や /update-finance のように Skill として日々使っていた業務は、Routines への移植がほぼノーコストでした。逆に Skill 化されていない雑多なワークフローを直接ルーチンに書こうとすると、プロンプトが肥大化してデバッグしにくくなります。「まず Skill、その次に Routines」の順番がおすすめです。
4. Opus 4.7 + Routines は手触りが良い
4月16日にリリースされた Opus 4.7 (whats-new-claude-4-7) は、長時間タスクでの安定感が向上していました。長文の収集・要約タスクでは早速恩恵を感じました。ただしトークン消費は素直に増えます。Routines との組み合わせでは、effort を無闇に上げすぎない運用が現実的だと思います。
まとめ
Claude Code Routines を3日間運用してみた結果、次のように感じました（N=1・単一環境の事例である点はご留意ください）。
- 「自分が見ていない時間」に動かす用途にはとても向いている
- 一方で、発火制御や停止手順を最初に整備しないと簡単に事故る
- Skill として定着させた業務との相性が良く、移植コストは低い
- コストは「安定運用」と「事故」でほぼ同じオーダーになり得るので、防衛策の優先度が高い
- 監視・停止は
/scheduleコマンドと hook でオペレーション化しておくと安心
4月14日にリリースされたばかりの機能なので、まだ運用ノウハウは固まりきっていません。筆者の環境では上記のような使い方に落ち着きましたが、読者の方の業務に合わせて調整していただければと思います。
もし自分でも試す場合、最初に次の3点だけ決めてから走らせるのをおすすめします。
- 最初のルーチンは1本だけにする（複数同時に始めない）
- 発火回数の上限と停止手順を先に書く
- 24時間後に必ず
/schedule listで棚卸しする
ここまで読んでいただきありがとうございました。Routines を安全に、かつ楽に使っていきたい方の参考になれば嬉しいです。