Cloudflare のメール送信機能 × 定時実行で通知を作るパターン: ローコスト通知
📌 記事の取り扱いについて（公開当時の内容を含みます — タップで詳細）
本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。
ツール工房.ai では、ちょっとした通知メールをよく送っています。週次のイベント情報、ホテルデータの更新リマインダー、サイトの点検や反映（デプロイ）の失敗を知らせる警告などです。
動き出すきっかけは通知ごとに違うのですが、一部の通知では、送信先を固定した共通の窓口を使っています。この記事は、その窓口まわりの話です。
もともとは「できるだけ外部サービスを増やさず、今ある環境の中で小さく通知を回したい」という発想でした。メール送信まわりはプランや提供状況によって変わる可能性があるので、実際に使うときは Cloudflare の最新の案内を確認しながら運用しています。
構成のあらすじ
定時実行の仕組みが決まった時間に動き、必要なデータを取得して通知すべきかを判定し、必要ならメール送信用の窓口に渡す。その窓口が、自分のメールアドレスに通知を届ける。
ざっくり言うと、こういう流れです。
ポイントは、送信処理を独立した窓口に切り出していること。これによって、いくつかの通知が同じ送信窓口を共有できます。
共通の送信窓口を作っておく
送信用の窓口には、/send という入口を用意してあります。
送信専用の入口に、合言葉と一緒に「件名・本文」を渡すと、自分宛にメールが届く、という単純な作りです（宛先は、事前に確認した自分のアドレスに固定してあります）。合言葉が合わないものは受け付けません。
これを共通化しておくことで、新しい通知を増やすのが楽になります。
「○○のイベントが更新されたら通知してほしい」と思ったとき、直接この入口を呼べる処理なら、呼び出しを足すだけで済みます。（クラウド側で動く処理からは直接届かないことがあって、その場合は別の中継を挟んでいます。）
状態を覚えておく置き場
通知系の自動処理では、「最後にいつ送ったか」を覚えておきたい場面が多くあります。
- 同じデータで2回連続で通知しない
- 差分があったときだけ通知する
- 1日に1回までに制限する
こういう判定が必要になるからです。
共通の送信窓口には「状態を保存する場所」も一緒に持たせています。
ネット上の小さなメモ帳を組み合わせて、通知ごとに付けた名前で「前回のメモ」を読み書きできるようにしてあります（こちらも合言葉つきです）。
各自動処理から「前回値の取得・今回値の保存」が簡単に呼べるので、状態管理の重複が減ります。
Cloudflare のメール機能を小さな通知窓口として使う
Cloudflare には、届いたメールを転送する仕組みと、裏側の処理からメールを送る仕組みという別々の機能があります。
私の通知で使っているのは後者、「固定した自分宛に送る」ほうだけです。
良いと感じている点は、追加のメール配信サービスを増やさずに済むことです。
外部のメール送信サービスを別に契約するとなると、無料枠の制限や、配信まわりの管理など、考えることが増えます。個人開発で自分宛に少量の通知を送る用途であれば、今の構成で十分に間に合っています。
ただし、Cloudflare のメール送信機能は、使えるプランや提供状況が変わる可能性があります。特に送信機能は、単なるメール転送とは扱いが違います。なので「ずっと無料で何通でも送れる」と決めつけず、公式の案内を確認しながら使うようにしています。
注意点もある
もちろん、万能ではありません。
メールの宛先は、事前に確認した自分のアドレスに固定しています。不特定多数へ大量に送る用途ではありません。（なお共通の窓口のほうは、用途によってはLINEにも同時に知らせます。この記事ではメール側に絞って書いています。）
ごくまれに届かないこともある前提で見ています。
たとえば、「お金診断記事を公開しました」という1通の通知メールが届かなかったことが一度ありました。通知の呼び出し自体は成功していたのに、受信側には届きませんでした。直後に試したときは届いたので、原因までは特定できていません。
「ごく稀に取りこぼされる」可能性があると認識して、重要な通知は別経路でも確認できるようにしています。
差分を知らせる通知で使っているテンプレ
「前回と比べて変わっていたら知らせる」タイプの通知は、毎回同じテンプレから始められるようにしてあります。
- データを取得する
- 判定用の状態を取り出す
- 送るべきか判定する
- 送るなら
/sendに渡す - 状態を更新する
この形を使う通知なら、新しい種類を足すのもかなり短時間で済みます。
私の場合、通知の仕組みを先に整えておいたことで、その後の運用がかなり楽になったと感じています。
「前回と違うか見て、必要なら自分に知らせる」という流れが共通だからです。（同じ形にならない通知もあって、そちらはそれぞれ別に組んでいます。）
やってみての感想
ローコストで通知を作れるようになると、個人開発の見通しがかなり良くなります。
毎回サイトを見に行かなくても、「動いた」「失敗した」「差分があった」が自分に届く。これだけで、運用の安心感がずいぶん変わります。
大げさな監視システムを作らなくても、まずは自分宛に小さく知らせる。
個人開発では、このくらいの軽さがちょうどいいなと感じています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ