英文の到着案内を読み取り、入港日・フリータイムの期限・請求額を輸入台帳に転記して、デマレージの恐れがあるコンテナを拾う

処理の起点を決める

起点は2つあります。到着案内が届いたときと、毎朝の定時です。

1つ目は、受付フォルダ（Amazon S3）に到着案内のPDFが保存されたことです。共有受信箱のルールで、登録した船会社とフォワーダーのアドレスから届いたメールの添付をS3へ転送します。保存の通知で AWS Lambda が動き、読み取りから台帳への記録までを済ませます。改訂版も同じ経路で入れ、件名と本文から改訂かどうかを判定します。

2つ目は、毎朝8時の定時です。台帳の全コンテナについて、フリータイムの最終日まで3営業日を切ったのに通関が終わっていないもの、配車の予定日が最終日より後のものを一覧にして、担当者と通関・配車の担当者に送ります。通関の状態と配車の予定は毎日変わるので、到着案内が届いた日だけでなく毎朝照らし直します。

入力データを集める

質を決めるのは、フリータイムの条件の表です。 同じ船会社でも荷主ごとに契約の日数が違い、ドライとリーファーで日数が違うこともあります。 表に無い組み合わせは、計算をせずに人に回します。

通関の状態と配車の予定は、毎朝取り込みます。 この2つが古いと、間に合うはずのコンテナに印が付き、担当者が印を信じなくなります。

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

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

質問の答えが見つからなければ空のまま返ります。 フリータイムが空なら、全文から free time、free days、last free day、LFD を含む行を探し、それでも無ければ not_stated にします。 書かれていないフリータイムを、契約の日数で埋めることはしません。契約の日数は別の列に持ちます。

コンテナ番号は表から取ります。 表の行ごとにコンテナ番号、種類、封印番号を読み、番号が決まった英字と数字の並びになっているかを、後段で確かめます。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。同期の処理はPDF1ページまでで、到着案内は請求の明細を含めて2〜3ページになるので非同期で読みます。

台帳、条件の表、通関の状態、配車の予定は、Python が読みます。 生成AIには渡しません。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。メール本文に到着の案内が書かれているものは、本文をPDFにして入れます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは送り元に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 言語の確認 … 6言語に入らない到着案内は読み取りに回さず、担当者が目で見る一覧に入れます
5. 送り元の特定 … 送信元のアドレスから船会社かフォワーダーかを決め、その送り元の日付の書き方を引きます
6. 改訂の判定の準備 … 件名に Revised、Amended、Updated があるかを記録し、読み取り結果と合わせて改訂かどうかを決めます

5番目の日付の書き方は、送り元ごとに持つと効きます。 同じ船会社はいつも同じ書き方をするので、決まった書き方の送り元の到着案内でだけ、日と月の順序を確定させます。

AIに処理させる

させるのは、到着案内から8つの項目を読み取り、原文の文字列と、日付や金額の解釈を分けて書き出すことです。 期限の計算と照合はさせません。

入港日の「予定か実績か」を分けるのが、いちばん大事な区別です。 ETA と Arrival Date を同じ入港日として扱うと、予定の日付で数えた最終日が、実績の入港で1〜2日ずれます。 予定なら、実績の到着案内が来るまで期限は仮の値として扱います。

最後の行も見落とされがちです。 OCRが O と 0 を取り違えたとき、それらしく直すと、台帳に存在しないコンテナが生まれます。 形が合わない番号は直さず、人に見せます。

指示内容を固定する

あなたは物流会社の輸入業務部で、船会社やフォワーダーから届いた
英文の到着案内の記載を記録する担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
mbl_no、hbl_no、vessel_voyage_raw、arrival_date_raw、arrival_date、
arrival_kind（estimated / actual / unknown）、pod_raw、
containers（配列：container_no_raw、type_raw、seal_raw）、
free_time_raw、free_time_days、last_free_day、
charges（配列：item_raw、amount、currency）、total_raw、
revision（revised / original / unknown）、
各項目の status と source（ページと行）

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

【厳守事項】
- フリータイムが書かれていない場合は not_stated にしてください。
  契約や慣習の日数で埋めないでください。
- 入港日が予定（ETA）か実績かを arrival_kind に入れてください。
  決まらなければ unknown にしてください。
- 日付は、日と月の順序が文面または {date_style} から確定できるときだけ
  YYYY-MM-DD で入れてください。決まらなければ空にし、ambiguous にしてください。
- コンテナ番号は読み取った文字列をそのまま入れてください。
  文字を補ったり、似た文字に直したりしないでください。
- 最終日までに引き取れるか、請求額が正しいかを書かないでください。
- 到着案内でない書類（請求書だけのもの、船積の案内、販促など）と
  判断した場合は、項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_forms_tables_queries}
【この送り元の日付の書き方】{date_style}

「契約や慣習の日数で埋めない」を明記しないと、埋めます。 フリータイムの記載が無い到着案内で、よくある日数を補った値を返すと、後段の照合では契約の日数と一致したように見え、食い違いの印が付きません。

出力形式を固定する

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

{
  "file": "",
  "document_type": "arrival_notice",
  "mbl_no": "ABCD26091234",
  "hbl_no": "",
  "vessel_voyage_raw": "EVER SAMPLE 112E",
  "arrival_date_raw": "ETA 14-Oct-2026",
  "arrival_date": "2026-10-14",
  "arrival_kind": "estimated",
  "pod_raw": "TOKYO, JAPAN",
  "containers": [
    { "container_no_raw": "TCNU1234567", "type_raw": "40HC", "seal_raw": "" }
  ],
  "free_time_raw": "",
  "free_time_days": null,
  "last_free_day": "",
  "charges": [
    { "item_raw": "D/O FEE", "amount": 0, "currency": "JPY" }
  ],
  "revision": "original",
  "items": [
    { "item": "free_time", "status": "not_stated", "confidence": 0, "source": "" }
  ]
}

1つ目の理由は、期限の計算と照合をプログラムの側に置けることです。 Python が条件の表で最終日を計算し、記載と通関・配車の予定と比べて印を付けます。

2つ目は、予定と実績を分けて持てることです。 arrival_kind が estimated の間は最終日を仮の値とし、実績の到着案内が来たら計算し直して履歴に残します。

3つ目は、記載が無いことを記録として残せることです。 not_stated が多い送り元は、フリータイムを契約の表だけで管理していることが分かり、船会社に確認する先が決まります。

システムへ連携する

船会社への支払と、配車の予定の変更は、この構成からは行いません。 請求額は台帳に記録するだけで、支払は既存の手順で行います。引き取りの順番を入れ替えるのは、通関と配車の担当者と話した担当者です。

人が確認する

担当者が開くのは、ok 以外の印が付いたものです。 印の無いものは確認せず、台帳の値のまま扱います。human_check を「条件付き」としているのはこのためです。

1. at_risk を最初に片付ける … 通関の書類の不足か、配車の空きかを確かめ、引き取りの順番を決めます
2. eta_changed の最終日を確かめる … 改訂版の入港日で計算し直した最終日を、配車の担当者に伝えます
3. freetime_mismatch を船会社に確かめる … 記載と契約のどちらが正しいかを問い合わせます
4. needs_human の値を画像で確定させる … コンテナ番号や日付を確かめます

3番目を放置しないでください。 記載と契約が食い違ったまま期限を過ぎると、後で届くデマレージの請求で、どちらの日数で数えるかの話し合いになります。

例外に対処する

上から3行目と4行目が、期限の誤りのほとんどを生みます。 どちらも最終日という1つの値に効く問題で、ここを人に回す設計を崩すと、at_risk の印が当てにならなくなります。

記録を残す

• 元の到着案内と、受け取った日時、送り元、メールの件名
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（原文と解釈の両方）
• 入港日と最終日の履歴 … 改訂のたびに、いつ、何が、何から何に変わったか
• 照合の結果と、そのとき参照した条件の表の版
• 担当者が印を覆した記録と、船会社への問い合わせの回答

4つ目の履歴は、デマレージの請求を確かめるときの材料になります。 請求が届いたときに、当時の到着案内の入港日とフリータイムの記載をすぐ引ければ、請求の日数が正しいかを確かめられます。