【iOS 27】事前チェックインで、宿泊者がパスポートを撮って名簿を自分で埋める（ホテルのアプリ設計）

こんにちは。リテールアプリ共創部で事業企画を担当しているかめだです。

ホテルに着く前にスマホで氏名や住所を入力しておくと、当日はフロントでQRコードを見せてサインをするだけで済みます。この事前チェックインの仕組みは、ホテルのアプリやWebに広がっています。

今回は、この入力・送信の前に、宿泊者のiPhoneでAIを使う設計を考えます。入力する画面自体はもうあるので、入力前の手順と、受け取ったホテル側の作業がどう変わるかを書きます。

事前チェックインで、宿泊者名簿の記入はどこまで進んでいるか

セルフチェックインシステムには、宿泊者情報を事前に入力しておき、当日はQRコードをかざして署名するだけでチェックインが完了するものや、AIを活用したパスポートの自動読み取りと本人認証の機能を持つものがあります。事前入力とQRコードでのチェックインは、すでに珍しいものではなくなっています。

一方で、宿泊者名簿に何を書くかは、旅館業法にもとづいて決まっています。令和5年12月13日施行の改正で職業欄が削除され、連絡先が追加されました。記載事項を整理すると、次のようになります。

フロント業務については、氏名・住所・電話番号などを端末で入力することで紙の記入や転記作業を減らしやすいとされる一方、外国人宿泊者のパスポート確認に対応する機能があればフロントでのコピー対応や確認作業を効率化できる、とも説明されています。事前チェックインで入力そのものは前倒しできても、外国人宿泊者の旅券の呈示・写しの取得・名簿への転記は、当日フロントの作業として残っています。

外国人の宿泊者が多いホテルでは、フロント担当者が限られた人数で、宿泊者ひとりひとりの旅券を確認し、コピーを取り、名簿に転記しています。チェックインの時間帯にこの作業が集中します。事前チェックインで氏名や連絡先を先に受け取れていても、旅券の確認と転記だけは当日に残ります。

読み取り機能を持つシステムはあるのに、なぜ広がらないのか？

AIでパスポートを自動で読み取り、本人認証まで行うセルフチェックインシステムは、すでにあります。それでも事前チェックインのアプリ全体に広がらないのは、本人確認書類の送り先が1か所増えるからです。

パスポートや運転免許証の画像は本人確認書類です。宿泊者は「ホテルに送る」つもりで撮っています。その画像を外部のAIサービスにも渡す設計にすると、ホテルに送る同意とは別に、外部に渡すことの説明と社内の審査が要ります。ここで企画が止まりやすいと考えます。

費用の面でも選びにくくなります。事前チェックインは多くの宿泊者が使う機能なので、回数に比例する課金はホテルの負担になります。端末の中で読む設計なら、この課金は発生しません。対応端末の調達や、確認画面の開発・運用にかかる費用は別に必要です。

宿泊者が送る前に内容を確認して直せること自体は、クラウドで読んでも端末内で読んでも、画面の設計次第で実現できます。この記事では、本人確認書類を渡す先を増やさずに済む端末内での読み取りを前提に、その確認画面を設計します。

端末内で読む理由は、本人確認書類を渡す先を増やさないことです。逆に、対応端末を持つ宿泊者が少ない、券面の様式が多く試作で精度が要件に届かない、確認画面での入力が増えて離脱が増える、のどれかに当たるなら、端末内は選ばず、クラウドでの読み取りかいまの運用を続けます。

券面から名簿に入る項目と、本人が入力する項目

iOS 27で加わったのは、券面の写真をそのまま渡す機能（Attachment で画像をプロンプトに添付する（Foundation Models の画像入力））と、文字を読み取る標準のOCRツール（AI にツールを持たせる（OCRTool・バーコード・端末内検索））です。この2つを組み合わせると、パスポートや運転免許証の画像から名簿に要る氏名・国籍・旅券番号（免許証なら氏名・住所）を宿泊者名簿の項目に振り分け、券面の写真1枚から名簿の下書きを宿泊者の端末の中だけで作れます。連絡先や到着日・出発日は券面には書いていないので、これまでどおり宿泊者が入力します。旅券には住所がないので、旅券を撮った宿泊者は住所も入力します。

読み取れなかった項目は空欄のまま残し、宿泊者が自分で入力します。券面1枚と項目の定義を渡す想定です。券面の画像が大きいほど処理に時間がかかるので、想定する画像で実測します。宿泊者が撮る券面の写真は、暗い場所や斜めからの撮影でぶれることもあるはずなので、実測は明るさや角度を変えた複数のパターンで行っておくと、実際の使われ方に近い数字が取れます。

パスポートと運転免許証とでは、記載されている項目も並び方も違います。免許証には住所が記載されていますが、パスポートにはありません。項目の定義を書類の種類ごとに用意し、どちらの書類が撮られたかをまず判定してから、それぞれの項目に振り分ける手順にします。

本人確認や顔認証の判定は、端末内のAIにはやらせません。読み取りは記入の補助で、確定はフロントで原本と照合して行います。対応端末を持たない宿泊者は、これまでどおり自分の手で項目を打つ手順のままです。対応端末の宿泊者には確認画面を挟み、非対応の宿泊者には今の手順を残します。この2通りを用意します。読み取れる言語や文字は端末のOCRが対応する分だけで、旅券や運転免許証の様式は国ごとに違うため、実際にどこまで読めるかは試して確かめる必要があります。

対応端末・費用などの共通の前提は、iPhoneの中でAIが動くと、どの業界の何が変わるのか（Apple Intelligence 業界別活用マップ） の「どの業務にも共通する前提」にまとめています。

確認画面と、旅券の写しを送る宿泊者をどう分けるか？

確認画面は「元の写真と読み取り結果を並べ、本人が直して送る」、送る項目は「国内に住所のない外国人か、それ以外か」で分けます。この2つを先に決めます。

送る前の確認画面を用意します。撮った旅券や運転免許証の写真（原文）と、読み取った氏名・国籍・旅券番号（免許証なら氏名・住所）を並べて表示し、宿泊者が入力する連絡先・到着日・出発日（旅券の場合は住所も）と合わせて1画面にまとめます。免許証の住所が現住所と違う場合は、宿泊者がその場で直します。宿泊者は元の写真と読み取り結果を見比べて、違っている項目があればその場で直し、「この内容で送る」を押します。読み取りの下書きで誤りは減りますが、なくなりはしません。

送る項目は、宿泊者の区分で表にしておきます。

国内に住所のない外国人については、ホテル側に旅券の呈示を求め、写しを名簿とともに保存することが求められているため、画像もそのまま送る設計にします。それ以外の宿泊者には写しの保存の定めがないため、読み取った項目だけを送り、画像そのものは送らない設計にできます。この区分は法令上の扱いで、それ以外の宿泊者に本人確認書類の呈示を求めるかどうかは、施設の方針として別に決めます。

確認画面の文言は、宿泊者が使う言語に合わせて出し分ける必要があります。読み取った項目そのものは言語によらず同じデータですが、画面の説明文やボタンの表示は、多言語対応のアプリであれば既存の翻訳の仕組みを使います。

フロント側の画面では、宿泊者から届いた下書きの名簿と、外国人宿泊者であれば旅券の写しを並べて表示します。チェックイン時に、担当者が宿泊者本人と原本（国内に住所のない外国人は旅券、それ以外は施設の方針で決めた書類）を照合し、内容を確定するボタンを押します。事前チェックインが前倒しするのは記入と写しの取得であって、本人確認そのものはこれまでどおりフロントの仕事です。画像を先に送ってもらうことで減るのはコピーの作業、AIの下書きで減るのは名簿への転記です。この2つは別の効果なので、分けて数えます。

同行者の扱いも決めておく必要があります。宿泊者名簿は宿泊者ごとに作るものなので、代表者が同行者の旅券や運転免許証もまとめて撮る運用を認めるか、同行者それぞれに確認画面を送るかは、施設ごとに決めます。同行者が本人確認を要しない区分で、代表者が内容を確認できるなら代表者がまとめて撮る運用を認めてよく、国内に住所のない外国人が同行者に含まれる場合や団体で人数が多い場合は、各人に確認画面を送ります。AIの処理自体は、1人分の券面を1件ずつ読み取ります。家族旅行や団体客のように同行者が多い予約ほど、この決め方が現場の運用に影響します。

処理は宿泊者の端末内で完結させ、Appleのサーバー側にある大きいモデルには渡さない設計にします。旅券や運転免許証の画像は本人確認書類であり、名簿の項目に振り分けるという仕事は、端末内で完結できる作業だと考えています。渡す情報も、その券面1枚と項目の定義だけに絞り、宿泊者の他の予約履歴までは渡さない設計にしておきます。

まず免許証、次に旅券の2段階で始める

2段階に分けます。第1段階は、国内に住所がある宿泊者の運転免許証です。写しの保存の定めがなく、送るのは項目だけで済むため、設計が単純です。ここで確かめるのは、名簿の転記がどれだけ減るかです。第2段階は、国内に住所のない外国人の旅券です。ここで確かめるのは、写しの取得と転記がどれだけ前倒しできるかです。

アプリは、対応端末（iPhone 15 Pro/Pro Max か iPhone 16 以降）でApple Intelligenceがオンになっていて、端末内のモデルが使える状態かを確認してから確認画面を出します。使えないとき、読み取りに失敗したときは、いまの入力画面に戻します。この振り分けは対応するiOSアプリに組み込む必要があり、Webの事前チェックイン画面だけの施設では、まずアプリ側の準備が要ります。

試作は、自社の開発部門か開発会社に、撮る、下書きにする、宿泊者が確認して送る、という最小の画面だけを頼みます。

数えるものは宿泊者単位にします。確認画面を開いた宿泊者のうち送信まで進んだ割合、送信した宿泊者のうちフロントで名簿を直した割合（項目ごとにも記録）、チェックイン1件あたりの所要時間です。第2段階では旅券の写しを取り直した件数も数えます。期間と対象人数を決め、これまでの手順と、宿泊者側とフロント側の両方の作業時間を比べます。

続けるかどうかの基準は、試す前に決めます。

この表は試す前に埋めておきます。結果を見てから基準を決めると、結果に合わせた基準になります。

必要なものは、すでにある事前チェックインのiOSアプリ、名簿の項目定義、お手本になる券面数十件（自社スタッフの同意を得た券面か、テスト用の見本）、試作用の対応端末、フロント側の画面の改修、そして試作を頼む先です。

最初の対象は1施設に絞ります。第1段階は国内の宿泊者の事前チェックイン利用が多い施設、第2段階は外国人宿泊者の比率が高くチェックインの時間帯が混む施設を選ぶと、それぞれの効果を測りやすくなります。

よくある質問

旅券の写しを保存する義務があるなら、画像を送らない設計に意味はありますか。

国内に住所がある宿泊者には意味があります。写しの保存の定めがないため、項目だけを送り、画像そのものは送らない設計にできます。国内に住所のない外国人についてはホテルが写しを保存するため画像も送りますが、記入そのものは端末内で先に済ませられます。

本人確認や顔認証まで、端末内のAIでやるのですか。

やりません。読み取りは記入の補助までで、本人確認はフロントで宿泊者本人と原本を照合して行います。

予約サイト経由の宿泊者にも使えますか。

自社アプリや自社の事前チェックイン画面を開く宿泊者が対象です。予約サイトの画面をそのまま使っている宿泊者は、この機能を利用できません。

対応していないiPhoneやAndroidの宿泊者は、どうなりますか。

これまでどおりの入力画面になります。アプリ側で端末とモデルの利用可否を確認し、対応端末なら確認画面、非対応ならいまの手順に分けます。

参考

• Apple, "Meet the updated Foundation Models framework", WWDC26: https://developer.apple.com/videos/play/wwdc2026/241/
• 大阪府「宿泊者名簿の記載徹底について」 https://www.pref.osaka.lg.jp/o100090/kankyoeisei/guest-list/index.html
• 川崎市「宿泊者名簿の必要事項の記載の徹底について」 https://www.city.kawasaki.jp/350/page/0000097871.html
• ASPIC「セルフチェックインシステム比較」 https://www.aspicjapan.org/asu/article/29570
• staysee ホテルノート https://staysee.jp/hotel-note/hotelsystem/self_checkin/

では、おつかめ！

--

クラスメソッドでは、既存スマホアプリをFlutterでiOS/Android同時に作り直し、バックエンドはAWSで再構築する「AI駆動アプリリニューアル」を提供しています。現行アプリの仕様読み解きから設計・実装まで生成AIを組み込んだ開発プロセスで進めるため、レガシー化したアプリのリニューアルを短い期間で作り直します。
サービス詳細・お問い合わせはこちら