WORXMT.FUJI

何を重なりとみなすかは、施設の使われ方に合わせています。ビジターやコワーキングはフロアを共有するので互いを妨げず、会議室は時間帯が重なったときだけ、1日貸切はその日のすべての予約とぶつかります。カレンダーには空いている枠しか出しませんが、開いてから送信するまでに埋まることがあるので、サーバーは書き込む前にもう一度確かめます。ほぼ同時に届いた2件はどちらもこの確認を通ってしまうため、登録した後にその日の予約を読み直し、先に入った予約と重なっていれば自分を取り消します。「先」は作成時刻で決め、同時なら予約IDで決めるので、2件の順番の見方が食い違うことはなく、両方が取り消し合うこともありません。取り消す側は、メールを送る前に消えます。

スタッフが登録・変更する予約がほかと重なる場合は、止めずに警告し、承知の上で保存できるようにしています。保存した後にもサーバーで確かめ直します。確認から保存までの間に、Web予約やもう一人のスタッフが同じ枠を押さえているかもしれないためです。確定とキャンセルは、想定した状態のままの予約にだけ効くので、お客様が同じ瞬間にキャンセルした予約を確定で上書きすることはなく、スタッフには状態が変わっていると伝えます。お客様のキャンセルも同じ仕組みで、実際に行が変わったときだけメールを送るので、二重に押しても2通は届きません。キャンセル済みの予約は元に戻せません。その枠がほかの人に渡っているかもしれないため、登録し直す運用にしています。

受付メールのリンクは予約IDにHMACの署名を付けたもので、受け取った本人だけが確認とキャンセルをできます。そのためにデータベースへ何かを保存することはありません。前日17時というキャンセルの締切は、サーバーの時計がどのタイムゾーンでも日本時間で計算し、月末や年末をまたいでも正しく出ます。マイページはメールでログインします。15分有効のリンクから30日間のhttpOnly Cookieに切り替わり、2つは別の用途として署名しているので、互いの代わりには使えません。ログインの画面は、そのアドレスに予約があってもなくても同じ応答を返し、メールは応答した後に送ります。応答時間からも、予約の有無が分からないようにするためです。

管理画面はCloudflare Accessの内側にあり、許可したメールアドレスにだけワンタイムコードが届きます。アプリ側はそれを前提にせず、管理用の操作のたびにAccessが署名したトークンを自分で検証します（発行元、対象、署名方式、許可リストにあるメールアドレス）。Accessの設定が漏れていても、workers.devのアドレスに直接来たリクエストでも、予約データは返りません。設定そのものがなければ、開けずに拒否します。データベースは行レベルセキュリティを有効にしたうえでポリシーを置かず、公開用のロールには権限を与えていません。名前・メール・電話番号に触れられるのは、server-onlyを付けたモジュールでサービスキーを持つサーバーのコードだけです。

動いているのはCloudflare Workersの無料プランで、1リクエストあたりのCPU時間は10msまでです。incremental cacheが未設定だったため、ビルド時に生成したページまでリクエストのたびに描画し直し、この上限を超えてError 1102を返していました。いまは生成済みのページを静的アセットのキャッシュから、Next.jsの処理を通さずに返しています。マイページや予約の確認ページ、管理画面のように見る人によって変わる部分はブラウザ側で読み込み、データはサーバーアクション経由で取るので、ページ自体は静的なままです。