予約・在庫サイトは「同時申込み」まで設計していますか

予約フォームや在庫表示は作れても、残り1枠へ2人が同時に申し込んだ場合まで考えられているでしょうか。

画面上で「残り1」と表示されていても、保存時には片方だけを成立させる必要があります。ボタンの連打防止だけでは、別端末からの同時申込みを防げません。

【最初に決めること】

・何を1単位として確保するか

・送信、承認、決済のどの時点で確定するか

・仮押さえを何分保持するか

・取消時に枠や在庫をどう戻すか

・競合した人へ何を案内するか

この業務ルールが曖昧なままAIへ実装を頼むと、見た目は動いても運用で矛盾が起きます。

【サーバー側の再確認が必要です】

保存直前に現在の空き数を再判定し、成功した処理だけが確保数を更新します。データベースの条件付き更新や制約、WooCommerceなど既存プラグインの在庫管理機能を用途に合わせて利用します。

WordPress標準REST APIを使う場合も、ブラウザから送られた残数を信用しません。権限と入力値を検証し、競合時は「直前に枠が埋まりました」など、理由と次の選択肢を返します。

【再送による重複も防ぐ】

通信状態によって同じリクエストが再送されることがあります。二重タップだけでなく、同じ注文番号や予約識別子が2回登録されない仕組みが必要です。

【AIへの指示に含める項目】

・既存プラグインとデータ保存先の調査

・保存直前の空き再判定

・同時更新を守る方法

・API再送時の重複防止

・競合時のメッセージと代替導線

・取消・期限切れ時の枠戻し

・2端末からの同時送信試験

【公開前チェック】

1. 残り1枠のテストデータを作る

2. 別ブラウザで同じ画面を開く

3. ほぼ同時に送信する

4. 成功が1件だけになることを確認する

5. 残数、取消、再送時の動作を確認する

予約・在庫サイトでは、フォームが送れることより、同時アクセスでもデータが矛盾しないことが重要です。CodexやClaude Codeへ実装を任せる際も、業務ルールと検証条件を具体化し、結果を開発ログへ残すことが再現性につながります。