Claude Code Routine実装手順｜定刻起動AI秘書

Claude Code Routineで「定刻に出勤するAI秘書」は作れるのか

「Claude Code routine」「Anthropic scheduled remote agent」「AI 定期実行」と検索した方が知りたいのは、おそらくこの一点です。夜中でも休日でも、毎朝決まった時間に勝手に動いてくれるAIエージェントを組めるか。

結論として、Claude Code は対話型CLIであり、それ自体は常駐サービスではありません。ターミナルを閉じれば止まり、Macがスリープに入れば中断されます。一方で、Anthropicが提供する Scheduled Remote Agents（公式スキル /schedule）を使えば、cronで指定した時刻にAnthropic側のクラウドで新しいセッションが自動起動し、ローカルの起動状態とは無関係に仕事をこなしてくれます。

私は実際に「毎朝7時にGoogleカレンダーと全クライアント案件を集約して報告するAI参謀（コードネーム: Argus）」をRoutineとして実装・検証しました。本記事では、その手順とハマったポイント、そしてなぜ最終的に「ローカル運用先行」を私の運用標準にしたのかまでを実体験ベースで解説します。

前提: Claude Code は「常駐サービスではない」という根本制約

まず最初に整理しておきたいのが、Claude Code のアーキテクチャです。Claude Code は基本的に ターミナルから対話的に呼び出すCLIツールであり、ユーザーがプロンプトを入力するたびに API を叩いて応答を返す構造になっています。

これは Cursor や Cline のようなエディタ統合型AIと近い設計で、「画面を閉じても裏で動き続けるAIエージェント」とは根本的に違います。具体的には次の制約があります。

• セッションは対話のたびに維持されるが、CLIプロセスを閉じれば終了する
• Macがスリープに入れば、CLIの処理は当然止まる
• launchd や cron で claude コマンドを叩くこともできるが、その場合もローカルマシンが起きていることが前提
• 外出先や深夜帯など、PCが触れない時間帯は基本的に何もできない

私自身、当初は「Macを付けっぱなしにして /loop で日次GSCレポートを自動取得する」という運用を1週間ほど続けていました。これでも実用にはなるのですが、外出時にMacを閉じると処理が止まる、電源を落とすと再起動後に手動で立ち上げ直す必要があるといった「ローカル前提の弱さ」が露骨に見えてきます。

ここに対してAnthropicが用意した解が、Scheduled Remote Agents（Routine）です。

Routine = クラウド側でフレッシュセッションを定刻起動する仕組み

Routine の本質は「cronで指定した時刻に、Anthropic側のサーバで新しいClaude Codeセッションを起動し、定義済みタスクをこなして終了する」仕組みです。メタモデルは次のとおりです。

ポイントは「ローカルのMacが起きているかとは無関係」という点です。Anthropicインフラ側で起動するため、Macが閉じていようが出張中だろうが、cron時刻になれば確実にセッションがスポーンされます。

ただし、この仕組みには対話型Claude Codeにはない制約が3つあります。

• 各実行は完全独立な「フレッシュセッション」: 前回の会話・記憶は引き継がれない。毎回0スタート
• ローカルファイルにアクセスできない: クラウドのコンテナで動くため、自分のMacのファイルは見えない。GitHubリポジトリ経由で clone して読む形になる
• 外部サービス連携はMCP接続が前提: Google Calendar、Notion、Gmailなどへのアクセスは、Anthropic公式MCPで事前接続しておく必要がある

この3つを理解していないと、後述する「実装したのに何も読めない」問題にハマります。私は最初の数回、まさにここでつまづきました。

実装手順: /web-setup → /schedule → 動作テストの3ステップ

ここからは、私が実際にArgus（朝のブリーフィング担当AI参謀）をRoutine化した手順を再現性の高い形で示します。

ステップ1: /web-setup で Claude → GitHub の連携を完了する

Routine はローカルファイルを直接読めないため、必ずGitHubリポジトリ経由で必要なファイル（persona定義やスキル定義、データ等）にアクセスします。そのため最初に /web-setup スキルでClaudeとGitHubの連携設定を済ませます。

Anthropic側にGitHubアクセストークンを登録し、対象リポジトリを clone できるようにします。私はモノレポ全体を扱う st-dev0/projects をリンクしました。

重要なのは、Routine が見るのはGitHubに push されている最新コミットだけという事実です。ローカル更新しても push していなければ古い状態に見えます。詳しくは後述します。

ステップ2: /schedule でRoutineを作成する

連携が済んだら /schedule スキルで実際のRoutineを作成します。設定する項目は次の5つです。

• cron式: UTC基準で記述する。日本時間（JST）の朝7時に動かしたいなら 0 22 * * *（22:00 UTC = 翌朝7:00 JST）
• repository: 対象のGitHubリポジトリと branch を指定（私は main）
• prompt: 起動時にエージェントに渡されるシステムプロンプト
• tools allowed: 使える組み込みツール（Bash, Read, Write, Edit, Glob, Grep が標準）
• MCP connections: Google Calendar や Notion など外部接続済みMCP

私のArgus用Routineの prompt は、persona定義ファイルへのポインタを渡すだけのシンプルなものにしました。理由は、prompt 内に毎回フルスペックを書くと管理が崩れるからです。

具体的には次のような prompt にしています。「.claude/agents/argus.md を読み込み、その指示に従って朝のブリーフィングを実行せよ。報告は secretariat/morning-briefings/YYYY-MM-DD.md に保存し、git commit & push してターミネートせよ」と。

こうしておくと、persona の内容を更新したいときは argus.md を編集して push するだけで済み、Routine 自体の設定は触らずに済みます。

ステップ3: RemoteTrigger run で即時テスト

cron時刻まで待っていると検証コストが高すぎるため、Anthropicは RemoteTrigger という即時実行APIを用意しています。実装後はこれで何度かテスト実行を回し、ログを見ながら prompt を調整するのが効率的です。

私の最初のテストでは、次のような典型的エラーが出ました。

• 「argus.md が見つからない」 → push 漏れ。ローカルにはあるがリモートには無い状態
• 「Google Calendar への接続が確立されていない」 → MCP connections に追加し忘れ
• 「カレンダー取得時のタイムゾーンが UTC で時刻がズレる」 → prompt 内で Asia/Tokyo を明示する必要あり

1〜2回回せば解消できますが、「ローカルとリモートで同じ動作になる」と思い込んでいるとハマります。Routineは別環境です。

動作確認が取れたら enabled で本番運用開始。止めたいときは disabled に切り替えるだけで凍結でき、再開もワンクリックです。

つまずきポイント: ローカルとGitHubの状態同期問題

Routine を実運用に乗せた瞬間に必ず直面するのが、「Routineが見ている世界はGitHub上の最新コミットでしかない」という現実です。これを理解せずに運用すると、次のようなことが起きます。

• ローカルでクライアント案件のCLAUDE.mdを更新したが、まだ push していない
• 翌朝7時にRoutineが走り、古いstageと古いnext_actionで報告してくる
• 「あれ、昨日更新したはずなのに反映されていない」と混乱する

原因は単純で、Routineは main ブランチの最新コミットしか clone しないからです。ローカルの未コミット変更や未push変更は、Routineには「存在しない情報」になります。

解決策1: launchd autocommitを高頻度化する

私のモノレポでは元々、毎日23:00に launchd でgit autocommit & pushする仕組み（scripts/git-autocommit.sh）が動いていました。これを3時間ごとなどに高頻度化することで、ローカル → GitHubの同期遅延を最小化します。

たとえば朝7時のRoutineに対しては、その直前（6:55や6:50）に最終autocommitを走らせておけば、当日朝までの更新がほぼ確実に反映されます。私はこの「Routineの直前にautocommitする」設計を「ピンポイント先回りpush」と呼んでいて、わざわざ別のlaunchdジョブを追加しています。

解決策2: rebase戦略でpush競合を吸収

もう一つの落とし穴が、Routine自身もGitHubに push する場合の競合です。Argusはブリーフィング結果を secretariat/morning-briefings/2026-05-01.md として保存し、git commit & push しますが、ほぼ同時にローカルautocommitが走ると衝突することがあります。

私は両方とも git pull --rebase origin main を実行してから push する運用に統一して回避しています。Routine側も git pull --rebase を prompt に明記しておくと、push衝突がほぼ起きなくなります。

「常時稼働するAIエージェント」との比較: 定刻スポーン型でも体験は出せる

近年「OpenClaw」のような常時稼働型AIエージェントのコンセプトが語られるようになりました。これは「電源を入れた瞬間からPC内で常駐し、ユーザーの作業を見ながら自律的にタスクを発火する」という方向性のものです。

Routine はこのような常時稼働型ではありません。あくまで「cron時刻にスポーンして仕事して終わる」定刻型です。しかし、cron頻度を細かくすれば「常時稼働している体験」はかなりの精度で出せます。

たとえば次のようなRoutineを並列で走らせると、ユーザー体感としては「いつもAIが先回りしている」状態になります。

• 毎朝7時: 全予定・全クライアント案件のブリーフィング
• 2時間ごと: GitHub の Issue / PR を巡回し、未対応のものをDigest化
• 毎日昼12時: 午前中の進捗を一行サマリで Slack 通知
• 毎週月曜朝: 先週の振り返り＋今週の優先度提案

こうしておけば、フル自律ではなくとも「定刻に出勤するAI秘書」として十分機能します。動作タイミングが固定されている分、人間側のリズムに乗せやすいメリットもあります。

私の運用判断: ローカル運用先行 → 安定後にRoutine化

ここまでRoutineの便利さを書いてきましたが、私の現時点での運用判断は「いったんRoutineは無効化して、ローカル運用を先行する」です。理由を3つ述べます。

第一に、persona定義やfrontmatterの質が安定していない段階でRoutine化するのは早すぎるからです。Routineは毎回フレッシュセッションで起動するため、persona定義に曖昧さがあると報告品質がブレます。ローカルで何度も対話しながら磨き込み、「この定義で起動すれば必ずこの品質の報告が返る」と確信が持てた段階で初めてRoutine化するのが安全です。

第二に、ローカル → GitHubの同期設計が未成熟だと、古い情報を元に報告される事故が起きます。autocommit高頻度化やrebase戦略は、運用してから必要性に気付く類の施策です。土台ができてからRoutine化しないと、信頼できない出力が積み上がるだけです。

第三に、クラウド実行はAPI課金が増えること。1日5回のRoutineを走らせる試算をしましたが、ローカル実行と比べて使用枠を圧迫します。フル24時間稼働を組む前に、どのRoutineが本当に投資に値するかをローカル運用で見極める必要があります。

結論として、私の現在の方針は次のとおりです。

• 第1段階（現在）: ローカルで対話的に運用し、persona定義・スキル・データソースを磨く
• 第2段階: 同期設計（autocommit高頻度化・rebase戦略）を整える
• 第3段階: 安定したスキルから順にRoutine化していく

関連して、定期実行手段の使い分け（/loop・cron・routinesの違い）については、過去にも踏み込んだ記事を書いていますので、合わせて読んでみてください。

定期実行の手段ごとの違いと使い分けを整理した記事はこちらです。

Claude CodeClaude Code定期実行の完全比較｜/loop・cron・routinesの使い分け

リモートエージェント（クラウド実行）に絞った設計の入門は、こちらの記事で解説しています。

Claude CodeClaude Codeリモートエージェント活用法｜/remote・/schedule・/loopの実践

まとめ: 「常駐ではない」を理解した上で、定刻起動を武器にする

本記事の要点を整理します。

• Claude Code 自体は対話型CLIで、常駐サービスではない
• Routine はcron時刻にクラウド側でフレッシュセッションを起動する仕組み
• 各実行は完全独立で記憶なし。ファイルはGitHub経由、外部連携はMCP経由
• 実装は /web-setup → /schedule → RemoteTrigger でテスト → enabled
• ローカルとGitHubの同期遅延が最大の落とし穴。autocommit高頻度化とrebase戦略で吸収する
• cron頻度を細かくすれば「定刻に出勤するAI秘書」の体験は出せる
• persona定義とデータ品質が安定するまではローカル運用先行が正解

「常駐できないなら使えない」と切り捨てるのではなく、「定刻起動という制約を逆手に取って、リズムある業務インフラを作る」という発想に切り替えることをおすすめします。土台ができてからクラウド化する、この順番が遠回りに見えて結局いちばん早いと考えています。