AIに予約変更を作らせた。希望の時間が予約済みでも元の予約は残るのか
美容室デモへ日時変更を追加し、希望の時間が予約済みでも元の枠を失わないか公開環境で検証しました。
予約を取り直すために、いったん元の予約を消すのは少し怖いものです。変更先が直前に埋まったら、両方を失うかもしれません。
今回の問いは一つです。
AIに予約変更を作らせたら、変更先が埋まっていても元の予約を残せるか。
先に結論
変更先が予約済みのときは 409 Conflict で止まり、元の予約はそのまま残りました。空いている時間へ変えたときだけ 200 OK となり、元の枠が空き、変更先が予約済みになりました。
作ったもの
- 予約後に表示される日時変更フォーム
- 変更先の空きをサーバーで確認する処理
- 変更先が埋まっていれば元予約を保持する処理
- 空いている場合だけ一度の更新で日時を変える処理
- 受付番号と秘密のキーによる照合
大事なのは、元の予約を消してから空きを調べないことです。同じ保存先をロックし、変更先が空いていると確認できた場合だけ日時を書き換えます。
公開環境での検証
2026年9月7日、独立した二つの接続から同じ担当者の予約を作って確かめました。
| 操作 | 結果 |
|---|---|
| 元の時間を予約 | 201 Created |
| 別接続で変更先を予約 | 201 Created |
| 埋まった時間への変更 | 409 Conflict |
| 元の予約が残っていることを確認 | 10:00 を保持 |
| 空いている時間への変更 | 200 OK |
| 元の枠が空いたことを確認 | 10:00 が空き、16:00 が予約済み |
変更失敗後も元の予約は残り、空いている時間への変更だけ成功しました。今回の最小条件は合格です。 検証用に作った予約は最後に削除しました。
サーバーがあると便利だった部分
別の画面から同時に操作されても、全員が同じ空き状況を見られる点です。ブラウザだけで見た目を変えるのではなく、予約の確認と更新をサーバー側でひと続きにできます。
ただし、独自の予約変更が不要なら、既存の予約サービスの方が簡単です。自分の店に合わせた流れを作りたいときに、サーバー側の処理を置ける環境が選択肢になります。
まだ作っていないもの
ログイン、確認メール、変更履歴、通知、キャンセル料、返金、本物の顧客情報管理は未実装です。今回は「変更に失敗しても元予約を失わない」という一点だけを検証します。