私たちには、あるクライアントがいました——中国東部で日用消費財ブランドのフルフィルメントを運営する3PLです。昨年、この会社はAI需要予測システムに7桁ものお金を投じました。営業デモは見事でした。過去の売上データを入れれば、全SKUに8週間分の補充推奨を出してくれる——スライドには「精度90%超」。オーナーはその場でサインしました。
導入から3か月後、倉庫マネージャーから愚痴の電話がかかってきました。システムの補充提案は、調子のいい日は予知能力のように当たり、悪い日は破壊工作のようでした。あるとき、キッチンペーパーのSKUを3か月分も積むように提案してきました——そのSKUがちょうどパッケージをリニューアルしたばかりで、旧パッケージのSKUがシステム上でまだ生きていたため、AIは両方の売上履歴を足し合わせて「この商品は爆売れ中」と結論したのです。倉庫は危うくキッチンペーパーで溺れるところでした。
私はオーナーにはっきり言いました。あなたのAIプロジェクトは、アルゴリズムでは死んでいない。データで死んだのです。輸入エンジンを買って、廃油を注いでしまったのです。
AIベンダーが決して自発的に語らない業界の内情
私は3PLサービスを長く売ってきて、倉庫契約書を100通ほどサインしてきましたし、AIプロジェクトが潰れていくのを何度も見てきました。テーブルをはさんだベンダー側からの業界の内情をひとつお教えしましょう。契約締結前にあなたのデータ品質を真剣に監査するAIベンダーは存在しません。
なぜそんなことをするでしょう？監査をすれば契約が潰れるかもしれません。営業はサインが欲しい。データ品質は「導入フェーズの問題」扱いです。契約書のデータ条項はたいてい1行だけ。「甲は必要な事業データの提供を行うものとする」。何が必要で、「提供」とは何で、どれくらいきれいなら十分なのか。何も定義されていません。そして導入後のパフォーマンスが期待外れに終わり、ベンダーは肩をすくめます。あなたのデータが悪いのです——ゴミを入れればゴミが出る。技術的には正しい。でも請求書はあなたに回ってきます。あなたが優位に立てたときに、データの責任を交渉しなかったのですから。
私が見た最悪のケース：華南のある自動車部品商社、SKUは50,000点超、私の見積もりでは重複コード率が15%——同じブレーキパッドが、購買ではひとつのコード、倉庫では別のコード、ECチームではまた別のコードでした。AI補充システムが稼働した後、モデルは3つのコードを3つの商品とみなし、それぞれの売上履歴が薄いため、すべての予測がノイズになりました。ベンダーは導入コンサルタントを「データクレンジング」のために送り込み、日給制で2か月がかり、クレンジングの請求書は数十万元に達しました。オーナーは激怒しました。データ清掃がソフトウェアより高くついたのですから。
率直に言いましょう。AIプロジェクトのデータ準備は、ベンダーがあなたの代わりに払ってくれるお金ではありません。サインする前に少しだけ自腹でデータをきれいにするか、サイン後にベンダーに高いお金を払ってきれいにしてもらうか。このお金は避けられません——選べるのは、先に払うか、後から払うかだけです。
倉庫データの4つの慢性病——あなたはいくつ当てはまる？
クリーンアップの前に、倉庫の健康診断をしましょう。4つの病気、10倉庫中9倉庫は少なくとも2つを抱えています。
- ひとつの商品、複数のコード。 同じ商品が購買・倉庫・販売で複数のSKUコードを持っています。AIは、ひとつのものを3つの「商品」と見ます。
- 混沌としたロケーションコード。 旧棟は旧棟の体系、新棟は新棟の体系、WMSはまた別体系。あるクライアントは3つのロケーション体系を並行運用していました——AMRが稼働した後、「商品が見つかりません」エラーを毎日吐き出し、ロボットがフロアをぐるぐる回る後ろで人が後片付けをしていました。
- 欠落した履歴資料。 予測モデルは12–24か月分のきれいな売上履歴を欲します。多くの倉庫では、その履歴は営業マンのスプレッドシートの中——退職のたびにドアの外へ歩いていきます。
- Excel vs システム：ふたつの真実。 WMSの言うことと、シフトリーダーのスプレッドシートの言うことが違います。棚卸はExcelで回し、システムは「だいたい」で回っている。AIが見るのはいつも「だいたい」の方だけです。
三段階のクリーンアップ：AIを買う前にデータを直す
ステップ1：マスターデータガバナンス——ひとつの商品にひとつのコード。ここから始める。
これが土台です。倉庫・購買・IT（またはシステム管理者）から1人ずつ、3人のチームを作り、唯一のミッションはSKUマスターデータの統一です。具体的には：全SKUをエクスポートし、品名・仕様・バーコードでファジーマッチングし、重複疑いを人間の目で確認し、正規コードを1つ指定して残りをそこにマッピングし、今後は別名コードの新規作成を禁止します。そしてルールを定めます。新規SKUはすべて入場プロセスを通す——重複チェックなしにコードは作らない。勝手なコードを作った者が責任を取る。
通常4–8週間かかります。急がないでください。土台がぐらつけば、その上にあるものはすべて危険です。
ステップ2：プロセスデータを遡及補充——履歴を取り戻す。
AIは履歴データを食べて育つので、履歴を与えましょう。24か月分の入出庫記録・売上・プロモーション・返品を引っ張り出し、回収できるものは回収します。そのExcel台帳はゴミではなく金鉱です——インターンか外注チームに重要項目を構造化してシステムに入力させましょう。本当に回収できない月は、正直に「欠落」とマークします。穴埋めのためにデータを捏造してはいけません。モデルはスカスカなデータを許容しますが、偽のデータを許容しません。 宣言された欠落はモデルが上手に扱いますが、捏造された数字はモデルをそのまま溝に導きます。
ステップ3：データ品質ゲート——汚いデータを入れない。
クレンジングは一回きりのイベントですが、ゲートは永続的です。WMSに3つの厳しいルールを設定します。新規SKU作成は重複チェック必須（バーコード/品名の類似警告）、入庫はスキャンと照合必須——スキャンできないコードを「手入力で完了」で通してはいけません。そして月次データ品質レポートを回し、重複コード率・ロケーション異常率・資料欠落率を追跡し、閾値を割ったら赤ランプと責任者の名前を出します。
この3ステップを終えれば、倉庫のデータ品質は「AI対応」の合格ラインに届きます。通常3–6か月かかり、コストはほぼ人件費——AIソフトウェア本体の10分の1程度です。でも7桁のソフトウェア予算がお札製造機を買ったのか、高級な文鎮を買ったのかを決めるのは、このプロセスです。
逆説的な結論：データが汚いほど、AIを先に買うべきではない
最後にもうひとつ、常識に反する話を。多くのオーナーは「うちのデータはぐちゃぐちゃだから、むしろAIで管理する必要がある」と考えます。ロジックが逆です。AIはデータの増幅器であり、データの掃除人ではありません。 きれいなデータなら、AIは効率を10倍にします。ゴミデータなら、AIはミスを10倍にします——その増幅に7桁を請求しながら。
順序は絶対に譲れません。まずデータを合格ラインまで持っていき、それからAIを入れましょう。そして営業マンが「うちのアルゴリズムは汚いデータを自動処理します」と言ったら、その一文を契約書の性能条項に書くよう頼んで、書く勇気があるかどうかを見守りましょう。
次にAI契約を交渉するときは、この3つの質問をしてみてください。
- データ準備の責任者は誰で、「準備完了」とは具体的に何を指しますか？ 受け入れ基準を契約書の付属文書に入れ、数値化しましょう。重複コード率、資料完備率、具体的な指標を。
- モデルの性能が期待外れだった場合、支払いは成果とどう連動しますか？ 留保金の割合、性能保証、パイロット期間——すべて文書で。口約束の精度保証は、インクの価値ゼロです。
- パイロットの期間はどのくらいで、どんなデータで検証しますか？ 自社のリアルな履歴データでバックテストしなければなりません——ベンダーのデモデータセットでは決してありません。デモデータセットに重複SKUコードが含まれることは決してありません。
覚えておいてください。AIの世界では、ベンダーはシャベルを売り、金を掘るのはあなたです。鉱山が岩だらけなら、どんなに鋭いシャベルも無駄です。まず岩を拾って、それからシャベルの議論をしましょう——この順序さえ正しければ、2年分の授業料を節約できるかもしれません。
Susan（3PLセールスディレクター）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
