
受付番号とイベントを組にする
参加者40名のワークショップを例に、一人に一つの受付番号を発行します。同じ番号体系を別の日にも使うなら、イベントIDと受付番号の組で照合します。番号だけで検索して、前回の参加者を今回の来場者として扱わない設計にします。最初の版は受付済みと未受付の判定、手入力検索、担当者の操作履歴までを対象にします。チケット販売や座席交換を同時に作らず、受付時に参照する名簿をどこで確定し、誰が訂正できるかをAIへ説明してから画面を作ります。
参加名簿と入場記録を分ける
registrationsにはイベントID、受付番号、参加資格の状態、確認に必要な最小限の情報を保存します。checkinsには受付ID、受付時刻、担当者、端末、操作キーを記録します。名簿の行へ氏名だけを書き換えて入場済みを表すのではなく、どの登録に対する操作か追えるようにします。受付担当には担当イベントの検索だけを許し、他の日の名簿や申込み内容を必要以上に取得しない構成にします。公開する確認ページが必要な場合も、推測しやすい連番だけで参加者情報を表示しない方法を別に決めます。
番号の読取後にサーバーで判定する
カメラや読み取り機から得た番号は入力値として扱い、そのまま入場済みへ変更しません。形式、イベント、参加資格を確認し、取り消された申込みや別イベントの番号なら明確な理由を表示します。読み取り機を使わなくても同じ判定を通る手入力の経路を用意します。AIには文字列の前後の空白など、許容する正規化だけを指定します。桁を勝手に補ったり、似た番号を最も近い参加者へ置き換えたりしません。候補検索と入場確定は別の操作として作ります。
同伴者をまとめて受け付ける場合も、一つの代表番号で人数だけを加算するか、参加者ごとの入場を残すかを決めます。名簿の定員と実際の受付人数を別々の数値として確認します。

一回だけ成立する入場処理を作る
サーバーの一つの処理で未受付かどうかを確認し、入場記録を保存します。イベントと登録の組に対する一意性などを使い、二つの受付端末が同時に操作しても有効な入場が二件にならない構成にします。保存が終わるまでは処理中と表示し、成功してから受付完了へ進めます。同じ操作キーの再送なら元の結果を返し、別端末からの二回目なら受付済みの日時を担当者へ示します。ボタンの連打防止だけに頼らず、データベース側でも重複を止める設計を確認します。
三つの受付番号で動きを照合する
練習用に有効な参加者E-001、取消済みE-002、別イベントのE-003を用意します。E-001は一回目だけ成功し、二回目には受付済み、残りはそれぞれ別の理由で停止することを期待結果にします。これは受入確認の例であり、実際のイベントで検証済みという意味ではありません。二つの端末でE-001をほぼ同時に送り、再読込後の入場件数が一件であることも照合します。成功の色や効果音だけで判断せず、管理用の記録と同じ受付IDになっているかを見ます。
| 練習用の入力 | 期待する結果 | 確認する記録 |
|---|---|---|
| 有効なE-001を初回送信 | 入場を一件保存 | イベントと受付番号 |
| E-001を二端末から送信 | 有効な入場は一件 | 重複と受付時刻 |
| 取消済みE-002 | 入場しない | 取消状態 |
| 別イベントのE-003 | 対象外と表示 | イベントID |
通信切れを受付完了と表示しない
通信が途切れたときは未送信または結果不明と表示し、端末が番号を読めたことだけで受付完了にしません。再接続後は同じ操作キーで結果を問い合わせ、すでに保存されていれば元の受付結果を表示します。二台が同時にオフラインの場合、各端末だけでは相手の受付状況を把握できません。オフライン受付を必要とするなら、入口を分担する、紙の台帳へ切り替える、後で保留分を照合するなどの運営手順を決めます。単にブラウザーへ保存しただけで全端末の二重入場を防げるとは考えません。
番号は架空の練習データです。通信切れ中に読み取れたことだけで入場確定とはしません。
端末数と受付の集中時間で費用を考える
Cursorでコードを作る費用と、開催中に動くサーバーやデータベースの費用を別に記録します。月の参加者数が少なくても、開場直後に複数端末から操作が集中するため、読み取りと保存の応答時間は練習環境で確かめます。画面の常時更新が本当に必要かも検討します。機器購入、ネット回線、充電や予備端末はソフトウェア契約とは別の費用です。最初は一イベント、一入口で運営手順を固め、複数入口や再入場を追加する場合は、入場回数と権限の仕様を改めて整理します。
訂正と終了後の保管を決める
誤って受付した場合は、管理者が元の入場記録を指定して訂正し、理由と操作者を残します。一般担当者が件数を合わせるために履歴を削除できる設計にはしません。再入場を認めるイベントなら初回入場と再入場の記録を区別し、重複エラーを迂回して使わないようにします。終了後は受付担当の権限を見直し、参加者データの保管期間を決めます。入口で使う画面には次の参加者の情報を残さないようにし、イベントID、受付番号、保存された結果を照合してから本番の運用へ渡します。
参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- PostgreSQL — Constraints情報確認日: 2026-10-30
- PostgreSQL — Explicit locking情報確認日: 2026-10-30
- Next.js — Forms情報確認日: 2026-10-30
- Cursor pricing情報確認日: 2026-10-26
- Cursor models and pricing情報確認日: 2026-10-26
- Cursor Agent overview情報確認日: 2026-10-26