英文の銀行保証状とスタンバイL/Cを読み取り、保証額・期限・請求の条件を与信台帳に転記して、契約との食い違いと期限切れ間近を拾う

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 保証状は契約の締結や前払金の支払に合わせて不定期に届くため、1日1回の定時実行にはしません。 受け取った日のうちに食い違いを営業へ返せば、出荷や前払金の支払の前に差し替えを頼めます。

入る経路は2つです。通知銀行から電子で届くPDFと、取引先から郵送された原本をスキャンしたPDFです。どちらも同じフォルダに入れ、ファイル名の先頭に取引先コードと契約番号を付けるところまでを人が行います。契約番号が付いていないファイルは、照合の相手を決められないので、処理を始める前に止めます。

S3 への保存を AWS Lambda が受け、StartDocumentAnalysis を呼びます。ClientRequestToken に契約番号とファイルのハッシュから作った値を入れると、二重に送っても同じ JobId が返り、同じ保証状を二度読みません。 JobTag には「新規」か「条件変更」かを入れます。完了は Amazon SNS に届き、SUCCEEDED を確かめてから結果を取り、すぐ S3 に保存します（JobId は7日間だけ有効です）。期限の見回りは、これとは別に毎朝、台帳の有効期限を相手に動かします。

入力データを集める

質を決めるのは、下の4つです。 最終の支払期日が無ければ「期限が足りるか」を言えず、受益者名の一覧が無ければ「Co., Ltd.」の有無だけで受益者が違うという印が付きます。

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

読み取りは StartDocumentAnalysis に FeatureTypes として FORMS、QUERIES、LAYOUT、SIGNATURES を指定して行います。全文の行と単語は、指定した機能にかかわらず返ります。 結果は GetDocumentAnalysis で取り、1回に返るブロックは既定で最大1,000件なので、NextToken が返る限り続けて取ります。

質問は QueriesConfig に並べ、別名（Alias）を付けます。非同期の処理では1ページあたり30問までです。公式の手引きは、日付が複数ある文書では「何の日付か」を特定して聞くことを勧めています。

質問は既定で1ページ目しか見ません。 ページの指定が無いと ["1"] になるため、**Pages に ["*"] を入れて全ページを対象にします。**

質問の答えは、そのまま採用しません。 発行日を拾うことがあるため、全文の中からも同じ値を探し、両方が一致したときだけ「読めた」とします。 請求の条件は質問で取りません。手引きは100語未満の答えになる質問を勧めており、数文にわたる条件は途中で切れます。 全文の行を段落で区切って生成AIに渡します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFは扱えないため、印刷し直してPDFにします
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。保護されたものは通知銀行に解除したものを頼みます
3. ページ数とサイズの確認 … 非同期の処理でPDFとTIFFは500MB・3,000ページが上限です。添付の契約書とまとめてスキャンされたものは、保証状の部分だけに分けます
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。原本は300 DPIでスキャンします
5. 言語の確認 … 英語以外の文が含まれていれば質問を外し、キーと値と全文だけで読みます
6. 新規か条件変更かの見分けと重複の確認 … 表題の「Amendment」「Extension」の有無で見分け、同じ保証番号・同じ版が既にあれば止めます

4番目を軽く見ないでください。 文字が小さくて読めないだけの条件は、「書かれていない」と区別がつきません。

AIに処理させる

させるのは、保証状の項目を原文のまま切り分け、請求の条件を1条件1行に分け、根拠の文字列を添えることだけです。

請求の条件の分解が、いちばん手間を減らすところです。 「書面で」「受益者の署名入りの陳述書を添えて」のように1条件1行を作り、元の英文を添えます。 ジェトロの解説でも、債務不履行が起きたことの証明書（通常は受益者のステートメント）が要求されるとされ、何を添えれば請求できるかが保全の中身そのものです。

3行目がいちばん起きやすい失敗です。 「URDG 758」とだけ書かれた保証状を渡すと、AIは規則の一般論から請求の手順を書き足し、本文の条件と食い違っても見た目では区別できません。 規則は名前だけを写させます。

指示内容を固定する

あなたは財務部の与信担当として、英文の銀行保証状またはスタンバイ信用状を読み、
与信台帳に登録するための項目を取り出します。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【取り出す項目】
1. 当事者と番号（保証番号、発行銀行、通知銀行、依頼人、受益者、保証の種類）
2. 保証額（通貨、上限額、減額の条件）
3. 効力と期限（効力が始まる条件、有効期限、期限の決め方）
4. 準拠規則と準拠法
5. 請求の条件（条件ごとに1行）
6. 譲渡と一部請求の可否

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- not_found .. その項目が書かれていない
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- original には、保証状の英文をそのまま写してください。
  言い換え、要約、綴りの修正をしないでください。
- 日本語の説明は note_ja にだけ書いてください。
- 日付の足し引きをしないでください。延長を頼む日や請求の期限を計算して書かないでください。
- 有効期限が日付ではなく出来事（例：前払金の全額の消化）で決まる場合は、
  expiry_type を event にし、出来事の原文を写してください。日付に直さないでください。
- 準拠規則は、書かれている名前と版をそのまま写してください。
  規則の一般的な内容から、請求の手順や期限を補わないでください。
- 書かれていない条件を補わないでください。「通常は」「一般に」で埋めないでください。
- 請求の条件は、1つの条件につき1行にしてください。
  1文に複数の条件が書かれているときは分け、split_from に元の文を写してください。
- 減額の条件は原文のまま写し、減額後の金額を計算しないでください。
- 受益者の名称は、書かれている綴りのまま写してください。自社名に直さないでください。
- 保証として有効か、十分か、差し替えを求めるべきかは書かないでください。
- これが条件変更の通知であれば、変更された項目だけを返し、amendment_no を入れてください。
- 英語以外の文が含まれていれば、language_note にその旨を書いてください。

【読み取り結果】{textract_result}
【段落ごとに区切った原文】{sections}
【文書の種類】{job_tag}

「日付の足し引きをしない」は、書かないと必ず破られます。 「30 days after the final payment due date」とあれば、AIは親切に日付を出し、支払期日が後で変わっても見た目では誤りと分かりません。

「受益者の名称を自社名に直さない」も同じ理由です。 AIが綴りを直せば、その食い違いが台帳から消えます。

出力形式を固定する

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

{
  "guarantee_no": "",
  "document_kind": "original | amendment",
  "amendment_no": 0,
  "instrument_type": "demand_guarantee | standby_lc | other",
  "fields": [
    { "item": "expiry", "status": "ok | not_found | unreadable | ambiguous",
      "value": "", "original": "", "confidence": 0, "note_ja": "" }
  ],
  "expiry_type": "date | event | not_found",
  "demand_conditions": [
    { "condition_type": "form | place | document | statement | timing | other",
      "original": "", "split_from": "", "note_ja": "" }
  ],
  "reduction_clauses": [ { "original": "", "note_ja": "" } ],
  "signature_detected": "yes | no",
  "language_note": ""
}

fields には当事者・保証額・期限・準拠規則・準拠法・譲渡・一部請求の項目を1つずつ並べます。

1つ目の理由は、AIの出力と照合の結果を別の層に置けることです。 JSONはAIが埋め、照合はプログラムが別の表に書きます。

2つ目は、期限をプログラムが毎日数えられることです。 expiry_type が date なら有効期限と最終の支払期日を比べ、期限が先に来るものに印を付けます。 延長を頼む日は「60日前」のように自社の規則で出します。event のものは、出来事が起きたかを営業に月1回確かめる一覧に回します。 original があるので、確認は1行ごとに英文と画像を見比べるだけで済みます。

システムへ連携する

与信台帳へは、人が確定するまで書き込みません。 「保証額が違う」と出ても、契約の側が変わった可能性もあるからです。台帳の保全の欄は保証1件につき1行、列は「保証番号／版／種類／保証額／有効期限／期限の決め方／準拠規則／請求の条件（原文へのリンク）／確定した人」とします。

人が確認する

人が確かめるのは、照合で印が付いた項目と、請求の条件の原文です。 match の項目は一覧で流し見ます。

1. needs_human を先に見る … 読めなかった項目と候補が複数ある項目です。画像を開いて値を確定します
2. 請求の条件の行を、原文と画像で見比べる … 1条件1行に分けたときに、書類と記載文言が別の行に紛れていないかを見ます
3. mismatch と not_in_contract を営業に渡す … 営業担当が、差し替えを頼むか、条件を受け入れて与信限度額の側を見直すかを決めます
4. 署名の印を見る … signature_detected が no のものは、原本の署名欄を目で確かめます
5. 確定の印を付ける … 確定したものだけが、与信台帳に保全として載ります

2番目を省かないでください。 請求の条件は、保証を使う日まで誰も読み返しません。

例外に対処する

上から3行目までが大半を占めます。 どれも受け取り方の問題で、通知銀行に電子で送ってもらう取り決めが効きます。

記録を残す

• 元の保証状と条件変更のPDF、受け取った日時と経路
• AWS Textract の結果のJSON全文と JobId
• Claude API の出力（fields、demand_conditions、reduction_clauses）
• 照合に使った契約の条件の値と、照合の結果
• 期限の計算に使った値と規則、通知を送った日時と相手
• 人が値を直した記録と、確定した版・確定した人・日時

4つ目で「そのときの契約の条件」を残すのは、契約が後から変わるためです。