レセプション顔登録全体仕様

構成要素

レセプション顔登録システムを構成するハード／ソフトの一覧。種別ごとに整理。

1. タブレット類

機材ID	名称	操作者	役割	備考
MA-1	iPad 1	お客様＋ FCH スタッフ	会社選択・署名同意・モニタリング	1 台で会社選択〜署名同意〜進捗モニタリングまでを担当
MA-2	iPad 2	お客様＋ FCH スタッフ	会社選択・署名同意・モニタリング	（MA-1 と同構成）
MA-3	iPad 3	お客様＋ FCH スタッフ	会社選択・署名同意・モニタリング	（MA-1 と同構成）

3 台のタブレットはそれぞれ独立して 1 社分のフロー（会社選択 → 同意 → レセプション顔登録 → 完了）を担当する。3 台で別々の会社を同時に対応できる。専用のアテンダント用タブレットは設けず、FCH スタッフの会社選択・モニタリング操作も MA-1〜MA-3 上で行う。

状況: iPad 3 台のうち 1 台起動確認済み（2026-05-19）

2. 表示装置（鏡）

機材ID	名称	役割	備考
MC-1	鏡A	レセプション顔登録演出・ビジュアルアイデンティティ表示	ハーフミラー越しにカメラ・27インチワイドディスプレイ×2（カメラ上下に配置）を内蔵。視線の先の一部のみに情報を出す部分表示方式。カメラ位置は実機検証で確定済み。
MC-2	鏡B	レセプション顔登録演出・ビジュアルアイデンティティ表示	（MC-1 と同構成）
MC-3	鏡C	レセプション顔登録演出・ビジュアルアイデンティティ表示	（MC-1 と同構成）

3. PC

機材ID	名称	役割	備考
MD-1	執務室PC (NEC)	事前訪問者登録	NEC メンバーが操作する PC
MD-2〜MD-4	演出用PC	レセプション顔登録全体制御（タブレット・鏡・GW・共有マネージャ中継）	ドスパラ GALLERIA XPC7A-R57-GD（型番 MC19364-SN4921）。3 台起動確認済み（2026-06-09）

4. バックエンド

機材ID	名称	役割	備考
ME-1	ゲートウェイ (NEC)	顔撮影・レセプション顔登録	NES チーム開発
ME-2	共有マネージャ (NEC)	顔情報サーバー登録	NES チーム開発

5. CMS

機材ID	名称	役割	備考
MF-1	演出用PCデータ	顔特徴量・氏名の保管／配信	物理的には独立サーバではなく、MD-2（演出用PC）内のデータストアとして組み込まれる（「システム構成図」参照）

システム構成図

顔登録システムの内部モジュール構成と通信プロトコル。色は担当チームを表す（凡例参照）。

注: 本図は最新の実装方針（鏡ごとの独立 PC・MQTT Broker 採用・演出用PC 内モジュール内訳）を反映している。上記「構成要素」テーブルの記述（特に MD-2 が鏡を直接制御する旧モデル）は本図に合わせて別途更新を予定。

凡例

色	チーム	担当範囲
🟡 黄	タングラム（Uniba）	鏡PC（A/B/C）／演出用PC 内モジュール（MQTT Broker・顔認識エンジンハンドラ・共有マネージャクライアント・タブレットWEB・データストア）
🟣 ピンク	タングラム（ひつじ）	鏡演出プログラム（鏡PC 上で稼働）／他エリア演出用PC
🟢 緑	NES	執務室PC（MD-1）／顔認証GW（ME-1）／共有マネージャ（ME-2）
🔵 青	デバイス	鏡 A/B/C／タブレット A/B/C

構成図

通信プロトコル一覧

経路	プロトコル	用途
執務室PC（MD-1）→ 共有マネージャ（NES）	NES 内部 I/F（公開仕様外）	FCH スタッフが当日の来館者リスト（会社／名前／日付）を作成・登録する。顔データは含まない。登録結果は `GET /groups/{date}`／`GET /users/{group_id}` で取得可能になる
顔認識エンジンハンドラ ↔ 顔認証GW（NES）	ZMQ REQ/REP + PUB/SUB	撮影開始要求・進捗イベント受信（API.md 参照）
顔認識エンジンハンドラ → MQTT Broker	MQTT publish	GW から受けた撮影状態・登録イベントを内部配信
鏡PC（A/B/C）→ MQTT Broker	MQTT subscribe	自鏡向けの演出指示・状態イベントを購読
タブレット（MA-1〜3）→ MQTT Broker	MQTT push	撮影中の進捗・成否を UI 反映
タブレット → タブレットWEB	HTTP GET	画面・状態取得
タブレットWEB ↔ 共有マネージャクライアント	HTTP GET/POST	訪問者情報の取得・状態送信
共有マネージャクライアント → 共有マネージャ（NES）	HTTP	API-1〜3 呼び出し
演出用PC（MD-2）→ データストア	HTTP PUT	顔特徴量・氏名・顔画像の永続化（DS-5／DS-6、プロセス C [PC-2]）
他エリア演出用PC → データストア	HTTP GET	他ゾーン演出向け配信参照（DS-1〜4）

構成プロセス

レセプション顔登録は 3 プロセスで構成される。

プロセス	概要
A: 同意	お客様が訪問者一覧から自分を選び、利用同意を行う。レセプション顔登録撮影 NG の場合は、ここで同意のみ完了へ分岐できる
B: レセプション顔登録	演出用PC（MD-2）がお客様を鏡へ誘導し、撮影。ゲートウェイ（ME-1）／共有マネージャ（ME-2）が顔情報をサーバー登録
C: レセプション顔登録完了	演出用PC（MD-2）が完了表示し、顔特徴量・氏名を他演出へ連携

メモ — A・B の結合方針: プロセス A と B は 密結合とする（OK）。プロセス B の進捗（撮影状態・エラー・リトライ・通信ステータス等）を、A で使用したタブレット（MA-1〜MA-3）で FCH スタッフがそのまま確認できるようにするため、同一タブレットがプロセス A → B → C を一貫して担当する設計を採る。

外部 API

レセプション顔登録システムで使用する API（一覧・イベント・プロセスB メッセージマッピング）は API.md に分離。本書ではフロー説明・図中で API-1〜3（共有マネージャ）、GW-REQ-1〜4 / GW-EVT-1〜7（レセプション顔登録ゲートウェイ）、DS-1〜7（データストア MF-1 モック実装）の ID で参照する。MF-1 の全体仕様は docs/mf-1/ARCHITECTURE.md を参照。

API 系統	提供元	主な用途	プロトコル
共有マネージャー API	共有マネージャ（ME-2、NES）	訪問者情報取得・顔画像取得	REST
レセプション顔登録ゲートウェイ API	レセプション顔登録ゲートウェイ（ME-1、NES）	撮影・レセプション顔登録制御	ZeroMQ（REQ/REP + PUB/SUB）
データストア API	データストア（MF-1、演出用PC 内蔵 / Uniba）	顔画像キャッシュ・メタデータ保存／グループ取得	REST

プロセス A: 同意

フロー（時系列）

① FCH スタッフが、本日の訪問者情報（会社／名前／日付）を、執務室PC で事前登録する。

② FCH スタッフが、各タブレット（MA-1〜MA-3）の団体一覧（SA-1）から、タブレットごとに該当会社を選択する（3 台それぞれ独立して別会社を割り当て可能）。　→ 演出用PC が API-1 GET /v1/groups/{date} で当日の訪問グループ一覧を取得し、各タブレットの SA-1 に表示。

③ 会社を選択したタブレットに、その会社の訪問者一覧（SA-3）が表示される。FCH スタッフは同一タブレットの訪問者一覧（SA-3）で登録状況をモニタリングする。　→ 演出用PC が API-2 GET /v1/users/{group_id} で選択グループの訪問者リストを取得し、SA-3 に表示。

④ レセプション顔登録スタート（お客様来場） — FCH スタッフがお客様を迎える。

⑤ お客様が、タブレットの名簿から、自分の名前を選択する（SA-3）。

⑥ お客様が、タブレットで、個人情報の取り扱いに同意する（SA-2）。

⑦ レセプション顔登録撮影 NG の場合、FCH スタッフが同一タブレットの訪問者一覧（SA-3）で該当参加者を同意のみ完了にする。該当参加者は受付／プロセス進捗上は完了扱いだが、顔データは未登録として区別する。

例外・補足

飛び入り参加者: FCH スタッフが SA-6 参加者追加フォームから手動追加
※欠席者・飛び入り参加など訪問者変更に備え、タブレット（MA-1〜MA-3）側で手動登録／編集／削除も可能
訪問者一覧取得失敗時: バックアップして別 PC（@NEC さん）で登録可能にしておく → それも無理ならレセプション顔登録を諦める
ゲートウェイ通信失敗時: レセプション顔登録の流れを省略
同意のみ完了: レセプション顔登録撮影 NG の参加者は、SA-2 で同意取得後に FCH スタッフが SA-3 で完了扱いにする。この分岐ではプロセス B の鏡割当・撮影開始へ進まず、顔データ未登録として表示する。後から撮影可能になった場合は、SA-3 から通常のレセプション顔登録開始へ戻せる余地を残す。
登録が中断されたお客さんの情報も保持し、再開できるようにする
同意情報の扱い: 同意完了状態は演出用PC（および SA-3 モニタリング）がローカルに保持する。NES（ゲートウェイ／共有マネージャ）へ同意情報を送信する専用 API はなく、レセプション顔登録に進む場合は撮影開始指示（GW-REQ-1 StartFaceCaptureRequest）の送信をもって同意済みとして扱う。
同意文章の更新方法: 同意文章は ファイル入れ替え による更新を想定。管理画面等は設けず、対象タブレット／演出用PC に SSH でログインしてファイルを差し替える 経路を確保する（運用上の手段として確定）。

ダイアグラム

画面対応表

ユーザー操作のタイミングで各端末が表示している画面（3 台のタブレットはそれぞれ独立に進行）：

操作	MA-1〜MA-3（タブレット）	鏡
① FCH スタッフが事前訪問者登録（執務室PC）	—	—
② FCH スタッフが会社選択	団体一覧（SA-1）	—
③ お客様来場・レセプション顔登録スタート	訪問者一覧（SA-3）	—
④ お客様が名前を選択	訪問者一覧（SA-3）	—
⑤ お客様が同意操作	個人情報の取り扱い同意（SA-2）	—
⑥ レセプション顔登録撮影 NG → 同意のみ完了	訪問者一覧（SA-3）（同意のみ完了・顔未登録）	スタンバイ・待機（SC-1）

プロセス B: レセプション顔登録

フロー（時系列）

① 演出用PCが、空いている鏡（鏡N）を割り当て、お客様を鏡N へ誘導する（タブレットと鏡の両方にSA-4を表示）。

② お客様が、案内された鏡N の前に立つ。

③ 共有マネージャが、お客様の顔を撮影・加工し、顔情報をサーバー登録する。

レセプション顔登録成功時

④ 演出用PCが、成功演出を鏡に表示する。

⑤ 演出用PCが、成功表示をタブレット（SA-4 ／ FCH モニタリング SA-3）に出す。 → プロセス C へ

レセプション顔登録失敗時（横向きすぎ／近い／遠い等）

④ 演出用PCが、以下を同時に表示する（お客様向けの SA-4 には出さない）。 → 再試行、または一定インターバルで人がいなければ中断。

鏡: お客様が自立判断できる程度の失敗情報
タブレット（FCH モニタリング SA-3）: 詳細なエラー情報＋失敗した画像

システムエラー時

④ 共有マネージャが内部リトライを行う。それでも失敗した場合、演出用PCが FCH スタッフに「再登録 or 諦め」を提示する。

通信で送られる情報（青字）

顔（近い／遠い、スコア） — GW: GW-EVT-1 CaptureStatusNotifiedEvent（face_quality_score、face_pan/roll/tilt、face_rect 等）
登録プロセス状況 — GW: GW-EVT-3 RegistrationStartedEvent → GW-EVT-5 RegistrationProvisionallyCompletedEvent → GW-EVT-6 RegistrationCompletedEvent
完了情報、顔特徴量 — GW: GW-EVT-6 RegistrationCompletedEvent（visitor_id）／顔特徴量は共有マネージャ（ME-2）から取得
失敗情報（横向きすぎ、近い、遠いなど） — GW: GW-EVT-1 CaptureStatusNotifiedEvent（姿勢ガイド guidance_code）／GW-EVT-7 RegistrationFailedEvent（reason_code + is_retryable）
撮影開始指示の送信・応答受領 — GW: GW-REQ-1 StartFaceCaptureRequest (start_face_capture コマンド) + GenericResponse

例外・補足

一定インターバルで人がいない場合 → 登録フロー中断処理
登録フローが中断された場合 → タブレット（MA-1〜MA-3）側で再度レセプション顔登録開始できるように
タブレット（MA-1〜MA-3）から強制停止できるように
共有マネージャシステムエラー時: 共有マネージャー内部でリトライ処理 → それでもだめな場合は再度登録プロセス or レセプション顔登録諦める
通信の成功・失敗状況はタブレット（MA-1〜MA-3）でも見れるように
同意のみ完了者は対象外: SA-2 後に SA-3 で同意のみ完了にした参加者は、その状態のままではプロセス B へ進まない。GW-REQ-1 撮影開始要求、GW イベント待受、鏡誘導は行わない。

ダイアグラム

画面対応表

ユーザー操作・主要イベントのタイミングで各端末が表示している画面（タブレットは鏡誘導後に FCH スタッフへ戻り、以降は SA-3 モニタリング表示）：

操作・状態	MA-1〜MA-3（タブレット）	鏡
① 鏡N誘導開始（同意完了→鏡N割当）	鏡への誘導（SA-4）	来訪者を感知（SC-2）
② お客様が鏡N前に立つ（タブレット回収後）	訪問者一覧（SA-3）（鏡N 割り当て・撮影待ち、FCH モニタリング）	来訪者を感知（SC-2）
③ 撮影・加工中（共有マネージャ処理）	訪問者一覧（SA-3）（撮影中・通信処理中）	撮影開始（SC-3）
④ レセプション顔登録成功	訪問者一覧（SA-3）（成功表示）	撮影完了・生成（SC-4）（成功演出）
⑤ レセプション顔登録失敗（画像条件不適合 / 横向き・近い・遠い等）	訪問者一覧（SA-3）（詳細エラー＋失敗画像）	撮影完了・生成（SC-4）（失敗情報・自律判断用）
⑥ 共有マネージャ通信エラー（内部リトライ中）	訪問者一覧（SA-3）（リトライ中・通信ステータス）	（継続）
⑦ 共有マネージャシステムエラー（内部リトライ失敗）	訪問者一覧（SA-3）（再登録 or 諦め通知）	（継続）
⑧ 一定インターバル人なし → 登録フロー中断	訪問者一覧（SA-3）（中断通知・再開ボタン）	スタンバイ・待機（SC-1）
⑨ ゲートウェイ通信失敗	訪問者一覧（SA-3）（通信失敗・レセプション顔登録省略）	スタンバイ・待機（SC-1）
⑩ FCH スタッフが強制中止	訪問者一覧（SA-3）（強制中止モーダル）	スタンバイ・待機（SC-1）

プロセス C: レセプション顔登録完了

フロー（時系列）

① 演出用PCが、完了表示を鏡とタブレットに出す。お客様はそれを見て登録完了を知る。

② 演出用PCが、お客様の顔特徴量・氏名・visitor_idと認識時の顔画像をデータストア（MF-1）に保存する（DS-5／DS-6）。

③ データストアが、保存した**visitor_id・氏名・顔画像 URL**を他の演出ゾーンへ push 型で配信する（MQTT over WebSocket。2026-06-04 会議で確定）。　→ 配信を受け取った演出ゾーンは、visitor_id を使って DS-3 GET /api/datastore/visitors/{visitor_id}／DS-4 …/face でデータストアから実データ（顔特徴量・顔画像）を取得する。共有マネージャ原本の顔画像が必要な場合は API-3 GET /v1/users/{visitor_id}/faces/image も利用できる。

他の登録者がいる場合

④ お客様が、タブレットのSA-5 完了後モーダルで次アクションを選択する。

全員完了の場合

④ 終了（追加操作なし）。

例外・補足

他の登録者がいる場合: 演出用PC が空いている鏡（次レーン）へ誘導表示
登録済みでも削除は可能
同意のみ完了者: 受付／プロセス進捗上は完了扱いだが、顔特徴量・visitor_id を伴うレセプション顔登録完了とは区別する。PC-2 顔特徴量保存、他演出への顔特徴量配信、API-3 顔画像参照は行わない。

ダイアグラム

画面対応表

ユーザー操作のタイミングで各端末が表示している画面：

操作	MA-1〜MA-3（タブレット）	鏡
① お客様が完了表示を確認	訪問者一覧画面（SA-3）（該当者を完了状態に更新）	生成完了（SC-5）
② FCH スタッフが完了表示を確認（モニタリング）	訪問者一覧画面（SA-3）（該当者を完了状態に更新）	生成完了（SC-5）
③ お客様が次アクション選択（他の登録者あり）	完了後の次アクション選択モーダル（SA-5）	生成完了（SC-5）
全員完了	訪問者一覧画面（SA-3）（全員グレーアウト）	スタンバイ・待機（SC-1）

端末別フロー

執務室PC

機材ID: MD-1
役割: 事前登録
操作者: FCH スタッフ

ID	概要	画面	操作	処理
PA-1	事前訪問者登録	—	FCH スタッフが訪問者情報（会社／名前／日付）を入力	ゲートウェイ（ME-1）へ訪問者情報を配信

MA-1 / MA-2 / MA-3

名称: タブレット
台数: 3 台
配置: お客様の前に常設（3 台それぞれ独立して 1 社分のフローを担当）
操作者: FCH スタッフ（会社選択・モニタリング）＋お客様（名前選択以降）

ID	概要	画面	操作	処理
PA-3	団体一覧表示	団体一覧（SA-1）	—	当日の訪問団体一覧を表示
PA-3	会社選択	団体一覧（SA-1）	FCH スタッフがタブレットごとに会社を選択	—
PA-4	訪問者一覧表示	訪問者一覧（SA-3） / 訪問者一覧（SA-3）	—	選択会社の訪問者一覧を表示。誘導済みのお客様はグレーアウト
PA-5	名前選択	訪問者一覧（SA-3）	お客様が自分の名前の `>` ボタンを押下	—
PA-6	個人情報同意	個人情報の取り扱い同意（SA-2）	お客様が同意操作	—
PA 例外	同意のみ完了	訪問者一覧（SA-3）	FCH スタッフがレセプション顔登録撮影 NG の参加者を同意のみ完了にする	受付／進捗上は完了、顔データ未登録として状態更新。鏡割当・撮影開始は行わない
PA 例外	飛び入り参加者追加	参加者追加フォーム（SA-6）	FCH スタッフが手動追加／編集／削除	—
PB-5	鏡N誘導表示	鏡への誘導（SA-4）	—	「鏡N に立ってください」表示（鏡と同時）。完了ボタン操作後タブレットは FCH スタッフへ戻る
PB	レセプション顔登録ステータスモニタリング	訪問者一覧（SA-3）（オーバーレイ）	FCH スタッフが確認	鏡N割当・撮影中・成功/失敗・リトライ中・通信ステータスを表示
PB-8 成功	成功表示	鏡への誘導（SA-4） / 訪問者一覧（SA-3）（成功表示）	—	レセプション顔登録成功表示。失敗時の詳細エラー＋失敗画像は SA-3 モニタリングに表示（SA-4 には出さない）
PB 例外	中断・通信失敗通知	訪問者一覧（SA-3）（中断通知・再開ボタン／通信失敗表示）	FCH スタッフが確認	共有マネージャシステムエラー時は「再登録 or 諦め」通知
PB 例外	強制中止	訪問者一覧（SA-3）（強制中止モーダル）	FCH スタッフが操作	該当タブレット・鏡をリセット
PC-1	完了表示	（完了表示）	—	完了表示
PC	次アクション選択	完了後の次アクション選択モーダル（SA-5）	お客様が次アクションを選択	他の登録者がいる場合のみ表示
PC	完了状態反映	訪問者一覧（SA-3）（該当者完了状態・グレーアウト）	—	レセプション顔登録完了した訪問者をグレーアウト
PC 全員完了	全員完了	訪問者一覧（SA-3）（全員グレーアウト）	—	終了

演出用PC

機材ID: MD-2
役割: タブレット全制御＋鏡制御
操作者: なし（システム）

ID	概要	画面	操作	処理
PA-1	訪問者情報受領	—	—	GW（ME-1）から訪問者情報配信を受領
PA-3	団体一覧表示送出	—	—	API-1 `GET /v1/groups/{date}` で当日の訪問グループを取得 → MA-1〜MA-3 に団体一覧（SA-1）を表示
PA-4	訪問者一覧表示送出	—	—	タブレットごとの会社選択結果を受領 → API-2 `GET /v1/users/{group_id}` で訪問者リストを取得 → 該当タブレットの SA-3 に訪問者一覧を表示
PA 例外	同意のみ完了制御	—	—	SA-3 で同意のみ完了にした参加者を完了状態へ更新。GW-REQ-1 送信、GW イベント待受、PC-2 顔特徴量保存は行わない
PB-2	撮影開始指示	—	—	GW（ME-1）へ GW-REQ-1 `StartFaceCaptureRequest` を送信。`GenericResponse` で `job_id` を保持
PB-4	鏡FIFO割当	—	—	空いている鏡から鏡N決定
PB-5	鏡N誘導表示送出	鏡への誘導（SA-4）	—	タブレット・鏡両方に「鏡N に立ってください」表示
PB-7	撮影状態受領（連続）	—	—	GW から GW-EVT-1 `CaptureStatusNotifiedEvent` を購読し、`guidance_code` / 品質スコアを鏡・タブレット（SA-3 モニタリング）に反映
PB-7b	登録開始受領	—	—	GW から GW-EVT-3 `RegistrationStartedEvent` を受領 → 鏡の演出を撮影完了状態（SC-4）へ遷移
PB-7c	visitor_id 採番受領	—	—	飛び入り参加者時、GW から GW-EVT-4 `TargetUserIdNotifiedEvent` を受領し以降の処理で利用
PB-8 成功	仮完了→成功表示制御	—	—	GW から GW-EVT-5 `RegistrationProvisionallyCompletedEvent` 受領 → 鏡へ成功演出、タブレット（SA-4／SA-3）へ成功表示。GW-EVT-6 `RegistrationCompletedEvent` 受領で PC-2 完了情報保存へ
PB-8 失敗	失敗表示制御	—	—	品質不適合は GW-EVT-1 の `guidance_code` で鏡側ガイド継続。鏡へ失敗情報、タブレット（SA-3 モニタリング）へ詳細エラー＋失敗画像（お客様向けの SA-4 には出さない）
PB 例外	システムエラー通知	—	—	GW から GW-EVT-7 `RegistrationFailedEvent` 受領 → `is_retryable=true` ならタブレット（SA-3）に「再登録 or 諦め」通知、再登録選択時 GW-REQ-3 `RetryFaceRegistrationRequest` を送信
PB 例外	強制中止／中断	—	—	タブレット（MA-1〜MA-3）からの強制中止指示／タイムアウトで GW へ GW-REQ-2 `CancelFaceCaptureRequest`（`job_id`）送信 → GW-EVT-2 `CaptureCanceledEvent` 受領で該当タブレット・鏡をリセット
PB／PC 例外	顔データ削除	—	—	登録済み顔データ削除時、GW へ GW-REQ-4 `DeleteFaceRegistrationRequest`（`visitor_id`）送信
PC-1	完了表示制御	—	—	鏡・MA-1〜MA-3 へ完了表示を送出
PC-2	完了情報保存	—	—	データストア（MF-1）へ顔画像・顔パラメータ・氏名・`visitor_id` を保存（設計: MF-1 仕様。モック実装 #104 は DS-5 `PUT …/face`／DS-6 `PUT …/metadata`）。※ NES 顔特徴量を MF-1 に保管するかは未確定（MF-1 論点 5 参照）
PC-3	他演出への配信	—	—	MF-1 から各演出ゾーンへ `visitor_id`・氏名・顔画像 URL を push 型で配信（MQTT WebSocket、MF-1 論点 7）。受信側は MF-1 から取得（モック実装は DS-3／DS-4）

共有マネージャ

機材ID: ME-2
役割: レセプション顔登録パイプライン
操作者: なし（システム）
詳細: 共有マネージャーAPIサイネージ用訪問者情報取得.html

ID	概要	画面	操作	処理
PB-7	撮影・加工・算出	—	—	顔（近い／遠い、スコア）・特徴量を演出用PC へ送信
例外	内部リトライ	—	—	エラー時に再試行。タブレットとは直接通信しない
API-1	訪問グループリスト返却	—	—	`GET /v1/groups/{date}` — 指定日の訪問グループ一覧を返却（演出用PC が呼び出し）
API-2	訪問者リスト返却	—	—	`GET /v1/users/{group_id}` — 指定グループの訪問者リストを返却（演出用PC が呼び出し）
API-3	顔画像返却	—	—	`GET /v1/users/{visitor_id}/faces/image` — 訪問者の顔画像バイナリを返却（他演出ゾーンが呼び出し）

鏡A / B / C

機材ID: MC-1 / MC-2 / MC-3
役割: お客様向け表示装置
台数: 3 台
操作者: なし（演出用PC = MD-2 が制御）

5 つの画面状態で構成される：

ID	概要	画面	操作	処理
待機	スタンバイ	スタンバイ・待機（SC-1）	—	通常待機状態。次レーン誘導・中断・強制中止・全員完了時もこの状態に戻る
PB-5	来訪者検知	来訪者を感知（SC-2）	—	鏡N 誘導後、お客様の来訪を検知した状態を表示
PB-7	撮影開始	撮影開始（SC-3）	—	撮影開始の合図を表示
PB-8	撮影完了	撮影完了・生成（SC-4）	お客様が自立判断（失敗時）	撮影結果を表示（成功演出 or 失敗情報＝横向き／近い／遠い等）
PC-1	生成完了	生成完了（SC-5）	—	顔特徴量生成完了の最終演出表示

ゲートウェイ

機材ID: ME-1
通信: ZeroMQ REQ/REP（:5555）+ PUB/SUB（:5556）
実測性能・制約: PUB/SUB の進捗イベント配信は約 10fps、遅延 0.5〜1.0 秒。GW-EVT-1 の連続配信はこのレート前提で演出設計する
詳細: 顔登録ゲートウェイ_API仕様書_1.0.4.html

ID	概要	画面	操作	処理
PA-1	事前登録中継	—	—	執務室PC → 演出用PC へ訪問者情報を配信
GW-REQ-1	撮影開始要求の受領	—	—	`StartFaceCaptureRequest`（`start_face_capture`）を REQ で受領 → `GenericResponse` で `job_id` を返却 → 撮影パイプライン起動
GW-REQ-2	撮影／登録キャンセル要求の受領	—	—	`CancelFaceCaptureRequest`（`cancel_face_capture` + `job_id`）を受領 → 現行ジョブ停止 → `CaptureCanceledEvent` を発火
GW-REQ-3	レセプション顔登録リトライ要求の受領	—	—	`RetryFaceRegistrationRequest`（`retry_face_registration` + `visitor_id`）を受領 → 再登録パイプライン起動
GW-REQ-4	顔データ削除要求の受領	—	—	`DeleteFaceRegistrationRequest`（`delete_face_registration` + `visitor_id`）を受領 → 登録済み顔データ削除
GW-EVT-1	撮影状態通知の配信	—	—	`CaptureStatusNotifiedEvent` を PUB — `guidance_code`／顔・頭部・目の座標／品質スコア／pan/roll/tilt／表情・装着物スコア／視線／切り出し画像（座標はカメラ原座標系）
GW-EVT-2	撮影キャンセル通知の配信	—	—	`CaptureCanceledEvent` を PUB（`reason_code` 例: `timeout`）
GW-EVT-3	登録開始通知の配信	—	—	`RegistrationStartedEvent` を PUB（確定済み `face_image` / `face_image_rect`）
GW-EVT-4	訪問者ID確定通知の配信	—	—	`TargetUserIdNotifiedEvent` を PUB（採番された `visitor_id`）
GW-EVT-5	仮完了通知の配信	—	—	`RegistrationProvisionallyCompletedEvent` を PUB（バックエンド登録要求完了、`visitor_id`）
GW-EVT-6	最終完了通知の配信	—	—	`RegistrationCompletedEvent` を PUB（認証等で利用可能、`visitor_id`）
GW-EVT-7	登録失敗通知の配信	—	—	`RegistrationFailedEvent` を PUB（`reason_code`、`is_retryable`）

演出用PCデータ

機材ID: MF-1
役割: 旧 CMS 機能内包
API 仕様: docs/mf-1/ARCHITECTURE.md

物理的には独立したサーバではなく、MD-2〜MD-7 のいずれかに組み込まれる（要確定）。MF-1 は論理 CMS の呼称。

ID	概要	画面	操作	処理
PC-2	完了情報保存	—	—	完了情報・顔特徴量・`visitor_id` を保存。※ MF-1 への保管かどうかは未確定（MF-1 論点 5 参照）
PC-3	他演出配信	—	—	演出側計算値・`visitor_id` を他演出ゾーンへ配信（MF1-API-3、プル型）。顔画像が必要な場合、他演出ゾーンは配信された `visitor_id` を使って共有マネージャの API-3 `GET /v1/users/{visitor_id}/faces/image` でオンデマンドに取得

エンドツーエンドスイムレーン

FAQ

レセプション顔登録システムの仕様に関するよくある質問と、確認済みの回答。

Q1. 「同意した」という情報を NES へ送る API はあるか？

A. ない。共有マネージャー API・レセプション顔登録ゲートウェイ API のいずれにも、同意情報を送信する専用の API・メッセージ・フィールドは存在しない（StartFaceCaptureRequest のペイロードにも同意関連の項目はない）。

同意完了状態は演出用PC（および SA-3 モニタリング）がローカルに保持する。レセプション顔登録に進む場合は撮影開始指示（GW-REQ-1 StartFaceCaptureRequest、[PB-2]）の送信をもって同意済みとして扱い、同意のみ完了（撮影 NG）の場合は GW-REQ-1 を送らない。

Q2. 「削除」と「解除」の違いについて

A. NES 一括登録 AP 画面で使われる「削除」と「解除」は、対象と意図が異なる。

解除: この顔の人を「この名前に紐づけた」という 紐付けを、その画面上で解除する操作。つまり、登録途中で「この顔はこの人ではない」と判断した場合に、紐付けを取り消すもの。
削除: 一度レセプション顔登録が終わった後に、一覧に出ている人の 顔を削除して、もう一回やり直す操作。間違って違う人を紐付けてしまった場合に、一度解除してから再度取り直すという流れで使われる。

レセプション顔登録全体仕様 ​

構成要素 ​

1. タブレット類 ​

2. 表示装置（鏡） ​

3. PC ​

4. バックエンド ​

5. CMS ​

システム構成図 ​

凡例 ​

構成図 ​

通信プロトコル一覧 ​

構成プロセス ​

外部 API ​

プロセス A: 同意 ​

フロー（時系列） ​

例外・補足 ​

ダイアグラム ​

画面対応表 ​

プロセス B: レセプション顔登録 ​

フロー（時系列） ​

通信で送られる情報（青字） ​

例外・補足 ​

ダイアグラム ​

画面対応表 ​

プロセス C: レセプション顔登録完了 ​

フロー（時系列） ​

例外・補足 ​

ダイアグラム ​

画面対応表 ​

端末別フロー ​

執務室PC ​

MA-1 / MA-2 / MA-3 ​

演出用PC ​

共有マネージャ ​

鏡A / B / C ​

ゲートウェイ ​

演出用PCデータ ​

エンドツーエンド スイムレーン ​

FAQ ​

Q1. 「同意した」という情報を NES へ送る API はあるか？ ​

Q2. 「削除」と「解除」の違いについて ​

レセプション顔登録全体仕様

構成要素

1. タブレット類

2. 表示装置（鏡）

3. PC

4. バックエンド

5. CMS

システム構成図

凡例

構成図

通信プロトコル一覧

構成プロセス

外部 API

プロセス A: 同意

フロー（時系列）

例外・補足

ダイアグラム

画面対応表

プロセス B: レセプション顔登録

フロー（時系列）

通信で送られる情報（青字）

例外・補足

ダイアグラム

画面対応表

プロセス C: レセプション顔登録完了

フロー（時系列）

例外・補足

ダイアグラム

画面対応表

端末別フロー

執務室PC

MA-1 / MA-2 / MA-3

演出用PC

共有マネージャ

鏡A / B / C

ゲートウェイ

演出用PCデータ

エンドツーエンドスイムレーン

FAQ

Q1. 「同意した」という情報を NES へ送る API はあるか？

Q2. 「削除」と「解除」の違いについて