今設定しているタスクが、クラウドとローカルのどちらで実行されているのか、どうすれば分かりますか？
最も直接的な判断材料は、設定時に作業フォルダを指定したかどうかだ。設定の過程で Slack や Gmail といったコネクタだけを選び、パソコン上のフォルダパスを一切指定していない場合、そのタスクはリモート実行に分類され、パソコンの起動状態とは無関係になる。設定の中で「このタスクをどのフォルダで作業させるか」を選んだ瞬間、それはローカルタスクとして紐づけられたことを意味し、パソコンが起動していなければ定刻通りには実行されない。
判断に迷う場合、最も確実な方法は Scheduled タブでそのタスクの過去の実行履歴を直接確認することだ。パソコンが起動していなかった時間帯でも過去に予定通り完了していれば、それはクラウドタスクが正常に動作している証拠だ。実行時刻が常に予定時刻より遅れており、明らかにパソコンを起動した後に補完実行されているようであれば、それはローカルタスクだと分かる。
クラウドのデータとローカルファイルの両方を扱うタスクが必要な場合、このハイブリッドな要件はどう設計すればよいですか？
現在のアーキテクチャでは、あるスケジュールタスクがローカルフォルダを必要すると判定された時点で、そのタスク全体がローカル実行のルールに入り、パソコンの起動状態が影響するようになる。「一部はクラウドで実行し、一部はローカルで実行する」というハイブリッドモードは存在しない。もし要件が本当に両方にまたがる場合——例えばクラウドドライブのデータを集約し、その結果をパソコン内のローカルフォルダに書き込みたい場合——現実的なやり方は2つのタスクに分けることだ。1つは集約とコンテンツ生成を担う純粋なクラウドタスクで、出力は Claude アカウントからアクセスできる場所に保存する。もう1つは、そのクラウドタスクの出力を取得してローカルフォルダに書き込むローカルタスクで、これをパソコンが確実に起動している時間帯にスケジュールする。
この分割は設定の手間が少し増えるものの、その代わりにクラウド部分はパソコンの起動状態から完全に切り離され、本当にローカル環境が必要なステップだけを、それが不可欠な部分に限定して最小化できる。
クラウドのスケジュールタスクは、特定のフォルダが見つからないことで実行に失敗することはありますか？
ない。クラウドタスクはそもそもパソコン上のフォルダを読み取らないように設計されているからだ——到達できるリソースの範囲は、すでに設定済みのコネクタ（Slack のメッセージ、Google Drive 内のファイルなど）と、Claude アカウントに保存されたファイルに限られる。つまりクラウドタスクは実行時にローカルフォルダへのアクセスを一切試みないため、「フォルダが見つからずに失敗する」という事態はそもそも起こり得ない。これが、公式ドキュメントが「リモートのスケジュールタスクをパソコン上のフォルダに紐づけることはできない」と明記している背景にある実際の意味だ。
もしクラウドタスクにパソコン内の特定フォルダを処理させることを期待していたなら、設定画面がそもそもこの種のタスクをローカルパスに紐づけさせてくれないことに気づくはずだ——これは説明不足の制約ではなく、その経路が設計上そもそも存在しないということだ。ローカルフォルダを必要とする要件は、ローカルタスクを通じて実現する必要がある。
ローカルタスクの「補完実行」の仕組みは、一般的にイメージされる「やるべきことは結局全部やってくれる」というものとどう違いますか？
最大の違いは、補完実行が直近の未実行分1回しか処理せず、間に累積した未実行分をすべて埋め合わせるわけではない点だ。毎日実行されるタスクがパソコンの3日連続の未起動によって3回逃した場合、パソコンが再起動されると、システムは通常この直近の1回分だけを実行し、それより前の2回分の実行は個別には回復されない——これは多くの人が直感的にイメージする「パソコンが起動していなかった日々のデータも結局は生成される、ただ少し遅れて届くだけ」とは異なる挙動であり、実際には「その間の実行記録がそのまま消え、最新の1回分だけが残る」に近い。
日次で独立した記録が必要なタスク（日ごとの財務集計など）にとって、このズレはデータの欠落を生む可能性があり、ローカルタスクを設計する段階であらかじめ考慮しておく価値がある——例えばタスクの内容を「過去N日分をまとめて集計する」ように設計し、毎日必ず独立した完全な実行記録が残ると想定しないことだ。
Claude Cowork のスケジュールタスクが「パソコンがスリープしていても実行されるのか」という疑問には、ネット上に実は2つの答えが存在する——古いものと現在のものだ。多くの既存記事は古い挙動を説明しており、それを鵜呑みにすると誤解しやすい。Anthropic の現在のヘルプドキュメントは明確に述べている：多くのスケジュールタスクはリモートで実行されるため、パソコンがスリープしていても、Claude デスクトップアプリが閉じていても、予定通りに実行される。パソコンの電源状態が本当に影響するのは、タスクが明確にローカルのフォルダやアプリを必要とする、その一種類のケースだけだ。
デフォルトでは、スケジュールタスクはすでに接続済みのコネクタ（Slack、Google Drive など）と、Claude アカウントに保存されたファイルを使って動作する。この種のタスクは Anthropic のサーバー上で実行され、パソコンの起動状態とは完全に切り離されている——パソコンが一晩中スリープしていても、デスクトップアプリが一度も開かれなくても、タスクは予定時刻に実行され、結果は Scheduled タブに届いて確認を待っている。
しかし、タスクに特定の作業フォルダを設定している場合——パソコン内のフォルダにあるファイルを読み書きするよう Claude に依頼している場合——公式ドキュメントはこの種のタスクがローカルでしか実行できず、実行時にはパソコンが起動しデスクトップアプリが開いて接続されている必要があると明記している。この違いは些細な操作上のディテールではない。タスクの種類そのものが、それがクラウドで動くのかローカルで動くのかを最初から決めており、両者の信頼性はまったく別物だ。
ローカルフォルダに紐づいたタスクが、パソコンのスリープによって予定時刻の実行を逃した場合、そのまま消えてしまうわけではない——次にパソコンが目覚め、デスクトップアプリが再接続されたときに、システムは直近で逃した実行分の補完実行を行い、それより前に逃した分はスキップする。つまり、パソコンが数日間連続で起動しなかった場合、ローカルタスクはその間のすべての日を埋め合わせるわけではなく、通常は最新の未実行分だけが実行され、それより前の実行記録は実質的に失われる。だからこそ、ローカルタスクであっても、スケジュールの時間帯を設定する際は「その時間帯に普段パソコンが起動しているか」を考慮する価値があり、補完実行の仕組みが時間のズレを完全に埋めてくれると期待しないほうがよい。
この違いの根本原因は、タスクが触れる必要のあるリソースがどこにあるかにある。クラウド型のスケジュールタスクはコネクタとアカウントに保存されたファイルに依存しており、これらは Anthropic のサーバーがパソコンを経由せず直接アクセスできるリソースだ。しかし、タスクがローカルのハードディスク上の実際のファイルを読み書きする必要がある場合、サーバーにはそれらのファイルへの直接的な経路がなく、接続され続けているデスクトップアプリを通じてしか実行できない。だからこそ公式ドキュメントは、リモートのスケジュールタスクをパソコン上のフォルダに紐づけることはできないと特に注記している——これは機能の欠落ではなく、クラウドとローカルという2つの実行環境がそもそも異なる到達範囲を持っていることによる境界なのだ。
コネクタ（Slack、Gmail、Google Drive など）だけを使い、作業フォルダを指定せずにスケジュールタスクを設定した場合、それはほぼ確実にクラウドで実行されており、パソコンのスリープ状態は影響しない。設定でローカルの特定フォルダを指定した瞬間、あるいはタスクがローカルでしか動かないアプリを必要とする瞬間、そのタスクはローカル実行に分類され、パソコンが起動しているかどうかが定刻実行を左右する決定的な要素になる。設定が終わったら、Scheduled タブでそのタスクの実行履歴を直接確認できる——過去の実行時刻が、その時点でパソコンが起動していなかった場合でも予定時刻と正確に一致していれば、それはクラウドタスクが意図通りに動作している証拠だ。
スケジュールタスクが Slack メッセージの集約や、クラウドドライブ内の文書からの週次レポート作成など、パソコン上のローカルファイルにまったく触れない内容であれば、それを純粋なクラウドタスクとして設計すれば、パソコンの起動状態を本当に気にしなくてよい自動化が手に入る——これはほとんどの人が初めてスケジュールタスクに触れたときに期待することそのものだ。しかし、タスクが本質的にローカルファイルを扱う必要がある場合（特定のローカルフォルダの整理など）、「なぜ実行されなかったのか」と悩むよりも、この種のタスクは本質的にローカル性質であると受け入れ、パソコンが確実に起動している時間帯にスケジュールを寄せ、「補完実行は直近の1回分しかカバーしない」という制約をあらかじめワークフローに組み込んでおくほうが現実的だ。クラウドタスクと同じ分刻みの正確さを期待するのではなく。