Cowork スケジュールタスク運用の実際 — 朝のダイジェストと週次レポートを無人で回すまで

cron 式の書き方 — 最初につまずく場所

定期実行のスケジュールは cron 式で指定します。5つのフィールドで構成され、左から「分 時 日 月 曜日」を表します。

┌───── 分 (0-59)
│ ┌───── 時 (0-23)
│ │ ┌───── 日 (1-31)
│ │ │ ┌───── 月 (1-12)
│ │ │ │ ┌───── 曜日 (0-7, 0と7は日曜)
│ │ │ │ │
* * * * *

よく使うパターンを挙げます。

0 9 * * *      # 毎日9時
0 9 * * 1-5    # 平日（月〜金）の9時
30 8 * * 1     # 毎週月曜8時30分
0 0 1 * *      # 毎月1日の0時
0 */3 * * *    # 3時間ごと

つまずきやすい点が2つあります。

ひとつは曜日の指定です。0と7がどちらも日曜を表すため、「土日に動かす」つもりで 6-7 と書くと環境によって解釈が揺れます。0,6 のように列挙する方が安全です。

もうひとつはタイムゾーンです。Cowork の cron 式は ローカルタイムゾーン で評価されます。日本時間の9時に動かしたければ 0 9 * * * と書くだけでよく、UTC への変換は不要です。サーバー系の cron に慣れている方ほど、ここで一度立ち止まってしまうようです。

ユースケース1: 朝の情報収集ダイジェスト

毎朝9時に関心トピックの最新情報を収集し、要約ファイルを作るタスクです。タスク名は morning-tech-digest としました。

プロンプトの全文を載せます。

以下のトピックについて、過去24時間の最新情報を Web 検索で収集してください。

トピック:
- Claude / Anthropic の最新アップデート
- AI エージェントの新しいツールやフレームワーク
- Apple / Google の開発者向け最新ニュース

収集した情報を、以下の形式でマークダウンファイルにまとめてください。

ファイル名: tech-digest-{今日の日付}.md
保存場所: ワークスペースフォルダ直下の digest フォルダ

形式:
# テックダイジェスト {今日の日付}

## 主要ニュース
（各ニュースを2〜3文で要約。最大5件）

## 注目ポイント
（全体を通して特に重要だと思う動向を1段落で）

検索結果が十分に得られなかった場合は、その旨をファイル冒頭に
1行で記載した上で、得られた範囲でまとめてください。
ユーザーへの確認や質問は行わず、最後まで自律的に完了してください。

cron 式は 0 9 * * * です。

このプロンプトには、後述する設計の型をすべて入れてあります。ファイル名・保存場所・フォーマット・件数上限・失敗時の振る舞い・自律実行の指示。対話なら省略できるものを、あえて全部書く。それが無人実行の作法です。

無人実行に耐えるプロンプト設計の型

スケジュールタスクのプロンプトと対話のプロンプトは、似ているようで別物です。スケジュールタスクは毎回まっさらなセッションで起動し、前回の文脈を引き継ぎません。そして実行中、あなたはそこにいません。

運用の中で固まってきた設計の型が4つあります。

1. 出力契約を結ぶ。 何を・どこに・どの形式で出すかを、ファイル名のパターンまで含めて固定します。「レポートを作って」ではなく「weekly-report-{日付}.md を reports フォルダに、この見出し構成で」。出力先が毎回揺れると、後段の確認も自動化できなくなります。

2. 定量的に指定する。 「最近のニュース」ではなく「過去24時間」。「いくつか」ではなく「最大5件」。曖昧語は対話なら聞き返してもらえますが、無人実行では Claude の解釈に委ねられ、日によって出力がぶれる原因になります。

3. 失敗時の振る舞いを書く。 検索が空振りした、対象ファイルが見つからなかった。そういう日も必ず来ます。「見つからない場合はその旨をファイルに記載してください」と一行書いておくだけで、タスクが沈黙する代わりに「今日は収穫なし」という記録が残り、動作確認にもなります。

4. 冪等性を意識する。 同じタスクが二度動いても壊れない設計にしておきます。ファイル名に日付を含めれば上書きで済みますし、「既に同名ファイルがあれば追記ではなく置き換え」と明示すれば重複も防げます。スリープ明けの追い実行（後述）があるため、これは保険ではなく前提です。

この4点を入れてからは、タスクの挙動が目に見えて安定しました。逆に言えば、不安定なタスクのプロンプトを見直すと、たいていこのどれかが抜けています。

ユースケース2: 週次レポートの自動生成

毎週金曜17時に、その週のワークスペースの変更をまとめるタスクです。

ワークスペースフォルダ内のファイルを確認し、
過去7日間に作成または更新されたファイルの一覧を取得してください。

以下の形式で週次レポートを .md ファイルとして作成してください。

ファイル名: weekly-report-{今週の金曜日の日付}.md
保存場所: reports フォルダ（なければ作成）

# 週次レポート（{月曜日} 〜 {金曜日}）

## 今週の成果物
- 新規作成: {ファイル一覧}
- 更新: {ファイル一覧}

## 作業サマリー
（ファイルの内容から推測できる今週の主な作業内容を3〜5文で）

## 来週に向けて
（未完了と思われる作業や、次のステップの提案を箇条書きで）

対象期間にファイルの変動がない場合は「今週は変更なし」と
記載したレポートを作成してください。

cron 式は 0 17 * * 5 です。

このタスクで面白いのは「作業サマリー」の部分です。ファイルの差分一覧だけなら shell スクリプトでも作れますが、内容を読んで「今週は何をしていた週か」を文章にしてくれるのは Claude ならではです。金曜の夕方にこのレポートを眺めて週を締める習慣は、想像していた以上に心地よいものでした。

ユースケース3: ワンタイムリマインダー

会話の中で「明日の14時にリマインドして」と頼むだけで、Claude がワンタイムタスクを作成してくれます。明示的に作る場合のプロンプトは簡潔で構いません。

以下の内容をユーザーにリマインドしてください。

リマインド内容: 15時からのデザインレビュー会議の準備。
Figma のプロトタイプを最終確認すること。

リマインド内容を .md ファイルとしてワークスペースに保存してください。

リマインダーで覚えておきたいのは、ワンタイムタスクには定期実行のようなランダム遅延が入らないことです。時刻に忠実に動いてほしい用途には、定期実行よりワンタイムの方が向いています。

MCP コネクターと組み合わせる

スケジュールタスクの出力先はファイルに限りません。MCP コネクターが接続済みであれば、タスクのプロンプトに一行書くだけで外部サービスへ届けられます。

Slack コネクターがあれば、朝のダイジェストの末尾に「まとめを Slack の #general チャンネルに投稿してください」と足すだけで、チームへの共有まで完結します。Google Drive コネクターなら、週次レポートをスプレッドシートに追記する運用も可能です。

ここで一つだけ注意点があります。外部サービスへの書き込みを含むタスクこそ、後述の「空打ち」を必ず挟んでください。ファイルへの出力なら失敗しても消せば済みますが、Slack への誤投稿は取り消しがききません。空打ちを一度挟むだけで、この種の事故の大半は回避できます。私は外部送信を含むタスクは、まず「送信せず、送信予定の内容をファイルに保存する」版で1週間動かしてから本番に切り替えるようにしております。

複数タスクの時間帯設計

タスクが2つ3つと増えてくると、「いつ動かすか」自体が設計対象になります。

経験上いちばん効いたのは、実行時刻を重ねないことでした。同じ時間帯に複数のタスクを置くと処理が重なり、互いに足を引っ張り合います。30〜45分ずつ間隔を空けて並べるだけで、取りこぼしが目に見えて減りました。

自分が Mac を使っていない時間帯に寄せるのも有効です。タスクはアプリが起動している間に動くため、作業中のマシンリソースと競合させない配置が快適さに直結します。個人開発のビルドやテストと重ねたくないこともあり、私の場合は早朝と昼休みの前後に散らしております。

タスクの並びは、ひとつの「日課表」として眺めると整理しやすくなります。朝9時にダイジェスト、9時45分にフォルダ整理、金曜17時に週次レポート。表にして時間軸で見ると、過密な帯と空白の帯が一目で分かります。

運用の実際 — enabled・通知・スリープの挙動

一時停止と再開。 定期実行タスクは enabled フラグで止められます。休暇中に朝のダイジェストを止める、プロジェクトの区切りで週次レポートを止める、といった操作が削除なしでできます。止める勇気も運用のうちです。

通知の制御。 タスク完了時に現在のセッションへ通知するかどうかは notifyOnCompletion で制御できます。バックグラウンドで静かに動いてほしいタスクは通知を切っておくと、作業の集中が途切れません。

実行タイミングの揺れ。 定期実行タスクには、負荷分散のため数分のランダム遅延が入ります。「9時0分0秒ちょうど」には動かないので、秒単位の正確性が要る用途には向きません。

スリープ中の挙動。 Mac のスリープ中やアプリ終了中、タスクは実行されません。次回起動時にスキップ分が追い実行される場合があります。前述の冪等性の話はここに効いてきます。追い実行で二重に動いても壊れないプロンプトにしておけば、この挙動はむしろ「取りこぼしを拾ってくれる」味方になります。

空打ちとログ — 静かに壊れることへの備え

無人実行の怖さは、失敗が静かに積み重なることにあります。誰も見ていない時間に、わずかな指示の取り違えが毎日繰り返される。気づいたときには1週間分のダイジェストが空っぽだった、ということも起こり得ます。

私の対策は2つだけです。

最初の1回は必ず手動で動かす。 新しいタスクを定期化する前に一度だけ手で実行し、出力を一行ずつ確かめます。この「空打ち」で、プロンプトの曖昧さの大半は洗い出せます。

実行の痕跡を残す。 タスク自身に「実行日時と処理概要を log.md に1行追記してください」と指示しておくと、後からいつ何が動いたかを一目で追えます。失敗時の記録（前述の「収穫なし」記載）と合わせて、沈黙と正常を区別できるようにしておくのが肝心です。

タスクが動かないときのチェックリスト

実行されないときは、上から順に確認していくと早く原因に当たります。

1. Cowork デスクトップアプリは起動しているか。タスクはアプリ起動中のみ動作します
2. Mac がスリープしていなかったか
3. タスクの enabled が true になっているか
4. cron 式の曜日指定が意図通りか。0と7がどちらも日曜である点に注意
5. プロンプトが長すぎ・複雑すぎないか

最後の点は見落とされがちです。1つのタスクに複数の目標を詰め込むと、途中で止まったり一部だけ実行されたりしやすくなります。「1タスク1目的」を守り、複雑な処理はタスクを分割することを推奨します。ダイジェスト生成と Slack 投稿を分けるだけで安定した、という例も経験しました。

まずは月曜の朝に1本だけ

スケジュールタスクは、Cowork を「話しかけたら動くツール」から「頼んでおけば動いている仕組み」へ変えてくれる機能です。

最初の1本には、失敗しても痛くない小さなタスクをおすすめします。月曜の朝に先週のファイル一覧をまとめるだけでも、「自分がいない間に仕事が進んでいる」感覚は十分に味わえます。その感覚を確かめてから、出力契約と空打ちを携えて、少しずつ任せる範囲を広げていってください。

同じ反復作業に時間を取られている方の参考になれば幸いです。