新規に開発が必要なのはソフトウェアのみです。ハードウェアは既設のものを使います。
| 実装項目 | 区分 | 可否 | 実装方法 | 前提条件 |
|---|---|---|---|---|
| Wi-Fi接続時の1問表示 | 接点 01 | 可能 | 既設APのキャプティブポータル機能を有効化し、認証先を当社サーバに向ける | 業務用AP（家庭用ルーターは非対応）／型番は PHASE 0 で確定 |
| フロア別の在館人数 | 接点 01 | 条件つき | APの管理APIに1分ごとに問い合わせ、接続端末数を記録 | SSIDの統合が必要。現地調査の結果、1Fと2Fで別SSIDでした |
| 1F↔2Fの移動検知 | 接点 01 | 条件つき | 接続先APの切り替わりを検知。専用機器は不要 | SSIDを統合しない限り取得できません（接続したまま上がっても切り替わらないため） |
| 滞在時間の記録 | 接点 01 | 可能 | 最終通信からの経過時間で切断を判定（既定30分） | Wi-Fiをオフにしただけでも切断されるため、退店時刻は正確に取れません。滞在時間は下限値として扱います |
| 来場者の識別 （接点をまたぐ紐づけ） | 基盤 A・C | 可能 | 接続時に当社が発行するCookie／接続セッションIDを主キーとし、ご同意いただいた方はJP NIGHTの会員IDで結合 | MACアドレスは主キーにしません。iOS・AndroidともSSIDごとにランダム化されるため、来店をまたいだ同定に使えません（下記の補足） |
| 再生ログの取得 | 基盤 A | 可能 | DJブースのLANに小型PCを接続し、CDJが発信するパケットを受信・保存 | CDJがLAN接続されハブに空きがあること。PC接続とUSB接続が混在のため、取得方式は4案から選定 |
| VIP席からの注文 | 接点 02 | 可能 | 既設の卓上iPadのブラウザから注文 → バックヤード端末に通知 | 1F・2FのVIP席が対象。台数・機種／注文をどなたが入力されるか／受信端末の置き場所 |
| LEDへの掲出 | 接点 03 | 可能 | 送出PCのブラウザを全画面表示（リクエスト名／投票結果／お題の3モード）。専用機材は不要 | LEDにPC映像を入力できること。2Fからは視認できないため、2FのVIPには卓上iPadから表示 |
| 投票・リクエストの 集計と表示 | 接点 03 | 可能 | リアルタイム集計しLEDに反映。不適切な投稿はAJ様の画面で承認してから表示 | 掲出のタイミングはAJ様の操作が前提。自動制御は含みません |
| 受付での1タップ | 接点 04 | 可能 | 既設iPadのブラウザで開くWebアプリ。インストール不要 | 受付にWi-Fiが届くこと／現場合意 |
| 翌日のプッシュ通知 | 接点 05 | 条件つき | 入店の検知 → 会員IDと突合 → 翌日1件配信 → 回答画面と特典付与 | JP NIGHTアプリ側の改修と、同意取得が前提。個人データを扱うオプションです（下記の補足） |
| 客単価の算出 | 基盤 A | 条件つき | POSのCSV取込、または日次売上の手動入力 | POSの外部出力可否／受領方法は PHASE 0 で確定 |
3つの入力が1つのデータベースに集まり、管理画面とAI分析に流れます。
月額を来場者数に比例させないためです。外部の音楽解析APIや、操作ごとのAI推論を使うと、 お客様が増えるほど月額が膨らみます。今回は接続数・投票数がどれだけ増えても、月額がほぼ変わらない構成にしています。
そのため店舗を増やしても、運用コストはほぼ横ばいのまま展開できます。
1回の接触で伺うのは1問だけ。ただし固定枠と入替枠を分けます。 すべてを日替わりにすると同じ条件のデータが揃わず、AIの分析が成立しないためです。
| 曜日 | 枠 | 設問の例 | 何に使うか |
|---|---|---|---|
| 毎日 | 固定 | 同行者構成（1人／友達／デート） | AI分析の基礎条件。毎日必ず取得します |
| 毎回 | 固定 | 初回か常連か（受付での1タップ） | リピート率。受付側で取得 |
| 月 | 入替 | 今日の気分 | フロア構成・イベント企画 |
| 火 | 入替 | 何で知ったか | 広告・SNSの効果測定 |
| 水 | 入替 | 聴きたい系統 | DJブッキング・選曲の方向づけ |
| 木 | 入替 | 来店の頻度 | 常連比率の補完 |
| 土 | 入替 | よく飲むもの | ドリンク・フードの開発判断 |
| 日 | 入替 | 次に来たい日 | イベント企画の優先順位 |
入替枠は管理画面からいつでも差し替えられます。 新メニューの検討を始められる際はその週を嗜好に関する設問へ、 広告の効果を測りたい際は認知経路の設問を毎日に切り替える、といった運用が可能です。 固定枠の項目だけは、PHASE 0 で確定させたうえで変更しない運用とします。
ご判断に必要な内容は 01〜04 です。以下は前提が崩れた場合の備えと個人データの扱いで、 確認したいときだけ開いてください。
PHASE 0 で前提が満たされなかった場合、その項目を諦めるのではなく代替手段に切り替えます。
| 前提が満たされない場合 | 影響 | 代替案 |
|---|---|---|
| Wi-Fiが家庭用ルーター | 大 | 業務用APへの交換（数万円規模）。または受付でのQR配布に切り替え、接続数計測を諦める |
| SSIDを統合できない （現状はフロア別SSID） | 中 | ①各APが観測する電波強度でフロアを推定（機器が対応している場合のみ）、②館内全体の在館数のみ扱い、 VIP注文の発生でフロア滞在を間接把握。いずれも移動の判定精度は落ちます |
| CDJがLAN接続されていない | 中 | LANケーブルの敷設を提案。難しい場合はAJ様の操作画面に「いま何がかかっているか」を残す仕組みで代替（操作した時刻で記録） |
| LEDにPCを繋げない | 小 | 掲出先を卓上iPadと手元のスマホに寄せる。集計は基盤側で完結するため、データは失われません |
| 受付に1タップの余裕がない | 小 | 接点 04 を見送り、Wi-Fi側の設問で代替。接点 01・02 と基盤Aは影響を受けません |
| JP NIGHT側で同意取得を 実装できない | 小 | 接点 05 を見送ります。個人データを扱わない接点 01〜04 のみで構成でき、他の接点には影響しません |
| POSからデータを出せない | 小 | 日次売上の手動入力、またはVIP注文のデータのみで客単価を推計 |
接点 01〜04 は、個人を特定しない形で設計します。個人データを扱うのは 接点 05（翌日のお声がけ）だけで、これは切り分けられるオプションです。実施されない場合、個人データは扱いません。
iOS・Android とも、SSIDごとにランダムなMACアドレスを使う設定が既定です。 同一SSID内では概ね安定するためその夜の在館・移動の判定には使えますが、 OSの設定やバージョンによっては接続のたびに変わるため、来店をまたいだ同一のお客様の判定には使えません。
そのため、接点をまたぐ紐づけは次の順で行います。 ① 会員ID（ご同意いただいた方のみ）→ ② 接続時に発行するCookie／接続セッションID → ③ 席IDと時刻（VIP注文）→ ④ 営業日単位の集計。 ①が無い方は、その夜の中でのみ紐づく設計です。
回答特典のドリンク1杯や、後段でご提案する予想ゲームなど景品を伴う機能は、 景品表示法の景品規制（懸賞・総付景品の上限、総額の枠）の範囲内で、単価と提供条件を設計します。 また店内で「予想を当てる遊び」を提供することが、風営法上の営業許可区分（特定遊興飲食店営業など）に影響しないかを、 実装前に確認します。いずれも当社の判断で確定させず、御社の顧問・所轄のご確認に従います。 確認が取れるまで、景品を伴う機能は実装しません。
screens.html 実際に表示される画面を、その場でタップしてご確認いただけます。
floor-map.html 1F・2Fのどこに何を設置するかの配置図です。
index.html の補足資料 設計の考え方・接点ごとの金額・PHASE 0 で確定する項目をまとめています。