リリース範囲 検討資料 · 話し合い用

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

シナリオ配信の骨格は実装済み。運用系(送信ドメイン認証・送信結果の可視化・読者の一括登録・再送防止)もすべて実装され、子PRとして出揃ったただし 2026-07-08 の打ち合わせで現行実装がデザイン仕様と乖離していると判明し、新デザインへの全面刷新を経てリリースする方針に転換。この資料は、その状態を共有し、リリースに含める範囲を議論するためのもの。

統合ブランチ PR #3206 → develop デザイン Figma を開く ↗ リリース目標 理想 9月末/遅くとも10月中旬(12月末の助成金着金から逆算) 時点 2026-07-08

🔄 方針転換(2026-07-08 打ち合わせ)— 新デザインへ全面刷新してリリース

現行の実装がデザイン仕様と乖離していることが判明。古いデザインのまま進めるのではなく、新デザインに全面作り直した上でリリースする方針に決定。これにより、下記セクション02「子PRのレビュー→マージのみ」という前提は変わり、FE 画面は新デザインでの作り直しが前提となる。進め方は、加藤氏が操作性重視のモックを作成 → 事前共有 → 打ち合わせで検証というフローに合意(デザイン性は二次的)。

01 リリース必須ライン

「登録 → 配信 → 結果確認」の一周が回ることが最低条件

単機能だけの部分リリースは不可。以下の3本柱がすべて揃って初めて実運用に耐えるという整理。必須ラインの機能はすべて実装済み(子PRが出揃った)状態で、あとはレビューとマージのみ。

DKIM 送信ドメイン設定 + 送信結果・エラー画面(BE / FE) + CSV インポート(BE / FE) + 再送防止(任意だが含めたい)

02 残タスク一覧(=出揃った子PR。すべて実装済み)

OPEN/レビュー待ち Draft クリティカルパス ■ 必須 ■ 強く推奨
PR機能種別状態マージ単位リリース
#3511 送信管理・送信エラー画面用API
mail_message モデル+一覧/詳細/再送を新設する土台
BE OPEN 要レビュー #4737 とセット 必須
#4737 メール送信エラー一覧画面 (旧 #3517) FE OPEN #3511 とセット 必須
#3534 CSV インポート関連API
読者の一括登録・レビュー指摘対応済み
BE OPEN 要レビュー #4702 とセット 必須
#4702 CSV インポート画面 (旧 #3537。モーダル+完了表示+インポート履歴一覧を含む) FE Draft #3534 とセット 必須
#3502 メアドドメイン DKIM 設定+顧客登録の導線 FE OPEN 単独 必須
#4703 送信失敗時の再送ループ防止制御 (旧 #3540) BE Draft 単独 · #3511 非依存 強く推奨

※ 前版で「#3540(再送防止)は #3511 に依存」としていたが、#4703 として #3511 非依存の設計で実装済みと判明したため訂正。BE(API)側の #3511 / #3534 / #4703 はロジックとしては他タスクを待たずに進められる。ただし 2026-07-08 の方針転換により、FE 画面は新デザインへの作り直しが前提となるため、下表の「レビュー→マージ」は主に BE に当てはまり、FE 側は Mock 検証後の再実装が必要になる見込み。

03 リリースに含める範囲の検討(設計にある機能の仕分け)

この会議で各機能を 未分類 / 入れる / 入れない に仕分ける。下の「入れる(確定)」は実装済み・実装対象で既に入れる前提。その下の候補を、各カードのボタンで会議中に仕分けていく。

2026-07-08 打ち合わせ①:MyASP 機能を洗い出して追記

分析・計測(開封率・クリック率・解除率)が必須級として新たに浮上(「最低ないときつい」)。現状の子PRには無い新規領域のため、下の仕分け対象の冒頭に追加。

2026-07-08 打ち合わせ②:優先度整理・仕分け結果を確定

上記①を踏まえて優先度を整理し、下の各カードの入れる/入れないを確定(カードの帯・初期選択状態に反映済み)。あわせてメール・LINE の分離管理/顧客管理の統合方針という新しいアーキテクチャ決定と、流入経路管理という新規機能が追加された。

🏗 アーキテクチャ決定 サイドバー・顧客管理の設計方針(2026-07-08 確定)

  • メール・LINE は分離管理 サイドバー/ステップ配信はメールと LINE を別々に管理・表示
  • 顧客管理は統合 顧客はリスト単位で一元管理し、その中でメール/LINE の登録状況を持つ設計を正とする

入れる(確定) 実装済み・実装対象

  • シナリオ一覧・作成・基本設定 骨格
  • ツリー編集(待機/終了ブロック・運用開始) 既存API流用
  • メール本文編集(件名・本文・置換文字) 配信内容
  • メール本文のテンプレート保存・再利用 enable_save_as_template・推奨スコープ
  • 配信条件・配信時刻・終了ブロック選択 開始トリガー
  • テスト送信(ステップ単位・個別) 07-08確定。全体一括テストは不要と決定
  • 顧客 CRUD・絞り込み 読者管理
  • CSV インポート 必須機能(#3534/#4702)
  • タグによる配信対象の絞り込み ⚠ 実装有無を要再確認(記載ミスの可能性)
  • プレーンテキスト配信 HTMLメールは初期スコープ外の方針

仕分け対象 入れる/入れないを判断する機能

各カードの 何をする機能か・なぜ即決でないか・入れないと何が起きるか・代替 を見て、下のボタンで 未分類/入れる/入れない を選ぶ。集計は下のバーに反映される。
候補の多くは今回新たに設計書を起こしドラフトPR化済み(#4746〜#4752、#4702/#4703 と同方式)。PR がある=実装着手済みだが、今回リリースに含めるかはこの場で判断する

未分類 0 入れる 0 入れない 0 決定 0 / 0 判断の目安 — 入れる=今回リリースに含める/入れない=今回は含めない(次回以降で再検討)。各カードの「影響度」(要確認・中・小・なし)が優先度のヒント。状態はこの端末にのみ保存され同期しません。

流入経路管理新規機能・07-08確定

確定:入れる

読者がどの経路(流入元)から登録したかを記録・管理する。

論点
07-08 打ち合わせで新規に必要と確認・含める決定。子PR・設計docにまだ存在しない完全な新規領域。
入れないと
どこからの登録かが分からず、施策の効果測定ができない。
判断メモ
設計・実装がまだ無いため、優先して仕様策定が必要。

分析ダッシュボードシナリオ単位・07-08確定

確定:入れる

シナリオごとに 開封率・クリック率・登録解除率 を可視化する。UTAGE は配信単位だが、本機能はシナリオ単位で見せる方針。

論点
07-08 打ち合わせで最低限必要な指標として含める決定。現状の子PRには無い新規領域。
入れないと
配信効果が測れず、改善サイクルが回らない。
判断メモ
下の「開封・クリック計測」が前提。タグ設定は不要(ログの集計で「どのステップまで見たか」が出せる)。分析ページの見せ方は Mock で先に設計。

開封・クリック計測トラッキング基盤・07-08確定

確定:入れる

トラッキングピクセルで開封、短縮URLでリンククリックを計測する。

論点
閲覧状況把握の土台SendGrid の開封トラッキング機能を活用でき、実装負荷は低いと確認済み。#3511 の送信ログに開封/クリックを紐づける。
入れないと
開封率・クリック率が出せず、分析が成立しない。
判断メモ
設定不要で自動に溜まる方式。タグ運用なしで「どのステップまで見たか」が分かる=ユーザーに優しい。分析の土台として確定。

置換文字の拡張会社情報・振込先・07-08確定

確定:入れる

名前だけでなく 会社情報・振込先などを置換文字で本文に差し込む

論点
特商法表記・請求導線に必要。「メールテンプレート・置き換え文字」として含める決定。
入れないと
会社情報・振込先を本文に差し込めない。
判断メモ
既存の置換文字の仕組みに項目を追加する形。

本文内の画像挿入07-08確定

確定:初期スコープ外

プレーンテキスト方針だが、本文に画像を差し込めるようにする。※独立の画像ブロック(見送り)とは別。

論点
07-08 決定で「HTMLメール・画像ブロック」は初期スコープ外と確定。プレーンテキストでは本文内へのインライン画像埋め込みは不可(添付は別途検討)。
入れないと
本文中に画像を差し込めない(添付での代替は要検討)。
判断メモ
HTMLメール自体が初期スコープ外のため連動して見送り。

登録禁止アドレス再送防止リスト・07-08追加

要確認

解除者・不達アドレスを登録禁止リストに入れ、再登録・再送を防ぐ

論点
MyASP は解除時に自動追加。到達率・オプトアウトと連動。
入れないと
解除者・不達に送り続け、到達率悪化・クレームのリスク。
判断メモ
バウンス処理(見送り)と合わせて最低限を検討。

登録時の自動返信・ダブルオプトインMyASP・07-08追加提案

要確認

登録フォーム送信直後にサンキュー/確認メールを自動返信し、必要ならダブルオプトイン(本人確認)を行う。

論点
MyASP 標準。リスト作成(登録フォーム)と対。到達率・本人確認・法令面で効く。
入れないと
登録直後の自動フォローや本人確認ができない。
判断メモ
リスト作成ウィジェットとセットで検討。

行動トリガー開封/クリックで自動タグ・分岐・07-08追加提案

要確認

開封・クリックなどの反応に応じてタグを自動付与し、シナリオを分岐する(反応した人だけ次を送る等)。

論点
タグは「閲覧状況の把握」には不要(それはログ集計で出せる)。タグが要るのは宛先を絞る・反応で分岐するというアクション側の用途のみ。
入れないと
反応ベースの出し分けができず、一律配信のみになる。閲覧状況の把握自体は影響なし。
判断メモ
効果は大きいが実装重め。開封・クリック計測が前提。まず計測を入れてから段階導入も可。

共通フッターの自動挿入会社情報・解除リンク・07-08追加提案

要確認

全配信メールに会社情報・特商法表記・配信解除リンクを自動付与する共通フッター。

論点
07-08 で「配信停止リンクは必須」と確定済み(下の裏側処理カード参照)。フッター全体の自動化までを今回の範囲に含めるかは未決。
入れないと
各メールに手動でフッターを書く必要/付け忘れのリスク。
判断メモ
オプトアウト(確定・必須)・置換文字拡張(確定)と合わせて設計。

カスタム検索一覧/フォルダ/対象者一覧

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

論点
専用モデル(custom_searches / folders)をゼロから新設。既存の対象抽出ロジックが LINE 前提で account / MarketingUser への移植が重い。設計docでも目的・完了条件が未確定
入れないと
複雑なセグメント配信・保存条件の使い回しができない。
判断メモ
配信条件モーダルのタグ指定で最低限の絞り込みは可能。第2弾で本実装。

一斉送信

確定:入れる

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

PR
#4747 · 設計書のみ
論点
07-08 打ち合わせでリリーススコープに含める決定
入れないと
都度の告知メール等、シナリオを介さない一括送信ができない。
判断メモ
一気に送るとドメインが汚れやすいため、送信レート制限(確定)とセットで実装する。MyASP の速度調整仕様を参考にする。

CSV エクスポート

確定:初期スコープ外

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

PR
#4752 · 設計書のみ
論点
07-08 で初期スコープ外と確定(必要時はシステム側で対応する運用)。
入れないと
読者リストや配信結果を書き出せない。他ツール連携・バックアップ不可。
判断メモ
ユーザー向け機能としては見送り。運用者が必要なら開発側で個別対応。

リスト作成ウィジェット

要確認

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

論点
設計docに記載がなく未定義。読者の取り込みは CSV/読者 CRUD のみが対象。
入れないと
外部からの自動的な読者獲得(自己登録)ができない。
判断メモ
当面は CSV・手動登録で対応。獲得導線が要るなら別途設計。

同一メールアドレスの統合顧客一覧

確定:初期スコープ外

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

PR
#4751 · 設計書のみ
論点
07-08 で初期スコープ外と確定。「顧客管理は統合(リスト単位で一元管理)」という新アーキテクチャを踏まえ、重複統合機能は次フェーズで再検討。
入れないと
重複登録で同じ人に複数通届く/手動整理が必要。到達率・体験に影響。
判断メモ
まず取込時の重複チェック(#3534)で最低限を担保。統合UIは初期スコープ外。

画像ブロック

確定:初期スコープ外

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

論点
07-08 で「HTMLメール・画像ブロック」は初期スコープ外と確定。プレーンテキスト方針とも整合。
入れないと
画像主体のステップを組めない。
判断メモ
HTMLメール解禁の要否とセットで次フェーズ以降に再検討。

メールテンプレート

確定:入れる

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

PR
#4748 · 設計書のみ
論点
07-08 で「メールテンプレート・置き換え文字」として含める決定(拡充版も対象)。
入れないと
テンプレートの一覧管理・使い回しがしづらい(都度コピペ)。
判断メモ
基本保存・管理拡充とも今回入れる。

配信条件のタグ絞り込み詳細

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

論点
「全員配信=条件空」で最低限成立するため、細かい条件は後付け可能。
入れないと
初期は「全員 or 単純なタグ指定」止まり。複雑な条件は不可。
判断メモ
条件エンジンは既存流用なので後から段階的に拡張できる。

タグの作成・付与

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

論点
設計のスコープ外。既存マーケティングタグを「参照する」前提で作成・付与UIは作らない。
入れないと
ステップメール画面からタグを新規作成・付与できない(既存タグは参照可)。
判断メモ
既存のタグ管理機能で付与。必要なら導線を後付け。

ステップ単位のテスト配信

確定:入れる

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

論点
07-08 で方針が逆転:個別(ステップ単位)のテスト送信を含めるシナリオ全体一括テストは不要と確定。旧版の「テスト送信(シナリオ全体一括)」の位置づけを差し替え。
入れないと
特定ステップだけを単独で確認できない。
判断メモ
設計docには元々記載がなかったため、新規に仕様策定が必要。

初回アンケート設定

確定:入れる

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

PR
#4749 · 設計書のみ
論点
07-08 で含める決定(タグ付与との連携も含む)。既存 Survey が line_user 前提のため再設計は必要。
入れないと
アンケート回答を起点にした出し分けができない。
判断メモ
タグ付与と連携する形で設計する。

AI 自動生成

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

論点
別リポジトリの先行実装を流用できるかの「調査フェーズ」段階で API 仕様が未確定。
入れないと
文面は手動作成のみ。配信機能自体には影響なし。
判断メモ
調査完了後に仕様確定してから。

シナリオのコピー機能

確定:後回し

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

論点
07-08 で「希望はするが優先度は低く後回し」と確定。今回のリリースには含めない。
入れないと
毎回ゼロから作成する必要がある。
判断メモ
次フェーズ以降で運用が増えて手間が顕在化したら着手。

メールプレビュー

なし

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

論点
設計上サーバー実装は対象外。フロント表示のみで完結する想定。
入れないと
なし(フロント側の表示範囲で対応)。
判断メモ
今回の実装対象外。追加開発は不要。

裏側処理 設計時点で「スコープ外」とされた配信基盤の処理(初期設計・未見直し)

shwld さんの初期設計(2026-03)でスコープ外とし、以降見直されていない配信基盤まわり。ここも今回対応するかを下のカードで仕分ける(集計は上のバーに合算)。

配信停止(オプトアウト)最小版

確定:必須

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

PR
#4746 · 設計書+BE実装進行中
論点
初期設計ではスコープ外だったが、07-08 で「必須。メール内に含めないと信用低下につながる」と確定。
入れないと
受信者が自分で配信を止められない(クレーム・法令面・信用低下のリスク)。
判断メモ
実装進行中。必須のため優先してマージ。

配信設定(購読解除フル版・時間帯・通知)

要確認

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

PR
#4750 · 設計書のみ
論点
オプトアウト最小版(#4746)の先の拡充版
入れないと
時間帯指定・通知・詳細な購読管理ができない。
判断メモ
最小版で足りるか、フル版まで今回入れるか。

バウンスメール処理

要確認

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

論点
初期設計でスコープ外。送信エラー管理(#3511)でどこまで拾えるか要確認。
入れないと
無効アドレスに送り続け、送信レピュテーション・到達率が悪化する恐れ。
判断メモ
#3511 のカバー範囲を確認の上で要否判断。

送信元メールアドレスの管理

要確認

送信元ドメイン/アドレスの検証フロー(SES/DKIM)

論点
初期設計でスコープ外。DKIM 導線(#3502)との切り分けを確認。
入れないと
送信元の検証・管理が不十分だと到達率に影響。
判断メモ
#3502 でどこまでカバーされるか確認。

送信レート制限スパム対策

確定:入れる

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

論点
07-08 で含める決定。「一斉配信を一気に送るとスパム認定リスクがある」ため、特にドメイン保護の観点で重要。
入れないと
一斉配信を一気に送るとスパム/ブロック・遅延のリスクでドメインが汚れやすい。
判断メモ
MyASP は 1万人規模でデフォルト分散送信する仕様。MyASP の速度調整仕様を参考に設計する(加藤氏 07-08 アクションアイテム)。

送信アクションの実行詳細・置換処理

要確認

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

論点
design.md では「別途検討中/スコープ外」。実配信の心臓部。07-08 でも「内容が不明瞭なため未分類」と明示的に保留された。
入れないと
本番配信が成立しない可能性。
判断メモ
選択というより実装状況の確認事項。現状どこまで動くか要確認(未確定事項として次回持ち越し)。

今回は入れない MyASP にはあるが、今回は考慮しない機能

MyASP のマニュアルを洗い出す過程で見つかったが、影響が小さい・現時点でニーズが見えないため今回のリリースでは入れないと判断(会議での仕分け対象には含めない)。将来ニーズが顕在化したら再検討。

件名 A/B テスト 見送り 開封率の最適化機能。まず分析(開封率計測)自体が無いため前提が整っていない。
配信停止理由アンケート 見送り MyASP: メール配信後の配信解除 ↗ 解除時にアンケートを挟む機能。解除率の分析より優先度が低い。
迷惑メール判定(到達性)チェック 見送り MyASP: 迷惑メール関連 ↗ 送信前のスパム判定シミュレーション。SendGrid側の基本対策(DKIM等)で当面は代替。
予約配信の一時停止・キャンセル 見送り 一斉送信自体が今回まだ仕分け中の機能のため、その先の運用機能は対象外。

04 マージの進め方(BE 中心。FE は新デザインで作り直し)

07-08 の方針転換により、以下は BE(API)ロジックのレビュー→マージが中心。FE 画面は新デザインでの作り直しが前提のため、まず加藤氏のモック検証を経てから着手する。

#3511 + #4737(送信管理API + エラー画面)をセットでレビュー → マージ

API と画面が対になるため一緒に通す。#3511 は送信管理の土台で、レビューが停滞しているクリティカルパス。まずここを動かす。

#3534 + #4702(CSV API + インポート画面)をセットでレビュー → マージ

#3534 はレビュー指摘対応済み。#4702 は Draft のため、Ready 化してからセットで通す。

#4703(再送防止)を Ready 化 → マージ

#3511 非依存で単独マージ可能。Draft 解除とレビューだけ。SendGrid 制限対策として今回に含める方針。

#3502(DKIM 導線)は並行でレビュー

単独マージ可能な FE。#3502 は必須。

全子PRマージ後、#3206 で develop へ一括投入

develop 同期(#4709)後の統合ブランチへ、各子PRのコンフリクト追従を済ませてから。

並行:加藤氏がモックを作成 → 事前共有 → 打ち合わせで操作性を検証

新デザインの UX・迷わない動線を優先(デザイン性は二次的)。事前に触ってもらってから打ち合わせを設定する。あわせて MyASP の UI を確認し、参考にできる点を整理する(UI 自体は洗練されていないが機能は揃っている)。

05 未確定事項

審査 補助金審査の範囲 — 見積書と開発機能の一致をどこまで確認されるかが未確定。斉藤氏(補助金担当)への確認待ち。
期限 リリース期限 — 理想は9月末、遅くとも10月中旬が限界。補助金申請の12月末期限から逆算。
要確認 タグによる絞り込み機能が現状実装されているか未確認(本資料の「入れる確定」記載が誤りの可能性あり)。上のリストにも警告マークを付記済み。
要確認 送信アクション実行詳細StepMailDelivery#perform!)— 内容が不明瞭なため未分類のまま。実配信の心臓部なので優先的に確認したい。

06 オープンな課題

再洗い出し MyASP の主要利用機能を参考に、最低限必要な機能の洗い出しを再実施する必要がある。
ヒアリング 田中氏(実際のメール配信利用者)にヒアリングし、必須機能の優先度を確認する。
方針 競合の「宴」ではなく、MyASP をベンチマークとして重視する方針。

07 アクションアイテム

加藤氏 新デザインに基づいたモックを作成し、事前共有後に打ち合わせを設定する(操作性重視、デザイン性は二次的)。
加藤氏 MyASP の UI を確認し、参考にできる点を整理する。
山田氏 補助金担当者(斉藤氏)に、見積書・機能・納品期限の確認範囲をヒアリングし、スレッドに報告する。
Keita氏 補助金審査用に、自社アカウントのみでメールステップ配信が閲覧できる状態を準備する(未リリースの状態でも審査対応可能にする)。