顧客から届いた荷傷み・誤品の申告を、出荷時の記録と写真で切り分ける

処理の起点を決める

新規の申告が届いたことを起点にします。問い合わせフォームの送信、または申告受付用のメールアドレスへの着信です。

すべての申告を通すのではなく、荷傷み・誤品に当たるものだけを通します。 フォームなら「お問い合わせ種別」で絞れます。メールの場合は、件名と本文の分類をワークフローの最初に置き、該当しないものは後続に流しません。

写真が添付されていない申告の扱いを、最初に決めておいてください。 写真がなければ比較はできません。この場合は比較に進まず、顧客に写真の送付を依頼する定型返信の経路へ回します。

入力データを集める

注文番号が取れないと、何も始まりません。 本文に書かれていない申告は一定数あります。メールアドレスや氏名から注文を引ける経路を用意しておき、それでも引けない場合は判断不能に落とします。

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

出荷実績と検品記録： 倉庫管理システムから注文番号で引きます。APIがない場合は、日次で出力される出荷実績のファイルをクラウドストレージに置き、そこを参照する形でも成立します。

出荷時の荷姿写真： 注文番号のフォルダから取得します。1件に複数の写真がある場合は、枚数を絞ってください。 外装1枚と封かん1枚のように、役割を決めて渡すほうが比較が安定します。

撮影日時は、画像のメタデータから取らないでください。 Claude は画像のメタデータを解析・受信しません。撮影日時が必要なら、ファイルの保存情報か、倉庫管理システムの出荷記録から取ります。 これは設計上の要点です。

AIへ渡す前に整形する

1. 画像のリサイズ … 大きすぎる画像は処理前に縮小されます。あらかじめリサイズ・切り出しをしておくほうが、待ち時間も結果も良くなります。 画像の最大寸法は8000×8000ピクセルです
2. 枚数の管理 … 1リクエストに20枚を超える画像を含めると、そのリクエスト内の全画像により厳しい寸法の制限が適用されます。各画像をどの辺も2000ピクセル以下にするか、画像とドキュメントのブロックを20個以下に収めます。 実際には申告写真3枚と出荷時写真2枚程度なので、通常は収まります
3. 形式の統一 … 対応形式は JPEG、PNG、GIF、WebP です。アニメーションは非対応で、最初のフレームだけが使われます。 顧客が動画を送ってきた場合は比較に回さず、人が見る経路へ回します
4. 圧縮のかけすぎを避ける … JPEG や WebP の圧縮は待ち時間を減らしますが、圧縮を繰り返すと劣化し、送り状の文字などが読めなくなります。 保存時に1回だけ圧縮する運用にします
5. ラベル付け … 各画像の前に Image 1: 出荷時（外装） のような短いラベルを置きます。これがないと、どちらの写真の話をしているのか分からない根拠が返ってきます

AIに処理させる

原因区分の候補と、その根拠の提示までです。確定はさせません。

原因区分は次の4つに固定します。

「判断不能」を必ず区分に置きます。 4つに分けるのではなく、3つに分けたうえで残りを受ける場所を作る、という考え方です。ここが Zapier のフォールバックのパスに対応します。

員数の確定はさせません。 画像から物の個数を読むのは概算で、小さい物が多数あると正確でないことがあります。「3個入っているはずが2個だった」の確定は、人が検品記録と突き合わせて行います。

指示内容を固定する

あなたは通信販売の荷傷み・誤品の申告を、出荷時の記録と照らして
一次的に切り分ける担当者を支援する立場です。
原因区分の候補と、その根拠を出してください。確定はしません。

【厳守事項】
- 画像から読み取れないことを書かないでください。
  「おそらくこうだろう」という補いをしないでください。
- 原因区分は次の4つから選んでください。
  self_wrong_item（自社起因・誤品／員数違い）
  self_packing（自社起因・梱包不良）
  carrier（輸送起因）
  unknown（その他・判断不能）
- 出荷時写真が渡されていない場合、または画像が不鮮明で
  外装の状態が読み取れない場合は、必ず unknown にしてください。
  推測で carrier や self_packing にしないでください。
- 根拠は、出荷時写真から見たことと申告写真から見たことを
  分けて書いてください。どちらの写真の話かが分かるようにしてください。
- 物の個数を数えた結果は確定値として扱わないでください。
  個数に言及する場合は quantity_note に「人が検品記録と照合すること」
  という趣旨を必ず入れてください。
- 撮影日時を画像から推定しないでください。
  日時は渡された出荷記録の値だけを使ってください。
- 写真に人が写っていても、人物について記述しないでください。
- 顧客への一次回答の下書きでは、原因を断定しないでください。
  「確認のうえご連絡します」という形にしてください。
  金額、返金、交換の可否を書かないでください。
- 判断に迷う場合は confidence を low にし、needs_human を true にしてください。

【出荷記録】
{shipment_record}

【検品記録】
{inspection_record}

【申告本文】
{claim_text}

画像は上の指示文より前に、Image 1: 出荷時（外装） のようなラベルを付けて並べます。

「出荷時写真が無ければ unknown にする」という指示が、この構成の要です。 これがないと、申告写真だけを見て「外装がつぶれているから輸送起因」と返ってきます。比較していないのに比較したような答えが出るのが、いちばん危ない失敗です。

「原因を断定しない一次回答」も必要です。 当日中に返すのは「受け付けました、確認しています」という内容までです。原因を書いた回答を自動で返すと、後で覆したときに最初の回答が証拠として残ります。

出力形式を固定する

{
  "order_id": "",
  "cause": "self_wrong_item | self_packing | carrier | unknown",
  "confidence": "high | medium | low",
  "evidence": {
    "shipping_photo": "",
    "claim_photo": ""
  },
  "quantity_note": "",
  "needs_human": true,
  "customer_reply_draft": ""
}

evidence を2つに分けていることが、この形式の中心です。 「外装がつぶれている」だけでは切り分けになりません。出荷時の写真では何が見えて、申告の写真では何が見えるのか。この差が、そのまま切り分けの根拠になります。

cause を自由文でなく決まった値にするのは、そのままワークフローの分岐条件に使うためです。 文章で返させると、分岐のルールが書けません。

quantity_note を独立した欄にしているのは、員数の話が根拠の文章に紛れ込むのを防ぐためです。 個数はAIの読みを確定値にしないので、確認する人がここだけを見れば済むようにします。

システムへ連携する

運送会社への申し立てそのものは自動化しません。 申し立ては金銭の請求であり、会社として事実を主張する行為です。 一覧に積むところまでを自動にし、提出は人が行います。

顧客への一次回答も、送信は人が押します。 文面が自動で用意されている状態と、自動で送られる状態は違います。前者でも当日中の回答には十分間に合います。

人が確認する

全件、人が確認します。 とくに次の3つは必ず読みます。

• cause が carrier のもの（運送会社への申し立てにつながる）
• confidence が low のもの
• quantity_note に記載があるもの（員数はAIの読みを使わない）

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

• 出荷時写真と申告写真を左右に並べて表示する
• evidence の2つの記述を、それぞれの写真の下に置く
• cause ごとに色分けし、unknown を上に出す
• 検品記録の品目と数量を、申告内容の横に並べる
• 前回までに同じ運送会社・同じ配送地域で起きた件数を添える

確認にかかる時間の目標は、1件7分です。 それ以上かかるなら、渡している写真の枚数が多すぎるか、根拠の記述が抽象的です。

例外に対処する

記録を残す

• 申告の原本（本文と添付写真）と受付日時
• 引き当てた出荷実績・検品記録・出荷時写真の識別子
• AIが返した cause confidence evidence の全文
• 人が確定した区分と、AIの候補と食い違った場合のその理由
• 顧客へ送った一次回答の文面と送信日時
• 運送会社への申し立ての有無と、提出日

4つ目が、この構成を育てる材料です。 「出荷時写真が少し暗いと、梱包不良が輸送起因になりやすい」といった傾向は、食い違いの記録からしか見えません。同じ種類の食い違いが繰り返されるなら、プロンプトか撮影の運用で直せます。

なお、証拠として残すのは自社側の保管です。 アップロードした画像はAPIリクエストの間だけ保持され、処理後に自動的に削除されます。