パーソナルジムの体験予約をLINEで受ける仕組み。入会までつなぐために作る側が先に決めること

この記事の結論：パーソナルジムの体験予約をLINEで受けるなら、最初に決めるべきは道具ではなく「体験の前後の流れ」と「予約データをどこに持つか」です。予約の確定や質問への返事は、利用者の操作に返す「応答」で送れば通数に数えられません。一方、前日のリマインドや体験後のフォローは「プッシュ」になり、通数に数えられます。予約はLINEの中ではなく自社の予約データに持ち、LINEのユーザーIDとひも付ける。健康状態の聞き取りは、法律上の扱いを確かめてから項目を決める。この3つを先に押さえておくと、拡張ツールを使う場合でも、作る場合でも、あとで作り直さずに済みます。

株式会社bundlyzeでは、予約や顧客の記録とLINE公式アカウントをつなぐ仕組みを、自社で開発しています。この記事では、その経験をもとに、ジムやスタジオで「体験予約 → 来館 → 入会 → 継続」をLINEでつなぐときの設計を、作る側の目線でまとめます。特定のお店の事例ではなく、設計の考え方です。

ジムの体験予約から継続までを、場面に分けて書き出す

ジムの体験は、予約してから入会を決めるまでに数日から数週間かかります。その間に、どの場面で何を届けるかを先に並べます。

LINEの公式の説明では、Messaging API で送るメッセージのうち、Reply API による応答は通数に数えられません。プッシュやマルチキャストなど、こちらから送るものは数えられます（出典：LINEヤフーの開発者向け資料・料金のページ）。表のように「利用者の操作に返すもの」と「こちらから送るもの」を分けておくと、月々のプランの見積もりが立てやすくなります。

予約データはLINEの外に持ち、ユーザーIDでひも付ける

LINEはあくまで「入口と連絡の手段」で、予約そのものは自社の予約データに持つ形をおすすめします。理由は3つあります。

1. 予約の入口はLINEだけではない。 Webサイトの予約フォーム、電話、店頭からも予約は入ります。枠の空きを1か所で管理しないと、同じ時間に2人入る事故が起きます
2. トレーナーの予定と合わせる必要がある。 パーソナルは「枠」ではなく「トレーナー × 時間」で埋まります。予約データの側で、人と時間の組み合わせを持つ必要があります
3. 道具を替えても、記録が残る。 予約の記録が拡張ツールの中にしか無いと、乗り換えのたびに書き出しと取り込みの作業が発生します

ひも付けには、LINEのユーザーIDを使います。友だち追加のときに Webhook で届く follow イベントに、そのユーザーのIDが入っています。予約データの会員に、このIDを1つの列として持たせておけば、「予約の前日に、この人のLINEにリマインドを送る」が実現できます。

{
  "type": "follow",
  "timestamp": 1759370400000,
  "source": { "type": "user", "userId": "U4af4980629..." },
  "replyToken": "nHuyWiB7yP5Zw52FIkcQobQuGDXCTA",
  "webhookEventId": "01FZ74A0TDDPYRVKNK77XKC3ZR",
  "deliveryContext": { "isRedelivery": false }
}

LINEの予約画面は、LIFFで開くWebページにする

日時を選ぶ、名前を入れる、といった操作は、トークの中のボタンだけで作ると窮屈になります。LINEの中でWebページを開ける LIFF を使い、予約の画面は自社のWebページとして作るのが扱いやすい形です。

このとき気をつけたいのは、ページの側で取れたユーザーIDをそのまま信用しないことです。LINEの公式の説明でも、サーバーに利用者を伝えるときは、IDではなくIDトークンを送り、サーバー側で検証するように案内されています（出典：LINEヤフーの開発者向け資料・LIFFの利用者情報のページ）。予約は個人に結びつく情報なので、ここは省かないようにしています。

メニューは、利用者の状態で出し分ける

トーク画面の下に出るリッチメニューは、ユーザーごとに別のものを表示できます（出典：LINEヤフーの開発者向け資料・リッチメニューのページ）。ジムなら、次の3種類に分けると迷わせにくくなります。

切り替えは、予約データの状態が変わったとき（体験の予約が入った、入会した）に、サーバーからそのユーザーにメニューをひも付け直す形で行います。人の手で切り替えないので、切り替え忘れが起きません。

健康状態の聞き取りは、項目を決める前に扱いを確かめる

体験の前に、けがや持病、服薬などを聞くことがあります。病歴は、個人情報保護法で「要配慮個人情報」とされ、取得には原則として本人の同意が必要です（個人情報保護委員会：個人情報保護法ガイドライン（通則編））。

作る側としては、次の3点を決めてから項目を作ります。

• 本当に事前に聞く必要がある項目か（当日の対面で聞けば足りるものは、フォームに入れない）
• 何のために使うかを、入力の画面に書いて同意を取るか
• 保存する場所と、見られる人を誰にするか（トレーナー全員か、担当だけか）

LINEのトークで病歴を聞くのは避け、聞く場合は自社の予約画面の中で、保存先を決めたうえで受け取ります。

止まったことに気づける仕組みを入れておく

Webhook は、受け取る側のサーバーが応答できないと、届かないまま終わることがあります。LINE の設定で Webhook の再送を有効にすると、失敗したイベントが再送されます。再送されたものには deliveryContext.isRedelivery が付くので、webhookEventId で処理済みかを確かめ、同じ予約を二重に作らないようにします（出典：LINEヤフーの開発者向け資料・Webhook再送の項）。

また、Webhook が本当に LINE から来たものかは、リクエストに付く署名（x-line-signature）で確かめます。予約を作る処理の入口なので、これも省かないようにしています。

ジムのLINE予約は、拡張ツールで足りるか作るか

ここまでの設計が決まると、「既製の拡張ツールの機能で足りるか」「予約データとの連携まで作るか」が判断しやすくなります。場面の表とメニューの出し分けが既製のツールの画面で組めて、予約データとのひも付けもツールの連携機能で足りるなら、作る必要はありません。予約の入口が複数あり、トレーナーの予定と合わせる必要があるなら、予約データの側から作るほうが、あとで困りません。予約の仕組みとLINEを一緒に設計して作る場合の進め方は、bundlyzeのシステム開発のページで紹介しています。

よくある質問

Q. 体験予約のリマインドは、毎回通数に数えられますか？ A. こちらから送るリマインドはプッシュになるので、数えられます。予約の確定のように、利用者が予約の操作をした直後に返すものは応答で送れるので、数えられません。どの場面をプッシュにするかを決めておくと、プランを選びやすくなります。

Q. 予約システムとLINEは、別々の会社のものでもつなげられますか？ A. 予約システムの側に、予約の作成や変更を外へ知らせる仕組み（WebhookやAPI）があれば、つなげられることが多いです。ない場合は、LINEのユーザーIDを予約システムに持たせる方法から考えます。

Q. LINEに友だち追加していない人の予約は、どう扱いますか？ A. 予約データは LINE の外に持つので、Webや電話からの予約もそのまま入ります。LINEのユーザーIDが空の会員には、メールなど別の連絡手段で送るように分けておきます。