顧客への自動メール・リマインドを安全に運用する:宛先・上限・配信停止
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。

顧客に自動でメールを送る仕組みを安全に運用するには、送信ボタンの手前に「宛先」「上限」「停止」の3つの関門を置きます。この3つは、メールを送る前の判定と、実行をまたいで共有する件数・停止状態の管理を組み合わせて設計します。 • 宛先:送ってよい相手だけを通します。テスト中は自分のアドレスだけ、本番では配信停止リストと照合した相手だけです。 • 上限:1回の実行と1日の送信件数に天井を決めます。超えたら送らず、人に通知して止めます。 • 停止:誰でも、どこから止めるかを決めておきます。ツール側のオフ操作と、自分たちの停止フラグの両方を用意します。 以下に、送信前チェック項目、上限と緊急停止を決めるメモ、各ツールで確認できた仕様、日本での配信停止の考え方を順に示します。サンプルの数値や顧客名は「説明用の例」で、実測値ではありません。例の設計は、この記事の作成時には実際のワークフローで動かしていません。
送信前の安全チェック項目
ワークフローを本番にする前に、次の表を埋めます。「いいえ」が残るうちは、本番の宛先に接続しません。
- 宛先、確認項目:テスト実行は自分・社内のアドレスだけで行ったか、はい/いいえ:
- 宛先、確認項目:宛先が空欄・複数件・社内共用アドレスのときに止まるか、はい/いいえ:
- 宛先、確認項目:配信停止リストと照合してから送っているか、はい/いいえ:
- 宛先、確認項目:同意の取得日と方法を記録した列があるか、はい/いいえ:
- 内容、確認項目:差し込み項目(氏名・日時)が空のとき送らないか、はい/いいえ:
- 内容、確認項目:件名と本文の冒頭に、誰からの何の連絡か分かる記載があるか、はい/いいえ:
- 内容、確認項目:広告・販促の文言を、リマインドや手続き連絡に混ぜていないか、はい/いいえ:
- 停止、確認項目:本文に配信停止の方法があり、受け付けた相手が次回から除外されるか、はい/いいえ:
- 上限、確認項目:1回の実行と1日の件数上限を設定したか、はい/いいえ:
- 上限、確認項目:宛先と予約IDなどで送信を識別し、再実行・同時実行でも重複送信を防ぐ仕組みがあるか、はい/いいえ:
- 停止、確認項目:緊急停止の担当者と手順を決め、実際に一度試したか、はい/いいえ:
- 検知、確認項目:エラーや上限超過が起きたとき、人に通知が届くか、はい/いいえ:
宛先の確認は、「送ってよい」という条件を足していく書き方にします。「除外する」条件を足す書き方だと、想定外のデータが素通りしやすくなります。
送信上限と緊急停止を決めるメモ
次のメモをコピーして、自分の業務の数字で埋めます。ここは公式の仕様ではなく、運用側で決める項目です。
【送信上限・緊急停止メモ】
自動化の名前:
送るメールの種類:(予約リマインド/支払い期限の連絡 など)
通常の1日の送信件数:___件 過去の最大:___件
1回の実行の上限:___件(目安:通常の最大の1〜1.5倍)
1日の上限:___件(目安:過去最大の1.5〜2倍)
上限を超えたとき:送信せず停止 → 通知先(___)へ連絡
同一宛先への送信間隔:最短___日
停止を判断する人:___(不在時の代行:___)
停止の手順:①停止フラグをON ②ツール側でオフ ③実行中・待機中・送信サービス側の予約を確認し、必要な停止・取消操作を行う ④送信済み件数を確認
再開の条件:原因の特定/対象リストの再確認/担当者の承認説明用の例
予約リマインドを毎朝送る小さな店を想定します。通常は1日20件、これまでの最大が45件だったとします。この場合、1回の上限を50件、1日の上限を80件にします。ある朝120件が対象になったら、それは異常です。件数を「通常より多い=忙しい」とは受け取らず、対象リストの抽出条件が崩れた可能性を先に疑います。
数字の倍率は目安にすぎません。大事なのは、上限を決めた根拠を「通常と過去最大」としてメモに残し、見直す日(たとえば月1回)を決めることです。
1日の集計範囲(例:日本時間の0時〜24時)と、送信サービス側の上限も確認します。同時実行で上限を超えないよう、件数の確認と送信枠の確保を一体で行うか、送信処理を直列化します。各通の送信直前には、配信停止・緊急停止の最新状態を確認し、状態を取得できなければ送らず止めます。ツールをオフにするだけで待機中・実行中の処理まで止まるとは想定せず、停止手順をテスト用アドレスで確かめます。
ツール別:上限と停止で確認できた仕様
各社の公式ヘルプで確認できた範囲です。プランや画面は変わる可能性があるので、設定時に最新の表記を見てください。
n8n
n8nの公式ドキュメントでは、レート制限への対応として、Loop Over Itemsで項目をまとめ、Waitノードで間隔を空ける方法が紹介されています。Retry On Failは失敗後に待つ仕組みで、あらかじめ間隔を空けるのはLoop Over ItemsとWaitの組み合わせ、と整理されています。送信間隔を空ける用途には、後者が向いています。1回・1日の総送信件数の上限は、別に判定します。
また、エラー用のワークフローをError Triggerで作り、本体のワークフロー設定から指定できます。Stop And Errorノードを使えば、任意の条件で実行を失敗させ、そのエラー用ワークフローを動かせます。上限メモに合わせて「件数が上限を超えたらStop And Errorで止め、エラー用ワークフローから担当者に通知する」という作りにできます。ただし、Error Triggerは自動実行でエラーが起きた場合だけ動くため、通知の確認はテスト用アドレスに限定した自動実行で行います。
Zapier
Delayステップの公式ヘルプには、次の記載があります。
- 遅延中にZapをオフにすると、遅延中のタスクは続行せず、再びオンにしても再開しません。
- 遅延中にZapを変更(アクションの追加・変更・削除)すると、そのタスクは再開後に続行しません。
- 遅延中のタスクを止めるには、Zapをオフにするか、Zap履歴から実行を削除します。
- 1つのステップの遅延は最長30日です。
つまり、Delayで待機中のタスクを止めるには「Zapをオフにする」が有効です。この説明だけで、Delayを通過した処理まで止まるとは判断できません。復旧時は、停止した分の送信状況を人が確認し、重複や配信停止を照合したうえで、必要な分だけ補います。
Make
Makeのシナリオ設定では、連続エラーが何回続いたら停止するかを「Errors before deactivation」で決められます。インスタントトリガーの場合はこの設定が無視され、原則として最初のエラーですぐ無効になります。ただし、後述のSkipなど、エラー処理による例外があります。「Cycles per run」は1回の実行で許される最大サイクル数を決める設定です。ただし、これが送信件数の上限として使えるかは公式の記述だけでは判断できないため、件数の上限は自分でフィルターやカウンターで作る前提にしてください。
ここで注意したいのは、Skipエラーハンドラーです。Skipはエラーになったバンドルを取り除いて続行し、実行を成功扱いにします。送信エラーを黙って飛ばす設計では、異常に気づけません。顧客向けの送信では、Skipを使うなら通知とセットにします。
配信停止と日本の規制をどう見るか
日本では、消費者庁の特定商取引法ガイドが、通信販売などの電子メール広告について、あらかじめ請求や承諾をしていない相手への提供を原則として禁止する規制(オプトイン規制、2008年12月施行)を説明しています。同ガイドの通信販売の説明と電子メール広告規制のポイントからは、次の点が読み取れます。以下は主に通信販売の電子メール広告についての説明です。
- 請求や承諾を得た記録は、原則として最後に電子メール広告を送った日から3年間保存する必要があります。同意日・取得方法の列だけでなく、何への承諾だったかを確認できる記録も残します。
- 相手が電子メール広告を受け取りたくない意思を示したら、その相手への電子メール広告の再送は禁止されます。
- 契約成立・注文確認・発送通知など、契約に関する重要事項の通知に付随する広告は、オプトイン規制の適用除外となる場合があります。
- 電子メール広告の本文には、受信拒否を申し出るメールアドレスやURL等を、容易に認識できるよう表示する必要があります。事業者名や連絡先など、広告の表示事項も別途確認します。
自動化に直すと、「同意日・同意方法の列」「配信停止の列」「送信前の照合」の3つになります。配信停止は、本文のリンクで終わらせず、停止を受けた時点でリストを更新し、次回の送信判定に必ず反映する流れまで作ります。
「リマインド」「手続き連絡」という名称だけでは、広告への該当性や適用除外を判断できません。販促を含む場合は、契約に関する重要事項の通知に付随する広告なのかなど、内容と条件を確認します。件名・本文の目的を分けておくと判断しやすくなります。個々の事業で規制の対象になるか、通販以外の規制(総務省所管の特定電子メール法など)に当たるかは、事業の形態で変わります。判断に迷うときは所管の窓口や専門家に確認してください。
AIに任せること、人が確認すること
AIには、設計の抜け漏れ探しと文面の下書きを任せます。送信先リストの実データや本物のAPIキーは渡さず、下のように説明用データに置き換えます。
次の自動メールの設計を、誤送信と配信停止漏れの観点でレビューしてください。
抜けている確認項目と、上限を超えたときの止め方を指摘してください。
【設計】
トリガー:毎朝8時
対象:明日予約のある顧客(シートの「予約日」列で抽出)
送信:予約前日のリマインド1通
宛先列:email(例:sample@example.com)
配信停止:本文のリンク → シートの「停止」列にTRUEを入れる
通常の件数:1日約20件、過去最大45件
使用ツール:(n8n / Zapier / Make のいずれか)AIの指摘は、そのまま採用しません。人が確認するのは次の点です。
- 上限の数字(AIは自社の過去件数を知りません)
- 配信停止の列が、送信判定の前に参照されていること
- テスト用アドレスで、停止フラグと上限超過の両方を実際に動かしたこと
- 規制の適用や文面の広告該当性(AIではなく、所管資料や専門家で確認)
この確認を終えるまでは、本番の宛先を接続しないでください。

