旅館・ホテルのフロントで手書きされる宿泊者カードを読み取り、氏名・住所・連絡先・国籍・旅券番号を宿泊者名簿のデータに転記して、記入漏れを当日のうちにフロントへ返す

処理の起点を決める

チェックインのときに、フロントが卓上スキャナーでカードを読み込むことを起点にします。 スキャナーは読み込んだ PDF を取込フォルダへ保存し、Google Apps Script の時間主導型トリガーが数分おきにそのフォルダを見ます。 夜にまとめて読み込むと、記入漏れが返るのは結局深夜になります。

ファイル名に部屋番号を入れます。 フロントは読み込むときにスキャナーの画面で部屋番号を選ぶか、カードの右上の部屋番号の欄に書きます。どちらも無いカードは、到着予定の一覧と氏名で照らします。

1回の実行で処理する件数に上限を置きます。 Apps Script の1回の実行は6分までとされています。チェックインの集中する夕方に備え、1回に8件までとし、残りは次の実行に回します。 処理済みフォルダへ移すのは、名簿の下書きへの書き込みまで成功したときだけにします。

入力データを集める

質を決めるのは、カードの欄の一覧です。 返ってきたキーと値の組を、どの欄の答えかに当てはめる物差しになります。必須の欄が一覧に無ければ、空欄だったのか、そもそも読まれなかったのかが分かりません。

到着予定の一覧は、人数を見るために持ちます。 予約が3名なのにカードの同伴者の欄が1名なら、2名分の氏名が書かれていないことが分かります。

データの取得方法を決める

読み取りは、Apps Script から Document AI の処理のAPIを呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。

旅券番号は、ここで Apps Script が取り出します。 「旅券番号／Passport No.」の欄の値を名簿の下書きへ直接書き、Gemini API に渡す全文のテキストとキーと値の組からは、その値を記号に置き換えて伏せます。 旅券番号は名簿の項目にそろえる必要がほとんど無く、生成AIに渡す理由がありません。

キーが見つからない欄は、全文のテキストで場所を探します。 カードの欄の一覧にある欄の名前が全文のどこにあるかを見て、その近くに値らしい文字があるかで「空欄」と「見つからない」を分けます。

AIへ渡す前に整形する

1. 形式の確認 … Form Parser の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP です。スキャナーの保存形式は PDF にします
2. 解像度の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。卓上スキャナーを300dpiに設定します
3. 圧縮の確認 … 非可逆の形式は、ファイルを小さくすると精度が落ちることがあるとされています。スキャナーの「小さいファイル」の設定を使いません
4. 向きの確認 … 逆さに読み込んだものは、画像の向きを直してから渡します
5. 旅券の写しとの分け … 旅券の写しを同じフォルダに読み込まないよう、写しは別のフォルダに保存します
6. 重複の検知 … 同じ部屋番号・同じ到着日のカードが2枚あれば、後のものに「書き直し」の印を付けます

5番目を軽く見ないでください。 旅券の写しがカードと一緒に Document AI と Gemini API へ流れると、伏せたはずの旅券番号が写しの側から渡ります。 写しの有無は、別のフォルダにファイルがあるかだけで見ます。

AIに処理させる

させるのは、カードに書かれた文字を、名簿の項目に写すことだけです。 必須の項目がそろっているかの判断はさせません。

右端の列が、この構成でいちばん大事な区別です。 書かれていない項目を、ほかの欄や予約の情報から埋めさせません。特に国籍は、氏名や住所の国から推し量らせません。

3行目がいちばん起きやすい失敗です。 予約の情報をAIに渡すと、空欄の連絡先を予約の電話番号で埋めます。その瞬間、カードに書かれていなかったという事実が消えます。 予約の情報は Apps Script だけが持ち、AIには渡しません。

指示内容を固定する

あなたはホテルのフロントで、宿泊者が手書きした宿泊者カードを読み、
宿泊者名簿に写すための下書きを作る立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 書類が宿泊者カードかを判断してください。
   旅券の写し、領収書、アンケートなど別の書類なら、
   写さずに document_type を other にしてください。
2. 代表者の氏名、住所、電話番号、メールアドレス、国籍、
   「日本国内に住所がありますか」の印、同伴者の氏名を写してください。
3. 読み取り結果の中の [MASKED] は伏せた値です。そのままにしてください。

【厳守事項】
- 文字は書かれたものをそのまま入れてください。綴りを直さないでください。
- 読みにくい字は、読めた文字のまま value に入れ、unclear を true にしてください。
  ほかの欄の内容から推し量って決めないでください。
- 書かれていない欄は空にしてください。
- 国籍が書かれていないときに、氏名の綴りや住所の国から決めないでください。
- 国内の住所の有無は、チェックボックスの印だけで決めてください。
  印がどちらにも無ければ unknown にしてください。
- 記入がそろっているか、名簿として足りているかについて書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。

【読み取り結果（キーと値の組、チェックボックス、全文。旅券番号は伏せてあります）】{ocr_result}
【このカードの版の欄の一覧】{card_fields}

「綴りを直さない」を明記しないと、AIはローマ字の氏名を「よくある綴り」に寄せます。 名簿の氏名は旅券と同じであるべきで、直された綴りは、もう一度旅券を見ないかぎり誤りだと分かりません。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、Interactions の response_format に JSON スキーマを渡すと、そのスキーマに従う応答を生成させられるとされ、enum で値の候補を限り、required で必須の項目を決められます。

{
  "document_type": "registration_card | other",
  "room_no": "",
  "guest": {
    "name": { "value": "", "unclear": false },
    "address": { "value": "", "unclear": false },
    "phone": { "value": "", "unclear": false },
    "email": { "value": "", "unclear": false },
    "nationality": { "value": "", "unclear": false }
  },
  "domestic_address": "yes | no | unknown",
  "companions": [{ "name": "", "unclear": false }],
  "evidence": [{ "field": "", "text": "", "confidence": 0 }]
}

1つ目の理由は、AIの仕事と点検の仕事を別の層に置けることです。 JSONはAIが埋め、必須の項目の点検は Apps Script が規則で行います。旅券番号は、このJSONとは別に Apps Script が名簿の下書きへ書きます。

2つ目の理由は、missing と not_detected を分けられることです。 Form Parser は空欄のキーと値の組を確実には読み取れないとされているので、キーが返ってこないことを空欄と決めつけません。 not_detected はフロントがカードの画像を見て、空欄か読み取りの漏れかを決めます。公式にも、構文として正しいJSONでも値はアプリケーションの側で検証するよう書かれています。

domestic_address が unknown のときは、国籍と旅券番号を必須として扱います。 印の漏れで外国人の宿泊者の旅券番号が抜けるほうを避けます。

システムへ連携する

記入漏れの一覧は、フロントの端末で開いたままにしておきます。 部屋番号と「住所なし」「国籍なし」のような不足の項目だけを出し、氏名や住所の値そのものは一覧に出しません。 カウンター越しに画面が見えても、ほかの宿泊者の情報が読めないようにします。

宿泊者への連絡は自動で送りません。 聞き直すのはフロントで、部屋への電話か、外出から戻ったときの声かけで行います。

人が確認する

人が見るのは、記入漏れの一覧と、complete 以外の行だけです。 complete のものは夜勤がまとめて確定の列に移します。全件を開く設計にすると、第10章の40.0時間には収まりません。

1. フロントが記入漏れの一覧を見る … missing と passport_copy_missing は、宿泊者が館内にいるうちに聞き直します
2. not_detected はカードの画像を見る … 本当に空欄なら聞き直し、書かれていれば値を下書きに入れます
3. unreadable を見る … 画像で確かめ、読めなければ宿泊者に聞きます。旅券の写しがあれば氏名と旅券番号は写しで確かめます
4. count_diff を見る … 同伴者の氏名が書かれていなければ聞き直します
5. 夜勤が確定する … 確かめ終えた行を名簿の確定の列に移します

1番目を夕方のうちに回すことが、この構成の目的です。 深夜に気づいても、宿泊者に聞ける時間はほとんど残っていません。

目標は、2,400件をならして1件1分です。 聞き直しや画像の確認が要るのは1割前後という想定で、それより多い月は、カードの版かスキャナーの設定に問題があります。

例外に対処する

2行目がいちばん大事な例外です。 空欄と決めつけて聞き直すと、きちんと書いた宿泊者に同じことを二度聞くことになります。

記録を残す

• 元のカードの PDF と、読み込んだ日時・部屋番号
• Document AI が返した Document のJSONの全文
• Gemini API に渡した伏せた後の読み取り結果と、返ってきたJSON
• Apps Script が付けた状態と、そのとき照らした到着予定の行
• フロントが聞き直した記録（いつ、どの項目を、誰が）と、確定した日時
• 旅券の写しのファイルとの対応

1つ目と2つ目は、名簿と同じく3年間の保存を前提に置き場所を決めます。 旅館業法施行規則では、名簿は作成の日から3年間保存するとされています。名簿の正本を PMS と表のどちらにするかを総務で決め、正本でないほうに古い控えを残さないようにします。