WMSに声で聞いてみる：自然言語での在庫照会はもう十分正確か？

結論から先に：自然言語での在庫照会は今日でも動く——ただし狭いレーンの中でだけだ：統制された語彙＋確認ステップ。思いつきで何を言っても毎回理解してくれると期待する？まずは自分の倉庫で試してみてほしい。私が見てきた現場の多くはまだそこまで行っていない。

この失敗はちょうど3回見た。1回目は2025年秋、中国東部の3PL。現場スーパーバイザーに在庫数を「ただ聞くだけ」にさせたかった。スーパーバイザーがタブレットに向かって「Aゾーンの3C製品の利用可能在庫はどれくらいある？」と話しかけると、システムが即答する。滑らかそのもの。3週目に爆発した：システムが出した数字をもとに販促出荷を準備したところ、パレットが2つ足りず、緊急輸送を手配する羽目に。1回の緊急陸送で3か月分の人件費削減が吹き飛んだ。事後分析で致命的な問題が2つ見つかった。まず、彼らのWMSには「3C製品」というカテゴリがそもそも存在しなかった——モデルがそれを「家電製品」だと幻覚し、スマホケースやケーブルを巻き込みながら、実際の3Cアクセサリの半分を落としていた。次に、「モデルA」は2つのSKU（赤と青のバリエーション）として存在していたのに、システムは1つしか照会していなかった。その倉庫のスラングでは「モデルA」が2つセットのファミリーだとは、システムは知らなかったのだ。

2回目はeコマース倉庫で、こちらは正しくやった。理由は3文で説明できる：語彙はモデルが推測したのではなく人間が定義した。すべての回答はまず「こう理解しました」と示し、タップで確認を待った。すべての数字には出所が付いていた。質問できる次元をホワイトリスト化した——倉庫、ゾーン、カテゴリ、SKU、ロット、在庫ステータスの6次元。各次元に人間が管理する類義語マップを付けた。「3C製品」がリストにない？システムが聞き返した：「3C製品は検索可能なカテゴリではありません。デジタルアクセサリか家電製品のことでしょうか？」作業員は1回タップした。10秒。その確認ステップは不格好に見える。それが精度を守るヒューズだ。

3回目はもっと厄介だった：昨年の化粧品倉庫で、SKU名がすべて色名だった——「チェリーピンク」「ピーチピンク」「あずきピンク」。モデルは3つが似ていると判断して類義語として統合してしまい、「ピンクはあとどれくらいある？」と聞くと3つのSKUの在庫を合計した数字が返ってきた。循環棚卸と合わず、倉庫チームはeコマース運用チームと怒鳴り合いになった。教訓：色合い、仕様、バージョン——類義語に見えて絶対に統合してはいけないもの——は、マッピング表に明示的な「統合禁止」フラグが必要だ。類義語表は「大きければ大きいほど良い」の世界ではない。間違った1件は、欠けた1件より痛い。

最初の3PLはどう立ち直ったか？3ステップだ。まず自由形式の質問を廃止し、「次元を選んでから聞く」に切り替え、質問できるものをすべて檻の中に入れた。次にベテランのスーパーバイザー2人を2週間座らせ、類義語マップを200件超まで作り上げた。スーパーバイザーは最初は文句を言っていたが、台帳をめくるより3倍速いことに気づき、自ら進んで使い始めた。3つ目に、すべての回答に出所とタイムスタンプを必ず付けさせた。2か月後、誤った回答はほぼ消えた——注意してほしいが、モデルが賢くなったわけではない。檻が狭くなったのだ。

ボトルネックはモデルではない、と私が言うのはなぜか？パイプラインは4ステップで、私はそのすべてで転んだ。

自然言語での在庫照会の仕組み：4ステップ、4つの落とし穴

意図認識：「あとどれくらい残っている」を「利用可能在庫を照会する」に翻訳する。モデルが一番得意なところ。一番心配のいらない部分だ。
エンティティマッピング：「Aゾーン」や「3C製品」を実際のWMSマスターデータに紐づける。ここが惨事ゾーンだ。1つの商品に3つの名前、カテゴリ項目の半分が空欄、新旧のゾーンコードが混在——マッピング表はここで死ぬ。ルールは1つ：モデルがマッピングできるのは、存在して一意なものだけ。マスターデータにないものは推測する。推測は外れる。
WMS API呼び出し：マッピングを実際のAPI照会に変換する。クリーンな読み取り専用照会APIが必要だ。レガシーWMSの照会エンドポイントの多くは人間向けレポート用に作られており、項目定義が在庫台帳と一致しない。だから2つの数字が食い違い、作業員がどちらかを選ばなければならなくなる。
結果検証：表示する前に回答をチェックする。正しくやったeコマース倉庫はここに厳格なルールを追加した：すべての回答に出所を必ず付ける——「出所：Aゾーン利用可能在庫台帳。フィルタ：zone = A AND category = デジタルアクセサリ。10分前に更新。」出所なしでは表示しない。

現場の倉庫在庫ダッシュボード

自然言語での在庫照会パイロット前チェックリスト

マスターデータが先、3つの関門：SKUの重複排除、カテゴリ項目の補完、ゾーンコードの統一。これを飛ばしたら後はすべて茶番だ。
質問できる次元をホワイトリスト化：最初は3〜5つ。初日に全部は開けない。
類義語マップは手作り：現場スーパーバイザーと座り、スラングを1つずつシステムコードに紐づける。1日の作業。価値はある。
確認は必須：システムが「こう理解しました」と示し、数字が出る前にユーザーが確認する。摩擦が大きすぎると感じたら、その機能は出荷するな。
まず読み取り専用：パイロットは照会だけ。書き込みは絶対にしない。モデルに残高調整や在庫ステータス変更をさせる？その失敗は3回見た。4回目はごめんだ。
すべてを計測する：各質問、システムの解釈、ユーザーが修正したか、何を修正したかをログに残す。3か月後、そのログはマッピング表改善の金の鉱脈になる。
「誤回答」のフォールバックを定義する：照会が外れたとき、是正プロセスは何で、責任者は誰か。本番稼働の前に、嫌なことは決めておく。

直感に反する話をしよう。よく聞かれる、「99%の精度に到達できますか？」私の答え：質問が間違っている。精度の天井はモデルでは決まらない。マスターデータがどれだけきれいかで決まる。マスターデータがぐちゃぐちゃなら、モデルは自信満々の回答をでっち上げるインターン。マスターデータがきれいなら、素早く数えるベテランだ。まずマスターデータを掃除して、それから自然言語の話をしよう。それは順序の問題であって、技術の問題ではない。

元の問いに戻ろう：自然言語での在庫照会の精度はもう十分か？モデル次第ではない。3つのこと次第だ：語彙が定義されているか、確認が組み込まれているか、マスターデータがきれいか。3つとも揃っていれば——進めていい。1つでも欠けていれば——先に宿題をやろう。

Lin Xiao（WMS導入コンサルタント）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。