海外から新しい引合いが来たときに、過去の輸出取引の条件とクレームの記録から近い取引を検索し、見積の条件とリスクの根拠を示す

処理の起点を決める

担当者が引合いを検索画面に貼り、「過去の取引を探す」を押したときに動かします。 引合いには、すぐに断るもの、カタログを送れば済むものも混ざります。見積を検討すると担当者が決めたものだけを対象にします。

もう1つの起点は、取引の締めです。 出荷・請求・入金が終わった取引を、毎月の締めのあとに索引に足します。クレームはその後に起きることがあるので、品質保証部の報告書が保存されたときに、該当の取引の文書を更新します。 経理の回収の記録も、入金の消込が終わった時点で更新します。

取引の文書は、出荷したときに一度作り、後から足していく形にします。 入金とクレームが確定するまで待つと、直近の取引がいつまでも検索に出ません。

入力データを集める

質を決めるのは、3行目と4行目です。 条件だけの索引なら、販売管理システムの検索と大差がありません。結末が付いているから、見積の前に読む意味があります。

回収の記録は、遅れの日数だけを持たせます。 取引先の与信の情報そのものは、この索引に入れません。与信は経理と与信管理の担当の仕事で、営業の検索画面から見える必要はありません。

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

集計と検索は、同じ filter で行います。 上位10件の取引と、集計の母数が違う範囲だと、「上位に出た取引は全部 L/C なのに、分布では送金が多い」という読みにくい結果になります。 filter には地域・品目の分類・取引の年を入れます。

検索の形は、次のようになります。

POST /export-deals/_search?search_pipeline=deal-hybrid
{
  "size": 10,
  "_source": ["deal_id", "summary", "incoterm", "named_place", "payment_class",
              "packing", "claims", "collection_delay_days", "shipped_on"],
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "summary": "spindle bearing housing Middle East Jebel Ali 2 pallets" } },
        { "knn": { "summary_vector": { "vector": [0.0], "k": 30 } } }
      ],
      "filter": {
        "bool": {
          "filter": [
            { "term": { "region": "middle_east" } },
            { "term": { "product_class": "machine_parts" } },
            { "range": { "shipped_on": { "gte": "now-5y" } } }
          ]
        }
      }
    }
  }
}

集計は別の問い合わせで、size を0にして件数だけを取ります。terms 集計の missing を指定すると、項目が空の取引を1つのバケットにまとめて数えられます。 支払条件が台帳に入っていない取引が何件あるかが分かり、分布をどこまで信じてよいかの目安になります。

取引の索引の1件は、次のような形にします。

{
  "deal_id": "EX-2024-1187",
  "customer_class": "distributor",
  "region": "middle_east",
  "country": "AE",
  "port_of_discharge": "Jebel Ali",
  "product_class": "machine_parts",
  "weight_kg": 820,
  "incoterm": "CIF",
  "named_place": "Jebel Ali",
  "payment_class": "LC_AT_SIGHT",
  "packing": "wooden_crate",
  "transport": "sea_container_lcl",
  "claims": [
    { "type": "damage", "cause": "荷役中の木枠の破損", "cost_bearer": "insurer" }
  ],
  "collection_delay_days": 0,
  "summary": "",
  "summary_vector": [0.0],
  "shipped_on": "2024-11-05",
  "access_group": "overseas_sales"
}

AIへ渡す前に整形する

1. 取引の文書へのまとめ … 販売管理システム・契約書・クレームの報告・回収の記録を、取引番号で1つにします
2. 支払条件の区分へのそろえ … 「T/T 30 days after B/L」「net 30 B/L」などを TT_AFTER_BL_30 のような決まった区分にします。そろえられなかったものは OTHER にして原文を残します
3. 貿易条件の確認 … 貿易条件と場所（例：CIF Jebel Ali）を分けて持ちます。版（2020年版など）が契約書に書かれていれば一緒に持ちます
4. クレームの分類 … 報告書の本文から種類・原因・費用の負担を取り出します
5. 取引の要約と埋め込み … 条件と結末を200字程度の文にし、Titan Text Embeddings V2 で埋め込みを作ります
6. 取引先を特定する情報の扱い … 取引先の名前は取引先コードにし、担当者の名前と連絡先は入れません

2番目が、集計の質を決めます。 区分にそろえないまま集計すると、同じ条件が5つのバケットに割れます。区分の一覧は経理と決め、そろえる処理はプログラムで行います。 決まった言い方に当たらないものだけを、生成AIで区分の候補に当て、人が確かめます。

AIに処理させる

させるのは2つです。引合いから検索に使う項目を取り出すことと、検索と集計の結果から見積の条件の論点を並べることです。

AIの整理とは別に、引合いの希望の条件に対して、決まった規則で注意の印をプログラムが付けます。 規則は国際商業会議所の規則の文面に沿って、営業部と貿易の担当で決めます。

2行目を「させない」に置くのが、この設計で大事なところです。 AIに渡すのは上位10件の取引ですが、分布は数百件の母数から数えたものです。AIに数えさせると、上位10件の傾向を全体の傾向として書きます。

指示内容を固定する

あなたは専門商社の海外営業部で、見積を作る担当者のために、
過去の輸出取引の記録から見積の条件の論点を整理する立場です。
見積の条件を決めないでください。決めるのは担当者と課長です。

【やること】
1. 引合いの希望の条件と、検索で見つかった過去の取引を読んでください。
2. 次の論点ごとに、過去の取引から読み取れることを書いてください。
   貿易条件／支払条件／梱包／輸送／保険
3. 各論点に、根拠にした取引番号（deal_id）を必ず付けてください。
4. 分布を書くときは、渡された集計の件数をそのまま使ってください。
5. 近い取引で起きたクレームと回収の遅れを、取引番号付きで挙げてください。
6. 引合いの希望の条件が、過去の取引と違う点を挙げてください。

【厳守事項】
- 件数を自分で数えないでください。集計の結果に無い件数を書かないでください。
- 検索結果に無い取引番号を示さないでください。
- 引合いに書かれていない希望の条件を推測しないでください。「記載なし」としてください。
- 与信、制裁、輸出管理（該非）について判断を書かないでください。
  関係がありそうな場合は、確認先として「与信管理」「輸出管理」と書くだけにしてください。
- 貿易条件は、売手と買手の費用と危険の分担を決めるものです。
  支払条件や所有権の移転は貿易条件では決まらないので、別の論点として扱ってください。
- 根拠の取引が3件未満の論点は、confidence を low にしてください。

【引合い】{inquiry}
【検索結果（取引の文書、上位10件）】{deals}
【集計（同じ絞り込みでの件数）】{aggregations}

「件数を自分で数えない」を明記しないと、上位10件から割合を書きます。 集計の結果を渡していても、手元の取引のほうが具体的なので、そちらを数えたくなります。

「支払条件は貿易条件で決まらない」を書くのは、取り違えを防ぐためです。 貿易条件の規則は売買契約そのものではなく、支払の条件や、所有権の移転を扱いません。 「CIF だから代金は船積後」のような書き方をさせないために、論点を分けさせます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "inquiry": {
    "customer_code": "", "country": "", "port": "", "product_class": "",
    "quantity": "", "requested_incoterm": "", "requested_payment": "", "requested_delivery": ""
  },
  "issues": [
    {
      "topic": "incoterm | payment | packing | transport | insurance",
      "finding": "",
      "evidence_deals": [],
      "counts_used": "",
      "confidence": "high | low",
      "differs_from_request": ""
    }
  ],
  "risks": [
    { "deal_id": "", "type": "damage | shortage | quality | delay | collection", "summary": "" }
  ],
  "check_with": []
}

1つ目の理由は、論点ごとに根拠の取引番号を照らせることです。 evidence_deals の取引番号が検索結果に含まれているかを、プログラムで確かめます。 含まれていない番号があれば、その論点は表示しません。

2つ目は、counts_used で件数の出どころが分かることです。 AIが書いた件数が、集計の結果と一致するかをプログラムで照らします。一致しない論点は「件数の確認が要る」と印を付けて出します。

3つ目は、check_with で他の担当への確認が漏れないことです。 与信管理・輸出管理・品質保証部など、この構成の外で確かめることを一覧にします。

システムへ連携する

人が確認する

1. 根拠の取引を開く … 論点に付いた取引番号のうち、少なくとも上位の2〜3件は文書を開いて読みます
2. confidence が low の論点を慎重に扱う … 根拠の取引が少ない論点は、課長に相談します
3. check_with の確認先に回す … 与信・輸出管理の確認は、この検索の結果と関係なく行います
4. 課長がリスクの点を確かめる … 回収の遅れやクレームが出ている論点を中心に見ます
5. 見積の条件を担当者が決める … 過去と違う条件で出す場合は、理由を見積の記録に残します

1番目を省かないでください。 論点の整理は要約です。同じ港の損傷のクレームでも、木枠を変えてからは起きていない、という事情は文書を読まないと分かりません。

目標は、160件をならして1件12分です。 論点と根拠を読むのに6分、条件の案を作って課長に回すのに6分という見込みです。

例外に対処する

記録を残す

• 引合い（受け付けた日時、担当者）と、取り出した項目
• 検索の条件（filter、重み）と、上位の取引番号と点数
• 集計の結果
• Claude API の出力と、そのとき使った指示の版
• 表示しなかった論点と、その理由（取引番号の不一致、件数の不一致）
• 担当者が実際に出した見積の条件と、過去と違う条件にした理由

最後の行が、次の検索の質を上げます。 見積の条件と理由が残れば、その取引が締まったとき、条件と結末と当時の判断がそろった文書になります。