QRバッジを使った来訪者チェックインアプリ：データモデルとフロー

チェックインフローが解決すべき問題

チェックインフローは単なるデジタルなゲストブックではありません。誰が中にいるか、誰と会うのか、次に何をする必要があるかを決めます。うまくできていれば受付は落ち着いて運用でき、後で信頼できる記録が残ります。

紙のサインインは予測可能な失敗をします：名前が誤記される、時刻が抜ける、サインアウトを忘れる。カウンターに置かれたシートは誰でも過去の記録を見られるため個人情報を露出しがちです。状況が急変したとき（ホストが会議で捕まっている、来訪者の安全質問で赤旗が立つ）には、スタッフが電話で人を追いかけ回すことになります。

良い結果はシンプルです：チェックインは1分未満、バッジは明瞭でスキャン可能、ホストには適切なアラートが届き過剰通知はしない。各訪問は「誰が／いつ／どこで／なぜ／何に回答したか」がきちんと残る記録になり、監査や調査のためにエクスポートできます。

設計を始める前にスコープを固定してください。多くのチームは最初にいくつかの訪問タイプを定めます：オンサイトのゲスト、契約業者（追加の安全手順が必要な場合が多い）、配送（バッジ無しだがタイムスタンプは必要なことがある）、面接（よりプライバシー要件がある）など。

また、体験がどこで行われるかを決めてください。キオスクタブレットは速度と一貫性に最適です。受付向けウェブアプリは例外処理、修正、再印刷に向いています。モバイルオプションはホストや警備が受付から離れてQRチェックインを検証するのに役立ちます。

役割、権限、追跡すべきイベント

来訪者チェックインアプリは2つの要素で成否が分かれます：明確な役割とクリーンなイベント履歴。どちらかが不明瞭だと、アラートの見落とし、乱れたエクスポート、誰も信頼しないログが残ります。

想定する役割

最初はシンプルに保ちます：

• Visitor：自身の情報を入力し質問に答えるが、他の訪問を見られない。
• Host：自分に割り当てられた訪問を見て到着を承認し、エスコートなどのアクションを要求できる。
• Receptionist（受付）：訪問を作成し、チェックイン時の明白な誤字を修正し、バッジを再印刷し、チェックアウトを行う。
• Security（警備）：現在の在席を確認し、緊急の点呼をサポートし、インシデントノートを確認する。
• Admin：サイト、ポリシー、エクスポート（保持ルール含む）を管理する。

権限境界は個人データとレポーティングにおいて最も重要です。誰が電話番号、ID情報、来訪者写真を見られるか、誰が来訪履歴をエクスポートできるかを早めに決めてください。一般的なルールは：フロントデスクがフローを運用し、セキュリティは現在の在席を見られ、フル履歴をエクスポートできるのは管理者だけ、です。

いつも記録すべきイベント

単一の「訪問」行を編集して終わりにするのではなく、イベントとして考えてください。監査やトラブルシューティングで後で必要になる瞬間は次の通りです：

• チェックイン完了（タイムスタンプ、デバイス、サイト）
• バッジ発行（バッジID、QR値、印刷者）
• ホスト通知（使用チャネル、配信状況）
• 安全質問の回答送信（どの質問セット／バージョンを表示したか）
• チェックアウト（誰がいつどのようにチェックアウトしたか）

重要イベントは監査可能で追記型にしてください（チェックイン、通知、チェックアウト）。頻繁に間違うフィールド（名前の綴り、会社名など）に対しては限定的な編集を許可し、何が誰によって変更されたかを記録してください。

コアデータモデル：来訪者、訪問、バッジ、サイト

信頼できるシステムはクリーンなモデルから始まります。重要な考え方は「人」と「その人がオンサイトに来た出来事」を分離することです。繰り返し来る来訪者は一つのレコードに留まり、到着ごとに新しい訪問（Visit）が作られます。

まずは2つのコアテーブル：Visitors と Visits。

• Visitor は人物（名前、電話、メール、会社、任意の写真やIDメモ）です。
• Visit は単一の出来事（日付、目的、会う相手、行き先）です。

1人のVisitorは多数のVisitsを持ちます。

業務に合わせてHostsとSitesを追加してください。ホストはアラートを受け取る従業員やテナント、サイトは物理的な場所（本社、倉庫A）を表します。後からゾーン（ロビー、フロア、立入制限区域）を追加しても基本は壊れません。

実際に必要なテーブル

小さく保ちます：

• Visitors
• Visits
• Hosts
• Sites
• Badges
• Devices（キオスク／タブレット／プリンター）

バッジはVisitorに恒久的に割り当てるのではなく、Visitに割り当ててください。これによりバッジ在庫の再利用、紛失、二重印刷の混乱を避けられます。

真実を語るステータスとタイムスタンプ

訪問にはスタッフが口にする状態に合うステータスとタイムスタンプが必要です。少なくとも created_at、checked_in_at、checked_out_at、canceled_at（またはキャンセルフラグ）を保存し、次のような明確なステータスと組み合わせます：scheduled、arrived、checked_in、checked_out、no_show、canceled。

例：10:00に予定された人が9:55に到着（status: arrived）、質問に答えてQRバッジを受け取ると（status: checked_in）となります。もしチェックアウトをしないまま去った場合でも、checked_in_atが残り、後で明示的なルールで処理できます。

安全質問：質問と回答のモデル化方法

安全質問は後で履歴を信頼できる形で残せないと役に立ちません。よくあるミスは回答を来訪者プロフィールに保存してしまい、前回の回答が上書きされることです。質問はテンプレートとして扱い、回答は来訪ごとの記録にしてください。そうすれば各チェックインにスナップショットが残ります。

シンプルな構成が有効です：

• Question Template は何を尋ねるかを定義します。
• Visit Answer は特定の訪問での回答を記録します。

質問テンプレートと来訪ごとの回答

テンプレートは安定させ、回答には表示された正確な文言（またはテンプレートバージョン）を保存してください。後で文言を更新しても、過去の訪問は当時表示された内容を示し続けます。

質問セットはサイト、来訪者タイプ、時間帯（臨時ルール）、ホストチーム、言語に応じて切り替えられるようにすると便利です。

回答タイプとアクションフラグ

はい/いいえ以外も想定してください。よく使われるタイプは、yes/no、短文、署名、写真、ドキュメントアップロード（保険証明など）です。ファイルのメタデータ（名前、種別、タイムスタンプ）と誰が収集したかを保存します。

テンプレートに「アクション必要」フラグを追加し、「回答がYESなら安全アラートを作成する」などのルールを定義します。例：「制限品を携行していますか？」でYESなら訪問をレビュー状態にしてバッジ発行前に承認を要するようにできます。

ホストアラート：トリガー、チャネル、通知追跡

ホストアラートは一つの質問に素早く答えるべきです：「今すぐ対応が必要か？」。通常は誰が来たか、どこにいるか、なぜ来たか、承認が必要かを短く伝えます。

何がアラートをトリガーするか

トリガーは予測可能に保ち、ホストが信頼できるようにします：

• 受付でゲストがチェックインしたとき
• 予定来訪が一定時間（例：10分）遅れているとき
• 安全質問の回答でセキュリティフラグが立ったとき
• VIP到着（優先度が異なることが多い）

トリガーはデータ駆動にして、サイト、訪問タイプ、ホストの設定に紐づけ、特別扱いをハードコードしすぎないようにします。

チャネル、重複排除、追跡

複数チャネルを使えますが、毎回すべてを発砲する必要はありません。良いデフォルトは主チャネル1つ＋配信失敗時に受付画面でのキュー表示です。

ルールは単純に：

• デデュープキー：短時間内に (visit_id + trigger_type + host_id)
• 優先度：通常 vs 緊急（緊急は別チャネルにリトライ）
• サイレント時間：ホストやサイトごとの勤務時間を尊重する

各通知は個別レコードとして追跡し、監査できるようにします。状態（sent、delivered、failed）、エラー詳細、試行回数、再試行タイミングを保存してください。メッセージが失敗したら、受付がホストに電話するなど単純なフォールバックを行います。

緊急ログ：信頼できる在席情報の取得

緊急ログは通常の来訪記録とは異なります。訓練や避難、実際のインシデントで誰かが後でチェックアウトを忘れても信頼できる時間制のスナップショットが必要です。

最初にエントリタイプとルールを定義してください。訓練は計画してスタッフが開始でき、インシデントは許可されたユーザーが作成し、安全責任者が確認する流れにできます。すべての緊急イベントはサイト（オプションでゾーン）に紐づけ、"今ここにいるはずの人は誰か" に答えられるようにします。

各緊急ログエントリには信頼性を担保する最小フィールドを保存します：

• イベントタイプ、サイト、任意のゾーン
• 開始時刻、終了時刻、ステータス（open、closed）
• 開始時にオンサイトだった人（来訪者、契約者、従業員）
• 承認（誰がいつどのデバイスでカウントを確認したか）
• すべての変更に対する作業者の身元（作成者、クローズした人、編集者）

これらは追記型に保ってください。誰かが名前を修正したり安全を確認したりした場合、古い値を上書きするのではなく、新しいタイムスタンプ付きのアクションを書きます。

最も効果的なのはワンタップの「現在のオンサイトリスト」を用意することです。サイトのアクティブな訪問をすべて取り出してイベントに固定し、緊急時に使いやすい大きな表示、CSV/PDFエクスポート、ゾーンや「未承認」をフィルタできるようにします。

ステップバイステップ：エンドツーエンドのチェックインとチェックアウトフロー

フローはウォークインと事前登録の両方に対応し、誰が到着し誰が承認し誰がまだオンサイトでいつ出たかをクリーンに残すべきです。

チェックインフロー（招待からバッジまで）

可能なら来訪前に始めてください。事前登録はSite、Host、時間帯に紐づくVisitを作り、その特定の訪問に紐づいたQRコードを送ることで受付が推測する手間を減らせます。

キオスクでは来訪者がQRコードをスキャンするか、受付が名前・会社・電話で検索します。進む前に簡単な本人確認（氏名と会社など）を表示し、誤った「John S.」がチェックインされないようにします。

次に安全質問と同意を収集します。各回答はタイムスタンプと表示された正確な文言で来訪ごとのレコードとして保存します。

必要なチェックを通過したらバッジを発行してホストに通知します。バッジにはアクティブなVisitに紐づく一意のQRトークンを持たせ、PersonではなくVisitにマップしてください。その後ホストアラートを送り、配信状況、再試行、（可能なら）既読や承認を保存します。

チェックアウトフロー（自動チェックアウトを含む）

チェックアウトも速くあるべきです：バッジのQRをスキャンして訪問を確認し、check_out_timeを設定します。

チェックアウト忘れには、サイトごとの終業ルールで訪問を自動チェックアウトにして理由をログに残す方法を使ってください。こうすることで緊急時の在席数がより信頼できるものになります。

例：安全フラグの立った契約業者の訪問

契約業者のJordanがHVACの作業のため20分早く到着したケースを想定します。受付でJordanはキオスクでQRをスキャンするか（初回なら発行される）、システムはサイト、予定ホスト、バッジIDに紐づく新しいVisitを作成します。

チェックイン中にJordanは短い安全質問に答えます。質問の一つに「過去24時間に熱作業を行いましたか？」があり、Jordanは「はい」を選択します。その回答がフラグとなり、訪問ステータスは"Checked in"ではなく"Pending approval"になります。タイムスタンプと正確な質問文と回答はVisitに保存されます。

受付は三つの選択肢を明確に提示します：

• 入場を許可する（理由を添えて上書き）
• 入場を拒否する（理由を記録）
• ホスト承認を依頼する（フラグが立った場合は推奨）

承認が要求された場合、ホストは誰が待っているのか、なぜフラグが立ったのか、どこにいるのか、承認／否認ボタン付きで即座に通知されます。ホストは短い訪問履歴（最終訪問日や過去のフラグの有無）も確認できます。

承認されると訪問は"Checked in"に変わり、バッジが有効になります。Jordanが退出する際、受付またはキオスクでチェックアウトされます。アプリはチェックアウト時刻、バッジ返却状況、短いメモ（例：「HVACフィルター交換完了。問題なし」）を記録します。バッジが返却されなければその旨も記録します。

悪いログや見逃したアラートを招く一般的なミス

データ不良は多くの場合、フロー中の一つのショートカットから始まります。システムは誰かに「ここに誰がいついて、誰が承認したか」を尋ねられたときに出せる監査トレイルでしか役に立ちません。

よくあるミスは来訪者のIDと訪問履歴を混同することです。人物は時間を通して安定しているべきで、各到着は独立した記録であるべきです。来訪者プロフィールの"current visit"フィールドを上書きすると、繰り返し訪問の監査やホスト、安全回答、バッジ再印刷の履歴が失われます。

QRコードも落とし穴です。QRバッジコードが期限切れにならないと、写真からコピーされて再利用可能な通行パスになります。QRは短命トークンとして特定のバッジ発行とVisitに結びつけ、チェックアウト時に無効化してください。

痕跡のない編集は信頼を静かに壊します。スタッフが過去の安全回答を変更できるなら、誰がいつ何を変更したかと以前の値を保存する必要があります。

キオスク障害が「まあ入れてしまえ」という対応につながってはいけません。スタッフの電話フロー、後で入力する紙のバックアップ、オフラインモードから戻ったら同期する仕組みなどのフォールバックを計画してください。

アラートの見逃しは現実世界の複雑さから生じます：

• サイトフィールドのない訪問とバッジで複数サイトが一つのデータベースを共有している
• 1回の訪問に複数のホストがいる（プライマリ、バックアップ、チームメールボックス）
• 訪問中にホストが変更されても再割当をログしない

ロールアウト前の簡単なチェック

実運用日の混乱でもデータが一貫していることが重要です。フロントデスクタブレットを導入する前に「混乱日テスト」を行ってください：同時に複数到着、紛失バッジ、応答しないホストなどを想定します。

まず訪問レコードを確認します。各訪問には一つの明確なステータス（pre-registered、checked-in、checked-out、denied、canceled）と実際の状況に合うタイムスタンプが必要です。誰かがチェックインを開始して離れた場合、5〜10分後にどう扱うかを決めてください：試行を自動失効させるか、"started"のままだがオンサイトにはしないか。

バッジのライフサイクルを端から端まで検証してください。QRバッジは監査しやすくあるべきです：いつ発行され、いつ有効になり、いつ返却または期限切れになったか。再印刷が発生したら古いQRを即座に無効化して、同一訪問に二つの"有効"バッジが存在しないようにします。

短いチェックリストで十分です：

• エクスポートがスタッフ画面の表示（件数、日付範囲、サイト・ホストフィルタ）と一致する
• 通知の再送が重複を起こさない
• アラートの内容が使える（来訪者名、サイト、ホスト、安全フラグ）
• 配信失敗が見える（sent、delivered、failed）かつ再試行が安全である
• 緊急訓練で2分以内に在席リストが作成できる

エクスポート可能な来訪履歴：レポート、保持、監査トレイル

エクスポートはチェックインシステムが実務で役立つ部分です：コンプライアンス、インシデントレビュー、"先週火曜の午後3時に誰が来ていたか"のような単純な問いへの回答。何が"真実"かを早めに決めてください。エクスポートは記録として扱われます。

少なくともCSVとXLSXをサポートしてください。監査やインポートにはCSVが最適で、XLSXは非技術系チームにとって扱いやすいです。

安定したフィールドセットを定義し、時間を通じて意味を一貫させてください。実用的な最小項目は：

• Visit ID（一意で再利用しない）
• 来訪者の身元（名前と安定した来訪者キー）
• サイトとホスト
• チェックイン／チェックアウトのタイムスタンプ（タイムゾーン付き）
• バッジ識別子（QR値またはバッジ番号）

「誰がエクスポートできるか」のルールは厳しくしてください。一般的に受付は当日の一覧を見られ、セキュリティは日付範囲をエクスポートでき、管理者のみがすべてをエクスポートできる、という分離が好ましいです。エクスポートは「表示許可」ではなく独立した権限として扱ってください。

実務に耐える保持ルール

保持ルールはわかりやすい言葉で書いて一貫して適用されるようにしてください。一般的なルールは、フル訪問ログは12〜24か月保管し、保持期間後に個人情報を匿名化する（集計やタイムスタンプは保持）、緊急ログはポリシーに応じて長めに保持、監査トレイルは匿名化しても削除しない、などです。

監査トレイルと削除要求

すべての訪問レコードに監査フィールド（created_by/at、edited_by/at）とエクスポート操作の記録（exported_by/at、export_scope、ファイル形式、行数）を追加してください。

削除要求にはハードデリートを避けてください。報告が壊れるからです。より安全なのは“プライバシー削除”：個人フィールド（名前、メール、電話）を空白化またはハッシュ化し、Visit ID、タイムスタンプ、サイト、ホスト、理由コードは残してレポートが維持されるようにする方法です。

次のステップ：計画を動くアプリにする

モデルを3つのフォーカスされた画面に落とし込みます：キオスクチェックイン（高速で大きなボタン）、受付ダッシュボード（当日の到着、オーバーライド、再印刷）、ホストビュー（誰が来るか、誰がオンサイトか、対応が必要か）。各画面が一つの仕事に専念すれば、運用者がプロセスを迂回しにくくなります。

次に自動化をボタンクリックではなくイベントに結びつけてください。すべてのステータス変更が信頼できるもの（created、checked_in、badge_issued、host_notified、checked_out、emergency_sweepでの離脱マーク）になるようにします。こうすることで異なるスタッフやデバイスを使ってもアラートは適切に発火します。

まずのリリースは、多くの場合これで十分です：1サイト、1キオスク、1受付ダッシュボード、QRバッジ作成と再印刷、配信追跡付きの基本的ホスト通知、安全質問の単一のレビュー規則、選択日付範囲の来訪履歴エクスポート。小さく始めて、1つのロビーでパイロットを行い、ログとアラートが実際のフロントデスク負荷の下で一貫していることを確認してから拡張してください。

無コードで構築したい場合は、AppMasterのようなプラットフォームがデータベースモデル、ワークフロー、複数フロントエンド（キオスク、ウェブ、モバイル）を一つのソースオブトゥルースで構築する手助けになります。小さく始め、ロビーで試験運用してから広げていってください。