1. STEPmini はどう動くのか
STEPmini は、問い合わせが来た人を customers シートに登録し、その人に対して「どのシナリオを、いつから開始するか」を決めると、あとはバッチ処理が毎日見に行って、送るべき日になったメールだけを送る仕組みです。
動き方はとてもシンプルです。
customersに顧客を登録する- その顧客に
scenario_idを設定する startDateを入れる- バッチが「今日が何日目か」を計算する
steps.daysと一致したメールを送る- 結果を
logsに残す
つまり、STEPmini は
「顧客ごとに、開始日から何日経ったか」で送信を判断する仕組み
です。
2. このGASで使っているシート
customers
GASでは customers の各行から、次の位置で値を読んでいます。
row[1]= namerow[2]= companyrow[3]= emailrow[4]= startDaterow[5]= scenarioIdrow[6]= stopFlag
つまり、ヘッダー行の次のデータ行から見て、実質的には以下のような列構成で使う前提です。
- A列:未使用または任意
- B列:名前
- C列:会社名
- D列:メールアドレス
- E列:開始日
- F列:シナリオID
- G列:停止フラグ
ここが 初心者向けに最重要 です。
この6項目が正しく入っていれば配信が回ります。
scenarios
GASでは scenarios から、
row[0]= scenarioIdrow[2]= active
を見ています。
つまり、1列目がシナリオID、3列目が有効/無効です。
ここで有効になっている scenarioId だけが配信対象になります。
steps
GASでは steps から、
row[0]= scenarioIdrow[1]= stepNorow[2]= daysrow[3]= enabledrow[4]= subjectrow[5]= body
を読み込んでいます。
つまり、steps は
「どのシナリオの何通目を、開始日から何日後に送るか」
を定義するシートです。
logs
GASでは logs から送信済み判定を作っています。
row[2]= emailrow[3]= scenarioIdrow[4]= stepNorow[5]= result
ここで result === "SUCCESS" のものを送信済みとみなし、
同じ email + scenarioId + stepNo は再送しません。
settings
settings は getSettings() で
1列目をキー、2列目を値として連想配列にしています。
特に使っているのは次です。
global_activesignaturereply_tofrom_name
3. 最初にやる準備
初心者の方は、まず次の順番で準備してください。
手順1:settings を入れる
最低限、次を設定します。
global_active= TRUEfrom_name= 送信者名reply_to= 返信先メールアドレスsignature= メール末尾の署名
特に global_active が TRUE でないと、GASは最初に「配信停止中」で終了します。
手順2:scenarios を1本だけ作る
初心者は最初から複数シナリオを作らず、まず1つだけ作るのが安全です。
例:
- A列:SC001
- B列:STOCKmini問い合わせフォロー
- C列:TRUE
この状態で、SC001 が有効シナリオになります。
手順3:steps を5件作る
例題として、5ステップの問い合わせフォローを作ります。
例:SC001 の5ステップ
1通目
- scenarioId:SC001
- stepNo:1
- days:0
- enabled:TRUE
- subject:お問い合わせありがとうございます
- body:{name} 様\nお問い合わせありがとうございます…
2通目
- scenarioId:SC001
- stepNo:2
- days:1
- enabled:TRUE
- subject:STOCKminiでできること
- body:{name} 様\n今日は概要をご案内します…
3通目
- scenarioId:SC001
- stepNo:3
- days:3
- enabled:TRUE
- subject:基本的な使い方
- body:{name} 様\n使い始めの流れをご紹介します…
4通目
- scenarioId:SC001
- stepNo:4
- days:5
- enabled:TRUE
- subject:よくあるつまずき
- body:{name} 様\n初心者が迷いやすい点をまとめました…
5通目
- scenarioId:SC001
- stepNo:5
- days:7
- enabled:TRUE
- subject:ご不明点があればご相談ください
- body:{name} 様\n質問がありましたらこのメールに返信してください…
差し込みについて
本文と件名では replaceTemplate() により、
{name}{company}
が置換されます。
ですので、本文に {name} を入れておくと「山田様」などに変わります。
手順4:customers に顧客を入れる
問い合わせが来たら、customers に1行追加します。
例:1件目
- B列 name:山田太郎
- C列 company:株式会社サンプル
- D列 email:yamada@example.com
- E列 startDate:2026/04/29
- F列 scenarioId:SC001
- G列 stopFlag:FALSE
これで、山田さんは SC001 の配信対象になります。
例:2件目
- B列 name:佐藤花子
- C列 company:合同会社テスト
- D列 email:sato@example.com
- E列 startDate:2026/04/29
- F列 scenarioId:SC001
- G列 stopFlag:FALSE
これで2件目も同じシナリオに乗ります。
問い合わせが1件でも2件でも問題なく動く理由は、顧客ごとに startDate と scenarioId を持っているからです。
4. 実際の送信判定の仕組み
このGASは、各顧客について次のように判定しています。
todayを0時にそろえるstartDateも0時にそろえるelapsed = today - startDate の日数step.days == elapsedのものだけ送る
たとえば startDate が 2026/04/29 の場合、
- 0日後 → 4/29 に送る
- 1日後 → 4/30 に送る
- 3日後 → 5/2 に送る
- 5日後 → 5/4 に送る
- 7日後 → 5/6 に送る
という動きになります。
5. 送信を止めたいとき
全体停止
settings.global_active を FALSE にすると、全体の配信が止まります。
個別停止
customers の stopFlag を TRUE にすると、その顧客だけ止まります。
GASでは stopFlag === true || stopFlag === "TRUE" のときスキップします。
つまり、
- 一時的に全員止めたい → settings
- この人だけ止めたい → customers
です。
6. どのシートをどう見ればよいか
ふだん一番見るのは customers
問い合わせが来たら、ここに登録します。
初心者の方はまずここだけ確実に見れば大丈夫です。
確認ポイントは次です。
- メールアドレスが正しいか
- 開始日が入っているか
- シナリオIDが入っているか
- stopFlag が TRUE になっていないか
送れたかどうかは logs
logs は「結果確認用」です。
バッチ実行後に、ここを見れば分かります。
- 送れた →
SUCCESS - 失敗した →
ERROR - エラーメッセージも保存される
つまり、初心者の運用は
customers で登録し、logs で結果を見る
これが基本です。
内容を変えるときだけ steps
件名や本文を直したいときは steps を見ます。
日常的には毎日いじる必要はありません。
シナリオを有効/無効にしたいときだけ scenarios
使わないシナリオを止めたいときは、3列目の active を FALSE にします。
全体停止や署名変更は settings
署名や返信先、送信者名を変えるときは settings を見ます。
7. 初心者が間違えやすい点
1. startDate を入れ忘れる
これが空だと送信されません。
GASは if (!startDate) return; でスキップします。
2. scenarioId が合っていない
customers の scenarioId が、scenarios や steps と一致していないと送られません。
3. global_active が FALSE
設定を忘れると、全員に送られません。
4. steps.enabled が TRUE でない
そのステップは無効扱いになります。
5. stopFlag を TRUE にしている
顧客単位で止まります。
6. email が正しくない
GASは @ が入っていないアドレスを送信対象から外します。
8. この実装での正しい理解
このSTEPmini V1.0 は、顧客ごとに「次回送信日」を持つ方式ではありません。
開始日からの経過日数ベース です。
ここはかなり重要です。
つまり、運用者は
- 顧客登録時に開始日を入れる
- steps に何日後送信かを書いておく
この2つを守ればよいです。
逆に言うと、
「個別に次回日を手で持つ」タイプではないので、初心者でも管理が崩れにくいです。
9. 実装を見て補正した結論
今回GASを見たことで、前回のガイドは次のように修正されます。
修正して確定したこと
- 顧客管理の要は
customersの D〜G相当の列 - シナリオ有効判定は
scenariosの3列目 - ステップ管理は
stepsの 1〜6列 - 送信判定は
開始日からの経過日数 - 再送防止は
logsの SUCCESS 判定 - 顧客IDは現行バッチでは未使用
- 差し込みは
{name}{company}の2種類のみ
ですので、今後の初心者向け仕様書は
「問い合わせが来たら customers に登録し、開始日とシナリオIDを入れるだけで流れる」
という説明を中心にすると、実装と完全に合います。





コメント