ECの注文ごとに、商品・サイズ・購入履歴・レビューから返品されるおそれを見込み、サイズの確認メールや商品ページの記載見直しの候補を出す

処理の起点を決める

30分ごとに、新しい注文を取り込んで見込みます。 出荷の締めは毎日15時で、確認のメールはその前に送る必要があります。1日1回の夜の処理だと、午前の注文の確認が締めに間に合いません。 30分ごとなら、担当者は確認の一覧を上から見ていくだけで済みます。

商品ページの見直しの一覧は、月の第1営業日に作ります。 返品は届いてから数週間かけて戻ってくるため、注文から30日を過ぎた注文だけで実績の返品率を数えます。 先月の注文ではなく、先々月の注文の実績が確定した時点で並べます。

モデルの学び直しは、月に1回にします。 新しい商品が毎週入る事業者では、半年に1回では新しい商品の傾向が入りません。学び直しの前後で確率の分布が大きく変わっていないかを確かめてから、入れ替えます。

入力データを集める

質を決めるのは、いちばん下の返品の理由の区分です。 モデルが学ぶのは「サイズが合わない理由で戻ってきた明細」です。理由が「その他」でまとめられていると、イメージ違いや不良の返品まで学んでしまい、サイズの確認メールでは減らせない返品を見込むことになります。 返品の受付で、理由の区分を必ず選ぶ運用にします。

会員の履歴は、同じ種類の商品に絞ります。 ワンピースのサイズと靴のサイズは関係しません。「パンプスでいつも23.5を選ぶ会員が、24.0を選んだ」が見たいことです。

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

注文と会員は、カートシステムの注文の書き出しか API で取ります。取り込むのは前回の取り込みより後の注文だけにし、注文番号で重複を除きます。 会員の履歴は毎晩まとめて作り直し、日中は前の晩の履歴を使います。

レビューのサイズの声は、月に1回 Claude API で区分します。 「普段Mですが少しきつめでした」「ゆったりしています」のような書き方はさまざまで、言葉の一覧で拾うと取りこぼします。区分の結果は商品ごとの割合にしてから特徴に入れます。 レビューの本文そのものはモデルに入れません。

区分の結果も構造化出力で受け取り、1件ごとに「区分」と「根拠にした一文」を返させます。 根拠の一文があれば、商品の担当者が月次の一覧を見たときに、どんな言い方で小さめと書かれているかをすぐ読めます。区分に迷うレビューは「言及なし」にさせ、割合の計算から外します。

AIへ渡す前に整形する

1. 答えの作り方 … 注文から30日以内に、サイズが合わない理由で返品・交換された明細を1、それ以外を0にします
2. 答えの確定していない注文を外す … 注文から30日が過ぎていない明細は、学習にも検証にも使いません
3. 同じ商品の複数サイズの印 … 同じ注文で、同じ商品を2つ以上のサイズで買った明細に印を付けます
4. いつもと違うサイズの特徴 … 会員が同じ種類の商品で最も多く選んだサイズとの差を、段の数で入れます。履歴の無い会員は空のままにします
5. 商品の特徴 … 種類とブランドはカテゴリの特徴にし、レビューのサイズの声の割合と、レビューの件数を入れます
6. 特殊な期間の印 … セールの初日、送料無料の期間、返品の条件を変えた時期に印を付けます

2番目の「答えの確定していない注文を外す」を軽く見ないでください。 先週の注文は、まだ返品が戻ってきていません。学習に入れると、最近の注文ほど返品されないとモデルが学び、新しい商品の確率が低く出ます。

4番目で「履歴の無い会員を空のままにする」のは、初めての会員を「いつものサイズ」として扱わないためです。 0で埋めると、いつもと同じサイズを選んだ会員と区別できません。

学習と検証は、時間の順で分けます。 scikit-learn の TimeSeriesSplit は、未来のデータで学習して過去を評価しないための分け方です。gap には30日分の注文を入れ、答えが確定していない期間をはさみます。

AIに処理させる

この構成の「AI」は3つに分かれます。 確率を出すのは Python の勾配ブースティングで、確率の補正も Python が行います。生成AIには、レビューの区分と、確認メールの下書きだけをさせます。

確率には、scikit-learn の HistGradientBoostingClassifier を使います。 欠けた値（NaN）をそのまま扱え、データフレームのカテゴリ型の列をカテゴリの特徴として扱えます。履歴の無い会員の「いつもとの差」を空のまま入れられるのは、このためです。 返品の明細は全体の一部なので、class_weight を balanced にして少ないほうの明細を重く見ることもできます。

そのうえで、CalibratedClassifierCV で確率を補正します。 class_weight で重みを変えると、出てくる値は実際の返品の割合より高めにずれます。補正の方法は sigmoid（既定）と isotonic などがあり、isotonic は補正に使う明細が1,000件よりずっと少ないと過学習するとされています。月15,000件の注文があれば isotonic も選べますが、新しい種類の商品では件数が足りないので、sigmoid から始めます。

線の引き方は、確率だけでなく、担当者が1日に確かめられる件数で決めます。 1日の注文が500件で、担当者が出荷の締めまでに確かめられるのが30件なら、確率の高い順に30件目あたりの値が、その日の線の目安になります。 線を低くしすぎると、一覧が長くなって上から見きれず、確率の高い明細まで見落とします。補正した確率なら、「線を0.25にすると1日に何件が候補になり、そのうち何件くらいがサイズで返品されてきたか」を過去の記録で数えられます。

2行目がいちばん起きやすい失敗です。 理由の候補をそのまま渡すと、生成AIは「返品の可能性が高いため」と書きます。確認メールの目的はサイズの案内で、会員に返品の見込みを伝えることではありません。

指示内容を固定する

あなたはECサイトのカスタマーサポートで、出荷の前にサイズの確認をお願いする
メールの下書きを作る立場です。下書きは担当者が直してから送ります。

【作るもの】
1. 件名（30字程度）
2. 本文：選ばれたサイズの確認のお願いと、商品のサイズ表の該当する行の案内
3. サイズを変えたい場合の返信の仕方（返信の期限は {reply_deadline} と書く）

【理由の候補の使い方】
- different_from_usual：同じ種類の商品で、以前に選ばれたサイズと違うことを、
  「以前ご購入の○○ではMサイズをお選びでした」のように事実だけで書く
- multiple_sizes：同じ商品を複数のサイズでご注文であることを書き、
  意図どおりかを確かめる
- review_runs_small / review_runs_large：「お客様のレビューでは小さめ（大きめ）
  との声が多い商品です」と書く。割合の数字は書かない

【厳守事項】
- 「返品」「返品の可能性」「返品率」という語を本文に書かないでください。
- 会員の購入の傾向を評価したり、注意したりする書き方をしないでください。
- サイズ表に無い寸法や、着用の感想を書き足さないでください。
- 返品・交換の条件、送料、返金について書かないでください。
- 理由の候補に無いことを理由として書かないでください。
- 情報が足りないときは missing_info に項目名を入れ、推測で補わないでください。

【商品】{item_name}（{color}／{size}）
【サイズ表の該当する行と、前後のサイズの行】{size_chart_rows}
【理由の候補】{reasons}
【以前に選ばれた同じ種類の商品のサイズ】{usual_size}

「返品という語を書かない」を明記しないと、ほぼ必ず入ります。 理由の候補が返品の見込みから来ていることを、生成AIは文脈から読み取ります。会員から見れば、返品しそうだと思われている、と受け取れる文面になります。

「返品・交換の条件を書かない」も同じ理由で外せません。 下書きに条件を書くと、ページの記載が変わったときに食い違い、メールに書いた条件で返品を求められることになります。

出力形式を固定する

明細ごとの見込みと、確認メールの下書きを、次の形のJSONで持ちます。 下書きの部分は Claude API の構造化出力（output_config.format に type: "json_schema" を指定）で、この形に固定します。

{
  "order_no": "",
  "line_no": 1,
  "item_code": "",
  "size": "",
  "model_version": "2026-10",
  "return_prob": 0.0,
  "threshold": 0.0,
  "reasons": ["different_from_usual", "multiple_sizes", "review_runs_small"],
  "mail_draft": { "subject": "", "body": "", "missing_info": [] },
  "agent_action": { "sent": false, "reason_if_not_sent": "" },
  "outcome": { "size_changed": false, "returned_for_size": null }
}

return_prob threshold reasons は Python が、mail_draft は Claude API が、agent_action は担当者が埋めます。outcome は、注文から30日が過ぎた後に Python が返品の受付の表から埋めます。

1つ目の理由は、確率と文章を別の層に置けることです。 生成AIの出力に確率の欄は無く、生成AIが数字を書き換える経路がありません。 構造化出力では文字数の制約（minLength／maxLength）が使えず、additionalProperties は false にする必要があるため、件名の長さや禁じた語が入っていないかは、受け取った後に Python で確かめます。

2つ目は、agent_action と outcome で、メールの効き目を後から数えられることです。 送った明細と送らなかった明細で、サイズを変えた割合と返品された割合を比べれば、第3章の（c）の「送る意味があったのか」に答えが出ます。

3つ目は、threshold をその時点の値で残せることです。 線を引き直した後でも、当時どの線で候補にしたかが分かります。

システムへ連携する

メールの送信は、カートシステムの通常の画面から担当者が行います。 この構成から直接メールを送る経路は作りません。送信の記録がカートシステムに残り、問い合わせが来たときに誰でも経緯を追えるようにするためです。

人が確認する

担当者は、確認の一覧を確率の高い順に見ます。

1. 備考とギフトの設定を見る … 贈り物や、家族の分をまとめて買った注文は、いつもと違うサイズで当然です。送らないと決め、理由を残します
2. 理由の候補と下書きを照らす … 下書きが理由の候補どおりの内容か、サイズ表の行が正しいかを見ます
3. 送るかを決める … 送る場合は注文を保留にし、返信の期限を書きます
4. 返信を処理する … サイズを変えるか、そのまま出荷するかを処理し、outcome の元になる記録を残します

同じ会員に、短い間に何度も確認メールを送らないようにします。 同じ月にすでに確認メールを送った会員の明細は、一覧で印を付けて出し、2通目を送るかは担当者が決めます。 何度も届くと、会員は自分の選び方を責められているように感じます。

1番目を省かないでください。 ギフトの注文に「以前はMサイズをお選びでした」と送ると、会員にとっては余計なお世話で、次の注文が遠のきます。

目標は、600件をならして1件2分です。 確率が線をわずかに超えた明細は一覧で流し見て1分足らず、下書きを直して送る明細は3〜4分かかります。

例外に対処する

上から3行目と6行目は、運用の最初から決めておきます。 返事の無い注文の扱いを決めていないと、保留のまま締めを過ぎ、確認したせいで届くのが遅れることになります。

記録を残す

• 取り込んだ注文の明細と、見込みに使った特徴（会員番号は仮の番号に置き換える）
• モデルの版、補正の方法、線の値（threshold）
• 明細ごとの確率と理由の候補、生成AIの下書き
• 担当者が送ったか、送らなかった理由（agent_action）
• 30日後の結果（サイズを変えたか、サイズの理由で返品されたか）
• 月次の商品ごとの見込みと実績の返品率、商品の担当者が直したページの記録

5行目と6行目は、線の引き直しに使います。 送った明細で返品が減っていなければ、メールでは防げない返品を拾っているということです。線を上げるか、理由の候補の出し方を見直します。