Claude Codeの定期実行とは？スケジュールタスクとRoutinesの違い・止まったときの備えを解説

毎週の議事録整理や毎月のレポート作成、同じ作業を手で繰り返すのは地味に負担です。じつはClaude Codeには、決まった時間に作業を自動で動かす仕組みが2種類あります。ただし「動いているはず」が一番危険です。PCがスリープしている間に気づかないまま失敗していることがあります。実際、起動したのに何もせず終わっていたり、途中で止まっていたりするケースが確認されています。個人でも法人でも、仕組みの違いと失敗の備え方を知っておけば、安心して繰り返し作業を任せられます。ここでは、デスクトップとクラウドの違い、スリープ中の挙動、実際に起きた失敗例と対策、週次・月次での組み方を解説します。

Claude Codeの定期実行とは？デスクトップのスケジュールタスクとクラウドのRoutinesの違い

Claude Codeで作業を定期実行する方法は、大きく2種類あります。アプリが入ったパソコンの状態に実行が左右される「デスクトップのスケジュールタスク」と、パソコンの電源に関係なく動き続ける「クラウドのスケジュールタスク（旧Routines）」です。どちらも「決まった時間に処理を動かす」という目的は同じですが、仕組みが異なるため、止まり方も対処の仕方も変わってきます。まずはこの2つの違いを、公式ドキュメントに基づいて整理します。

デスクトップのスケジュールタスクとは

デスクトップのスケジュールタスクは、Claude Code Desktopアプリに備わった定期実行の機能です。公式ドキュメントでは、タスクが実行されるのはアプリが起動しており、かつパソコンが起きている間だけだと説明されています。

Tasks only run while the desktop app is running and your computer is awake.

つまり、アプリを閉じていたり、パソコンがスリープしていたりすると、その時間帯の実行は成立しません。一方で、ローカルのファイルやツールに直接アクセスできる点は、デスクトップならではの特徴として整理されています。パソコン内の資料を読み込んで処理したい場合に向いた方式です。

クラウドのスケジュールタスク（旧Routines）とは

クラウドのスケジュールタスクは、以前「Routines」と呼ばれていた機能で、Anthropicが管理するクラウド上で動きます。公式ドキュメントによると、ノートPCを閉じていても動き続けるよう設計されている点が、デスクトップ版との大きな違いです。

so they keep working when your laptop is closed

概要ページでも、クラウドのスケジュールタスクはパソコンの電源が入っていなくても動き続けると説明されており、API呼び出しやGitHub上の出来事をきっかけに起動させることもできます。

ただし注意すべき点が2つあります。1つは、この機能がまだ研究プレビュー段階であることです。

Scheduled tasks are in research preview. Behavior, limits, and the API surface may change.

挙動や制限、呼び出し方法が今後変わる可能性があるため、現時点の仕様を前提に恒久的な運用設計を組みすぎない姿勢が必要です。もう1つは、法人向けのプランでは管理者側でこの機能自体を止められる点です。Team・Enterpriseプランのオーナーは、組織の設定からメンバー全員分のクラウドのスケジュールタスクを無効化できると明記されています。社内で使う前に、管理者が有効化しているかを確認しておく必要があります。

どちらを選ぶべきかの判断軸

2つの方式は、パソコンの使い方と、処理の中身によって向き不向きが分かれます。

パソコンの中にある資料を読み込ませたい作業や、パソコンを開きっぱなしにして使う作業であれば、デスクトップのスケジュールタスクが候補になります。反対に、ノートPCを閉じて持ち運ぶことが多い場合や、クラウド上のデータだけで完結する作業であれば、クラウドのスケジュールタスクのほうが止まりにくいといえます。次のセクションでは、実際にパソコンがスリープした状態で何が起きるのかを、具体的に見ていきます。

PCがスリープ中はどうなる？デスクトップとクラウドで異なる「止まり方」

ここまで見てきたように、2つの方式はパソコンの電源状態への依存度が違います。では、実際にスリープした瞬間には何が起きるのでしょうか。具体的に見ていきます。

デスクトップのスケジュールタスクはスリープ中スキップされ、復帰時に1回だけ追いつく

公式ドキュメントには、パソコンが予定時刻にスリープしていた場合、その回の実行はスキップされると明記されています。

If your computer sleeps through a scheduled time, the run is skipped.

実行が消えるだけでは終わりません。パソコンが起きてアプリが再び動き出すと、過去7日以内で最も新しい未実行分だけ、1回だけキャッチアップ実行されます。

Desktop starts exactly one catch-up run for the most recently missed time and discards anything older.

それより古い未実行分は破棄されるため、数日間パソコンを閉じていても、戻ってくる実行は1回だけです。

• 毎日9時に実行する設定で3日間パソコンを閉じていた場合、復帰時に動くのは1回分の処理のみです
• 残り2日分は実行されず、取りこぼしたままになります

毎日の実行が前提の処理ほど、取りこぼしたまま気づかない状態になりやすい仕組みです。

クラウドのスケジュールタスクはPCの電源に関係なく動く

クラウドのスケジュールタスクには、こうした「スキップ」や「キャッチアップ」という概念自体がありません。前のセクションで見たとおり、公式ドキュメントはクラウドのスケジュールタスクについて、パソコンの電源が入っていなくても動き続けると説明しています。パソコンの状態を確認する工程自体が発生しないため、起動のたびに「動いたか動かなかったか」を気にする必要がありません。パソコンを開く頻度が低い働き方なら、こちらの方式のほうが取りこぼしのリスクを減らせます。

ただし、Anthropicのヘルプサイトには、名称が似た別のデスクトップ製品向けのスケジュール機能についての解説記事もあります。名称だけでは見分けがつきにくいため、本記事で扱っているのはあくまでClaude Codeの公式ドキュメント（code.claude.com/docs）に基づく仕様である点にご注意ください。自社で契約している製品・プランがどちらの機能を指すかは、公式サイトで個別に確認することをおすすめします。

ノートPCで「閉じたら本当に止まるか」を見分けるポイント

デスクトップのスケジュールタスクには、スリープを防ぐための「Keep computer awake」という設定があります。ただし公式ドキュメントでは、この設定をオンにしていても、ノートPCのふたを閉じるとそれでもスリープすると説明されています。外出のためにふたを閉じる習慣がある場合、この設定だけでは定期実行を守り切れません。実行を止めたくない処理は、クラウド側に置くかどうかを検討する材料になります。

名称が近い別製品と混同しやすい点は前述のとおりです。ノートPCを閉じて持ち歩く働き方をしているなら、重要な定期実行ほど、どちらの方式で動いているかを事前に確認しておくことをおすすめします。

次のセクションでは、こうした仕組みの違いが実際にどんな失敗として現れたか、具体的な実例を見ていきます。

定期実行が「動いているのに失敗している」3つの実例

デスクトップのスケジュールタスクはスリープ中にスキップされる仕組みだと説明しました。ただし現場では、この「スキップ」という言葉どおりに静かには終わらない失敗も起きています。ここでは、実際に確認された3つの実例を紹介します。

スリープ中の一瞬の起床で発火し、何もせず失敗していたケース

MacBookは夜間、完全なスリープと一瞬だけ起きるDarkWake（スリープ中の一時起床）を繰り返すことがあります。ある夜、フタを閉じた状態のまま、定時タスクがこのDarkWakeのタイミングで発火しました。

タスクの実行記録には実行済みを示す時刻が残るため、一見すると成功したように見えます。しかし実際には、通信エラーだけを出して何も処理せずに終わっていました。失敗を知らせる通知も届きませんでした。

G

実録GOROの作業記録

DarkWake中の無言失敗

「APIの仕様変更」と誤診して調査が空振りしやすい。実際にはその瞬間だけ繋がらないだけで、日中に手で叩くと正常に動く。

重要：Claude Code の scheduled task には「疎通リトライを入れる」対策が効かない。 ENOTFOUNDはClaude Code自身のAPIサーバ接続で出ており、モデルが起動する前にセッションが死ぬのでSKILL.mdは読まれもしない。

出典：GOROの社内の作業記録

DarkWakeはごく短時間だけ起きる現象です。この一瞬に処理が重なると、実行記録だけが残り、中身は空のまま終わります。

処理の途中でPCが再び眠り、前半だけで止まったケース

週次レポートを作る定時タスクを、データを集めるスクリプトと、その結果を文章にまとめる処理をつなげた多段構成で組んでいた例があります。

ある晩、DarkWake中にこのタスクが起動しました。データを集める処理と、通知の送信までは成功しています。しかしその直後にパソコンが再びスリープし、処理そのものが中断されました。結果、表としてのデータは記録先に残ったものの、それを解説する文章は作られていません。実行状況を確認する画面でも、成功でも失敗でもない「実行中」の表示のまま止まっており、失敗の通知も出ない状態でした。

G

実録GOROの作業記録

多段構成の途中停止

教訓：定時タスクを「スクリプト実行＋そのあとモデルが書く作業」の多段構成にすると、DarkWakeの3分程度の窓に収まらず後半が落ちる。

出典：GOROの社内の作業記録

複数の工程をまとめて1回の定期実行に詰め込むと、途中で電源状態が変わったときに、前半だけ完了した中途半端な状態が残ります。

日付条件が後追いの回で外れ、月次レポートが作られなかったケース

月に一度のレポート作成を、「月末に近い数日間に毎日起動し、その日が月末の最終日であれば処理を実行する」という条件で組んでいた例もあります。

ある月の月末、夜の回には起動した記録そのものが残っていません。パソコンが開いたあとに動いた数日後の回では、タスクが日付を確認し、「今日は月末ではない」と判断してそのままスキップしました。その結果、その月のレポートは作られず、誰も気づかないまま時間が過ぎています。異常が発覚したのは、翌月のレポートに前月分の記録が見当たらないと表示されてからでした。

G

実録GOROの作業記録

日付条件の恒久ミス

教訓：日付条件で実行可否を決める定時タスクは、「対象期間の成果物がまだ無ければ作る」という冪等な判定にする。

出典：GOROの社内の作業記録

日付をもとに実行の可否を判断する設計は、起動のタイミングが1回ずれただけで、恒久的な取りこぼしにつながります。

「止まったことに気づけない」を防ぐには？通知が来ても安心できない理由

ここまでの3つの実例は、どれも実行記録や通知だけでは失敗を見抜けませんでした。さらに、通知が届いているのに中身が空だったケースもあります。

ログが書けないのに通知だけ届いたケース

定期実行の仕組みの中には、処理の記録をログファイルに書き出すものがあります。あるジョブでは、このログファイルをシステム側が開けなくなる現象が起きました。原因はファイルに付いた許可情報で、OSが書き込みを拒否する状態になっていたためです。

ジョブ自体は処理を最後まで終えており、Slack通知も普段どおり届きました。ところがログファイルの中身だけが空のままで、何が起きたのかを確認する手段がありませんでした。

G

実録GOROの作業記録

ログが残らなかった失敗

「ログが伸びていないのにSlack通知だけ届く」状態になり、失敗の痕跡が一切残らない。

出典：GOROの社内の作業記録

通知が来たという事実だけでは、処理の中身まで保証されません。今回のケースのように、通知は届いても処理の記録そのものが失われていることがあります。

失敗に気づくための点検の考え方

通知を信じ切らずに失敗へ気づくには、確認する対象を通知そのものから結果物へ移す必要があります。結果物とは、その処理が本来作るはずのファイルやレコード、投稿のことです。

結果物を確認する点検は、次の2点を押さえると設計しやすくなります。

1. 対象の期間や日付に結果物がすでに存在するかを調べ、無ければ作る判定にします
2. 定期的に「結果物が最後に更新されたのはいつか」を人が目で確認する時間を決めます

1つめは、処理の内部で組み込む設計です。通知やログに頼らず、結果物そのものの有無を基準にするため、途中で処理が止まっても次の回で取りこぼしを拾い直せます。2つめは、人の側で持つ最終の点検です。通知が来ても、月に一度は実際に結果物を開いて中身を確認する時間を決めておくと、ログが壊れていても気づけます。

通知は「処理が始まった合図」であり、「処理が正しく終わった証拠」ではありません。この前提を持っておくことが、放置してよい部分と人が見るべき部分を分けるための出発点になります。

週次・月次で実際に組んだ定期実行の例

失敗に気づくには、通知ではなく結果物を基準にした点検が必要だと説明しました。ここでは、実際に組まれている週次と月次の定期実行を例に、どんな判定の仕組みにしているかを具体的に見ていきます。

金曜17時に1週間分の議事録を同期するルーティン

1週間分の会議議事録をまとめて同期する定期実行では、起動時刻を金曜17時に設定しています。以前は金曜21時に設定していましたが、前述のとおりクラムシェルスリープ中のDarkWakeで処理が発火し、無言で失敗する事故が起きたため、17時へ前倒ししました。17時は社内の定例会議の開始時刻にあたり、ほかの定例・商談・月末の振り返りはすでに完了している時間帯です。パソコンが開いていて通信できる時間帯を選んだ、意図的な設定になっています。

対象の範囲も、起動のたびに迷わないよう明記されています。

処理の流れは、会議ごとに文字起こしを取得し、議事録のファイルを作成（既存のものは上書きしない）、スクリプトで試し実行してから本実行に進み、担当者宛てにレポートを送る、という順番です。レポートの冒頭には起動時刻のタグを付けています。これは、17時の起動では完了していない全社定例の分を、翌日の別の時間帯に動く二段目の処理が拾うためで、どちらのレポートかを見分けられるようにする工夫です。具体的な議事録の作り方そのものは、Claude Codeで議事録作成を自動化する方法で扱っています。

投稿すべき日だけ動く月次レポートの組み方

月次の社員ブログレポートの投稿でも、判定の仕組みが工夫されています。起動自体は毎月3日から9日までの7日間、毎日同じ時刻に行いますが、実際に投稿するかどうかは、その日が条件に合うかではなく、まだ投稿していないかどうかで決めています。

判定の流れは次のとおりです。

1. 投稿すべき状態かどうかを、専用のスクリプトに確認させます
2. 投稿不要と判定されれば、何も投稿せず、担当者への連絡もせずに終了します
3. 投稿が必要な場合だけ、集計と画像の作成に進みます

集計した画像は、一度ファイルとして開いて崩れがないかを確認してから投稿します。集計の中身は前月の社員ブログの投稿実績で、本文に書く数字は専用のスクリプトが出力した値だけを使い、手作業で数字を書き加えない運用にしています。

この仕組みの利点は、7日間のどの回で投稿が成立しても結果が同じになることです。3日の回でパソコンが開いておらず起動できなくても、4日や5日の回が「まだ投稿していない」と判定して投稿を引き継ぎます。日付そのものを条件にする設計とは違い、どの回が成功するかを気にする必要がありません。

投稿が失敗した場合は、その日のうちに再試行はせず、担当者への連絡だけして処理を終えます。取りこぼしは、翌日の起動がまだ投稿していない状態を見つけて拾い直します。

週次・月次のどちらの例にも共通しているのは、成功か失敗かを時刻や日付ではなく、結果物の状態で判定している点です。次のセクションでは、こうした定期実行を法人で使う際に、個人で使う場合とは別に気をつけておきたい点を整理します。

法人で使うときの注意点

週次・月次の定期実行は、結果物の状態で成否を判定する設計が有効だとわかりました。ただし、法人の組織でこの仕組みを使う場合は、個人の工夫だけでは解決しない前提条件を確認しておく必要があります。クラウドのスケジュールタスク（旧Routines）には、利用を検討する前に把握しておくべき2つの制約があります。

研究プレビュー段階であることを理解する

クラウドのスケジュールタスクが研究プレビュー段階の機能であることは前述のとおりです。法人で業務フローに組み込む場合、この位置づけは意思決定に関わる情報です。現時点で動いている処理が、仕様変更によって突然動かなくなる可能性を前提にしておく必要があります。社内の重要な業務を丸ごとこの仕組みに任せきりにするのではなく、変更があった際に気づける体制を同時に用意しておくことをおすすめします。具体的には、以下のような備えが考えられます。

• 定期実行の結果物を確認する担当者を決めておきます
• 仕様変更の告知がないか、公式ドキュメントを定期的に確認します
• 重要な業務ほど、結果物の有無で成否を判定する設計にしておきます

最新の仕様は変わる可能性があるため、導入を検討する段階では必ず公式サイトで現状を確認してください。

Team/Enterpriseの管理者が機能自体を無効化できる

もう1つの制約は、組織での利用権限に関するものです。Team・Enterpriseプランのオーナーが組織の設定からクラウドのスケジュールタスクを全メンバーに対して無効化できる点は前述のとおりです。これは、個人のアカウントでは起こらない制約です。担当者が個人の判断でクラウドのスケジュールタスクを使い始めても、組織の管理者側の設定次第では、ある日突然その機能が使えなくなる可能性があります。社内で定期実行の仕組みを広めようとする立場であれば、現場の担当者だけで判断せず、次の点を事前に確認しておくと後戻りが減ります。

管理者の設定変更は、現場からは見えにくいところで行われます。定期実行を複数の部署や担当者で使い始める前に、組織としてこの機能をどう扱うかを決めておくことが、後になって処理が止まる事態を防ぐ備えになります。許可の出し方や設定ファイルの管理については、Claude Codeの設定の基本で扱っています。

定期実行は、仕組みを理解して設計すれば、繰り返しの作業を任せられる手段になります。一方で、研究プレビュー段階という位置づけや、組織側の管理権限といった、個人の工夫だけでは越えられない条件も存在します。自社の業務にどこまで任せてよいかを見極める際は、こうした前提を踏まえて判断することが欠かせません。

この記事と合わせて読みたい

• Claude Codeで議事録作成を自動化する方法とは？非エンジニア向けに仕組みを解説 — 週次で議事録を自動同期する仕組みをもっと詳しく知りたい読者が、具体的な設定方法を学べるため
• GA4 MCPとは？Claude CodeでGA4・Search Consoleのレポートを自動化する方法を解説 — 月次・週次のレポート自動化を自社のGA4レポートで試したい読者が、具体的な作り方を確認できるため
• Claude Codeの設定とは？許可の出し方と設定ファイルの置き場所を解説 — 定期実行を人の確認なしで動かすための許可設定をどう出すか、次に知りたくなるため

---

Claude Codeを業務で使いたい方へ

自分の業務を題材に試したい方には、1対1で進めるClaude Code マンツーマン講座があります（オンライン・回数制）。部署やチームで導入する場合は、業務に合わせて内容を設計するClaude Code法人研修をご覧ください。