← 制作記一覧へ

Cloudflare のメール送信機能 × 定時実行で通知を作るパターン: ローコスト通知

公開: 2026-05-30 · #42 / 最終更新: 2026-06-04 Cloudflare通知Email Sending定時実行

📌 記事の取り扱いについて:本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。

ツール工房.ai では、ちょっとした通知メールをよく送っています。週次のイベント更新、ホテルデータベースの更新、サイトへの反映(デプロイ)の完了通知などです。

これらの通知は、Cloudflare の 定時実行の仕組み と、メール送信用の小さな窓口 を組み合わせて作っています。

もともとは「できるだけ外部サービスを増やさず、今ある環境の中で小さく通知を回したい」という発想でした。メール送信まわりはプランや提供状況によって変わる可能性があるので、実際に使うときは Cloudflare の最新の案内を確認しながら運用しています。

構成のあらすじ

定時実行の仕組みが決まった時間に動き、必要なデータを取得して通知すべきかを判定し、必要ならメール送信用の窓口に渡す。その窓口が、自分のメールアドレスに通知を届ける。

ざっくり言うと、こういう流れです。

ポイントは、送信処理を独立した窓口に切り出していること。これによって、いろんな通知の自動処理 が同じ送信窓口を共有できます。

共通の送信窓口を作っておく

送信用の窓口には、/send という入口を用意してあります。

POST /send に「件名・本文」をデータの形で送れば、自分宛にメールが届く、という単純な作りです(宛先は自分のアドレスに固定してあります)。

これを共通化しておくことで、新しい通知の自動処理 を増やすのが楽になります。

「○○のイベントが更新されたら通知してほしい」と思ったとき、新しい自動処理からこの /send に向かって投げる処理を足すだけで済みます。

状態を覚えておく置き場

通知系の自動処理では、「最後にいつ送ったか」を覚えておきたい場面が多くあります。

  • 同じデータで2回連続で通知しない
  • 差分があったときだけ通知する
  • 1日に1回までに制限する

こういう判定が必要になるからです。

共通の送信窓口には「状態を保存する場所」も一緒に持たせています。

ネット上の小さなメモ帳を組み合わせて、/state/<キー名> のような形で値を読み書きできるようにしてあります。

各自動処理から「前回値の取得・今回値の保存」が簡単に呼べるので、状態管理の重複が減ります。

Cloudflare のメール機能を小さな通知窓口として使う

Cloudflare には、届いたメールを転送する仕組みや、Workers からメールを送るための仕組みがあります。

私の用途では、それらを細かく使い分けるというより、「自分宛の通知を送る小さな窓口」としてまとめて扱っています。

良いと感じている点は、追加のメール配信サービスを増やさずに済むことです。

外部のメール送信サービスを別に契約するとなると、無料枠の制限や、配信まわりの管理など、考えることが増えます。個人開発で自分宛に少量の通知を送る用途であれば、今の構成で十分に間に合っています。

ただし、Cloudflare のメール送信機能は、使えるプランや提供状況が変わる可能性があります。特に送信機能は、単なるメール転送とは扱いが違います。なので「ずっと無料で何通でも送れる」と決めつけず、公式の案内を確認しながら使うようにしています。

注意点もある

もちろん、万能ではありません。

送信先は自分宛が基本です。不特定多数へ大量に送る用途ではありません。

配信が遅れることもありますし、ごくまれに届かないこともある前提で見ています。

たとえば、「お金診断記事を公開しました」という1通の通知メールが届かなかったことがあります。送信ログを見ると確かに処理は走っていたのですが、受信側には届きませんでした。

原因は完全には特定できませんでしたが、「ごく稀に取りこぼされる」可能性があると認識して、重要な通知は別経路でも確認できるようにしています。

通知の自動処理 の汎用テンプレ

新しい通知の自動処理 を作るときは、毎回同じテンプレから始められるようにしてあります。

  1. データを取得する
  2. 判定用の状態を取り出す
  3. 送るべきか判定する
  4. 送るなら /send に渡す
  5. 状態を更新する

このパターンに当てはめれば、新しい通知の追加はかなり短時間で済むようになります。

通知系の仕組みを最初に整えておくと、その後の運用が劇的に楽になります

通知の中身はそれぞれ違っても、「前回と違うか見て、必要なら自分に知らせる」という流れはだいたい共通だからです。

やってみての感想

ローコストで通知を作れるようになると、個人開発の見通しがかなり良くなります。

毎回サイトを見に行かなくても、「動いた」「失敗した」「差分があった」が自分に届く。これだけで、運用の安心感がずいぶん変わります。

大げさな監視システムを作らなくても、まずは自分宛に小さく知らせる。

個人開発では、このくらいの軽さがちょうどいいなと感じています。


← 他の制作記を見るトップお問い合わせ