# メールマーケティングの自動化：まず状態のチェックを設計する

正規URL：https://brew.new/ja/blog/email-marketing-automation-guide
執筆：Thomas Park
公開日：2026-08-19
更新日：2026-09-29

メールのオートメーションとは、いつメッセージを送るかについての、繰り返し使える判断です。エディターは、その一部にすぎません。イベント、顧客の現在の状態、停止のルールは、コピーと同じくらい重要です。

シーケンスを描く前に、各メッセージが存在すべき理由と、送信される時点でそのメッセージを不適切にしてしまう条件を書き出しましょう。

## トリガーとそのデータを定義する

新規登録、購入の完了、支払いの失敗、製品での節目などが、オートメーションの起点になります。イベントには明確な意味を持たせましょう。「ユーザーがアクティブ」は曖昧ですが、「最初のレポートをエクスポートした」なら、アプリケーションが記録し、テストできます。

メッセージに必要なデータだけを含め、必要に応じて、変わらない識別子とタイムスタンプを付けます。それぞれの値をどのシステムが管理するかも決めましょう。イベントの配信は再試行されることがあるので、連携側が対応している冪等性の仕組みを使い、重複して配信された場合もテストします。

[Stripe 連携](/ja/browse/integrations/stripe)は、ドキュメント化されたサブスクリプションと支払いのイベントを提供します。製品に固有の節目は、アプリケーションの独自のイベントでカバーできます。

## 待機と対象条件のチェックを分ける

待機によって変わるのは、次のステップが実行されるタイミングです。待機そのものが、オートメーションの知っている事実を更新するわけではありません。

Brew のイベントトリガー型のフローでは、「フィルター」ノードと条件分岐ノードが、イベントのデータとコンタクトのデータを区別します。`activated` または `payload.activated` は、元のイベントを読み取ります。`activated: false` という登録時のペイロードは、翌日には古くなっているかもしれません。`contact.activated` は、その条件ノードが実行された時点での、受信者の現在の Brew のコンタクトフィールドを読み取ります。「待機」の後でも同じです。

セットアップのリマインダーなら、`activated` という真偽値のコンタクトフィールドを宣言し、アプリケーションから同期し続けて、待機の後に `contact.activated equals false` のフィルターを置きます。値がないことと false は同じではないので、両方をテストしましょう。この状態に依存する後続のリマインダーには、それぞれの前に条件を置きます。コンタクトの更新や新しいイベントによって、進行中の実行が自動的にキャンセルされることはありません。

コンタクトの読み取りでは、自社の製品データベースや請求プロバイダーに問い合わせることはありません。対象となるかどうかが、同期していないアクティビティ、特定の請求書、現在のカートの中身によって決まるなら、そのチェックはアプリケーション側でスケジュールしましょう。予定の時刻になったら、正となるレコードを読み取り、リマインダーにまだ意味がある場合にだけ、対象であることを示す新しいイベントを送信します。

両方の方法は、[トライアルのシーケンスのガイド](/ja/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events)で解説しています。条件で使うフィールドのパスについては、[オートメーションのリファレンス](https://docs.brew.new/create-emails/build-an-automation#check-state-before-later-reminders)をご覧ください。

## まずは役に立つシーケンスを1つ

ウェルカムのオートメーションなら、登録時に約束した資料や次のステップを届けられます。支払いの通知なら、実際の請求イベントを説明できます。製品での節目に送るメールなら、完了したばかりの作業の成果を生かす手助けができます。

最初のバージョンは、隅々まで確認できるくらい小さく保ちましょう。メッセージごとに、オーディエンス、トリガー、必須のフィールド、促したい行動、そして送信を止めるべき条件を記録します。その確認には、購読状態と配信除外の動作も含めましょう。

Brew では、実行を決めるのは公開したオートメーションです。下書きを作成・編集しても、公開したことにはなりません。連携サービスの設定とオートメーションの状態は、役割が異なります。たとえば、Stripe の**氏名を同期**の設定が制御するのは名前の更新であり、イベントで起動するオートメーションが実行されるかどうかではありません。

## 状態の変化をテストする

通常の実行、任意のフィールドが欠けている場合、重複したイベント、マーケティングメールの配信を停止したコンタクト、リマインダーの予定時刻より前に状態が変わった顧客をテストします。コンタクトの条件については、待機中に Brew のフィールドを更新し、後の条件でリマインダーがスキップされることを確認しましょう。アプリケーション側でスケジュールするリマインダーについては、顧客が対象から外れたときに、アプリケーションが、対象であることを示す新しいイベントを送信しないことを確認します。

実行記録だけでなく、実際のメールも確認しましょう。リンク、差し込みタグ、送信ドメイン、そして公開されている正確なバージョンをチェックします。トリガーのリクエストが成功しただけでは、正しいメッセージが正しい受信トレイに届いたことの証明にはなりません。

## 製品の変化に合わせてオートメーションを見直す

常時稼働のシーケンスは、セットアップの手順、料金、製品の利用範囲が変わると、気づかないうちに時代遅れになることがあります。シーケンスごとに担当者を決め、関連するリリースの後に見直しましょう。

意図した成果と、望ましくない影響の両方を測定します。目的がセットアップの完了なら、その行動を、迷惑メール報告や配信停止とあわせて追跡しましょう。開封を、オートメーションが役立った証拠として扱わないためには、[指標のガイド](/ja/blog/email-metrics-that-matter)が参考になります。