LINE予約システムを自作する3つの構成。二重予約・変更・通知まで設計する

LINE予約を自作するときは、予約を誰が確定するか、空き枠をどこで管理するか、連絡が届かなかった場合に誰が対応するかを先に決めます。この3点によって、必要な開発が変わります。

構成は、スタッフが確定する半自動受付、システムが枠を確保する自動確定、日時やメニューを画面で選ぶ予約画面型に分けて考えられます。画面を付けても、枠の管理や変更処理が自動で完成するわけではありません。

本記事では、発注・運用担当者が構成を選べるように、比較表と受入確認表を用意しました。LINEの仕様は2026年9月8日に公式資料で確認しています。予約DBの構成や業務例は設計案であり、特定の実案件での実装・配信結果を示すものではありません。

3つの構成を、確定方法と運用負担で選ぶ

構成	利用者の操作	予約を確定する人・仕組み	向いている条件	残る仕事
半自動受付	トークやフォームで希望を送る	スタッフが台帳を確認して確定	個別の調整が多い、担当者が受付を確認できる	未対応の確認、日程調整、確定連絡
自動確定	提示された候補から選ぶ	予約システムが空き枠を確保	時間・設備・人数のルールを機械的に判定できる	例外対応、枠や休業日の管理、失敗時の確認
予約画面型	カレンダー、メニュー、担当者を画面で選ぶ	予約DBの処理。必要なら一部をスタッフ承認にする	選択項目が多い、変更・取消も利用者に任せたい	画面と予約処理の保守、会員連携、問い合わせ対応

この分類は選択肢の整理です。必ず順番に作り直す必要はありません。既存の予約サービスにLINEから案内するだけで目的を満たすなら、その導線から始められます。

個別開発を検討する理由は、「電話・店頭・Webの予約を同じ台帳で扱いたい」「顧客DBの会員条件で予約可否を変えたい」など、既製機能で埋まらない業務上の差です。既製サービスを確認するときも、画面の見栄えだけでなく、外部連携、変更・取消、データの持ち出し、障害時の対応を比較します。全体の選び方はLINE開発の全体地図にまとめています。

構成1：スタッフが確定する半自動受付

LINEのメニューからトークや受付フォームへ案内し、希望日時を受け付けます。スタッフが既存台帳を確認して、候補の調整と確定連絡を行う構成です。

受付完了と予約確定を、表示と管理画面の両方で分けます。 たとえば受付直後には「ご希望を受け付けました。予約はまだ確定していません。営業時間内に担当者からご連絡します」と案内します。営業時間と返答期限は、実際の体制に合わせて設定します。

自動化する部分を絞っても、未対応の一覧、対応担当、受付日時、連絡履歴は必要です。スタッフがトークを開いたことだけを対応完了とすると、途中で作業が中断した際に依頼が埋もれます。管理上は「未対応」「調整中」「確定」「受付終了」のように業務状態を残します。

後日の確定連絡に、受付時のreply tokenを使わない

Messaging APIの応答トークンは1回だけ使用でき、Webhookの受信から1分以内の使用が求められます。ネットワーク状況等で使える期間は変わるため、1分間使えることを前提に待たせる設計にはしません。公式の応答トークン仕様

スタッフが数時間後に判断する場合は、運用するチャット機能、条件を満たすPush送信、予約確認画面など、別の連絡経路を決めます。受付時の応答用トークンを保存して、後日そのまま返信する構成は採りません。

スプレッドシートは受付一覧の候補になりますが、使う場合は共有先、編集権限、担当交代、バックアップを決めます。GASなどでWebhookを直接受ける構成は、署名検証を含む受信方法と同時実行時の挙動を個別に確認する必要があります。「シートに書き込めた」という確認だけでは、本番の予約受付を任せられるか判断できません。

構成2：同じ予約台帳で空き枠を確保し、自動確定する

自動確定では、希望を受け付けた後に、営業時間、必要設備、担当者、定員などを確認し、枠を確保できた場合だけ予約を確定します。候補の提示と確定処理は別です。空き枠を表示してから送信ボタンを押すまでに、別の利用者や電話受付がその枠を取ることがあります。

開発上の要点は、空き確認と枠の確保を、競合が起きても矛盾しない処理にすることです。既存の予約DBを業務の正として使っているなら、LINEからの予約も、そのDBの予約作成・変更処理を通します。LINE用の別シートで確定してから後で転記すると、転記までの間に同じ枠を販売してしまいます。

実装方法としては、既存システムの競合を防ぐ予約API、DBのトランザクション、条件付き更新などを検討します。これは予約システム側の設計であり、LINEのMessaging APIが提供する枠管理機能ではありません。

確認項目	開発前に確かめること	条件を満たさない場合の案
既存DBへの登録	空き確認と確保を一つの処理として実行できるか	スタッフ承認にする、既存システム側の改修を見積もる
電話・店頭予約	同じ枠管理へ登録できるか	自動確定の対象枠を業務上分ける、半自動で運用する
カレンダー連携	表示用の同期か、確定処理の窓口か	カレンダーは予定の表示先にし、予約DBを正にする
複数設備・担当者	同時に必要な資源をまとめて確保できるか	対象メニューを絞る、複雑な予約は有人受付にする
通信切断	登録結果が不明でも同じ予約を二つ作らないか	依頼IDで結果を照会できる連携方式を採る

Googleカレンダー等を参照して予定を追加するだけで、複数経路の二重予約を防げるとは限りません。採用するAPIの競合制御や、スタッフが直接編集する場合の扱いを確かめます。既存システムに必要なAPIがなければ、その制約を見積もり前に明示します。

構成3：予約画面で、選択・変更・取消を完結させる

メニューや担当者が多い場合は、カレンダーや入力フォームを持つ予約画面が候補になります。LINEミニアプリはLIFF上で動くWebアプリで、未認証と認証済では利用条件や機能に違いがあります。LINEミニアプリの公式説明

方式はLIFFとLINEミニアプリの比較で確認し、予約業務側では次を設計します。

• 日時・店舗・担当・料金など、確定前に確認してもらう情報。
• 入力途中で画面を閉じた場合の保存範囲と、仮確保を解除する条件。
• ログイン中の利用者が、自分の予約だけを参照・変更できる権限。
• キャンセル期限を過ぎた場合の、有人窓口への案内。
• 予約完了画面から、後で最新の予約状態を確認する導線。

LINEログイン、友だち追加、自社の会員IDとの連携は別に整理します。表示名を会員の照合キーにせず、本人確認と予約の参照権限をサーバー側で確認する設計にします。連携の前提はLINE APIでできること・できないことも参照してください。

変更・取消と通知を、予約状態から分けて管理する

予約の状態と、メッセージの送信状態は別に保存する設計を勧めます。予約DBに登録済みでも、確定メッセージの送信に失敗することがあるためです。

処理	予約側に残すもの	利用者へ示す内容	失敗した場合の扱い
希望の受付	受付ID、希望、受付時刻、担当	まだ未確定であることと回答予定	受付できたか照会できる導線を用意
予約の確定	予約ID、確保した枠、確定日時	確定した日時と確認先	DB登録と通知結果を別に確認
日時変更	変更前後、現在の版、処理結果	現在有効な予約内容	新しい枠の確保に失敗したら元の予約を維持
取消	取消日時、操作者、処理結果	取消完了と必要な注意事項	重複操作でも枠を二重に解放しない
リマインド	通知予定、対象の予約ID・版	送信時点で有効な予約内容	変更・取消済みなら古い通知を停止

日時変更は、先に元の予約を消してから新しい枠を探すと、変更先が満席だった際に元の予約も失います。既存APIの機能に合わせ、変更全体を成功・失敗のどちらかに揃えるか、仮確保と復元の手順を設計します。

「APIが200を返した」を到達確認にしない

Pushは送信対象に条件があり、友だちではない利用者への送信には直近の1対1のメッセージ受信などの条件があります。また、ブロックした利用者等には、APIが200を返しても届かない場合があります。公式のPush送信条件

そこで、予約は確認画面やスタッフの台帳で照会できるようにし、「通知が届かない＝予約されていない」という誤解を防ぎます。到達をAPI応答だけで判定できないことを前提に、重要な変更は利用者の確認操作を求めるなど、業務に合った確認方法を決めます。電話やメールを併用する場合は、取得目的と連絡方法を予約時に案内します。

Webhookの重複と、利用者の二重操作を両方扱う

Messaging APIで予約操作を受ける場合は、処理前に署名を検証します。検証には未加工のリクエスト本文を使い、JSONの整形や再シリアライズをした本文へ置き換えません。公式の署名検証手順

Webhookは重複や順序の逆転が起こり得ます。公式資料ではwebhookEventIdで重複を検出する方法が示されています。再送を有効にしても、すべてのイベントの再送が保証されるわけではありません。Webhook受信・再送の仕様

予約側では、これに加えて同じ確定ボタンの連打、通信切断後の再操作、スタッフと利用者による同時変更を確認します。異なるWebhookイベントとして届いた操作でも、同じ予約依頼なら二重登録しないための依頼IDや状態の検査が必要です。受信IDだけで予約業務全体の重複を解決しようとしないことがポイントです。

架空例：面談予約で、最後の1枠に申し込みが重なったら

以下は設計を考えるための架空例です。30分の面談を受け付け、電話とLINEの両方から同じ予約DBへ登録する事業を想定します。

利用者AとBが同じ15時の枠を選んだとき、Aの確保が先に成立したら、Bには別候補を案内します。二人とも同じ空き枠画面を見ていたとしても、確定結果はDBでの確保結果に従います。

続いてAへの確定通知だけが失敗しても、Aの予約を取り消したり、もう一度予約を作ったりしません。通知処理を確認対象にし、Aは予約確認画面から確定済みの状態を見られるようにします。スタッフも同じ予約IDを使って案内できます。

翌日、Aが16時へ変更したら、15時の予約に対して用意していたリマインドを無効にします。通知を送る直前にも予約の現在の版を確認する設計なら、古い日時の案内を送る事故を抑えられます。

この例では、画面数よりも、共通の予約台帳、確保処理、通知の分離が開発の中心です。LINE上の見せ方から見積もりを始めると、これらの作業を見落としやすくなります。

費用は、初期開発と毎月の運用に分けて試算する

初期開発では、受付画面・トーク、予約DB連携、変更・取消、スタッフ用機能、移行、試験を分けます。毎月の費用には、LINE公式アカウントの利用、サーバー、予約サービス、保守、スタッフの確認作業を含めます。同じ「LINE予約」でも、既存DBの連携条件によって作業量が変わるため、一律の開発相場は示しません。

通知通数は「予約件数×予約1件あたりの送信回数」に、変更連絡や販促等を加えて見積もれます。たとえば、月300件に対して1人宛てのPushを確定時と前日に1回ずつ送り、変更連絡を60回送る想定なら、計画上は300×2＋60＝660通です。これは全送信が通数に数えられると仮定した架空の計算で、実測値や料金見積もりではありません。

Messaging APIではPush等が料金プランの通数に数えられ、応答メッセージは数えられません。吹き出しの数と課金通数も同じではないため、採用する送信方法で計算します。Messaging APIの料金・通数の数え方

見積書ではLINE開発の見積もり比較を使い、通知費用を抑えることと、スタッフの作業を減らすことを同じ表で比較すると判断しやすくなります。

公開前の受入確認表

以下は開発会社と業務担当者が合意するための確認項目案です。採用した構成に合わせ、担当・結果・証拠を記入します。実際の顧客データを使わずに確認できる試験用の予約・アカウントを用意します。

確認場面	合格条件の例	主な確認担当
半自動で希望を送る	受付と確定が明確に分かれ、未対応一覧へ残る	業務担当
営業時間外に希望を送る	回答予定と緊急時の連絡方法を案内する	業務担当
残り1枠へ同時に申し込む	定員を超えて確定せず、取れなかった側へ別案を示す	開発・業務担当
電話とLINEから同じ枠を登録する	同じ台帳の競合制御が両方に適用される	開発・業務担当
同じ確定操作を再送する	同じ依頼を二重登録しない	開発担当
署名が不正なWebhookを送る	予約・通知等の業務処理を実行しない	開発担当
登録直後に通信が切れる	予約IDや依頼IDから結果を照会できる	開発担当
変更先の枠が満席になる	元の予約が意図せず消えない	業務担当
取消操作が重複する	定員や返金等を二重に処理しない	開発・業務担当
変更後に古い通知予定が残る	送信時に現在の予約を確認し、古い内容を送らない	開発担当
通知が届かない	台帳と確認画面で状態を確認でき、必要な案件は担当へ回る	業務担当
別の利用者の予約IDを指定する	本人以外の予約を表示・変更できない	開発担当
既存DBやLINE連携が停止する	新規受付の制限と、既存予約の有人確認手順が使える	保守・業務担当

項目を相談資料へ落とし込む際はLINE開発の要件定義テンプレート、継続的な監視や再試行はLINE Botの本番運用を参照してください。

よくある質問

LINE予約システムは無料で自作できますか？

既存のLINE公式アカウントとスタッフによる受付を組み合わせ、小さく始めることはできます。ただし、スタッフの確認作業、保守、外部サービスや送信の費用までゼロになるとは限りません。自動化する範囲と継続費用を分けて比較してください。

カレンダー連携だけで二重予約を防げますか？

空き予定の参照と予定の追加だけでは、同時の申し込みを防げない構成があります。電話や店頭を含む予約経路が同じ枠管理を使い、空き確認と確保を矛盾なく処理できることを確認します。実現できない場合はスタッフ承認などの運用を検討します。

予約にはLINEミニアプリが必要ですか？

必須ではありません。トークで希望を受け付ける方法や、既存の予約ページへ案内する方法もあります。日時・担当者・メニューの選択が複雑で、変更や取消も画面で完結させたい場合に、ミニアプリを含む予約画面の開発を検討します。

確定メッセージが届かなかったら予約は取り消しますか？

予約の確定状態と通知結果は別に管理し、通知の失敗だけを理由に自動で予約を取り消さない設計にします。利用者が確認画面で状態を見られるようにし、必要に応じてスタッフが確認します。APIの200応答だけでは利用者への到達を確認できません。

この記事に関連するサービス

TodoONadaでは、受付業務と既存システムの条件を整理し、LINEで実現する範囲をご提案します。現在の予約台帳、電話・Webの受付経路、変更・取消のルールをもとに、半自動受付と自動確定を比較できます。

LINEアプリ開発のサービス・相談窓口を見る