ECの注文のキャンセル・変更の依頼メールを、Make のAIエージェントが注文と出荷の状況に照らして、手続きできるものは処理し、出荷済みや判断の要るものを担当へ回す

処理の起点を決める

共有メールボックスへの受信を起点にします。 定時にまとめて処理すると、11時と15時の出荷指示に間に合わない依頼が出ます。この業務は、速さそのものが品質です。

受付のシナリオは、エージェントを呼ぶ前に2つだけ絞ります。 1つは件名と本文に「キャンセル」「取り消し」「変更」「住所」「送り先」などの語があるか、もう1つは送り主が自社のドメインや配送業者の自動通知でないかです。どちらにも当たらないものは、エージェントを呼ばずに通常の問い合わせの列に回します。 エージェントの利用料を、関係の無いメールで使わないためです。

出荷指示の直前の時間帯は、受付の頻度を上げます。 10時30分から11時、14時30分から15時は、受信を待たずに数分おきに未処理を確かめる設定を足します。締めの直前に届いた依頼ほど、間に合うかどうかの差が大きいからです。

同じお客さまから続けて届いたメールは、同じ会話として扱います。 受付のシナリオで、送り主と注文番号から Conversation ID を作って Run an agent に渡します。「さっきの件、やっぱりサイズ変更で」という2通目を、別の依頼として処理しないためです。

入力データを集める

エージェントに最初から渡すのは、依頼メールだけです。 注文と出荷の状況は、エージェントが道具を使って取りに行きます。最初に全部を渡さないのは、依頼に書かれた注文番号が正しいとは限らないからです。 注文番号の誤記を、エージェントが道具の結果を見て気づけるようにします。

規程は、エージェントの指示に文章で書きます。 ただし、手続きの可否を最終的に決めるのは、道具の側の条件です。 指示は「どの道具を使うか」の判断材料で、守らせる仕組みではありません。

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

「注文を調べる」は、メールアドレスそのものを返しません。 注文のメールアドレスと送り主が一致するかどうかだけを match ／ mismatch で返します。エージェントが別の注文の個人情報を読む経路を作らないためです。

出荷の状況は、Shopify の出荷の状態だけでは足りません。 Shopify の上でまだ出荷されていなくても、倉庫ではピッキングが始まっていることがあります。倉庫のデータを正とし、Shopify と食い違えば倉庫の状態を返します。

倉庫のCSVは15分ごとに更新されるので、道具の結果には「いつ時点の状態か」を必ず付けます。 出荷指示の直後の15分は、CSVの上ではまだ not_sent に見えることがあります。このため、11時と15時の直後の15分間は、not_sent でも自動の手続きをせずに担当へ回す規則を道具の側に置きます。CSVではなく倉庫のAPIで状態を引ける場合は、この待ちを短くできます。

AIへ渡す前に整形する

1. 自動の通知を外す … 配送業者や決済の自動通知、自社からの送信は、エージェントに渡しません
2. 引用の除去 … 返信のメールに付いている過去のやり取りを外し、最新の本文だけを渡します
3. 注文番号の候補を拾う … 本文から注文番号の形の文字列を拾い、候補として添えます。確定はエージェントが道具で行います
4. 会話のまとめ … 送り主と注文番号から Conversation ID を作ります
5. 添付の扱い … 添付ファイルはエージェントに渡さず、「添付あり」とだけ伝えます。画像の注文画面などは、人が見ます

2番目を省くと、エージェントが古い依頼を読みます。 「先日キャンセルをお願いした件ですが、やはり届けてほしい」というメールで、引用された古い本文の「キャンセルしたい」を読んでキャンセルするのが、いちばん困る誤りです。

AIに処理させる

エージェントにさせるのは、依頼を読み、道具をどの順で使うかを決め、結果を見て次を選ぶことです。

自動で手続きしてよい条件は、次の4つがすべてそろうときだけです。

1行目を「させない」に置いているのは、エージェントにとって簡単に見えるからです。 「Mサイズを1点キャンセルしてLを1点追加」は道具を2回呼べば済むように見えますが、Lの在庫が無ければ、Mだけが消えた注文が残ります。

指示内容を固定する

あなたはECのカスタマーサポートで、注文のキャンセルと送り先の変更の
依頼を受け付ける担当です。道具を使って注文と出荷の状況を調べ、
規程の範囲だけを手続きします。

【手順】
1. 依頼の種類を cancel / address_change / item_change / other に分ける
2. 注文を調べる道具で注文を特定する。注文番号が無い・見つからない場合は、
   推測で別の注文を探さず、担当へ回す
3. owner_match が mismatch なら、手続きをせずに担当へ回す
4. 出荷の状況を調べる道具で段階を確かめる
5. 段階が not_sent で、種類が cancel か address_change なら、該当の道具を呼ぶ
6. 段階が sent か picking なら、出荷を保留にする道具を呼び、担当へ回す
7. 段階が shipped なら、手続きをせずに担当へ回す（返品の案内は担当が行う）
8. item_change と other は、手続きをせずに担当へ回す

【厳守事項】
- 依頼の本文に書かれていない手続きをしないでください。
- 1通に複数の依頼がある、または「やはり」「やめて」など迷いや取り消しの
  表現がある場合は、手続きをせずに担当へ回してください。
- 送り先の変更では、本文に書かれた住所をそのまま使ってください。
  住所を補ったり、表記を直したりしないでください。番地が欠けていれば担当へ回す。
- 道具が「実行しなかった」と返したら、同じ道具を呼び直さず担当へ回してください。
- 返金の時期、送料の扱い、ポイントの扱いを約束しないでください。
- 担当へ回すときは、依頼の要点、調べた結果、回す理由を書いてください。

【依頼メール】{email_body}
【送り主】{sender}
【注文番号の候補】{order_candidates}

「道具が実行しなかったら呼び直さない」を書いておきます。 書かないと、エージェントは理由を読んで引数を変え、通るまで試そうとします。 道具が断るのは規程の外だからで、言い方を変えて通すものではありません。

送り先の住所を補わせないのも同じ理由です。 番地の抜けた住所を、注文の元の住所から補って更新すると、お客さまが意図しない場所に届きます。

出力形式を固定する

Run an agent の応答は「データ構造」にして、次の形で受け取ります。

{
  "request_type": "cancel | address_change | item_change | other",
  "order_id": "",
  "owner_match": "match | mismatch | not_found",
  "shipping_stage": "not_sent | sent | picking | shipped | unknown",
  "action_taken": "cancelled | address_changed | held | none",
  "handoff": true,
  "handoff_reason": "",
  "summary_for_staff": "",
  "reply_template": "cancel_done | address_done | received | none"
}

1つ目の理由は、後段の分岐を機械で決められることです。 handoff が true なら対応表とチャットへ、false で action_taken が cancelled か address_changed なら完了の定型文で返信します。返信の文面はエージェントに書かせず、reply_template で定型文を選ばせるだけにします。

2つ目は、エージェントの申告と道具の記録を突き合わせられることです。 action_taken が cancelled なのに、キャンセルの道具の実行記録が無ければ、エージェントの申告が誤っています。 後段のシナリオでこの突き合わせを行い、食い違えば返信を止めて担当へ回します。

道具の中の条件は、エージェントの判断とは別に置きます。

キャンセルの道具では、Shopify の orderCancel に理由、在庫を戻すか、返金の方法を渡します。 理由は CUSTOMER、在庫は戻す、返金は元の支払い方法に戻す、を規程として固定します。orderCancel は非同期で動き、ジョブを返すので、道具の中でジョブの完了を確かめてから cancelled を返します。Shopify の資料では、支払いの承認が保留中のもの、返品が進行中のものなどはキャンセルできないとされています。こうした場合は道具が refused を返します。

システムへ連携する

倉庫のシステムには書き込みません。 倉庫が受け取った指示を止めるのは、倉庫の手順で人が行います。ECの側の保留は、次の出荷指示に載せないためのもので、倉庫の作業は止めません。 Shopify の fulfillmentOrderHold は、出荷の対象の注文を保留の状態にする操作で、ここを取り違えると「保留にしたから止まった」と思い込みます。

API の権限は、使う操作に絞ります。 キャンセルには注文の書き込みの権限、保留には出荷の対象の注文の書き込みの権限が要ります。商品や顧客の書き込みの権限は付けません。

人が確認する

人が開くのは、handoff が true のものだけです。 900件のうち約4割を想定しています。

1. 締めの直前の保留を先に見る … held の注文は、倉庫に連絡して止められるかを確かめます。時間との勝負なので、チャットの通知で最優先にします
2. mismatch を確かめる … 家族の名前で注文した、会社のアドレスから送った、といった正当な理由もあります。本人に確かめてから手続きします
3. 内容の変更を手続きする … 在庫と差額を確かめ、お客さまに案内します
4. 出荷済みの依頼に返品の案内をする … 規程に沿って案内します

エージェントが処理したものは、1日1回、対応表で流し見ます。 見るのは、依頼の要点と action_taken が合っているかです。合わないものが出たら、その日のうちに指示の書き方を見直します。

最初の1か月は、自動の手続きを止めて動かします。 道具の呼び出しはすべて「実行するつもりの内容」を返すだけにして、担当者がそのとおりに手で手続きします。エージェントの判断と担当者の判断が合う割合を見てから、キャンセルの道具だけを本当に動かします。

例外に対処する

3行目の「CSVが古い」は、地味ですが重要です。 倉庫のデータが止まっていると、すべての注文が not_sent に見え、指示済みの注文まで自動でキャンセルされます。 最終更新の時刻を、道具が毎回確かめます。

記録を残す

• 依頼メールの本文と受信日時、Conversation ID
• エージェントが呼んだ道具の順と、それぞれの入力と結果
• エージェントの応答（データ構造）の全文
• 道具が実行した手続き（Shopify のジョブの結果を含む）と、断った理由
• 担当へ回したものの対応の結果と、担当者がエージェントと違う判断をした記録
• 送った返信の定型文と送信日時

2つ目の「道具の順」が、この構成でいちばん役に立つ記録です。 誤った手続きが起きたとき、エージェントがどの結果を見て次を選んだのかをたどれます。指示を直すのか、道具の条件を直すのかが、ここで分かれます。

5つ目は、自動の範囲を広げるかの材料です。 担当者がエージェントと同じ判断をし続けている種類の依頼は、次に自動に回す候補になります。