こんにちは、アプリケーションサービス本部の遠藤です。
複数の顧客案件を並行して進めていると、「あのSlackメッセージに返信しなきゃ」「今日の定例で何を共有するんだっけ」といった情報がGoogle CalendarとSlackに散らばりがちです。
毎朝それらを巡回して頭の中で整理する時間がもったいなかったので、Claude（Coworkモード）を使ってSlack「後で」ブックマークとGoogle Calendarの予定を自動集約するTODOリストを作りました。平日毎朝9時に自動更新され、HTMLでインタラクティブに操作できます。
本記事では、Claudeの活用方法・TODOリストの工夫ポイント・プロンプト設計の3つの観点からこの仕組みを紹介します。
全体アーキテクチャ
┌─────────────────┐ ┌─────────────────┐
│ Google Calendar │ │ Slack「後で」 │
│ (MCP連携) │ │ (MCP連携) │
└────────┬────────┘ └────────┬────────┘
│ │
└───────────┬───────────┘
▼
┌─────────────────────┐
│ Claude スケジュール │ ← 平日 毎朝9:00 自動実行
│ タスク │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ daily-todo-list.html │ ← 案件別・優先度別のTODOリスト
│ todo-state.json │ ← チェック状態の永続化ファイル
└─────────────────────┘
│
▼
ブラウザで操作
チェック → 次回更新で除外
ClaudeのCoworkモードにはSlackやGoogle CalendarとのMCP（Model Context Protocol）連携が組み込まれており、APIキーの設定やOAuth認証のコードを書くことなく、会話の中で「Google Calendarの予定を取得して」「Slackの保存済みメッセージを検索して」と指示するだけでデータを取得できます。
また、UIとしては以下のテンプレートをもとに日々更新されるものとなります。
Claudeの活用方法
1. MCPコネクタによるデータ取得
今回のシステムでは、以下の2つのMCPコネクタを活用しています。
Google Calendar MCP — gcal_list_events を使い、今日から2週間分の予定を取得します。timeZoneに Asia/Tokyo を指定し、定例会議・スプリントイベント・社内行事などを抽出します。
Slack MCP — slack_search_public_and_private に is:saved クエリを投げることで、Slackの「後で」に保存したメッセージを一括取得します。ここには「レビュー依頼」「確認依頼」「期限付きタスク」など、対応が必要なメッセージが含まれています。
ポイントは、普段の業務でSlackの「後で」機能をTODO的に使っている習慣をそのまま活かしている点です。特別な入力を求めないため、仕組みの導入コストがほぼゼロでした。
2. スケジュールタスクによる自動実行
Claudeのスケジュールタスク機能（create_scheduled_task）を使い、cron形式 0 9 * * 1-5（平日毎朝9時）で自動実行されるようにしています。スケジュールタスクにはプロンプト全文を渡すため、毎回のセッションが独立して完結する設計です。
3. 対話的な開発プロセス
このシステムはClaudeとの対話を通じて段階的に作り上げました。
- 「Google CalendarとSlackの情報からTODOリストを作成して」→ 初版のHTML生成
- 「faviconをつけて」→ SVG faviconの追加
- 「チェック状態を保持したい」→ localStorage対応
- 「スケジュール更新時にチェック済みを除外したい」→ File System Access API + JSONステートファイルの仕組みを構築
このように、一度に完成形を作るのではなく会話しながら機能を積み重ねていく開発スタイルがClaude活用のポイントです。フィードバックを伝えるだけで、HTML・CSS・JavaScript・スケジュールタスクのプロンプトまで一貫して修正してくれるため、非エンジニアでも実用的なツールを作ることができます。
TODOリストの工夫ポイント
工夫1: 案件（プロジェクト）別にグルーピング
複数案件を並行している場合、フラットなTODOリストでは「今日どの案件に集中すべきか」が見えにくくなります。そこで、Slackチャンネル名をキーにして案件ごとにセクションを分けています。
顧客A DevOps案件 ← #prj-customer-a-devops 等 顧客B インフラ構築案件 ← #prj-customer-b-infra 顧客C CI/CDパイプライン案件 ← #prj-customer-c-cicd 社内タスク・定例
各セクションには「顧客案件」「社内」のタグも付けており、顧客対応を優先的にこなすべきか一目で判断できます。
工夫2: 3段階の優先度と視覚的なデザイン
各タスクの左端にカラーバーを配置し、優先度を直感的に把握できるようにしています。
| 優先度 | 色 | 判定基準 |
|---|---|---|
| 高 | 赤 | 期限超過、当日対応必須、顧客への即日回答 |
| 中 | 橙 | 今週中に対応、レビュー依頼、ドキュメント作成 |
| 低 | 青 | 定例会議、任意参加イベント、情報共有のみ |
朝の時点で赤いバーが目に入れば、まずそこから着手する、というシンプルな運用が可能です。
工夫3: ソースの明示
各タスクに「Slack: #prj-customer-a-devops」「Slack: DM メモ」といったメタタグを付与し、どこから来た情報かを明記しています。対応時に該当のSlackチャンネルやスレッドにすぐ移動できるため、コンテキストスイッチのコストを下げる効果があります。
工夫4: 完了状態の永続化と次回更新への引き継ぎ
ブラウザ上のチェック状態をlocalStorageで保持するだけでなく、File System Access APIを使って todo-state.json というファイルにエクスポートする仕組みを設けました。
{ "lastSynced": "yyyy-mm-ddThh:mm:xx.xxxZ", "completedTasks": [ "スプリントイベントのカレンダー登録", "作業完了報告書の構成チェック", "納品チェック処理（ツール導入案件）" ] }
ここで重要なのは除外判定のロジックです。チェックしただけでは即座にリストから消えるわけではなく、次回のスケジュール更新時に「チェック済み かつ ソースデータからも消えている（Slackのブックマーク解除済み、カレンダーイベント終了など）」場合にのみ除外されます。まだSlack「後で」に残っているタスクは、チェック済み状態で表示が継続されます。
この二重チェックにより、「うっかりチェックしたけど実はまだ対応が必要」というタスクの見落としを防いでいます。
プロンプト設計のポイント
スケジュールタスクに渡すプロンプトは、毎回独立したセッションで実行されるため完全に自己完結している必要があります。以下は実際に使用しているプロンプトの構成と、設計時に意識した点です。
プロンプト全文（抜粋付き）
毎朝のTODOリスト自動生成タスクです。以下の手順で実行してください。 ## 目的 自分の当日のTODOリストを、 Google CalendarとSlackの「後で」ブックマークから自動生成し、 HTMLファイルとして出力する。 **完了済みタスクは除外する。** ## ファイルパス - HTMLファイル出力先: /Users/user/Documents/Claude/daily-todo/daily-todo-list.html - 完了状態ファイル: /Users/user/Documents/Claude/daily-todo/todo-state.json ## 手順 ### 1. 祝日・休日チェック （省略） ### 2. 完了済みタスクの読み込み - todo-state.json が存在するか確認する。 - 存在する場合、JSONを読み込み completedTasks 配列を取得する。 ### 3. Google Calendar情報の取得 - gcal_list_eventsツールを使い、calendarId="primary"、timeZone="Asia/Tokyo"で 今日から2週間分の予定を取得する。 ### 4. Slack「後で」ブックマーク情報の取得 - slack_search_public_and_privateツールで query="is:saved" を検索する。 ### 5. TODOリストの整理（完了タスク除外ロジック） **除外判定:** 以下の両方を満たすタスクは除外する: 1. completedTasks に含まれている（ユーザーがチェック済み） 2. かつ、以下のいずれかに該当する: - Slack「後で」のソースデータにもう存在しない - カレンダーイベントが過去になっている - 期限が過ぎており、ソースデータに新たな言及がない **保持判定:** 以下のタスクは除外しない（チェック済みでも残す）: - completedTasks に含まれているが、Slack「後で」にまだ存在する → チェック済み状態で表示 - completedTasks に含まれていない新規タスク → 未チェックで表示 （以下、案件カテゴリ分類・優先度定義・HTML出力仕様・クリーンアップ処理が続く）
設計ポイント1: 明確なステップ分割
プロンプトを8つのステップに分割し、番号付きの手順書として記述しています。Claudeは指示が曖昧だと独自に判断してしまうことがあるため、「何を」「どの順番で」「どう判断するか」を明示的に書くことで、毎回の実行結果のブレを最小限に抑えています。
設計ポイント2: 判定ロジックの条件分岐を明文化
特に「完了タスク除外ロジック」では、除外判定と保持判定の2パターンを箇条書きで明確に分けています。
**除外判定:** 以下の両方を満たすタスクは除外する: 1. completedTasks に含まれている 2. かつ、ソースデータにもう存在しない **保持判定:** 以下のタスクは除外しない: - completedTasks に含まれているが、Slack「後で」にまだ存在する
「両方を満たす」「かつ」「いずれかに該当する」といった論理条件を自然言語で正確に記述することで、Claudeが条件判定を誤るリスクを減らしています。
設計ポイント3: 具体的なファイルパスとデータ形式の指定
## ファイルパス - HTMLファイル出力先: /Users/user/Documents/Claude/daily-todo/daily-todo-list.html - 完了状態ファイル: /Users/user/Documents/Claude/daily-todo/todo-state.json
{ "lastSynced": "2026-04-01T18:00:00.000Z", "completedTasks": ["タスク名1", "タスク名2", ...] }
スケジュールタスクは毎回新しいセッションで実行されるため、ファイルパスやJSONの形式を省略すると「どこに保存するか」「どんな形式で読むか」をClaudeが推測してしまいます。入出力の仕様を具体的に記述することが再現性の鍵です。
設計ポイント4: HTML構造の保持を明示的に指示
**重要:** 既存の daily-todo-list.html のHTML構造・CSS・JavaScript （localStorageによるチェック保持、File System Access APIによるtodo-state.json同期機能、 IndexedDBによるファイルハンドル永続化、同期バー、トースト通知）をそのまま維持すること。 変更するのはタスクの中身（.todo-item 要素群）のみ。
Claudeは親切心からHTML全体を書き直してしまうことがあります。「変更するのはここだけ」と変更スコープを限定する指示を入れることで、既存のJavaScript機能（ローカルストレージ、ファイル同期など）が壊れるのを防いでいます。
設計ポイント5: 案件カテゴリのマッピングルール
- 顧客A DevOps案件 （チャンネル: #prj-customer-a-devops, #sc-customer-a-devops, #notice-customer-a-devops） - 顧客B インフラ構築案件（チャンネル: #prj-customer-b-infra）
Slackチャンネル名と案件名のマッピングを明記することで、Claudeが新しいメッセージを正しいカテゴリに分類できるようにしています。案件が増えた場合は、このマッピングに行を追加するだけで対応できます。
運用してみての所感
実際に数日運用してみて、以下の効果を感じています。
朝の立ち上がりが早くなった。 以前はSlackの各チャンネルを巡回して「あ、これやらなきゃ」と思い出す作業に15-20分かかっていましたが、TODOリストを開くだけで全体像が把握できるようになりました。
タスクの抜け漏れが減った。 Slack「後で」に保存したまま忘れていたメッセージも自動的にリストアップされるため、「あのメッセージに返信するの忘れてた」という事態が起きにくくなりました。
案件の切り替えコストが下がった。 案件別にグルーピングされているので、「午前は顧客Aの案件、午後は顧客Bの案件」といった切り替え時に、何をすべきかすぐ把握できます。
まとめ
Claudeを使って、Slack「後で」とGoogle Calendarから毎朝自動生成されるTODOリストを作りました。
ポイントを振り返ると、Claudeの活用ではMCPコネクタによるノーコードでのデータ取得と、スケジュールタスクによる自動化が鍵でした。TODOリストの設計では案件別グルーピング・3段階優先度・ソース明示・完了状態の二重チェックによる除外判定が工夫点です。プロンプトでは、ステップ分割・条件分岐の明文化・変更スコープの限定・具体的な入出力仕様が再現性を高めるために重要でした。
特にスケジュールタスクのプロンプト設計は、「毎回別のセッションが冷たい状態から実行する」という前提で書く必要があるため、通常の対話的なプロンプトとは少し違った意識が求められます。その分、一度作り込めば安定して動き続けるので、日常業務の自動化に非常に有効だと感じています。
アプリケーションサービス本部
2024年中途入社
アプリケーションサービス本部にてAWSを活用したアプリケーション開発に携わっています！
趣味はお酒とバンドです
