英文の団体宿泊契約書を読み取り、室数・料金・減室（アトリション）の条件・取消の期限を予約台帳に転記して、期限の前に営業担当へ知らせる

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 契約書は旅行会社の都合で不定期に届き、改定版は到着の直前にも届くため、1日1回の定時実行にはしません。 到着の数週間前に届いた改定版で室数が減っていれば、その日のうちに返却の判断をしたいからです。

保存するのは営業担当で、ファイル名の先頭に団体番号を付けます。 団体番号が無いファイルは、照合の相手を決められないので処理を始める前に止めます。旅行会社からのメールを自動で保存する形にしないのは、署名前の案や見積の往復が混ざり、どれが最後の版か機械では決められないからです。

S3 への保存を AWS Lambda が受け、StartDocumentAnalysis を呼びます。ClientRequestToken に団体番号とファイルのハッシュから作った値を入れ、同じファイルを二度読まないようにします。 完了は Amazon SNS に届き、SUCCEEDED を確かめてから結果を取り、すぐ S3 に保存します（JobId は7日間だけ有効です）。

入力データを集める

質を決めるのは、いちばん下の対応表です。 旅行会社は「Twin」「Standard Twin」「TWN」と書き方がばらばらで、対応表が無いと、正しい室数でも別のタイプとして食い違いが出ます。

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

読み取りは StartDocumentAnalysis に FeatureTypes として TABLES、FORMS、QUERIES、LAYOUT、SIGNATURES を指定して行います。全文の行と単語は、指定した機能にかかわらず返ります。

表は、セルの行と列の番号で組み立て直します。 公式の説明では、セルは CELL として行の番号・列の番号・信頼度を持ち、列見出しのセルには COLUMN_HEADER が付きます。結合されたセルは MERGED_CELL として別に返ります。日付が結合セルの見出しになっている表は、結合セルを先に展開してから泊ごとの行にします。

見出しの構造は LAYOUT で取ります。 見出しは LAYOUT_SECTION_HEADER、本文は LAYOUT_TEXT として、上から下・左から右の読む順で返ります。「Attrition」の見出しから次の見出しまでを、減室の条件の原文として切り出します。

質問は、手引きに沿って文書の言葉で、何の日付かを特定して聞きます。

ページの指定が無いと質問は1ページ目しか見ないので、Pages に ["*"] を入れます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFは扱えないため、印刷し直してPDFにします
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。保護されたものは旅行会社に解除したものを頼みます
3. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。ファックスや写真で届いた署名ページは、読めない項目が出やすいので印を付けます
4. 言語の確認 … 英語以外の文が含まれていれば質問を外し、表とキーと値と全文で読みます
5. 版の確認 … 同じ団体番号の前の版があるかを調べ、あれば改定版として扱います

AIに処理させる

させるのは、室数・料金・条件・期限を原文のまま取り出し、期限を「何の期限か」と「到着日から何日前か」に分けることだけです。

期限の分け方が、いちばん手間を減らすところです。 「Cut-off date: 21 days prior to arrival」なら、種類は cutoff、基準は arrival、日数は21と分け、原文を添えます。 日付で書かれている期限は、その日付を写すだけにします。

1行目と3行目が、いちばん起きやすい失敗です。 減室の条件が書かれていない契約書を渡すと、AIは業界の通念らしき割合で埋めます。その数字は契約書のどこにも無く、請求の根拠になりません。

取消料の段階は、表と本文の両方に書かれていることがあります。 表では「30-15 days: 50%」、本文では「within 21 days」のように食い違う契約書もあります。どちらかに寄せず、両方を写して ambiguous にします。 どちらが有効かは、契約の優先順位の条項を読んだ人が決めます。

指示内容を固定する

あなたはホテルの団体営業の担当として、英文の団体宿泊契約書を読み、
予約台帳に登録するための項目を取り出します。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【取り出す項目】
1. 泊ごと・部屋タイプごとの室数と1室1泊の料金（通貨、税とサービス料の扱い）
2. 減室（attrition）の条件
3. 取消料の段階
4. デポジットと支払の条件
5. 提出物と期限（ルーミングリスト、返却期限、最終の人数）
6. 無料の部屋の条件

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- not_found .. その項目が書かれていない
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない（表と本文が食い違う場合も含む）
迷ったときに ok を選ばないでください。

【厳守事項】
- original には、契約書の英文をそのまま写してください。言い換えないでください。
- 日本語の説明は note_ja にだけ書いてください。
- 期限は、種類（deadline_type）、基準（arrival / signing / date）、日数に分けてください。
  日付への換算はしないでください。日付で書かれていれば、その文字列を写してください。
- 取消料や違約金の金額を計算しないでください。割合と対象を写してください。
- 書かれていない条件を補わないでください。「通常は」「業界では」で埋めないでください。
- 室数と料金は、表のセルの値を写してください。合計や平均を計算しないでください。
- 部屋タイプの名前は、契約書の書き方のまま写してください。
- 請求するべきか、免除するべきかは書かないでください。
- 英語以外の文が含まれていれば、language_note にその旨を書いてください。

【読み取り結果】{textract_result}
【見出しごとに区切った原文】{sections}
【組み立て直した表】{tables}

「日付への換算をしない」は、書かないと必ず破られます。 到着日と「21 days prior」が並んでいれば、AIは親切に日付を出します。改定版で到着日が1日ずれても、その日付は直りません。

「部屋タイプの名前を書き方のまま写す」も同じ理由です。 AIが「Standard Twin」を台帳のタイプ名に寄せると、対応表で照合する意味がなくなります。

出力形式を固定する

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

{
  "contract_no": "",
  "room_block": [
    { "night": "", "room_type_text": "", "rooms": 0, "rate": "", "currency": "",
      "tax_service_text": "", "status": "ok | unreadable | ambiguous" }
  ],
  "deadlines": [
    { "deadline_type": "deposit | rooming_list | cutoff | attrition_review | final_numbers | other",
      "basis": "arrival | signing | date", "days": 0, "date_text": "",
      "original": "", "status": "ok | not_found | ambiguous" }
  ],
  "cancellation_tiers": [ { "from_days": 0, "to_days": 0, "charge_text": "", "original": "" } ],
  "attrition": { "allowance_text": "", "review_text": "", "original": "", "status": "" },
  "comp_rooms": { "original": "", "status": "" },
  "agent_signature_detected": "yes | no",
  "language_note": ""
}

1つ目の理由は、期限を毎日数え直せることです。 プログラムは basis と days と台帳の到着日から日付を出し、到着日が変わった改定版でも、全部の期限が自動で動きます。

2つ目は、照合の結果を別の層に置けることです。

改定版は前の版と項目ごとに比べ、変わった泊と期限に印を付けます。

システムへ連携する

予約台帳へは、人が確定するまで書き込みません。 室数が違うと出ても、台帳の側が正しい（旅行会社が古い版に署名した）こともあるからです。通知には、期限の種類、日付、原文、団体の担当者を載せ、契約書を開かなくても次の手が分かるようにします。

人が確認する

人が確かめるのは、印の付いた項目と、期限の一覧です。 match の泊は一覧で流し見ます。

1. needs_human を先に見る … 読めなかったセルと、表と本文が食い違う条件です。画像を開いて値を確定します
2. 期限の一覧を原文と見比べる … 種類と日数の分け方が正しいか、「prior to arrival」と「after signing」を取り違えていないかを見ます
3. mismatch の扱いを決める … 台帳を直すか、旅行会社に確かめるかを決めます。確認文の下書きは直してから送ります
4. 署名の印を見る … 旅行会社の署名が検出されないものは、署名済みの版が届いているかを確かめます
5. 確定して台帳に登録する … 確定したものだけが、毎朝の期限の通知の対象になります

2番目を省かないでください。 期限の基準を取り違えると、通知そのものが誤った日に届きます。 誤った通知は、通知が無いより危険です。担当者は通知を信じて、カレンダーを見なくなるからです。

目標は、90件をならして1件10分です。 改定版で変わった泊だけを見るもの、新規で全部の期限を見るものが混ざります。15分を超える件が続く旅行会社は、書式そのものを相談する材料にします。

例外に対処する

上から3行目までが大半を占めます。 どれも契約書の作り方の問題で、旅行会社に自社の書式で署名してもらう取り決めがいちばん効きます。

記録を残す

• 元の契約書のPDFと、保存した日時・版
• AWS Textract の結果のJSON全文と JobId
• Claude API の出力（room_block、deadlines、cancellation_tiers）
• 照合に使った台帳の値と、照合の結果
• 期限の換算に使った到着日と規則、通知を送った日時と相手
• 人が値を直した記録と、確定した版・確定した人

5つ目を残すのは、取消料を請求するときの根拠になるためです。 どの版のどの条件で、いつ知らせたかが分かれば、旅行会社との話が早く済みます。