LINEの日時選択は予約確定ではない｜希望日時・空き枠・時間帯の確認

LINEで日付や時刻を選ぶ画面を出しても、選んだだけで予約が確定したことにはなりません。Messaging APIの日時選択アクションは、選択結果をポストバックイベントとして受け取るための機能です。空き枠の確認や予約の登録は、業務側の処理として分けて設計します。

この記事は、開発担当者と予約業務の担当者が、どの段階を「完了」と表示するか決めるための確認です。Webhook自体に応答できない場合はポストバックを受け取った後の確認を参照してください。

受け取れるのは、ユーザーが選んだ日時

日時選択アクションの公式仕様では、選択した結果がWebhookのポストバックイベントに含まれます。modeによって、postback.paramsで確認する項目が異なります。

日付だけを受け取ったのに、時刻も決まった予約として登録しないようにします。時刻だけなら、どの日の時刻なのかも業務側で確かめます。画面のラベル、設定したmode、処理で読む項目を並べると、食い違いを見つけやすくなります。

架空の日時選択の設定例です。実際の予約機能や、LIFEが提供済みの受付フローを示すコードではありません。

{
  "type": "datetimepicker",
  "label": "希望日時を選ぶ",
  "data": "pick_slot",
  "mode": "datetime"
}

この例では、選択結果はpostback.params.datetimeを読みます。dataは「何の選択だったか」を処理側で識別する値、paramsは選ばれた日時として分けます。公開リンクやdataへ顧客の氏名・電話番号などを直接埋め込まない設計にしてください。

initialは選択画面の初期値、minとmaxは選択できる日付・時刻の最小値と最大値です。範囲を指定しても、その間のすべての日時に空きがあることや、店休日を除外できたことの証明にはなりません。

たとえば、月内の希望日時を選べるようにした架空の受付なら、次に店舗・サービス・所要時間と、実際の空き枠を照合します。選ばれた日時が既に埋まっていた場合は、まだ予約を登録していないことを伝え、変更の案内を用意します。

受信後の検証で、選択範囲や受付条件も確認します。古いメッセージから選ばれた日付が、現在の受付期間にも合うとは限りません。画面の範囲設定だけに処理の判断を任せないようにします。

希望日時を予約へつなぐ確認図。LINEで日時を選ぶ、希望日時として受け取る、時間帯と対象サービス・空き枠を確認する、予約登録の結果を確かめてから確定を案内する順に分ける。枠が合わない場合は未確定と伝えて変更を案内し、日時選択だけを予約完了にしない。

図は開発・運用上の設計例です。LINEの日時選択機能に、空き枠検索や予約登録が標準で備わっているという意味ではありません。

公式仕様では、日時選択アクションはタイムゾーンの違いに対応していません。返されるdatetimeの形式も、日付と時刻を組み合わせたもので、タイムゾーンを表す部分はありません。

予約業務でどの時間帯として解釈するかを決め、確認画面や案内へ明記します。たとえば日本の店舗で日本時間として受付する設計なら、「日本時間の希望日時」と案内し、保存先の日時の扱いともそろえます。

海外から利用する人がいる場合は、端末の場所や日時だけから、お客さんが希望した時間帯を推測しません。どの時間帯の選択か、最終確認で分かる案内にします。単に末尾へタイムゾーンの文字を付ければすべて解決する、という処理にはしないでください。

予約がまだ成立していない段階では、架空の案内例として「希望日時を受け付けました。空き枠を確認します」と表示できます。ただし、自社で実際に行う確認方法や返答の予定に合わせて書き、未提供の確認担当や即時の返答を約束しないようにします。

確定の案内は、予約登録の結果を確認できた段階にします。Webhookへ正常なHTTP応答を返したこと、返信メッセージが送れたこと、予約システムへの登録が終わったことを同じ成功として扱いません。

画面や担当者が変わる場合は、選択した日時、対象のサービス、確認済みの時間帯、まだ決まっていないことを引き継ぎます。お客さんに再び同じ内容を入力してもらう前に、どの情報が既に受け取れているかを確認してください。問い合わせや希望を、一人の顧客の記録として追える状態にするための設計判断です。

※仕様確認日：2026年10月13日。APIの形式は公式資料、予約の判断順と会話は架空の設計提案です。