外航貨物海上保険の事故で届く英文のサーベイレポートと船荷証券・インボイスを読み取り、保険金請求に要る項目と不足書類を洗い出して、請求書類一式の下書きを作る

処理の起点を決める

案件フォルダ（Amazon S3）にファイルが保存されたことを起点にします。 フォルダは事故の案件番号ごとに作り、担当者がメールの添付をそこへ保存します。保存のたびに、その案件の書類全体を見直します。 サーベイレポートが先に届き、運送人の回答書が2週間後に届く、という順番のばらつきがあるためです。

もう1つの起点は、毎朝の定時実行です。 書類が新しく届かなくても、事故の発見日からの日数を数え直し、不足が続いている案件を一覧にします。催促を忘れる失敗は、書類が届かないあいだに起きるからです。

入力データを集める

質を決めるのは、下から2つ目の表です。 ある保険会社は、損害見込額50万円未満の案件を想定した標準の必要書類として、保険証券（保険料請求書）、Invoice と Packing List、B/L または Air Waybill、損傷貨物の写真、入庫報告書または Devanning Report、運送人宛ての事故通知（Claim Notice）を挙げています。そのうえで、コンテナ船・在来船・航空便ごとに追加の書類を示しています。 この表を保険会社ごとに作り、輸送の形で行を切り替えます。

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

問いは、別名（Alias）を付けて登録します。 例えば What is the recommended amount of loss? に RECOMMENDED_LOSS、What is the B/L number? に BL_NO を付けます。答えは別名と信頼度つきで返り、答えが見つからないときは空で返ります。 空のまま後段に渡し、「書かれていない」として扱います。

問いの数には上限があります。 非同期の処理で1ページあたり30、同期で15です。サーベイレポートでは、問いをかけるページを最初の数ページと結論のページに絞り、残りは LAYOUT で取った本文から拾います。

B/L では、表の面の摘要の欄も取ります。 積み込みの時点で包装の傷みなどが書き込まれていることがあり、事故が輸送中に起きたかどうかの材料になります。ここは問いで取らず、FORMS と本文の文字列をそのまま渡します。 何を書き込みと見るかは、担当者と保険会社が決めます。

インボイスの貿易条件（CIF・FOB など）も取ります。 どちらが保険を手配する条件かで、請求する側が自社かどうかが変わるためです。取れなかったときは、販売管理システムの取引条件を担当者が見ます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG・PNG・PDF・TIFF であることを確かめます。XFA形式のPDFは扱えないため、印刷し直したPDFを依頼します
2. パスワードの確認 … パスワード付きのPDFは読めません。送り元に解除を頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 文字の大きさの確認 … 検出できる文字の高さは15ピクセル以上で、150dpiで8ポイントに当たります。写真を貼り込んだページの小さな注記は読めないことがあります
5. 言語の確認 … 本文が英文でないファイルは、読み取りに回さず「届いたかどうか」だけを記録します
6. 書類の束ねの分割 … 1つのPDFにB/Lとインボイスとパッキングリストがまとまって届くことがあります。ページごとに種類を判別してから、それぞれの機能に回します
7. 重複の検知 … 同じファイル名・同じページ数のものが二度保存されたら、版の違いとして扱います

6番目を軽く見ないでください。 インボイスのページをLAYOUTに回すと明細の表が崩れ、B/LのページをExpenseに回すと項目が OTHER ばかりになります。種類を先に決めてから機能を選びます。

AIに処理させる

1回目にさせるのは、読み取り結果を請求明細の項目へ並べ直すことです。

2回目にさせるのは、照合と不足の結果を受けて、下書きを作ることです。 請求明細（日本語）、保険会社宛ての送付状（日本語）、倉庫・フォワーダー宛ての不足書類の催促（日本語または英語）、事故通知が出ていない案件では運送人宛ての Claim Notice の下書き（英語）です。

3行目がいちばん起きやすい失敗です。 「雨水の浸入の可能性がある」という見立てを「雨水の浸入による」と要約すると、可能性の話が断定に変わります。 運送人へ賠償を求めるときの言い分にも響くので、原因は原文を引用で残します。

指示内容を固定する

あなたは貨物保険の担当として、保険金の請求書類をそろえる立場です。
渡すのは AWS Textract が英文の書類から読み取った結果です。
読み取り結果に書かれていることだけを使ってください。推測で埋めないでください。

【1回目：請求明細の項目への並べ直し】
- 各ページの書類の種類を、survey_report / bill_of_lading / invoice /
  packing_list / insurance_certificate / photo / other から選んでください。
- 項目ごとに value と、根拠にした英文（evidence）をそのまま写してください。
- 書かれていない項目は value を空にし、status を not_stated にしてください。
- 推奨損害額（recommended loss）は、書かれた数字と通貨をそのまま写してください。
  合計・単価・数量から計算して埋めないでください。
- 原因（cause of loss）は、サーベイヤーの英文をそのまま evidence に写し、
  value には和訳を1文で書いてください。「可能性」「推定」の表現を
  断定に変えないでください。
- 信頼度は Textract が返した値をそのまま confidence に入れてください。

【2回目：下書き】
- 照合の結果（{match_results}）と不足書類（{missing_docs}）を使って、
  請求明細、送付状、催促の下書きを作ってください。
- 食い違いがある項目は、下書きの中で値を選ばず「要確認」と書いてください。
- 事故通知の写しがない場合（{claim_notice_status}）は、運送人宛ての
  Claim Notice の英文の下書きを作ってください。事故の内容はサーベイ
  レポートの記載の範囲で書き、賠償の額は書かないでください。
- 保険金の額、支払の可否、運送人の責任の有無を書かないでください。

「可能性を断定に変えない」を明記しないと、和訳で言い切りになります。 英文の may have been を「〜による」と訳すのは翻訳としては自然に見えるため、指示で止めない限り毎回起きます。

出力形式を固定する

1回目の出力は、次の形のJSONで受け取ります。

{
  "case_id": "",
  "documents": [
    { "file": "", "page": 1, "doc_type": "survey_report" }
  ],
  "claim_items": [
    {
      "item": "recommended_loss",
      "value": "",
      "currency": "",
      "status": "ok | not_stated | low_confidence",
      "source_doc": "survey_report",
      "page": 0,
      "confidence": 0,
      "evidence": ""
    }
  ],
  "transport_mode": "container | conventional | air | unknown"
}

1つ目の理由は、照合をプログラムに渡せることです。 claim_items の B/L番号・コンテナ番号・数量・金額を、書類ごとに並べて文字列で比べます。結果は match ／ mismatch ／ one_side_only の3つで、AIはこの判定に関わりません。

2つ目は、transport_mode で必要書類の一覧を切り替えられることです。 一覧の表から、該当する行だけを引きます。

構造化出力では、スキーマのすべてのオブジェクトに additionalProperties: false を付けます。数値の範囲や文字列の長さの制約はスキーマで書けないため、金額の形の確認はプログラムで行います。

システムへ連携する

StartDocumentAnalysis には、同じ依頼を二度動かさないための識別子（ClientRequestToken）を付けます。 同じ識別子なら同じ JobId が返ります。保存のたびに見直す作りなので、同じファイルを二重に読ませない仕掛けが要ります。 結果の暗号化に KMS の鍵を指定でき、出力先のバケットも指定できます。

保険会社と運送人へは、自動では何も送りません。

人が確認する

担当者が見るのは、mismatch と one_side_only、low_confidence と not_stated の項目です。

1. mismatch を先に見る … B/L番号やコンテナ番号の1文字違いは、読み取りの誤りか書類の誤りかを、PDFの該当ページで確かめます
2. 推奨損害額を原本で確かめる … 請求の中心になる数字です。信頼度が高くても、必ずページを開きます
3. 原因の和訳を原文と見比べる … 「可能性」の表現が残っているかを見ます
4. 不足書類の一覧を確かめる … 輸送の形が正しく取れているか、保険会社の一覧の版が新しいかを見ます
5. 下書きを直して送る … 催促、事故通知、送付状のいずれも、送るのは人です

2番目を省かないでください。 推奨損害額を1桁読み違えた請求は、保険会社の照会で戻ってくるか、気づかれずに少ない額で協議が進みます。

目標は、25件をならして1件36分です。 確認の印が付く項目が1件あたり数項目という想定で、それより多い月は、特定のサーベイヤーのレポートの構成が問いと合っていないか、書類の束ねの分割が崩れています。 サーベイヤーごとに not_stated の数を数えておくと、どちらかが分かります。

例外に対処する

上から3行目までが、書類の受け取り方の問題です。 倉庫やフォワーダーに、PDFの形式と英文の報告書の提出をお願いしておくほうが、読み取りの精度を上げるより効きます。

記録を残す

• 受け取った書類のPDFと、受け取った日時
• Textract が返した読み取り結果の全文と JobId
• 1回目のJSON（項目、根拠の英文、信頼度）
• 照合の結果と、そのとき使った必要書類の一覧の版
• 2回目の下書きと、担当者が直したあとの送付版
• 催促を送った日と、書類が届いた日
• 案件ごとの、事故の発見日から保険会社へ一式を送るまでの日数

4つ目で一覧の版を残すのは、保険会社の必要書類が変わるためです。 どの版の一覧で「不足なし」としたかが残っていないと、後から追加の書類を求められたときに理由をたどれません。

最後の行は、この構成の効き目を測る数字です。 工数よりも、請求が出るまでの日数がどれだけ縮んだかのほうが、支払の早さに直結します。