出荷済みの荷物の配送状況を毎日見回り、遅延や持ち戻りを顧客から問い合わせが来る前に拾う

処理の起点を決める

Schedule Trigger で、毎日8時30分と13時30分に動かします。 Schedule Trigger は秒・分・時間・日・週・月の間隔と、cron 式での指定ができるとされています。1日2回にするのは、朝の分で前日夜までの状況を、昼過ぎの分で午前中の配達の結果を拾うためです。

時刻の基準を必ず確かめてください。 Schedule Trigger は、ワークフローにタイムゾーンが設定されていればそれを、なければ n8n のインスタンスのタイムゾーンを使うとされ、自前で動かす場合の既定は America/New York とされています。ワークフローのタイムゾーンを Asia/Tokyo に設定します。 忘れると、朝の見回りが夜中に動きます。

保存して公開しないと動きません。 Schedule ノードをトリガーにするワークフローは、保存して公開するよう注意書きがあります。また、n8n 2.36 以降では、予定の時刻に動けなかった実行をどう扱うか（捨てる、直近の1回だけ動かす、取りこぼした分を個別に動かす）を設定できるとされています。この構成では「直近の1回だけ」を選びます。 見回りは最新の状況を見れば足り、古い回を積み直す意味がないからです。

入力データを集める

質を決めるのは、下の2つです。 方針が無ければエージェントは「念のため全部連絡する」側に倒れ、台帳が無ければ同じ荷物を毎回新しい例外として扱います。

問い合わせ履歴を入れるのは、二重の連絡を避けるためです。 顧客がすでに問い合わせていれば、その荷物は UC-0045 のような受付側の対応に乗っています。そこへ別の連絡を送ると、顧客のもとに違う担当者から違う文面が2通届きます。

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

配送状況は、運送会社ごとに1本ずつ取り込みの枝を作ります。 CSVで受け取る契約なら決まった保管場所から読み、APIで受け取る契約ならワークフローから呼びます。取り込む範囲は、出荷から一定日数（例：14日）以内で、まだ配達完了になっていない荷物です。 配達完了の荷物を毎回読むと、件数が増えるだけです。

出荷実績を先に読み、運送会社のデータと突き合わせます。 逆にすると、出荷したのに運送会社のデータに一度も出てこない荷物を見落とします。集荷の漏れや追跡番号の打ち間違いは、この向きでしか見つかりません。

受注と顧客は、ワークフローの冒頭では読みません。 例外の出た荷物についてだけ、エージェントが道具で引きます。12,000個分の顧客情報を毎回生成AIへ渡さないためです。

AIへ渡す前に整形する

1. 状況の言い回しの置き換え … 運送会社ごとの状況を、in_transit ／ delivered ／ absent_returned ／ address_unknown ／ held_at_depot ／ damaged ／ returning_to_sender ／ unknown の共通区分に置き換えます。対応表に無い言い回しは unknown にします
2. 最終更新からの経過時間の計算 … 状況が最後に変わった時刻から、今までの時間を出します
3. お届け予定日の計算 … 出荷日と配送先の地域から、自社の標準の日数で予定日を出します
4. 例外の拾い出し … 共通区分と経過時間、予定日から、規則で拾います
5. 出荷実績との突き合わせ … 出荷から一定時間を過ぎても運送会社のデータに出てこない荷物を、not_scanned として拾います
6. 例外台帳との突き合わせ … 同じ追跡番号・同じ区分で前回すでに上げたものは外し、区分が変わったものと新しいものだけを残します
7. 件数の確認 … 残った件数が普段の数倍なら、エージェントに渡さずに担当者へ知らせます

1番目で、AIに言い回しを解釈させないでください。 対応表で置き換え、対応表に無いものは unknown として人に回し、対応表のほうを直します。 AIに解釈させると、同じ言い回しが日によって別の区分になります。

7番目は、大雪や台風の日のためです。 一つの地域の荷物が一斉に遅れた日は、個別の文案ではなく、まとめてのお知らせを人が判断します。

AIに処理させる

させるのは、例外の出た荷物1件ごとに、必要な照会を選んで事実を集め、次の5つを組み立てることです。

道具の選び方が、荷物ごとに違うのがこの題材です。 住所不明なら受注の住所の入力内容を引きます。お届け予定日を過ぎた荷物なら、お届け日の指定とギフトの有無を見ます。2個口の片方だけが止まっているなら、もう片方の状況を引きます。どれを引くかを決めてから引くので、固定の手順で全部を引くより照会が少なく済みます。

3行目がいちばん起きやすい失敗です。 「天候の影響で」と書きたくなりますが、データにあるのは状況と日時だけです。分からない原因を書いた文面は、顧客が別の経路で違う事情を知ったときに、そのまま不信になります。

道具を読み取り専用に限るのが、この設計の土台です。 n8n の AI Agent ノードには、特定の道具を実行する前に人の承認を求める仕組みがあり、メッセージの送信や記録の変更のような操作に向くとされています。それでも本記事では、書き込む道具そのものをエージェントに持たせません。 下書きを置くのは、エージェントの外の、規則で動くワークフローの側です。

指示内容を固定する

あなたはEC事業者の物流チームで、配送に例外が出た荷物の対応を準備する立場です。
渡された荷物1件について、道具で事実を集め、決められた形で返してください。

【使える道具】
- lookup_order_by_tracking：追跡番号から注文・顧客・お届け先・指定日を引く
- list_parcels_of_order：同じ注文の他の荷物と、その配送状況を引く
- find_open_inquiries：その顧客・その注文の未完了の問い合わせを引く
- get_contact_policy：例外の区分ごとの連絡方針を引く
必要なものだけを呼んでください。get_contact_policy は必ず呼んでください。

【判断の手順】
1. 荷物に入っている注文と顧客を特定する。特定できなければ止めて needs_human
2. 未完了の問い合わせがあれば、連絡文案は作らず contact を skip_inquiry_open にする
3. 連絡方針に照らして、contact を now ／ wait ／ none から選ぶ
4. 対応先を customer ／ carrier ／ warehouse ／ none から選ぶ（複数可）

【厳守事項】
- 遅れや持ち戻りの原因を書かないでください。配送状況データに原因は書かれていません。
- 新しいお届け予定日を書かないでください。運送会社からの確定の情報がない限り「不明」です。
- お詫びの品、送料の返金、補償を約束しないでください。
- 住所の誤りを断定しないでください。「確認させてください」と書いてください。
- 道具が返した内容に無い事実を書かないでください。記載がなければ「不明」としてください。
- 迷ったときは contact を now にせず、needs_human を true にしてください。
- 顧客への文案には、注文番号と商品名、今わかっている状況だけを書いてください。

【荷物】{parcel}
【共通区分と経過時間】{status}
【前回までの記録】{ledger_entry}

「原因を書かない」「予定日を書かない」を独立に書いているのは、文案が丁寧になるほど両方を書き足すからです。 顧客に安心してもらおうとする文面は、自然に「明日にはお届けの見込みです」と続きます。禁じるのは、確定していない事実を書く書き方そのものです。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "tracking_no": "",
  "carrier": "",
  "exception_type": "absent_returned | address_unknown | held_at_depot | damaged | delayed | not_scanned | unknown",
  "orders": [
    { "order_no": "", "customer_id": "", "delivery_date_requested": "", "is_gift": false }
  ],
  "other_parcels": [ { "tracking_no": "", "status": "" } ],
  "open_inquiry": false,
  "contact": "now | wait | none | skip_inquiry_open",
  "wait_until": "",
  "route_to": ["customer | carrier | warehouse | none"],
  "customer_draft": "",
  "ticket_draft": { "to": "", "summary": "", "facts": [] },
  "tools_used": [],
  "needs_human": false,
  "reason": ""
}

1つ目の理由は、ワークフローが規則で後段を振り分けられることです。 contact が now のものだけヘルプデスクに下書きを置き、route_to に carrier があるものだけ社内チケットの起票案を作ります。振り分けを文章から読み取らせると、同じ文でも日によって分岐が変わります。

2つ目は、出力を点検できることです。 Structured Output Parser は JSON Schema に基づいてフィールドを返すとされ、JSONの例から作ると、すべてのフィールドが必須として扱われるとされています。スキーマの参照（$ref）は使えないとされているので、1つのスキーマに平たく書きます。

3つ目は、tools_used で何を調べたかが残ることです。 住所不明なのに受注の住所を引いていない、2個口なのに他の荷物を引いていない、といった調べ漏れを、ワークフローの規則で見つけられます。

システムへ連携する

道具の先の小さなワークフローは、入力を追跡番号か注文番号に限ります。 Call n8n Workflow Tool は、入力の値を固定値・式・AIに埋めさせる値の組み合わせで決められるとされています。顧客IDやメールアドレスで検索できる道具を作らないでください。 エージェントが別の顧客の情報まで引ける経路になります。

ヘルプデスクへは下書きとして置き、送信はしません。 受注管理システムと運送会社のシステムには何も書き込みません。

人が確認する

人が見るのは、contact が now のもの、route_to に carrier か warehouse があるもの、needs_human のものです。 wait と none は、件数と区分を一覧で流し見ます。

1. needs_human を先に見る … 注文を特定できない、区分が unknown、点検の規則に引っかかったもの
2. 文案の事実を確かめる … 注文番号・商品名・状況が、受注と配送状況のデータと合っているか
3. 送る … ヘルプデスクの下書きを直して送ります。送信は人が行います
4. 運送会社への照会と再送を手配する … 起票案を確かめてから、チケットとして確定します
5. 判断を覆したら記録する … wait を now に変えた、連絡をやめた、などを残します

5番目が、方針表を育てる材料になります。 同じ区分で何度も覆しているなら、方針表の待つ日数が合っていません。

目標は、360件をならして1件4分です。 一覧で流し見て終わる wait と none が半分ほど、文案を直して送るものと手配の要るものが残りという想定です。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、データの受け渡しと、追跡番号の記録の問題です。 ここを直すほうが、判断の精度を上げるより効きます。

記録を残す

• 取り込んだ配送状況データと出荷実績の、回ごとの件数と取り込み時刻
• 例外として拾った荷物と、前処理で付けた共通区分
• エージェントが呼んだ道具と、その結果（tools_used と途中経過）
• エージェントの出力（JSONの全文）と、点検の規則の結果
• 人が判断を覆した記録と、送った文面、送った日時
• 例外台帳（追跡番号・区分・連絡の有無・対応先・完了日）

3つ目の途中経過は、AI Agent ノードの Return Intermediate Steps で出力に含められるとされています。どの道具を、どの順で呼んだかが残るので、「なぜこの荷物は連絡しないと判断したのか」を後から追えます。