NES 宛 質問リスト

レセプション顔登録（Z-1）の NES チーム（ゲートウェイ ME-1／共有マネージャ ME-2 開発）への確認事項。全 13 件。最新の回答状況は下表のとおり。

関連: レセプション顔登録 全体仕様／API 仕様

#	サマリ	状態
1	ページング仕様の要否	回答済（2026-05-29）
2	顔画像取得 API の解像度	回答済（2026-05-29）
3	face_status の各値の意味	回答済（2026-05-29）
4	ペイロードの文字コード	回答済（2026-05-29）
5	face_image（Base64）の具体フォーマット	回答済（2026-05-29、2026-06-01 追記）
6	timestamp フォーマット	回答済（2026-05-29）
7	人物区分の表記揺れ（user_type/type、visitor/guest）	回答済（2026-06-02 追記）
8	顔画像の破棄タイミング	回答済（2026-05-29）
9	ミドルウェア・ランタイムのインストール権限（事後申請可？）	回答済（2026-06-02）
10	バックアップの考慮 — 待機系プログラム／冗長構成	タイミングをみて徐々に確認
11	バックアップの考慮 — データバックアップ	タイミングをみて徐々に確認
12	ZMQ イベント取りこぼし時のリカバリ手段（ジョブ状態問い合わせ API の有無）	回答済（2026-06-02）
13	顔認識時のカメラと人の推奨位置（カメラ高さ 140cm）	未起票

Q1. ページング仕様の要否

• 質問: 共有マネージャー API（API-1 GET /v1/groups/{date}／API-2 GET /v1/users/{group_id}）にページングパラメータの定義がない。日付・グループでのフィルタリングで十分小さく収まる前提でよいか。
• NES 回答（2026-05-29）: NES が担当している画面では人数が多い場合はスクロールして表示する想定。訪問数が最大 10 名程度との伺いに基づき、ページングは不要。

Q2. 顔画像取得 API の解像度

• 質問: API-3 GET /v1/users/{visitor_id}/faces/image が返す顔画像（application/octet-stream）の解像度・縦横比を確認したい。512 × 512 px 程度を想定。
• NES 回答（2026-05-29）: レセプション顔登録用に用いられた画像そのものを返却するため、4K 画像から顔検出された顔（頭）の部分を切り出したもの。縦横比もサイズも不定。

Q3. face_status の各値の意味

• 質問: 共有マネージャー API-2 の face_status（still / inprocess / provisional / complete / error）の各値の意味と遷移タイミングを確認したい。
• NES 回答（2026-05-29）:
  • still: 未登録。レセプション顔登録前の状況。
  • inprocess: 登録（削除）処理中。何かしらのレセプション顔登録アプリでレセプション顔登録要求があり、登録処理中の状況。
  • provisional: 仮登録完了。何かしらのレセプション顔登録アプリでレセプション顔登録要求があり、要求のあった顔画像には問題なくレセプション顔登録成功するに間違いないと判断されたときの状況。
  • complete: 登録完了。何かしらのレセプション顔登録アプリでレセプション顔登録要求があり、レセプション顔登録が完了した状況。
  • error: 登録（削除）エラー発生。何かしらのレセプション顔登録アプリでレセプション顔登録もしくは顔削除要求があり、エラーで処理が止まってしまった状況。

Q4. ペイロードの文字コード

• 質問: ゲートウェイ ME-1 の ZeroMQ メッセージおよび共有マネージャー API のレスポンスの文字エンコーディングを確認したい（UTF-8 想定で問題ないか）。
• NES 回答（2026-05-29）: UTF-8。

Q5. face_image（Base64）の具体フォーマット

• 質問: CaptureStatusNotifiedPayload（GW-EVT-1）等の face_image（Base64）の画像フォーマットと文字列形式（Data URI スキーム付きか否か）を確認したい。
• NES 回答（2026-05-29）: JPEG 画像データを以下仕様で Base64 エンコード。
  • アルファベット: RFC 4648 標準（A-Za-z0-9+/）
  • パディング: = を使用
  • 改行: なし（1 行出力）
  • 仕様準拠: RFC 4648 Section 4（標準 Base64）
• NES 回答（2026-06-01・追記）: 顔共有マネージャー操作 API（共有マネージャー API-3 GET /v1/users/{visitor_id}/faces/image）から返る画像は、Web ブラウザの <img> タグの src 指定でそのまま表示できることを想定し、顔登録に利用された JPEG 画像データをそのまま返却する。

Q6. timestamp フォーマット

• 質問: BaseEvent・ResponsePayload 等の timestamp（type: string / format: date-time）の具体的なフォーマット・タイムゾーン・秒未満の精度を確認したい。
• NES 回答（2026-05-29）: RFC 3339、ミリ秒まで表示、日本時間で出力。
  • 例: 2026-05-26T13:22:34.171+09:00

Q7. 人物区分の表記揺れ

• 質問: ゲートウェイ ME-1（StartFaceCapturePayload）は user_type ／ employee / visitor、共有マネージャー API ME-2（Visitor スキーマ）は type ／ employee / guest と表記が揺れている。同じものを指す想定でよいか。
• NES 回答（2026-06-02）: employee / visitor の区分を employee / guest に統一し、API 仕様書を改版済み。両 API の人物区分は同一のものを指し、値は employee / guest（旧ゲートウェイの visitor は廃止）。

Q8. 顔画像の破棄タイミング

• 質問: GW-EVT-1 / GW-EVT-3 の face_image（Base64）や API-3 の顔画像バイナリを、演出側はいつまで保持してよいか（個人情報保護の観点で破棄ポリシーを確定したい）。
• NES 回答（2026-05-29）: 基本「用済み後削除」。可能であれば 当日中に破棄すべき。

Q9. ミドルウェア・ランタイムのインストール権限

• 質問: NES 提供環境（ゲートウェイ・共有マネージャ等が稼働するホスト／VM／コンテナ）に、演出側でミドルウェアやランタイム（Node.js／Python／DB クライアント／ドライバ等）を 自由にインストールできるか。事後申請でよいか、それとも事前承認が必要か。
• NES 回答（2026-06-02）: おそらく制限はないが、一応確認するとのこと（藤井さん）。
• 状態: 回答済（2026-06-02）。確認待ち（藤井さん）。

Q10. バックアップの考慮 — 待機系プログラム／冗長構成

• 質問: NES 提供のゲートウェイ・共有マネージャに 待機系プログラム や 冗長構成（Active-Standby / Active-Active 等）が設けられているか。フェイルオーバ時の挙動・切替時間・演出側で考慮すべき点を確認したい。
• 状態: タイミングをみて徐々に確認（演出側で受け止めるべき要件を整理する必要あり）。

Q11. バックアップの考慮 — データバックアップ

• 質問: NES 提供環境で扱う データ（訪問者情報・顔特徴量・顔画像・各種ログ等）のバックアップ方針（取得頻度／世代数／保管場所／復元手順）を確認したい。
• 状態: タイミングをみて徐々に確認（演出側で扱うデータの保持・復元要件を整理する必要あり）。

Q12. ZMQ イベント取りこぼし時のリカバリ手段

• 質問: ZMQ メッセージの 取りこぼし（演出用PC のクラッシュ・リブート・ネットワーク瞬断など）が発生した場合、どのようにリカバリすればよいか。ジョブ単位（撮影セッション単位）の状態問い合わせ API は提供されるか。
• NES 回答（2026-06-02・畑さん）: ZMQの方の質問ですが、残念ながらZMQ的な対策はないです。訪問者リスト取得APIで顔登録を依頼したと思われる方のレコードをさがしていただき、face_statusでどのような状況かを確認するぐらいです。
• 状態: 回答済（2026-06-02）。ジョブ単位の状態問い合わせ API はなく、訪問者リスト取得 API（API-2）の face_status（Q3 参照）で代替確認する。

Q13. 顔認識時のカメラと人の推奨位置

• 質問: 顔認識（レセプション顔登録）時のカメラの高さは 140cm と認識しているが、カメラと人（被写体）の推奨位置（立ち位置・距離等）はあるか。過去にご回答済みでしたら申し訳ございません。
• 状態: 未起票。