スケジュールされたタスクがコンテキストを持つ場合と持たない場合がある理由
各実行は独自のセッションである
スケジュールされたタスクのページには、はっきりとこう書かれています。「スケジュールされた各タスクは、独自のCoworkセッションとして実行されます。他のタスクと同様に、準備ができたら結果を確認できます。」
この一文だけを読むと、他の一般的な自律型エージェントの設計と同じように思えます。しかし、次の文を読むと印象が変わります。「スケジュールされたタスクはリモートで実行されるため、コンピュータがスリープ状態であったり、Claudeデスクトップアプリが閉じられていたりしても、設定された周期で実行されます。」
リモートで実行される、つまりクラウドで実行されるということです。
クラウドセッションはチャットとメモリを共有する
ここがCoworkの異なる部分です。Coworkのスタートガイドページでは、これを機能として挙げています。「チャットとの共有メモリ: クラウドでのセッションにおいて、Claudeはチャットからすでに記憶している内容から開始し、Coworkタスクで発生した内容はチャットに引き継がれます。」
双方向です。クラウドセッションはClaudeがすでに記憶している内容から開始され、タスク内で発生したことはチャットにフィードバックされます。
したがって、クラウドで実行されるスケジュールされたタスクは、ゼロから開始されるわけではありません。あなたのメモリから開始され、そこに貢献します。これは、空のコンテキストから始まるスケジュールされた実行とは本質的に異なる提案であり、この記事が存在する理由でもあります。
タスクが保存するのはプロンプトであり、学習した内容ではない
「メモリがある」という言葉は2つの意味を持ち得るため、その仕組みを正確に理解しておく価値があります。スケジュールされたタスク自体は指示を保存します。「スケジュールされたタスクを作成すると、Claudeはプロンプトをタスクの指示として保存し、選択した周期で実行します。」
これがタスクの定義です。メモリは、クラウドセッションが読み取る独立したレイヤーです。タスクは、以前の実行の独自の履歴を蓄積するわけではありません。メモリへのアクセス権を持つセッションで、保存されたプロンプトを再実行するだけです。どちらも真実ですが、同じことではありません。この違いこそが、what persistent memory actually is（永続メモリの真の意味）の核心にあります。
一致しない2つの注意書き
ここからが未解決の部分です。一方だけを選ぶのではなく、公開されている両方の文章を読む価値があります。
スケジュールされたタスクのページにはこう書かれています。「注意: スケジュールされたタスクは、組み込みのスケジュールオプションを使用し、コネクタおよびClaudeアカウントに保存されたファイルで動作します。コンピュータ上のフォルダに関連付けることはできません。」
同じページの、手動セットアップ手順には、「Claudeが作業するフォルダ [任意]」がフィールドとしてリストされており、その後にこう続いています。「注意: スケジュールされたタスクがローカルファイルやアプリを必要とする場合、ローカルでのみ実行されます。」
一方、スタートガイドページでは3つ目の構成が説明されています。Coworkは「セッションをクラウドでリモート実行し（ベータ版）」、ローカル機能はセッションをローカルで実行するのではなく、デスクトップアプリを通じてアクセスされます。「これらの機能はコンピュータ上のものにアクセスするため、セッションがクラウドで実行されていてもアプリが必要です。」
現在公開されている3つのページで、フォルダに関連付けられたタスクがどこで実行されるかについて3つの異なる表現がなされています。Anthropicに代わってこれらを調停するつもりはありません。推測で語ることは、そう明言することよりも悪影響を及ぼすからです。ここから読み取るべきことは、スケジュールされたタスクがローカルファイルに触れる場合、そのメモリの挙動について何も仮定してはならないということです。実際に検証してください。
よくある試みと誤解
スケジュールされたタスクは白紙から始まると仮定する。 最も一般的な仮定ですが、Coworkのクラウド実行においては誤りです。これにより、タスクのプロンプトにすべてのコンテキストを詰め込むことになり、プロジェクトの詳細が変更されるたびに手動で編集する羽目になります。
したがって、すべてを知っていると仮定する。 逆の誤りです。クラウドセッションではメモリがチャットと共有されますが、それはそのタスクの過去の実行記録ではありません。実行3が実行2の結論を知る必要がある場合、メモリはそのための伝達経路としては弱く、タスクの出力を使用する方が適しています。
コンテキストを増やすために、スケジュールをローカルフォルダに向ける。 理解できる直感ですが、これはタスクが実行される場所を変更してしまう可能性が最も高いアクションです。これこそが、3つのページで意見が分かれている点です。コンテキストを得るためにローカルファイルへのアクセスを追加すると、依存していたメモリを失う可能性があります。
他のツールのスケジュール実行と比較して一般化する。 ChatGPTのスケジュールされたタスクやWarpのクラウドエージェントは、設計上どちらも新しく開始されるため、Coworkも同じように動作すると仮定したくなります。しかし、クラウド実行においてCoworkはそうではありません。もしあなたのメンタルモデルが、ChatGPT's scheduled tasks starting over every run（毎回最初からやり直すChatGPTのスケジュールタスク）やWarp's cloud agents（Warpのクラウドエージェント）から来ているなら、Cowork専用にアップデートする必要があります。
プロジェクトとメモリを同じものだと仮定する。 Coworkのプロジェクトは「関連するタスクを、独自のファイル、コンテキスト、指示、メモリを持つ個別のワークスペースにグループ化」します。これはワークスペースごとの設定であり、チャットと共有されるアカウントレベルのメモリではありません。両方が存在し、それぞれスコープが異なります。この境界線については、Claude's memory across chat and Coworkで説明しています。
解決策：各タスクがどこで実行されるかを決定し、コンテキストの伝達をプロンプトに依存するのをやめる
ステップ 1: コンピュータが必要かどうかに基づいてスケジュールを分類する
スケジュールされたタスクを確認し、それぞれを次の2つのバケットのいずれかに分類します。
クラウド限定タスク。 Slackやメールからの日次ブリーフィング、連携ツールからの週次レポート、定期的なリサーチ、ステータスの要約など。これらはコネクタやClaudeアカウントに保存されたファイルを使用します。これらは設定された周期でリモート実行され、ドキュメントによればクラウドセッションとして実行されます。つまり、チャットとの共有メモリが適用される場所です。
ローカルマシン上の何かを必要とするタスク。 ローカルフォルダ内のファイル整理、ローカルアプリを読み取る処理など。これらは、フォルダフィールドや「ローカルでのみ実行されます」という注意書きが関係してくるタスクであり、メモリの挙動を仮定すべきではありません。
2つ目のバケットについては、そのタスクが本当にローカルアクセスを必要としているかを自問してください。驚くほど多くの「ファイルの整理」スケジュールが、代わりにClaudeアカウントに保存されたファイルに対して実行可能であり、それによってタスクをすっきりと1つ目のバケットに移行し、曖昧さを排除できます。
ステップ 2: 各バケットの1つのタスクでメモリの挙動を検証する
推測するのではなく、一度テストしてみれば、ご自身の環境での挙動がわかります。
使い捨てのスケジュールされたタスクを作成し、そのプロンプトで、あなたのメモリからしか知り得ない特定の事実（チャットで設定した好みや、そのプロンプトに入力したことのないプロジェクトの詳細など）を述べるようClaudeに求めます。スケジュールオプションでサポートされている手動実行を行い、出力を確認します。
次に、同じタスクのフォルダに関連付けられたバージョンで同じことを繰り返します。もし回答が異なる場合、あなたのアカウントにおける境界線がどこにあるかが判明します。これは、異なる表現をしている3つのページから推測するよりもはるかに信頼性があります。
結果をどこかに書き留めておいてください。これは、Coworkがウェブやモバイルでベータ版から移行するにつれて変化する可能性が非常に高い挙動であるため、永続的な事実ではなく、有効期限のある知見として扱ってください。
ステップ 3: タスクが必要とするものを、実行場所に依存しないレイヤーに配置する
これが構造的な解決策です。上記はすべて、2つの挙動のどちらが得られるかを判断することに関するものでした。しかし、3つ目の選択肢があります。それは、タスクがその回答に依存しないようにすることです。
スケジュールされた実行が必要とする知識が、タスクが明示的に読み取る外部のメモリレイヤーに存在する場合、その実行が共有メモリを持つクラウドセッションであるか、それを持たないローカルセッションであるかは関係なくなります。どちらの場合でも、コンテキストは同じように届きます。検証し続けなければならない疑問を、常に安定した仕組みに置き換えることができます。
これは、プロンプト編集の問題に対する答えでもあります。タスクのプロンプトは保存された文字列です。プロジェクトが変更されるたびに、誰かがスケジュールを開いて編集しなければなりません。「現在のプロジェクトの規約を使用する」と指示し、それをストアから読み取るプロンプトであれば、規約が変更されても編集する必要はありません。MemoryLakeは3つのステップでセットアップできます。
ステップ 1: APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。これは特定のインターフェースに紐づいていません。ここが重要な特性です。クラウド実行とローカル実行が同じストアを読み取るため、クラウドかローカルかという問題によってタスクが知っている内容が左右されなくなります。
ステップ 2: 最初のメモリをアップロードする
スケジュールされたタスクが繰り返し必要とするものを入力します。週次レポートのフォーマット規約、リサーチダイジェストで関連性があるとみなされるもののリスト、ブリーフィングで監視すべきアカウントや用語、そうでなければすべてのタスクプロンプトに貼り付けることになる固定の好みなどです。
これは、実行をまたぐ結論を置く場所でもあります。火曜日の実行が月曜日の決定事項を知る必要がある場合は、共有メモリに期待するのではなく、ストアにそれを書き込みます。
ステップ 3: AIとエージェントを接続する
Coworkをストアに向けます。これにより、監視なしの実行も、インタラクティブなセッションと同じ知識から開始されるようになります。また、一度変更を加えれば、編集し忘れたプロンプトを探すことなく、すべてのスケジュールに反映されます。
実践においてこれがもたらす変化
最初の変化は、スケジュールが壊れやすい文字列ではなくなることです。現在、タスクのプロンプトはそれを書いた時点で真実だったことのスナップショットにすぎません。プロジェクトが変更されると、それに言及しているすべてのスケジュールが静かに陳腐化していきます。
2つ目は、自動化が何を把握しているかを知るために、ベータ版の境界線を追跡し続ける必要がなくなることです。クラウドでのCoworkセッションはウェブとモバイルでベータ版であり、組み込みブラウザは段階的に展開中、Dispatchは一部のプランで限定ベータ版です。これらは急速に進化するプロダクトにおいては正常なことですが、誰かが実際に依存している週次レポートの基盤としては心もとないものです。
3つ目は、実行間の継続性が明確になることです。チャットとの共有メモリは素晴らしい機能ですが、「先週の実行がどのような結論を出したか」を伝える仕組みとしては不十分です。結論をストアに書き込み、次の実行でそれを読み戻す方法こそが、実行がクラウドであるかどうかにかかわらず機能するアプローチです。これは、memory for MCP tasks（MCPタスク用のメモリ）の背後にある考え方と同じです。
Coworkスケジュールタスクのベストプラクティス
- コンピュータが必要かどうかに基づいてスケジュールを分類する。 これが、得られる挙動を変化させる可能性が最も高い唯一の変数です。
- タスクが許す限り、ローカルフォルダよりもClaudeアカウントに保存されたファイルを優先する。 クラウド限定タスクは、最も明確にドキュメント化された挙動を持っています。
- バケットごとに一度メモリの挙動をテストし、発見したことを書き留めておく。 手動実行を利用すれば低コストでテストでき、その知見には有効期限があります。
- タスクのプロンプトは短く、タスク自体に関する内容にとどめる。 フォーマット、周期、出力の形式はプロンプトに含めるべきですが、プロジェクトの知識は含めるべきではありません。
- 共有メモリを実行ログとして使用しない。 実行Nが実行N-1の結論を必要とする場合は、意図的にどこかに書き込んでください。
- プロジェクトは別のスコープであることを忘れない。 プロジェクトのワークスペースには、独自のファイル、コンテキスト、指示、メモリがあります。これはチャットと共有されるアカウントレベルのメモリではありません。
- Coworkの変更後に再確認する。 クラウドセッションはウェブとモバイルでベータ版であり、ベータ版の挙動は変化します。
- スケジュールがアクセスできる範囲を確認する。 スケジュールされたタスクは、連携ツール、スキル、インストールされたプラグインなど、通常のCoworkタスクと同じ機能を持っています。タスクが定期的に無人で実行される場合は、監査する価値があります。
結論
Coworkのスケジュールされたタスクは、業界のデフォルトよりも優れた取引です。クラウドでの実行は、何もない状態から始まるのではなく、Claudeがすでに記憶している内容から開始され、そこにフィードバックされます。これは本当に便利で、知っておく価値があります。
同時に、フォルダに関連付けられたタスクについては、ドキュメントが現在解決していない条件付きの挙動でもあります。そのため、スケジュールを分類し、各バケットで1つずつテストし、実際に依存しているものについては、実行がどのマシンで行われたかによって回答が変わらない場所に知識を配置してください。