現在走っているスケジュールタスク構成

まず全体像から。

タスク名	実行タイミング	役割
Slack calendar sync	毎朝8:00	Google Calendar → Slack通知
Slack daily digest	毎朝8:30	前日Slackサマリ生成・投稿
Trend research morning	毎朝9:00	Qiitaトレンド調査＋記事ネタBrief生成
N gen task reminder	毎日9:30	タスク管理チャンネルのリマインド
Schedule push daily	毎日17:00	翌日スケジュール最終確認push
N gen channel watcher	毎日07:00	Slackチャンネルの増減を監視
qiita-daily-post	毎日21:00	Qiita記事生成・投稿

qiita-daily-postは、Trend researchのBriefを読み込んで、その日の活動ログと組み合わせて記事を組み立てる。7本の中で一番複雑なタスクだ。

なぜ7本に増えたか

正直、計画的ではなかった。

最初のSlack calendar syncを入れたとき、「あ、毎日やってる定型作業ってほかにも全部これで代替できるんじゃ?」という気持ちになって、一気に設定した。一気にやったのが失敗の始まりだったけど——それは後で書く。

私が重視したのは「毎日20分以上かかっている繰り返し作業」を洗い出すこと。

洗い出してみると:

朝、Googleカレンダーを開いてSlackに貼る（5分）
昨日のSlackを流し読みしてサマリをメンバーに送る（15分）
Qiitaトレンドをチェックして記事ネタを考える（20分）
タスク管理チャンネルを確認してリマインド（10分）
夕方に翌日の確認push（5分）

合計で1日60〜70分。これを全部スケジュールタスクに移した。

7つのハマりポイント

①セッションIDが溢れる問題

list_sessions で「本日のセッション」を取得しようとすると、過去に実行したスケジュールタスクのセッションが大量に積み上がっていて、デフォルトのlimit:20では当日分が見つからないことがある。

最初のqiita-daily-postでこれに詰まった。「今日やったこと」を拾いにいったら、昨日・一昨日のSlack syncセッションばかりが並んでいて、当日分が見えない。limitを増やすと今度はレスポンスが重い。

私が落とし込んだ解決策は「セッション名でフィルタする」こと。自動タスク由来（Slack syncなど）はノイズとして除外する判断を最初から組み込むべきだった。

結局、スケジュールタスクの名前は最初からユニークかつ判別しやすくつけること。これ地味に重要。

②同じ出力先への書き込み競合

7本が全部 outputs/ に書き込む設計にしていたら、ファイル名の衝突が起きた。

Trend research morningがBriefファイルを書き込んでいる最中に、qiita-daily-postが同じファイルをReadしようとして、中途半端な状態を読んでしまった。

これ、めっちゃ詰まった。「なんでBriefが途中で切れてるんだろう」って30分くらい悩んだ。

解決は単純で、タスクごとにサブディレクトリを切る設計に変えた。outputs/qiita-post/、outputs/trend-research/ みたいに分ける。気づくのに時間がかかった——シンプルなことなのに。

③「ユーザー不在」での判断設計

スケジュールタスクはユーザーが見ていない状態で動く。

通常のCoworkセッションは「迷ったら聞く」ができるけど、スケジュールタスクではClaudeが自律判断しなければいけない。具体的には「守秘判断」で、「これ、業界が特定されそうだな」という判断をClaudeに委ねなければいけない場面がある。

だからSKILL.mdに「判断に迷ったら draft 降格」というルールを明示的に書いている。単純に見えて、実際にはスケジュールタスクのリスク管理の核心だと思っている。

タスクに「曖昧なケースの裁量をどこまで与えるか」を設計段階で決めておかないと、あとで「なんで勝手にこうしたの?」になる。

④タスク間の依存関係の設計ミス

「Trend researchのBriefをqiita-daily-postが読む」という依存関係を作ったのに、Trend researchが9:00実行、qiita-daily-postが21:00実行で時間差がある。Briefが前日のままになるケースが発生した。

1日以内のファイルかどうかを確認するロジックをqiita-daily-postに組み込んで解決したが、タスク間の依存関係は事前にフローチャートで整理すべきだった。いや、ほんとに。

⑤ToolSearchのオーバーヘッドが7本分積む

各タスクが独立してToolSearchでツールロードをやる。Slackのメッセージ送信ツールなど同じものを複数タスクが個別にロードしていて、ちょっともったいない。現状は許容しているが、将来的に共通ツールの事前ロードを仕組み化したいと思っている。

⑥セッション読み取りが自己参照になる

qiita-daily-postが「今日の活動を読む」ためにlist_sessionsを叩くと、自分自身のセッション（まさに今動いているこのセッション）も候補に入ってくる。

最初これに気づかず、「自分のセッションをReadしようとして、実行中でタイムアウト待ちが発生する」という状態になった。自分のセッションIDを除外する処理を入れることで解決。ただ、こういう構造に気づいたとき、「Claudeをツールとして使って動かしている仕組みの面白さ」みたいなものを感じる。

⑦一度に全部設定しすぎた

これが一番の反省。正直しんどかった。

最初の1本を検証せずに7本を一気に設定したので、問題が複数箇所に同時に現れてデバッグが大変だった。スケジュールタスクは「動いているかどうか」の確認が通常の開発より難しいので、段階的な導入が特に重要だと学んだ。1本ずつ動作確認→次に進む、というシンプルな原則を守ればよかった。

コピペで使えるSKILL.md リスク管理セクション

# ⚠️ ユーザー不在時の判断規則

## 判断の優先順位
1. このタスクファイルに明示された規則に従う
2. 規則に記載のないケースは「安全側」を選ぶ
3. 複数の行動が考えられる場合、最もリスクの低いものを選ぶ

## 強制 draft 降格条件（どれか1つでも該当したら publish → draft に変更）
- 守秘対象の固有名詞がマスキングしきれない場合
- 想定字数が最低字数を大幅に下回る場合
- 外部APIが500/429を返し、リトライ上限に達した場合

## write 系操作の制限
- MCP tool で「送信」「投稿」「削除」を伴う操作はタスクファイルで明示的に許可された場合のみ
- 迷ったら report のみ出力して終了する

私の判断：スケジュールタスクは「委任の設計書」

一言でまとめると、スケジュールタスクのSKILL.mdは「Claudeへの委任状」だと思っている。

普通のコードと違うのは、ユーザー不在での自律判断を前提に書かなきゃいけないこと。「こういう場合はこうしろ」「迷ったらこっちを選べ」という判断木を文章で書く設計が求められる。

私はこれが結構好きで、「何をClaudeに判断させて、何は人間が決めるか」を明確にする作業として位置づけている。委任範囲が曖昧だとタスクが暴走するか、逆に何もしなくなる。コードで言えばインターフェース設計に近い感覚。

賛否あると思うが、私は「Claudeに判断を委ねる範囲を広くしていく方向」で運用している。理由は、毎回人間が確認しなければいけないタスクは「自動化」とは呼べないから。ただ、その分SKILL.mdの設計にかけるコストは惜しまない。

まとめ

毎日の繰り返し作業を洗い出してスケジュールタスク化は確実に効く（1日60分以上の削減実績あり）
セッション名・出力先ディレクトリ・タスク間依存関係は設計段階で整理する
「ユーザー不在での判断規則」をSKILL.mdに明示することがリスク管理の核心
1本ずつ検証しながら増やす——一気に7本は無謀だった
ハマりポイントの大半は「複数タスクが同一環境で動く前提」での設計の甘さ

みなさんはClaudeのスケジュールタスク、どんな用途で使っていますか? 「この定型作業を自動化した」「こうするともっとよい」という事例・意見があればぜひコメントで教えてください。

Claude Cowork を社内AXの相棒として毎日使っているエンジニアの実践ログです。

私が日中見ている事業は「N限（Ngen）インターン」── 新卒の実務試験型（ワークサンプル型）インターンを企業に提供しています。AI時代の新卒採用に関心がある方は、下記からどうぞ。

サービス概要（企業向け）: https://ngen-intern.jp/company
使い方ガイド: https://ngen-intern.jp/company/guide
お問い合わせ: https://ngen-intern.jp/contact

シリーズ: Claude Cowork で社内AXを回す