通知システムの中身（メール編）：もう一つの通知経路としての役割

みなさんこんにちは。まーきゅりーです。

前回はゴトー日通知システムのLINE編として、前日21:00・当日7:00にCloudflare Workersの「Cron機能」が起動し、エントリー注文・決済注文それぞれのタイミングでLINEに通知が届く仕組みを紹介しました。今回はもう一方のメール通知について書いていきます。

メールにはどんな役割を持たせているか

対象日の判定や休場日の確認といった中身は、前回書いたLINE側とまったく同じロジックを使っています。起動するタイミングも同じ前日21:00・当日7:00です。つまり仕組みの土台は共有していて、通知の出し先がLINEとメールの2つに分かれている、という形です。

ではなぜ、同じ内容をメールでも送る必要があるのでしょうか。一番の理由は、通知経路を一つに絞らないことです。LINEは気づきやすい反面、スマホ側の通知設定やアプリの不具合など、自分の環境側の要因で通知に気づけなくなる可能性もゼロではありません。メールはそれとは別の経路なので、どちらかで問題が起きても、もう一方で気づけるようにしています。

もう一つ、メールには「後から見返せる」という良さもあります。LINEのトーク画面は流れていってしまいますが、メールは受信フォルダに残るので、何日の何時にどんな通知が来ていたかを後から確認しやすいという利点があります。

さらに、私はClaudeで毎朝「モーニングブリーフ」を行っていて、そこで未読メールの中から重要そうなものをピックアップしてもらっています。つまりLINEのプッシュ通知に気づかなかったとしても、翌朝のモーニングブリーフで未読のゴトー日通知メールが拾われ、そこで気づけるという、もう一段の保険になっています。通知経路が二重であるだけでなく、見逃したときの拾い直しの仕組みまで用意できているのは、思いがけない副産物でした。

仕組みは共通、出し先が違う

通知の判定ロジック（対象日かどうか、休場日に当たっていないか）は前回紹介したとおりで、メール側でもまったく同じ判定結果を使っています。判定が済んだ後、LINEのMessaging APIに送る代わりに、メール送信の仕組みを呼び出して自分宛てにメールを送る、という違いだけです。

このメール送信の具体的な設定方法やプログラムの中身については、LINE編のときと同じ理由で、記事では触れない方針にしています。「同じ判定結果を、もう一つの経路にも流している」という構成の紹介にとどめようと思います。

LINEとメール、役割分担まとめ

まとめると、LINEは「気づきやすさ」を担い、メールは「記録として残ること・もう一つの経路であること」を担う、という役割分担になっています。どちらか一方だけでは不安が残りますが、2つ揃うことで、ゴトー日の注文忘れという最初の課題にはかなり対応できるようになったと感じています。

次回は運用してみての話

次回は、実際にこの通知システムを使ってみてどうだったかを書く予定です。ただ、運用を始めたのは9月30日のトレードからで、まだ動かし始めてすぐの段階です。実績としてはごく短い期間のものになりますが、その点も含めて正直に書いていこうと思います。

引き続きよろしくお願いいたします。