物流の電話受付では、同じ「荷物はどこですか」という問い合わせでも、荷主、受取人、ドライバー、倉庫、協力会社、営業担当では必要な情報と行動が異なります。AI電話は配送を判断・操作する主体ではなく、呼び手、荷物・案件、現在の状態、次に動く部署を結ぶ入口です。配送状態を会話で作るのではなく、TMS・配送管理・OMSなどの正本を参照し、正本が取れない時は推測で答えない設計にします。
最初に分ける6つの呼び手
| 呼び手 | 主な用件 | AIが受ける情報 | 人へ渡す境界 |
|---|---|---|---|
| 荷主 | 集荷、配送予定、遅延、請求 | 荷番・案件・希望・連絡先 | 契約、運賃、例外承認 |
| 受取人 | 配送状況、再配達、受取変更 | 追跡番号、本人照合に必要な情報、希望 | 住所・時間指定の例外、本人確認が必要な変更 |
| ドライバー | 到着、積込・荷卸し、事故・遅延、連絡 | 運行ID、位置の報告、緊急性 | 配車・安全管理が即時に判断する事項 |
| 倉庫 | 入出庫、欠品、破損、バース | 拠点・荷番・状態 | 在庫訂正、品質・事故判断 |
| 協力会社 | 引渡し、配車、運行状況 | 委託案件・担当・時刻 | 契約外対応、運行変更 |
| 営業・社内 | 見積、案件確認、顧客連絡 | 案件・担当・期限 | 価格・契約・顧客情報の個別判断 |
呼び手が曖昧なまま配送状況を読んだり、住所変更を受けたりすると、誤案内や権限外操作につながります。番号照合は便利でも本人確認そのものではないため、変更・再配達・個人情報の境界を別に決めます。
配送状態はTMSなどの正本で管理する
電話AIの会話履歴を配送ステータスの正本にしてはいけません。集荷済み、輸送中、持戻り、配達完了、例外保留のような状態は、TMSや配送管理システムが更新するものです。AIは許可された範囲で読取り、状態に応じた案内・Case作成・人へのRoutingをします。
| 状態例 | 電話で案内できる範囲 | 自動実行しないこと | Fallback |
|---|---|---|---|
| 出荷前 | 受付済みか、出荷準備中か | 在庫・出荷日を推測して確約 | 荷主・倉庫へCase |
| 輸送中 | 正本にある最新の公開可能な状態 | 到着時刻を保証、ルートを詳細開示 | 配車・CSへ |
| 持戻り | 再配達の正規手続き・受付条件 | 本人確認なしの住所変更 | 再配達窓口または人 |
| 配達完了 | 正本上の完了事実 | 異議・紛失を会話だけで解決 | 調査Caseと担当 |
| 例外保留 | 確認中であることと次の連絡経路 | 原因・補償・再配達を断定 | 配車・倉庫・CSの所有者 |
APIが遅延・停止した時には、最後に取得できた古い情報を現在の状態として読ませません。取得時刻を持ち、古い場合は「確認中」として安全にCaseへ切り替えます。
4つの具体Flow
配送状況
追跡番号などで照合し、正本の状態を取得できた時だけ案内します。照合できない、更新が古い、複数候補がある場合は、荷番・折返し先・希望をCaseにして担当へ渡します。
再配達・受取変更
受取人ができる操作、締切、本人確認、荷物の状態を先に確認します。すでに配達完了・保留・返品処理に入った荷物へ同じ操作を二重に行わないよう、状態ごとに許可Actionを固定します。
配車・運行連絡
配車変更や遅延は、AIが運行計画を変更するのではなく、運行ID・時刻・状況を整えて配車担当へ送ります。担当不在時の代替所有者と、何分以内に応答するかを決めます。
ドライバー連絡
運転中の応答や画面操作を期待する導線にしません。安全に配慮した会社の運行管理ルールに沿い、緊急連絡は決めた人間経路へ、通常連絡は安全に確認できる時点の後続連絡へ回します。
例外を先に設計する
| 例外 | 防ぎたい失敗 | 設計 |
|---|---|---|
| API失敗 | 状態を推測して誤案内 | 仮受付、時刻付きの再照会、担当Case |
| 重複Action | 再配達・変更を二重登録 | 通話IDと冪等キー、正本の結果確認 |
| 古い在庫・状態 | 古い情報を現在として読む | 更新時刻の閾値、期限超過時の人間確認 |
| 同時着信 | 案件・個人情報の混在 | 通話ごとの状態分離、容量上限、待ち行列の案内 |
| 障害・災害 | 受付が消え、荷主・受取人が行き場を失う | 代替番号、録音・Caseの復旧、優先用件の縮退運用 |
国土交通省の物流分野の安全・セキュリティ関連資料が示すように、運行と情報を扱う仕組みでは、利便性だけでなく安全・情報管理・継続性を同時に扱う必要があります。電話AIの導入も、会話の自動化だけでなく、誰が状態を更新し、障害時に誰が受けるかを運用として決めます。
一次情報
以下は設計例：4つの物流電話
Case A：受取人の配送状況確認
「荷物はいつ届きますか」と聞かれたら、追跡番号などで照合し、TMS等の正本から公開可能な最新状態をReadします。状態が古い・照合できない時は到着時刻を推測せず、Caseを作り担当へ渡します。
Case B：再配達の希望
「明日の午後に変更したい」は、本人確認、Shipment Status、利用可能枠を順に確認し、Draftを作って復唱後にCommitします。通話IDと冪等キーを使い、再入電や再試行で二重登録しないようにします。
Case C：荷主の集荷時間変更
集荷条件・締切・運行計画を会話だけで確定せず、案件の正本と配車担当の承認へ渡します。AIは希望・連絡先・変更理由を構造化しますが、配送約束は人または承認済みのシステム操作が行います。
Case D：ドライバーの遅延連絡
「事故渋滞で遅れます」という連絡では、運転中に会話や画面操作を続けさせないことが先です。安全な会社Ruleに沿い、配車担当が運行判断・荷主連絡を担い、AIは安全に処理できる後続の記録経路へつなぎます。
一般モデルとしてのShipment State Machine
CREATED、PICKED_UP、IN_TRANSIT、OUT_FOR_DELIVERY、DELIVERED、EXCEPTION、RETURNEDは一般モデルです。実際の名称・遷移は物流会社ごとに異なります。例えばIN_TRANSITはRead中心、OUT_FOR_DELIVERYは再配達等のActionを会社Ruleにより制限、EXCEPTIONはHuman必須、と状態ごとに許可を変えます。
災害・繁忙期は共通案内と人のQueueを切り替える
台風、大雪、大型連休、ECセールでは、同じ問い合わせが同時に集中します。AIは最新の共通案内を正本から読み、個別判断が必要なケースだけ人のQueueへ送ります。古いステータスを読まない更新時刻の閾値、同時着信時の容量、障害時の代替番号を平時に試験します。
状態の更新責任を電話AIに持たせない
電話で受けた「届いていない」「住所を変えたい」は、会話としてもっともらしくてもShipmentを更新する権限にはなりません。誰が、どの本人確認で、どの状態からどの状態へ変更できるかをTMS・配車・CSのRuleとして決めます。AIはRead、Draft、Case作成を行い、Commitは許可された業務システムと確認手順へ限定します。
繁忙期に共通案内を更新する人、古い情報を止める時刻、Human Queueが飽和した時の優先順を前もって決めます。配送遅延の問い合わせを一件ずつ人へ送るだけではなく、最新の正本案内と個別調査Caseを分けることで、顧客への情報提供と運行側の判断を両立できます。
物流受付を周辺業務とつなぐ
出荷・返品・定期購入の問い合わせとの境界はEC電話受付、着信を失わない入口は電話の取りこぼし対策を参照します。配送の例外を人へ渡す構造はAI電話から人間への転送、障害と複数着信の試験はAI電話のBCP、同時着信設計と合わせて確認できます。
よくある質問
配送状況をAI電話が案内する場合、何を正本にすべきですか？
会話ログではなくTMS、配送管理、OMSなど、運行・出荷を更新する業務システムを正本にします。取得できない状態は推測せず、Caseまたは人へ渡します。
運転中のドライバーへAIが直接連絡してよいですか？
安全を最優先にし、運転中の応答・操作を前提にしません。会社の運行管理ルールに従い、配車担当・安全な連絡経路・後続の確認へ切り替えます。