海外の販売代理店から届く英文の保証修理請求書を読み取って台帳に転記し、保証期間外・重複請求・部品単価の食い違いの疑いを拾う

処理の起点を決める

受付フォルダ（Amazon S3）に請求書が保存されたことを起点にします。 代理店は修理を終えたものから順に請求を送ってくるため、月末にまとめて流すより、届いたものから照らして疑いを出すほうが、照会の時間を確保できます。

請求の受け取り用のメールアドレスを代理店に案内しておき、添付を自動で受付フォルダへ保存する形にすると、担当者の保存の手間がなくなります。写真や作業報告が別のメールで届くこともあるので、請求番号で後から束ねられるようにします。

処理が終わった請求書は処理済みの場所へ移し、移すのは審査の一覧への書き出しまで成功したときだけにします。

入力データを集める

質を決めるのは、納入日の表と故障区分の一覧です。 納入日が無ければ保証の内外が照らせず、故障区分の一覧に英語の説明が無ければ、AIの対応付けが社内の区分とずれます。

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

読み取りは、Lambda から StartDocumentAnalysis を呼んで始めます。 文書はS3の場所で指定し、完了の通知先にSNSのトピックを渡します。ClientRequestToken に受付のファイルごとの値を入れると、同じ請求書の処理が二重に始まりません。JobId は7日間しか有効でないので、完了を受けたらすぐに GetDocumentAnalysis で結果を取り、自社のバケットへ書き出します。

質問は QueriesConfig に並べます。 1件ごとに Text（質問の文）と Alias（答えの名前）を持たせ、非同期の処理では1ページに30個まで使えます。

答えは QUERY_RESULT の塊として返り、質問の塊と ANSWER の関係でつながります。 答えにも信頼度が付きます。答えが見つからないときは、答えの要素が空のまま返ります。 空を「0」や「該当なし」に読み替えないことが大事です。

部品の表は、列見出しで列の意味を決めます。 表の塊には、列見出し・表の題・表の脚・合計のセルなどの種類が付いて返ります。合計の行（TABLE_SUMMARY）を部品の行として数えないように、セルの種類で外します。複数ページにまたがる表は、ページごとの表をつないでから渡します。

AIへ渡す前に整形する

1. 形式の確認 … 扱えるのはJPEG、PNG、PDF、TIFFです。XFA形式のPDFには対応していません
2. パスワードの確認 … パスワードで保護されたPDFは読めません。 代理店に保護のないものを送り直してもらいます
3. 解像度の確認 … 読み取れる文字の高さは15ピクセル以上（150dpiで8ポイント）。作業報告の手書きの小さな文字が、この下限に近いことがあります
4. 言語の切り替え … 代理店の一覧の書式の言語が英語なら QUERIES を入れ、それ以外は FORMS と TABLES だけにします
5. シリアルの正規化 … ハイフン・空白を外し、大文字にそろえます。元の文字列は残します
6. 数値と日付の正規化 … 代理店の一覧の書き方で、「1.250,00」や「03/04/2026」を自社の形に直します
7. 重複の検知 … 同じ代理店・同じ請求番号のものが既にあれば、再送の印を付けます

6番目はAIに任せません。 「03/04/2026」を3月4日と読むか4月3日と読むかは、代理店の国の書き方で決まります。 生成AIに決めさせると、もっともらしい方を選んで保証期間の内外がひっくり返ります。書き方は代理店の一覧で決め打ちします。

AIに処理させる

させるのは、読み取り結果を台帳の形にそろえ、部品の行を整え、故障の記述を社内の故障区分の候補に対応付けることだけです。

故障区分の候補を最大3つまで出させるのは、記述があいまいなことが多いからです。 「engine won't start」だけでは、燃料系か電気系かが決まりません。1つに決めさせると、もっともらしい方を選んで集計に偏りが出ます。

1行目がいちばん起きやすい失敗です。 故障日と納入日を一緒に渡すと、AIは頼まなくても月数を数えて「保証期間内」と書きます。納入日の報告が遅れているシリアルでは、その数え方の前提がずれていても気づけません。 だから納入日はAIに渡しません。

指示内容を固定する

あなたは機械メーカーの品質保証部で、海外の販売代理店から届いた
保証修理請求書を、社内の保証請求台帳の形にそろえる立場です。
渡すのは、OCRが返した読み取り結果と、社内の故障区分の一覧です。
そこに書かれたことだけを使ってください。

【書き出すこと】
1. 主要な項目: claim_no, model, serial_no, failure_date, repair_date,
   hour_meter, total_claimed
2. 部品の行: part_no, description, qty, unit_price, amount,
   role（causal_part / related_part / consumable / unknown）
3. 工賃の行: labor_description, hours, rate, labor_code
4. 出張費の行: distance, travel_hours, amount
5. 症状・原因・処置の原文と、故障区分の候補（最大3つ）とその根拠

【厳守事項】
- 書かれていない項目は「不明」としてください。推測で埋めないでください。
- 金額・日付・シリアル・部品番号は、読み取り結果の文字列のまま写してください。
  桁を補ったり、書き方を直したりしないでください。
- 金額を計算したり、合計を作り直したりしないでください。
- 保証期間の内外、重複かどうか、単価や工数が妥当かを書かないでください。
- 故障区分の候補は、渡した一覧のコードからだけ選んでください。
  当てはまるものが無ければ unclassified とし、新しい区分を作らないでください。
- 故障区分を1つに絞れないときは、無理に絞らず複数を挙げてください。
- role は記述から分かる範囲で付け、分からなければ unknown としてください。
- evidence には、根拠にした文字列をそのまま写してください。
- 保証修理請求書でない書類（見積、作業報告だけ、写真だけなど）と判断した
  場合は、そろえる作業をせず document_type に種類を書いてください。

【読み取り結果】{textract_result}
【故障区分の一覧】{failure_codes}
【この代理店の書式の言語】{form_language}

「渡した一覧のコードからだけ選ぶ」を書かないと、AIは新しい区分を作ります。 「Hydraulic seal failure」のような、それらしい名前の区分が台帳に増え、社内の区分で集計したときに数え漏れが出ます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とJSONスキーマを渡す）を使うと、スキーマどおりの形で返り、必須の項目が欠けません。

{
  "document_type": "warranty_claim",
  "claim_no": "",
  "dealer_code": "",
  "model": "",
  "serial_no": "",
  "failure_date": "",
  "repair_date": "",
  "hour_meter": "",
  "total_claimed": "",
  "parts": [
    { "part_no": "", "description": "", "qty": "", "unit_price": "",
      "amount": "", "role": "causal_part", "evidence": "" }
  ],
  "labor": [ { "labor_description": "", "hours": "", "rate": "", "labor_code": "" } ],
  "travel": { "distance": "", "travel_hours": "", "amount": "" },
  "failure": {
    "complaint": "", "cause": "", "correction": "",
    "code_candidates": [ { "code": "", "evidence": "" } ]
  }
}

この後に、Python が照合を足します。

1つ目の理由は、保証期間を規則で照らすことで、起算日の扱いをそろえられることです。 納入の報告が無いシリアルを needs_human にしておけば、出荷日から推し量るかどうかを担当者ごとに決める余地が無くなります。 推し量る規則を作るなら、それも規則の側に書きます。

2つ目は、price_diff と labor_over を差額と超過の時間で出せることです。 どこまでを許すかは、代理店との取り決めで決めます。

システムへ連携する

代理店への支払の登録には書き込みません。 審査の一覧までで止め、承認した金額の支払は既存の手順で行います。台帳への書き込みも、担当者が承認・一部承認・否認を決めたものだけです。 照合の途中の値を台帳に入れると、「審査中」と「確定」の区別が消えます。

人が確認する

人が開くのは clean 以外の請求です。 種類ごとに見る順を決めます。

1. duplicate_suspect を最優先で見る … 過去の請求番号と並べ、本当に同じ修理か、同じ部品が短い期間で再び壊れたのかを確かめます。後者なら、それ自体が品質の情報です
2. out_of_warranty を見る … 納入日の表が正しいかをまず疑います。納入の報告が遅れて届いていないかを海外営業に確かめます
3. price_diff と labor_over を見る … 差額と超過の時間を見て、代理店の説明を求めるか、許すかを決めます
4. 故障区分を確定する … 候補から選ぶか、別の区分にします。確定した区分だけを台帳に積みます

2番目で納入日を先に疑うのは、out_of_warranty の多くが納入の報告の遅れから出るからです。 代理店の在庫に長く置かれた機械は、出荷日から見ると保証の外でも、納入日から見ると内に入ります。否認する前に、起算日を確かめます。

目標は、240件をならして1件10分です。 clean は数分、duplicate_suspect や照会の要るものは20分以上かかる想定です。

例外に対処する

5行目と6行目は、どちらも「保証の外」と出かねない形です。 シリアルが表に無いのを「保証の対象外」と読むと、正しい請求を否認することになります。 代理店との関係に直接ひびくので、必ず人に回します。

記録を残す

• 元の請求書のPDFと添付、受け取った日時・送り元
• OCRが返したJSONの全文
• AIが返したJSONと、そのとき参照した故障区分の一覧の版
• 照合に使った納入日・価格表・標準の修理時間の版と、照合の結果
• 人が判定と故障区分を確定・変更した記録
• 代理店への照会と回答、承認した金額

「そのとき参照した版」を残すのは、価格表と保証の条件が後から変わるためです。当時の版が残っていないと、どの判定が正しかったかが決まりません。