海外の旅行会社から届く英文のルーミングリストとバウチャーを読み取り、宿泊者名・部屋割り・食事・送迎を団体の予約データに転記して、手配書どうしの食い違いを営業へ返す

処理の起点を決める

団体フォルダ（Amazon S3）にファイルが保存されたことを起点にします。 フォルダは予約システムの団体の予約番号ごとに作り、担当者がメールの添付をそこへ保存します。保存のたびに、その団体の手配書をすべて読み直すのではなく、新しいファイルだけを読み、前の版と比べます。

ファイル名の版の書き方は当てにしません。 「Final」「Rev.2」と付け方がばらばらだからです。版の順番は保存の日時で決め、同じ日に2つ届いたときは手配書の作成日の欄で並べます。

もう1つの起点は、毎朝の定時実行です。 到着日の7日前・3日前・前日の団体について、食い違いが解消されていない団体と、ルーミングリストがまだ届いていない団体を一覧にして担当者へ送ります。催促を忘れる失敗は、書類が届かないあいだに起きるからです。

入力データを集める

質を決めるのは、いちばん下の表です。 「NAME」の1列に「LEE/MINHO MR」と書く書式もあれば、「Surname」「First name」「Title」を分ける書式もあります。同じ旅行会社なら書式はほぼ変わらないので、旅行会社ごとに1行ずつ対応を書いておけば、並べ直しの迷いが減ります。

旅券番号と生年月日の列は、読み取っても予約データへ入れません。 第1章のとおり、旅券の確認はチェックインのときにフロントが旅券そのもので行います。到着前の手配に要らない個人の情報を、予約データに広げないためです。

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

問いは、別名（Alias）を付けて登録します。 例えば How many twin rooms are booked? に TWIN_ROOMS、What is the meal plan? に MEAL_PLAN、How many free of charge rooms are included? に FOC_ROOMS を付けます。答えは QUERY_RESULT として信頼度つきで返り、答えが見つからないときは空で返ります。 空のまま後段に渡し、「書かれていない」として扱います。

問いの数には上限があります。 非同期の処理で1ページあたり30、同期で15です。バウチャーは1〜2ページのことが多いので、問いはバウチャーにだけかけ、ルーミングリストは表として読みます。

表の種類も見ます。 TABLE のブロックには、きちんと罫線のある表か、罫線の少ない表かを示す STRUCTURED_TABLE ／ SEMI_STRUCTURED_TABLE が付きます。罫線の少ない表は列のずれが起きやすいので、その団体は信頼度にかかわらず担当者の確認に回します。

予約システムの団体の枠は、毎朝書き出したファイルを読みます。 照合に要るのは部屋の種類ごとの数と泊数だけです。

AIへ渡す前に整形する

1. 形式の確認 … JPEG・PNG・PDF・TIFF であることを確かめます。XFA形式のPDFは扱えません。Excelのまま届いたものは、PDFに印刷して入れます
2. パスワードの確認 … パスワード付きのPDFは読めません。旅行会社に解除を頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 文字の大きさの確認 … 検出できる文字の高さは15ピクセル以上で、150dpiで8ポイントに当たります。40名を1枚に詰めた表は、この下限に近づきます
5. 言語の確認 … 本文が英文でないファイルは、読み取りに回さず担当者へ戻します
6. 書類の種類の判別 … 1つのPDFにルーミングリストとバウチャーと旅程表がまとまって届くことがあります。ページごとに種類を分けてから、表として読むか、問いをかけるかを決めます
7. 同じファイルの検知 … 中身が同じファイルが二度保存されたら、新しい版として扱いません

6番目を軽く見ないでください。 旅程表のページを表として読むと、日付と観光地の行を宿泊者の行と取り違えます。種類を先に決めてから読み方を選びます。

AIに処理させる

1回目にさせるのは、読み取った表の列を、予約データの項目へ並べ直すことです。

2回目にさせるのは、プログラムが出した差分と照合の結果を受けて、食い違いの説明と問い合わせの下書きを作ることです。 担当者向けの一覧（日本語）と、旅行会社への問い合わせ（英語）です。

1行目がいちばん起きやすい失敗です。 「JHON」を「JOHN」に直すのは親切に見えますが、旅券のつづりが JHON なら、直した名前のほうが誤りです。 読み取りの誤りか原本どおりかは、信頼度と原本の画像で人が見ます。

指示内容を固定する

あなたはホテルの団体予約の担当として、海外の旅行会社から届いた
英文のルーミングリストを予約データへそろえる立場です。
渡すのは AWS Textract が読み取った表（行・列・見出し・結合セル）と、
この旅行会社の列の対応表です。
読み取り結果に書かれていることだけを使ってください。推測で埋めないでください。

【1回目：予約データの項目への並べ直し】
- 表の行を部屋ごとにまとめてください。結合されたセルは1部屋として扱い、
  まとめ方が決まらない行は status を ambiguous にしてください。
- 名前は、列の対応表に従って surname / given_name / title に分けてください。
  分け方が決まらないときは、原文の文字列を raw_name にそのまま入れ、
  status を ambiguous にしてください。
- 名前のつづりを直さないでください。大文字・小文字も含めて、
  読み取った文字列のまま入れてください。カタカナにしないでください。
- 部屋の種類は、書かれた略号をそのまま room_type_raw に入れ、
  対応表の区分を room_type に入れてください。書かれていなければ
  not_stated とし、人数から推定しないでください。
- TL、TC、Tour Leader、Driver、FOC などの印は、書かれた文字列のまま
  staff_flag に入れてください。
- 備考の列にある食事の要望とアレルギーは、原文のまま remarks に写し、
  dietary にはその要望の区分だけを入れてください。
  書かれていない要望を足さないでください。
- 旅券番号・生年月日の列は出力に含めないでください。
- 信頼度は Textract が返した値をそのまま confidence に入れてください。

【2回目：食い違いの説明と問い合わせの下書き】
- 差分（{diff}）と照合の結果（{match_results}）だけを使ってください。
- 担当者向けの一覧は日本語で、項目ごとに「どの書類の、どの値と、
  どの値が合わないか」を書いてください。どちらが正しいかは書かないでください。
- 旅行会社への問い合わせは英語で、団体名と旅行会社の参照番号を書き、
  合わない値を並べて確認を求める文にしてください。
  ホテルの側で値を決めたような書き方をしないでください。

「つづりを直さない」を明記しないと、よくある名前に寄せて直します。 英語の名前として不自然なつづりほど直されやすく、それは旅券のつづりであることが少なくありません。 禁じるのは直すことそのものです。

出力形式を固定する

1回目の出力は、次の形のJSONで受け取ります。

{
  "group_ref": "",
  "doc_version_saved_at": "",
  "rooms": [
    {
      "row_no": 1,
      "room_type_raw": "TWN",
      "room_type": "twin | single | double | triple | not_stated",
      "guests": [
        {
          "surname": "",
          "given_name": "",
          "title": "",
          "raw_name": "",
          "staff_flag": "",
          "child": false,
          "confidence": 0
        }
      ],
      "remarks": "",
      "dietary": ["vegetarian | halal | allergy | other"],
      "status": "ok | ambiguous | low_confidence"
    }
  ],
  "arrival": { "flight": "", "time": "", "transfer": "yes | no | not_stated" }
}

1つ目の理由は、差分と照合をプログラムに渡せることです。 前の版の rooms と今回の rooms を、surname と given_name の組で突き合わせ、「追加」「取り消し」「部屋の移動」「部屋の種類の変更」の4つに分けます。数の照合は次の3つで、AIはどれにも関わりません。

2つ目は、dietary を手配表の列に直接つなげられることです。 区分ごとにレストランと調理の手配表へ行を出し、remarks の原文を必ず添えます。 区分だけを渡すと、「nut allergy」と「peanut allergy」の違いが手配表で消えます。

構造化出力では、スキーマのすべてのオブジェクトに additionalProperties: false を付けます。数値の範囲や文字列の長さの制約はスキーマで書けないため、信頼度の範囲や人数の形の確認はプログラムで行います。

システムへ連携する

StartDocumentAnalysis には、同じ依頼を二度動かさないための識別子（ClientRequestToken）を付けます。 同じ識別子なら同じ JobId が返ります。JobTag には団体の予約番号と書類の種類を入れ、完了の通知からどの団体の結果かをすぐ引けるようにします。結果の出力先のバケットと、暗号化の KMS の鍵も指定できます。

予約システムへは、担当者が承認するまで何も渡しません。 旅行会社へも、自動では何も送りません。

人が確認する

担当者が見るのは、差分、mismatch と over ／ under、ambiguous と low_confidence の行です。

1. 差分を先に見る … 追加・取り消し・移動の行を、改訂版の原本と並べて確かめます。取り消しの行は特に、本当に名前が消えているかを見ます
2. 数の食い違いを見る … 添乗員の部屋がどちらに数えられているかが、いちばん多い理由です。旅行会社に聞く前に、バウチャーの FOC の欄を見ます
3. 信頼度の低い名前を原本で見る … つづりは直さず、読み取りの誤りだけを直します
4. 食事の要望を原文で見る … remarks の原文と手配表の区分が合っているかを見ます
5. 承認して書き出す … 予約システムの取り込みと手配表への書き込みは、承認のあとに動きます
6. 問い合わせを直して送る … 送るのは人です

4番目を省かないでください。 アレルギーの見落としは、工数の話ではなく宿泊客の安全の話です。 区分が付いていても原文を読みます。

目標は、80件をならして1件12分です。 それより長くかかる月は、罫線の少ない書式が増えているか、列の対応表が古くなっています。

例外に対処する

上から3行目までは、受け取り方の問題です。 旅行会社に手書きの直しではなく版を作り直して送ってもらうほうが効きます。

記録を残す

• 受け取った手配書のPDFと、保存された日時（版の順番の根拠）
• Textract が返した読み取り結果の全文と JobId
• 1回目のJSON（部屋、宿泊者、要望の原文、信頼度）
• 差分と照合の結果、そのとき照らした予約システムの枠
• 担当者が直した行と、直す前の値
• 承認した日時と、予約システムへ取り込んだファイル
• 旅行会社へ問い合わせた日時と、回答が届いた日時
• 旅行会社ごとの、ambiguous と low_confidence の発生率

4つ目で「そのときの枠」を残すのは、営業が枠を後から動かすためです。 枠を足した後では過去の over が消え、経緯をたどれません。 旅券番号の列は読み取り結果の全文に残るため、出発後に消す期間を決めます。