Claude Coworkのスケジュール機能で、Slackチャネルのデイリーレキャップを自動生成してみた

Claude Coworkのスケジュール機能で、Slackチャネルのデイリーレキャップを自動生成してみた

Claude Coworkのスケジュール機能を使って、Slackチャネルのデイリーレキャップを自動生成する仕組みを構築しました。複数チャネルの横断監視、古いスレッドへの返信検知、トピック自動マージなどの工夫を、コードを書かず対話だけで実現した過程を紹介します。
2026.03.26

はじめに

プロジェクトのSlackチャネルでは、毎日さまざまな議論がスレッド内で進行しています。しかし、複数のスレッドに分散した情報を追いかけるのは大変で、特に「古いスレッドに昨日新しい返信があった」ケースは見落としがちです。

そこで、Claude Coworkのスケジュール機能(cron)を使い、毎朝自動でSlackチャネルのデイリーレキャップを生成・投稿する仕組みを作ってみました。対話しながら要件を詰めていくだけで、コードを一行も書かずに実現できた点が面白かったので、そのプロセスと工夫点を紹介します。

作ったもの

平日の毎朝9時に、前日のSlackチャネルのアクティビティを自動で要約し、以下のような形式でチャネルに投稿するbotです。

image-redacted_dot_app

特徴は以下の通りです。

  • 社内チャネルとクライアントチャネル(Slack Connect)の2チャネルを横断監視し、同一トピックは自動でマージ
  • 古いスレッドへの新規返信も漏れなくキャッチ
  • トピックごとにチャネルソース(社内ch / クライアントch / 両方)をタグ表示
  • 出力先は社内チャネルのみ(クライアントチャネルには投稿しない)
  • レキャップの内容はすべて日本語

前提・環境

  • Claude Desktop(Cowork機能が利用可能な状態)
  • Slack連携(Claude DesktopのSlack MCP connector)が有効化済み
  • 監視対象のSlackチャネルにアクセス権があること

セットアップの流れ

1. Slack連携の確認

Claude CoworkにはSlack MCPコネクタが用意されており、チャネルの読み取り・メッセージ送信・検索などが可能です。今回は以下のツールを使用しています。

ツール 用途
slack_search_channels チャネルIDの特定
slack_search_public_and_private 前日のメッセージ検索(スレッド返信含む)
slack_read_channel チャネルタイムラインの読み取り
slack_read_thread スレッドの全文読み取り
slack_send_message レキャップの投稿

SCR-20260326-lttm

2. Claudeとの対話でタスクを設計

Claude Coworkのスケジュール機能は、自然言語で「何をやりたいか」を伝えるだけでcronタスクを作成できます。今回は以下のようなやりとりで要件を詰めていきました。

まず、やりたいことを伝えます。

「昨日のスレッドを読んで、チャネルのレキャップを作るcronを追加したい。サマリーとアクションアイテムを含めて、日本語で出力してほしい」

Claudeから実行時刻・投稿先・スレッドの扱いについて質問が返ってきたので、以下のように回答しました。

  • 実行時刻: 平日9時(JST)
  • 投稿先: 要約元と同じチャネル
  • スレッド: すべてのスレッド返信を読む

これだけで、最初のバージョンのcronタスクが作成されました。

3. ドライランで問題を発見・修正

最初のバージョンを実行したところ、古いスレッドへの新規返信が拾えていない問題が見つかりました。

原因は2つありました。

問題1: プライベートチャネルの検索に slack_search_public を使用していた

対象のチャネルはプライベートチャネルだったため、slack_search_public では結果が0件でした。slack_search_public_and_private に変更することで解決しました。

問題2: チャネルタイムラインだけでは古いスレッドの返信をキャッチできない

slack_read_channel はチャネルのトップレベルメッセージのタイムラインを返すため、過去のスレッドに昨日投稿された返信は含まれません。

これを解決するため、2つのアプローチを組み合わせる方式を採用しました。

アプローチ 手法 キャッチできるもの
A: チャネルタイムライン slack_read_channel 昨日の新規トップレベルメッセージ
B: 全文検索 slack_search_public_and_private 昨日のすべてのメッセージ(古いスレッドへの返信を含む)

アプローチBで見つかったスレッド返信に対しては、slack_read_thread で親メッセージを取得し、文脈を把握した上で要約に含めます。

実際にこの修正でどれくらい差が出たかというと、あるテスト日では:

  • アプローチAのみ: 1件(トップレベルメッセージ)
  • アプローチA+B: 49件(スレッド返信を含む)

という大きな差がありました。

4. クライアントチャネルの追加

社内チャネルだけでなく、Slack Connectで繋がっているクライアントチャネルも監視対象に追加しました。ポイントは以下の通りです。

  • 同じトピックが両チャネルで議論されている場合はマージして1つのセクションにまとめる
  • 各トピックにチャネルソースを表示(社内ch / クライアントch / 両方
  • 出力は社内チャネルのみに限定(クライアントチャネルには絶対に投稿しない)

これにより、「クライアントが何を承認したか」と「社内で何を議論したか」が一目でわかるレキャップになりました。

5. 出力フォーマットの改善

最初のバージョンでは、要約が1つの長い段落にまとまっており、Slack上で読みにくいものでした。以下の改善を加えました。

  • トピックごとにセクションを分割し、絵文字マーカーで視覚的に区別
  • 区切り線(━━━)で構造を明確化
  • 各トピックは1-2行の概要 + 箇条書きでスキャンしやすく
  • 担当者名は「名字+さん」に統一(チームのSlackでの自然なトーンに合わせる)
  • アクションアイテムは で視覚的フローを表現
📋 *UA案件 デイリーレキャップ(YYYY/MM/DD)*

━━━━━━━━━━━━━━━

📩 *[トピック名]* `クライアントch`([コンテキスト])
[1-2行の概要]
• [要点1]
• [要点2]

🏠 *[トピック名]* `社内ch`([コンテキスト、例: 3/18スレッド継続])
[1-2行の概要]
• [要点1]
• [要点2]

🔗 *[トピック名]* `両方`([コンテキスト])
[If the same topic was discussed in both channels, merge them under one heading]
• [要点1 — from customer channel]
• [要点2 — from internal channel]

━━━━━━━━━━━━━━━

✅ *アクションアイテム*
• *[名字]さん* → [アクション内容]
• *[名字]さん* → [アクション内容]
(該当なしの場合は「特になし」と記載)
---

スケジュールタスクの構成

最終的に作成されたcronタスクの概要です。

項目 設定値
タスクID daily-slack-recap-project-x
スケジュール 0 9 * * 1-5(平日9:00 JST)
監視チャネル 社内チャネル + クライアントチャネル(Slack Connect)
出力先 社内チャネルのみ
言語 日本語

スケジュールタスクはClaude Desktopのサイドバーから確認・管理でき、「Run now」で手動実行もできます。初回実行時にSlack MCPのツール権限が承認されると、以降の自動実行では承認プロンプトが出ません。

工夫した点・ハマったポイント

プライベートチャネル・Slack Connectの扱い

Slack MCPには slack_search_publicslack_search_public_and_private の2つの検索ツールがあります。プライベートチャネルやSlack Connectチャネルを検索する場合は、必ず後者を使う必要があります。最初この違いに気づかず、検索結果が0件になってしまいました。

ページネーションの必要性

活発なチャネルでは、1日のメッセージが検索結果の1ページ(20件)に収まりきらないことがあります。pagination_info にカーソルが返ってくる限り、次のページを取得し続ける必要があります。

活動がない日のスキップ

休日や活動がなかった日にレキャップを投稿しても意味がないため、botメッセージや自動通知を除いた人間のメッセージが0件の場合は、投稿をスキップするようにしています。

まとめ

Claude Coworkのスケジュール機能を使って、Slackチャネルのデイリーレキャップを自動生成する仕組みを作りました。

対話ベースで要件を伝え、ドライランで問題を発見・修正するサイクルを数回繰り返すだけで、コードを一行も書かずに実用的なSlack botが完成しました。特に「古いスレッドへの返信を拾う」問題は、実際にドライランしてみないと気づけなかった点で、対話的な開発プロセスの強みが発揮された場面でした。

今後は、レキャップの精度向上(不要な情報のフィルタリング、アクションアイテムの自動フォローアップなど)や、他のチャネルへの展開を検討しています。

この記事をシェアする

FacebookHatena blogX

関連記事