輸出入の船積書類を突き合わせて、記載の食い違いを見つける

処理の起点を決める

トリガーは2つです。

1つ目は、専用メールアドレスへの着信です。n8n の Gmail トリガーは、設定したポーリング間隔で新着メッセージを検知して処理を開始します。仕入先には shipping-docs@ のような専用アドレスへ送ってもらいます。Gmail 以外を使う場合や、細かい条件で絞り込みたい場合は、HTTP Request ノードから各サービスのAPIを直接呼ぶ形にできます。

2つ目は、毎日朝の定期実行です。n8n の Schedule Trigger は、秒・分・時・日・週・月・cron式の7種類の間隔を設定できます。書類の未着チェックは、この定期実行で行います。 待っているだけでは気づけないためです。

なお、セルフホストの n8n では既定のタイムゾーンが America/New_York です。 環境変数で変更するか、ワークフロー側でタイムゾーンを設定してください。これを忘れると、朝8時のつもりが日本時間の夜に動きます。

入力データを集める

照合の基準はインボイスにします。 インボイスは取引の内容そのものを表す書類で、他の書類はインボイスの内容を前提に作られます。基準を決めずに全書類を総当たりで比べると、差異の数だけが増えて読めなくなります。

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

書類の種別判定： Document Intelligence のカスタム分類モデルを使います。分類モデルの学習にはクラスごとに最低5件、クラスは2つ以上が必要です。「インボイス」「パッキングリスト」「船荷証券」「航空運送状」「原産地証明書」「保険証券」「その他」の7クラスで組みます。

書類の種別は、多くの場合ファイル名（INV_xxx.pdf、PL_xxx.pdf）からも判定できます。ファイル名の規則が仕入先ごとに安定しているなら、まずそれを使い、判定できないものだけ分類モデルに回すほうが安く済みます。

項目の抽出： prebuilt-layout で表構造と見出しを取り出し、その結果をLLMに渡して項目を抽出させます。船積書類は表と自由記述が混在し、罫線のない様式も多いため、汎用の項目抽出モデルより、レイアウト情報を持たせてLLMに解釈させるほうが安定します。

信用状の条件： 銀行から受領した信用状のコピーから、必要書類・金額・期限などを抽出して構造化します。これは案件ごとに1回だけ行えばよく、以後の照合で繰り返し使います。

取引先マスタ： 社名の別表記（ABC TRADING CO., LTD. と ABC TRADING CO LTD）をそろえるために使います。

AIへ渡す前に整形する

1. 書類の分割 … 1つのPDFに複数の書類が入っていることがあります。分類モデルの判定がページ間で変わる箇所で分割します
2. 案件への紐付け … インボイス番号、注文番号、船荷証券番号のいずれかで既存案件に結び付けます。どれも当たらない場合は「未紐付け」として担当者に回します。推測で結び付けないでください
3. 単位の正規化 … 重量（KGS／MT／LBS／TON）、容積（CBM／M3／CFT）、数量（PCS／SETS／CTN／DRUM／PALLET）を基準単位に換算します。「TON」がメトリックトンかロングトンかは書類に明記されていないことがあるため、その場合は換算せず差異として挙げます
4. 日付書式の正規化 … 05/03/2026 は3月5日か5月3日か、書類だけでは決まりません。発行国の慣習で推測せず、他の書類の日付と矛盾しないかで判定し、判定できなければ差異として挙げます
5. 社名・住所の正規化 … CO., LTD. CO LTD COMPANY LIMITED、略称、旧社名をそろえます
6. 品名の対応づけ … インボイスの商品名、原産地証明書の品名、船荷証券の梱包記載を対応づけます。ここがもっとも難しく、LLMの出番になります

AIに処理させる

OCRとLLMで役割を分けます。

OCR（Document Intelligence）にさせること： 文字・表・見出しの読み取り。座標付きで返るため、差異の指摘に「どの書類の何ページのどこか」を添えられます。

LLMにさせること：

HSコード（関税分類）の判定はさせないでください。 原産地証明書に書かれたHSコードと、自社が申告に使っているHSコードが違う場合、それは差異として挙げます。しかし「どちらが正しいか」の判断はしません。 関税分類は法令の解釈であり、誤れば関税の追徴や事後調査の対象になります。ここは通関業者と自社の通関士の領域です。

同じ理由で、原産地の判定（特恵関税の適用可否）もさせません。 記載の不一致を指摘するところまでです。

指示内容を固定する

あなたは貿易事務を支援する担当者です。
1つの輸入案件について、複数の船積書類から項目を抽出し、
書類どうしの記載を突き合わせて、食い違いを報告してください。

【厳守事項】
- 書類に書かれていない項目を補わないでください。
  記載がない場合は null とし、missing に書類名と項目名を入れてください。
- 数値は、書類に印字されたとおりの値と単位をそのまま source_value に残し、
  換算後の値を normalized_value に入れてください。
  換算の根拠（1 MT = 1,000 KGS など）を basis に書いてください。
- 単位が「TON」のように、メトリックトンとロングトンの区別がつかない表記の場合は、
  換算せず、differences に「単位の特定不可」として挙げてください。
- 日付が DD/MM と MM/DD のどちらとも読める場合は、推測しないでください。
  他の書類の日付と矛盾しない読み方が1つに定まるときのみ確定とし、
  定まらない場合は differences に挙げてください。
- HSコードの正誤、原産地の判定、関税分類の解釈は行わないでください。
  記載が書類間で異なる場合に、差異として挙げるだけにしてください。
- 差異を挙げるときは、必ず「どの書類の、どの項目が、どう違うか」を
  書類名と項目名つきで示してください。
- 品名の対応づけは、同じ品目を指していると判断できる場合のみ行い、
  判断の根拠を basis に書いてください。

【照合の基準書類】
インボイス

【各書類の読み取り結果】
{documents}

【当社の発注データ】
{purchase_order}

【信用状の条件（信用状取引の場合のみ）】
{lc_terms}

【取引先マスタの別表記】
{company_aliases}

「換算の根拠を basis に書いてください」の1行が効きます。 換算結果だけを返されると、担当者はその換算が正しいかを確かめられません。根拠が書かれていれば、目で追えます。

「HSコードの正誤を判断しない」は必ず入れてください。 これを書かないと、それらしいHSコードの解説が返ります。読んだ担当者がそれを根拠に申告すると、関税の誤りにつながります。

出力形式を固定する

{
  "case_id": "",
  "documents_received": ["invoice", "packing_list", "bill_of_lading"],
  "documents_missing": ["certificate_of_origin"],
  "extracted": {
    "invoice": { "invoice_no": "", "shipper": "", "consignee": "", "incoterms": "", "currency": "", "total_amount": 0, "items": [] },
    "packing_list": { "net_weight": { "source_value": "", "normalized_value": 0, "unit": "KGS", "basis": "" } }
  },
  "differences": [
    {
      "item": "",
      "documents": [
        { "document": "", "page": 0, "source_value": "" }
      ],
      "type": "value | unit | format | missing | unmatched_item",
      "impact": "customs | letter_of_credit | payment | none | unknown",
      "explanation": "",
      "severity": "high | medium | low"
    }
  ],
  "po_match": "matched | mismatched | not_found",
  "lc_check": [
    { "condition": "", "result": "satisfied | not_satisfied | cannot_determine", "note": "" }
  ],
  "needs_review": []
}

source_value（書類に印字されたままの値）を必ず残します。これがないと、担当者が原本と突き合わせられません。 換算後の値だけでは、換算そのものが疑わしいときに追えなくなります。

impact に unknown を用意しているのは、影響度を無理に断定させないためです。判断できないものを none にされると見落とします。

システムへ連携する

通関業者への送付は自動化しないでください。 照合が済んでいても、送るかどうかは担当者の判断です。書類が不足したまま送ると、通関業者側で手戻りが発生します。

訂正依頼のメールも、下書きまでにします。 仕入先との関係に関わる連絡であり、文面の調整が要ります。英文の下書きがあるだけで、7分の連絡作業がかなり軽くなります。

人が確認する

全件、人が確認します。 ただし見る場所を絞ります。

信用状取引では、AIの照合結果を最終判断にしないでください。 信用状の条件は文言の細部まで意味を持ち、書類の不一致（ディスクレ）があると買取を拒まれます。AIの結果は「見落としを減らすための下敷き」として使い、条件との照合そのものは担当者が行ってください。

確認を速くするための設計が重要です。

• 差異の一覧に、該当箇所を原本PDF上でハイライトしたリンクを付ける
• 書類を左右に並べ、差異のある項目だけを色分けする
• 過去に「問題なし」と判断した種類の差異には、その履歴を表示する

例外に対処する

記録を残す

貿易書類は、関税法に基づく保存義務の対象になります。 この構成でも、次を残します。

• 受領した書類の原本（メールの受信日時と送信元を含む）
• 抽出結果（source_value を含む生の状態）
• 差異の一覧と、担当者の判断（訂正依頼した／問題なしとした）
• 訂正版の書類と、旧版
• 通関業者への送付記録
• 担当者が「問題なし」と判断した差異の内容と理由

最後の項目が、この構成の資産になります。「この仕入先のパッキングリストは総重量にパレット重量を含むため、船荷証券と50キロずれるのが常態」といった判断が蓄積すれば、それをプロンプトの前提に加えられます。 経験の差が縮まるのは、この蓄積によってです。