リッチメニューを残回数で自動切替する実装｜LINE上に「回数券を持っている感」を作る

LINE公式アカウントのリッチメニューは、通常「全員に同じメニュー」を表示するものです。しかし、回数券の残回数のように「人によって違う情報」をメニュー画像そのものに出せると、LINEの画面を開くだけで自分の残回数が見える状態が作れます。紙の回数券をデジタル化するとき、この「開けばいつでも残数が見える」体験が、お客様にとっての『回数券を持っている感』になります。

先に結論です。残回数連動のリッチメニューは、次の4点で設計すれば動きます。

• **残回数は友だち情報欄（カスタムフィールド）に数値型で持つ**。リッチメニューは表示に徹し、状態はデータ側で管理する
• **リッチメニュー画像は「残回数のパターン数」だけ用意する**。3回券なら残3・残2・残1・残0の4枚
• **店舗設置QRの読み取りをトリガーに、減算と切替のアクションを一括実行する**
• **減算の前に「実行してよいか」の判定を置く**。判定を後ろに置く設計では、残0の状態でQRを読まれたときに残回数がマイナスになる事態が起こりえます（後述）

この記事では、graciautoが多店舗展開するサロン企業のLINE運用ツール（Lステップ）本番環境——有効友だち約51万人——で、回数券のリッチメニュー自動切替を実際に構築した記録をもとに、設計と実装の急所をまとめます。なお、リッチメニュー自体の基本的な作り方・配置設計はリッチメニューの作り方の記事で解説しているので、本記事は「切替の実装」に絞ります。

標準機能でできること・できないこと

まず前提の整理です。LINE公式アカウントの標準機能（LINE Official Account Manager）では、リッチメニューを複数作って期間で切り替えることはできますが、**友だち一人ひとりの状態に応じて別々のメニューを出し分けることはできません**。残回数連動のような「セグメント別リッチメニュー」を実現するには、Lステップやエルメなどの拡張ツールが必要です。

今回採用したLステップの場合、プラン条件が2つあります。

• **セグメントリッチメニュー（友だちごとの出し分け）はスタンダードプラン以上**
• **店舗QRのトリガーに使う「流入経路分析」で、アクションを読み取りのたびに実行する設定はプロプラン限定**

つまり「店舗のQRを読むたびに残回数が減ってメニューが変わる」仕組みをLステップ内で完結させるには、実質プロプラン（月額32,780円）が前提になります。外部システムとのAPI連携オプション（+11,000円/月）を足す構成も検討しましたが、後述する有効期限の自動計算までLステップ単体でできると確認できたため、**API連携なし・ツール内完結**で構築しています。ツール費用の考え方はLINE構築の月額実費の記事にまとめています。

実例：51万人の本番アカウントで構築した回数券メニュー

構築したのは、店頭で販売する回数券（3回券×2種・5回券×1種）をLINE上でデジタル管理する仕組みです。全体設計（券種の絞り方・QRを購入用と消化用に分ける理由など）は回数券デジタル化の設計記事に書いたので、ここではリッチメニュー切替に関わる実装の中身を出します。

データ構造：友だち情報欄に3項目

友だち情報欄に「回数券管理」フォルダを作り、券種ごとに次の3項目を持たせました。

• 残回数（数値型）
• 購入日（年月日型）
• 有効期限（年月日型）

命名は「回数券｜スタートアップ｜残回数」のように **「用途｜券種｜項目名」で統一**します。3券種×3項目で9フィールドになるため、命名規則がないと後から自分でも判別できなくなります。友だち情報欄とタグの設計指針はセグメント配信の実装記録でも詳しく書いています。

リッチメニューは「残回数のパターン数」だけ作る

• 3回券：残3・残2・残1・残0の**4枚**
• 5回券：残5〜残0の**6枚**

画像は券面デザインの中央に残回数を大きく置き、下帯は「有効期限を確認する」のタップ領域にしました。タップすると有効期限の日付を差し込んだテキストが自動返信されます。メニュー画像に日付そのものを焼き込むのではなく、**変動する情報は差し込みテキストで返す**ようにすると、画像の枚数を増やさずに済みます。

画像制作で注意すべきはLINEの仕様です。リッチメニュー画像は容量1MB以下である必要があり、デザインデータからの書き出しそのまま（今回の元画像は10417×7025ピクセル・5〜7MB）ではアップロードできません。**2500×1686ピクセルに縮小して1MB以下に変換する**工程をあらかじめ制作フローに入れておくと、アップロード時に弾かれて手戻りすることがなくなります。

付与QR：読み取り1回で6アクション

回数券を販売したら、お客様に店頭の「付与QR」を読み取ってもらいます。このQR（流入経路）に次の6アクションを設定しました。

• 残回数に3を代入（5回券なら5）
• 購入日に「アクションの実行日」を代入
• 有効期限に「アクションの実行日」を代入
• リッチメニューを「残3」に変更
• 有効期限に「+0年6ヶ月0日」を加算
• 券種名と有効期限を差し込んだ案内テキストを送信

ポイントは有効期限の作り方です。Lステップの友だち情報操作には値の加算・減算があり、年月日型に「6ヶ月」を加算すると**カレンダー通りの半年後**が入ります（180日加算ではなく、1月31日+6ヶ月のように移動先に同じ日がない場合は月末日に自動調整されます）。回数券のような前払式サービスは、資金決済法の関係で**有効期限を6ヶ月以内に収めると前払式支払手段の規制対象外にできる**ため、「購入日から6ヶ月ちょうどまで有効・1日でも過ぎたら使えない」を厳密に作る必要がありました。カレンダー通りの加算ができるかどうかは、この要件を満たせるかの分かれ目になります。

消化QR：減算・切替・ガードを8アクションで

来店時にはレジ横の「消化QR」を読み取ってもらい、1回分を消化します。ここが実装の本丸で、次の8アクションを組みました。

• 【残回数が1以上 かつ 有効期限内】一時タグ「消化成功」を付与
• 【同条件】残回数を1減算
• 【一時タグあり】「1回ご利用いただきました。残りはN回です」を送信
• 【残回数=2】リッチメニューを「残2」に変更
• 【残回数=1】「残1」に変更
• 【残回数=0】「残0」に変更
• 【一時タグなし】「この回数券はご利用いただけませんでした。残回数が0回、または有効期限を過ぎています」を送信
• 一時タグを解除（後始末）

なぜ一時タグを挟むのか。これが本記事でいちばん伝えたい急所です。

実装の急所：条件は「実行される瞬間の値」で評価される

Lステップのアクション条件は、アクションリストの上から順に、**そのアクションが実行される瞬間の値**で評価されます。つまり減算アクションの後ろに置いた条件は「減算後の値」を見ます。

この仕様を踏まえずに「残回数を減算→残回数が0なら完了メッセージ」という素直な構成にすると、次の事態が起こりえます。

• **最後の1回を使った直後（減算で残0になった）と、使い切った後にもう一度QRを読んだ空打ち（元から残0）が、残回数だけでは区別できない**
• **減算に条件を付けないと、残0でQRを読まれるたびに残回数が-1、-2と沈んでいく**

だから消化QRは「減算前の値」で実行可否を先に判定し、その結果を一時タグに焼き付けてから減算する、という二段構えにします。利用メッセージと「ご利用いただけません」の分岐は残回数ではなくタグの有無で判定するため、正規の消化と空打ちを確実に区別できます。タグは最後のアクションで必ず解除して、次回の読み取りに持ち越さない。この「判定→記録→実行→後始末」の型は、残回数に限らずポイント付与などの数値操作全般に使えます。

有効期限の判定にも同じ思想を使います。Lステップの年月日型には「残り期間で絞り込み」という条件があり、「有効期限まで残り期間0年」と指定すると**当日を基準に、今日から1年後までの範囲だけが対象**になります。期限切れ（過去日）は範囲外になるので、この条件を減算の可否判定にAND条件で入れておけば、期限切れ券は減算されず案内メッセージ側に流れます。ひとつ注意があり、有効期限が1年以上先の日付だと「残り期間0年」の範囲からも外れて消化できなくなります。6ヶ月券なら問題になりませんが、1年券を扱う場合は絞り込みの値を変える必要があります。

この消化QRの挙動は、テスト用の友だち（自分の端末）で「付与→3回消化→4回目の空打ち→期限切れ状態での読み取り」まで通しで実機確認してから本番設置しています。51万人が友だち登録している本番アカウントでの構築だったため、**作成物はすべて「誰にも適用されていない0人状態」で組み上げ、テスト友だちで検証してから公開する**手順を徹底しました。一斉配信系の操作には一切触れない、という運用ルールもセットです。

多店舗展開と運用設計の判断基準

今回の仕組みは1店舗では終わらず、多店舗展開が前提でした。展開設計で判断したポイントを挙げます。

• **リッチメニュー画像は全店舗共通にし、店舗差分はQR側で持つ**。このアカウントには既に300本以上の店舗別QR（流入経路）が運用されており、回数券も「店舗×券種×用途」でQRを分ければ、どの店で買われ・どの店で使われたかを経路データとして追えます。メニュー画像を店舗ごとに作り分ける必要はありません
• **状態は友だち情報欄、表示はリッチメニュー、と役割を分ける**。メニュー切替アクションの条件は残回数だけを見るため、券種が増えてもアクションの順序に依存せず追加できます
• **同型の横展開はコピー機能を使う**。Lステップの流入経路とリッチメニューにはコピー作成があり、「読み取りのたびに実行」の設定（新規作成後は変更不可）もコピーなら引き継がれます。1券種目を作り込んでからコピーで横展開するのが安全です
• **命名を最初に固める**。タグ・友だち情報欄・流入経路・リッチメニューのすべてに「回数券｜券種｜〜」の接頭辞を付けておくと、既存運用の数百のタグや経路に埋もれません。なお、後から名前を変えてもID参照は壊れない仕様でしたが、参照箇所を洗ってから変える方が確実です

まとめ：メニューは「表示」、状態は「データ」で持つ

残回数連動のリッチメニューは、拡張ツールの機能一覧だけ見ると「セグメントリッチメニューがあるからできる」と即断しがちですが、実際に動くものにするには次の設計判断が必要でした。

• 友だちごとの出し分けは標準機能では不可。ツール選定とプラン条件（今回はプロプラン相当）を最初に確認する
• 残回数は友だち情報欄に数値で持ち、リッチメニューは残数パターン分の画像切替に徹する
• 条件評価は「実行される瞬間の値」。減算前判定＋一時タグの二重ガードで、空打ちによるマイナスや誤案内を設計段階で潰す
• 有効期限はカレンダー通りの加算で自動計算し、「残り期間」条件で期限切れを弾く。法令要件（6ヶ月）を仕様に落とし込む
• 本番アカウントでは0人状態で構築→テスト友だちで通し検証→公開の順を崩さない

LINEの画面を開くたびに自分の残回数が見える体験は、紙の回数券にはない再来店の後押しになります。一方で、数値の減算を扱う仕組みは「動いているように見えて残数がずれている」ことが最も怖い。派手な機能より、ガードと検証手順を先に設計することをおすすめします。

graciautoでは、LINE公式アカウントの構築を「作って終わり」ではなく、こうした業務の仕組みごと設計しています。回数券やポイントのデジタル化を検討している店舗・多店舗展開の企業の方は、お問い合わせページからご相談ください。