英文のチャージバック通知を読み取り、予約・決済・滞在の記録と照らして、反証に要る資料と回答期限を台帳にする

処理の起点を決める

起点は2つあります。通知が届いたときと、毎朝の定時です。

1つ目は、受付フォルダ（Amazon S3）に通知のPDFが保存されたことです。共有受信箱のルールで、決済代行とOTAの送り元から届いたメールの添付をS3へ転送します。保存の通知で AWS Lambda が動き、読み取りから台帳への記録までを済ませます。届いた時点で読むので、期限を数える起点が受け取った日からずれません。

2つ目は、毎朝9時の定時です。台帳の全案件について、社内の期限まで3営業日を切ったもの、資料が集まっていないもの、館からの返事が無いものを一覧にして、経理の担当者に送ります。期限の管理を、担当者の記憶ではなく台帳の側に置きます。

照会からチャージバックに進んだ通知や結果の通知などの続報も、同じ経路で入れます。 ケース番号が同じものは同じ行の履歴に足します。

入力データを集める

質を決めるのは、理由コードの対応表です。 Stripe のドキュメントでは、カードの理由コードを「未処理のクレジット」「重複支払い」「不正使用」「商品が届かない」などのカテゴリーに整理しており、Mastercard の 4853 や 4859 にはノーショーに対する宿泊料、American Express の C18 には「ノーショー」または車両デポジットのキャンセル、170 には宿泊予約施設のキャンセルの項目が並んでいます。同じノーショーの申し立てでも、ブランドごとに番号が違います。 対応表はブランドと番号の組で引けるように作ります。

決済の記録は、通知と予約をつなぐ唯一の橋です。 通知に予約番号が書かれていることはまれで、決済代行の取引IDか、金額・日付・カード番号の下4桁の組で決済の記録を引き、そこに入っている自社の注文番号から予約に戻ります。

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

読み取りは StartDocumentAnalysis にS3の場所と FeatureTypes を渡して始めます。完了は NotificationChannel に指定した Amazon SNS のトピックに通知され、状態が SUCCEEDED なら GetDocumentAnalysis で結果を取ります。

質問の答えが見つからなければ空のまま返ります。 期限が空なら、全文から due、respond、within、days を含む行を探します。「通知の日付から10日以内」のような相対の書き方なら、その文と通知の日付を両方記録し、日付の計算はプログラムの側で行います。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。同期の処理はPDF1ページまでで、通知は2〜3ページになることが多いので非同期で読みます。

決済の記録とPMSの予約は、Python が読みます。 決済代行のCSVは毎朝取り込み、PMSは館ごとの予約の出力を夜間に取り込んでおきます。生成AIには、決済の記録もPMSのデータも渡しません。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。メール本文に通知が書かれているものは、本文をPDFにして入れます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは送り元に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 言語の確認 … 6言語に入らない通知は読み取りに回さず、担当者が目で見る一覧に入れます
5. 送り元の特定 … 送信元のアドレスから、決済代行かOTAか、どの事業者かを決めます。期限の数え方の既定値を送り元ごとに持つためです
6. 続報の判定 … 件名や本文のケース番号が台帳にあれば、続報として同じ行に付けます

AIに処理させる

させるのは、通知から8つの項目を取り出し、原文の文字列と、日付や金額の解釈を分けて書き出すことです。 照合はさせません。

回答期限の原文を残すのは、日と月の順序が送り元で違うためです。 05/11/2026 は5月11日にも11月5日にも読めます。1週間ほどの回答期間では、取り違えは致命的です。 順序が決まらない日付は解釈させず、人に見せます。

指示内容を固定する

あなたはホテルチェーンの経理部で、海外の決済代行から届いた英文の
チャージバック通知の記載を記録する担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
case_id、stage、card_brand、reason_code_raw、amount_raw、amount、currency、
transaction_date_raw、transaction_date、transaction_date_kind、card_last4、
response_due_raw、response_due_date、response_due_relative、
documents_requested（配列）、cardholder_claim_raw、
各項目の status と source（ページと行）

【status の選び方】
- ok ........... 値が読み取れており、その項目として解釈できる
- missing ...... 書かれていない
- unreadable ... 文字は検出されているが値として確定できない
- ambiguous .... 候補が複数ある、または日付の順序が決まらない

【厳守事項】
- 日付は、日と月の順序が文面から確定できるときだけ YYYY-MM-DD で
  入れてください。決まらなければ空にし、status を ambiguous にしてください。
- 回答期限が「〜日以内」のような書き方なら、日付に直さず、
  その文をそのまま response_due_relative に入れてください。
- 理由コードは書かれた番号だけを入れてください。番号の意味を
  書き添えたり、別のブランドの番号に読み替えたりしないでください。
- 取引日が決済の日か宿泊の日か書かれていなければ、
  transaction_date_kind を unknown にしてください。
- 反論できるか、勝てそうかを書かないでください。
- 通知でない書類（請求書、入金明細、販促メールなど）と判断した場合は、
  項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_forms_tables_queries}
【送り元の区分】{sender_type}

「番号の意味を書き添えない」を明記しないと、書き添えます。 理由コードの番号を見ると、知っている意味を補足しようとし、それがブランド違いの意味でも、もっともらしい文になります。 意味は対応表の側に置き、AIには番号だけを写させます。

出力形式を固定する

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

{
  "file": "",
  "document_type": "chargeback_notice",
  "case_id": "CB-2026-104233",
  "stage": "chargeback",
  "card_brand": "Mastercard",
  "reason_code_raw": "4853",
  "amount_raw": "JPY 48,000",
  "amount": 48000,
  "currency": "JPY",
  "transaction_date_raw": "09/14/2026",
  "transaction_date": "2026-09-14",
  "transaction_date_kind": "unknown",
  "card_last4": "4417",
  "response_due_raw": "",
  "response_due_relative": "within 10 days of the date of this letter",
  "documents_requested": ["Cancellation policy", "Proof of disclosure"],
  "items": [
    { "item": "response_due", "status": "ok", "confidence": 0, "source": "p1:L22" }
  ],
  "request_draft": ""
}

1つ目の理由は、照合と期限の計算をプログラムの側に置けることです。 Python が決済の記録と予約を引き、対応表から資料を引いて、案件ごとに印を付けます。

2つ目は、社内の期限を一律に置けることです。 通知の期限から3営業日前を社内の期限とし、館への資料の依頼はさらにその3営業日前に締めます。期限が確定しない案件は、それだけで印が付きます。

システムへ連携する

決済代行への回答の提出は、この構成からは行いません。 Stripe のドキュメントでは、回答を提出する機会は1回のみで、提出後は回答を編集したり、追加のファイルを送ったりできないとされています。決済代行によって扱いは違いますが、一度きりの提出を自動にする理由はありません。 資料をまとめて提出するのは、責任者の判断を経た担当者です。

人が確認する

経理の担当者が開くのは、ok 以外の印が付いた案件です。 ok の案件は、期限と資料の一覧を並べた台帳で流し見ます。

1. deadline_unclear を最初に片付ける … 期限が確定しない案件は、通知の画像と送り元の決まりで期限を確定させます。期限が決まらないうちは、他の作業に進みません
2. booking_not_found と multi_match の予約を確かめる … 決済代行の管理画面で取引を開き、館と予約を特定します
3. 資料の一覧を確かめて館に依頼する … 下書きを直して、館のフロントに送ります
4. 反論するかを責任者に上げる … 集まった資料と宿泊客の主張を並べ、責任者と支配人に決めてもらいます

提出する資料のまとめ方にも決まりがあります。 Stripe のドキュメントでは、反証資料ファイルのサイズを合計で最大4.5MB、Mastercard の反証資料は合計で最大19ページまでに制限し、音声や動画のファイル、クリックすると詳細が表示されるリンクは含めないよう案内されています。館から集めた資料を担当者がそのまま束ねると、上限を超えることがあります。

例外に対処する

上から3行目と4行目が、取り返しのつかない失敗のほとんどを生みます。 どちらも回答期限という1つの値の問題で、ここを人に回す設計を崩すと、台帳の期限そのものが当てにならなくなります。

記録を残す

• 元の通知と、受け取った日時、送り元、メールの件名
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（原文と解釈の両方）
• 照合の結果と、そのとき参照した決済の記録と対応表の版
• 担当者が期限や予約の特定を直した記録 … どの値を、どう変えたか、誰が確かめたか
• 反論か受け入れかの判断と、提出した日、結果の通知との対応

最後の行は、対応表を育てる材料になります。 理由コードごとに、反論した件数と結果の件数を並べると、集める資料が足りていない理由が見えてきます。 Stripe のドキュメントでは、カード保有者の銀行が内容を審査して結果を決め、確認には最長で3か月かかる場合があるとされています。結果の通知は、元の行に付けておきます。