こんにちは。バナナデスクです。
講座へ申し込んだ方にも、LINEの下に「はじめての申込み」が出続ける。逆に、申込ページを開いただけの方へ「受講者用」の案内が出る。このようなずれは、画像のデザインより、表示を切り替える条件に原因があるかもしれません。
Lステップのリッチメニューを使うなら、最初に「どの状態の人へ何を見せるか」を決めます。申込み、確定、利用終了を分け、キャンセルしたときの戻し方まで一緒に設計しましょう。
使えるプランと、管理するツールを確認する
2026年10月1日に確認したLステップ公式の説明では、ユーザーに応じて出し分けるセグメントリッチメニューはスタンダードプラン以上で利用可能です。画像を作るLメニュープラスと、状態に応じて表示を切り替える機能の条件は分けて確認します。Lステップ公式・リッチメニューの出し分け
LINE Official Account Managerの標準メニューと、外部ツールで設定するメニューは、同じ編集画面で自由に入れ替えられるものではありません。LINE公式資料は、一つのリッチメニューを二つのツールから取得・編集できないと説明しています。既存メニューがある場合は、作成場所を先に記録します。LINE Developers・リッチメニューの概要
見込み客、申込済み、利用者を具体的に定義する
ここでは、架空のオンライン講座を例にします。以下は独自の設計で、実アカウントへ設定した記録ではありません。
| 状態 | 判定に使う事実 | 表示する三つの入口 |
|---|---|---|
| 検討中 | この講座の有効な申込受付記録がない | 講座内容／日程と料金／よくある質問 |
| 申込済み | 受付番号があり、参加確定前の確認を進めている | 申込状況／参加前の準備／変更の相談 |
| 利用者 | 参加を確定し、受講案内の対象になった | 参加方法／当日の資料／受講中の問い合わせ |
「申込ページをクリックした」は関心を示す手掛かりにはなりますが、申込みを受け付けた事実ではありません。申込済みへ変える条件は、フォームの正常な受付など、確認できる記録に結び付けます。
また、メニューを隠すことは、有料コンテンツへのアクセス権管理の代わりにはなりません。URLを知る人が開けるページなら、画像を出さなくても閲覧できる可能性があります。受講者限定の情報は、掲載先でも権限を管理します。
切り替える条件と、戻す条件を組にする
| きっかけ | 変更前→変更後 | 必要な照合 |
|---|---|---|
| 有効な申込みを受付 | 検討中→申込済み | 講座ID、受付番号、重複受付の有無 |
| 参加確定 | 申込済み→利用者 | 必要な支払い・条件確認と確定記録 |
| 確定前に取消 | 申込済み→検討中 | 有効な別申込みが残っていないか |
| 受講を取消 | 利用者→検討中、または別の案内 | 予約・返金・アクセス権をそれぞれ処理 |
| 再申込み | 現在状態から新しい受付を照合 | 過去の取消タグだけで新規申込みを除外しない |
タグを使うなら、例えば「講座A_受付済」「講座A_参加確定」のように対象を含めます。ただしタグが増えた順だけで状態を決めると、過去の受付と現在の取消が混ざります。何を現在の状態として見るかを決め、不要になった状態タグの扱いも同じ処理へ入れます。
複数講座を同時に受ける方がいる場合、この三状態をそのまま一つのタグへ押し込めません。講座ごとの状態と、共通メニューで優先して見せたい用事を別に設計します。最初は一講座の流れを整えてから広げる方が、矛盾を見つけやすくなります。
画像と領域を作り、切り替えのアクションへ接続する
Lステップの現行公式設定例では、リッチメニュー画像と領域、各ボタンの動作を作り、アクション設定の「メニュー操作」で表示するメニューを選んでいます。回答フォームへの回答後にタグを付け、条件を満たす人へ表示を変える例もあります。公式の表示切り替え設定例
今回なら、まず三種類のメニューを作り、各ボタンの行き先を決めます。次に、申込受付や参加確定という事実がどこで得られるかを確認し、その処理にメニュー変更を組み込みます。申込みに使う製品が違えば接続方法も変わるため、公式例のアンケート回答を、そのまま決済成功として読み替えないことです。
運用担当者が手で変更する工程が残るなら、処理する人と確認時刻も決めます。自動化していない部分まで「登録後すぐ切り替わります」と読者へ約束しないようにします。
標準Managerの画像を変えても反映しないとき
LINE Developersが示す優先順位は、Messaging APIで設定したユーザー単位のメニュー、APIのデフォルトメニュー、Managerのデフォルトメニューの順です。ユーザーに別のメニューが割り当てられていると、Managerで画像を変えても、その人には新しい画像が見えない場合があります。
これはLステップ内で「申込済み」と「利用者」のどちらを優先するかという独自条件の順序とは別です。LINE側の表示優先と、運用側の状態判定を分けて調べます。APIの応答が成功したことだけで、全員の画面を確認できたことにもなりません。
公式資料では、メニューの種類によって即時反映やトークへの再入室といったタイミングの違いがあります。確認対象のアカウントを取り違えないよう、同じテスト利用者で状態と表示を照合します。
順方向だけでなく、取消と再申込みも試す
| テスト操作 | 想定する表示と記録 |
|---|---|
| 新規のテスト利用者 | 検討中。過去タグなし |
| 申込ページだけを開く | 検討中を維持。クリックを受付扱いしない |
| 仮の申込受付を完了 | 申込済み。受付番号に対応 |
| 仮の参加確定を処理 | 利用者。古い状態が競合しない |
| 取消を処理 | 決めた案内へ戻る。資料のアクセス権も別に確認 |
| 同じ人が再申込み | 新受付の状態へ進み、過去の取消が妨げない |
この表は試験前の設計です。実環境では許可されたテストデータを使い、処理前後のタグや情報欄、表示画像、全ボタンの行き先を記録します。メニューを変更したのに違う画像が見える場合は、画像を作り直す前に、割当先と表示条件を確認してください。
表示を細かく変えること自体が目的ではありません。申込済みの方が必要な準備を見つけ、利用者が参加方法へ進めるよう、現在の用事に合う入口を出すために使いましょう。