ステップ配信を止めたのに配信が届く原因｜タグ解除だけでは走行中のシナリオは止まらない
ステップ配信を止めたのに配信が届く原因｜タグ解除だけでは走行中のシナリオは止まらない
LINE公式アカウントの運用で、こういう問い合わせを受けることがあります。
- キャンセルした人にリマインドが届き続けている
- 配信対象のタグを外したのに、翌日のステップ配信が普通に届いた
- 設定を見直しても、どこにも「配信する」設定は残っていないように見える
先に結論を書きます。
ステップ配信は、タグを外しても止まりません。 これは設定ミスでもツールの不具合でもなく、多くの配信ツールに共通する仕様です。ステップ配信（シナリオ配信）は「登録された瞬間に走り出す時限式の予約配信」で、走り出した後の配信予定は、登録のきっかけになったタグとはもう切り離されています。タグは入口の条件であって、走行中の配信を制御するスイッチではないのです。
止めたいなら、止め方を設計する必要があります。この記事では、実際に構築したウェビナーのリマインド配信で「キャンセルした人に視聴URLが届かない」ことを検証まで含めて確認した設計を、そのまま使える形で書きます。
なぜタグを外しても配信が届くのか
ステップ配信の仕組みを電車に例えると分かりやすくなります。
タグの付与は「乗車券の発行」です。乗車券を持った人が改札を通ると（＝シナリオに登録されると）、電車は発車します。1通目は3日後、2通目は7日後、という時刻表どおりに配信が予約されます。
ここで乗車券（タグ）を回収しても、すでに発車した電車は止まりません。 シナリオ登録の時点で配信予定が確定しているため、その後にタグを外しても、予約済みの配信は予定どおり実行されます。
「タグを外せば配信されなくなる」が通用するのは、一斉配信でタグを絞り込み条件に使っている場合だけです。一斉配信は送信の瞬間に条件を評価しますが、ステップ配信は登録の瞬間に評価します。この違いを知らないまま運用すると、キャンセル処理を「タグ解除」だけで作ってしまい、止めたはずの配信が届き続けます。
正しい停止設計は「配信ステップ側の絞り込み」
では、どう設計するのが正しいか。答えは配信する側のステップに「タグを持っている人にだけ送る」という絞り込み条件を入れることです。
多くの配信ツールには、シナリオ内の各ステップに配信対象の絞り込み条件（フィルタ）を設定する機能があります。ここに「予約タグを保持している人のみ」という条件を入れておくと、配信の実行タイミングでタグの有無が再評価されます。つまり、
- 予約時：タグ付与 → シナリオ開始
- キャンセル時：タグ解除
- 配信時刻が来る → タグが無いので配信対象0人 → 届かない
という流れが成立します。走行中のシナリオ自体は止まっていなくても、配信の瞬間に対象から外れるので、実害が出ません。
この設計にはもうひとつ利点があります。キャンセル処理側の実装が「タグ解除」だけのシンプルな形で済むことです。停止処理の抜け漏れがあっても、配信側のフィルタが最後の砦として機能します。
「シナリオ停止アクション」に頼り切らない
ツールによっては、キャンセル時のアクションとして「シナリオ停止」を実行できるものもあります。あれば併用してかまいません。ただし、これを唯一の停止手段にするのは避けたほうがいいです。
理由は2つあります。ひとつは、ツールによって停止できる単位が違うこと。特定のシナリオだけを狙って止められるものもあれば、その友だちに走っている配信を全部止めることしかできないツールもあります。後者の場合、別のシナリオ（たとえば購入後のフォロー配信）まで巻き添えで止まるため、キャンセル処理には使えません。実際、あるツールでは仕様書上「停止」とあるだけで、実機で確認すると全停止しかできず、停止アクション前提の設計を絞り込み方式へ組み直すことになりました。
もうひとつは、停止処理は実行されなければ意味がないこと。キャンセル導線を通らずに離脱した人、処理が何らかの理由で失敗したケースには効きません。配信側の絞り込みは配信のたびに毎回評価されるので、この取りこぼしを拾えます。
停止アクションは補助、絞り込み条件が本体。 この順番で設計しておくと安全です。
実例：ウェビナーリマインドのキャンセル導線
教育系のクライアントで、3日間のオンラインウェビナーのリマインド配信を構築したときの実例です。参加者は12時・18時・21時の3枠から視聴時間を選び、選んだ枠の開始1時間前と5分前にリマインドが届きます。5分前の配信には視聴URLが入っています。3日間×3枠で、シナリオは合計9本です。
ここで一番やってはいけないのは、キャンセルした人に視聴URLが届くことです。キャンセルしたつもりの人にURL付きリマインドが届き続けると、ユーザー体験が悪いだけでなく、「本当にキャンセルできたのか」という問い合わせが運用側に返ってきます。
設計は次のとおりにしました。
- 予約時：時間帯タグを付与 → 該当枠のシナリオを開始
- 時間変更時：選ばなかった同日の他の時間帯タグを解除 → 選んだタグを付与 → 新しい枠のシナリオを開始
- キャンセル時：同日の時間帯タグを全部解除 → キャンセルタグを付与 → 再予約案内を送る
- 9本すべてのシナリオ：1時間前・5分前の配信ステップに「該当の時間帯タグ保持者のみ」の絞り込み条件を設定。絞り込みなしで全員に送るトラックは0件にする
検証では、テストユーザーでキャンセル操作をした直後に管理画面で5分前ステップの配信対象者数を確認し、0人になっていることを見ました。配信予定時刻を待たずに「届かない」を確認できるのがこの方式の良いところで、本番のタイミング設定を書き換えずに検証が完結します。あわせて、12時→18時→21時と時間変更を繰り返しても時間帯タグが常に1本だけ残ることも確認しています。タグが2本残ると2枠分のリマインドが届くので、ここも配信事故の芽になります。
設計時に潰しておきたい3つの落とし穴
同じ仕組みを組むときに起こりやすいリスクを、予防策とセットで挙げておきます。
1. アクションの実行順序でタグが消える
予約変更の処理を「全タグ解除 → 選択タグ付与」の順で組むと安全に見えますが、ツールのアクション実行順によっては、付与したばかりの選択タグを後続の解除処理が消してしまう構成になりえます。安全なのは「選ばなかったタグだけを個別に解除 → 選択タグを付与」という組み方です。最終状態は同じでも、途中経過に「タグ0本」の瞬間を作らないことが事故防止になります。
2. タグ付与よりシナリオ開始が先に並んでいる
「タグ付与 → シナリオ開始」の順序が正しく、逆だと危険です。シナリオ側の絞り込み条件は評価の瞬間のタグを見るため、タグが付く前にシナリオが動き出す構成だと、条件評価のタイミング次第で配信されない・されるが不安定になります。ボタンひとつに複数アクションを積むときは、条件判定に使う情報を先に確定させてから、それを参照する処理を並べるのが原則です。
3. タグ解除の後ろに、タグを条件にした処理が残っている
キャンセル処理の中で「タグ解除」を先頭に置き、その後ろに「タグを持っていたら◯◯する」という条件付きアクションを並べると、条件は解除後の状態で評価されるため一度も成立しません。多くのツールでは、条件はそのアクションが実行される瞬間の値で評価されます。解除は必ず一連の処理の最後に置きます。
止まらない配信に気づいたときの確認手順
すでに運用中の配信で「止めたのに届く」が起きている場合は、次の順で見てください。
- 届いた配信の送信元を特定する。一斉配信かステップ配信かで対処が変わります。配信履歴やチャットログの詳細から、どのシナリオ・どのテンプレートから送られたかを確認します
- そのステップに絞り込み条件があるか見る。条件なしで「登録者全員」に送る設定なら、それが原因です
- 絞り込み条件を追加し、全員配信のトラックを空にする。既存の配信内容は絞り込み側へ載せ替えます
- テスト用の友だちでキャンセル→対象者数0人を確認する。配信時刻を待たず、管理画面の対象者数で検証できます
まとめ
- ステップ配信は登録の瞬間に走り出す。タグ解除では走行中のシナリオは止まらない
- 停止は「配信ステップ側の絞り込み条件」で設計する。配信の瞬間にタグの有無が再評価されるため、キャンセル処理がタグ解除だけでも確実に止まる
- シナリオ停止アクションは補助として使う。個別停止ができないツールもあり、停止処理の実行漏れも絞り込みが拾ってくれる
- アクションは「条件に使う情報を先に確定 → 参照する処理 → 解除は最後」の順に並べる
- 検証は配信を待たなくていい。キャンセル直後の配信対象者数が0人かを見れば、その場で確認できる
ステップ配信の「止める側」の設計は、組むときには忘れられがちで、事故が起きてから気づくことが多い部分です。予約やキャンセルのある業態（サロン・スクール・ウェビナー運営など）でLINEの自動配信を組むなら、開始の導線とセットで停止の導線まで設計しておくことをおすすめします。