Claude Codeの定期実行はローカルとクラウドどっち？｜私の振り分け方

Claude Codeに定期的な仕事を任せるとき、最初に迷うのが「どこで動かすか」です。自分のPCで動くローカル型か、Anthropicのクラウドで動くクラウド型か。公式ドキュメントや解説記事には比較表が並んでいますが、自分の作業をどちらに置けばいいかは、表を眺めても決めきれませんでした。

私はObsidianのVaultで、ニュースの収集や週次のメンテナンスなど6本をクラウドで、ノートの片付け1本をローカルで回しています。前回の記事では「ローカルとクラウドの使い分けは別の記事で」と書いたので、今回はその続きです。

この記事では、私がどんな基準で振り分けているか、実際にどう組み合わせているか、併用して初めて気づいた落とし穴を紹介します。どちらが優れているかの話ではありません。作業の性質で置き場所を決める、という話です。

Claudeの定期実行は3種類ある

まずは前提として、選べる方式を整理しておきます。細かい比較は公式ドキュメントに任せて、振り分けに関わるところだけに絞りました。

私の環境では、Web版・デスクトップ版とも、画面の表記は「スケジュール済みタスク」です。以前は「ルーティン（routines）」と呼ばれていました。ただしアカウントによっては、画面がまだ「ルーティン」表記のままかもしれません。

URL（claude.ai/code/routines）やCLIの/routinesにも、旧名が残る箇所があります。この記事では、まとめて「定期タスク」と呼びます。

項目	クラウドの定期タスク	デスクトップアプリのローカルタスク	/loop
どこで動くか	Anthropicのクラウド	自分のPC	開いているセッションの中
PCとアプリ	不要	アプリが起動していて、PCが起きている間だけ	セッションが開いている間だけ
ローカルのファイル	見えない（毎回GitHubのリポジトリをクローンする）	見える	見える
最短の間隔	1時間	1時間（Claudeに頼めば1分）	1分
期限	なし	なし	7日で失効

※2026-11-15時点の公式ドキュメントで確認。クラウドの定期タスクはリサーチプレビューのため、仕様が変わる可能性があります。

表だけでは見えにくい注意点も、4つ挙げておきます。

• ローカルはスリープ中に動かない：予定時刻を寝過ごした分はスキップされます。スリープ防止の設定があっても、ノートPCの蓋を閉じれば止まります
• 逃した分の補完は1回だけ：起動や復帰のときに過去7日分を確かめますが、動くのは最後に逃した1回だけです
• クラウドの時刻はUTC：cron式はそのまま書くとUTCとして扱われます。正時ちょうどは数分遅れることがあるため、9:07のように少しずらすよう案内されています
• /loopは一時的な繰り返し用：セッションの中で一定時間ごとに確認する、といった使い方向けです。毎週の定期運用には向きません

私の振り分け基準：作業の性質で決める

比較表を見ると、クラウドのほうが便利そうに見えますよね？ PCが稼働していなくても動き、時刻もずれにくいからです。それでも私は全部をクラウドに寄せず、1本だけローカルに残しています。

決め手は、作業の中身でした。

ローカルに置くのは「Vaultを直接さわる作業」

ローカルに置いているのは、Vaultのノートを動かす作業です。Obsidianでは、ノートを移動するとそのノートへのリンクも自動で書き換わります。ただしそれは、Obsidianを通して動かしたときの話です。

私はObsidian CLIを使って、起動中のObsidianにノートを移動させています。クラウドのクローンにはObsidianアプリがありません。ファイルを動かすことはできても、リンクの追従までは任せられないわけです。

なので、ノートの移動やリネームのように、Obsidianの機能に頼る処理はローカルに置いています。

クラウドに置くのは「リポジトリの中で完結する作業」

残りはクラウドです。Webから情報を集めてノートにまとめる。Vaultのリンク切れや台帳のずれを点検する。こうした作業は、リポジトリのファイルとWebさえあれば完結します。結果をGitHubにコミットすれば、手元のVaultにも届きます。

時刻どおりに動いてほしい作業も、クラウドを選びます。毎朝のニュース収集が、PCを起動した昼過ぎにずれ込むのは困りますよね。

決め手は「アプリが落ちていることがある」こと

私の環境では、Obsidianはほぼ一日中開いています。一方で、Claudeのデスクトップアプリは時々落ちてしまいます。

ローカルのタスクは、アプリが起動していないと動きません。復帰したときの補完も、最後の1回だけです。「毎日必ず」の作業をローカルに置くと、アプリを閉じていた日の分は黙って抜けてしまいます。そこで、ローカルに置くのは多少ずれても困らない作業だけにしました。

迷ったときは、次の3つを順に考えています。

1. ローカルのファイルやアプリ（Obsidianなど）が必要か → 必要ならローカル
2. 時刻どおりに動かないと困るか → 困るならクラウド
3. 結果をどこで読むか → 手元のVaultで読むなら、クラウドの成果物を取り込む仕組みまで含めて考える

実例：私のVaultの定期タスク7本

実際に回している定期タスクを並べると、次のようになります。クラウドが6本、ローカルが1本です。

定期タスク	頻度（日本時間）	置き場所	選んだ理由
AIニュースの日次収集	月〜土 9:00	クラウド	Webの収集で完結する。毎朝の時刻を守りたい
週次メンテナンス	月曜 9:00	クラウド	リンク切れや台帳の点検で、リポジトリの中で完結する
Obsidianの週次情報収集	日曜 10:00	クラウド	Webの収集で完結する
Claude運用の週次情報収集	日曜 11:00	クラウド	Webの収集で完結する
Wikiへの自動取り込み	日曜 21:00	クラウド	Webクリップをまとめ直す作業で、リポジトリの中で完結する
ブログの競合リサーチ巡回	毎月1日 12:00	クラウド	Webの収集で完結する
AIニュースの既読分の片付け	月曜 8:30	ローカル	ノートの移動にObsidianを使う

見てのとおり、ほとんどがクラウドです。ローカルに残ったのは、Obsidianが必要な1本だけでした。

なお、競合リサーチ巡回は毎月1日に1回だけ起動する1本です。その中で、既存記事の鮮度点検は毎月、ジャンル全体の動向チェックは2か月に1回、と頻度を振り分けています。

2か所で1つの流れを作る

AIニュースの2本は、セットで動いています。月曜の朝8:30に、ローカルのタスクが先週分のニュースをarchive/フォルダへ移します。その30分ほどあとに、クラウドの定期タスクが新しいニュースを書き込みます。日曜は収集を止めているので、月曜の回は土日の2日分をまとめたものです。

集める役はクラウド、片付ける役はローカル。どちらか片方だけでは、この流れは閉じません。置き場所を分けたことで、それぞれが得意なことだけを担当する形になりました。

併用して気づいた落とし穴

ローカルとクラウドを併用すると、片方だけのときにはなかったズレが出てきます。どれも、仕様を読めば書いてあることです。それでも、実際に引っかかるまでは自分ごととして気づけませんでした。

クラウドから見えないファイルがある

クラウドの定期タスクは、GitHubのリポジトリを毎回クローンして動きます。つまり、Gitで管理していないファイルはクラウドには存在しません。私のVaultでいうと、次のようなものです。

• .gitignoreで除外しているフォルダ（Obsidianの設定フォルダ.obsidian/、スクリプト置き場、私用のメモなど）

公式ドキュメントでは確認できていませんが、次のような設定も、クラウドでは使えない可能性があります。

• 手元だけで設定しているHooksやMCPサーバー
• リポジトリの外にある~/.claude/の設定

実際に困ったことは2回あります。1回目は、Wikiへの取り込みがWebクリップのフォルダを読めず、2週続けて「対象0件」で終わった件です。これは姉妹記事で詳しく書きました。

2回目は、週次メンテナンスのリンク切れチェックでした。除外しているフォルダにあるノートへのリンクを、クラウド側が「リンク先が無い」と判断して、リンク切れとして報告してきたんです。手元では、ノートはちゃんとそこにありました。

対策として、定期タスクを作るときは「読むフォルダと書くフォルダがGitの管理対象か」を最初に確かめています。必要なものだけ、.gitignoreに例外を足しました。たとえばWikiの取り込みが新しいページを作るときに使うテンプレートは、テンプレートのフォルダの中でその1枚だけを管理対象にしています。逆に、見えないと分かっているリンクは、リンク切れとして扱わないよう定期タスクの指示に書き足しました。

クラウドの成果物はGitHubにしかない

クラウドの定期タスクが作ったノートは、まずGitHubに届きます。手元のVaultに出てくるのは、pullしてからです。

私も、ある日のニュースのノートが手元に無いまま、しばらく気づかなかったことがありました。定期タスクは成功していて、GitHubにはちゃんと入っていたのに、です。今はObsidian Gitプラグインで、Obsidianの起動時と一定の間隔で自動的にpullするよう設定しています。最初のうちはこの仕様に気づかずに、同じような運用をしている人もいるかもしれません。一度確認してみると良いですよ。

逆向きも同じで、手元での変更はpushするまでクラウドには届きません。クラウドが読むファイルを手元で直したら、pushまでがひと続きの作業です。

時刻はUTCで考える

先ほど触れたとおり、クラウドのcron式はUTCで解釈されます。日本時間の朝9時に動かしたいなら、0 0 * * *と書くことになります。式の先頭にCRON_TZ=Asia/Tokyoを付ければ、日本時間のまま書くこともできます。

時計のずれは、定期タスクの中にも潜んでいました。クラウドの実行環境は、時計の設定がUTCです。ログに日本時間として記録された日時が、実はUTCのままだったことがあります。今はプロンプトで、日本時間で日付を取るよう指定しています。

定期タスク本体はVaultの外にある

クラウドの定期タスクの設定やプロンプトは、claude.ai側で管理されています。Vaultの中をいくら探しても、どの定期タスクが、何を、どんな指示で動かしているかは出てきません。

そこで、定期タスクの一覧メモをVaultに置くことにしました。スケジュール・対象のフォルダ・プロンプトの全文・変更履歴を書き写し、定期タスクを変えたら一覧も手で直します。自動では同期されないので、正直なところ手間はかかります。それでも、後から「なぜこうなっているのか」をたどれるのは、このメモだけです。

人が後から読める記録を残す

定期タスクは、私が見ていないところで動きます。だからこそ、何をしたか、何を決めたかを人が読める形で残すようにしました。AIが読むための記憶とは別の、私が読むための記録です。

実行ログは毎回、最新を一番上に

どの定期タスクも、実行するたびにログを1件書きます。問題があってもなくても、です。何も書かれていない週があれば、それ自体が「動いていない」というサインになります。

ログは、最新の記録が一番上に来る形にそろえました。開いた瞬間に、直近の結果が目に入るからです。

報告は「何かあったときだけ」

一方で、チャットへの報告は、問題がなければ何も言わずに終わる設定にしています。毎週「異常なし」が届くと、だんだん読まなくなるからです。

新しいチェック項目を足したときだけは、数週間、毎回1行で報告させます。期待どおりに動いているのを確かめてから、報告を止める順番です。動いた痕跡から正常を確かめる考え方は、姉妹記事で紹介しています。

決めたことと見送ったことを、理由と一緒に

定期タスクを作ったり変えたりするときは、決めたことだけでなく、見送ったことも残しています。たとえば、AIニュースの収集に使うモデルを上位のものに替える案は見送りました。品質は今のままで足りていて、残っている弱点はネットワークの制限が原因だったからです。

こうした判断を、日付つきの決定ログと日次ログに書いておきます。後から「なんでこうしたんだっけ？」となったときに、理由ごと思い出せるのが利点です。同じ相談を何度も繰り返さずに済むのは、地味ですが効いています。

まとめ

Claude Codeの定期実行は、方式の比較表だけでは置き場所を決めきれません。私が落ち着いたのは、作業の性質で振り分けるやり方でした。

• ローカルのファイルやアプリが必要な作業はローカル、リポジトリの中で完結する作業と時刻を守りたい作業はクラウドに置く
• クラウドは毎回クローンで動くので、Gitで管理していないものは見えない
• 成果物の受け渡し（pullとpush）と、UTCの時刻を確かめておく
• 何をしたか・何を決めたかを、人が読める形で残す

まずは今の定期タスクを1本選んで、「ローカルのファイルが要るか」「時刻がずれたら困るか」を考えてみてください。その2つに答えが出れば、置き場所はほとんど決まります。