コンテナのリース会社が海外のデポから届く英文の修理見積（EOR）を読み取り、損傷の箇所・修理の内容・金額を修理の基準と単価表に照らして、過大な見積と利用者の負担の区分を拾う

処理の起点を決める

デポごとの受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 フォルダは eor/<デポコード>/ の形にし、どのデポの見積かを保存した場所で決めます。 見積の見出しのデポ名から決めると、同じ会社の別の港のデポと取り違え、別の単価表を引きます。

読み取りを始めるとき、ClientRequestToken に「デポコード＋見積番号＋改訂の番号」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。保存の時点では見積番号が分からないので、ファイル名に担当者が見積番号を付けて保存する運用にします。

完了は Amazon SNS の通知で受け、JobTag に入れたデポコードと見積番号で、どの見積かを知ります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存します。

否認や出し直しの依頼の後、デポから改訂の見積が届きます。 同じ見積番号で改訂の番号が上がったものは、前の版と行ごとに並べ、変わった行だけを確かめどころにします。

入力データを集める

質を決めるのは、標準の工数表です。 IICLの指針では、部位・損傷・修理のコードの組み合わせの推奨は、IICLの Equipment Code Standards（ECS）の文書にまとめられているとされています。自社の工数表をこのコードの組み合わせに合わせておくと、どのデポの見積でも同じ表で引けます。

リースの契約の条件には、保険の制度の扱いを必ず入れます。 見積の見出しには保険の制度の対象かの欄があり、負担者のコードにも保険の制度（I）があります。対象のコンテナで利用者の負担の行が並んでいたら、契約の上限と照らす必要があります。

コードの表の「文での書き方の例」は、コードの無い行の当てはめに使います。 「Replace floor board」「Renew floorboard」「F/B replace」のような書き方を、床板の交換のコードの行に並べておきます。

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

見出しの項目は、キーと値の組で取り、問い合わせで補います。 IICLの指針が示す見積の形には、コンテナ番号、デポ、機器の種類、返却の日付、見積番号、改訂の番号、作業の単価、見積の通貨、保険の制度の対象かなどの見出しの項目があります。ただし、指針は「リース会社ごとに見積の項目と形は違う」としているので、デポごとに見出しの言い方の一覧を持ちます。

**問い合わせには Pages: ["*"] を付けます。 ページを指定しないと既定で1ページ目だけに当てるとされ、2ページ目の見出しの項目が取れません。結果は NextToken が返る限り GetDocumentAnalysis を呼び続け、全ページ分をそろえてから組み立てます。**

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFとパスワードで保護されたPDFは扱えないとされています
2. コンテナ番号の確認 … 4文字の英字と6桁の数字と確認の数字の形かを確かめ、確認の数字を計算して照らします。合わない番号は、読み取りの誤りか見積の書き間違いとして人に回します
3. 位置のコードの形の確認 … IICLの指針では、位置のコードは4文字で、1文字目が面（右側・左側・屋根・床・前面・扉・下部構造など）、2文字目が区画を表すとされています。形に合わないコードは、読み取りの誤りとして印を付けます
4. 数字の確かめ … 工数×作業の単価が作業費と合うか、作業費＋材料費が行の合計と合うかを、行ごとに計算します
5. 手書きの追記の印 … 単語の TextType が手書きのものに印を付けます

2番目を軽く見ないでください。 番号を1文字読み違えると、別の利用者に貸し出したコンテナの見積として扱い、別の利用者に請求することになります。 確認の数字で読み取りの誤りの多くを止められます。

AIに処理させる

させるのは、コードの無い行と、コードと文が食い違う行に、自社のコードの表から候補を当てはめることだけです。

備考の区分は、負担者を決めるためではありません。 「forklift damage」と書かれていれば、損傷の原因として荷役を挙げたという事実を書き出すだけです。その損傷を利用者の負担とするかは、契約の条件と承認の担当が決めます。

5行目がいちばん起きやすい失敗です。 「Straighten side panel」とだけ書かれた行に、AIは一般的な寸法を補いがちです。標準の工数は寸法の範囲で決まるので、補った寸法で工数を引くと、過大な見積を見逃します。 寸法が無い行は、そのまま確かめどころにします。

指示内容を固定する

あなたはコンテナのリース会社で、海外のデポから届いた修理見積の行を
整理する担当者を手伝います。
渡された「行の一覧（行番号・部位・位置・損傷・修理のコード・作業の文・備考）」と
「コードの表（コード・説明・文での書き方の例）」だけを見てください。

【やること】
- コードの欄が空の行には、作業の文からコードの表の部位・損傷・修理のコードを選び、
  suggested_codes に入れてください。
- コードがある行で、作業の文がそのコードの説明と明らかに合わない場合は、
  code_text_conflict に true を入れてください。
- 備考の文について remark_type を次のどれかで付けてください。
  handling ...... 荷役・フォークリフトなどによる損傷と書かれている
  cargo ......... 貨物による損傷・汚れと書かれている
  accident ...... 事故・衝突と書かれている
  wear .......... 長年の使用による損耗・腐食と書かれている
  prior_repair .. 以前の修理の不良と書かれている
  none .......... 備考が無い
  unclear ....... 上のどれかを文から決められない
- evidence に、判断に使った文をそのまま写してください。

【厳守事項】
- コードの表に無いコードを書かないでください。
- 工数や金額を計算しないでください。
- 寸法や数量が書かれていない行に、値を補わないでください。
- 利用者の負担か所有者の負担かを書かないでください。
- 迷ったときにコードを選ばないでください。unclear にしてください。

「利用者の負担か所有者の負担かを書かない」を明記しないと、AIは備考から負担者まで書きます。 「rust」とあれば所有者の負担と書きがちですが、錆の原因が貨物の液漏れなら、契約によっては利用者の負担です。 備考は事実の区分までにとどめます。

出力形式を固定する

AIの出力は、Claude API の構造化出力で形を決めて受けます。 公式のページでは、output_config.format に JSON スキーマを渡すと、スキーマに合う JSON が返るとされ、正式提供の機能です。コードは自社のコードの表の値を列挙した型にします。数値の minimum／maximum などの制約はスキーマに書けないとされているので、値の範囲はプログラムで確かめます。

{
  "estimate_no": "D-SGP03/E-26-1182/R0",
  "rows": [
    { "row_no": 4, "text": "Replace floor board 2 pcs",
      "suggested_codes": { "component": "FLB", "damage": "BR", "repair": "RP" },
      "code_text_conflict": false, "remark_type": "handling",
      "evidence": "Replace floor board 2 pcs / forklift damage" }
  ]
}

プログラムは、これに照合の結果を足して点検の結果にします。

{
  "unit_no": "ABCU1234560", "check_digit_ok": true,
  "lessee": "L-0031", "labor_rate": { "estimate": 28.00, "agreed": 25.00 },
  "lines": [
    { "row_no": 4, "party": "U", "hours": 2.0, "std_hours": 1.5,
      "flags": [ "labor_rate_over", "hours_over_std", "ai_mapped_code" ] }
  ],
  "totals_ok": true
}

形を分けるのは、当てはめと照合を別の層に置くためです。 rows はAIが埋め、lines の flags はプログラムが決めます。単価表や工数表を直しても、当てはめをやり直さずに照合だけやり直せます。

システムへ連携する

機器の管理の仕組みとデポへの返事は、人が行います。 点検の結果がそのまま否認になると、取り決めの単価表が古かっただけの見積まで否認し、修理が止まってコンテナを貸し出せなくなります。

人が確認する

1. check_digit_ok が false のものを先に見る … コンテナ番号を原本で確かめます
2. party_check を確かめる … 返却の検査の記録と契約の条件を見て、負担者を決めます
3. labor_rate_over・material_over・hours_over_std を確かめる … 超過を認めるか、否認するかを決めます。認めた理由を記録に残します
4. ai_mapped_code の行を原本で確かめる … 当てはめたコードが作業の文と合うかを見ます
5. デポに返事をする … 承認・一部の否認・出し直しの依頼を返します

例外に対処する

4行目が、この構成で最も守りたいことです。 取り決めが無いデポの見積を、ほかのデポの単価で照らすと、それらしい超過の印が付き、正当な見積を否認することになります。 取り決めが無ければ単価の印を出しません。

記録を残す

• 修理見積の原本と、保存した場所（デポ・見積番号・改訂の番号）
• Textract が返した結果の全文と、組み立てた行の一覧
• AIの当てはめと備考の区分の結果、根拠の文
• 照合の結果（flags）と、そのとき使った単価表・工数表・契約の条件の版
• 承認の担当の決定 … どの行を承認・否認し、超過を認めた理由は何か
• デポへの返事と、改訂の見積との対応

5つ目の記録は、承認の基準を文書にする材料になります。 超過を認めた理由が積み上がれば、どの程度の超過をどの条件で認めるかを、工数表の幅として決め直せます。