Claude Code Routinesが来た｜Macを開きっぱなしにしなくていい時代の無人運用ガイド

昨日、Anthropicから静かな、しかし小さな事業者にとっては地味に大きいアップデートが出ました。Claude Codeに routines（ルーチン）というリサーチプレビュー機能が追加された、という発表です。一言で要約するなら、「プロンプトとリポジトリと接続先を一度登録しておけば、あとはスケジュール・API・イベントで勝手に走る。しかもAnthropicのクラウド側で動くから、自分のノートPCを開きっぱなしにしなくていい」という話です。

私は今までこの連載の中で、Macにlaunchdを仕込んで毎朝2時にエージェントを叩き起こす話を何度も書いてきました。それなりに動きます。ただ正直に言うと、一番の泣きどころは「Macを閉じたら止まる」でした。電源を抜けば止まる。macOSをアップデートすれば再起動で止まる。出張に行ってホテルのWi-Fiが弱いと止まる。自動化したつもりがMacの機嫌取りに変わっていく、あの感覚です。

routinesは、この泣きどころを根っこから取り払います。実行環境がAnthropicのウェブインフラ側に移るということは、私のMacの状態とは切り離されて走るということ。夜中に停電しようが、私が新幹線の中で電源を落としていようが、ルーチンは粛々と回り続けます。

本記事では、発表内容の整理、既存のlaunchd運用からの乗り換え判断、そして小さな事業でどう使い倒すかの具体案を書いていきます。記事末尾には、手持ちのlaunchd設定をroutinesに引っ越すためのコピペ用プロンプトも置いているので、忙しい方はそれを先にスクロールしてください。

図: routinesの全体像

発表内容をざっくり整理する

公式アナウンスの要点は次の4つです。

1. 機能名は routines（ルーチン）。ステータスはリサーチプレビュー
2. 設定する対象は3つ。プロンプト、リポジトリ、コネクタ
3. 実行トリガーは3種類。スケジュール実行、API呼び出し、イベント駆動
4. 実行場所はAnthropic側のウェブインフラ。ユーザーのPCを開いておく必要はない

一つずつ、小さな事業の視点で噛み砕きます。

まずプロンプト。これは要するに「何をやってほしいか」を書いた指示書です。今まで皆さんがCLAUDE.mdやターミナルから叩いていた指示を、そのまま登録する、というイメージに近い。

次にリポジトリ。routinesは単発のチャットではなく、特定のコードベースやドキュメントに紐づく形で動きます。私の理解では、これがroutinesのキモです。要するに「どの作業机の前に座らせるか」を決めておける。毎回コンテキストをゼロから渡し直さなくていい。

コネクタは、外部サービスへの接続設定です。Slack、Gmail、Google Drive、GitHub、Linearなど、Anthropicが用意する接続口を事前に登録しておき、ルーチンから使えるようにする。これも毎回認証しなくていい、という地味な恩恵があります。

最後にトリガー。ここが今回の発表で一番面白いところです。

• スケジュール: 毎朝8時、毎週月曜9時、のような時間起動
• API: 外部システムから「今走って」と叩ける
• イベント: 特定の出来事（新しいIssue、新しいメールなど）に反応して起動

スケジュールはlaunchdやcronでも当然できます。イベント駆動も、頑張ればWebhook受け口を自作できます。でもこの3つを1箇所にまとめて、しかもAnthropic側のインフラで回してくれる、というのが今回の発表のキモです。

launchd運用と何が違うのか

この連載をずっと読んでくれている方のために、301・302で書いた構成との違いを表にします。

図: launchd運用 vs routines

違いは技術的な細かさよりも、運用者の心理負荷の方に出ます。launchd時代は、朝起きて最初にやるのは「昨夜ちゃんと走ったか確認」でした。落ちていたらMacを覗き込み、ログを見て、原因を探す。月に何度かは、OSのアップデートで再起動がかかり、plistの登録が外れていた、みたいな地味な事故が起きます。

routinesに引っ越すと、この「Mac様のご機嫌取り」タスクが消えます。代わりに、失敗したルーチンの通知を見て原因を調べる、という作業に変わる。性質は似ていますが、心理的な重さが違います。Macが起きていたかどうかという自分の生活と地続きの心配事から、抽象的なクラウド上の出来事になります。この差、やってみると大きいです。

小さな事業で何に使うか、具体5ケース

routinesが便利そうだと分かっても、実際に何に使うかイメージが湧かないと意味がありません。私が今ぱっと思いつくだけで、次の5つはすぐ置き換えたいと感じています。

ケース1: 毎朝のニッチメディア記事生成

これは私自身がやっている用途の筆頭です。深夜2時に記事の企画を10本生成し、朝6時までに下書きが揃っている状態を作る。launchd時代はこのために毎晩Macを起動したまま寝ていました。routinesならMacを閉じて寝られます。小さな話ですが、生活の質が変わります。

ケース2: 競合の価格チェック

スケジュール起動で毎朝9時に、競合サイト3社の商品価格ページをコネクタ経由で取得し、前日差分を出してSlackに投げる。今まで「誰かが気づいたら教えて」だった領域を、誰も見ていなくても毎朝自動で転がる領域に持ち替えられます。

ケース3: 新規問い合わせへの1次返答

イベント駆動の出番です。Gmailに特定のラベルが付いたメールが届いたら、コネクタ経由でメール本文を読み、当社の過去FAQとプライシング資料を参照した1次返答ドラフトを生成。私はそれを見て、良ければそのまま送信する。この構成は、ひとり事業で問い合わせ対応に時間を取られている人に劇的に効きます。

ケース4: 週次の売上・指標レポート

毎週月曜8時、決まったスプレッドシートとStripeの数字を取りに行って、先週との差分と3行コメントを書いてnote下書きに放り込む。自分への週次報告を、自分に作らせない。小さい事業ほど、この「振り返りの固定化」が継続の土台になります。

ケース5: ドキュメントの陳腐化チェック

毎週金曜、特定のリポジトリ内のREADMEやドキュメントを読み、直近のコミットで触られた機能と照らし合わせて、古くなっている記述を洗い出す。ひとりでコードとドキュメントを両方維持するのは負担が大きいので、ここをルーチン化できると気持ちが楽になります。

図: routinesの典型フロー

今すぐ乗り換えるべきか、様子見でいいか

ここは正直に書きます。リサーチプレビューという表記が意味するのは、「本番運用で事故が起きても文句を言える場所がない」ということです。仕様が変わる可能性もあるし、料金体系が後から変わる可能性もあります。

私の判断基準は次の3つです。

1. 失敗しても誰にも迷惑がかからないタスクから入れる
2. クリティカルな問い合わせ返答やお金に直結する処理は当面launchdと二重運用する
3. 最低2週間、手動でログを見てから信頼度を上げる

具体的には、ケース1（記事下書き生成）とケース2（価格チェック）はすぐroutinesに移します。ケース3（問い合わせ返答）はルーチン化しても送信は手動のまま、という運用にします。ケース4・5は2週間様子見してから。こういう温度差を持たせると、新機能の事故リスクを飲み込みつつ、恩恵は取りにいけます。

launchdから引っ越すときの注意点

実際に引っ越してみて、私が事前に知っておきたかった注意点を3つだけ置いておきます。

注意点1、実行時間の上限が違う可能性があります。launchdは実質無制限でしたが、routinesはクラウド側の実行時間制約があると思っておいた方が安全です。長大なバッチ処理は分割してください。

注意点2、ログの持ち方が変わります。私は今まで実行ログをSQLiteに全部突っ込んでいましたが、routinesは実行履歴がクラウド側に置かれます。自分の手元にも履歴を残したい場合は、ルーチンの最後にWebhookかメール送信を挟んで、自分のDBに書き戻す導線を作っておくと後悔しにくいです。

注意点3、コネクタの権限は広めに取らない。routinesが勝手に動くということは、認証情報も勝手に使われるということです。Gmailなら読み取り専用、Google Driveなら特定フォルダのみ、のように最小権限で登録するクセを最初から付けてください。あとから絞るのは面倒になりがちです。

まとめ: 無人運用の重心がクラウドに移った日

今回のアップデートは、ニュースとしては地味ですが、連載で扱ってきた「ひとりで事業を24時間稼働させる」という設計思想にとっては、けっこう大きな節目です。今まで私たちは、24時間稼働を自分のMacと launchd という家内制手工業で支えていました。これがAnthropic側のインフラに移る、ということは、家内制手工業が工場に変わる、ということに近い。

一方で、職務記述書（エージェント定義）の書き方や、品質フックの設計思想は、routinesになっても変わりません。むしろ、クラウド側で勝手に走る分、プロンプトの品質が結果にそのまま出ます。ここの詰めは、これまで以上に大事になります。

私はこの2日間で、launchdで回していたジョブのうち記事生成と価格チェックをroutines側に引っ越しました。引っ越し作業自体は1ジョブ30分以内でした。下に、私が実際に使った移行用のコピペプロンプトを置いておきます。

🎁 特典: launchdからroutinesに引っ越すためのプロンプト

お手持ちのplistファイルの内容をまるごとClaude Codeに貼り付けて、以下のプロンプトを続けて送ってください。現状の起動設定をroutines用の登録項目に自動で翻訳してくれます。

あなたはClaude Codeのroutines機能への移行を手伝うアシスタントです。
以下に、私が現在macOSのlaunchdで動かしているplist設定を貼り付けます。
この内容を分析し、routinesに登録する際に必要な項目を次の形式で出力してください。

## 出力してほしい項目
1. ルーチン名（日本語で20字以内）
2. 実行目的の1行説明
3. 登録すべきプロンプト本文（そのままroutinesに貼れる形）
4. 参照すべきリポジトリ（plist内のパスから推測）
5. 必要なコネクタ一覧（GitHub/Slack/Gmail等、plistから推測）
6. トリガー種別の提案（schedule / api / event のどれが最適か、理由つき）
7. 推奨実行頻度（cron記法と日本語の両方）
8. 想定される失敗パターンと検知方法
9. 引っ越し前に手動テストすべき項目チェックリスト

## 制約
- 存在しない機能を前提にしない
- 認証情報は絶対に出力に含めない
- 既存のplistで使われている環境変数は「※要確認」とマークする

それでは、以下のplistを分析してください:

[ここにplistの中身を貼り付け]

このプロンプトは、特別なことは何もしていません。ただ、今までMacの世界だけで閉じていた設定情報を、routinesという新しい器に合わせて再整理するだけです。でも、自分で1から項目を洗い出すより、だいぶ楽になります。

🎁 特典: routines移行チェックリスト（zipダウンロード）

あわせて、今回の記事で紹介した5ケースそれぞれに対応する「ルーチン登録シート」と、上記の移行プロンプトをまとめたテンプレート一式を配布します。

zipの中身:

• migration-prompt.txt — launchdからroutinesへの移行プロンプト（上記と同じもの）
• routine-template-01-daily-articles.md — 毎朝の記事生成ルーチン設計シート
• routine-template-02-competitor-watch.md — 競合価格チェックルーチン設計シート
• routine-template-03-inquiry-reply.md — 問い合わせ1次返答ルーチン設計シート
• routine-template-04-weekly-report.md — 週次レポートルーチン設計シート
• routine-template-05-doc-rot-check.md — ドキュメント陳腐化チェックルーチン設計シート
• migration-checklist.md — launchdから引っ越すときの事前確認リスト
• README.md — セットアップと使い方

: claude-routines-migration-kit-v1.0.0.zip （note編集画面の「ファイル」メニューからアップロードしてください）

📚 参考リファレンス

• Claude Code 公式ドキュメント — routinesのドキュメントはここに追加されていくはずです
• @claudeai の発表ツイート — 今回のアナウンス元
• developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html — launchd側の挙動を理解したい方向けのリファレンス
• awesome-claude-code — コミュニティが集めるClaude Code活用事例集

Claude Works（claudelab.jp）で最新情報をお届けしています](https://x.com/ClaudeCodeDigest)