# ウェルカムメールのシーケンス：例、タイミング、対象条件

正規URL：https://brew.new/ja/blog/welcome-email-sequence
執筆：Brew Team
公開日：2026-08-16
更新日：2026-09-29

ウェルカムシーケンスは、新しい購読者が次に何をすればよいかを知る手助けをします。SaaSなら、最初のプロジェクトを作成することかもしれません。ECストアなら、商品のラインナップを知ること。ニュースレターなら、何がどのくらいの頻度で届くのかを知ることかもしれません。

まずは、登録時にした約束から考えましょう。その後のメールはすべて、その約束を果たす助けになるべきです。タイミングやメッセージの数は、製品とオーディエンスによって異なります。以下の例は、テストの出発点として使ってください。ウェルカムシーケンスは、[AIでメールを自動化する](/ja/blog/ai-email-automation)ガイドで紹介している、ライフサイクルフローの最初の1つです。

## 起点となるイベントを選ぶ

| 起点 | 最初のメッセージに適した内容 | 確認すること |
| --- | --- | --- |
| アカウントの作成 | セットアップの操作を1つ | メールアドレスの確認を先に済ませるべきか |
| メールアドレスの確認完了 | 歓迎のあいさつと、製品への直接のリンク | 確認メールと内容が重複しないようにする |
| ニュースレターの購読 | 届く内容の案内と、役に立つ例を1つ | 受信者の同意と、選んだトピック |
| ストアへの会員登録 | 商品、購入の案内、または約束したオファー | オファーの実際の条件と有効期限 |

Brew では、バックエンドから送るカスタムイベントや、[Supabase](/ja/browse/integrations/supabase) や [Clerk](/ja/browse/integrations/clerk) などの対応する連携サービスを起点に、フローを開始できます。ペイロードは選択したトリガーのスキーマに沿って組み立て、そのトリガーの実際のIDを使ってください。

## SaaSのウェルカムメールの例

| メール | タイミングの目安 | 役割 | 送信時点の対象条件 |
| --- | --- | --- | --- |
| ウェルカム | 登録後、またはメールアドレスの確認後 | 最初のプロジェクトの作成を後押しする | 新規アカウント |
| セットアップのサポート | 2日目 | 短い例を1つ見せる | まだアクティベーションしていない |
| 次のステップ | アクティベーション後 | 次に役立つ行動を紹介する | アクティベーション済み |
| トライアルのリマインダー | トライアル終了の前 | 次に何が起きるかを説明する | まだトライアル中で、支払いをしていない |
| 様子伺い | 適切な間隔をあけて | サポートを申し出る | 引き続き対象で、受信の許諾もある |

各メールは、1つの行動を軸に書きましょう。実在するリンク先のURL、明確な件名、誰かが目を通している返信先アドレスを使います。ありきたりな緊急性の演出や、測定していない成果についての主張は避けましょう。

## ニュースレターやECストアのウェルカムメールの例

ニュースレターの場合、最初のメッセージでは、約束した資料を届け、配信の頻度を伝え、代表的な記事を紹介できます。その後のメッセージでは、受け取るトピックの設定方法を説明したり、書き手を紹介したりできます。ニュースレターなら、2通目を送る理由づけのために、SaaSのようなアクティベーションのファネルを用意する必要はありません。

ECストアの場合は、まず約束したオファーを届け、それから購入に役立つ案内をします。対象外の商品や有効期限は、正確に書きましょう。購入すると、残りの割引のリマインダーは不要になる場合があるため、対象条件のチェックには購入状況を含めます。

## フォローアップを書く前に、終了条件を決める

それぞれのメッセージを止めるべき条件を決めましょう。アクティベーション、購入、オファーの期限切れ、アカウントの削除、配信停止、プランの変更などです。そのうえで、そのルールを、現在の状態を実際に読み取るシステムに実装します。

Brew のイベントトリガー型のフローでは、`payload.activated` を使う条件は、元のイベントを読み取ります。`contact.activated` を使う条件は、ノードが実行される時点（「待機」のあとを含む）の、Brew のコンタクトフィールドの現在の値を読み取ります。フィールドを宣言して同期し、その値に依存する各リマインダーの前に条件を置きましょう。コンタクトの更新や、あとから届いたイベントによって、以前に開始した実行が自動的にキャンセルされることはありません。

同期していないアカウントのデータや、特定の購入に左右される対象条件については、自社のアプリケーションでチェックを予約しましょう。メッセージの送信時点で正となるレコードを読み取り、ルールにまだ当てはまる場合にだけ、リマインダーの対象であることを示す別のイベントを送信します。[オートメーションを作成する](https://docs.brew.new/create-emails/build-an-automation#check-state-before-later-reminders)もご覧ください。

## シーケンスを作成して確認する

Brew で、トリガー、オーディエンス、望む行動、トーンを説明しましょう。[フローギャラリー](/ja/browse/flows)にある公開例から始めることもできます。ただし、そのタイミングはあくまで参考です。同じスケジュールが自社のオーディエンスにも効果的だという根拠にはなりません。

生成されたフローのグラフと、すべてのメールを確認します。リンク、差出人、パーソナライズの代替値、ドメインの用途を確かめましょう。確認用のメッセージと、販促を含むオンボーディングのメッセージとでは、満たすべき要件が異なる場合があります。米国の「主な目的」による判断基準は[FTCのガイド](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business)で、認証、迷惑メール率、配信停止のルールは [Gmail の送信者の要件](https://support.google.com/mail/answer/81126)で説明されています。

## うまくいくケース以外もテストする

登録、重複したイベント、パーソナライズ用のデータの欠落、対象外の受信者をテストしましょう。コンタクトの条件については、待機中に同期対象のフィールドを更新し、リマインダーがスキップされることを確認します。フィールドが欠けている場合もテストしましょう。アプリケーション側で予約したリマインダーについては、チェックの前にアクティベーションや購入を行い、リマインダーのイベントが送信されないことを確認します。配信停止の処理と配信結果も確かめておきましょう。

公開するのは、メッセージと対象条件のチェックを確認してからにしましょう。配信やクリックのデータとあわせて、セットアップの完了や初回の注文など、シーケンスで後押ししたい行動を追跡します。その行動につながっているメッセージは残し、それ以外は見直しましょう。

実装の例については、[Cursor からオンボーディングを構築する方法](/ja/blog/how-to-create-an-email-onboarding-sequence-from-cursor)と、[製品イベントを使ったトライアル転換のシーケンス](/ja/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events)をご覧ください。