海外の旅行会社から届く英文の宿泊バウチャーを読み取り、予約番号・宿泊者・泊数・食事条件・支払区分を予約システムと突き合わせて、食い違いをフロントへ回す

処理の起点を決める

受付フォルダ（Amazon S3）にバウチャーが保存されたことを起点にします。 予約課の共有メールボックスに、旅行会社のドメインから届いたメールの添付を受付フォルダへ保存する仕組みを置きます。保存の通知で AWS Lambda が動きます。

届いた時点で1件ずつ処理します。 バウチャーは予約の確定後に届くので、到着の数日前に食い違いが分かれば、旅行会社に問い合わせる時間が残ります。 前日にまとめて処理すると、旅行会社の営業時間が終わっていて問い合わせが間に合いません。

もう1つの起点は、毎朝の定時の処理です。 翌日に到着する予約のうち、バウチャーが紐付いていないものと、食い違いが解けていないものを一覧にしてフロントへ回します。催促の作業が、前日の夕方から当日の朝へ移ります。

入力データを集める

質を決めるのは、対応表です。 同じ HB でも、旅行会社によって朝夕食か朝昼食かが違うことがあります。対応表に無い略語や言い回しは unclear にして人に見せ、確かめたら表に足します。

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

読み取りは AnalyzeDocument に S3 の場所（Document の S3Object）と FeatureTypes を渡します。同期の処理なので、応答にそのまま結果のブロックが入っています。

HumanLoopConfig を指定しないのは、人の確認を AWS の外の仕組みで行うためです。 公式のAPIの説明でも、この設定が使う Amazon Augmented AI は2026年7月に保守の段階に入り新規の利用者を受け付けていない、とされています。食い違いの一覧は、予約課の画面に出します。

質問の答えが見つからなければ空のまま返ります。 支払区分の答えが空なら、全文から prepaid、bill to、direct を含む行を探し、それでも無ければ missing にします。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。HTMLのメール本文だけで届いたバウチャーはPDFにします
2. ページ数とサイズの確認 … 1ページ・10MBに収まれば同期、収まらなければ非同期に回します
3. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。旅行会社に保護の無いものを頼みます
4. 解像度の確認 … 文字の高さは最小15ピクセルで、150 DPIで8ポイントの文字に相当します。客がスマートフォンで見せた画面の写真は、ここで下回ることがあります
5. 旅行会社の特定 … 送信元のメールアドレスから旅行会社を引き、対応表を選びます
6. 重複の確認 … 同じ予約番号のバウチャーが既に紐付いていれば、新しい版として扱います

4番目に当たったものは、読み取りを試さずに旅行会社へPDFを頼みます。 画面を撮った写真は文字が小さく、読めた部分だけで比べると、読めなかった項目の食い違いを見落とします。

6番目は、旅行会社が変更のたびにバウチャーを出し直すために要ります。 泊数の変更や同行者の追加で、同じ予約に2枚目、3枚目が届きます。最新の版で比べ、前の版との差も一覧に出します。

AIに処理させる

させるのは、読み取り結果を予約システムの項目にそろえ、食事条件と支払区分の原文を抜き出すことです。 比較と判定はさせません。

支払区分は、宿泊代と追加料金を分けて持ちます。 Room and breakfast prepaid. Extras paid direct. なら、宿泊代は旅行会社、追加料金は客です。1つの値にまとめると、どちらの請求で食い違ったのかが分かりません。

日付は、月の名前が書かれている（12 Nov 2026）か、年・月・日の順の数字か、日か月の一方が13以上のときだけ解釈します。 バウチャーは到着日と出発日の2つが並ぶので、泊数と照らせば順序が決まることも多いのですが、その推論はプログラムの側で行います。

3行目がいちばん起きやすい失敗です。 支払区分が書かれていないバウチャーを渡すと、旅行会社経由という文脈から Prepaid と書きます。書かれていないことは「書かれていない」として、旅行会社に問い合わせる項目にします。

指示内容を固定する

あなたはホテルの予約課で、海外の旅行会社から届いた英文の宿泊バウチャーを
予約システムの項目にそろえる担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
references（agent_ref、wholesaler_ref、hotel_conf）、guests、
check_in、check_out、nights、rooms（room_type、count、adults、children）、
meal_plan、payment（room_raw、extras_raw）、issue_date。
各項目に raw（読んだ文字列そのまま）、status、source を入れてください。

【status の選び方】
- ok ......... 値が読み取れ、その項目として解釈できる
- missing .... 書かれていない。質問の答えが空の場合も missing
- ambiguous .. 読み方が複数ある
- unreadable . 文字は検出されているが信頼度が低い
迷ったときに ok を選ばないでください。

【予約番号の扱い】
- 3種類の番号を区別できるときだけ、それぞれに入れてください。
- 区別がつかない番号は reference_unknown に入れてください。

【食事条件と支払区分の扱い】
- meal_plan は略語を読み替えず、raw に原文を入れてください。
  書類の中に略語の定義があれば definition_raw に写してください。
- payment は宿泊代（room_raw）と追加料金（extras_raw）を分け、原文の文を写してください。
- 支払区分が書かれていなければ missing にしてください。
  旅行会社経由であることから前払いと推測しないでください。

【日付の扱い】
- raw に原文を入れ、月の名前がある、年・月・日の順である、日または月の
  一方が13以上である、のどれかのときだけ value に YYYY-MM-DD を入れてください。

【厳守事項】
- 予約システムと合っているか、請求をどうするかを書かないでください。
- 宿泊者の名前の綴りを直さないでください。
- バウチャーでない書類と判断した場合は document_type を other としてください。
- inquiry_draft には、missing と ambiguous の項目について旅行会社に確かめる
  英文の文案を、簡潔に書いてください。

【読み取り結果】{textract_result}
【旅行会社】{agent_name}

「旅行会社経由であることから前払いと推測しない」を明記しないと、推測します。 実際に前払いの予約が多いので、推測はたいてい当たります。外れた1件が、チェックアウトで客に請求しそこねる1件です。

出力形式を固定する

Claude API の構造化出力（output_config.format に json_schema を指定）で、次の形のJSONを受け取ります。

{
  "file": "",
  "agent": "",
  "references": { "agent_ref": "", "wholesaler_ref": "", "hotel_conf": "", "reference_unknown": [] },
  "guests": [ { "raw": "", "status": "" } ],
  "check_in": { "raw": "", "value": "", "status": "" },
  "check_out": { "raw": "", "value": "", "status": "" },
  "rooms": [ { "room_type_raw": "", "count": 0, "adults": 0, "children": 0 } ],
  "meal_plan": { "raw": "HB", "definition_raw": "", "status": "" },
  "payment": { "room_raw": "", "extras_raw": "", "status": "" },
  "inquiry_draft": ""
}

1つ目の理由は、比較をプログラムの側に置けることです。 Python が予約番号3種と名前で予約を探し、項目ごとに次の印を付けます。

2つ目は、支払区分を宿泊代と追加料金に分けて比べられることです。 予約システムの支払区分も2つに分かれていれば、どちらで食い違ったのかがフロントにそのまま伝わります。

3つ目は、inquiry_draft で問い合わせが速くなることです。 旅行会社への問い合わせは英文で、項目が決まっています。下書きを直して送るだけになります。

システムへ連携する

予約システムへの書き込みは、バウチャーの紐付けと確認の印だけです。 日程や支払区分の値は書き換えません。食い違いを直すのは職員で、旅行会社に確かめてからです。

予約システムにAPIが無い場合は、毎朝の予約の出力ファイルで代えます。 到着予定の予約を出力し、受付フォルダの隣に置いて Python が読みます。その日のうちに入った予約とは照らせないので、not_found は翌朝にもう一度比べ直します。

人が確認する

予約課の職員が開くのは、mismatch、unclear、not_found の予約です。 match の予約は、紐付いたことを一覧で確かめるだけにします。

1. 支払区分の mismatch を先に見る … 画像で原文を確かめ、契約条件の一覧と照らします
2. not_found を片付ける … 予約の登録漏れか、別のホテル宛てのバウチャーかを確かめます
3. unclear を対応表に足すか決める … 新しい略語や言い回しは、確かめてから表に足します
4. 旅行会社に問い合わせる … 下書きを直して送ります。送信は職員が行います

フロントは、到着前日の一覧を見てチェックインに臨みます。 支払区分に食い違いが残っている客には、チェックインの時点で「宿泊代は旅行会社にお支払い済みですか」と確かめることができ、チェックアウトの場で揉めずに済みます。

match の予約を開かない設計を、条件付きの確認にしている理由はここにあります。 全項目が一致したものまで開くと、5分が2分になりません。ただし毎月、match の予約から20件を抜き出して画像と見比べ、比較の規則に漏れがないかを確かめます。

例外に対処する

下から3行目は、思ったより起きます。 系列のホテルや近隣の同じ名前のホテルのバウチャーが、間違って届くことがあります。not_found を放置せず旅行会社に知らせると、到着した客が別のホテルに予約していた、という場面を前もって防げます。

記録を残す

• 元のバウチャーと、受け取った日時、送信元、旅行会社
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSONと、Python の比較の結果
• そのとき使った対応表の版
• 職員が印を覆した記録 … どの項目を、どちらに変えたか
• 旅行会社への問い合わせと回答、予約の修正の記録

対応表の版を残すのは、旅行会社の略語が変わることがあるためです。 契約の更新で食事プランの名前が変わると、過去の判定の意味が変わります。