海外の配送業者から届く英文の配達証明（POD）を読み取り、受取人・受領日時・個数・リマークを出荷台帳に転記して、請求の前に未着・数量違い・破損の記載を拾う

処理の起点を決める

受付フォルダ（Amazon S3）にPODが保存されたことを起点にします。 PODは提携先ごとに届く日がばらばらで、配達の翌日に来るものもあれば月末にまとめて来るものもあるため、1日1回の定時実行にはしません。 届いた日に読めば、破損の記載に気づくのが最大で1か月早くなります。

S3 への保存を AWS Lambda が受け、StartDocumentAnalysis を呼びます。ClientRequestToken にファイルのハッシュから作った値を入れると、同じトークンで呼び直しても同じ JobId が返り、同じPODを二度読みません。 JobTag には提携先のコードを入れ、完了の通知（Amazon SNS）からどの提携先のPODかを引けるようにします。通知の状態が SUCCEEDED であることを確かめてから結果を取り、すぐ S3 に保存します。 JobId は7日間しか有効ではありません。

未着の一覧は、別のトリガーで動かします。 毎朝の定時に出荷台帳を読み、配達予定日から提携先ごとに決めた日数を過ぎてもPODの無い出荷を数えます。

入力データを集める

質を決めるのは、下の3つです。 出荷台帳に運送状番号と出荷個数が無ければ照合ができず、提携先の一覧が無ければ未着の日数を決められません。言い換えの一覧は、最初は空でかまいません。 担当者がリマークの区分を直すたびに1行ずつ増え、略語や現地の言い回しを迷わず分けられるようになります。

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

結果は GetDocumentAnalysis で取ります。1回の呼び出しで返る件数は既定・最大1,000で、NextToken が返る限り続けて取ります。 JobStatus が PARTIAL_SUCCESS のときは Warnings に出たページを記録し、そのPODを needs_human にします。

質問（Queries）は QueriesConfig に並べます。非同期の処理では1ページに30問まで投げられます。PODに投げる質問は次のとおりです。

質問への答えが見つからないときは、答えの欄が空のまま返ります。 リマークが無ければ REMARKS は空で返り、その事実を記録に残せます。

署名は「あるかどうかと、どこにあるか」しか分かりません。 SIGNATURE のブロックは、ページ上で検出された署名の位置と信頼度を返すもので、誰が署名したか、本物かは返しません。 受取人の名前は質問への答えとキーと値の組から取り、署名の位置とは別に扱います。

AIへ渡す前に整形する

1. 形式の確認 … 文書の分析は JPEG、PNG、TIFF、PDF を扱います。HEIC などで届いた写真は JPEG に変換します
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。保護されたものは提携先に解除したものを頼みます
3. ページ数とサイズの確認 … 非同期の処理でPDFは500MB・3,000ページが上限です。月末のまとめ送りで、1つのPDFに数十件のPODが綴じられていることがあります。 1件ごとのページに分けます
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。ドライバーの端末の画面を小さく写した写真は、ここで止まります
5. 出荷台帳の準備 … 照合用に、直近3か月の出荷台帳を読み込みます

3番目を省かないでください。 まとめ送りのPDFをそのまま読むと、質問への答えが1件目のPODのものだけになり、残りの出荷が「PODが無い」まま未着の一覧に載ります。 運送状番号が書かれた位置でページを切り分け、1件ずつ読みます。

AIに処理させる

させるのは、読み取り結果を項目にそろえ直し、リマークの文言を区分に分け、根拠の文字列を添えることだけです。

リマークの区分には、言い換えの一覧を渡します。 一覧にある文言なら、その区分を使います。一覧に無ければ文言から区分を選び、その行には new_term の印を付けて人に確かめてもらいます。 「OK」「Good order」「Rcvd in good condition」は none に、「Subject to inspection」「STC（said to contain）」のような留保の文言は other に入れます。

2行目がいちばん起きやすい失敗です。 受領個数の欄が空いていると、AIは「全数受領」の想定で埋めがちで、その瞬間に不足の疑いが見えなくなります。

指示内容を固定する

あなたは国際フォワーダーの輸出業務課で、海外の配送業者から届いた英文の配達証明（POD）を点検する担当です。
OCRが返した読み取り結果だけを見て、項目をそろえてください。推測で埋めないでください。

【やること】
1. 運送状番号・受取人・受領日・受領時刻・受領個数を、原文のまま写す
2. リマークの文言を原文のまま写し、下の区分のどれに当たるかを選ぶ
3. 各項目の根拠にした原文の文字列を evidence に入れる

【リマークの区分の決まり】
- まず「リマークの言い換えの一覧」を見る。一覧にある文言ならその区分を使う
- 一覧に無ければ、文言から区分を選び、term を "new_term" にする
- none ...... 異常が無い旨の記載（Good order など）、またはリマークの欄が空
- damage .... 破損・へこみ・つぶれ・破れの記載
- shortage .. 不足・欠品・個数の違いの記載
- wet ....... 濡れ・水濡れの跡の記載
- refused ... 受取の拒否の記載
- other ..... 上のどれにも当たらない記載。Subject to inspection などの留保もここに入れる
- 文字が読めず区分を決められなければ "unreadable" にする

【厳守事項】
- 受領個数が書かれていなければ "not_found" にしてください。出荷個数や「全数」で埋めないでください。
- 受領個数と出荷個数を比べないでください。不足かどうかを判断しないでください。
- 留保の文言を none にしないでください。
- 日付が日・月の順か月・日の順か決められないときは "ambiguous" にしてください。
- 署名があるかどうかを書かないでください。署名の判定は別の処理で行います。
- 破損の程度、責任の所在、申し立ての要否を書かないでください。
- 受取人の名前以外の個人の情報（電話番号・身分証の番号など）を書き出さないでください。
- confidence は OCR が返した値をそのまま入れてください。

【読み取り結果】{textract_result}
【リマークの言い換えの一覧】{remark_terms}
【この提携先の日付の書き方】{date_format}

「比べない」を書いているのは、読み取り結果に「10 PCS」と「9」が並ぶと、片方を出荷個数とみなして「不足1」と書くことがあるからです。 比較はプログラムが出荷台帳を相手に行います。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とスキーマを指定）を使い、形の崩れた応答を照合のプログラムに流さないようにします。

{
  "file_id": "",
  "partner_code": "",
  "waybill_no": { "value": "", "status": "ok | not_found | ambiguous", "confidence": 0, "evidence": "" },
  "received_by": { "value": "", "status": "ok | not_found", "confidence": 0, "evidence": "" },
  "delivery_date": { "value": "", "status": "ok | not_found | ambiguous", "confidence": 0, "evidence": "" },
  "delivery_time": { "value": "", "status": "ok | not_found", "confidence": 0, "evidence": "" },
  "pieces_received": { "value": "", "status": "ok | not_found", "confidence": 0, "evidence": "" },
  "remarks": [
    { "text": "", "category": "none | damage | shortage | wet | refused | other | unreadable",
      "term": "alias | new_term", "handwritten": true, "confidence": 0, "page": 1 }
  ]
}

照合のプログラムは、この結果と SIGNATURE の検出、出荷台帳を合わせて、出荷ごとに次の判定を付けます。

理由は、AIの出力とプログラムの判定を別の層に置けることです。 リマークの区分はAIが原文から付け、判定は規則が出荷台帳を相手に付けます。どの区分を請求の保留にするかが変わっても、直すのは規則だけです。

システムへ連携する

出荷台帳へは直接書き込みません。 clean のものは毎日まとめて、それ以外は担当者が確かめた後に取り込みます。

人が確認する

担当者が開くのは exception・mismatch・needs_human の出荷と、未着の一覧だけです。 clean のものは一覧で件数と提携先を流し見ます。全件を開く設計にすると、第10章の2分には収まりません。

1. exception を先に見る … 原本でリマークの文言を読み、区分が正しいかを確かめます。申し立ての期限がある出荷なので、その日のうちに営業の担当へ知らせます
2. needs_human の署名の無いものを確かめる … 署名が薄く検出されないことがあります。本当に無ければ、提携先に受領の証跡を求めます
3. mismatch の個数を確かめる … 原本の受領個数を読み直し、出荷台帳の個数（梱包の数え方）とも見比べます
4. 未着の一覧を提携先ごとにまとめる … 照会の下書きを直して送ります。送るのは担当者です
5. 判定を変えたら記録する … どの出荷を、どの判定に、なぜ変えたかを残します

3番目を急がないでください。 台帳がパレット、PODがカートンで数えていることがあり、「10」と「120」の違いは不足ではありません。 提携先ごとの数え方を一覧に足します。

例外に対処する

上から5行目が、立ち上げの時期にいちばん多く出ます。 出荷の手配のときに提携先の追跡番号を出荷台帳に記録する手順を足すと減ります。

記録を残す

• PODの原本と、受け取った日時・提携先・元のメール
• OCRが返したJSONの全文（GetDocumentAnalysis の全ページ分）
• AIのそろえ直しとリマークの区分の結果
• 照合の結果と、そのとき参照した出荷台帳の行
• 担当者が判定や区分を変えた記録
• 営業への連絡、提携先への照会と回答、請求を保留・解除した日時
• 提携先ごとの needs_human と new_term の発生率、PODが届くまでの日数

4つ目で出荷台帳の行を残すのは、出荷個数や届け先が後から直されることがあるためです。 当時どの個数と照らしたかが分からないと、顧客や提携先との精算のときに説明できません。