Claude Coworkで何をさせないかを決めたら、タスク管理が楽になった

今日何をやるべきかを考えるのが、昔から苦手です。タスクは溜まっているのに、どれを先にやるべきかを整理する段階でいつも止まってしまいます。優先順位を決めること自体が、自分にとっては小さな負荷でした。

その苦手さを、Claude Coworkの定期実行タスクに任せてみることにしました。今回は、その仕組みと、仕組みを作るときに一番慎重になった部分の話です。

毎朝Slackに届くもの

平日の朝、こんなメッセージがSlackのDMに届きます。

今日のブリーフ(2026-07-03)

今日やるべきこと 上位3件

1. [出典: Linear] 外部パートナーとの共催相談への対応
   — 根拠: 期限5日超過＋外部パートナーからの直接相談＋放置6日
2. [出典: Linear] 記事の進行
   — 根拠: 期限10日超過＋放置11日
3. [出典: Gmail] 登壇イベントの登壇可否の返信
   — 根拠: 依頼主からの直接依頼＋返信期限あり

締切リスク
• 本日期限のタスクが1件
• 1日超過のタスクが1件
• 5日超過・10日超過のタスクがそれぞれ1件

返信待ち(自分がボールを持っているもの)
• なし

要判断
• 出欠未回答の会議が1件

今日の時間制約
• 会議とOOO(不在)の時系列

取得状態
• Linear: OK / Slack: OK / Gmail: OK / カレンダー: OK / Slack送信: OK

Linear、Slack、Gmail、カレンダーの4つを読み取り、その日やるべきことを3件に絞って、締切と依頼主と放置日数の3規則だけで並べ替えてくれます。自分で優先順位を考える手間が、ここでほぼなくなりました。

何を読ませて、どう並べさせているか

裏側の仕組みは、Claude Cowork のScheduled Tasksという、定期実行のタスクをCoworkに登録できる機能です。プロンプトを一度書いて登録すれば、決めた頻度で自動的に走ってくれます。

このプロンプトの設計自体は、Fable5モデルに丸投げして作らせています。それも、過去のセッションを分析させた上で提案させたものです。自分でゼロから書いたわけではなく、これまでの運用の経緯を踏まえてAIに設計させました。

分類の規則は3つだけです。

1. 締切が近い、または過ぎている
2. マネージャーや顧客、外部パートナーからの直接依頼
3. 自分がボールを持ったまま3日以上動いていない

これで同格になった場合は放置日数が長い方を優先し、それでも決まらなければ順位をつけずに「要判断」として並べるだけにしています。規則を増やして精度を上げようとはしていません。シンプルなロジックほどAIの判断ミスが起きにくいと考えていますし、それに加えて、そもそも自分がタスクの優先順位を決めたり判断するのが苦手だという事情もあります。判断を作り込むこと自体が、自分には向いていません。

なぜ「送信」だけは絶対にさせないのか

このプロンプトで一番厳格に書いた部分は、禁止操作です。

• メール・Slack・Linear issueのコメントを含む、一切の送信・投稿・下書き作成
• 自分宛DM以外への送信・投稿・下書き作成
• Linear issueのステータス変更・内容変更・削除
• カレンダーの作成・変更・削除
• Gmailのラベル操作(既読化を含む)

許可されているのは、読み取りと、ブリーフのファイル生成、そして自分宛のSlack DM送信1回だけです。

これだけ厳格にした理由は、勝手なメッセージ送信やチケット変更で慌てたことが何回もあったからです。「AIが他人に対してアクションを仕掛けること」について、非常に慎重なスタンスを取っています。

自分に対して何をされても、自分が怒るかガッカリして終わるだけです。しかし、他人に対して勝手なことをされると、自分に迷惑がかかります。Slackやメールでの誤送信は、対人関係上のダメージが本質です。取り消しても、相手はもう読んでしまっています。一方でLinear issueの変更などは、取り消せないこと自体が問題です。履歴やステータスは、元に戻したつもりでも痕跡が残ります。

one-way door / two-way doorという判断軸

この慎重さを一言でまとめると、AWSでいうtwo-way doorな作業しか、AIに対して自律的な作業を許可するつもりはないということになります。

two-way doorとは、後から引き返せる、やり直せる判断のことです。読み取りは何度でもやり直せます。ファイルの生成も、消してもう一度作らせれば済みます。一方で、メッセージの送信やチケットの変更は、one-way doorです。一度実行されたら、もう元には戻せません。

このプロンプトの禁止操作リストは、one-way doorに該当する操作を機械的に洗い出したもの、と言い換えられます。読み取りとファイル生成という、やり直せる操作だけをAIに渡し、やり直せない操作は自分の手元に残しています。

Linearの記入が、なぜか増えた

想定していなかった副産物があります。この仕組みを入れたことで、Linearにチケットをちゃんと書く習慣がついたことです。もともとチケット管理は苦手で敬遠しがちな作業でした。ところが、Claudeで記事を書いているときや、DMで届いたタスクをClaude経由で参照しながら作業しているときに、追加のタスクが発生すると、「それは別のタスクだから、Linearに関連issueとしてトラックして」とその場で指示するようになりました。自分の手でLinearを開いて登録する横着はそのままですが、それでもチケット化そのものは以前より確実に起きています。

順序としては逆転している気がします。本来は自分でチケットを整理してから、それをAIに読ませる仕組みを作るはずです。しかし実際には、AIに読まれる前提の仕組みを先に作ったことで、書く側の習慣が後から変わりました。

まとめ：苦手なことほど、AIに読まれる前提を作る

優先順位を決めるのが苦手だという弱さは、このプロンプトを作った後も変わっていません。ただ、その苦手さをAIに丸投げするのではなく、規則を単純にした上で「並べて出す」ところまでを任せる、という形に落ち着きました。判断の中身はAIに預けていません。判断の材料を集めて、単純な規則で並べる作業だけを任せています。それが、毎朝Slackに届く3行のブリーフです。

Linearの記入習慣も、同じ構造で動いています。活用されて自分の役に立つとわかると、苦手で敬遠しがちなことでも使うようになります。AIが代行してくれるなら、その分ハードルはさらに下がります。

タスク管理が苦手なままでも、今日何をやるべきかで悩む時間は、確実に減りました。