荷主からの問い合わせで時間を取られているのは、調べる作業そのものよりも「どこを調べればよいかを決める」手前の工程です。この記事では、在庫照会・誤出荷の申告・棚卸差異の照会を受けた後の一次切り分けに絞り、出荷番号・SKU・ロット・ロケの候補特定と証跡集め、権限の範囲での参照、回答の下書きまでをAIに任せる範囲と、現物確認・引当・原因の確定・在庫調整・荷主への回答という人が決める範囲を整理します。
3PL倉庫の事務担当者に届く問い合わせは、多くが短い文章です。「昨日出た分の在庫、まだ残ってますか」「先週届いた荷物の中身が違うようです」「棚卸の数が合わないので調べてください」。文章としては数行ですが、これに答えるには倉庫側で複数の情報を突き合わせる必要があります。
ここで負担になっているのは、WMSの検索が遅いことではありません。問い合わせの文面が、倉庫側のキーに翻訳されていないことです。
この翻訳は経験のある担当者ほど速く、経験の浅い担当者ほど時間がかかります。結果として、問い合わせ対応が特定の人に寄り、その人が休むと止まるという形になりがちです。多荷主の倉庫では荷主ごとに呼び方も運用も違うため、この属人化は自然に強まります。
この記事が扱うのは、荷物を受け取った後に届く問い合わせへの一次対応です。荷主から届く出荷指示そのものを読み取って取り込む工程は出荷指示メール・Excelの取込が、共有メールボックスの対応漏れや滞留の管理は共有メールの対応漏れ防止が扱っています。多荷主オペレーション全体の標準化の論点は3PL倉庫の多荷主オペレーションと標準化の壁にあります。
在庫と出荷に関する問い合わせは、答えに必要な情報と判断の重さが類型ごとに違います。同じ「問い合わせ対応」として一括りにすると、軽いものと重いものが同じ列に並び、重いものが後回しになります。
| 類型 | 荷主が知りたいこと | 特定が必要なキー | 判断の重さ |
|---|---|---|---|
| 在庫照会 | いま何個あるか、今日出せる数はいくつか | 荷主・SKU・ロット・ロケ・引当の状態 | 軽い。ただし引当済みと保留の扱いで数が変わる |
| 出荷実績の照会 | いつ何個出たか、どのロットが出たか | 荷主・出荷番号・出荷日・SKU・ロット | 軽い。証跡が残っていれば事実の確認で済む |
| 誤出荷の申告 | なぜ違うものが届いたのか、どう対応するのか | 荷主・出荷番号・SKU・ロット・作業者・作業時刻 | 重い。原因の確定と対応の約束が伴う |
| 棚卸差異の照会 | 差異はどこで生じたのか、在庫をどう合わせるか | 荷主・SKU・ロット・ロケ・対象期間の入出庫履歴 | 重い。在庫調整と荷主との精算に関わる |
この四つのうち、上の二つは事実を引いて返す作業に近く、下の二つは調査と判断を伴います。同じキューに混ぜると、軽い照会の量に埋もれて重い案件の初動が遅れます。分類そのものは文面から機械的に判定できる余地があり、ここを最初に自動化する価値は高いと考えられます。
なお、この記事は在庫照会と誤出荷申告を受けた後の一次切り分けを扱います。棚卸で差異が出る構造そのものについては棚卸で在庫が合わない原因の特定方法を、誤出荷が繰り返される背景については誤出荷が再発する理由を参照してください。
問い合わせを受けてから担当者が動き出すまでに必要なのは、完成した回答ではなく調査の起点です。実務で機能する形は、次の三点をひとまとめにして提示することだと考えられます。
問い合わせ文から読み取れる手がかりをもとに、該当しそうな荷主・出荷番号・SKU・ロット・ロケを候補として並べます。重要なのは一つに絞らないことです。「昨日の出荷」が複数該当するなら、複数のまま出す方が安全です。絞り込みを機械が断定すると、外れたときに担当者が気づけません。
候補が決まれば、そこに紐づく記録を集められます。入出庫の履歴、ロケーション間の移動、ピッキングと検品の記録、梱包時の写真、送り状の控え、保留や出荷停止の設定。これらは別々の画面や別々の保管場所に散っていることが多く、集めて一枚に並べるだけでも初動は速くなります。
類型ごとに、確認すべき項目はある程度決まっています。誤出荷の申告なら「出荷指示の内容」「ピッキング実績」「検品記録」「梱包写真」「送り状の宛先」「同時刻の他出荷との取り違えの有無」。棚卸差異なら「対象期間の入出庫」「ロケ間移動」「返品の受け入れ」「保留在庫の扱い」。この一覧を最初から添えておくと、担当者が違っても抜けが減ります。
この三点セットは、経験のある担当者が頭の中でやっていることを外に出したものです。外に出しておけば、経験の浅い担当者でも同じ順序で進められ、対応の質のばらつきが小さくなる可能性があります。
在庫と出荷の問い合わせは、対応の結果が荷主との精算や補償につながることがあります。取り返しがつく範囲とつかない範囲を先に分けておく必要があります。
| 工程 | AIに任せられると考えられる範囲 | 人が確定すべき範囲 |
|---|---|---|
| 受付・分類 | 問い合わせ文の読解と四類型への分類、緊急度の目安の付与 | 分類が妥当かの確認、判断のつかないものの振り分け |
| キーの特定 | 荷主・出荷番号・SKU・ロット・ロケの候補提示と、確度の低さの明示 | どの候補で調査を進めるかの決定 |
| 証跡の収集 | 入出庫履歴・作業記録・写真・送り状控えの収集と時系列での整列 | 証跡が揃っているかの確認、不足分の追加取得 |
| 差異の抽出 | 指示内容と実績の食い違いを機械的に並べる | その食い違いが問題なのかどうかの解釈 |
| 現物 | 該当ロケと対象SKUの提示 | 棚に行って現物を確認すること |
| 引当・在庫の操作 | 現在の引当状態の表示 | 引当の変更、在庫調整、WMSデータの修正 |
| 原因 | 関連しそうな事象の列挙 | 原因の確定 |
| 返品・再出荷 | 過去の同種案件での対応手順の提示 | 返品を受けるかどうか、再出荷するかどうかの決定 |
| 回答 | 集めた事実に基づく回答の下書き作成 | 荷主・顧客への回答、補償や納期に関する約束 |
特に注意したいのは引当と在庫調整です。引当を動かせば他の出荷に影響し、在庫調整はWMS上の数量を書き換える不可逆な操作です。読み取りや提示と違い、間違えたときに「見て捨てる」ことができません。ここを自動実行の対象に含めない設計を推奨します。
任せる範囲と承認を挟む位置の決め方は、AIエージェントに任せる範囲と人の承認ポイントの設計で扱っています。
3PL倉庫の在庫データは、自社のものではなく荷主から預かっているものです。ある荷主の担当者が別の荷主の在庫・ロット・出荷先を見られる状態は、機能の便利さ以前に許容されません。AIに情報を参照させる場合も、この前提は変わりません。
実務上、次の点を先に決めておく必要があります。
権限設計の一般的な考え方はAIエージェントの権限設計で整理しています。ここで述べているのは、その考え方を多荷主倉庫という条件に当てはめたものです。
読み取りの精度以外のところで止まることが多いのが、この領域の特徴です。
次のいずれかに当てはまる場合、AIより先に検討すべき手段があると考えられます。
| 状況 | 先に検討すべき手段 | 理由 |
|---|---|---|
| 荷主が知りたいのは在庫数量とロケーションだけ | WMSの荷主向け照会画面の開放 | 問い合わせ自体を発生させない方が確実で安価 |
| 問い合わせが定型のフォームで届いている | WMSやシステムの標準機能、または簡単な自動照会 | キーが構造化されて届くなら読解の工程が要らない |
| 荷主が数社で、担当者が固定されている | 現状維持、または照会テンプレートの統一 | 翻訳の属人性が問題になりにくい |
| 定型の帳票を人が転記して照会している | 定型フォーマット向けのOCR | レイアウトが固定なら、より安価で挙動が読める手段で足りる |
| 毎朝決まった画面から決まったレポートを取得している | RPA | 手順が固定された繰り返しは規則で書ける方が保守しやすい |
| 定期レポートの集計をExcelで作っている | Excelの関数・ピボット | 入力が構造化されているなら計算はExcelで足りる |
実務では、これらを組み合わせるのが現実的な場合が多くあります。定型フォームで届く照会は標準機能で自動応答し、決まったレポート取得はRPAに任せ、自由な文章で届く問い合わせの読解と候補提示だけをAIが担うという分担です。すべてをAIに寄せると、簡単に解けたはずの部分まで説明の難しい仕組みに載せることになります。
手段の使い分けの整理はAIエージェント・チャットボット・RPAの違いにまとめています。
この領域は、全荷主・全類型を一度に対象にすると例外の量で止まります。次の順序が現実的だと考えます。
この順序の背景にあるのは、回答の速さより調査の起点が誰にでも同じ形で用意される状態を先に作るという考え方です。起点が揃えば、経験の差が対応の質に出にくくなります。
荷主がWMSの画面を見られる環境があり、見たい情報が在庫数量とロケーションで足りているなら、画面の開放が最も直接的な手段になり、費用も抑えやすくなります。問い合わせが残るのは、荷主が知りたいことが画面の項目からずれているときです。「今日出せる数はいくつか」「先週の出荷分のロットは何か」「保留になっている在庫はなぜ動かないのか」といった問いは、引当や保留の状態を読み解いて初めて答えられます。画面を開放してもなお届く問い合わせがどんな種類かを数えてみると、開放で解ける分と解けない分が分かれます。
特定できると考えるべきではありません。AIが担えるのは、申告の内容から出荷番号・SKU・ロット・出荷日の候補を絞り、該当しそうな出荷実績、ピッキングの記録、梱包時の写真といった証跡を集めて並べ、確認すべき項目をチェックリストとして示すところまでです。ピッキングの取り違えなのか、ロケーションの表示違いなのか、荷主側の指示に起因するのかという原因の確定は、現物とその場の状況を見た人が行う判断です。原因が確定しないまま外部に説明すると、後から訂正することになります。
調査の手前にある「候補を集める」工程は自動化の余地があります。差異が出たSKUについて、対象期間の入出庫の履歴、ロケーション間の移動、返品の受け入れ、保留や出荷停止の設定といった関連記録を集めて時系列に並べることは機械的な作業です。一方で、差異の原因を確定することと、在庫を調整することは別です。在庫調整はWMS上の数量を変える不可逆な操作であり、荷主との精算にも関わるため、人が確認して実行する範囲として残す設計を推奨します。
そこは設計で担保すべき最重要の論点です。多荷主の倉庫では、ある荷主の担当者が別の荷主の在庫やロットを見られてはいけません。AIに参照させる場合も、人が使うときと同じ権限の範囲に閉じ、参照できる範囲を荷主単位で区切ったうえで、誰が何を参照したかを記録として残せる状態にしておく必要があります。仕組みの側で権限を持たせるのではなく、担当者の権限の範囲でしか参照できないようにするのが基本の考え方です。
そのまま送るべきではないと考えます。在庫や誤出荷に関する回答は、その後の補償や再出荷、返品の受け入れといった話につながることがあり、一度出した内容は取り消しにくい性質を持ちます。AIが作れるのは、集めた証跡に基づく回答の下書きまでです。事実として確定しているか、まだ確認中か、といった区別を含めて担当者が読み、必要な修正を加えたうえで送る前提にしておく必要があります。約束にあたる部分は特に人が書く範囲として残すのが安全です。
仕組みの話をする前に、実際に届いている問い合わせを在庫照会・出荷実績照会・誤出荷申告・棚卸差異照会に分け、どこに時間がかかっているかを一緒に見るところから始められます。WMSの照会画面の開放や定型フォームで足りると判断した場合は、そのように申し上げます。
在庫照会・誤出荷対応の整理について相談する