ステップ配信が失敗する5つのパターン｜どの通で離脱しているかを配信ログで特定する
ステップ配信が失敗する5つのパターン｜どの通で離脱しているかを配信ログで特定する
「ステップ配信を組んだのに予約が増えない」「配信のたびにブロックが増える」。こうした相談で中身を見せてもらうと、原因が配信文のうまい下手だったことはほとんどありません。壊れているのはたいてい、文面より手前の設計と、公開したあとの運用です。しかも失敗の型は決まっています。
先に結論です。ステップ配信の失敗は、次の5つのパターンに集約されます。
| # | 失敗パターン | 起きること |
|—|—|—|
| 1 | 出口を設計していない | 用が済んだ人に配信が届き続け、ブロックが増える |
| 2 | ツールの停止・判定の仕様を確かめずに設計する | 「止めたつもり」の配信が止まらない。条件分岐が想定と違う動きをする |
| 3 | 相手の状態をシナリオの本数で管理する | 分岐が爆発し、作った本人も追えなくなる |
| 4 | 絞り込みなしで公開する・移行を中間状態で放置する | 対象外の人に配信が届く。二重配信が起こる |
| 5 | 公開後に配信ログを見ない | どの通が壊れているか特定できず、感覚で全部を書き直してしまう |
この記事では、graciautoがエルメ（L Message）やLステップで本番構築・運用しているシナリオを素材に、5つのパターンそれぞれを「正しい設計」とセットで解説します。後半では、この記事の本題である「どの通で離脱しているか」を配信ログから特定する手順をまとめます。
シナリオの組み方の実物は[実物分解の記事](/blog/line-scenario-jitsubutsu-202607/)、通数と間隔の決め方は[配信間隔の記事](https://cms.graciauto.jp/line-scenario-haishin-kankaku-202607/)で扱ったので、この記事は「事故を防ぎ、壊れた箇所を直す」側に絞ります。/
パターン1：出口を設計していない——用が済んだ人に配信が届き続ける
正しい設計は、入口（誰をシナリオに乗せるか）と同じ重さで出口（誰をいつ降ろすか）を決めることです。予約した・キャンセルした・購入した・応募したなど、「もうこの配信が必要なくなる状態」を最初に洗い出し、その状態になった瞬間に配信を止める処理を組み込みます。
出口がないシナリオで起きるのは、キャンセルした人に当日の案内が届き続ける、購入済みの人に売り込みが届き続ける、という事態です。本人にとって「もう関係ない配信」ほどブロックに直結するものはありません。ブロックの主因は通数より、この空振り配信です。
注意したいのは、「タグを外せば止まるだろう」という想定が通用しないケースがあることです。教育系クライアントのウェビナー予約リマインドを構築した際、エルメでは予約タグを解除しても、走り出したシナリオは止まらずに動き続けるという仕様を本番環境で確認しています。タグはあくまで相手に貼るラベルで、シナリオの購読状態はそれとは別に生きているためです。
このため出口は、次の二重ガードで設計するのが正解です。
1. **キャンセル・完了時にシナリオ自体を停止するアクションを組む**
2. **保険として、視聴URLや来店案内など重要な配信に「該当タグを保持している人にだけ送る」絞り込み条件をかける**
どちらか片方が漏れても、もう片方で空振り配信が止まる構造にしておきます。
パターン2：ツールの停止・判定の仕様を確かめずに設計する
正しいやり方は、設計の要になる機能（シナリオ停止・タグ解除・条件分岐）を、本番公開の前にテスト用アカウントで必ず1周動かして確かめることです。管理画面の項目名やマニュアルの記述から挙動を想像して設計を確定すると、思い込みと実際の仕様のズレがそのまま事故になります。
実機で確認して初めて分かる仕様のズレは、実際に少なくありません。本番構築で確認した実例を3つ挙げます。
- **エルメのシナリオ停止アクションは、止めるシナリオを個別に指定できない**（全シナリオ停止になる）。複数のシナリオが並走する設計では、1本だけ止めるつもりが全部止まります。この仕様を前提にするなら、個別の止血は停止アクションではなく絞り込み条件の側に主役を置く設計が正解です
- **エルメのステップ配信の絞り込みは、ステップ1通ごとではなく「配信対象」の単位で設定する**UIになっています。1通だけに条件をかけるつもりで設計していると、実装段階で設計図とUIが噛み合いません
- **Lステップのアクション条件は「そのアクションが実行される瞬間の値」で評価される**。数値を減算するアクションの後ろに置いた条件は、減算後の値を見ます。サロンチェーンのデジタル回数券システムでは、この仕様を見落とすと「残回数0の人がQRを読むと残回数がマイナスになる」という事故が起こりえます。正解は、減算前の値で判定してタグを立ててから減算する、というガードの置き方です
いずれも「動かして確かめれば1時間で分かること」です。逆に、確かめずに公開すると、気づくのは顧客に誤配信が届いたあとになります。
パターン3：相手の状態をシナリオの本数で管理する——分岐爆発
正しい設計は、相手の状態（どこまで進んだか）はタグや友だち情報欄で持ち、シナリオの本数は最少に抑えることです。原則は「1つのタグが1つの状態だけを表す」。状態の管理と配信の実行を分離します。
これを逆にして、状態の組み合わせをシナリオの分岐で表現し始めると、本数が爆発します。たとえば3日間のセミナー案内で「Day1〜3 × 視聴完了/遅刻/未視聴 × 次の日程への誘導」を全部シナリオの分岐で組むと、どのシナリオがどの条件で発動するのか、作った本人が途中から追えなくなります。実際のエルメ構築案件でも、当初シナリオの分岐で組む設計を見直し、予約機能に標準搭載されているリマインド設定へ載せ替えることで、設計全体を大幅に単純化できました（経緯は[ウェビナー案件の設計記録](/blog/260422-2/)に書いています）。/
判断基準はこうです。**予約・来店・セミナーのように日時が決まっている行動に紐づく配信は、シナリオで組む前に、予約系機能の標準リマインドで実現できないかを先に検討する**。シナリオは万能に見えて、実は「日時起点の配信」はもっと単純な機能で置き換えられることが多いためです。
パターン4：絞り込みなしで公開する・移行を中間状態で放置する
正しいやり方は2つです。
1. **重要な配信ステップには、配信対象の絞り込み条件を付けてから公開する**。絞り込みのないステップは、その時点でシナリオに乗っている全員に届きます。パターン1の二重ガードの片翼でもあります
2. **稼働中のシナリオに絞り込みを後付けする移行作業は、1シナリオずつ完結させる**。旧の配信対象と新の配信対象が両方生きている中間状態のまま作業を中断すると、同じ相手に二重配信が起こります。複数シナリオをまとめて途中まで進める進め方は避け、1本を最後まで載せ替えてから次に移ります
もう1つ、公開のタイミングにも順序があります。キャンセル導線のような「出口」を新設する場合、**止血側（停止アクション・絞り込み）が入るまで、導線そのものを利用者に案内しない**ことです。ボタンだけ先に公開すると、「キャンセルしたのに案内が届く」というワーストの体験を先に配ることになります。
パターン5：公開後に配信ログを見ない——感覚で全部書き直す
ステップ配信は公開した時点で半分です。反応が悪いときにやるべきは、全通の書き直しではなく、**配信ログでどの通が壊れているかを特定して、その1通だけ直す**ことです。
全部を書き直すと、何が原因だったのか永久に分からなくなります。壊れていない通まで変えてしまうので、改善したのか悪化したのかの比較もできません。特定→1点修正→数字の再確認、というサイクルを回すのが正しい運用です。
その特定の手順が次章です。
どの通で離脱しているかを配信ログで特定する3ステップ
ステップ1：シナリオ画面で「通ごとの人数の減り方」を見る
エルメやLステップなどの拡張ツールでは、シナリオごとの配信状況と、友だち一人ひとりの購読状態（配信中/停止/完了）が確認できます。見るのは、通番の若い順に追ったときの購読者数の減り方です。
各通の配信人数を1通目から順に並べると、どこかに減りが集中している区間があります。3通目までは届いているのに4通目の配信人数が大きく落ちているなら、3通目が「壊れた1通」の第一容疑者です。その通の直後にブロックや購読解除が集中しているということだからです。
なお、LINE公式アカウント単体の分析では、ここまでの粒度（通単位の購読離脱）は追えません。日次のブロック数と配信ごとの開封数までです。通単位で特定したいなら拡張ツールのログが必要になります。
ステップ2：日次ブロック数と配信日時を突き合わせる
LINE公式アカウント管理画面の分析で、ブロック数の日次推移を出し、各通の配信日時と突き合わせます。見分けるのは次の2つです。
- **特定の通の配信直後にブロックが跳ねている** → 原因はその1通の内容かタイミング。その通だけ直す
- **配信のたびに少しずつ確実に増えている** → 原因は1通ではなく、頻度・間隔・配信対象の広さ。設計側を見直す
この切り分けの詳細は[反応がないときに見る3つの数字の記事](/blog/line-hannou-nai-3numbers-202607/)と[配信間隔の記事](https://cms.graciauto.jp/line-scenario-haishin-kankaku-202607/)にまとめています。/
ステップ3：リンクのクリック計測で「読んだが動かなかった」を切り分ける
離脱もブロックも増えていないのに成果が出ない場合、壊れているのは途中の通ではなく、最後のオファー（予約・申込への誘導）です。ここを見るには、各通に貼るリンクを計測URLにしておきます。
通ごとのクリック率を並べると、相手の温度がどこで下がっているかが段差で見えます。ウェビナー案件では、セールスの各段階に計測URLを6本配置し、「視聴完了URLのクリック数」と「その後の予約数」の比較で、どの段階の訴求に問題があるかを数字で判断できるようにしました。読了や既読が取れないLINEでは、クリックが実質的な読了ログの代わりになります。
補足：本番設定を書き換えずに検証する
絞り込みが効いているか・止血が成立しているかは、配信対象の「対象者数」の表示で確認できます。前述のウェビナー案件では、キャンセル操作のあとに直前リマインドの対象者数が0人になっていることを画面上で確認するだけで、本番のタイミング設定を一切触らずに検証を完了しました。
テスト配信のために本番シナリオの配信時刻を書き換えて動かす方法は、戻し忘れがそのまま次の事故になります。まず「設定を変えずに読み取りだけで確認できないか」を考えるのが安全です。
まとめ：失敗の5パターンは、文章力の問題ではない
最後にもう一度整理します。
1. **出口を設計する**：用が済んだ人を降ろす処理を、入口と同じ重さで組む（停止＋絞り込みの二重ガード）
2. **仕様は実機で確かめる**：タグ解除で止まるか・停止は個別にできるか・条件はいつの値を見るか。想像で設計を確定しない
3. **状態はタグで持つ**：シナリオの本数で分岐を表現しない。日時起点の配信は予約系リマインドを先に検討する
4. **絞り込みを付けてから公開する**：移行は1シナリオずつ完結。止血が入るまで導線は案内しない
5. **ログで壊れた1通を特定する**：通ごとの人数の減り方→日次ブロック数との突き合わせ→クリック率の段差。直すのはその1通だけ
どれも文章のセンスとは関係のない、設計と手順の話です。逆に言えば、この5点を押さえれば、ステップ配信の失敗の大半は公開前に潰せます。
よくある質問
**Q. すでに動いているシナリオに、絞り込みを後付けできますか？**
できます。ただしエルメの場合、絞り込みはステップ1通ごとではなく配信対象の単位で設定するため、既存の配信を新しい配信対象へ載せ替える作業になります。パターン4のとおり、1シナリオずつ完結させ、新旧が併存する中間状態で作業を止めないことが条件です。
**Q. 配信ログはどこまで細かく見えますか？**
ツールによります。LINE公式アカウント単体では日次のブロック数・配信ごとの開封数まで。エルメやLステップなどの拡張ツールでは、シナリオ単位の配信状況に加えて、友だち単位の購読状態（配信中/停止/完了）まで確認できます。通単位で離脱を特定する運用をするなら、拡張ツールの導入が前提になります。
**Q. 壊れた1通を特定したあと、何から直すべきですか？**
順番は「対象→タイミング→内容」です。まずその通が届くべき人だけに届いているか（絞り込み）、次に配信時刻が深夜・早朝などに流れていないか、最後に文面とオファーを見直します。内容から手を付けると、対象やタイミングの問題だった場合に修正の効果が数字に出ず、原因の切り分けが振り出しに戻ります。
—
graciautoでは、LINE公式アカウントのステップ配信を、本記事のような本番運用の設計基準で構築しています。すでに動いているシナリオの診断（どの通で離脱しているかの特定）だけの相談もお受けしています。配信設計で判断に迷う点があれば、お気軽にご相談ください。