Claude Cowork を社内AXに使っている私の実践ログです。社内固有名・個人名は伏せています。
最初は1本だった。
毎朝Slackに翌日の予定を流すだけの、シンプルなやつ。「これ、毎日手でやるの無駄だな」と思って設定した。気づいたら3週間で7本になっていた。
今日は、その7本が何をやっていて、どこで詰まったかを書く。
現在走っているスケジュールタスク構成
まず全体像から。
| タスク名 | 実行タイミング | 役割 |
|---|---|---|
| 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を回す