カード会社の加盟店向けの担当が、EC加盟店から集めた注文・配送・認証の記録を Azure OpenAI で照会の理由に照らして整理し、チャージバックへの反論の資料の下書きと足りない証跡の依頼文を作る

処理の起点を決める

起点は2つあります。 1つ目は、案件管理に新しい照会が登録されたときで、依頼文の下書きを作ります。2つ目は、加盟店が管理画面から記録を提出したときで、当てはめと資料の下書きを作ります。どちらも Azure Functions が案件管理と管理画面の状態を10分ごとに見て拾います。

期限が近いものから処理します。 照会ごとに期限を取り、残りの日数が少ないものを先に並べ、加盟店からの提出が無いまま期限が迫っているものは担当者に知らせます。 Visa の手引きは、期限は依頼に示されたとおりで、アクワイアラによって異なりうるとしています。期限は案件管理に入っている日付だけを使い、AIに計算させません。

加盟店が追加の記録を出したときも、もう一度動かします。 前回の当てはめとの差（満たされた項目、まだ足りない項目）を出します。

照会の登録から依頼文の下書きまでは、その日のうちに終わらせます。 加盟店が記録を探して出すまでに数日かかることが多く、依頼が1日遅れると、そのまま資料を作る時間が1日減ります。 夜間に届いた照会は、翌朝の始業時に依頼文の下書きがそろっているようにします。

入力データを集める

過去の取引の照合はプログラムで行います。 Visa の手引きでは、カード非対面の不正の申し出に対し、紛争の120〜365日前に決済された、不正として報告されていない2件以上の取引で、端末の識別・端末のフィンガープリント・IPアドレスのいずれかと、もう1つ以上の項目が同じであることを示す記録が挙げられています。日数の数え方と項目の一致は機械で確かめ、AIには結果だけを渡します。

理由によって、効く記録はまったく違います。 商品の未着の申し出なら、配送の追跡番号と配達の記録、届け先が注文の届け先と同じであることが中心です。キャンセルの申し出なら、キャンセルの受付の有無と、注文の時点で示していたキャンセルの条件です。同じ加盟店の同じ注文でも、理由が変われば出すべき記録が変わるので、依頼文は必ず理由のコードから作ります。

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

1. 照会と証跡の一覧 … 案件管理から照会を取り、理由のコードで証跡の一覧を引きます
2. 決済の記録 … 取引の番号で、承認・売上・3Dセキュアの認証の結果を取ります
3. 加盟店の記録 … 管理画面に提出されたファイルと入力欄の内容を取ります。画像やPDFは、既存の読み取りの仕組みで文字のデータにしてから渡し、原本は添付として残します
4. 過去の取引 … 加盟店から出たログインID・端末の識別・IPアドレス・届け先で、同じ加盟店の過去の取引を引き、日付と一致した項目を出します

3番目で、加盟店に出してもらう形をそろえるのが効きます。 管理画面の提出の窓口を、「注文」「配送」「認証・ログイン」「問い合わせ」「返金」の欄に分けておけば、記録の種類をAIに推し量らせる必要がなくなります。

配送の記録は、加盟店に配達完了の記録を出してもらいます。 カード会社の側から配送業者のサイトを見に行って取る作りにはしません。追跡の画面の表示は配送業者によって違い、保存の期間も限られるので、加盟店の手元にある記録を証跡として出してもらうほうが確実です。

AIへ渡す前に整形する

1. 伏せ字 … カード番号は下4桁以外を伏せ、カード会員の氏名・住所・電話番号は「Cardholder」「Delivery address A」に置き換えます。届け先の一致はプログラムが元の値で確かめ、結果だけを渡します
2. 添付番号の付与 … 記録ごとに Ex.1、Ex.2…を振り、種類・日付・ファイル名の一覧を作ります
3. 言語の印 … 記録が日本語か英語かを付けます
4. 重複の除去 … 同じ記録が2回出されていれば1つにします
5. 読み取りの印 … 画像から読み取った文字のデータで信頼度の低いものに印を付けます

1番目は、外部のサービスに渡す範囲を絞るための処理です。 反論の資料に必要なのは「届け先が一致した」という事実で、届け先そのものではありません。

2番目の添付番号は、回答のときの添付の並びと同じにします。 資料の本文で「Ex.3 shows…」と書いた番号が、実際に回答に付ける添付の順と違うと、読み手は根拠を見つけられません。番号は前処理で一度だけ振り、AIにも担当者にも振り直させません。

AIに処理させる

表の3行目を入れておくのが大事です。 加盟店の記録に「返金処理済み」の画面が入っていれば、反論の資料を作る前に受け入れを検討すべきです。AIに反論の資料だけを作らせると、受け入れるべき照会にも立派な資料ができてしまいます。

たとえば、利用の否認（Condition 10.4）で、決済の記録に3Dセキュアの認証の成功があり、過去の取引の照合で、同じ端末の識別とログインIDの取引が2件見つかった場合です。AIは「認証の記録」に Ex.2、「過去の取引」に Ex.5・Ex.6 を当て、それぞれが何を示すかを1文ずつ書きます。 配送の記録が出ていなければ、それは足りない項目として残ります。反論にそれで足りるかは、担当者が規則を見て決めます。

指示内容を固定する

あなたはカード会社のチャージバック対応の担当を補助します。
加盟店から出された記録を、渡す「証跡の一覧」に当てはめ、
足りない項目と、反論の資料または追加の依頼文の下書きを作ります。
反論するか受け入れるかは決めません。

【させること】
1. 証跡の一覧の各項目について、満たす記録があれば exhibits に添付番号を入れ、
   その記録が何を示すかを1文で書いてください。
2. 満たす記録が無い項目は missing_items に入れてください。
3. 受け入れを検討する項目に当たる記録があれば acceptance_signals に入れて
   ください。
4. missing_items があるときは、加盟店への依頼文を日本語で書いてください。
   出してほしい記録の例を挙げてください。
5. missing_items が無いときは、英文の反論の資料を書いてください。
   取引の概要、反論の要点、添付ごとの説明の順にしてください。

【厳守事項】
- 記録に書かれていないことを書かないでください。配達完了、認証、
  利用規約への同意、本人による利用などを推測で補わないでください。
- 日付・追跡番号・金額・IPアドレスの国などの値は、記録から写し、
  quoted_values に記録の添付番号とともに入れてください。
- カード会員の申し出がうそだと書かないでください。
- 反論が通る、勝てる、といった見込みを書かないでください。
- 「読み取り不確か」の印がある記録だけに基づく項目は、満たしたことに
  せず missing_items に入れ、理由に「読み取り不確か」と書いてください。

【照会】{dispute}
【証跡の一覧（版：{checklist_version}）】{checklist}
【決済の記録】{payment_record}
【過去の取引の照合結果】{prior_match}
【加盟店の記録（添付番号付き）】{exhibits}

「カード会員の申し出がうそだと書かない」を入れるのは、資料の調子のためです。 反論の資料は、取引が正しく行われた記録を並べるもので、相手を責める文書ではありません。記録の事実だけを並べた資料のほうが、読み手に伝わります。

「読み取り不確か」の扱いを指示に入れるのは、満たしたことにする誤りを防ぐためです。 配達完了の画面の写しがぼやけていて、日付の数字が読み取りで別の数字になっていることがあります。それを根拠に「合意した日に届いた」と書けば、資料の事実が崩れます。 読めないものは足りない項目に戻し、加盟店に読める形で出し直してもらいます。

出力形式を固定する

{
  "dispute_id": "",
  "reason_code": "10.4",
  "checklist_version": "",
  "matched_items": [
    { "item": "3ds_authenticated", "exhibits": ["Ex.2"], "what_it_shows": "" }
  ],
  "missing_items": [
    { "item": "", "reason": "" }
  ],
  "acceptance_signals": [
    { "item": "", "exhibits": [""], "note": "" }
  ],
  "quoted_values": [
    { "exhibit": "Ex.3", "field": "tracking_number", "value": "" }
  ],
  "merchant_request_ja": "",
  "response_draft_en": ""
}

1つ目の理由は、quoted_values をプログラムで照合できることです。 追跡番号や日付が、指定した添付の文字のデータにそのまま含まれているかを確かめ、一致しない値があれば資料を担当者に回す前に印を付けます。

2つ目は、acceptance_signals で受け入れの検討を先に出せることです。 1件でもあれば、案件管理の一覧で「受け入れの検討」として目立たせます。

3つ目は、資料と依頼文を同じ当てはめから作れることです。 依頼文で頼んだ項目と、資料で満たした項目が、同じ証跡の一覧の言葉でつながります。

response_draft_en は、次のような形の下書きになります。

Dispute ID: XXXX / Reason: 10.4 Other Fraud - Card-Absent Environment
Transaction: 2026-08-14, JPY 18,700, online order No. 55120
Summary: The transaction was authenticated with 3-D Secure (Ex.2).
The cardholder's account (login ID matched) placed two prior orders
on 2026-03-02 and 2026-05-19 from the same device ID (Ex.5, Ex.6).
Exhibits:
 Ex.2 Authentication result from the payment record
 Ex.5 Prior order record (device ID, login ID)
 Ex.6 Prior order record (device ID, login ID)

添付の一覧を資料の末尾に必ず付けます。 読み手が添付から本文を引き直せるようにするためで、担当者が確かめるときも、この一覧から原本を順に開けます。

システムへ連携する

回答と依頼の送信は、どちらも担当者が行います。 依頼文を加盟店に自動で送ると、理由の取り違えがそのまま加盟店の手間になります。

下書きは、案件管理の照会の画面から開ける場所に置きます。 担当者が照会を開いたときに、当てはめの一覧・足りない項目・資料の下書き・照合の結果が1画面にそろっていれば、別の画面を行き来せずに確かめられます。

人が確認する

1. 依頼文を送る前 … 理由と、頼む項目が合っているかを見ます
2. 資料を回答する前 … quoted_values の照合結果、添付の中身、英訳を確かめます。添付の原本を必ず開きます
3. 反論か受け入れかを決める … acceptance_signals と、満たした項目がブランドの規則で足りるかを見て決めます
4. 英文の資料を読み直す … 記録に無い表現や、カード会員を責める表現が無いかを見ます

目標は、300件をならして1件20分です。 記録がそろって当てはめが素直なものは10分程度、追加の依頼が要るものや受け入れの検討が出たものは30分以上かかります。

2番目で原本を開くのを省かないでください。 値の照合で分かるのは「文字のデータに同じ値がある」ことまでで、その記録が本当にこの注文のものか、画像が別の注文の画面ではないかは、原本を見ないと分かりません。導入の最初の1か月は、経験の長い担当者が全件の資料を読み直し、直した箇所を指示と証跡の一覧に戻します。

例外に対処する

1行目の「出なければ受け入れを検討」は、担当者の判断です。 記録が出ないまま期限を過ぎれば、反論の機会そのものがなくなります。期限の数日前の通知で、加盟店に最後の催促をするか、受け入れるかを決める時間を残します。

記録を残す

• 照会、使った証跡の一覧の版、AIに渡した入力（伏せ字の後）
• AIの出力のJSONと、quoted_values の照合結果
• 送った依頼文と、加盟店の提出の日時
• 回答した資料の版と添付の一覧、反論か受け入れかと決めた人
• 結果（反論が認められたか）と、理由のコード・満たした項目の組み合わせ

最後の行が、証跡の一覧を直す材料になります。 どの理由で、どの項目を満たしたときに結果が良かったかを数えれば、依頼文で頼む項目の優先順位を記録に基づいて決められます。

加盟店ごとの照会の数と、記録の提出の速さも残します。 同じ加盟店に利用の否認が続くなら、3Dセキュアの使い方や商品の説明を見直す相談の材料になります。資料を作るたびに同じ記録を頼んでいる加盟店には、提出の欄の使い方を案内するほうが早く片づきます。