海外出張の英文の予約確認書を読み取り、日程・便名・宿泊先・料金を出張台帳に転記して、出張規程の上限と申請内容との食い違いを拾う

処理の起点を決める

起点は、受付フォルダ（Amazon S3）に予約確認書が保存されたことです。 共有受信箱のルールで、転送されたメールの添付のPDFと、本文だけのメールをPDFにしたものをS3へ入れます。保存の通知で AWS Lambda が動き、読み取りから台帳への記録までを済ませます。

転送のメールの件名に出張申請の番号を書く決まりにします。 番号があれば台帳の行がすぐ決まり、無ければ出張者名と日程から候補の行を探して、担当者に確かめさせます。 番号の無い転送が多い出張者には、決まりを伝え直します。

毎朝8時にも動かします。 7日以内に出発する出張のうち、航空券かホテルの確認書が届いていないもの、たびレジの登録が確かめられていないもの、取消期限が3日以内に迫った予約を一覧にして担当者に送ります。取消期限を一覧に出すのは、出張が取りやめや延期になったときに、取消料のかからないうちに手を打つためです。

入力データを集める

質を決めるのは、社員の一覧のローマ字の表記です。 予約確認書の名前はパスポートの表記で、姓と名の順、ミドルネームの有無、長音の書き方が揃いません。 一覧の表記と完全に一致しなければ、候補として担当者に見せます。

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

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

便は表から取ります。 旅程表やeチケットの控えでは、便名、区間、日付、時刻、等級が表の行に並ぶので、表の行ごとに1区間として読みます。 質問の答えは、見つからなければ空のまま返るので、空の項目は全文から欄の見出しの語を探し、それでも無ければ missing にします。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。出張申請、規程の表、換算レート、社員の一覧は Python が読み、生成AIには渡しません。

AIへ渡す前に整形する

1. メール本文のPDF化 … ホテルや予約サイトの確認はメール本文だけで届くことが多いので、本文をPDFにしてから入れます
2. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます
3. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは出張者に解除したものを頼みます
4. 転送の文の除去 … 出張者が転送のときに書いた文と、転送の見出しをPDFにする前に外します
5. 言語の確認 … 6言語に入らない確認書は読み取りに回さず、担当者が目で見る一覧に入れます
6. 取り直しの判定の準備 … 件名の Change、Modified、Cancellation の語を記録し、同じ予約番号の確認書が前にあるかを調べます

4番目を省くと、転送の文に書かれた日付や金額を読み取ります。 出張者が「前の便は〇日でした」と書き添えていると、その日付を便の日付として取ることがあります。

AIに処理させる

させるのは、予約確認書から便と宿泊の項目を取り出し、料金が何の額かを書き出すことです。 照合と換算はさせません。

料金の「1泊か滞在全体か」と「税込みか」を分けるのが、いちばん大事な区別です。 同じホテルの同じ予約でも、確認書によって書かれ方が違い、種類を取り違えると、上限超えを見逃すか、超えていない予約を問い合わせることになります。

3行目がいちばん起きやすい失敗です。 税の扱いが書かれていない確認書で、一般的な書き方から「税込み」と推すと、税別の料金が上限の内に見えます。 書かれていなければ unknown で返させます。

指示内容を固定する

あなたは会社の総務部で、海外出張の英文の予約確認書の記載を
記録する担当です。OCRの読み取り結果だけを使ってください。
推測で埋めないでください。

【取り出す項目】
document_kind（new / change / cancellation / unknown）、
booking_ref、traveler_names（配列）、
flights（配列：flight_no、from_raw、to_raw、
  depart_raw、depart、arrive_raw、arrive、cabin_raw）、
hotels（配列：name_raw、city_raw、check_in、check_out、
  rate_amount、rate_currency、rate_kind（per_night / total / unknown）、
  tax（included / excluded / unknown））、
fare（amount、currency、tax_raw）、
cancel_deadline_raw、cancel_deadline、
各項目の status と source（ページと行）

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

【厳守事項】
- 宿泊の料金が1泊の額か滞在全体の額かを rate_kind に入れてください。
  文面から決まらなければ unknown にしてください。
- 税やサービス料が含まれるかを tax に入れてください。
  書かれていなければ unknown にしてください。推して決めないでください。
- 金額は書かれた通貨のまま入れてください。換算や泊数での割り算を
  しないでください。
- 日付は、月が英語の名前で書かれているか、文面から日と月の順序が
  確定できるときだけ YYYY-MM-DD で入れてください。
- 名前は書かれたとおりに入れてください。表記を直さないでください。
- 規程の上限を超えているか、予約を取り直すべきかを書かないでください。
- 予約確認書でない書類（請求書、領収書、案内のメールなど）と
  判断した場合は、項目を取り出さず document_kind を unknown にし、
  document_type に種類を書いてください。

【読み取り結果】{textract_result}

「税の扱いを推して決めない」を明記しないと、推します。 確認書に税の記載が無いとき、「Room rate」という語だけから込みと判断して返し、後段の照合で上限の内に入ってしまいます。

出力形式を固定する

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

{
  "file": "",
  "document_kind": "new",
  "booking_ref": "",
  "traveler_names": ["YAMADA/TARO MR"],
  "flights": [
    { "flight_no": "XX101", "from_raw": "NRT", "to_raw": "SIN",
      "depart": "2026-10-20T10:30", "arrive": "2026-10-20T16:45",
      "cabin_raw": "ECONOMY" }
  ],
  "hotels": [
    { "name_raw": "", "city_raw": "SINGAPORE",
      "check_in": "2026-10-20", "check_out": "2026-10-23",
      "rate_amount": 0, "rate_currency": "SGD",
      "rate_kind": "per_night", "tax": "unknown" }
  ],
  "cancel_deadline": "2026-10-18",
  "items": [
    { "item": "hotels[0].tax", "status": "missing", "confidence": 0, "source": "" }
  ]
}

1つ目の理由は、照合をプログラムの側に置けることです。 Python が申請番号と出張者名で台帳の行を決め、申請の日程と規程の表、換算レートで印を付けます。

2つ目は、変更の確認書を履歴として持てることです。 document_kind が change なら、同じ予約番号の前の値を残したまま新しい値を足します。 台帳の日程はいつも最新になり、何がいつ変わったかも引けます。

システムへ連携する

予約の変更や取消、出張申請の承認は、この構成からは行いません。 規程を超える予約を取り直すか、例外として認めるかは、出張者と上長が決め、承認はいまの出張申請のワークフローで行います。

人が確認する

担当者が開くのは、ok 以外の印が付いたものです。

1. date_mismatch を最初に片付ける … 申請と違う日程は、出張の予定そのものが変わった可能性があるので、出張者に確かめて申請を直してもらいます
2. over_limit と class_mismatch を上長に回す … 例外として認めるかを上長に確かめます。出発前に決めれば、取り直す時間が残ります
3. needs_human を確認書の画像で確定させる … 料金の種類、税の扱い、名前の表記を確かめます

目標は、160件をならして1件3分です。 印の付く件が増えた月は、規程の表に無い都市が増えていないか、税の扱いが書かれない予約サイトが増えていないかを見ます。

例外に対処する

上から4行目と5行目は、推して決めると規程の判定が誤ります。 表に無いものは表に足してから照合し直す、という順を崩さないでください。

記録を残す

• 元の予約確認書と、受け取った日時、転送した出張者、メールの件名
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（原文と、料金の種類・税の扱いの解釈）
• 照合の結果と、そのとき参照した規程の表と換算レートの版
• 予約の変更の履歴 … いつ、どの便やホテルが、何から何に変わったか
• 上長が例外を認めた記録と、その理由

最後の行は、規程を見直す材料になります。 同じ都市で例外が続くなら、上限そのものが実態に合っていないことが分かります。