LINEで回数券をデジタル化する方法｜QRを読むだけで残回数が減る仕組みを本番構築した記録

紙の回数券には、なくす・忘れる・数え間違えるという構造的な弱点があります。お客様は財布の中の券を探し、スタッフはハンコの数を目視で確認する。この運用を、LINE公式アカウントの上に載せ替えることができます。

結論から書きます。回数券のデジタル化は、システム開発なしで実現できます。必要なのはLINE公式アカウントと拡張ツール（今回はLステップ）、そして2種類のQRコードだけです。購入時に「付与QR」を読むと残回数がセットされ、来店のたびに「消化QR」を読むと残回数が1つ減る。お客様のLINE画面には、残回数に応じた回数券の画像が常に表示されます。

graciautoでは、この仕組みを多店舗展開するサロン企業（LINE友だち約51万人）の本番アカウントで実際に構築しました。この記事では、その構築記録をもとに、全体の構成、QR2種類のアクション設計、有効期限の法令対応、店舗運用で決めておくべきことまでを解説します。

仕組みの全体像：4つの部品で成立する

デジタル回数券は、Lステップの標準機能を4つ組み合わせるだけで成立します。

• 残回数の記録：友だち情報欄（お客様ごとに数値を持てる項目）
• 購入の入口：付与QR（流入経路機能で作るQRコード）
• 消化の入口：消化QR（同じく流入経路機能のQRコード）
• 見た目：残回数ごとに切り替わるリッチメニュー（回数券の券面画像）

ポイントは、残高のデータベースを外部に作らないことです。残回数・購入日・有効期限はすべてLステップの友だち情報欄に持たせます。外部のスプレッドシートやシステムに残高を持つと二重管理になり、「LINE上の残回数と台帳が合わない」という不整合が起こり得ます。残高の正はLINE側の1か所に置き、外部には履歴だけを記録する。これが崩れない設計です。

リッチメニューを残回数に連動して自動で切り替える実装の詳細は、別記事「リッチメニューを残回数で自動切替する実装」にまとめています。本記事では、残回数が動く側、つまりQR2本の設計と運用に軸足を置きます。

なぜQR方式が店頭運用に合うのか

回数券の消化方法には、スタッフが管理画面を操作する方式や、お客様が申告する方式も考えられます。それでもQR方式を選ぶ理由は、店頭のオペレーションがゼロ手数になるからです。

• お客様がレジ横のQRを自分のスマホで読むだけ。スタッフの操作は不要
• 読んだ瞬間にLINEのトーク画面へ「1回ご利用。残りは2回です」と返る。その場で双方が確認できる
• 店舗ごとにQRを分ければ、どの店で使われたかが自動で記録される

今回の構築先では、すでに340本を超える店舗別QR（来店ポイント付与用）を運用しており、店舗×用途でQRを分ける型が数百店舗規模でも破綻しないことは実運用で確認済みでした。回数券もこの型に乗せています。

実例：友だち51万人の本番アカウントで構築した中身

構築したのは3券種です。新規向けの3回券、全客向けの3回券、5回券の3種類で、券種ごとに友だち情報欄・リッチメニュー・QRをすべて独立させました。共用すると、1人のお客様が複数の券種を持ったときに残回数が混ざるためです。部品の数はこうなります。

• 友だち情報欄：3券種×（残回数・購入日・有効期限）＝9項目
• リッチメニュー：3回券は残3〜残0の4枚×2券種、5回券は残5〜残0の6枚、計14枚
• QR：付与・消化×3券種＝6本

項目名は「回数券｜券種名｜残回数」のように命名規則を統一しました。51万人規模のアカウントには既存のタグや情報欄が大量にあるため、命名を揃えておかないと、あとから探せなくなります。

付与QRのアクション設計（購入の入口）

お客様が店頭で購入した直後に、スタッフが提示する付与QRを読み取ってもらいます。QRの裏側には6つのアクションを順番に設定しています。

1. 残回数に3（5回券なら5）を代入

2. 購入日に「アクションの実行日」を代入

3. 有効期限に「アクションの実行日」を代入

4. リッチメニューを「残3」の券面に変更

5. 有効期限に6ヶ月を加算

6. 券種名と有効期限を差し込んだ案内メッセージを送信

これだけで、購入処理・期限設定・画面切り替え・購入案内が1回のQR読み取りで完了します。

有効期限は「6ヶ月ちょうど」を厳密に守る設計にする

有効期限の設計は、単なる親切設計ではなく法令要件です。回数券は資金決済法の前払式支払手段に該当し得ます。有効期限を6ヶ月以内に収めると届出等の規制対象外にできるため、「購入日から6ヶ月の同日まで有効・その翌日から使用不可」を厳密に実現する必要がありました。

ここで設計上の注意点が2つあります。

• 「購入日からの経過月数」で判定する設計は避けること。月単位の判定は精度が月に丸まるため、6ヶ月と20日経過していても「6ヶ月経過」の範囲に含まれて使えてしまう、という事態が起こり得ます。判定は有効期限の日付そのものに対する「残り期間」条件で行うのが正しく、これなら当日まで有効・翌日から不可が日単位で効きます
• 期限の自動計算はLステップ単体で完結できること。年月日型の友だち情報欄は加算操作に対応しており（2025年9月のアップデート以降）、「実行日を代入→6ヶ月を加算」の2段構えでカレンダー通りの半年後が入ります。180日加算ではないため、1月31日購入のような月末起点でも月末日に自動調整されます。この機能を見落とすと、有効期限の計算のためだけに月額1万円超のAPI連携オプションを契約する判断になりかねません

消化QRのアクション設計と「減らしすぎ」を防ぐガード

来店時に読む消化QRは、単純に「残回数−1」だけを設定してはいけません。正しい構成は、減算の前に条件付きの一時タグでガードを張ることです。

1. 【残回数が1以上、かつ有効期限内】の場合のみ一時タグを付与

2. 同じ条件で残回数を−1

3. 【一時タグあり】の場合「1回ご利用。残りはN回です」を送信

4. 残回数に応じてリッチメニューを切り替え

5. 【一時タグなし】の場合「この回数券はご利用いただけません。残回数0または期限切れです」を送信

6. 一時タグを解除

なぜこの順序が必要か。ツールのアクション条件は「そのアクションが実行される瞬間の値」で評価されるためです。無条件に減算する設計だと、残0の状態でお客様がもう一度QRを読んだとき（使い切り後の空打ちは実運用で普通に起こります）に残回数がマイナスに沈みます。また、減算後に条件判定を置くと、最後の1回を正しく使った直後と、使い切り後の空打ちがどちらも「残0」になり区別できません。減算前の値で成否を確定させる一時タグ方式なら、この両方を未然に防げます。実機テストでは、残0での空打ちに対して減算されず案内文だけが返ることまで確認しました。

導入手順と判断基準

実際に進める場合の順序と、途中で判断が必要になるポイントを整理します。

• 手順1：券種・回数・価格・有効期限・新規と再来のどちらに売るかを確定する。この要件定義の勘所は「LINE公式アカウント×AIでサロンの回数券をデジタル化する方法」で詳しく書いています
• 手順2：友だち情報欄・リッチメニュー画像・QR2本×券種分を構築する。券面画像は2500×1686pxで1MB以下というLINE側の仕様があります
• 手順3：テスト用の友だち（自分の端末）で、付与→消化→使い切り→空打ち→期限切れの一連を実機確認する
• 手順4：店舗にQRを配布し、購入時・会計時の声かけをオペレーションに組み込む

費用面の判断基準も書いておきます。今回の構成はLステップのプロプラン（月額32,780円）が前提です。消化QRに使う流入経路のアクション実行を「読むたびに毎回」にできるのがプロプランの要件だからです。一方で、月額11,000円のAPI連携オプションは必須ではありません。残回数の増減・期限判定・画面切り替えはすべてプラン内の標準機能で完結します。外部システムとのリアルタイム連携に月1万円超の固定費を足すかは、それで何の業務が減るかで判断してください。今回の案件では不採用とし、履歴の記録はCSVエクスポートを起点にした日次バッチで賄う設計にしました。

もう1つの判断基準は、残高と履歴の分離です。スプレッドシートで購入店・消化店・利用履歴を管理する場合、台帳（現在の状態）は上書き、履歴（購入・消化の記録）は追記専用と、シートの役割を最初に分けておきます。混ぜると、あとから月次集計や店舗間の精算確認ができなくなります。

起こりうるリスクと予防設計

本番運用を想定すると、事前に潰しておくべきリスクがいくつかあります。いずれも設計段階で対処すれば防げるものです。

• 未購入者の誤判定：「残回数が0」という条件だけでは、使い切ったお客様と、まだ買っていないお客様を区別できません。数値の初期状態と使い切り後の0が同じに見えるためです。「現在保有している券種」を示す情報欄を1つ立てて購入QRで上書きする排他的な設計にしておくと、過去に別の券種を買った履歴が残っていても表示が混ざりません
• 期限条件の範囲外落ち：「残り期間が0年」のような条件は「今日から1年以内」という範囲指定です。6ヶ月券なら問題ありませんが、将来1年を超える有効期限の券を追加すると範囲外になり、有効なのに使えない事態が起こり得ます。券種を追加するときは期限条件の範囲も見直す前提で、運用ルールに入れておきます
• QRの持ち帰り利用：店頭の消化QRをスマホで撮影して持ち帰れば、店外から消化できてしまいます。自分の残回数が減るだけでお客様側に得のない構造ですが、気になる場合はQRの定期差し替えや、消化時のスタッフ目視確認をオペレーションに足します
• 大規模アカウントでの作業事故：友だち数十万人の本番アカウントを触る場合、一斉配信につながる操作を禁止した上で、テスト用の友だちで検証してから本番適用する2段階を必ず踏みます。リッチメニューは作成しただけでは誰にも表示されない仕様のため、部品の作成作業自体は本番アカウント上でも安全に進められます

まとめ：開発案件ではなく設計案件

LINEでの回数券デジタル化は、プログラムを書く案件ではなく、標準機能をどう組むかの設計案件です。残回数は友だち情報欄、購入は付与QR、消化は消化QR、見た目はリッチメニュー。この4部品の組み合わせと、減算ガード・期限判定・未購入者判定という3つの予防設計さえ押さえれば、友だち51万人規模の本番環境でも安全に動きます。

そして店舗ビジネスにとっての本当の価値は、券がLINEの中にあることそのものです。お客様のトーク画面に残回数付きの券面が常駐し、店を思い出す接点が、財布の中から毎日開くアプリの中へ移ります。回数券は再来店の約束であり、その約束をLINE上に置けることがこの仕組みの本質です。

graciautoでは、LINE公式アカウントの構築を要件定義から店舗運用の設計まで一貫して支援しています。「うちの回数券・チケット・ポイントカードはデジタル化できるのか」という段階のご相談でも、本番構築の実例をもとに判断材料をお出しできます。

FAQ

Q. システム開発なしで本当に作れますか？

作れます。今回の実例では、残回数の増減・有効期限の自動計算・期限切れ判定・券面画像の切り替えまで、すべてLステップの管理画面上の設定だけで構築しました。プログラミングは使っていません。ただし、どの機能がどのプランに含まれるかの見極めと、減算ガードのような予防設計には実装経験が要ります。

Q. 月額費用はどのくらいかかりますか？

今回の構成ではLステップのプロプラン（月額32,780円）が前提です。回数券のためだけに契約すると重い金額ですが、セグメント配信や流入経路分析など販促機能全体を含んだ金額なので、LINE運用全体で回収する位置づけが現実的です。API連携オプション（月額11,000円）は、回数券の基本機能には不要でした。

Q. 複数店舗で使えるようにできますか？

できます。消化QRを店舗別に発行すれば、どの店舗で使われたかが経路単位で記録されます。実例の環境では340本を超える店舗別QRが既に運用されており、数百店舗規模でも同じ型で横展開できることを確認しています。購入店舗限定にするか全店共通にするかは、本部と店舗の精算ルールに合わせて要件段階で決めます。