ステップメール配信 — 何が残っていて、リリース時に何をすべきか

名前・年代・性別・地域・流入元などの条件を AND/OR で組み、セグメントとして保存・再利用。該当人数の即時計算、対象者一覧の閲覧、フォルダ整理まで含む。

論点

専用モデル（custom_searches / folders）をゼロから新設。既存の対象抽出ロジックが LINE 前提で account / MarketingUser への移植が重い。設計docでも目的・完了条件が未確定。

入れないと

複雑なセグメント配信・保存条件の使い回しができない。

判断メモ

配信条件モーダルのタグ指定で最低限の絞り込みは可能。第2弾で本実装。

シナリオを組まず、セグメントへ1通を即時／予約で一括送信する（LINE 一斉送信のメール版）。

PR

#4747 · 設計書のみ

論点

元々スコープ外（シナリオ型のみ）だが、今回設計書を起こしドラフトPR化。含めるかは要判断。

入れないと

都度の告知メール等、シナリオを介さない一括送信ができない。

判断メモ

最小シナリオで近いことは可能だが本来のUIとは別物。要否を判断したい。

読者一覧や配信結果を CSV でダウンロードして外部に持ち出す。

PR

#4752 · 設計書のみ

論点

元設計はインポートのみ。今回エクスポートの設計書を起こしドラフトPR化。含めるかは要判断。

入れないと

読者リストや配信結果を書き出せない。他ツール連携・バックアップ不可。

判断メモ

需要があれば別途実装。要否を判断したい。

Web サイト等に埋め込む登録フォームでメールアドレスを収集し、読者リストを自動生成する（自己登録の入口）。

論点

設計docに記載がなく未定義。読者の取り込みは CSV／読者 CRUD のみが対象。

入れないと

外部からの自動的な読者獲得（自己登録）ができない。

判断メモ

当面は CSV・手動登録で対応。獲得導線が要るなら別途設計。

顧客一覧で、同じメールアドレスの重複した読者レコードを1件に名寄せ・統合する。

PR

#4751 · 設計書のみ

論点

元設計に名寄せ運用の定義なし。今回顧客統合の設計書を起こしドラフトPR化。含めるかは要判断。

入れないと

重複登録で同じ人に複数通届く／手動整理が必要。到達率・体験に影響。

判断メモ

まず取込時の重複チェック（#3534）でどこまで防げるか確認。統合UIは別途。

ステップの種類として「画像」を選び、テキストメールとは別に画像を1ブロックとして差し込む。

論点

設計はメール送信＋待機＋終了ブロックのみ定義。画像を独立ステップに差す仕様は未定義。

入れないと

画像主体のステップを組めない。本文への画像埋め込み可否は別途確認。

判断メモ

まず「本文内の画像表現で足りるか」を確認。要るなら仕様策定から。

メール本文をテンプレートとして保存・管理し、複数シナリオで再利用する。

PR

#4748 · 設計書のみ

論点

本文保存の基本（enable_save_as_template）は実装対象。管理・再利用の拡充を設計書化しドラフトPR。

入れないと

テンプレートの一覧管理・使い回しがしづらい（都度コピペ）。

判断メモ

基本保存は入れる確定側。拡充版を今回入れるかを判断。

開始対象を「全員」ではなくタグ条件（AND/OR・グループ）で細かく絞る。

論点

「全員配信＝条件空」で最低限成立するため、細かい条件は後付け可能。

入れないと

初期は「全員 or 単純なタグ指定」止まり。複雑な条件は不可。

判断メモ

条件エンジンは既存流用なので後から段階的に拡張できる。

読者へタグを付け、セグメント用のタグ自体を作成・管理する。

論点

設計のスコープ外。既存マーケティングタグを「参照する」前提で作成・付与UIは作らない。

入れないと

ステップメール画面からタグを新規作成・付与できない（既存タグは参照可）。

判断メモ

既存のタグ管理機能で付与。必要なら導線を後付け。

1ステップ／1メールブロックだけを指定して単独でテスト送信する。

論点

設計docに記載がなく未定義。テスト送信は「シナリオ全体一括」方式のみ定義。

入れないと

特定ステップだけを単独で確認できない。

判断メモ

全体テスト送信（実装対象）で全ステップまとめて確認可能。

シナリオ開始直後に読者へアンケートを提示し、回答に応じて属性付与や分岐を行う。

PR

#4749 · 設計書のみ

論点

既存 Survey が line_user 前提。今回メール対応の設計書を起こしドラフトPR化。含めるかは要判断。

入れないと

アンケート回答を起点にした出し分けができない。

判断メモ

基本の段階配信には不要。需要確認後に別途設計。

シナリオ構成やメール文面を AI が下書き生成し、作成の手間を削減する。

論点

別リポジトリの先行実装を流用できるかの「調査フェーズ」段階で API 仕様が未確定。

入れないと

文面は手動作成のみ。配信機能自体には影響なし。

判断メモ

調査完了後に仕様確定してから。

既存シナリオを複製して下書きから作成。似た配信を量産する運用で効く。

論点

便利機能で必須ではない。

入れないと

毎回ゼロから作成する必要がある。

判断メモ

運用が増えて手間が顕在化したら追加。

%line_name% などの置換文字を実値に置き換えた見た目をプレビューする。

論点

設計上サーバー実装は対象外。フロント表示のみで完結する想定。

入れないと

なし（フロント側の表示範囲で対応）。

判断メモ

今回の実装対象外。追加開発は不要。

メール本文に購読解除リンクを置き、受信者が配信停止できる最小限の導線。

PR

#4746 · 設計書＋BE実装進行中

論点

初期設計でスコープ外。特定電子メール法の観点では通常必須級だが、当初の切り出しに倣い改めて要判断。

入れないと

受信者が自分で配信を止められない（クレーム・法令面のリスク）。

判断メモ

実装は進行中。今回入れるかを判断。

オプトアウトのフル版に加え、配信時間帯の指定・各種通知を含む配信設定一式。

PR

#4750 · 設計書のみ

論点

オプトアウト最小版（#4746）の先の拡充版。

入れないと

時間帯指定・通知・詳細な購読管理ができない。

判断メモ

最小版で足りるか、フル版まで今回入れるか。

SES/SendGrid の通知を受け、不達アドレスのステータスを自動更新する。

論点

初期設計でスコープ外。送信エラー管理（#3511）でどこまで拾えるか要確認。

入れないと

無効アドレスに送り続け、送信レピュテーション・到達率が悪化する恐れ。

判断メモ

#3511 のカバー範囲を確認の上で要否判断。

送信元ドメイン／アドレスの検証フロー（SES/DKIM）。

論点

初期設計でスコープ外。DKIM 導線（#3502）との切り分けを確認。

入れないと

送信元の検証・管理が不十分だと到達率に影響。

判断メモ

#3502 でどこまでカバーされるか確認。

単位時間あたりの送信量を制御し、送信過多によるブロック／遅延を防ぐ。

論点

初期設計でスコープ外。SendGrid 側の制限との兼ね合い。

入れないと

大量送信時に制限超過・遅延のリスク。

判断メモ

想定送信量次第。小規模なら後回し可。

StepMailDelivery#perform! の実配信ロジックと、置換文字の email 対応（PlaceholderReplacer 拡張）。

論点

design.md では「別途検討中／スコープ外」。実配信の心臓部。

入れないと

本番配信が成立しない可能性。

判断メモ

選択というより実装状況の確認事項。現状どこまで動くか要確認。