WES補充トリガー：forward pickゾーンが枯渇する前に補充を始める方法

結論から先に。forward pickゾーンの補充トリガーは、1つのトリガーに頼るな。30回以上のWES導入をやってきて、プロジェクトが死ぬ最も一般的なパターンだ。レベルトリガーだけを設定して、初日にピッカーが空のスロットの前に立ち尽くし、補充タスクはキューに眠る。実際に機能する設定は3つのトリガータイプを重ねる。在庫レベルがフロアを支え、波動需要予測がリードタイムを買い、時間ウィンドウが安全網になる。この記事では各トリガーの設定と失敗事例、そして補充とピッキングが人員と設備を奪い合う時の優先順位付けを扱う。

なぜ1つのトリガータイプでは決して足りないのか

forward pickゾーンには組み込みの矛盾がある。スロットは小さく回転が速い。ピッカーの移動を減らすためにファストムーバーを手の届く高さに置きたいが、エルゴノミックなスロットは在庫をあまり持てないし、1つの大きな波で枯渇する。WESがここでやるのは時間の数学だ。スロット在庫がどれだけ持つか、補充にどれだけかかるか、その2つの数字の差がピッカーを待たせるかどうかだ。

各トリガータイプはそのうち1つの問いにしか答えない。レベルトリガーは「今どれだけ残っているか」に答える。波動予測トリガーは「どれだけ消費されようとしているか」に答える。時間ウィンドウトリガーは「何か見落としたか」に答える。1つだけ設定するのは片目で運転するようなものだ。

トリガータイプ1：在庫レベル（Min/Max）——フロアを支える

最も単純なロジック。ピックフェイスの在庫がminを下回ったら補充タスクを生成する。maxで止める。設定チェックリスト。

minは（補充リードタイム中の最大消費量）＋安全バッファで設定する——最大値で、平均ではない。平均で設定すればプロモ日の破綻が保証される。
maxは物理スロット容量から10〜15%の作業スペースを引いた値にする。スロットに詰め込みすぎると、補充者が手戻りなしに商品を入れられなくなる。
min/maxをABC速度で段階化する。Aムーバーはminを上げ、Cムーバーは低く抑えて、スローSKUに補充労働力を燃やさない。
移動中の補充数量を除外する。既に生成済み・未実行のタスクをトリガー計算から差し引く。さもなければスロットに重複発注がかかる。

この失敗を3回見た。最悪は中国東部のEコマースDCで、1日約20,000オーダー、minが平均日次消費量で設定されていた。プロモ日の午前10時、ホットSKUのピックフェイスが40分で枯渇したのに、補充リードタイムは25分——minはタスクを発火させるほど長く持たなかった。さらに悪いことに、システムは同じスロットに3件の重複発注を出した——誰も移動中数量を除外していなかった。修正。ホットSKUのminを時間帯別ピークで再設定し、重複排除ロジックを一晩で追加した。それ以来、「移動中除外」は俺の本番前夜チェックリストの必須行だ。

トリガータイプ2：波動需要予測——リードタイムを買う

ロジック。WESが波動計画を受け取ったら、各SKUの波動需要から逆算する——ピックフェイスが波動を乗り切れなければ、補充タスクを早めに生成する。設定チェックリスト。

「波動需要＋進行中オーダー」で予測し、履歴の日次平均だけに頼らない。履歴は今日何を出荷するかを知らない。
トリガーしきい値を逆算で求める。まず「波動開始のX分前に補充を完了させる」を決め、そこからタスクのリリース時刻を逆算する。
データ品質ゲートを追加する。波動計画のSKUカバレッジが95%を下回ったら、自動でレベルトリガーにフォールバックする。不完全なデータで予測するな。
ホットSKUとプロモSKUには独自ルールを与える。通常SKUとしきい値を共有しない。

失敗事例。ある3PLは見事な予測トリガーを持っていたが、波動計画は手動インポートのスプレッドシートで、日常的に2時間遅れだった。すべての予測は古いデータで走った——タスクは1時間早く発火したり、次の1時間は遅れたり。教訓は率直だ。予測トリガーは上流データの質までしか良くならない。WESには鮮度チェックが必要だ——波動計画が設定ウィンドウ内に更新されていなければ、レベルトリガーにフォールバックしてアラートを上げろ。

トリガータイプ3：時間ウィンドウ——安全網

ロジック。固定時刻にピックフェイスを一掃し、ライン以下のものをすべて補充する。設定チェックリスト。

ウィンドウは波動の間の隙間に置く——出荷ピーク中の掃引は絶対にダメだ。補充タスクの洪水がノイズになるだけだ。
安全網のラインはminより緩くていい。その仕事は最初の2つが見落としたものを拾うことで、重労働ではない。
スロットルをかける。ウィンドウあたりの補充タスク数に上限を設け、1回の掃引でフロアを洪水にしない。
ウィンドウあたりタスク数を指標として追跡する。連続してゼロのウィンドウは最初の2つのトリガーが健全な証拠。急なスパイクは上流で何かが壊れた証拠だ。

失敗事例。ある倉庫はウィンドウを「毎時ちょうど」に設定した。各掃引で200件以上の補充タスクが生成され、チームは処理しきれず、バックログは雪だるま式に膨らみ、WESのタスクプールは完全に詰まった。修正。4時間に1回のウィンドウで、ウィンドウあたり60タスクの上限だ。覚えておけ。安全網は見落としを拾うためのもので、本業をやるためのものじゃない。

3つの比較：何を選び、どう組み合わせるか

次元	レベルトリガー	波動予測	時間ウィンドウ
解決する問題	枯渇させない	待たせない	見落とさない
発火タイミング	在庫がminを下回る	波動計画が届き、逆算	固定時刻の掃引
強み	単純、堅牢、上流データ不要	最大のリードタイム、プロモに強い	最も作りやすく、全部拾う
弱み	反応的。minを間違えれば失敗	波動データの品質次第	頻度が高すぎるとタスクプールが洪水
最適	すべての倉庫のベースライン	信頼できる波動計画を持つ倉庫	他の2つの補完
俺の推奨	必須、ABC段階化	波動計画が信頼できるなら設定	必須、ただしスロットル付き

ここからが反直感的な話だ。**早いトリガーが常に良いとは限らない。**補充を早く発火させればタスク数が爆発する——補充者とピッカーが通路と設備を奪い合い、ピック生産性が落ちる。極端な例も見た。minが高すぎてスロットが空になることはなかったが、補充がフロア労働力の40%近くを食い、ピッカーは一日中補充カートを避けて回った。補充ロジックの目標は「スロットが常に満杯」じゃない。「ピッカーが商品を待たない」だ。この2つの目標はちょうど1リードタイム分離れている。その距離を正確に取ることが、水位を上げるより大事だ。

フロアで頑丈ハンディに送られた補充タスク

補充とピッキングが労働力を奪い合う時：優先順位の付け方

これはほとんどのチームが逆にやるルールだ。俺の優先順位リスト——1行1行がプロジェクトで金を払って学んだものだ。

通常は、ピッキング（出荷）が日常の補充より上だ。出荷は顧客への約束。補充は内部の効率だ。顧客への約束が常に先だ。
ただし緊急補充は通常のピッキングより上だ。スロットが空で波動がそれを待っている時、そのスロットのピックタスクはどうせ死んでいる——先に補充してからピックだ。
設備を分ける。補充者はリーチトラックかパレットジャッキ、ピッカーはオーダーピッカー、時間か通路でずらす——同じ通路での正面衝突デッドロックなしだ。
WESで優先順位を動的にする。波動開始の30分前に補充タスクを自動昇格させる。波動が走り始めたらピッキングを昇格させる。ハードコードの優先順位はいずれ片方を罰する。
シフト引き継ぎ。未完了の補充タスクは明示的なチェックリストで引き継ぐ。「次のシフトがやるだろう」は絶対にダメだ。次のシフトは忙しくなって、タスクは消える。

この失敗を3回見た。いつも同じ脚本だ。ある本番前夜、クライアントは「補充優先」にこだわった。「ピッカーを待たせてはならない」からだ。プロモ日、補充者がすべての主要通路を塞ぎ、ピッカーはカートを入れられず、出荷SLAが爆発した。一晩で「ピッキング優先、緊急補充は列に割り込み」にひっくり返したら、翌日は回復した。だから補充ファーストかピッキングファーストかで俺と議論するな——答えは「場合による」だ。WESが自動で切り替えるようルールに書け。