日付指定リマインダが静かに取りこぼす理由と、台帳方式への作り替え

指定時刻に一度だけ動く日付指定リマインダは、その瞬間にホストが止まっていれば、何も言わずに約束を落とします。今回作り替えたのは、その静かな取りこぼしを減らすための小さな道具です。

自宅ラボを無人で動かしつつ、「この日に思い出して」を任せたい人にとって、必要なのは派手な自動化ではありません。予定を後から見返せて、止まっていた後にも追いつけることです。

これは工作展・第2期『ラボを支える小さな道具たち』の3つ目として置いた、日付指定リマインダの記録です。

一発型の通知は、止まった瞬間だけ予定を失います

旧環境では、指定時刻に一度だけ知らせを送り、送ると設定ごと消える定期処理を使っていました。単純で、予定が少ない間は扱いやすい形です。ただし移設調査をした2026-07-25、2日後に鳴る設定のまま残った一発ものを見つけました。

所長の判断は明快でした。取りこぼしは許容しない。新環境に組み込む。その一点で、作りを替えました。

旧作りには、3つの弱さがありました。

図1は、変えたのが通知先ではなく「予定をどこに残すか」だったことを示しています。

読み取るべき点は、止まっていた側です。旧作りでは予定時刻を過ぎた事実がそのまま消えます。新しい作りでは、予定時刻を過ぎていて、まだ知らせ済みでなければ対象に残ります。

台帳には、約束に必要な4項目だけを書きます

台帳の1件は、一意な識別子、タイムゾーン付きの予定時刻、知らせる本文、由来メモの4項目です。通知のための大きな仕組みを増やす代わりに、約束そのものを小さく残しました。

予定時刻のタイムゾーンが省かれていた場合は、自宅の標準時として扱い、警告を出します。時刻の意味を曖昧にしたまま通知だけ正しくしようとしても、後から困るためです。

図2で変化しないのは、台帳の中身が4項目だけであることです。再試行や送信済みの扱いは巡回側が引き受け、予定を書く側に複雑さを押しつけません。

成功した時だけ、知らせ済みにします

台帳を見に行く定期処理は毎時1回です。予定時刻を過ぎた未送信の項目を送信し、成功した時だけ知らせ済みにします。失敗なら次の巡回で再び対象になります。

この判断は、送信を試みたことを成功と混同しないためのものです。以前の連続SKIPは成功ではない — fail-closed が静かに壊れるときでも扱ったように、動かなかった記録だけで完了を決めると、失ったものが見えにくくなります。

毎時1回の巡回なので、理屈上の最悪の遅延は1時間です。一方、ホストや定期処理が止まっていた期間をまたいだ場合も、復帰後の巡回で未送信分を探します。これは無人運用を続けるための土台としても、小さいながら重要な差です。

6時間を超えて遅れた知らせには、遅延の印と、本来の予定時刻・実際に送った時刻を添えます。遅延そのものを消せないなら、少なくとも遅れた事実は隠しません。

最小再現は、台帳と毎時巡回だけです

• 予定を1件ずつ残す台帳を用意する
• 毎時1回、その台帳から「予定時刻を過ぎ、まだ知らせ済みでない項目」を探す
• 送信が成功した項目だけを知らせ済みにする
• 一覧表示と、送信せず対象だけを見る確認手段を用意する

通知サービスや保存形式は、この仕組みの本質ではありません。先に決めるべきなのは、失敗した送信を完了として扱わないことです。

作り替え直後は、旧作りも少しだけ残っていました

移行直後は旧作りの一発ものも生きており、同じ日に通知が二重に届く可能性がありました。しばらくは二人羽織の状態です。ただし旧作りは知らせを送ると自分で消えるため、その後に残るのは台帳方式です。

この仕組みに最初に登録したのは、2026-07-27 09:00を予定時刻とする、ある作業の着手判断を思い出すための1件でした。最初の約束を送り届けた後も、定期処理は毎時、淡々と台帳を見に行っています。

今すぐ多機能な通知基盤へ寄せる必要はありません。まずは自分が落としたくない「この日」を1件だけ台帳に書き、次はどんな約束を託すかを決めれば十分です。

{"id":"reminder-1","due_at":"2026-07-27T09:00:00+09:00","message":"着手判断","sent_at":null}