返品の受付から返金までの進捗を追って、止まっているものを毎日洗い出す

処理の起点を決める

毎朝7時を起点にします。Schedule by Zapier の日次の間隔で時刻を7時にし、土日に動かすかどうかは倉庫と運送会社の稼働に合わせます。起動の分は数分ずれ得るため、朝礼で見る運用なら朝礼の1時間前に置きます。

もう1つの起点として、顧客から催促の連絡が入ったときの臨時照会を置きます。問い合わせ管理システムで「返品」のタグが付いた新規の問い合わせをきっかけに、その返品IDだけを同じ流れに通します。担当者が5つの画面を開く前に、いまの段階が手元に出ている状態を作ります。

Delay by Zapier は使いません。 待ち時間を作るステップとして便利ですが、保持できるのは最長で1か月（30日）までと公式の説明にあり、最短は1分です。返品の追跡は数日から数十日にわたるため、「待たせる」のではなく「毎朝すべて見直す」ほうが安全です。遅延の途中でZapを編集すると再開後に続かないという注意も公式にあり、運用しながら直す仕組みには向きません。

入力データを集める

返品IDと送り状番号を受付の時点で台帳に入れておくことが前提です。 送り状番号が無いと、運送会社の記録に辿り着けません。集荷を依頼した時点で番号を控える運用が無いなら、そこから直してください。

標準日数の表と宛先の対応表は、最初に人が作ります。 どちらも20行に満たない表で、作るのに1〜2時間です。この2つを作らずに始めると、AIに「何日で異常か」と「誰に言うか」を推測させることになり、出力が信用できなくなります。

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

返品受付台帳： 問い合わせ管理システムのAPIか日次のCSVから、仕掛かり中の返品（受付済みで、返金・交換の完了フラグが立っていないもの）を取ります。受付日が90日より前のものは別扱いにします。 長期の未決は、進捗ではなく判断の問題であることが多いためです。

運送会社の追跡： 送り状番号ごとの状態を取ります。APIが使える契約ならAPIを、無ければCSVを日次で取り込みます。取得の方法は契約の形で変わるため、ここは利用環境に応じた個別確認が必要です。 照会には回数の上限があることが多いので、1日1回、仕掛かり中の件だけを引く設計にします。

倉庫管理システム： 入荷の実績を、返品IDか送り状番号で引きます。ここが最も詰まりやすい部分です。 倉庫の入荷は「入荷番号」で管理されており、返品IDが入っていないことがあります。返品ラベルに返品IDを印字し、入荷登録のときに入力してもらうのが確実です。検品は入荷番号で、会計は注文番号で引きます。キーが段階ごとに違うため、前の段階で得たキーを次の段階に渡す形になります。 これが「順に辿る」という設計の中身です。

エージェントに引かせる形： 配送・倉庫の入荷・検品・会計・顧客とのやり取りの5つを、Claude API のツールとして定義します。ツールは名前、説明、input_schema（入力の形を表すJSONスキーマ）で定義し、Claude が必要と判断すると stop_reason が tool_use の応答を返します。 そのブロックにツール名と引数が入っているので、ワークフロー側でシステムを引き、結果を tool_result ブロックに入れ、tool_use_id を添えて送り返します。これを繰り返すと、必要な数だけシステムを辿らせられます。

tool_choice に {"type": "auto", "disable_parallel_tool_use": true} を指定します。 まとめて呼ばせず1つずつ順に呼ばせるためで、集荷されていないと分かった時点で以降を引かない節約ができるのは、この形のときだけです。ツール定義の strict: true は、引数がスキーマどおりになることを保証します。 返品IDを勝手な形で渡されると照会が空振りするため、これを付けます。

AIへ渡す前に整形する

1. 対象の絞り込み … 完了済み、キャンセル済み、受付日が90日より前のものを外します。残るのは200〜250件程度です
2. キーの整形 … 送り状番号のハイフン、注文番号の接頭辞、SKUの全角・半角をそろえます。表示用には元の文字列を残します
3. 前日の結果の読み込み … 前回の段階、その段階に入った日、前回の催促日を持ってきます。これが無いと「何日止まっているか」が数えられません
4. 期待する返送内容の確定 … 受付台帳の「返送予定のSKUと数量」を、突き合わせの基準として1件ぶん組み立てます
5. 営業日の計算 … 標準日数を営業日で数える段階（倉庫・検品・経理）と暦日で数える段階（輸送・顧客都合）を分け、休業日の表を当てて経過日数を先に計算します
6. 前回からの変化の判定 … 前日と段階が同じで、超過の判定も同じ件は、催促を再送しない印を付けます

5番目をAIにさせないでください。 営業日の計算は休業日の表で決まる事実で、判断の余地がありません。日付の引き算をAIにさせると、まれに1日ずれます。

AIに処理させる

計算処理にさせること：

エージェント（Claude API）にさせること：

3番目が効きます。 「いま検品待ちである」だけでは催促できません。「入荷計上が9月18日、今日が9月24日、検品の記録が無い」まで出て初めて、倉庫に言えます。

5番目が、この題材でいちばん機械的に解きにくい部分です。 3点の返品に対して入荷が2件あるとき、それは「2箱に分けて送られ、両方着いた」のかもしれませんし、「1点がまだ届いていない」のかもしれません。SKUと数量を合計して期待値と比べ、足りなければ 一部到着 と判定させます。

判定そのもの（再販可か廃棄か）と、金額の計算はさせません。 見るのは「判定が記録されているか」「記録された日から何日経ったか」だけです。

指示内容を固定する

エージェントに与えるシステムプロンプトの例です。ツールの定義は別に渡します。

あなたは返品案件の進捗を確かめる担当者です。
1件の返品について、必要な記録を順に引き、いまどの段階で止まっているかを判定してください。

【引く順序】
1. get_shipment を、受付台帳の送り状番号で引いてください。
   送り状番号が空欄なら引かず、stage を "受付済み" として終えてください。
2. 集荷日が記録されていない場合は、そこで終えてください。
3. 配達完了（倉庫への到着）が記録されたら、get_receipts を引いてください。
4. 入荷が記録されていれば、その入荷番号で get_inspection を引いてください。
5. 判定が記録されていれば、注文番号で get_settlement を引いてください。
6. 段階が "受付済み" か "集荷済み" で、受付から5日以上経っている場合だけ、
   get_customer_log を引き、顧客への依頼に未回答が無いかを確かめてください。

【厳守事項】
- ツールは1回につき1つだけ呼び、引く必要のないツールを呼ばないでください。
  ある段階で止まっていると分かったら、その先のシステムは引きません。
- 日付は、ツールが返した文字列をそのまま evidence に写してください。
  日付の足し算・引き算をしないでください。経過日数はこちらで計算します。
- ツールが値を返さなかった場合と、エラーを返した場合を区別してください。
  前者は「まだ記録が無い」、後者は「確かめられなかった」です。
  後者のときは stall_reason を "照会失敗" にし、推測で段階を決めないでください。
- 返送予定のSKUと数量に対し、入荷の合計が足りない場合は
  quantity_match を "一部到着"、多い場合は "超過" にし、
  不足または超過しているSKUと数量を quantity_note に書いてください。
- 催促の宛先を決めないでください。宛先はこちらで対応表から引きます。
- 返金や交換の実行を促す文言を書かないでください。
- 顧客の氏名・住所・電話番号は与えられていません。
  文面が必要な場合は {customer_name} のままにしてください。

【段階】
受付済み ... 集荷の記録が無い
集荷済み ... 集荷されたが、輸送の履歴が動いていない
輸送中 ... 輸送の履歴はあるが、倉庫への到着の記録が無い
入荷済み ... 倉庫で入荷計上されたが、検品の記録が無い
検品済み ... 検品されたが、判定の記録が無い
判定済み ... 判定が出たが、返金または交換出荷の記録が無い
完了 ... 返金または交換出荷が記録されている

【止まっている理由の区分】
集荷未実施 ... 集荷を依頼したが、運送会社の集荷の記録が無い
輸送中 ... 集荷後、倉庫への到着の記録が無い
入荷未処理 ... 配達は完了しているが、倉庫の入荷計上が無い
検品待ち ... 入荷計上から、検品の記録が無い
判定保留 ... 検品は終わっているが、判定が記録されていない
返金処理待ち ... 判定は出ているが、返金・交換出荷の記録が無い
顧客都合 ... 集荷日時の回答待ち、返送用の伝票の未受領など
照会失敗 ... いずれかのシステムを引けず、段階を決められなかった

【今日の日付】{today}
【返品の受付内容】
{return_case}

「1回につき1つだけ呼ぶ」は、プロンプトだけに頼らず disable_parallel_tool_use でも止めてください。

「値が無い」と「引けなかった」を分けさせる1行が重要です。 倉庫のシステムが応答しなかっただけなのに「入荷未処理」と判定されると、倉庫に濡れ衣の催促が飛びます。照会に失敗した件は、催促に回さず、システム担当へ回す別の列に出します。

「宛先を決めないでください」も必須です。 宛先をAIに選ばせると、「顧客に確認したほうがよさそう」といった判断が混ざります。宛先は、段階と理由の区分から対応表で一意に引きます。

社外に出る2種類（運送会社・顧客）だけを承認待ちにします。 社内向けを全部承認にすると、毎朝の承認が20件を超えて、承認そのものが滞留します。

出力形式を固定する

エージェントには、1件ごとに次の形で返させます。

{
  "return_id": "",
  "order_no": "",
  "stage": "受付済み | 集荷済み | 輸送中 | 入荷済み | 検品済み | 判定済み | 完了",
  "stage_entered_on": "",
  "stall_reason": "集荷未実施 | 輸送中 | 入荷未処理 | 検品待ち | 判定保留 | 返金処理待ち | 顧客都合 | 照会失敗",
  "quantity_match": "一致 | 一部到着 | 超過 | 判定不能",
  "quantity_note": "",
  "evidence": [
    { "system": "", "field": "", "value": "" }
  ],
  "systems_checked": [],
  "systems_failed": [],
  "note": ""
}

Claude API では、output_config.format に type: "json_schema" とスキーマを渡すと、応答をスキーマに沿った形に制約できます。stage stall_reason quantity_match は enum で固定します。公式の説明では、additionalProperties は false にする必要があり、文字列の長さや数値の範囲の制約は使えません。 配列の minItems は0と1だけです。evidence が空でないことは、後段の Code by Zapier で確かめます。

stage_entered_on を必ず返させます。 経過日数はワークフロー側で計算しますが、起点の日付をどのシステムから採ったのかが分からないと検算できません。 evidence に「倉庫管理システム／入荷日／2026-09-18」の形で残させます。

systems_checked と systems_failed を分けさせます。 5つのうち3つしか引いていない件が、正常な節約なのか途中で止まったのかが分かります。note には「顧客が発送済みと連絡しているが、送り状番号が台帳と一致しない」のような、区分に収まらない事情を1文で書かせます。これが入っている件は、担当者が先に見ます。

システムへ連携する

滞留一覧をスプレッドシートに作ります。1行を1件の返品にし、催促の宛先ごとにフィルタで見られるようにします。

Paths で宛先ごとに分けます。 社内の4つの宛先（倉庫の入荷担当、検品担当、商品部、経理）へは、それぞれのSlackチャンネルに件数と一覧のリンクだけを送ります。1件ずつ通知しないでください。 毎朝15件の通知が別々に飛ぶと、3日で読まれなくなります。どの条件にも当たらなかった件はフォールバックのパスで受け、責任者へまとめて送ります。

社外向けは、Human in the Loop の Request Approval を通します。 催促文の下書きを承認の対象として渡し、承認者にメールかSlackで通知します。承認者は承認・却下のほか、文面を直したうえで承認することもできます。 待ち時間の上限は当日中に置き、上限に達したら「実行を終える」を選びます。 「そのまま進む」にすると、誰も見ていない文面が顧客に届きます。

会計システムへの書き込みは行いません。 返金の実行、金額の変更、交換出荷の指示は、いずれもこの構成の外です。読み取り専用の権限で接続してください。

人が確認する

社外へ出す催促文は、全件を人が確認します。 運送会社宛と顧客宛の2種類で、月に30〜50件程度になる想定です。

社内向けの一覧は、担当者が朝に一度、次の順で見ます。

• 照会失敗 … システムの不調かもしれない。5件を超えたら、その日の一覧全体を疑う
• 顧客都合 … 放っておくと止まったままになる段階なので、最優先で見る
• 集荷未実施で5日以上 … 顧客の手元に商品が残っている。不満が最も溜まる段階
• 返金処理待ち … お金の話だけが残っている。顧客から催促が来る直前の状態
• 入荷未処理・検品待ち … 倉庫側の話。まとめて依頼する
• 数量の一致が「一部到着」 … 残りが行方不明かもしれない。個別に追う

確認を速くするための設計が効きます。

• 根拠（システム名・項目・日付）を、判定の隣に並べて表示する
• 前日から段階が変わった件に印を付ける
• 前回「判定が誤り」とした件と同じ判定には、その理由を並べて表示する
• 同じ宛先の件をまとめて表示し、1通で催促できるようにする

4番目が効きます。 倉庫への催促が12件あるなら、返品IDを12件並べた1通にします。倉庫の側も、1回の作業でまとめて処理できます。一覧に出る件数が毎日30件を超えるなら、標準日数が実態より短すぎます。

例外に対処する

記録を残す

この記録は、どの段階が慢性的に詰まっているかを知る材料になります。

• 日ごとの対象件数、段階ごとの件数、超過した件数
• 各件の段階の履歴（いつ、どの段階から、どの段階へ移ったか）
• 催促した日、宛先、対応が動いた日
• 担当者の判断（催促する／様子を見る／判定が誤り）と、その理由
• systems_checked と systems_failed、照会失敗の件数と相手先
• 承認の記録（承認者、承認・却下、修正された文面）

「段階ごとの平均滞留日数」を必ず残してください。 入荷未処理が平均4日、検品待ちが平均6日、といった数字が出ると、催促のやり方ではなく、倉庫の人繰りを直す話になります。

「催促してから動くまでの日数」も宛先ごとに残してください。 3日以上かかる宛先には、催促の手段そのものを変える必要があります。承認のときに毎回同じ直しが入る文面は、ひな形のほうを直します。