GPT-Liveで予約受付を作る｜空き確認・変更・取消の設計
仕様確認・更新日: · 編集: 株式会社ウェステリア
予約受付で大切なのは、会話が終わったときに正しい予約が残ることです。日時の言い直し、人数変更、空き枠の変化、通話の切断を前提に、会話と予約システムの状態を揃える設計が必要です。
結論から
- 希望条件の聞き取り、空き確認、同意、予約確定を別の段階として扱います。
- 音声の割り込みと、実行中の予約処理の取消は別です。
- 予約IDと処理結果を管理し、重複登録と不確かな完了案内を防ぐ設計にします。
音声を止めても、予約処理は止まらない
GPT-Liveの公式ガイドは、発話への割り込みがバックエンドの処理を自動的に取り消すわけではないと説明しています。『やっぱり別の日に』という発言を受けた際に、どの処理を止め、どの内容を再確認するかはアプリケーション側で扱います。
予約の流れを5段階に分ける
この段階分けは当社の設計例です。予約システムに仮押さえ機能があるか、確認中に空きがなくなり得るかによって実装を調整します。予約の成功はAIの返答から判断せず、システムの確定結果で判断します。
| 段階 | 確認・実行すること |
|---|---|
| 1. 条件を聞く | 日時、人数、サービス、店舗など必要な条件を揃える |
| 2. 空きを調べる | 予約システムの最新の空き枠を取得する |
| 3. 内容を確認する | 選んだ枠と条件を読み上げ、利用者の同意を得る |
| 4. 予約を登録する | 権限と空き状況を再確認し、登録結果を保持する |
| 5. 結果を伝える | 成功した予約の情報、または失敗時の次の行動を案内する |
言い直しで古い条件を使わない
例えば『2026-10-03の午前に2名』で検索中に『午後、3名に変更』と訂正された場合、午前2名の検索結果をそのまま案内しないようにします。検索した条件と結果を対にして保持し、最新条件に合う結果かを確認します。
登録前なら内容を再確認し、登録済みなら新規受付とは別に変更処理へ進みます。『いま確定済みなのか、まだ候補なのか』を追えるようにすると、担当者が後から確認する場合にも役立ちます。
重複登録と途中切断に備える
同じ依頼や通信の再試行を受けても、予約を二重に作らないよう、処理を識別する番号や予約IDを記録します。予約APIの返答が遅れた場合、失敗したと決めつけて再登録せず、実際の結果を照会する手順を設けます。
予約が確定した直後に電話が切れる場面もあります。確認画面や通知など、利用者が結果を確かめる手段を設計します。メールやSMSを使う場合は、宛先の確認や送信機能も開発範囲に含めます。
変更・取消には本人確認と業務ルールがある
予約番号を知っているだけで変更できてよいかは、サービスのルールによります。確認する情報、変更できる期限、取消時の案内、担当者判断が必要な条件を整理します。これらを会話の指示だけに任せず、予約処理を行う側でも確認します。
最初の試作では、架空の予約データで、新規・訂正・満席・二重依頼・途中切断を試します。現場が例外として扱うケースを先に共有すると、運用開始後の手戻りを減らせます。
よくあるご質問
- APIがない予約システムでも連携できますか？
- 連携手段と提供会社の対応範囲を調査します。安全に確定処理へ接続できない場合は、希望条件を受け付けて担当者に渡す範囲から始める方法があります。
- 予約を間違えないことを保証できますか？
- 一律の保証はできません。必要な確認、システム側の検証、例外時の引き継ぎを設計し、実際の業務シナリオで合否を確認します。