Notion をタスクキューにする MCP を自作した話 — 制作日誌 #4

前回 は Gmail を AI から触る MCP の話を書いた。今回は Notion をタスクキューとして AI から操作する MCP の話。

Notion 連携は claude.ai 純正にも、third-party にもある。にもかかわらず自作した理由は、「タスク管理」という1ジョブに用途を絞った時に、汎用 Notion 連携が逆に重いから。

なぜ汎用 Notion 連携でなく専用 MCP か

claude.ai の Notion 連携は素晴らしい。ページ作成、データベース操作、リッチコンテンツ挿入、ほぼ何でもできる。

ただ「タスクを1件追加する」だけの場面で、その全機能の上を歩くのは、AI 側にもユーザー側にも認知負荷が高い。

• AI 側: ツールが20個並ぶ中から「タスク追加に正しい組合せ」を毎回選ぶ
• ユーザー側: 「期間どうする？」「繰り返しは？」「カラーは？」を AI に都度説明する

これを 「期間と繰り返しのデフォルトを内蔵した、タスク特化の MCP」 に置き換えると、ユーザーは「タスク追加して」と言うだけで済む。AI 側のツール選択も mcp__k-notion__add_task 1個で決まる。

汎用ツールを薄くラップした タスクキュー用の DSL、と言った方が近いかもしれない。

設計の核 — 期間方式 + Notion ネイティブの繰り返し

Notion の Tasks DB には、いくつか定石がある。

期間方式: Due は「日付ひとつ」ではなく「区間」

タスクの締切を Due プロパティに単一日で持つ設計は使いにくい。「いつから手をつけられて、いつまでに終わらせるか」が分からないからだ。

そこで、Due を 日付範囲（start + end） で持つ。

• Due.start = 着手可能日（=タイマー開始日）
• Due.end = 締切日

これだけで、ガントチャート的な見せ方、カレンダーへの幅付き表示、「今日着手可能なタスクは何か」の問い合わせが全部成立する。

add_task の引数は基本このルールに従う。指定しなければデフォルトで:

• due.start = 当日 12:00
• due.end = 1ヶ月後 12:00
• repeat = Daily

「とりあえず1ヶ月の幅で、毎日リマインドが出る」ところに落とす。これは「やる気はあるけど期限を決めきれないタスク」を逃さないための設計。期限がはっきり決まっているなら明示的に書けばよい。

繰り返しは Notion ネイティブの Repeat select で

Notion DB には「Repeat」みたいなプロパティ型はないので、Repeat 列を select 型で自作する。値は Daily / Weekly / Monthly / Yearly / None。

AI 側からは schedule_recurring(name, repeat="Weekly", weekday=...) で渡すと、自動で次回起動日を計算して Due に入れる。タスク完了時に complete_task を呼ぶと、Repeat を見て自動で次の DB エントリを作る、という挙動になる。

繰り返し系のシリーズは、delete_recurring_series(name) で一括削除できる。これがないと「もう要らないルーチン」を消し切れない事故が起きる。

提供している MCP ツール

公開しているのはこのセット:

• add_task — タスク1件追加
• complete_task — タスク完了 → Repeat 設定があれば次回分を自動生成
• delete_task — タスク1件削除
• update_task — 既存タスクの編集（締切ずらし、内容変更）
• list_tasks — 期間・状態で絞り込み一覧
• schedule_recurring — 繰り返しタスクを新規登録
• delete_recurring_series — シリーズまるごと削除

「人間がやる時の最小公倍数」だけ並べてある。重い操作は claude.ai 純正の Notion 連携や Notion 自体の UI に任せる。

「タスク追加して」だけで成立する世界

実際の使用感はこんな感じ:

自分: 「火曜にゴルフ場の予約してリマインドして」 AI: add_task で 火曜 9:00〜10:00 を Due に設定、「ゴルフ場予約」をタイトルに、Notion 登録完了

自分: 「来月毎週月曜の朝、フリーランス案件チェックして」 AI: schedule_recurring(repeat="Weekly", weekday="Monday") で繰り返し設定、初回は次の月曜

自分: 「もう要らない、フリーランスのやつ消して」 AI: delete_recurring_series でまるごと削除

「毎回どのプロパティに何を入れるか」を AI と詰める必要が消えた。これが効く。

リマインダーは別系統 (Google Tasks)

タスク管理と「指定時刻に通知する」リマインダーは、別の話。

このルール分けを意図的にやっている。Notion はあくまで 「やることのリスト」 であって、PC・スマホをまたいで指定時刻にアラートを鳴らす機能ではない。リマインダーは iOS のリマインダーや Google Tasks の方が向いている。

なので、AI には CLAUDE.md レベルで:

「タスク追加して」「あとで」「対応する」「申請する」「確認する」など行動が必要なもの → Notion 「リマインダー」と明示された場合のみ → Google Tasks

と明文化してある。AI 側は文脈で判断する。ツールが多くなるほど「役割を綺麗に切る」のが重要で、ここを曖昧にすると、全部が中途半端な使い心地になる。

デフォルト期間の罠と再発見

最初は due.start = 当日 / due.end = 翌日 のデフォルトで作った。これだと**「翌日見たら全タスクが期限切れ表示**」になって、結局誰も使わなかった。

そこで due.end = 1ヶ月後 に変えた。すると今度は**「1ヶ月たまり続けて、棚卸しを誰もしなくなる**」現象が起きた。

最終的に「毎日 Daily リマインドを出して、未完了タスクは AI が朝のブリーフィングで強制的に見せる」ようにした。これで「タスクが溜まっていく」状態を可視化して、優先度の再振り分けが起きるようになった。

つまり、MCP のデフォルト値ひとつで、運用の習慣が変わる。設計時に「1日後に何が起きるか」「1週間後に何が起きるか」を想像することが、ツール作りでは大事だと学んだ。

公式 / 第三者 / 自作の役割分担

「専用 MCP は薄く小さく、汎用 MCP は表現力高く」の使い分けは、たぶん今後の標準パターンになる。AI に与えるツールが増えるほど、ツールひとつに用途をしぼった専用 DSL を内蔵させる方が、認知負荷が下がって運用が回る。

次回予告

次回は 「ヤマトの集荷依頼を自動化したスキル」——いや、流石にヤマトの名前は出さずに、**「配送会社の集荷依頼を自動化するスキル」**として書く。Playwright + Google Calendar 連携、配送系スキルの王道パターン。

まとめ

• 汎用 Notion 連携で「タスク追加」はできる。ただ表現力が広すぎて毎回 AI と詰める負担が出る
• 専用 MCP として 期間方式 + Notion ネイティブの Repeat select を内蔵
• ツールは「タスク管理の最小公倍数」7つだけ
• リマインダーは 別系統に分離（タスクは Notion / 通知は Google Tasks）
• デフォルト値ひとつで運用習慣が変わることを再発見

← 第3回 Gmail 周りの自作 MCP | 第1回 ブログ立ち上げ記