配送遅延通知のためのAI：何を、いつ送るか、そして法律が求めること

TL;DR

配送遅延通知のためのAIは、「遅延」を2つの別の問題として扱うと機能します。倉庫を出ていない注文（「ラベル作成済み」で止まっているものを含む）には、新しい日付と無料でキャンセルできる方法を添えたメッセージが必要で、米国ではFTCのMail Order Ruleがまさにそれを求めており、違反1件につき最大53,088ドルの罰則があります。出荷済みで遅れている注文には、配送業者の最後の実際のスキャンと、配送業者自身の新しい日付が必要で、AIが作り上げた日付は決して使いません。

トリガーは「配送業者が例外を掲載した」ではありません。「新しい日付が約束した日付より遅い」ことです。それが切り替わったときに1通送り、そうでなければ静かにしておき、数日間スキャンがない、日付がない、荷物が紛失または破損しているといった案件は人に回します。

eeselは、ヘルプデスク内のAIチームメイトとしてこれを行います。Shopifyの注文とAfterShipのスキャンを読み取り、遅延ウェブフックで起動でき、キャンセルと返金は承認待ちにします。Question BeautyはGorgiasで運用しており、1か月に290件のShopify注文を調べてから配送の質問に答え、人手を介さずに280件のチケットを完了しました。

なぜ配送遅延でサポート受信箱があふれるのですか？

お客様が沈黙によって遅延を知るからです。追跡リンクを確認すると昨日と同じ表示で、問い合わせが来て、さらにもう一度来ます。

"where is my order" emails, easily. a package sits on "label created" for 3 days and i've got the same customer in my inbox twice asking if we scammed them, and nothing i've tried has really fixed it

HoneyedVices, Reddit

私はeeselで連携機能を作っているので、ストア、配送業者のフィード、ヘルプデスクの間の配管に多くの時間を使っています。何度も目にするパターンは、チームが「注文はどこですか」への回答（WISMO）は自動化しても、遅延そのものは知らせないままにしていることです。返信ボットは速くなりますが、遅れた荷物のたびに少なくとも1件のチケットが生まれるため、受信箱は埋まったままです。

プロアクティブなメッセージに切り替えた店舗運営者は、こう的確に述べています。

"The other thing that helped was sending a proactive "your order is running late" email when tracking shows a delay. Customers don't get mad about delays as much as they get mad about not knowing."

EarSubstantial9362, Reddit

つまり、ここでのAIの仕事は二面あります。お客様が尋ねる前に遅延メッセージを送ること、そしてそれでも届くチケットに同じ事実で答えることです。この記事の残りは前半を正しく行うことについてです。多くの設定が失敗するのはそこだからです。返信側だけについては、注文追跡サポートのためのAIと注文追跡の自動化の記事でさらに詳しく扱っています。

配送遅延の2つの種類とは？

2種類あり、それぞれ別のメッセージが必要です。「遅延」には、まだ出荷されていない注文と、出荷されたものの配送業者のネットワークで遅れている荷物の両方が含まれます。ほとんどの遅延自動化はこの2つを同じものとして扱うため、まだ棚にある箱について「お荷物はお届け中です！」とお客様に伝えてしまうことになります。

この2つの境界は見た目より明確です。FTCの規則本文は、出荷を「the act by which the merchandise is physically placed in the possession of the carrier.」と定義しています。印刷されたラベルはこれに当たりません。AfterShipはこれに専用のステータスPending_003を与えており、処理・梱包済みだが「but not scanned at a shipping location yet.」と説明されています。「ラベル作成済み」は未出荷の注文であり、AIもそのように扱うべきです。

配送遅延通知について法律は何と言っていますか？

米国では、未出荷の注文に対する遅延通知は礼儀ではなく義務です。FTCのMail, Internet, or Telephone Order Merchandise Rule（ビジネスガイド）は、オンラインで注文されたほとんどの商品に適用され、示した出荷時期には合理的な根拠が必要であり、何も示さない場合は30日以内に出荷しなければならないとしています。間に合わないと分かった時点で、お客様に遅延への同意を求めるか、返金しなければなりません。

メッセージを書くAIにとって重要な点は次のとおりです。

この規則には列挙された適用除外がいくつかあり（種子と植物、最初の出荷後の定期購入、代金引換の注文など）、サービスは対象外です。罰則は違反1件につき最大53,088ドルです。

英国は線の引き方が違います。Consumer Rights Act 2015の第28条は出荷ではなく配達についてのもので、時期を合意していない限り、商品は30日以内に届かなければなりません。届かず、その日付が重要だった場合、お客様は契約を終了できます。そうでなければ新しい期限を設定できます。そのため英国のお客様に対しては、配送業者側の遅延も数えられます。

私はエンジニアであり弁護士ではないので、これは法的助言ではなく地図として受け取ってください。それでも実務上のポイントは変わりません。未出荷の注文について「少し遅れています、お待ちいただきありがとうございます！」と明るく書くAIは、この規則が最も重視する2つの文を欠いています。

AIは遅延通知をいつ送るべきですか？

新しい日付が約束した日付より遅いときに、1回だけです。この一文が、遅延ガイドにある閾値の表のほとんどに取って代わります。

配送業者のイベントではなく約束を基準にする理由はこうです。配送業者の例外はノイズが多いからです。AfterShipの配達サブステータスには約20種類の例外が並んでおり、Exception_017（異常気象）やException_004（通関）からException_019（フライト遅延）まであります。その多くは当日中に解消します。天候で遅れても約束した期間内に届く荷物にメッセージは不要です。お客様に伝えれば、不安を生み、そしてチケットを生むだけです。

逆も起こります。例外が一切なく、ただ新しいスキャンがない荷物が、静かに約束の日付を過ぎていくことがあります。そのためAIは、1つのフィードを見張るのではなく、2つの日付を比較すべきです。

• 約束。 チェックアウト時または出荷確認に表示された配達見込み。ストアまたは配送ポリシーにあるため、AIは追跡番号だけでなくShopifyの注文を読む必要があります。
• 現在の見込み。 配送業者または追跡プラットフォームが改訂した日付。AfterShipは「estimated delivery date revised」イベントを発生させ、extreme_weather、carrier_processing、customs_clearanceなどの理由コードを付けます。

現在の見込みが約束より遅ければ送ります。現在の見込みがなく、3日間スキャンがなければ、推測を送らず、人に回します。3日は私の経験則であり標準ではないので、配送業者に合わせて調整してください。

さらに2つのルールでスパムにならないようにします。AfterShipのフローのドキュメントには、通知は「only once as the status of the shipment changes」発火するとあり、AIも同じ方針を守るべきです。スキャンごとではなく、新しい日付ごとに1通です。そしてお客様がすでにこの注文について問い合わせている場合は、2つ目のスレッドを作らず、同じチケットに返信します。統合の面はチケット重複排除のためのAIの記事で扱っています。

どの遅延メッセージを送ればよいですか？

注文が置かれている状況を選んでください。カードには、メッセージに必要な内容と、誰が送るべきかが表示されます。

AIが書く遅延メッセージが絶対にしてはいけないことは？

日付を作り上げることです。これが、遅延を苦情に変える失敗です。

"Chat bot promised a guitar delivery by tomorrow, and they have not shipped yet. Phone support says they can't do that despite acknowledging the firm commitment promised by the chat bot."

never-armadillo, Reddit

この引用は問題のすべてを2文で表しています。未出荷の注文と自信満々のボット、そして誰も教えていない日付です。解決策はより良いモデルではなくルールです。AIはシステム（注文レコード、配送業者の見込み）から得た日付だけを引用し、そのことを伝え、日付がなければ日付がないと伝えます。

eesel自身のAfterShip連携のドキュメントはこれを組み込んでいます。エージェントはスキャンを「the carrier's version of events, not the parcel's location」として扱い、最新のチェックポイントを時刻と場所とともに報告し、「never invents a delivery date the carrier did not give.」としています。GorgiasとShopifyを使うプランナーブランドのSTIL Classicsは、同じことを指示に書きました。出荷日、配達見込み、製品仕様を作り上げない、注文が見つからなければお客様に何か伝えるのではなくチームにフラグを立てる、というものです。

私の「絶対にしない」リストの残りです。

• 未出荷の注文を「お届け中」と呼ばない。 まず出荷状況を確認します。「ラベル作成済み」はお届け中ではありません。
• ポリシーが対象としない補償を約束しない。 ポリシーを引用するか、人に引き継ぎます。エージェントが従えるポリシーの書き方は、返金依頼のためのAIのガイドで解説しています。
• 例外について推測しない。 Shopifyの店舗運営者による失敗パターンの要約は、デスクの上に貼っておく価値があります。

"Usually the failure mode is not the first reply, it is the edge cases. A bot that answers "where is my order?" fast but confidently guesses on delivery exceptions burns trust."

missuncleben, Reddit

• 同じ遅延を2回送らない。 新しい日付ごとに1通。重複は、注意を払っていないシステムのように見えます。
• 「配達済み」を終わりとして扱わない。 「配達済みなのに届いていない」への返信は、必ず人に回します。それは追跡の質問ではなく苦情です。

AIによる配送遅延通知にはどんなツールが必要ですか？

3つの層があり、AIは他の2つの上に載ります。

ストア

ストア自身の通知は、ストアが管理するイベントをカバーします。Shopifyのストア通知は、注文の発生、出荷、返金などによって起動し、Liquid変数でカスタマイズできます。ストアが見えないのは、出荷後に配送業者のネットワーク内で起こることで、そのために2つ目の層があります。Shopifyをお使いなら、ストアチャットでの返信側はShopifyのAIチャットボットの記事で扱っています。

追跡プラットフォーム

この層ではAfterShipが最も一般的な選択で、そのフロービルダーを見ればその理由が分かります。例外、配達予定日の改訂、配達予定日の超過に対応する、すぐ使えるトリガーが用意されています。

どのトリガーが使えるかはプランによって異なります。AfterShipの通知ガイドと料金ページによると次のとおりです。

AfterShip自身のフローはテンプレートのメールやテキストを送り、その点は優れています。限界は判断の部分です。新しい日付をストアにある約束と比較すること、注文が実際に出荷されたかを確認すること、書く前にお客様の直近のチケットを読むこと。それが3つ目の層の仕事です。

ヘルプデスク内のAI

ここでメッセージが書かれ、返信が処理されます。選択肢を比較しているなら、おすすめの注文追跡チャットボットと注文ステータスチャットボットの比較記事が全体像を一覧にしています。

Gorgiasのユーザーは、GorgiasのAI注文追跡とGorgiasの遅延しきい値の記事で、ネイティブの設定も確認できます。

AIによる配送遅延通知はどう設定しますか？

私ならこの順番で進めます。各ステップは小さく、ステップ4で止めても、すでに価値の大部分が得られます。

ステップ1：遅延チケットを数える

先月のWISMOチケットを取り出し、先ほどの2つの列に分けます。まだ出荷していないものと、出荷済みだが遅れているものです。私が見てきたほとんどのストアは、最初の列の大きさに驚きます。それは倉庫が原因のチケットであり、米国では法的な縛りが付くものです。構造的に行いたいなら、サポートレポートのためのAIの記事に問い合わせ理由の内訳があります。

ステップ2：AIが読める場所に約束を書いておく

AIは、見えない約束とは比較できません。配送時間を、ポリシーページまたは短い指示ドキュメントに書いておきます。地域ごとの処理日数と配送業者の期間、「エクスプレス」が何を意味するかも含めます。補償ポリシーがあれば、同じ場所に正確な数字で追加します。

ステップ3：注文と追跡を接続する

ストアと追跡プラットフォームをAIエージェントに接続し、両方をリアルタイムで読み取れるようにします。eeselでは、Shopify連携により、Get Order Fulfillment（追跡番号、配送業者、出荷ステータス）、Cancel Order（未出荷の注文向け）、Refund Orderなどの操作が追加されます。AfterShip連携（リクエストに応じてワークスペースごとに有効化）は、配送業者、最新のチェックポイント、履歴、配送業者が出した配達見込みを読み取るGet trackingを追加します。

ステップ4：遅延が起きたらエージェントを起動する

ShopifyもAfterShipも、単独ではAIエージェントを起動しません。eeselのドキュメントでも、両連携にトリガーがないことが明記されています。そこで2つのパターンから選びます。

• ウェブフック。 倉庫システム、AfterShipのイベントを受けるZapierのステップ、または自社のバックエンドが、遅延をeeselのウェブフック自動化にPOSTします。エージェントはそのデータとともに起動し、あなたが書いた指示に従います。
• スケジュール。 朝に実行し、未完了の注文を約束した日付と照らし合わせ、対応が必要なものを送ります。Cape Coffee BeansはZendeskのキューにスケジュール実行を使っています。1か月に160回のスケジュールチェックを行い、それぞれが創業者への短いメールで終わるか、報告することがなければメールなしで終わります。

ウェブフックの方法は、倉庫の出荷遅延を実例として使っているeesel自身のドキュメントにあるものです。チャットでウェブフックを依頼し、各ペイロードをどう処理するかを伝えます。

遅延が届くと、エージェントはそれをShopifyと照合して動きます。ドキュメントの例では注文を突き合わせられなかったため、誰かにメッセージを送る代わりに、チーム向けにタグ付きのGorgiasチケットを作成しました。データが合わないときに望むのはまさにこれです。

ターミナルやコーディングエージェントから設定したい場合は、eesel CLIで同じことができます。eesel integrations connect aftershipは接続リンクを表示し、eesel automationsはウェブフック自動化とその有効状況を一覧にし、eesel approvalsは人の対応を待っているものを表示します。Claude Code、Codex、Cursorもこれらのコマンドを操作できるので、ウェブフックの送信元が自社のバックエンドで、同じエンジニアが両端を接続する場合に便利です。

ステップ5：リスクのある操作は承認の後ろに置く

遅延の更新連絡を送るのは低リスクです。キャンセルと返金はそうではありません。eeselでは、すべての操作を自動実行、事前確認、オフのいずれかにできます（操作と承認）。保留された操作は、ダッシュボード、Slack、またはターミナルのeesel approvals approve <id>で承認できます。

私なら、キャンセルと返金は「事前確認」から始め、数週間その判断を観察し、それから無難なものを緩めます。選び方はカスタマーサポートの承認ワークフローの記事で説明しています。

ステップ6：先月の遅延注文でテストする

何かをお客様に送る前に、再現してみましょう。先月の遅延注文を20〜30件取り、1件ずつ通して、送られたはずのメッセージをすべて読みます。確認するのは3点です。正しい列を選んだか、すべての日付がシステム由来だったか、保留すべきケースを保留したか。そのためのサンプルサイズは、AIサポートのシミュレーションテストのガイドで扱っています。

実際のストアではどうなりますか？

eeselの3社のお客様が、参考にする価値のある方法で配送の質問に対応しています。

Question BeautyはShopifyでヴィーガンコスメを販売し、サポートをGorgiasで運用しています。大半はSNSやチャットからの短いメッセージです。配送や注文の質問に対し、eeselはメールアドレスでお客様を見つけ、注文とその出荷状況を確認し、追跡の詳細で答えます。注文がまだ処理中の場合や、追跡がすでに質問に答えている場合は、その旨を伝えてチケットをクローズします。1か月で、Gorgiasのチケット990件を処理し、Shopifyの注文290件を調べ、人手を介さずに280件のチケットをクローズしました。

Rúngneは、ノルウェーと米国の倉庫から出荷するノルウェーのクライミングウェアブランドで、作業を複数のエージェントに分けました。下書きエージェントがShopifyで注文を見つけ、なぜ出荷されていないかを確認し、チーム向けに内部メモとして返信を残します。別のヘルプデスクエージェントは、「注文はどこですか」や配送ポリシーの質問に直接答えます。1か月のGorgiasチケット2,100件のうち、チーム向けの下書きが580件、公開返信が440件でした。「なぜ出荷されていないか」の確認は、先ほどの未出荷の列であり、誰かが返信を書く前に行われます。

「推測しない」ルールの例として私が挙げたいのはSTIL Classicsです。チケットにはしばしば「a delivery scan that has not moved」が絡み、エージェントは1か月に230件のShopify注文を調べてから1行の下書きを書きました。作り上げた出荷日は許されていません。

この3社はどれも純粋な「プロアクティブな遅延メール」の設定ではないことを、率直に述べておきます。これは返信側を丁寧に行ったもので、それが土台です。上のウェブフックとスケジュールのパターンが、同じエージェントを外向きに使う方法です。

機能しているかどうかをどう測りますか？

導入の前後で、4つの数字を見ます。

最後の指標について一言。配送業者の見込みが外れるのは普通です。AIが配送業者を引用して、その配送業者が外すのは問題ありません。ですが、AIがどこからも来ていない日付を作り出すのは、バグです。

AIによる配送遅延通知のよくある間違い

私がよく目にするもので、引き起こす問題の大きい順におおよそ並べています。

1. 未出荷の注文を配送業者の遅延として扱う。 キャンセルの案内なし、新しい出荷日なし、明るい「お届け中」。米国では、FTCの規則が問題にしているのはメッセージのこの部分です。
2. すべての例外でトリガーする。 当日中に解消する天候の一時的な乱れが、不安なお客様になります。スキャンではなく約束を基準にトリガーします。
3. AIに空白を埋めさせる。 システムからの日付がなければ、メッセージにも日付はありません。「配送業者からまだ新しい日付が出ていません」は、完全で正直な一文です。
4. 送信専用アドレスから送る。 お客様の返信（「キャンセルできますか？」）は、次に起こりうる最も有益なことです。チケットに届くよう、ヘルプデスクから送ります。
5. すでにあるチケットを忘れる。 昨日問い合わせがあったなら、遅延メッセージはそのスレッドに属します。
6. 紛失荷物のケースを自動化する。 紛失、破損、「配達済みなのに届いていない」は請求と判断の案件です。下書きして引き継ぎます。保証請求のためのAIのガイドに同じ引き継ぎパターンがあります。

遅延が波のように来る場合（年末年始のピーク、配送業者のストライキ）は、負荷の下でも同じルールを保つ方法を季節的なサポート急増のためのAIの記事で、誰も見ていない土曜日のスキャンについては週末のサポート対応のためのAIの記事で扱っています。

配送遅延通知にeeselを試す

ストアがShopifyで、チケットがGorgias、Zendesk、Freshdeskに届くなら、eeselは、注文と配送業者のスキャンの読み方をすでに知っているAIチームメイトとして働きます。遅延ウェブフックを向けるだけで、注文が出荷されたかを確認し、新しい日付をあなたの約束と比較し、正直な更新連絡を1通送り、キャンセルと返金はあなたの承認待ちにします。Question Beautyは、この方法で1か月に280件のGorgiasチケットを、人が触れることなくクローズしました。

ダッシュボードのチャットまたはCLIから設定し、先月の遅延注文でテストして、料金ページのプランをご確認ください。eeselを無料で試して、何を送っていたかをご覧ください。