1. 目的
STEPmini V1.01 は、従来の STEPmini V1.0 にあった
- バッチ未実行日の取りこぼし
- 完全一致日のみ送信される硬い運用
を改善し、過去日付で未送信のstepがあれば順番に救済送信できるようにしたバージョンです。
2. V1.0 の課題
V1.0 では、顧客ごとの経過日数 elapsed を計算し、steps.date_from_start と 完全一致したstepだけを送信していました。
V1.0 の問題点
- バッチを毎日回さないと、その日のstepを取りこぼす
- 一度取りこぼしたstepは後から送られない
- 手動運用やトリガー停止時に弱い
3. V1.01 の基本思想
V1.01 では、送信判定を次の考え方に変更します。
- 今日までに送るべきstep
- まだSUCCESSになっていないstep
- その中で最も古いstepを1件だけ送る
これにより、取りこぼしがあっても、次回以降の実行で順番に追回しできます。
4. 対象シート
V1.01 で使用するシートは以下の5つです。
元コードでもこの5シート前提です。
settingscustomersscenariosstepslogs
5. 各シートの役割
5-1. settings
システム全体の送信設定を保持するシートです。
主な項目例
from_namefrom_addressreply_tosignatureglobal_activetest_email
V1.0 の送信処理では、特に以下を使用していました。
reply_tofrom_namesignatureglobal_active
5-2. scenarios
シナリオ単位の有効・無効を管理するシートです。
想定列
- A列：
scenario_id - C列：
active
V1.0 では active=TRUE のものだけ有効シナリオとして読み込んでいました。
5-3. steps
各シナリオで何日後に何を送るかを定義するシートです。
想定列
- A列：
scenario_id - B列：
step_no - C列：
date_from_start - D列：
enabled - E列：
subject - F列：
body - G列：
send_time
V1.0 では enabled=TRUE の行だけを取り込み、scenario_id ごとに stepsMap を作っていました。
5-4. customers
顧客ごとの開始日・停止フラグ・シナリオ番号を保持するシートです。
想定列
- A列：
customer_id - B列：
name - C列：
company - D列：
email - E列：
start_date - F列：
tag - G列：
stop_flag - H列：
memo - I列：
scenario_id
5-5. logs
送信結果の履歴を保持するシートです。
想定列
- A列：送信日時
- B列：customer_id
- C列：email
- D列：scenario_id
- E列：step_no
- F列：result
- G列：error_message
- H列：備考
V1.0 では result === "SUCCESS" のものを再送防止判定に使用していました。
6. V1.01 の送信判定仕様
6-1. 顧客の基本チェック
顧客ごとに以下を確認します。
- email が存在し、メール形式らしいこと
- start_date があること
- stop_flag が TRUE ではないこと
- scenario_id があること
- scenario が active であること
これらの基本チェックの考え方は V1.0 を踏襲します。
6-2. elapsed の意味
elapsed は、start_date から今日までの経過日数です。
V1.0 でもこの式で計算していました。
例
- start_date = 2026/4/29 → elapsed = 0
- start_date = 2026/4/28 → elapsed = 1
- start_date = 2026/4/27 → elapsed = 2
6-3. V1.01 の送信対象step
V1.01 では、対象stepを次の条件で抽出します。
step.days <= elapsed- まだ
logsにSUCCESSがない - scenario_id が顧客の scenario_id と一致する
- step が enabled = TRUE
つまり、今日までに送るべきだった未送信step が対象です。
6-4. 1回の実行で送る件数
V1.01 では、1顧客につき1回の実行で送るstepは 1件だけ です。
対象stepが複数ある場合は、
date_from_startが最も小さいもの- 同日なら
step_noが小さいもの
を優先します。
つまり、最も古い未送信stepを1件だけ送る仕様です。
6-5. 同一顧客への1日1通制限
V1.01 では、同一メールアドレスに対して 同じ日に複数通送らない ようにします。
そのため、logs の SUCCESS を見て、
- 今日すでに送信済みの email
は、その日は追加送信しません。
7. V1.01 の動作例
条件
steps が以下の場合
- step1 = 0日後
- step2 = 1日後
- step3 = 2日後
ケース1：通常運用
- 4/29 実行 → elapsed=0 → step1送信
- 4/30 実行 → elapsed=1 → step2送信
- 5/1 実行 → elapsed=2 → step3送信
ケース2：3日止まった
- 4/29〜5/1 未実行
- 5/2 実行 → elapsed=3
V1.0 なら対象ゼロでした。
V1.01 では
- 未送信の step1 を送信
翌日実行で
- 未送信の step2 を送信
さらに翌日実行で
- 未送信の step3 を送信
となります。
8. ログ仕様
V1.01 では、原因調査しやすいようにログを強化します。
主な出力内容
settings全体global_active rawglobal_active typequotacustomer checkelapsedscenarioStepsdueStepssend successsend errorskip: ～
skipログ例
skip: email不正skip: startDateなしskip: stopFlag=trueskip: scenarioIdなしskip: scenarioが非アクティブskip: stepsなしskip: 送るべき未送信stepなしskip: 本日すでに送信済み
9. V1.01 のメリット
9-1. 取りこぼし救済
バッチ停止や手動実行漏れがあっても、後から追回しできます。
9-2. 順番維持
過去stepを一度に全部送らず、最古stepから順に送るため、流れが崩れにくいです。
9-3. 暴発防止
同一顧客に1日1通だけなので、同日に何度実行しても安全性が高いです。
9-4. 実務向け
完全一致仕様よりも現場運用に向いています。
10. V1.01 の注意点
10-1. 追いつくまで日数がかかる
過去未送信stepが3件あれば、3日かけて順番に追回しします。
10-2. 即時一括送信はしない
意図的に1日1通にしているため、遅れを一気に取り戻す設計ではありません。
10-3. logs が重要
SUCCESS 判定は logs に依存するため、logs を消すと再送判定が崩れます。
11. 運用ルール
V1.01 の推奨運用は以下です。
- バッチは基本的に毎日1回実行
- ただし未実行日があっても追回し可能
- 同一顧客への重複送信を防ぐため logs は保持する
- steps は
enabled=TRUEを明示 - scenarios は
active=TRUEを明示 - customers は
scenario_idを必須とする
12. V1.0 との違いまとめ
V1.0
step.days === elapsedの完全一致- 取りこぼし救済なし
- 運用が止まると送信漏れが残る
V1.01
step.days <= elapsedの未送信stepを対象- 最も古い未送信stepを1件送信
- 1日1通制限あり
- 送信漏れを順次追回し可能
13. バージョン位置づけ
- V1.0
完全一致型の初期版 - V1.01
運用安定化版
過去日付未送信救済、1日1通制御、ログ強化 - V1.1
別途計画済みの次期機能拡張版
14. 補足
元コードでの基本構造は以下でした。
- settings取得
getSettings(sheetSettings) - global_active 判定
- active scenario 抽出
- enabled step 抽出
- SUCCESS 再送防止キー作成
- elapsed 計算
- 完全一致判定
- sendEmail 実行
コメント