荷主から届く英文の危険物申告書（DGD）を読み取り、UN番号・等級・包装等級・数量を受託前の点検表に写して、記載漏れと予約との食い違いを拾う

処理の起点を決める

起点は、受付フォルダ（Amazon S3）にDGDが保存されたことです。 共有受信箱のルールで、登録した荷主から届いた「DGD」「Dangerous Goods」を含むメールの添付をS3へ転送し、保存の通知で AWS Lambda を動かします。

紙で持ち込まれたDGDも、受付の担当者がスキャンして同じフォルダに入れます。 経路を一つにまとめ、メールのものだけが下書きを持つ差を作りません。

毎朝8時にも1回動かし、 当日と翌日に搬入予定の貨物のうち、DGDが未着のものと needs_human のまま残っているものを担当者に送ります。

入力データを集める

質を決めるのは、いちばん下の2つです。 受託実績の一覧は、同じUN番号でいつもと違う組み合わせに気づくための材料で、規則そのものではありません。点検表の区分は下書きの範囲を決めます。チェックリストの13番目「包装物の個数および種類が記入されているか」は書類の項目、30番目「搬入された個数および容器の型式は危険物申告書と一致しているか」は現物の項目で、同じ「個数」でも別の項目として扱います。

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

DGDは AnalyzeDocument で1ページずつ読みます。 Document に1ページに分けたPDFのS3の場所を渡し、FeatureTypes に FORMS、TABLES、QUERIES を、QueriesConfig に質問の文と Alias の組を指定します。結果は Block の一覧で返り、キーと値は KEY_VALUE_SET、表は TABLE と CELL、質問の答えは QUERY_RESULT の Block です。

質問は英語の文書でしか使えず、同期の操作では1ページあたり15個までとされています。答えが見つからなければ空のまま返るので、全文から該当の語を含む行を探し、それでも無ければ missing にします。

品目の欄は、質問ではなく表として読みます。 1枚に複数の品目が並ぶことがあるためです。CELL を RowIndex、ColumnIndex でたどり、列の見出し（COLUMN_HEADER）が「UN or ID No.」「Proper Shipping Name」「Class or Division」「Packing Group」「Packing Inst.」のどれに当たるかで値を分けます。

各 Block の TextType（HANDWRITING／PRINTED）を必ず残します。 手書きで訂正された値は、チェックリストの24番目「修正または変更について荷送人の署名はあるか」に関わるため、印を付けて担当者に見せます。予約の台帳と受託実績の一覧は Python が読み、生成AIには渡しません。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。HEICなどの写真は JPEG に変換します
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは荷主に解除したものを頼みます
3. 1ページずつに分ける … 同期の操作はPDFとTIFFで1ページまで、10MBまでです。ページ番号を付けたまま分け、あとで1件にまとめ直します
4. 文字の大きさの確認 … 検出できる文字の高さの下限は15ピクセルで、150DPIで8ポイントの文字に当たるとされています。低い解像度のスキャンは取り直しを頼みます
5. 放射性の申告書を分ける … 「Radioactive」の欄を見て、放射性のものは担当者に直接渡します
6. 重複の検知 … 同じ運送状番号のDGDがあれば版を上げ、前の版との違いを並べて出します

6番目を省かないでください。 訂正したDGDの送り直しはよくあり、古い版の下書きが残ると、直る前の値で受託を決めることになります。

AIに処理させる

させるのは、OCRの結果から値を原文のまま取り出し、その値がDGDのどの欄の値かを記録することです。 照合と、規則に照らした判断はさせません。

包装等級と包装基準を not_stated にしているのは、品目によって書かない場合があるからです。 チェックリストでも包装等級の項目には「N/A」の欄があり、不備かどうかは担当者が決めます。

航空機の種類の欄は、消去の線が文字の検出に影響しないことが多く、両方の文字が読めても、どちらも消されていないとは限りません。 この欄は Lambda が Block の位置から切り出し、担当者の画面に画像で出します。

3行目がいちばん起きやすい失敗です。 分類の欄が空のDGDでも、生成AIはUN番号の一般的な分類を書き足しがちで、訂正を頼むべき記載漏れが消えます。

指示内容を固定する

あなたは航空貨物の混載業者の危険物の担当で、荷主から届いた
英文の危険物申告書（Shipper's Declaration for Dangerous Goods）の
記載を記録する立場です。OCRの読み取り結果だけを使ってください。
推測で埋めないでください。

【取り出す項目】
awb_no、page_no、shipper_raw、consignee_raw、origin_raw、
destination_raw、aircraft_field_texts（検出された文字の一覧）、
lines（配列：un_no_raw、proper_shipping_name_raw、technical_name_raw、
  class_raw、subsidiary_risk_raw、packing_group_raw、
  packages_count、package_type_raw、quantity、quantity_unit、
  gross_flag、packing_instruction_raw、authorization_raw）、
handling_info_raw、signatory_raw、signed_date_raw

【status の選び方】
- ok ............ 値が読み取れており、その欄の値として解釈できる
- missing ....... 書かれていない
- not_stated .... 包装等級・包装基準・承認の欄に記載が無い
- unreadable .... 文字は検出されているが値として確定できない
- ambiguous ..... 候補が複数ある、または値が途中で切れている
- unit_unknown .. 数量の単位が決まらない
- needs_visual .. 消去の有無など、画像で人が見る必要がある

【厳守事項】
- 書かれていない値を、他の欄やUN番号から補わないでください。
  分類・品名・包装等級を一般的な知識で埋めないでください。
- UN番号は「UN」「ID」の接頭と数字を、読み取った文字のまま
  入れてください。桁を補ったり、似た文字に直したりしないでください。
- 航空機の種類の欄と放射性の欄で、どちらが消去されているかを
  判定しないでください。status は常に needs_visual にしてください。
- 数量は、数値と単位と「G」の有無を分けてください。
  単位を換算しないでください。
- 手書きの値（text_type が HANDWRITING）は、そのことを
  handwritten に true として残してください。
- 分類や包装等級が正しいか、受託してよいかを書かないでください。
- DGDでない書類（安全データシート、インボイス、航空貨物運送状など）
  と判断した場合は、項目を取り出さず document_type に種類を
  書いてください。

【ページの並び】{page_order}
【読み取り結果（ページごと、TextType と信頼度付き）】{textract_result}

「UN番号から補わない」を明記しないと、補います。 生成AIは多くのUN番号の一般的な品名や分類を知っているためです。埋めた値が正しいかではなく、空欄だったという事実が消えることが問題です。

出力形式を固定する

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

{
  "file": "",
  "document_type": "dgd_non_radioactive",
  "awb_no": "000-00000000",
  "page_no": "1 of 1",
  "origin_raw": "NRT",
  "destination_raw": "FRA",
  "aircraft_field": { "status": "needs_visual", "texts": ["PASSENGER AND CARGO AIRCRAFT", "CARGO AIRCRAFT ONLY"] },
  "lines": [
    {
      "un_no_raw": "UN3481",
      "proper_shipping_name_raw": "Lithium ion batteries packed with equipment",
      "class_raw": "9",
      "packing_group_status": "not_stated",
      "packages_count": 2,
      "quantity": 4.2,
      "quantity_unit": "kg",
      "packing_instruction_raw": "966",
      "handwritten": false,
      "items": [ { "item": "un_no", "status": "ok", "confidence": 0, "source": "" } ]
    }
  ]
}

1つ目の理由は、照合をプログラムの側に置けることです。 Python が値の完全一致だけで印を付けます。

2つ目は、点検表の下書きを「書類」の項目だけに限れることです。 Python は点検表の区分を引き、「現物」と「判断」の項目には何も書かず、「YES」も書きません。 aircraft_field は常に needs_visual で、切り出した画像と予約した航空機の種類を並べて出します。

システムへ連携する

予約の台帳には書き込みません。 食い違っていても、どちらが正しいかは荷主に確かめるまで分からないためです。航空会社への通知や搬入の受付の仕組みにもつながず、受託の結果は担当者が次の工程に渡します。

人が確認する

資格を持つ担当者が、すべての下書きを原本と並べて確かめます。 human_check を「必須」としているのは、チェックリストが担当者の署名で完結する書類だからです。

1. booking_mismatch と missing を最初に片付ける … 搬入の前に荷主へ訂正を頼めるかで、予約した便に間に合うかが決まります
2. 航空機の種類の欄を画像で見る … 消去されている方を、予約した航空機の種類と比べます
3. pattern_differs と first_time を規則で確かめる … 分類・包装等級・包装基準の組み合わせを規則に照らします
4. 手書きの訂正を見る … 訂正の箇所に荷送人の署名があるかを確かめます
5. 書類の項目に「YES／NO／N/A」を付ける … 担当者が自分で付けます

3番目を省かないでください。 実績の一覧は「いつもと違う」に気づくための材料で、正しさの根拠ではありません。 目標は、240件をならして1件6分です。

例外に対処する

上から2行目は、読めないこと自体が点検の材料になる例です。

記録を残す

• 元のDGDと、受け取った日時、送り元、メールの件名、版の番号
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（原文と、項目ごとの status）
• 照合の結果と、そのとき参照した予約の台帳の値と、受託実績の品目の一覧の版
• 担当者が付けた「YES／NO／N/A」と、下書きの値を直した箇所
• 荷主への訂正の依頼と、訂正されたDGDとの対応

4行目で「そのときの予約の値」を残すのは、予約が後から変わるためです。 残さないと、なぜ印が付いたのかを後から説明できません。 5行目は、同じ欄が毎回直される荷主の書式を見つけ、質問の文を足す材料になります。