飲食店の紙の予約台帳に手書きした予約を読み取って予約のデータにそろえ、重複と席数の超過と連絡先の書き漏れを拾う

処理の起点を決める

共有フォルダに台帳の写真が保存されたことを起点にします。 撮るのは1日2回、昼の営業が終わった時と、閉店した時です。撮るたびに、Python のプログラムが1分おきにフォルダを見て、新しい写真を処理します。

撮るのは、その回に書き足したページだけです。台帳をめくりながら、書き足したページの角に付箋を貼っておき、撮影のときに付箋のページだけを撮ります。撮り終えたら付箋をはがします。全ページを毎回撮ると、照合の手間が増えるだけで得るものがありません。

写真の名前は、タブレットの撮影アプリで「店番号_予約日」を選んでから撮る形にします。予約日をページの見出しから読ませないのは、見出しの日付が手書きのことが多いからです。 日付を読み違えると、その日の予約が丸ごと別の日に入ります。処理が終わった写真は処理済みのフォルダへ移します。移すのは成功したときだけにし、元のフォルダに残った数が未処理の数になるようにします。

入力データを集める

質を決めるのは、店の席の情報です。 「18時台に何名まで入れるか」が決まっていないと、超過は判定できません。席数をそのまま上限にすると、テーブルの組み合わせで入らない人数を見落とします。 4名席が5つある店に3名の予約が5組入れば、人数は15名でも席は埋まっています。上限は人数と組数の両方で持ちます。

担当の一覧を渡すのは、台帳の「受付」の欄に略称や名字の1文字しか書かれないからです。 「ヤ」「山」「山田」が同じ人だと分からないと、電話番号の書き忘れを誰に聞けばよいかが決まりません。

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

読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。オンラインの処理は1回の要求で最大15ページで、台帳の写真は1ページずつ送るので上限に届きません。

表の見出しの行で、列の意味を決めます。 headerRows のセルに「時間」「お名前」「人数」「電話」「ご要望」「受付」と書かれていれば、その列番号を覚えておき、bodyRows の各セルを列の意味で読みます。見出しの文字は印刷なので、手書きの欄より読み取りが安定します。

ネット予約は、毎朝と夕方にグルメサイトの管理画面から書き出した一覧を使います。書き出しの方法はサイトごとに違うため、この部分は利用環境に応じた個別実装になります。 書き出しのAPIがあるサイトもあれば、管理画面から一覧をダウンロードするしかないサイトもあります。

AIへ渡す前に整形する

1. 台帳の様式を作り直す … 時間・お名前・人数・電話・ご要望・受付の6列の罫線を印刷した様式にします。セルを結合した欄を作りません
2. 書き方を決める … 1件は1行に書き、要望が長いときは隣の欄にはみ出さず、ページ下の「メモ」欄に行番号を付けて書きます
3. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。タブレットの写真は JPEG で保存し、撮影後に圧縮し直さない設定にします
4. 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。写真では、ページの4隅が画面いっぱいに入る距離で撮ります
5. 向きと傾きの確認 … 横向きの写真は回転させ、4隅が写っていない写真は撮り直しに回します
6. 見開きの片側を切る … 見開きで撮った写真は、写真の名前の日付のページだけを残します
7. 重複の確認 … 同じ店・同じ予約日の写真が同じ回に2枚あれば、新しいほうを使います

1番目と2番目を省くと、この構成は動きません。 公式の説明では、Form Parser の表の抽出は行や列をまたぐセルの無い表だけを認識します。いまの台帳に「18時」を2行分の大きな文字で書く習慣があれば、その2行は表として読まれません。様式を作り直すのは、AIのためというより、表として読める紙にするためです。

4番目は、撮影の手順として最初に決めます。 レジ横の暗い場所で急いで撮ると、影が入り、ページが傾きます。読み取りの信頼度が低い写真の多くは、撮り方の問題です。

AIに処理させる

させるのは、表の1行を1件の予約の形にそろえることだけです。 行ごとのセルの文字を受け取り、時間・名前・人数・電話番号・要望・受けた担当の6つに直して返させます。重複と超過の判定はさせません。

右端の列が、この構成でいちばん大事な区別です。 電話番号の blank は受けた人が書かなかったということ、unreadable は文字はあるが確定できないということです。前者は受けた担当に聞くもの、後者は台帳を見直せば済むものです。

分ける材料は、セルの信頼度と、セルに文字が検出されたかどうかです。 公式のページでは、Form Parser は値の入っていないキーと値の組を確実には読み取れないとされています。空欄の判定を、キーと値のペアに頼らず、表のセルに文字が検出されたかどうかで行うのはこのためです。

いちばん起きやすい失敗は、電話番号の補完です。 「090-12-5678」のように桁が足りない番号を渡すと、それらしい11桁に直して返すことがあります。直された番号は、客にかけてもつながりません。 桁が足りないこと自体が、受けた担当に聞くべき合図です。

指示内容を固定する

あなたは飲食店の予約係の補助として、紙の予約台帳の1ページを
予約の一覧に写す立場です。OCRが返した表のセルだけを見て、
1行を1件の予約の形にそろえてください。推測で埋めないでください。

【列の意味】
time（時間）／name（お名前）／party（人数）／phone（電話）／
request（ご要望）／staff（受付）

【そろえ方】
- time は 24時間表記の HH:MM にしてください。「6時半」のように
  午前か午後か決まらない書き方は、店の営業時間の内側で解釈し、
  それでも決まらなければ time_status を ambiguous にしてください。
- name は書かれた名前をカタカナにそろえ、「様」「さん」を外してください。
  漢字が書かれていても、読みが一つに決まらないときは原文のまま
  name_raw に入れ、name_kana を空にしてください。
- party は大人と子どもに分けてください。分けられなければ total だけ入れます。
- phone は数字とハイフンだけを写してください。
- request は allergy／celebration／child_seat／private_room／course／other
  のどれかに分け、原文を request_raw にそのまま残してください。

【厳守事項】
- 電話番号の桁を補わないでください。足りなくても、読めたとおりに写してください。
- 空欄のセルは値を書かずに status を blank にしてください。
- 文字はあるが読めないセルは「（判読不能）」とし、status を unreadable にしてください。
  空欄と読めないセルを混ぜないでください。
- 名前に漢字を当てないでください。
- アレルギーの記載を広げたり、言い換えたりしないでください。
  「えびNG」は「えびNG」のまま request_raw に写してください。
- 二重の予約かどうか、受けてよい予約かどうかを書かないでください。
- 取り消し線が引かれた行は、cancelled を true にしてください。
  消された内容を読み取ろうとしないでください。
- ページ下のメモ欄の「3行目：…」のような書き足しは、その行の
  request_raw に足してください。

【店の営業時間】{business_hours}
【担当の一覧】{staff_list}
【表のセル（行ごと・列ごと、信頼度つき）】{table_cells}

「取り消し線の行」を指示に入れているのは、台帳の取消がたいてい線で消すだけだからです。 何も言わなければ、消された予約もそのまま1件として返ります。取消の印を付けさせ、予約一覧の側で、すでに入っている同じ行を取消に変えます。

「午前か午後か」を店の営業時間で決めさせるのは、台帳の「6時」がほぼ18時だからです。 ただしランチ営業のある店では、「11時半」と「1時」のどちらも昼です。営業時間を渡し、それでも決まらないものだけを ambiguous にします。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に JSON スキーマを渡す方式）を使い、形を固定します。

{
  "store_id": "",
  "reservation_date": "",
  "rows": [
    {
      "row_no": 0,
      "time": "", "time_status": "ok | ambiguous | blank | unreadable",
      "name_kana": "", "name_raw": "",
      "party": { "adult": 0, "child": 0, "total": 0 },
      "phone": "", "phone_status": "ok | blank | unreadable",
      "request_type": ["allergy | celebration | child_seat | private_room | course | other"],
      "request_raw": "",
      "staff": "",
      "cancelled": false,
      "min_confidence": 0
    }
  ]
}

1つ目の理由は、照合をプログラムの規則で行えることです。 前回までに取り込んだ行と、予約日・時間・名前のカナ・電話番号の4つで突き合わせます。4つとも一致すれば同じ行、時間か人数だけが違えば「書き直された行」として確認の一覧に出します。

2つ目は、確認の一覧に出す条件を、AIでなくプログラムが決められることです。

3つ目は、request_type で厨房への連絡をそのまま並べ替えられることです。 allergy と course だけを予約日の順に並べれば、厨房向けの連絡票になります。原文の request_raw を必ず添えて出します。 分類が外れていても、原文を読めば分かります。

システムへ連携する

予約一覧には足すだけで、消しません。 取り消し線の行も、一覧の行を消すのではなく「取消」の印を付けます。消すのは店長が確かめてからです。 プログラムが消した予約は、誤っていたときに戻す手がかりが残りません。

グルメサイトの側には書き込みません。 二重の予約が見つかっても、ネットの予約を取り消すのは客に確かめてからです。この構成が出すのは、確かめるべき予約の一覧までです。

人が確認する

店長が開くのは確認の一覧だけです。 一覧の各行から、台帳の写真の該当の行に枠を付けて開けるようにしておきます。写真と一覧を並べ、読み取りの結果が台帳のとおりかを見ます。

1. 電話番号の blank を先に片づける … 受けた担当がまだ店にいるうちに聞きます。昼の撮影の分は夕方の営業前に、閉店の分はその場で
2. 二重の予約の疑いを見る … 同じ客かどうかを確かめ、同じなら客に電話して、どちらを残すかを聞きます
3. 席数の超過を見る … テーブルの組み合わせで入るなら、そのまま通します
4. 時間と信頼度の低い行を見る … 写真で確かめて直します
5. 直したら記録する … どの項目を何から何に変えたかを残します

1番目を急ぐのは、（d）で書いたとおり、時間がたつと受けた担当も覚えていないからです。 一覧に出たその日のうちに聞けば、たいていは「メモ用紙に書いた」と出てきます。

目標は、900件をならして1件1分です。 確認の一覧に出るのは2割前後という想定で、それより多い月は、撮り方が崩れているか、様式からはみ出して書く担当がいます。

例外に対処する

上から2行目までが、運用の最初の1か月にいちばん多く出ます。 どれもAIの問題ではなく、台帳の書き方の問題です。 担当ごとに件数を数え、多い担当にだけ書き方を伝え直します。

記録を残す

• 台帳の写真と、店番号・予約日・撮影日時
• OCRが返したJSONの全文（表のセル、全文、信頼度）
• AIが返した行ごとの予約と、そのとき照合した取り込み済みの行とネット予約の一覧
• 確認の一覧に出した理由と、店長が直した記録（項目、変更前、変更後）
• 電話番号を受けた担当に聞いた日時と、聞けたかどうか
• 担当ごとの、様式からはみ出した行と blank の件数

3つ目で「照合した一覧」を残すのは、二重の予約の疑いを後から説明するためです。 同じ客の2件のうち、どちらを残したかで揉めたとき、その時点でどちらが先に入っていたかを示せます。