はじめに

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件とも自分でやらかしました。

事故1: 停止忘れで課金が跳ねた

Day 1 のテスト用ルーチン（5分間隔）を消し忘れて就寝した件です。Pro や Max にはプラン内の実行回数上限がありますが、超過分は追加課金の対象になる場合があります。筆者の場合は1日分の想定を明らかに上回るトークンを消費してしまい、翌朝の請求見込みが通常日の3倍近くになっていました。

ルーチンを作ったら、まず /schedule list で必ずリストを確認してから就寝するのをおすすめします。

事故2: 通知が鳴り止まない

issue トリアージの連続発火（Day 3）では、Slack に15通の通知が2分以内に飛びました。深夜帯で家族にも迷惑をかけました。

GitHub トリガーは event の発火タイミングを制御できないので、「1時間に何件まで」「深夜帯は通知を抑制する」といった上限を自分で設計する必要があります。

事故3: 意図せず複数セッションが重複

週次レポートを2つ登録してしまったパターンです。/weekly-activity-report の weekly スケジュールを2回定義してしまい、同じ時間に2セッションが走って、同じ内容のレポートが2通届きました。

幸い、どちらもプラン上限の範囲だったので金額的被害はありませんでしたが、/schedule list で重複を確認する癖はつけたほうが良いです。

コスト実績（概算）

筆者環境の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 を安全に、かつ楽に使っていきたい方の参考になれば嬉しいです。

参考リンク