旅館に届く手書きの食事・アレルギーの要望票を読み取り、料理長と配膳係が見る献立の変更指示表に起こす

処理の起点を決める

スキャンした画像が保管場所に保存されたことを起点にします。 郵送とFAXで届いた要望票は、届いたその日にスキャンします。到着時に書かれたものは、フロントで受け取ったらすぐにスキャンします。 当日の夕食に間に合わせるには、その時点で下書きが要るからです。

ファイル名は予約番号にします。 予約番号があれば、宿泊日・部屋・人数をPMSの書き出しから引けます。予約番号が分からない要望票は、代表者の氏名と到着日で引いた候補を出し、人が決めます。

毎日15時に、翌日の到着分で要望票が未着の予約を一覧にします。 要望票が返ってこなかった予約は、到着時に書いてもらう対象です。未着の一覧は、フロントの到着時の声かけの手元資料になります。

入力データを集める

質を決めるのは、原材料の表です。 料理ごとに、主な食材だけでなく、だし（かつお・昆布・えび）、つなぎ（卵・小麦）、調味料（しょうゆの小麦・大豆）、揚げ油の共用まで書かれているかどうかで、照合の結果が変わります。表に書かれていないものは、照合では「入っていない」になります。 だから、表の書き方を料理長と最初に決めます。

食材の語彙の土台には、食物アレルギーの表示の区分を使います。 京都府の案内では、表示が義務づけられた「特定原材料」は、えび、カシューナッツ、かに、くるみ、小麦、そば、卵、乳、落花生の9品目、表示が推奨される「特定原材料に準ずるもの」は、アーモンド、あわび、いか、いくら、オレンジ、キウイフルーツ、牛肉、ごま、さけ、さば、大豆、鶏肉、バナナ、ピスタチオ、豚肉、マカダミアナッツ、もも、やまいも、りんご、ゼラチンの20品目とされています（令和8年4月にカシューナッツが特定原材料に追加）。これは食品を購入する場面のための表示の決まりで、旅館の料理の範囲をそのまま決めるものではありません。 要望票の選択肢と語彙の出発点として使い、館の事情で食材を足します。

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

要望票は、レイアウトモデルを呼んで読みます。 取るものは次のとおりです。

チェック欄と食材の対応は、要望票の様式で固定です。 様式を変えない限り、何番目のチェック欄がどの食材かは決まっています。選択マークの位置を、様式の座標の一覧と照らして食材に結び付けます。 これを生成AIに推測させません。

予約の情報は、毎朝と15時にPMSから書き出したものを読みます。 献立と原材料の表は、月替わりの献立が決まった時点で厨房から受け取り、宿泊日ごとにどの献立を使うかを持っておきます。

AIへ渡す前に整形する

1. 寸法と向きの確認 … 画像は50×50ピクセルから10,000×10,000ピクセルの間であることが必要です。FAXの画像は向きを直します
2. 文字の大きさの確認 … 抽出できる文字の最小の高さは、1024×768の画像で12ピクセル（150dpiで約8ポイント）です。FAXで届いた要望票は解像度が低く、小さな手書きが下限に近くなります
3. 様式の確認 … 印字された見出しの文字で、館の様式の要望票かを確かめます。旧様式や、宿泊客が別の紙に書いて同封したものは needs_human にします
4. 予約の引き当て … ファイル名の予約番号でPMSの書き出しを引き、宿泊日・部屋・人数を付けます
5. 献立の引き当て … 宿泊日から、その日の夕食と朝食の献立と原材料の表を付けます
6. チェック欄の座標の照合 … 選択マークの位置を様式の座標の一覧に当て、食材の名前を付けます

2番目は、FAXの要望票で効いてきます。 小さな手書きが読めないとき、それは「書かれていない」のではなく「読めない」です。 読めない欄は空欄として扱わず、unreadable として人に回します。

AIに処理させる

させるのは、要望票の読み取り結果を、人ごとの要望の一覧にそろえることです。 献立と照らすこと、料理を出してよいかを判断すること、代わりの料理を決めることはさせません。

「程度の言葉を原文のまま」が、この構成のいちばん大事な指示です。 程度の言葉は、語彙にそろえると意味が変わります。「少量なら大丈夫」を「軽度」とまとめると、料理長は「軽度」の意味を宿泊客に確かめ直すことになります。 原文のまま横に置けば、料理長がそのまま読めます。

対象の食事を、書かれていなければ「すべての食事」にするのは、安全側に倒すためです。 夕食だけと書かれていなければ、朝食も対象にします。

4行目が、いちばん判断が分かれるところです。 「魚介類」と書かれた要望票は、えび・かに・いか・貝・魚卵をすべて避けるのか、魚だけなのかが分かりません。AIに広げさせると、広げすぎても狭めすぎても誤りになります。 「魚介類」のまま ambiguous にし、宿泊客に確かめる項目として出します。

指示内容を固定する

あなたは旅館の予約課で、宿泊客が手書きした食事・アレルギーの要望票を
人ごとの要望の一覧にそろえる立場です。
OCRが返した読み取り結果だけを使ってください。推測で埋めないでください。

【書く項目（人ごと）】
- person ........... 要望票に書かれた名前や続柄（「長男」「父」など）
- allergens ........ チェック欄で selected の食材と、自由記述に書かれた食材。
                     自由記述の食材は【食材の語彙】から選ぶ。無ければ other と原文
- degree_words ..... 程度やどこまで避けるかの言葉。原文のまま写す
- severity_quotes .. アナフィラキシー、エピペン、救急、入院などの言葉。原文のまま写す
- meals ............ 対象の食事（dinner／breakfast）。書かれていなければ両方
- dislikes ......... 苦手な食材（アレルギーではないもの）
- other_requests ... 宗教上の理由、菜食、子どもの食事、記念日など

【status の選び方】
- ok ......... 読み取れており、食材の語彙に当てはまる
- unreadable . 文字は検出されているが信頼度が低く、確定できない
- ambiguous .. 食材の範囲が広く、どこまでを避けるか書かれていない（「魚介類」など）
迷ったときに ok を選ばないでください。

【厳守事項】
- 料理にその食材が入っているかを判断しないでください。献立のことは書かないでください。
- 料理を出してよいか、代わりの料理を何にするかを書かないでください。
- 程度の言葉を要約したり、「軽度」「重度」などに言い換えたりしないでください。
- 重さを評価しないでください。severity_quotes に言葉を写すだけにしてください。
- 「甲殻類」「魚介類」「ナッツ類」のような広い言葉を、個別の食材に広げないでください。
  そのまま other に原文を入れ、status を ambiguous にしてください。
- 似た字（いか／いくら、卵／卯など）で迷ったときは、どちらかに決めず unreadable にしてください。
- チェック欄が unselected の食材を、自由記述から selected にしないでください。
  自由記述に書かれた食材は、別に allergens に足してください。
- アレルギーと苦手な食材を混ぜないでください。要望票の欄に従って分けてください。

【食材の語彙】{allergen_vocab}
【チェック欄（座標で食材を付けたもの）】{checkboxes}
【手書きの文字（行ごと、信頼度つき）】{handwritten_lines}
【予約の人数】{party_size}

「似た字で迷ったら決めない」を書くのは、読み違いがいちばん危ないからです。 「いか」と「いくら」は、手書きでは1字の差です。AIは文脈からもっともらしいほうを選びますが、もっともらしさは安全の根拠になりません。 unreadable にして人が紙を見れば、数秒で決まります。

「広い言葉を広げない」を書くのは、広げると親切に見えるからです。 「甲殻類」をえびとかにに広げた一覧は、一見よくできています。ただし宿泊客の言う「甲殻類」に、ほかのものが含まれるかどうかは、聞かないと分かりません。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力（response_format に json_schema を strict: true で渡す方式）を使い、形を固定します。

{
  "reservation_no": "",
  "form_type": "meal_request",
  "persons": [
    {
      "person": "",
      "allergens": [ { "item": "", "source": "checkbox | free_text", "status": "ok", "raw": "" } ],
      "degree_words": [""],
      "severity_quotes": [""],
      "meals": ["dinner", "breakfast"],
      "dislikes": [""],
      "other_requests": [""]
    }
  ],
  "unreadable_lines": [ { "text": "", "confidence": 0 } ]
}

このあとに、ワークフローが献立との照合を足します。

1つ目の理由は、読み取りと照合を別の層に置けることです。 献立が月替わりで変わっても、要望の一覧はそのままで照合だけをやり直せます。到着の前日に献立の一部が差し替わったときも、照合を回し直すだけで済みます。

2つ目は、ingredient_hits で料理長の確認が速くなることです。 「八寸：えび（だし）」のように、どの原材料で当たったかが分かれば、料理長はその料理のどこを差し替えればよいかがすぐに分かります。

システムへ連携する

PMSには書き込みません。 備考欄に入れる文の案を出し、予約の担当が入力します。原材料の表にも書き込みません。 表の更新は厨房が行います。

人が確認する

人が全件を確かめます。 確かめるのは2段階です。

1. 予約の担当が、要望票の画像と下書きを並べて確かめる … チェック欄の状態、食材の名前、程度の言葉が画像と合っているかを見ます。unreadable と ambiguous を先に見ます
2. 確かめる事項を宿泊客に聞く … to_confirm の項目について、到着前なら電話、到着後ならフロントで聞きます
3. 料理長が変更指示表を確かめ、代わりの料理を決める … affected_dishes と ingredient_hits を見て、差し替える料理と、出せないものを決めます
4. 確定した版だけを配る … 料理長が確定したものを、配膳係の画面と印刷用に出します

1番目で、チェック欄の空欄を見落とさないでください。 選択マークの信頼度が低いチェック欄は、薄い鉛筆の印か、消しゴムで消した跡のことがあります。どちらなのかは、紙を見ないと分かりません。

目標は、480件をならして1件3分です。 要望の無い要望票（「特になし」にチェック）は数十秒で終わり、複数人の要望が書かれた要望票に時間を使います。

例外に対処する

上から6行目が、最初の数か月でいちばん出ます。 月替わりの献立のたびに新しい料理が入り、原材料の表が追いつかないからです。照合できない料理を「当たりなし」と表示しないことが大事です。 当たりなしと照合できないは、別の結果です。

記録を残す

• 要望票の画像と、受け取った経路・日時
• 読み取りサービスが返した JSON と、Azure OpenAI に渡した入力と返ってきた JSON
• 照合の結果（affected_dishes、ingredient_hits、to_confirm）と、そのとき使った献立と原材料の表の版
• 宿泊客に確かめた内容と、確かめた人・日時
• 料理長が確定した変更指示表と、確定した時刻
• 人が下書きを直した記録

3つ目で原材料の表の版を残すのは、表が月の途中でも直るからです。 後から「この料理にえびのだしが入っていた」と分かったとき、どの宿泊客の照合がその版で行われたかを引けるようにします。