「予約フォームは作れたのに運用できない」を防ぐ設計

CodexやClaude Codeを使うと、WordPressに予約画面を用意する作業は早く進められます。ただし、実務サイトでは画面よりも先に決めることがあります。

それが「同じ時間へ申込みが重なった場合、どの時点で予約を確定するか」です。

【フォーム送信＝予約確定ではありません】

問い合わせフォームへ希望日時を追加しただけでは、空き枠の競合を判断できません。予約機能として運用するには、仮受付・確定・取消・満席または受付停止を分けます。

自動返信文にも「受付」と「確定」の違いを明記します。ここが曖昧だと、利用者と運営者で認識がずれます。

【AIへ渡すべき5つの条件】

1. 予約対象：担当者、部屋、設備、座席など

2. 占有時間：サービス時間と前後の準備時間

3. 確定条件：自動確定か運営確認か

4. 取消条件：期限、料金、枠を戻すタイミング

5. 競合時の表示：別日時の提示、キャンセル待ちなど

「予約サイトを作って」という一文だけでは、AIは業務固有の判断を補えません。条件表とテストケースを渡すことで、実際の運用に近い設計になります。

【WordPressを所有型の予約基盤にする】

WordPress標準REST APIを使えば、予約枠、申込み、担当者、通知履歴などを構造化して扱えます。無料プラグインを使う場合も、権限、バックアップ、スマートフォン管理、データ移行を確認します。

【公開前に試すケース】

・2人が同じ枠を同時に申し込む

・通信途中で画面を閉じる

・仮押さえ期限が切れる

・担当者だけ変更する

・キャンセル後に枠を再公開する

・通知メールが届かない

制作を速くするのは完成ページではなく、業務を分解してAIへ伝える「設計の型」です。予約サイトでは、まず「いつ、誰が、何を確定するか」から整理すると、制作も改善も進めやすくなります。