ひとつ話をさせてくれ。長年トラックを運転してきて、いちばん怖いのは渋滞じゃない。間違った注文だ。特に、小さな顧客のExcelがWMSに間違って入ったときはな。
去年の10月、私はオンタリオの3PL倉庫の列に並んで、荷下ろしを待っていた。ロングビーチ港の近くで積んだ小型家電、400カートンほどを、ラスベガスの配送拠点へ運ぶところだった。荷主は小さな事業主で、全部で7人。彼自身がIT部門だった。持っているのはExcelだけだ。毎日午後、その日の注文をExcelに書き出して倉庫にメールで送り、倉庫の若い子が1行ずつWMSに手入力していた。
その日、事件が起きた。スプレッドシートのSKUはHD-2204Bだった。若い子の指が滑って、HD-2204Dと入力した。1文字違いだ。ラスベガスに着くと、受取人が型番をチェックして、積荷まるごと拒否された。私は400カートンをそのまま持ち帰った。往復500マイル以上、2日間がパーになり、ディーゼル代だけでも1000ドル近くを無駄に燃やした。事業主は電話で倉庫のマネージャーに怒鳴った。マネージャーは人手不足で、ミスは起きると言った。事業主は、1日に数十件しか送っていないのに、それすら正しく入力できないのかと言った。運送会社が運賃の半分を負担した。私たちはそれを飲み込んだ。
ここがポイントだ。ITがいない小さな顧客は怠け者じゃない。本当に誰もいないのだ。3PLが彼を厄介者扱いすれば、彼は向かいの倉庫へ行ってしまう。でも大切にすれば、彼は毎年何万カートンもの荷物を、時計のように規則正しくくれる。
ITスタッフがいない?このCSV/SFTP連携プレイブックが効く
昼食をともにするうちに、私はその倉庫マネージャーとすっかり親しくなった。彼は、20数社の顧客の半分が「Excel顧客」だと言った。大手はEDIやAPIを持っている。一度連携すれば1年は忘れていられる。小さな顧客はどうか。今日はExcel、明日はチャットのスクリーンショット、翌日は電話だ。彼はAPI連携に移行させようとした。半分はAPIが何かすら知らなかった。
そこで彼らはローテクな方法をまとめた。ITスタッフのいない顧客向けの、平易な言葉で書かれたCSV SFTP WMS連携プレイブックだ。正直、素晴らしいと思った。さて、君たちのIT用語は私には難しすぎる。ドライバー流に説明しよう。
方法その1:ロックされたCSVテンプレート。
CSVはExcelの「名前を付けて保存」だと思えばいい。倉庫は小さな顧客一人ひとりに固定の注文テンプレートを送る。どの列を、どの順番で、日付はどの形式で、数量は必ず数字で。すべて固定だ。カンマ1つたりとも変えてはいけない。顧客は毎日そのシートに記入して送る。
その倉庫には大好きな工夫があった。1行目は見出しではなく、記入済みのサンプルなのだ。事業主はパターンを真似するだけだ。間違えようがない。ファイルが届くと、WMSがまず自動チェックする。数量の列に文字が入っていたり、日付が「2026-10-05」ではなく「10/5」になっていたりすれば、ファイル全体が、壊れた行を平易な言葉で示すメモ付きではね返される。
手入力の時代は、若い子が1日に数百行を入力し、昼食を過ぎると1時間ごとにエラーが増えていった。今ではCSVの取り込みは5分で終わり、ミスがあってもそれは顧客のタイプミスだ。責任の所在は明確だ。
方法その2:スケジュールされたSFTPでの受け取り。ファイルに自分で飛ばせよう。
毎日メールを送ることすら面倒がる顧客もいる。SFTPは鍵のかかったファイル投函ボックスだと思えばいい。倉庫が顧客にアカウントを渡し、顧客は毎晩CSVをボックスに入れる。WMSがスケジュール通り、たとえば午前2時に取りに行き、チェックして取り込む。朝のシフトが始まるころには、注文はもうシステムに入っている。
これは、毎日午後4時に時計のようにアップロードする事務マネージャーにぴったりだ。誰も見張っていない。ファイルは自分で飛び、1つでも欠ければシステムが騒ぎ立てる。ランチョクカモンガの小さな自動車部品顧客の事務マネージャーは、午後4時のアップロードを一度も欠かさなかった。3か月連続、エラーゼロだ。彼女は今では4:05に帰って子どもを迎えに行けると言っていた。
方法その3:メール添付ファイルの解析、最後の手段。
毎週SFTPのパスワードを忘れ、それでもテンプレートを正しく埋められない顧客が必ず1、2社いる。彼らと戦うのはやめよう。専用の受信箱を用意し、件名に「注文+日付」を必須にして、WMSがタイマーでそのメールボックスを巡回し、添付ファイルを取り出して解析し、取り込むようにする。メールが送れれば、それで連携完了だ。
正直な比較がこちらだ。
| 方法 | 顧客に必要な知識 | 倉庫の手間 | エラー率 | 向いている規模 |
|---|---|---|---|---|
| メールでのCSVテンプレート | Excelへの記入とメール送信 | テンプレート+検証ルールの作成、半日 | 低い。不良ファイルははね返される | 1日数十件 |
| スケジュールされたSFTPでの受け取り | フォルダにファイルを置くこと | アカウント+スケジュールの設定 | 非常に低い。自動で動く | 1日数十件から100件 |
| メール添付ファイルの解析 | メールを送ること | メールボックスのルール設定 | 中程度。件名の間違い=ファイルの取り漏れ | 1日十数件 |
そして、あえて逆張りの意見を言おう。小さな顧客にはAPIは不要だ。固定されたCSVテンプレートのほうが、APIよりも安心できる。 APIは格好良く聞こえるが、顧客側にはそれを維持する人がいない。今日は動く。来月、彼がメールアドレスを変えたり、パスワードをリセットしたりすれば、接続は切れ、誰かを修理に送ることになる。CSVは見た目が悪いが、向こう側の誰にも依存しない。ファイルの形式が正しければ入る。間違っていればはね返される。責任は明確だ。これだけ長く運転してきて、私は1つ信じている。部品が少なければ、故障も少ない。
CSVフィールドマッピングの罠:毎日変わる列名
ローテクだからといって罠がないわけではない。最大の罠はフィールドマッピングだ。平易に言えば、顧客のシートの列名がWMSのフィールド名と一致しないことだ。
私が見た最悪の顧客はこうだった。月曜日は列名が「Item#」、水曜日は「SKU」、金曜日は「製品番号」を意味する中国語の言葉だった。取り込みは列名で照合していたので、名前を1つ変えただけでファイル全体が空白になってしまった。数十件の注文がシステムの外に取り残され、トラックがゲートでアイドリングしていた。私はかつてこのせいで4時間も待たされたことがある。
マネージャーは3つの対策を教えてくれた。どれも確かなものだ。
第1に、変換テーブル。 システム内にマッピングを保持する。顧客の「Item#」も「SKU」も「製品番号」も、すべてシステムのsku_codeに変換される。顧客が何と呼ぼうと、テーブルに載っていればいい。新しい顧客が来たら、半日かけて古いファイルの列名をすべて記録する。
第2に、厳格な検証ルール。 数量の列は必ず数字でなければならない。日付の列は2026-10-05のような形でなければならない。SKUの列は空ではいけない。1つでも失敗すればファイル全体がはね返される。1行たりとも入らない。建物の中に汚いデータを入れるくらいなら、30分遅れるほうがましだ。汚いデータが一度入ってしまえば、出荷全体が間違う。
第3に、新しいテンプレートには必ず3日間の目視チェック。 顧客が新しいテンプレートを初めて使うとき、あるいは列名を変更したときは、3日間、人が1行ずつチェックする。マッピングが正しいことを確認してから、自動取り込みをオンにする。これを省いてはいけない。この3日間が、3か月分の火消しを救ってくれる。

1日1回、照合しよう。一晩寝かせてはいけない。
最後の1つ、マネージャーの秘密兵器だ。終業の15分前に、その日の照合をする。
WMSの出荷注文数を、顧客のファイルの注文件数と突き合わせる。数字が合わなければ、理由が分かるまで誰も帰れない。ファイルが取り込まれなかったのか。取り込まれたが出荷されなかったのか。顧客がファイルを2回送ったのか。15分間、毎日、例外なしだ。
この15分を侮ってはいけない。月末の争いを何度も見てきた。顧客は100件と言い、倉庫は98件と言う。残りの2件が出荷されたことを誰も証明できず、損失を折半する。毎日照合すれば、問題は生まれたその日に表面化する。月末はただの形式になる。
3PLの仲間への一言の助言だ。小さな顧客を厄介者扱いしてはいけない。 大きな顧客はありがたいが、契約は3年ごとに更新され、1社失えば骨が折れる。小さな顧客は1社ずつ見れば大したことはないが、積み重なれば君たちの土台だ。CSVテンプレート、SFTPでの受け取り、毎日の照合をきっちりやれば、小さな顧客は大きな顧客よりもスムーズに回る。向こう側は1人、こちら側はほとんど誰もいらないのだから。
古い諺がある。髪1本のずれが、1マイルのずれになる。SKUの1文字の間違いが、私に500マイルの空走を強いた。書類を正しく整えれば、トラックは正しく走る。その真実は高速道路でも、倉庫の中でも同じだ。
Shifu Zhao(トラック輸送ベテラン、15年)著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。







