🏨法改正、現場の運用、エントランスのカメラ端末。省人化ホテルの本人確認をソフトウェアでつなぐ
渋谷区のホテルで、顔照合システムの運用を開始しています。旅館業の改正に合わせて、エントランスのカメラ端末、AWSの照合処理、フロントスタッフの業務画面をつなぎました。法令の要件、現場の運用、カメラ端末のそれぞれについて取り組んだことを紹介します。
# はじめに
こんにちは、matsuri technologies開発部開発課の後醍院です。
渋谷区のホテルで、顔照合システムの運用を開始しています。ゲストがエントランスを通ると、カメラ端末が撮影します。顔照合システムは、その日に泊まっているゲストの中から似ている人を探し、候補をフロント業務の画面に並べます。チェックイン済みにするかどうかは、スタッフがその画面を見て判断します。
きっかけは、2025年の旅館業の改正です。宿泊施設のチェックインでは、来た人が予約したゲスト本人かどうかを確認する必要があります。これまではフロントのスタッフや、ビデオ通話の向こうにいるオペレーターが確認していましたが、改正でカメラやシステムを使って確認できるようになりました。
ただ、実際に取り組んでみると、考えるべきことは法令の要件だけではありませんでした。現場のスタッフがどの画面で何を確認するかという運用と、エントランスに置いたカメラ端末という物理的な機器も関わってきます。
この記事では、顔照合システムの運用を始めるまでに、この3つをソフトウェアでつなぐために取り組んだことを紹介します。
# フロントを省人化しても、本人確認は欠かせない
2025年4月1日に、厚生労働省の「旅館業における衛生等管理要領」が改正されました。条件を満たせば、フロントで従業員がゲストと面接しなくてもよくなります。実際に適用される時期は、自治体の条例で決まります。
面接がなくなっても、本人確認そのものは必要です。改正後は、システムやカメラを使った本人確認と、その記録が求められます。この記事でも、法令が求めることを「確認」と「記録」の2つに分けて考えます。
matsuri technologiesでも、この改正に合わせた新しいチェックインフローを作っています。顔照合システムは、そのうちエントランスのカメラを使った本人確認を担当するシステムです。
# 本人確認を支える5つの作業
作り始める前に、本人確認のためにどこで誰が手を動かしているかを洗い出しました。作業は大きく分けて次の5つで、担当する人はそれぞれ異なります。
- ビデオ通話での確認（オペレーター）。ゲストが到着するたびに、オペレーターがビデオ通話で本人を確認します。
- 目視での照合（フロント業務のスタッフ）。カメラで撮影しても、フロント業務のスタッフが映像を1本ずつ見てどの予約のゲストかを探すなら、確認する場所が変わるだけです。
- 管理画面の行き来（フロント業務のスタッフ）。予約情報と映像が別々の画面にあるため、フロント業務のスタッフは複数の画面を開いて見比べることになります。
- 端末の設定のための現地作業（カメラ端末の管理担当）。カメラ端末は物件の識別子をプログラムに直接書き込んでいたので、設定を変えるたびに、担当者が現地で書き換える必要がありました。
- 記録が残っているかの確認（カメラ端末の管理担当）。映像が届かないとき、担当者は誰も通らなかったのか、カメラが故障しているのかを区別できませんでした。入退室の記録は保健所に提出する証拠なので、確実に残っていることを確かめられる必要があります。
1から3は確認の作業で、4と5は記録を残し続けるための作業です。ここからは、前半で確認の作業、後半で記録の作業について、取り組んだことを紹介します。
# 判断は人が行い、探して揃える作業はシステムが行う
確認の作業で最初に取り組んだのは、ゲストが到着するたびに行っていたビデオ通話での確認（作業1）の置き換えです。システムが候補を揃えておき、スタッフがそれを見て判断する形にしました。
そのうえで、照合結果だけでチェックインを完了させない方針を決めました。
顔照合の結果が「一致」でも、システムはチェックインを自動で完了にしません。顔照合システムが担当するのは、カメラの映像から照合に使える顔を切り出し、その日に滞在しているゲストの中から似ている人を探し、候補を根拠の画像と一緒に並べるところまでです。
チェックイン済みにするかどうかは、スタッフが判断します。判断に使うのは、スタッフが普段使っているフロント業務の画面に表示される予約とゲストの情報、写真です。
人の判断を残した理由は2つあります。
1つ目の理由は、本人確認ができたかどうかと、チェックインを完了してよいかどうかが、別々の判断だからです。たとえば照合できた人数が予約人数に足りないとき、どう扱うかは施設や運用によって変わります。この判断のルールまでシステムに組み込むと、運用が変わるたびに改修が必要になります。
2つ目の理由は、照合が外れた場合に備えるためです。照合結果だけでチェックインまで完了させると、照合が外れていたときに取り消す作業が発生します。システムの役割を候補を出すところまでにしておけば、照合が外れていても、スタッフが確認する段階で気づけます。
映像の中からゲストを探す作業はシステムが引き受け、スタッフは並んだ候補を見て確認します。顔照合システムの目標は、必要なときにスタッフがすぐ確認に動ける状態を、システムで用意しておくことです。
# 全体の流れ
ゲストの事前チェックインから、スタッフの判断までの流れは次のとおりです。
この流れの中で、スタッフが確認に集中できるように取り組んだことを3つ紹介します。
# 比べる相手を、今日この施設に泊まっている人に絞る
目視での照合（作業2）では、スタッフが映像を見て、どの予約のゲストかを探していました。システムが探す場合も、比べる相手が多いほど似た顔が増え、見分けにくくなります。そこで、比べる相手を絞ることにしました。
照合にはAmazon RekognitionのCollectionを使っています。Collectionには顔の特徴を登録でき、新しい画像に似た顔を検索できます。顔の索引のようなものだと考えてください。
Collectionは施設ごとに作り、今その施設に滞在しているゲストの顔だけを登録しています。登録と削除は、チェックインシステム側のバッチが定期的に実行しています。
比べる相手が数十人なら、似た別の人と見分けやすくなります。候補に出てくるのは今日泊まっている人だけなので、スタッフも状況を把握しやすくなりました。
# 確認は、フロント業務の画面の中で行う
※この節の画面キャプチャは、個人情報にあたるため、写真と映像を黒く塗りつぶしています。
管理画面の行き来（作業3）をなくすために、照合結果は、スタッフがフロント業務で使っている画面で確認できるようにしました。顔照合システムは、次の情報をAPIで提供しています。
- 施設と期間を指定した、入退室の映像の一覧
- カメラに映った顔の一覧
- 照合の結果、どの予約のどのゲストらしいか
このAPIの利用者は、ホテルのフロント業務を担当する別チームのプロダクトです。その画面の「入館確認」メニューには、顔照合、入館記録、滞在者の3つの画面があります。以下は、運用中の画面のキャプチャです。施設名・予約番号・氏名・客室名は置き換えています。
顔照合の画面には、カメラが捉えた人のカードが時間帯ごとに並びます。予約のゲストと一致したカードは緑の枠、一致しなかったカードは赤の枠で表示されます。
カードを開くと、ゲストが事前チェックインで登録した顔写真と身分証、カメラの検知画像が並び、予約番号と類似度が表示されます。スタッフはこの3枚を見比べてから、そのまま予約詳細の画面に進めます。
入館記録の画面には、照合できたかどうかにかかわらず、エントランスで撮影した映像がすべて時間順に並びます。顔が映っていない映像も、この画面で確認できます。
滞在者の画面には、その日に滞在している予約ごとに、ゲストが事前に登録した顔写真が並びます。照合の範囲と同じく、今日この施設に泊まっている人を単位にしているので、スタッフも照合と同じ範囲でゲストを確認できます。
スタッフは、フロント業務で使っている画面の中で、映像と候補を見比べて確認を終えられます。
# ゲストの顔写真を、照合システム側に置かない
確認の作業とは別に、ゲストの顔写真をどこに置くかも考えました。照合元の顔写真は、ゲストが事前チェックインで登録したものです。この写真はチェックインシステムが管理していて、Collectionへの登録と削除もチェックインシステムが実行します。顔照合システムはCollectionを検索して照合するだけです。
Collectionが保存するのは顔の特徴を表すデータで、写真そのものは含みません。そのため、顔照合システム側にゲストの顔写真を置く必要がありません。照合結果は、一致したものだけを保存しています。必要な情報は、どの予約のゲストが映っていたかだからです。
# 照合が外れても、確認と記録が残る設計
ここからは、記録の作業についてです。
顔照合のシステムについて話すと、精度は何パーセントかと聞かれることがあります。今回のシステムでは、照合の精度だけに頼らない設計にしました。照合が外れた場合でも、記録が抜け落ちないようにしています。
予約のゲストと一致しなかった撮影は、顔照合の画面に赤い枠で並び、スタッフが確認します。横顔しか映っていない画像のように、照合に使えない画像もあります。その場合も映像は入館記録に残るので、スタッフが必要に応じて個別に確認できます。
関係者によって知りたいことが違ったことも、この設計につながりました。事業者として知りたいのは、予約したゲストが到着したかどうかでした。一方、保健所が確認したいのは、いつ入退室があったかです。法改正で求められる記録は、こちらにあたります。
保健所の確認に必要なのは、撮影の記録が漏れなく残り、あとから見られることです。そのため顔照合システムでは、顔を検出できなかった映像や変換に失敗した映像も、入退室の記録として一覧に出しています。
ただし、ソフトウェア側で記録を残す仕組みを用意しても、エントランスのカメラ端末が止まれば記録は欠けてしまいます。
# 現地に行かずに、カメラ端末を運用する
実際に運用を始めると、手間がかかったのはエントランスに置いた小さなカメラ端末のほうでした。
記録が欠けずに残り続けることは、近隣の方や行政に安心してもらうための前提です。そこで、端末の設定のための現地作業（作業4）と、記録が残っているかの確認（作業5）に取り組みました。カメラ端末を現地に行かずに見守り、設定を変えられるようにしています。
# 設定の変更も状態の確認も、サーバー経由で行う
最初のカメラ端末は、物件の識別子や撮影の設定をプログラムに直接書き込んでいました。設定を1つ変えるだけでも、現地で書き換える必要がありました。映像が届かないときに、誰も通らなかったのか端末が止まっているのかも区別できませんでした。そこで、次の順番で改善しています。
- Wi-Fiや物件の識別子を、Wi-Fi経由で設定できるようにした。識別子と施設の対応づけはサーバー側で管理する
- 端末から定期的にサーバーへ状態を報告させるようにした（heartbeat）
- heartbeatの応答で、撮影時間や画質などの設定を端末に配るようにした
- 開発者でなくても、管理画面から設定を変え、端末に反映されたかを確認できるようにした
- ファームウェアも、現地に行かずに更新できるようにした
heartbeatの仕組みは、社内の別のIoTプロジェクト（騒音計）で使っていた方式を参考にしました。定期的に行う報告の応答に、設定や指示を載せて返しています。報告が一定時間届かなければ停止と判定します。この判定で、誰も通らなかったのか端末が止まっているのかを区別できるようになりました。
# おわりに
顔照合システムでは、法令の要件、現場の運用、カメラ端末の3つをつなぐことに取り組みました。
確認の作業では、照合結果だけでチェックインを完了させず、最終判断をスタッフが行う形にしています。比べる相手は今日この施設に泊まっている人だけで、候補はフロント業務で使う画面に並びます。記録の作業では、照合が外れても映像が入館記録に残ります。カメラ端末の設定変更や状態の確認も、現地に行かずに済むようにしました。
法令の要件、現場の運用、カメラ端末のどれか1つだけを見ていても、この仕組みは作れませんでした。3つをつなぐ小さな判断を積み重ねて、本人確認を確実に続けられる仕組みにしています。この仕組みは今も渋谷区のホテルで、毎日のチェックインを支えています。