L4 ─ Scheduled / Routines で時間軸を切り離す

L3 はイベント駆動 ── 何かが起きたら動く。L4 は 時間駆動 ── 「毎朝 9 時」「毎週月曜」「毎月 1 日」というカレンダー軸で動く。

これが「寝ている間に成果が出る」状態の正体。

3 種類の Scheduled

公式 Scheduled Tasks ドキュメント で 3 種類が整理されている：

種類	動作場所	あなたの PC が落ちていても動くか	設定
Cloud Routines	Anthropic クラウド	✅ 動く	/schedule で登録
Desktop Scheduler	あなたの PC（macOS launchd / Linux cron）	❌ PC が落ちると止まる	同左
/loop skill	あなたの session 内	❌ session を閉じると止まる	session 内で起動

graph TB
  subgraph "実行場所"
    C[Cloud Routines<br/>Anthropic クラウド]
    D[Desktop Scheduler<br/>ローカル PC]
    L[/loop skill<br/>session 内]
  end

  subgraph "持続性"
    P1[PC 落ちても OK]
    P2[PC 起動が必要]
    P3[session 開いている必要]
  end

  C --> P1
  D --> P2
  L --> P3

  style C fill:#e1ffe1
  style D fill:#fff4e1
  style L fill:#ffe1e1

「あなたが寝ていても動く」のは Cloud Routines だけ。これが L4 の core。

いきなり Cloud に乗せない ─ dely の段階移行

zenn / dely_jp の記事「定常業務を自動操縦にする」 は L4 の段階移行を見事に整理している：

まず Desktop で動かす → 安定したら Cloud に昇格

なぜか？ Cloud Routines は 失敗してもあなたの目の前で起きない。token を浪費しても気付かない。loop が暴走しても止められない。

graph LR
  Stage1[Stage 1<br/>/loop で動かす<br/>session を開いて確認] --> Stage2[Stage 2<br/>Desktop Scheduler<br/>PC 起動中だけ]
  Stage2 --> Stage3[Stage 3<br/>Cloud Routines<br/>完全に手放す]

  style Stage1 fill:#ffe1e1
  style Stage2 fill:#fff4e1
  style Stage3 fill:#e1ffe1

各 stage で確認するのは「失敗パターンを尽くしたか」「通知設計はあるか」「コスト上限はあるか」。これらが固まってから上に昇格する。

設定の基本 ─ Cloud Routines

/schedule コマンドで登録：

/schedule

Task name: weekly-trend-article
Description: 毎週月曜 9 時 JST に AI 業界のトレンドをまとめて Zenn に下書き保存
Cron: 0 0 * * 1  # UTC で月曜 0:00 = JST で月曜 9:00
Action prompt: |
  以下を実行：
  1. 過去 1 週間の主要 AI ニュースを web 検索（特に Anthropic / OpenAI / Google）
  2. 重要度上位 5 件を選出
  3. 各記事を 200-300 字で要約
  4. Zenn 用 markdown を生成、frontmatter 付き
  5. ./drafts/<日付>.md に保存

これで毎週月曜 9 時 JST に Claude が自律的に走る。あなたが旅行中でも、PC を閉じていても動く。

実例 1：tm_dev の週次自動記事生成

zenn / tm_dev の記事 は Cloud Routines の素直な活用例。

やっていること

graph LR
  Cron[Cloud Routines<br/>毎週月曜 09:00] --> Search[Web 検索]
  Search --> Filter[重要度フィルタ]
  Filter --> Write[記事生成]
  Write --> Zenn[Zenn に下書き]
  Zenn --> Notify[Slack 通知]
  Notify --> Human[人間が最終確認]

  style Cron fill:#e1f5ff
  style Human fill:#fff4e1

ポイントは 「下書き保存」で止める こと。完全公開まで自動化すると：

• 重大な誤情報が拡散する
• 重複コンテンツで SEO ペナルティ
• 自分のブランドが毀損される

「人間が最終確認するための土台を Claude が用意する」という思想。これは LINE ヤフーの「準備は AI、判断は人」と同じ構造。

コスト感

このパターンは 週 1 実行 × Sonnet クラスのモデル で、月数百円〜数千円のオーダー。情報商材が言う「全自動コンテンツ工場で月100万」とは別世界。現実的な ROI は「自分の手間が浮くこと」 であって直接収益ではない。

実例 2：定期的な依存更新チェック

OSS / 個人プロジェクトでよくあるユースケース：

/schedule

Task name: weekly-deps-check
Cron: 0 1 * * 1  # 月曜 10:00 JST
Action prompt: |
  1. cd ~/projects/my-app
  2. npm outdated --json で更新可能な依存を取得
  3. 各 dependency の changelog を確認
  4. patch / minor 更新は自動で PR 作成
  5. major 更新はリストアップして Slack 通知のみ
  6. PR にはテスト実行結果を含める

Dependabot でも似たことはできるが、Claude を使う利点は：

• changelog を読んで影響範囲を要約してくれる
• 複数依存を関連性で grouping できる
• breaking change の対応コードを書けることもある

実例 3：日次インシデント report

社内ツールなら：

Task name: daily-incident-report
Cron: 0 22 * * 1-5  # 平日 7:00 JST
Action prompt: |
  1. PagerDuty MCP で過去 24h のインシデント取得
  2. Datadog MCP でメトリクスから関連 alert 取得
  3. GitHub MCP で関連 PR / commit 取得
  4. 30 分以内に読める report を生成
  5. Slack #incidents-summary に投稿

これも MCP との合わせ技で（L5 の伏線）、3 つのデータソースを横断する朝刊を Claude が作る。

/loop の使い所

/loop は session 内で繰り返し実行する skill。Cloud / Desktop と違い「あなたが見ている前で繰り返す」用途。

/loop

Interval: 5 minutes
Action: ./scripts/check_build.sh で build 状態を確認、失敗していれば修正案を提示

これが効くのは 長時間の build / test を見守る ような場面。「ビルドが落ちたら直して、もう一度ビルドして」を session を開いたまま繰り返す。

L4 として「自律」させる用途には適さない（session を閉じると止まる）。だが Stage 1（最初のテスト） には便利。

L4 の最大リスク ─ 暴走と無自覚

L4 の本質的な怖さは「人が見ていない」点だ。L1〜L3 では何か起きれば気付く。L4 で起きる失敗は気付くまでに時間がかかる：

graph LR
  Bug[bug 発生] -->|L1: 即時| F1[人間が気付く]
  Bug -->|L2: hook で block| F2[block される]
  Bug -->|L3: PR / Issue| F3[GitHub UI で見える]
  Bug -->|L4: 真夜中| F4[気付かない<br/>翌朝 / 来週判明]

  style F4 fill:#ffe1e1
  style F2 fill:#e1ffe1

これに対抗するために L4 では 「気付く設計」が L1〜L3 より重い。

必須要素 1：成功・失敗の通知

すべての L4 task は通知を設計する。

# Pseudo
on_success:
  - slack: "#routines-success" → サマリーだけ（毎日読む必要はない）
on_failure:
  - slack: "#routines-alerts" → 即対応すべき
  - email: メンテナへ

「失敗を通知しない L4 task」は禁止。気付かない自動化は、ないより悪い。

必須要素 2：コスト上限

/schedule の設定で：
- max_tokens_per_run: 50000
- max_runs_per_day: 1
- monthly_cost_cap: $50

月額 cap を必ず設定。情報商材が言う「全自動」を真に受けて cap なしで走らせると、loop バグで月数十万円飛ぶ事故が起きる（実際にいくつか報告がある）。

必須要素 3：dry-run / canary

新しい task をいきなり Cloud に乗せない。

Stage 1: /loop で 1 度だけ実行（dry-run）
Stage 2: Desktop で 1 週間動かす（canary）
Stage 3: Cloud に昇格

これが dely 社の「段階移行」の中身。

必須要素 4：殺すスイッチ

「動いている scheduled task を一覧する / 止める」術を確保する。

# Cloud Routines
claude routines list
claude routines delete <name>

# Desktop
launchctl list | grep claude  # macOS
crontab -l | grep claude       # Linux

これを 手元の cheatsheet にしておく。深夜に暴走している task を慌てて止める時に「あれ、どうやって止めるんだっけ」になると地獄。

L4 の典型的な ROI

L4 が効くのは：

用途	ROI が出る目安
週次レポート生成	自分が手で書くと 2h → Claude で 5min（人間レビュー込み）
依存更新 PR	Dependabot よりも判断付き、月数時間の節約
業界トレンド要約	情報感度を保ちつつ調査時間を 1/10
定期的な品質監査	Linter で取れない人間的観点も含む
個人ブログの定期更新	ネタ切れ防止

逆に L4 が効かないのは：

• 月 1 回しかやらない作業（設計コストが浮いた時間を上回る）
• 内容が毎回大きく違う作業（型化できない）
• 結果を評価する人間がいない作業（フィードバックループが切れる）

副業視点での L4

L4 は副業との相性が一番怪しい。理由は：

• 直接収益にならない：定期実行で「コンテンツ生成」しても、それが質の高い記事として流通するかは別問題
• コストが出やすい：cap 忘れの token 浪費は副業では致命的
• 暴走リスクが「副業時間外」に発生する：本業中に Slack で alert が鳴る

「Claude Code を Cloud Routines に乗せて月 100 万」を謳う情報商材は、L4 の暴走リスクを語らないところで本物と区別できる。

本物の L4 副業活用は地味に：

• 自分の zenn / note の 下書き を週次で生成（最終公開は手動）
• 受託案件の 進捗 report を朝刊として自動生成
• 自分の technical blog のための 業界調査ノート を週次で蓄積

これらは「時間が浮く」だけで、お金は別途稼ぐ必要がある。

L4 のチェックリスト

graph TB
  C1[type 化済みか<br/>= L1 完了] --> C2[Hook で品質ゲートあるか<br/>= L2 完了]
  C2 --> C3[/loop で dry-run] --> C4[Desktop で canary]
  C4 --> C5[通知設計] --> C6[コスト cap]
  C6 --> C7[殺すスイッチ確保] --> Cloud[Cloud Routines に昇格]

  style Cloud fill:#e1ffe1

この章の要点

• L4 = 時間駆動。Cloud Routines / Desktop Scheduler / /loop の 3 種類
• 「あなたが寝ていても動く」のは Cloud だけ。Desktop は PC 必要、/loop は session 必要
• いきなり Cloud に乗せない。/loop → Desktop → Cloud の段階移行（dely 流）
• 必須要素：成功/失敗の通知、コスト上限、dry-run、殺すスイッチ
• L4 の最大リスクは 無自覚 ── 暴走に気付かない時間が長い
• ROI が出る用途と出ない用途を明確に切り分ける
• 副業煽りは L4 を「全自動収益」と誤誘導する。本物は地味に時間を浮かせるだけ

次章への問いかけ

ここまで Claude が 1 体で動く 前提だった。だが扱う問題が複雑になるほど、1 体では限界が見える。

次章は L5：Sub-agent と MCP で多体化する。Anthropic Growth Marketing の「generator + validator」のような役割分担、MCP で外部システムを道具として持たせる設計。

＋ － ⟳ ✕