客室係が手書きするミニバーの補充伝票を読み取って精算の明細にそろえ、チェックアウト前に未精算と記入漏れをフロントへ出す

処理の起点を決める

客室係が撮影した画像が共有フォルダに保存されたことを起点にします。 昼と夕方の2回にまとめると、出発日の朝に清掃が入った部屋の伝票が間に合いません。撮影されたら1枚ずつ動かします。

撮影はフロアのタブレットで行い、カメラのアプリから決まったフォルダへ保存する形にします。客室係のスマートフォンは使いません。 伝票には部屋番号が書かれており、個人の端末に残すと宿泊の記録が持ち出されることになるからです。

これとは別に、出発予定の時刻に合わせた定時の点検を毎朝7時・9時・10時半に動かします。こちらは伝票の到着を待たず、清掃が終わったのに伝票が届いていない部屋を探す処理です。届いたものを読むだけでは、届かなかったものは見つけられません。

処理が終わった画像は処理済みのフォルダへ移します。移すのは成功したときだけにします。 元のフォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、品目マスタの略称の列です。 客室係は「ビール」を「ビ」「BR」「生」と書き、「ミネラルウォーター」を「水」「ミネ」と書きます。略称の一覧が無いと、品目の名寄せをAIに推測させることになります。 推測させないために、書かれうる略称を先に集めてマスタに持たせます。

無料品かどうかの列も要ります。 客室にサービスで置く水やお茶を同じ伝票に書く施設では、補充の数は書かれても売上にはしません。 この列が無いと、無料の水が客室料金に乗ります。

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

読み取りは、ワークフローからレイアウトモデルを呼ぶだけです。伝票は1枚1ページなので、ページの指定は要りません。

部屋番号は、表の外に書かれることが多い項目です。 伝票の上の欄に書く決まりでも、急いでいると余白に書かれます。表からだけ取ると、部屋番号が見つからない伝票が増えます。 全文から拾い、部屋番号の一覧（PMSの客室マスタ）にある値かどうかで確かめます。

PMSからの書き出しは、朝の点検の前に1回、その後は1時間ごとに取り直します。連携の方式はPMSの製品によって違います。 帳票をCSVで書き出せるなら、それをフォルダに置いてワークフローで読む形が最も手堅い構成です。

AIへ渡す前に整形する

1. 形式と寸法の確認 … 画像は 50×50 から 10,000×10,000 ピクセルの間である必要があります。範囲外は撮り直します
2. 文字の大きさの確認 … 取り出せる文字の最小の高さは、1024×768 の画像で 12 ピクセルです。150dpi で約8ポイントに相当します。伝票を遠くから撮ると、数量の数字がこれを下回ります
3. 向きの確認 … 横向きや逆さまに撮られたものは、返ってくるページの角度で見分けて、回転させてから判定します
4. 1枚に1部屋の確認 … 2枚の伝票を重ねて撮ったものは、部屋番号が2つ見つかるので分けて撮り直します
5. 重複の検知 … 同じ部屋・同じ日付・同じ記入者の伝票が直前にあれば、撮り直しとして印を付けます
6. 清掃の記録との突き合わせ … 伝票の部屋番号が、当日清掃の終わった部屋に入っているかを見ます

2番目を軽く見ないでください。 客室係はワゴンの上で伝票を撮ります。伝票全体を収めようとして離れて撮ると、数字が小さくなりすぎます。 撮影の位置を決めた台紙を用意し、そこに置いて撮る運用にします。

AIに処理させる

させるのは、読み取り結果から部屋番号・品目ごとの数量・記入者・日付を取り出し、品目名を品目マスタの名前にそろえることだけです。

数量は、4つの区分のどれかで返させます。

blank と zero を分けるのが、この構成でいちばん大事な区別です。 zero は客室係が見て「無かった」と書いたもの、blank は書かれていないもので、数え忘れの可能性が残ります。 伝票の全部の数量欄が blank で、「補充なし」のチェックも無い伝票は、冷蔵庫を開けたかどうかが分かりません。 客室係へ確かめに回します。

unreadable の根拠は、OCRが返した信頼度に置きます。 数字が検出され信頼度が十分なら filled か zero、検出されていても信頼度が低ければ unreadable です。AIに「たぶん2」と読ませません。

4行目がいちばん起きやすい失敗です。 「酎」と書かれた行を、マスタに酎ハイが2種類あるのにどちらかへ寄せると、単価の違う品目で請求されます。 略称が1つの品目に決まらないときは unmatched にします。

指示内容を固定する

あなたはホテルの宿泊部の事務担当で、客室係が手書きした
冷蔵庫・ミニバーの補充伝票を、精算の明細にするための値に直す立場です。
OCRが返した読み取り結果だけを見て答えてください。推測で埋めないでください。

【取り出すもの】
1. 部屋番号（客室の一覧にある値だけ。無ければ空にして status を ambiguous）
2. 品目ごとの数量（伝票の表の行ごと）
3. 「補充なし」のチェック欄の状態
4. 記入者名と日付（書かれていなければ空）

【品目名のそろえ方】
- 伝票の品目名は、下の品目一覧の「正式名」か「略称」のどれかに
  完全に当たるときだけ、その品目コードにしてください。
- 当たる候補が2つ以上あるとき、どれにも当たらないときは、
  item_code を空にして match を unmatched にしてください。
  似ている品目に寄せないでください。

【数量の qty_status の選び方】
- filled ....... 1以上の数字が読み取れた
- zero ......... 0、または「－」「／」「なし」が書かれている
- blank ........ 何も書かれていない
- unreadable ... 文字はあるが、信頼度が低く数字として確定できない
迷ったときに filled を選ばないでください。

【厳守事項】
- 数量の数字が読めないとき、前後の行や他の部屋から補って埋めないでください。
- 「正」の字や線の本数で書かれた数量は、数え方が確定できるときだけ
  数字にし、そうでなければ unreadable にしてください。
- 空欄を 0 として扱わないでください。空欄は blank です。
- 単価、金額、税率は書かないでください。
- confidence には、OCRが返した信頼度をそのまま入れてください。
- evidence には、判定の根拠にした文字列をそのまま写してください。
- 補充伝票でない書類と判断した場合は、取り出しをせず document_type に種類を書いてください。

【読み取り結果】{layout_result}
【品目一覧（コード・正式名・略称）】{item_master}
【客室の一覧】{room_list}

「空欄を0として扱わない」を明記しないと、空欄は0になります。 何も書かれていない欄は、文章として読むと「消費なし」に見えるからです。空欄の意味を決めるのは「補充なし」のチェック欄と人の確認であって、AIではありません。

「似ている品目に寄せない」も同じ理由で書きます。 名寄せを任せると、AIはもっともらしい品目を選んで埋めます。埋めた品目が正しいかではなく、確かめるべき行が一覧から消えることが問題です。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、strict: true で、すべての項目を required にし、additionalProperties を false にしたスキーマを渡します。

{
  "slip_id": "",
  "document_type": "minibar_slip",
  "room_no": "",
  "room_status": "ok | ambiguous",
  "no_refill_checked": "selected | unselected | unreadable",
  "staff_name": "",
  "slip_date": "",
  "lines": [
    { "written_name": "", "item_code": "", "match": "matched | unmatched",
      "qty": 0, "qty_status": "filled | zero | blank | unreadable",
      "confidence": 0, "evidence": "" }
  ]
}

1つ目の理由は、AIの出力と売上の判定を別の層に置けることです。 lines はAIが埋め、そこから明細を作るかどうかは Azure Functions の規則で決めます。単価や品目が変わっても、直すのはマスタと規則だけです。

2つ目は、構造化出力のスキーマにすべての項目を必須で並べることで、取り出せなかった項目が「抜ける」のではなく「空として残る」ことです。 公式の説明でも、すべての項目を required にし、任意の項目は null との組み合わせで表すとされています。抜けた項目は気づけませんが、空の項目は数えられます。

Azure Functions は、この出力に品目マスタとPMSの書き出しを合わせて、次の形の明細の案を作ります。

システムへ連携する

PMSへは書き込みません。 この構成が出すのは計上の案までで、売上を確定させるのは人の操作です。 誤った明細が自動で計上されると、客の目の前で精算額が違うという形で表に出ます。

フロントへの通知は、出発予定の時刻順に並べます。 部屋番号順に並べると、10分後に出発する部屋が一覧の下に埋もれます。

人が確認する

人が開くのは needs_human の伝票と、伝票の届いていない部屋だけです。 ready のものは明細の一覧で件数と部屋を流し見て計上します。

1. 出発の近い部屋から見る … 一覧は出発予定の時刻順です。出発後に回したものは、ほぼ回収できないからです
2. unreadable と unmatched は画像を開いて読む … 読めなければ、記入者に内線で聞きます
3. 全欄 blank の伝票は客室係に確かめる … 冷蔵庫を開けたかどうかを聞きます
4. 伝票の届いていない部屋は、清掃の担当に聞く … 出発の近い部屋はフロントにも伝え、客に自己申告をお願いするかを決めます
5. 判定を直したら記録する … どの欄を、何に直したかを残します

3番目を省かないでください。 全欄が空の伝票を「消費なし」として通すと、数え忘れが売上の漏れとして確定します。

目標は、2,400枚をならして1枚1分です。 開くのは1割前後という想定で、それより多い月は、撮り方か伝票の様式に原因があります。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、撮り方と伝票の様式の問題です。 直すほうが、読み取りの精度を上げるより効きます。

記録を残す

• 伝票の画像と、撮影した日時・タブレット・フロア
• OCRが返したJSONの全文と、生成AIが返したJSON
• 明細の案（verdict、reason）と、そのとき参照した品目マスタの版
• 人が判定を直した記録 … どの欄を、何から何に直したか
• PMSに計上した日時と、計上した担当
• 記入者ごとの unreadable と全欄 blank の件数

品目マスタの版を残すのは、価格と品目が入れ替わるためです。 季節で品目を替えたあとに過去の精算を見直すと、当時の単価が分からなくなります。

最後の行は、客室係への声かけの材料になります。 特定の記入者で unreadable が続くなら、数字の書き方を一度そろえれば片づきます。評価に使うのではなく、伝票の様式と書き方を直すために使います。