レセプション顔登録全体仕様
構成要素
レセプション顔登録システムを構成するハード／ソフトの一覧。種別ごとに整理。
1. タブレット類
| 機材ID | 名称 | 操作者 | 役割 | 備考 |
|---|---|---|---|---|
| MA-1 | 署名用タブレット 1 | お客様 ＋ FCH スタッフ | 会社選択・署名同意・モニタリング | 1 台で会社選択〜署名同意〜進捗モニタリングまでを担当 |
| MA-2 | 署名用タブレット 2 | お客様 ＋ FCH スタッフ | 会社選択・署名同意・モニタリング | （MA-1 と同構成） |
| MA-3 | 署名用タブレット 3 | お客様 ＋ FCH スタッフ | 会社選択・署名同意・モニタリング | （MA-1 と同構成） |
3 台のタブレットはそれぞれ独立して 1 社分のフロー（会社選択 → 同意 → レセプション顔登録 → 完了）を担当する。3 台で別々の会社を同時に対応できる。専用のアテンダント用タブレットは設けず、FCH スタッフの会社選択・モニタリング操作も MA-1〜MA-3 上で行う。
状況: タブレット 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・共有マネージャ中継）。Web アプリケーションは MD-2 上で動作し、タブレット MA-1〜3 も MD-3／MD-4 もそこへアクセスする（2026-08-13 確定。PC とタブレットはペアではない） | ドスパラ 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 |
構成図
外部システム（NES / NEC）タブレット演出装置データストアタングラム（Uniba）タングラム（ひつじ）
通信プロトコル一覧
| 経路 | プロトコル | 用途 |
|---|---|---|
| 執務室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-2）が表示される。FCH スタッフは同一タブレットの訪問者一覧（SA-2）で登録状況をモニタリングする。 → 演出用PC が API-2 GET /v1/users/{group_id} で選択グループの訪問者リストを取得し、SA-2 に表示。
④ レセプション顔登録スタート（お客様来場） — FCH スタッフがお客様を迎える。
⑤ お客様が、タブレットの名簿から、自分の名前を選択する（SA-2）。
⑥ お客様が、タブレットで、個人情報の取り扱いに同意する（SA-3）。
⑦ レセプション顔登録撮影 NG の場合、参加者本人が同意画面（SA-3）で「同意して終了（撮影しない）」を選び受付完了画面（SA-7）へ進むか、FCH スタッフが同一タブレットの訪問者一覧（SA-2）で該当参加者を同意のみ完了にする。該当参加者は受付／プロセス進捗上は完了扱いだが、顔データは未登録として区別する。
例外・補足
- 飛び入り参加者: FCH スタッフが SA-6 参加者追加フォーム から手動追加
- ※欠席者・飛び入り参加など訪問者変更に備え、タブレット（MA-1〜MA-3）側で手動登録／編集／削除も可能
- 訪問者一覧取得失敗時: バックアップして別 PC（@NEC さん）で登録可能にしておく → それも無理ならレセプション顔登録を諦める
- ゲートウェイ通信失敗時: レセプション顔登録の流れを省略
- 同意のみ完了: レセプション顔登録撮影 NG の参加者は、SA-3 の「同意して終了（撮影しない）」で本人が辞退する（SA-7 へ進む）か、SA-3 で同意取得後に FCH スタッフが SA-2 で代行して完了扱いにする（2026-08-11 確定）。この分岐ではプロセス B の鏡割当・撮影開始へ進まず、顔データ未登録として表示する。後から撮影可能になった場合は、SA-2 の管理モードから通常のレセプション顔登録開始へ戻せる（2026-08-11 確定。管理モード）。
- 登録が中断されたお客さんの情報も保持し、再開できるようにする
- 同意情報の扱い: 同意完了状態は演出用PC（および SA-2 モニタリング）がローカルに保持する。NES（ゲートウェイ／共有マネージャ）へ同意情報を送信する専用 API はなく、レセプション顔登録に進む場合は撮影開始指示（GW-REQ-1
StartFaceCaptureRequest）の送信をもって同意済みとして扱う。 - 同意文章の更新方法: 同意文章は ファイル入れ替え による更新を想定。管理画面等は設けず、対象タブレット／演出用PC に SSH でログインしてファイルを差し替える 経路を確保する（運用上の手段として確定）。
ダイアグラム
外部システム（NES / NEC）演出用PCタブレット
画面対応表
ユーザー操作のタイミングで各端末が表示している画面（3 台のタブレットはそれぞれ独立に進行）：
| 操作 | MA-1〜MA-3（タブレット） | 鏡 |
|---|---|---|
| ① FCH スタッフが事前訪問者登録（執務室PC） | — | — |
| ② FCH スタッフが会社選択 | 団体一覧（SA-1） | — |
| ③ お客様 来場・レセプション顔登録スタート | 訪問者一覧（SA-2） | — |
| ④ お客様が名前を選択 | 訪問者一覧（SA-2） | — |
| ⑤ お客様が同意操作 | 個人情報の取り扱い同意（SA-3） | — |
| ⑥ レセプション顔登録撮影 NG → 同意のみ完了 | 訪問者一覧（SA-2）（同意のみ完了・顔未登録） | スタンバイ・待機（SC-1） |
プロセス B: レセプション顔登録
フロー（時系列）
① 演出用PCが、空いている鏡（鏡N）を割り当て、お客様を鏡N へ誘導する（タブレットと鏡の両方にSA-4を表示）。
② お客様が、案内された鏡N の前に立つ。
③ 共有マネージャが、お客様の顔を撮影・加工し、顔情報をサーバー登録する。
レセプション顔登録成功時
④ 演出用PCが、成功演出を鏡に表示する。
⑤ 演出用PCが、成功表示をタブレット（SA-4 ／ FCH モニタリング SA-2）に出す。 → プロセス C へ
レセプション顔登録失敗時（横向きすぎ／近い／遠い 等）
④ 演出用PCが、以下を同時に表示する（お客様向けの SA-4 には出さない）。 → 再試行、または一定インターバルで人がいなければ中断。
- 鏡: お客様が自立判断できる程度の失敗情報
- タブレット（FCH モニタリング SA-2）: 詳細なエラー情報＋失敗した画像
システムエラー時
④ 共有マネージャが内部リトライを行う。それでも失敗した場合、演出用PCが FCH スタッフに「再登録 or 諦め」を提示する。
通信で送られる情報（青字）
- 顔（近い／遠い、スコア） — GW: GW-EVT-1
CaptureStatusNotifiedEvent（face_quality_score、face_pan/roll/tilt、face_rect等） - 登録プロセス状況 — GW: GW-EVT-3
RegistrationStartedEvent→ GW-EVT-5RegistrationProvisionallyCompletedEvent→ GW-EVT-6RegistrationCompletedEvent - 完了情報、顔特徴量 — GW: GW-EVT-6
RegistrationCompletedEvent（visitor_id）／顔特徴量は共有マネージャ（ME-2）から取得 - 失敗情報（横向きすぎ、近い、遠い など） — GW: GW-EVT-1
CaptureStatusNotifiedEvent（姿勢ガイドguidance_code）／GW-EVT-7RegistrationFailedEvent（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-3 後に SA-2 で同意のみ完了にした参加者は、その状態のままではプロセス B へ進まない。GW-REQ-1 撮影開始要求、GW イベント待受、鏡誘導は行わない。
ダイアグラム
外部システム（NES / NEC）演出用PCタブレット演出装置
画面対応表
ユーザー操作・主要イベントのタイミングで各端末が表示している画面（タブレットは鏡誘導後に FCH スタッフへ戻り、以降は SA-2 モニタリング表示）：
| 操作・状態 | MA-1〜MA-3（タブレット） | 鏡 |
|---|---|---|
| ① 鏡N誘導開始（同意完了→鏡N割当） | 鏡への誘導（SA-4） | 来訪者を感知（SC-2） |
| ② お客様が鏡N前に立つ（タブレット回収後） | 訪問者一覧（SA-2）（鏡N 割り当て・撮影待ち、FCH モニタリング） | 来訪者を感知（SC-2） |
| ③ 撮影・加工中（共有マネージャ処理） | 訪問者一覧（SA-2）（撮影中・通信処理中） | 撮影開始（SC-3） |
| ④ レセプション顔登録 成功 | 訪問者一覧（SA-2）（成功表示） | 撮影完了・生成（SC-4）（成功演出） |
| ⑤ レセプション顔登録 失敗（画像条件不適合 / 横向き・近い・遠い 等） | 訪問者一覧（SA-2）（詳細エラー＋失敗画像） | 撮影完了・生成（SC-4）（失敗情報・自律判断用） |
| ⑥ 共有マネージャ 通信エラー（内部リトライ中） | 訪問者一覧（SA-2）（リトライ中・通信ステータス） | （継続） |
| ⑦ 共有マネージャ システムエラー（内部リトライ失敗） | 訪問者一覧（SA-2）（再登録 or 諦め通知） | （継続） |
| ⑧ 一定インターバル人なし → 登録フロー中断 | 訪問者一覧（SA-2）（中断通知・再開ボタン） | スタンバイ・待機（SC-1） |
| ⑨ ゲートウェイ通信失敗 | 訪問者一覧（SA-2）（通信失敗・レセプション顔登録省略） | スタンバイ・待機（SC-1） |
| ⑩ FCH スタッフが強制中止 | 訪問者一覧（SA-2）（強制中止モーダル） | スタンバイ・待機（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 顔画像参照は行わない。
ダイアグラム
演出用PCタブレット演出装置データストア
画面対応表
ユーザー操作のタイミングで各端末が表示している画面：
| 操作 | MA-1〜MA-3（タブレット） | 鏡 |
|---|---|---|
| ① お客様が完了表示を確認 | 訪問者一覧画面（SA-2）（該当者を完了状態に更新） | 生成完了（SC-5） |
| ② FCH スタッフが完了表示を確認（モニタリング） | 訪問者一覧画面（SA-2）（該当者を完了状態に更新） | 生成完了（SC-5） |
| ③ お客様が次アクション選択（他の登録者あり） | 完了後の次アクション選択モーダル（SA-5） | 生成完了（SC-5） |
| 全員完了 | 訪問者一覧画面（SA-2）（全員グレーアウト） | スタンバイ・待機（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-2） / 訪問者一覧（SA-2） | — | 選択会社の訪問者一覧を表示。誘導済みのお客様はグレーアウト |
| PA-5 | 名前選択 | 訪問者一覧（SA-2） | お客様が自分の名前の > ボタンを押下 | — |
| PA-6 | 個人情報同意 | 個人情報の取り扱い同意（SA-3） | お客様が同意操作 | — |
| PA 例外 | 同意のみ完了 | 同意画面（SA-3） ／ 訪問者一覧（SA-2） | 参加者本人が SA-3 の「同意して終了（撮影しない）」で辞退（SA-7 へ）、または FCH スタッフが SA-2 で代行する | 受付／進捗上は完了、顔データ未登録として状態更新。鏡割当・撮影開始は行わない |
| PA 例外 | 飛び入り参加者追加 | 参加者追加フォーム（SA-6） | FCH スタッフが手動追加／編集／削除 | — |
| PB-5 | 鏡N誘導表示 | 鏡への誘導（SA-4） | — | 「鏡N に立ってください」表示（鏡と同時）。完了ボタン操作後タブレットは FCH スタッフへ戻る |
| PB | レセプション顔登録ステータスモニタリング | 訪問者一覧（SA-2）（オーバーレイ） | FCH スタッフが確認 | 鏡N割当・撮影中・成功/失敗・リトライ中・通信ステータスを表示 |
| PB-8 成功 | 成功表示 | 鏡への誘導（SA-4） / 訪問者一覧（SA-2）（成功表示） | — | レセプション顔登録成功表示。失敗時の詳細エラー＋失敗画像は SA-2 モニタリングに表示（SA-4 には出さない） |
| PB 例外 | 中断・通信失敗通知 | 訪問者一覧（SA-2）（中断通知・再開ボタン／通信失敗表示） | FCH スタッフが確認 | 共有マネージャ システムエラー時は「再登録 or 諦め」通知 |
| PB 例外 | 強制中止 | 訪問者一覧（SA-2）（強制中止モーダル） | FCH スタッフが操作 | 該当タブレット・鏡をリセット |
| PC-1 | 完了表示 | （完了表示） | — | 完了表示 |
| PC | 次アクション選択 | 完了後の次アクション選択モーダル（SA-5） | お客様が次アクションを選択 | 他の登録者がいる場合のみ表示 |
| PC | 完了状態反映 | 訪問者一覧（SA-2）（該当者完了状態・グレーアウト） | — | レセプション顔登録完了した訪問者をグレーアウト |
| PC 全員完了 | 全員完了 | 訪問者一覧（SA-2）（全員グレーアウト） | — | 終了 |
演出用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-2 に訪問者一覧を表示 |
| PA 例外 | 同意のみ完了制御 | — | — | SA-2 で同意のみ完了にした参加者を完了状態へ更新。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-2 モニタリング）に反映 |
| 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-2）へ成功表示。GW-EVT-6 RegistrationCompletedEvent 受領で PC-2 完了情報保存へ |
| PB-8 失敗 | 失敗表示制御 | — | — | 品質不適合は GW-EVT-1 の guidance_code で鏡側ガイド継続。鏡へ失敗情報、タブレット（SA-2 モニタリング）へ詳細エラー＋失敗画像（お客様向けの SA-4 には出さない） |
| PB 例外 | システムエラー通知 | — | — | GW から GW-EVT-7 RegistrationFailedEvent 受領 → is_retryable=true ならタブレット（SA-2）に「再登録 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 に保管する。ただし 顔画像・NES 顔特徴量・氏名は当日限りで破棄（翌日の起動時に削除）。翌日に残るのは visitor_id と VI 生成用パラメータのみ（データ保持・破棄ポリシー） |
| PC-3 | 他演出への配信 | — | — | MF-1 から各演出ゾーンへ visitor_id・氏名・顔画像 URL を push 型で配信（MQTT WebSocket、MF-1 論点 7）。受信側は MF-1 から取得（モック実装は DS-3／DS-4） |
共有マネージャ
- 機材ID: ME-2
- 役割: レセプション顔登録パイプライン
- 操作者: なし（システム）
| 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 の連続配信はこのレート前提で演出設計する
| 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-9 のいずれかに組み込まれる（要確定）。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 でオンデマンドに取得 |
エンドツーエンド スイムレーン
外部システム（NES / NEC）演出用PCタブレット演出装置データストア
FAQ
レセプション顔登録システムの仕様に関するよくある質問と、確認済みの回答。
Q1. 「同意した」という情報を NES へ送る API はあるか？
A. ない。共有マネージャー API・レセプション顔登録ゲートウェイ API のいずれにも、同意情報を送信する専用の API・メッセージ・フィールドは存在しない（StartFaceCaptureRequest のペイロードにも同意関連の項目はない）。
同意完了状態は演出用PC（および SA-2 モニタリング）がローカルに保持する。レセプション顔登録に進む場合は撮影開始指示（GW-REQ-1 StartFaceCaptureRequest、[PB-2]）の送信をもって同意済みとして扱い、同意のみ完了（撮影 NG）の場合は GW-REQ-1 を送らない。
Q2. 「削除」と「解除」の違いについて
A. NES 一括登録 AP 画面で使われる「削除」と「解除」は、対象と意図が異なる。
- 解除: この顔の人を「この名前に紐づけた」という 紐付けを、その画面上で解除する操作。つまり、登録途中で「この顔はこの人ではない」と判断した場合に、紐付けを取り消すもの。
- 削除: 一度レセプション顔登録が終わった後に、一覧に出ている人の 顔を削除して、もう一回やり直す操作。間違って違う人を紐付けてしまった場合に、一度解除してから再度取り直すという流れで使われる。