デジタル回数券の消化QRは券種ごとに分けない｜店頭で別の券のQRを読んで「使えません」になる構造と、1枚のQRから券種で分岐させる設計
デジタル回数券の消化QRは券種ごとに分けない｜店頭で別の券のQRを読んで「使えません」になる構造と、1枚のQRから券種で分岐させる設計
LINE公式アカウントで回数券をデジタル化し、3回券・5回券のように券種が複数あるとき、店頭に置く「消化用QRコード」を券種の数だけ作っていないでしょうか。
運用が始まると、次のような問い合わせが届くことがあります。「さっき買ったばかりの5回券を使おうとしたら、『残回数が0回、または有効期限を過ぎております』と表示された。1回も使っていないのに」。
結論：お客さまが同時に持つ券が1種類なら、消化QRは共通の1枚にする
先に結論をまとめます。
- 「買ったばかりなのに使えない」と言われたら、不具合より先に「別の券種の消化QRを読んでいないか」を疑う。券種別にQRを分けている限り、店頭でこの取り違えは構造的に起こり続けます
- お客さまが同時に持つ回数券が1種類だけの運用なら、消化QRは共通の1枚でよい。QRを読んだ後、システム側で「この人がいま持っている券種」を見て分岐させれば、店頭のスタッフは券種を見分ける必要がなくなります
- 券種別に分けるべきなのは「付与（購入）QR」だけ。こちらは券種ごとに金額も回数も違うため、分けておくのが正解です
- 設計の前提が変わったら、その前提を理由に決めた設計を全部洗い直す。QRの枚数は、まさにその対象です
以降、当社が構築・運用を担当しているデジタル回数券の実例をもとに説明します。仕組み全体の作り方はLINEで回数券をデジタル化する方法にまとめていますので、本記事は「消化QRの枚数をどう決めるか」に絞ります。
実例：付与は成功しているのに「使えません」と出た問い合わせ
対象は、多数の店舗を展開するサロンチェーンのLINE公式アカウントです。LINE拡張ツールのLステップで、3種類の回数券（3回券が2種類、5回券が1種類）を運用しています。お客さまが店頭で購入すると、スタッフが提示する「付与QR」を読んで回数券が付き、来店のたびに「消化QR」を読むと残回数が1つ減り、LINEのリッチメニューの表示も残回数に合わせて切り替わります。
ある日、本部の担当者から「5回券が1回も使っていないのに消化できない。至急見てほしい」と連絡がありました。
このときに行ったのは、本番の設定にもデータにも手を入れず、該当する友だちのタイムライン（操作履歴）を秒単位で読むことだけです。残っていた記録は次のとおりでした。
| 時刻 | 記録 |
|---|---|
| 15:26:18 | 5回券の付与QRを読み取り→付与の確認メッセージ送信 |
| 15:26:22 | 付与を実行。残回数5・有効期限・リッチメニュー「残5」がすべて設定される |
| 15:26:23 | 「5回券をお渡ししました」のメッセージ送信 |
| 15:26:37 | 別の券種（3回券）の消化QRを読み取り→「利用できません」のメッセージ送信 |
付与は完全に成功しています。その15秒後に読まれた消化QRが、5回券用ではなく3回券用だった。3回券の消化QRは「3回券の有効な保有者でなければ利用不可の文面を返す」設計にしてあるので、これは設計どおりの正常動作です。5回券用の消化QRを読み直せば、データを直すことなくそのまま消化できました。
原因の切り分け自体は、管理画面を開いてから短時間で終わっています。ポイントは、付与QRの流入経路から「最近読んだ人」を新しい順に出し、該当者のタイムラインを開くという順番です。不具合を疑って設定を開く前に、まず「どのQRが読まれたか」を履歴で確かめる。これだけで、直さなくてよい設定を触る事故を防げます。
券種別QRが取り違えを生む構造
この1件は単発の操作ミスではありません。数字に表れていました。
この問い合わせの前日、定期の稼働確認で、消化QRの「読み取り数」と「実際に消化が実行された数」を券種別に比べていました。
| 券種 | 消化QRの読み取り→消化実行の割合 |
|---|---|
| 3回券A | 93% |
| 5回券 | 82% |
| 3回券B | 47%（449回読まれて、消化されたのは213回） |
1種類だけ、読まれた回数の半分以上が消化に至っていません。お客さまが確認画面でキャンセルしたにしては多すぎます。今回の問い合わせと合わせると、「別の券種を持っている人が、この券種の消化QRを読んで弾かれている」回数が積み上がっていると読むのが自然です。3回券Bは最も利用者の多い標準的な券種で、その消化QRが店頭で「消化用のQR」として一番手に取られやすい位置にある、というのが当社の見立てです（弾かれた人が別券種の保有者かどうかの突合は、これから行う検証項目です）。
構造として整理すると、こうなります。
- 店頭には、付与用3枚・消化用3枚の計6枚のQRがある
- QRコードは見た目で区別がつかない。見分ける手がかりは横に印刷した文字だけ
- スタッフは接客しながら、お客さまの券種を確認し、6枚の中から正しい1枚を選ぶ必要がある
- 間違えても、表示されるのは「利用できません」という文面だけで、「券種が違います」とは分からない
間違いを「スタッフの注意不足」で片づけると、店舗数が増えるほど同じ問い合わせが増えます。人が選ぶ工程がある限り、一定の割合で選び間違いは起きる。選ぶ工程そのものをなくすのが設計側の仕事です。
QRの枚数は「同時に何種類持てるか」という前提で決まる
消化QRを券種別にするか共通にするかは、好みではなく前提で決まります。
- 1人のお客さまが複数の券種を同時に持てる運用なら、共通QRではどの券を1回減らすのかをシステムが決められません。この場合は券種別に消化QRを分けるのが正しい設計です
- 同時に持てるのは1種類だけの運用なら、友だち情報に「現在の券種」という単一の欄を持たせて排他制御でき、共通の1枚から現在の券種で分岐できます
注意が必要なのは、この前提が構築の途中で変わる場合です。今回の案件も、要件定義の段階では「複数券種を同時に持てる」前提で券種別QRを採用し、その後「同時保有は当面なし」に運用方針が確定しました。後から追加した、誤付与を取り消すための「取消QR」は、新しい前提に沿って最初から共通の1枚で作っています。一方で、前提が変わる前に決まっていた消化QRの枚数は、同じ論理で見直す対象になります。
前提の変更は、たいてい「リッチメニューの分岐を直す」のような目の前の作業の文脈で決まります。そのため、同じ前提に依存していた他の設計へ波及させる確認が抜けやすい。ここが、運用開始後に店頭で問題が表面化する典型的な経路です。
予防策は地味ですが効果があります。設計を決めたとき、結論だけでなく「理由」を記録に残すことです。この案件でも「券種別に分ける。理由＝1人が複数券種を同時に持てるため」と理由が残っていたので、どの設計が古い前提に依存しているかを逆引きできました。前提を変える決定をしたら、「この前提を理由にしている設計は他にどれか」を記録から検索して一覧にし、1つずつ見直す。これを手順に入れておけば、QRの枚数のような店頭に直結する設計の見直し漏れを防げます。
1枚のQRから券種で分岐させる設計
共通の消化QRは、Lステップであれば新しい流入経路（QR）を1本作り、条件付きのアクションを並べるだけで実現できます。今回の案件向けに設計した構成では、アクションは7個です。
- 3回券Aの「有効タグ」を持つ人 → 3回券Aの消化確認待ちタグを付ける
- 3回券Aの有効タグがあり、かつ現在の券種＝3回券A → 既存の「3回券Aを1回使いますか？」の確認メッセージを送る
- 3回券Bの有効タグを持つ人 → 3回券Bの消化確認待ちタグを付ける
- 3回券Bの有効タグがあり、かつ現在の券種＝3回券B → 3回券Bの確認メッセージを送る
- 5回券の有効タグを持つ人 → 5回券の消化確認待ちタグを付ける
- 5回券の有効タグがあり、かつ現在の券種＝5回券 → 5回券の確認メッセージを送る
- 3種類の有効タグをどれも持っていない人 → 「ご利用いただける回数券がありません」の文面を送る
ここで大事なのは、既存の部品をそのまま使うことです。券種ごとの確認メッセージ、「実行する」を押した後に残回数を減らす内部の処理、残回数に応じたリッチメニューの自動切替は、一切変更しません。共通QRは「入口を1つ増やすだけ」で、消化そのものの処理は従来の券種別の経路が担います。これには3つの利点があります。
- 戻すのが簡単：問題があれば新しいQRを使うのをやめるだけで、元の状態に戻ります
- 並行稼働できる：既存の券種別QRは有効なまま残せます。多店舗で一斉に差し替える必要がありません
- 集計が崩れない：消化件数を券種別の内部経路で数えていれば、入口が1枚になっても券種別の数字はそのまま取れます。集計側は、QR経路の一覧に新しい経路を1行足す程度で済みます
設定の作業量の見積もりは、手入力で30分、スタッフのスマホでの実機テストに15分ほどです。条件を満たさないアクションは実行されないため、1人のお客さまに対して動くのは、自分の券種に対応する2つだけです。
実機テストでは、少なくとも次の4通りを確かめます。3券種それぞれの保有者が読んだときに自分の券種の確認メッセージだけが届くこと、そして未保有の人が読んだときに案内文だけが届くこと。加えて、残回数0の人・有効期限切れの人が読んだ場合に減算されないことも、既存のガード（有効タグと期限の条件）が共通QR経由でも効いているかという観点で確認します。
切り替えで一番重いのは、設定ではなく店頭の差し替え
システム側の作業は1時間程度で済みます。時間がかかるのは、各店舗に掲示・保管されている印刷済みQRの入れ替えです。店舗数が多いほど、ここが工程の大半を占めます。
進め方の要点は次のとおりです。
- 旧QRは止めない。新しい共通QRを配布した後も、券種別のQRは有効なままにしておき、店舗ごとに順次入れ替えます。「この日から旧QRは使えません」という切り替え方は、差し替えが遅れた店舗で「消化できない」問い合わせを新たに生みます
- 配布物には「消化用はこの1枚だけ」と明記する。旧QRが手元に残っていても使えてしまうので、新しい台紙には「回数券のご利用はこのQRひとつ」と大きく書き、付与用QRとは色や台紙の形を変えて見分けやすくします
- 差し替え前に、印刷物のQRを読み取ってリンク先を確かめる。QRの中身の確かめ方はQRコードのリンク先を確認する方法にまとめています
- 効果は同じ指標で測る。共通QRの「読み取り→消化実行」の割合が、券種別のときの47%からどこまで上がるかを見れば、取り違えが減ったかどうかを数字で判断できます
共通QRにしてよい条件と、分けたままにする場面
共通の1枚にしてよいのは、「お客さまが同時に持つ有効な回数券が1種類だけ」とシステム側で保証できている場合です。具体的には、有効な券を持っている間は別の券種の付与を拒否する、といった排他の仕組みが付与QR側に入っていることが条件になります。これがないまま共通QRにすると、2種類持っている人が読んだときに両方の確認メッセージが届いてしまいます。
では、将来「複数の券種を同時に持てる」ようにしたくなったら共通QRは邪魔になるかというと、なりません。複数保有に対応する改修は、付与の排他・現在券種の欄・リッチメニューの表示・集計のすべてを作り直す規模のもので、QRの枚数で難易度は変わらないからです。むしろ共通QRの確認メッセージを「どの券を使いますか？」という選択式に変えれば、そのまま複数保有時の入口として使えます。
一方、付与（購入）QRは券種別のままにします。券種ごとに金額も付与回数も有効期限も違い、「どの券を売ったか」はスタッフが必ず意識している情報だからです。会計と連動する操作なので、選ぶ工程を残し、付与の前に「5回券を付与します。よろしいですか？」という確認を挟む設計のほうが安全です。消化は「持っている券を1回使う」だけで、選ぶ情報がありません。選ぶ必要のないところから、選ぶ工程をなくします。
まとめ
- 「買ったばかりの回数券が使えない」という問い合わせは、設定を疑う前にどの消化QRが読まれたかを履歴で確認する。付与が成功していて、読まれたのが別券種のQRなら、システムは正常
- 消化QRの「読み取り→実行」の割合を券種別に出すと、取り違えの蓄積が数字で見える。1券種だけ極端に低ければ、そのQRが他券種の保有者にも読まれている可能性が高い
- 同時保有が1種類だけの運用なら、消化QRは共通の1枚にして、保有券種でシステムに分岐させる。既存の確認メッセージと内部処理を再利用すれば、設定は1時間程度の見積もりで、旧QRとの並行稼働もできる
- 付与QRは券種別のまま残す。分けるかどうかの基準は「スタッフが選ぶべき情報がそこにあるか」
- 前提（同時保有の有無など）を変えたら、その前提を理由に決めた設計を全部洗い直す。そのために、決定には理由を書き残しておく
QRを使った店頭オペレーションは、画面の中の設計だけでは完結しません。忙しい時間帯に、スタッフが迷わず1枚を手に取れるか。回数券のデジタル化を検討されている方は、券種の数とQRの枚数を、運用を始める前に一度並べて確認してみてください。