海外の銀行から届く英文の信用状を読み取り、期限・要求書類・特記条件を輸出の書類チェックリストに転記して、契約と食い違う条件を船積前に拾う

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 信用状は買い手の都合で不定期に届くため、1日1回の定時実行にはしません。 船積期限まで日数の少ない信用状ほど、受け取った日のうちに食い違いを営業へ返す必要があるからです。

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

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

入力データを集める

質を決めるのは、下の3つです。 契約上の船積期限が無ければ比べられず、これまでの版が無ければ条件変更を重ねられません。書類の作り方の一覧が無ければ、外部に頼む書類に印が付かず、手配が遅れます。

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

読み取りは StartDocumentAnalysis に FeatureTypes として FORMS、TABLES、QUERIES、LAYOUT を指定して行います。全文の行と単語は、指定した機能にかかわらず返ります。

質問は QueriesConfig に並べ、それぞれに別名（Alias）を付けます。非同期の処理では1ページあたり30問までなので、次のように絞ります。

金額の過不足の許容、積替えの可否、船積港も同じ形で足します。質問の答えは、そのまま採用しません。 見出しの書き方が変わると別の箇所を拾うことがあるため、全文の中からも同じ値を探し、両方が一致したときだけ「読めた」とします。

要求書類と特記条件は、質問で取りません。 数十行の要求を短い答えで取ると途中で切れます。全文の行を LAYOUT の見出しで区切り、欄ごとの原文をそのまま生成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」の有無で見分け、同じ信用状番号・同じ版が既にあれば止めます

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

AIに処理させる

させるのは、信用状の項目を原文のまま切り分け、要求書類を1書類1行に分け、根拠の文字列を添えることだけです。

要求書類の分解が、いちばん手間を減らすところです。 「インボイス、署名入り、原本3通、信用状番号の記載」のように書類1つにつき1行を作り、元の英文をそのまま添えます。

1行目と3行目が、いちばん起きやすい失敗です。 船積期限と呈示期間を読んだAIは、頼まなくても「書類の提出期限は○月○日」と書き足します。その日付は、有効期限との前後を見ていないことがあります。 計算そのものを禁じ、計算に要る値だけを返させます。

指示内容を固定する

あなたは輸出の貿易事務の担当として、英文の信用状を読み、
船積書類のチェックリストを作るための項目を取り出します。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【取り出す項目】
1. 基本情報（信用状番号、発行銀行、通知銀行、受益者、発行依頼人）
2. 期限と場所（有効期限と場所、船積期限、呈示期間）
3. 金額（通貨、金額、過不足の許容）
4. 船積の条件（船積港、仕向港、分割船積、積替え、貿易条件）
5. 要求書類（書類ごとに1行）
6. 特記条件（条件ごとに1行）
7. 手数料の負担

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

【厳守事項】
- original には、信用状の英文をそのまま写してください。
  言い換え、要約、綴りの修正をしないでください。
- 日本語の説明は note_ja にだけ書いてください。original を日本語に置き換えないでください。
- 日付の足し引きをしないでください。書類の提出期限を計算して書かないでください。
  期限に関する値は、書かれている文字列のまま返してください。
- 書かれていない条件を補わないでください。「通常は」「一般に」で埋めないでください。
  書かれていなければ status を not_found にしてください。
- 要求書類は、1つの書類につき1行にしてください。
  1文に複数の書類が書かれているときは分け、split_from に元の文を写してください。
- 通数は「ORIGINAL」「COPY」「IN TRIPLICATE」などの原文の語を copies_text に写し、
  数に直した値を copies_original と copies_copy に入れてください。
  直せないときは数を空にしてください。
- 特記条件が、どの書類に関する条件かを applies_to に書いてください。
  決められなければ unknown にしてください。
- 条件を満たせるか、買い手に変更を頼むべきかは書かないでください。
- これが条件変更の通知であれば、変更された項目だけを返し、amendment_no を入れてください。
- 英語以外の文が含まれていれば、language_note にその旨を書いてください。

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

「日付の足し引きをしない」は、書かないと必ず破られます。 呈示期間が「21 DAYS AFTER THE DATE OF SHIPMENT」と書かれていれば、AIは親切に日付を出します。その日付が有効期限より後なら誤りですが、見た目では分かりません。

「通数を原文の語で写す」のも同じ理由です。 「2/3 SET」のような書き方を数に直すと解釈が入るため、原文の語と数を並べ、直せないときは空にさせます。

出力形式を固定する

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

{
  "lc_number": "",
  "document_kind": "original | amendment",
  "amendment_no": 0,
  "fields": [
    { "item": "expiry", "status": "ok | not_found | unreadable | ambiguous",
      "value": "", "original": "", "confidence": 0, "note_ja": "" }
  ],
  "documents_required": [
    { "doc_type": "commercial_invoice", "original": "",
      "copies_text": "", "copies_original": 0, "copies_copy": 0,
      "must_state": [""], "signed": "yes | no | not_stated",
      "split_from": "", "note_ja": "" }
  ],
  "additional_conditions": [
    { "original": "", "applies_to": "", "note_ja": "" }
  ],
  "language_note": ""
}

fields には期限・金額・港・船積の条件・手数料の項目を1つずつ並べます。

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

2つ目は、書類を出せる最終日をプログラムが計算できることです。 船積日はまだ決まっていないため、「船積期限の日に船積した場合の最終日」を出します。呈示期間が書かれていればその日数、書かれていなければ船積後21日とし、有効期限と比べて早いほうを最終日とします。 計算に使った値と規則を、結果と一緒に残します。

3つ目は、original があることで、1行ごとに元の英文と画像を見比べるだけで確認が済むことです。

システムへ連携する

受注台帳には書き込みません。 照合の結果が「金額が違う」と出ても、どちらが正しいかはまだ分からないからです。台帳を直すのは、営業が買い手と話して決めた後です。

チェックリストは書類ごとに1行、列は「書類の種類／原文／通数／記載文言／署名／作る人／確認済みの印」とします。

人が確認する

人が確かめるのは、照合で印が付いた項目と、要求書類・特記条件の原文です。 match の項目は値を一覧で流し見ます。全文を読み直す設計にすると、第10章の12.0時間には収まりません。

1. needs_human を先に見る … 読めなかった項目と候補が複数ある項目です。画像を開いて値を確定します
2. 要求書類の行を、原文と画像で見比べる … 1書類1行に分けたときに、通数と記載文言が別の行に紛れていないかを見ます
3. mismatch と not_in_contract を営業に渡す … 営業担当が、条件変更を頼むか、条件に合わせて自社の手配を変えるかを決めます
4. 最終日の計算を確かめる … 使った値と規則を、有効期限の場所とあわせて見ます
5. 確定の印を付ける … 確定したチェックリストだけが、フォワーダーと書類担当に渡ります

2番目を省かないでください。 書類を作る人はチェックリストしか見ません。

例外に対処する

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

記録を残す

• 元の信用状と条件変更のPDF、受け取った日時、通知銀行の通知番号
• AWS Textract の結果のJSON全文と JobId
• Claude API の出力（fields、documents_required、additional_conditions）
• 照合に使った受注台帳の値と、照合の結果
• 書類を出せる最終日の計算に使った値と規則
• 人が値を直した記録 … どの項目を、何から何に直したか
• 確定したチェックリストの版と、確定した人・日時

4つ目で「そのときの台帳の値」を残すのは、台帳が後から変わるためです。 契約の条件を変えた後で台帳を直すと、当時なぜ mismatch だったのかが分からなくなります。