まだ格納するな：WES格納最適化とワンタッチ削減の計算

まず結論から言います。**ほとんどの倉庫は、本来不要だった1回の荷役タッチにお金を払っています。**貨物が到着し、受入エリアでバラされ、保管エリアに格納され、数日後にはまたピックされて出てきます。同じパレットがフォークリフトに2回触られます。これはまさにお金を垂れ流しているようなものです。

WES格納最適化はまさにこの問題を解決するためのものです。貨物が到着した瞬間、システムはすでにその行き先を把握しています。そのまま出荷に直結できるものは出荷ステージングやピックフェースに直行し、本当に保管が必要な貨物だけが保管ロケーションに入ります。1回タッチを減らすのはフォークリフトの燃料を節約することではありません。その1回のタッチに付随するすべてのコストを消し去ることなのです。

なぜこの判断をWMSではなくWESが担うべきなのか

WMSでも格納ルールは設定できます。売れ筋上位品をドック近くに、重い貨物は低い位置に、といった具合です。しかしWMSのルールは静的です。今まさに起きていることは見えません。

特に印象に残っている事例があります。違う顧客で3回見てきた落とし穴です。2023年11月、上海郊外の3PLが小型家電向けに18,000平方メートルの拠点を運営していました。Singles' Dayの前週、受入エリアは400+パレットの貨物に埋め尽くされていました。フォークリフトのドライバーたちは朝8時から夜10時まで働いても、格納が追いつきません。オーナーは私にこう聞きました。「重要度別の格納ルールを設定したのに、なぜ忙しくなるほど悪化するんだ？」と。

3日間のデータが理由を教えてくれました。**ルールは正しかったのですが、タイミングが間違っていました。**400パレットのうち120パレットは、翌朝出荷の出庫オーダーにすでに引き当てられていました。静的なルールはそれらを忠実に保管エリアに入れ、翌日ピッカーがすぐに取り出しました。120パレット、何のためでもない余分な1回のタッチです。

WMSは貨物の置き場所を教えてくれます。WESは今そこに置くべきかどうかを教えてくれます。動的格納オーケストレーションは4つのライブ入力を重み付けします。

**未充足需要：**今後24–72時間でこの貨物を必要とする出庫オーダー（または計画ウェーブ）はありますか。
**保管の実態：**対象ロケーションは満杯ですか、半分ですか、それとも今は存在しませんか。
**リソースの状態：**フォークリフトは手いっぱいですか。フロースルーレーンは空いていますか。
**貨物の特性：**消費期限、ロット要件、混載パレット。

静的なルールは4つ目だけを見ます。WESは4つすべてを見ます。

フロースルー導入の4ステップ

ステップ1：受入時に目的地をタグ付けする——ロケーション割当の前に

従来の流れ：受入 → QC → WMSがロケーションを割当 → 格納。新しい流れ：受入 → WESが目的地を算出 → タグ付け（フロースルー／補充直行／保管）→ タグ別に振り分け。

タグ付けのロジックはWESの判断エンジンにあります。導入時のテンプレート例は次の通りです。

今後48時間の出庫需要が入庫量の80%以上をカバーする → フロースルー
需要はあるが80%未満をカバーし、ピックフェースの在庫が補充トリガーを下回っている → 補充直行（ピックフェースに直行）
短期の需要がない → 保管（通常の格納ルール）

48時間というウィンドウは恣意的ではありません。短すぎるとフロースルーの量が立ち上がらず、長すぎると予測が当てにならなくなり、貨物がステージングに山積みになります。私は通常、顧客には48時間から始めてもらい、2週間のデータで調整します。上海の3PLは36時間に落ち着きました。彼らは1日に2つのオーダーウェーブを回しており、36時間はちょうど3つのウェーブをカバーするからです。

ステップ2：フロースルーを階層化する——一種類ではありません

フロースルーにはコストとリスクのプロファイルが大きく異なる3つの形態があります。

形態	内容	適したケース	注意点
フルパレット・フロースルー	受入から出荷ステージングへパレット全体を移動	大量、単一SKU、フルパレット出庫	スペース不足でステージングレーンが詰まる
ブレークバルク・フロースルー	受入時にパレットをバラしてオーダー別に仕分け	複数SKU、小ロット、通販オーダー	ブレークバルクの人件費が高い
補充直行	保管をスキップしてピックフェースに直行	ピックフェースの在庫が低下、入庫がジャストインタイム	ピックフェースの容量は限定的

判断フレームワークはシンプルな2×2です。横軸は「入庫量と短期需要の適合度」、縦軸は「SKUの集中度」です。右上（適合度高、SKU集中）→ フルパレット・フロースルー。左上 → ブレークバルク・フロースルー。下半分 → ピックフェースを確認し、収まるなら補充直行、収まらなければ保管です。

WES動的格納オーケストレーションの図

ステップ3：役割分担を書き出す——WES、WMS、設備

これは本番稼働前夜のチェックリストに、交渉の余地なく入れます。**目的地の判断はWES、ロケーション割当の実行はWMS、物理的な移動はMHE（コンベヤー／AGV）**が担います。3つの層をインターフェース仕様書に明記し、障害が起きたらログを読んでどの層が失敗したか分かるようにします。

受け渡しは次の通りです。

WESがASNを受け取る → 3秒以内に目的地タグとターゲット（ステージングレーン／ピックフェース／未割当）を返します
タグ＝保管 → WMSが既存の格納ルールでロケーションを割り当てます
タグ＝フロースルー → WESが移動タスクをフォークリフト端末やAGVスケジューラに直接出し、WMSを完全にバイパスします
例外（ターゲット満杯、オーダー取消）→ WESが10秒以内に再計算し、新しい目的地を出し、古いタスクを自動無効化します

4番目が最も重要です。2024年5月、中国南部の美容通販倉庫：フロースルー貨物がすでにステージングに置かれているところで、顧客がオーダーの30%を取消しました。再計算がなければ、その貨物はステージングで腐ります。彼らのWESは輸送中のフロースルーを10分ごとに再スキャンし、需要が消えればタスクは格納に切り替わり、フォークリフトが次の一手で運び去ります。**フロースルーの判断は取り消し可能でなければなりません。**これがWESオーケストレーションとハードコーディングされたルールの本質的な違いです。

ステップ4：本番稼働後は3つの数字を見て調整する

フロースルー率 ＝フロースルーのパレット数 ÷ 入庫パレット総数。健全な水準は通常15%–35%です。15%を下回ればルールが保守的すぎます。40%を超えれば、保管すべき貨物が無理に流されていないか確認します。
フロースルー滞留時間 ＝フロースルー貨物が出荷ステージングに置かれる平均時間。24時間を超えれば滞留です。需要予測が楽観的すぎるので、閾値を引き締めます。
再荷役率 ＝フロースルー貨物のうち結局保管に回ってしまう割合。10%を超えれば判断の質が低いということです。どのデータソース（オーダー、在庫、ウェーブ計画）が嘘をついているか確認しに行きます。

現場の失敗パターン3つ

失敗1：フロースルーゾーンの物理的な分離がない

2022年、中国北部の自動車部品倉庫。フロースルーのパレットと格納待ちのパレットが受入エリアの床を共有し、仕切りは引かれたラインだけでした。忙しくなるとドライバーはラインを無視しました。フロースルー貨物は保管に入れられ、保管行きの貨物は出荷側に引っ張られました。まる1週間の混乱です。教訓：フロースルーのステージングエリアは物理的に独立させます。専用のドックドア、専用のロケーション番号帯、WES内での専用のロケーショングループです。

失敗2：ロット／期限管理貨物を無理に流す

食品、医薬品、厳格なFIFOが求められるもの全般——フロースルーの最大のリスクはロットのトレーサビリティを壊すことです。ロット情報の取得が完了する前に貨物が出荷され、システム上のロット記録が現実と食い違います。私のルールはこうです。期限敏感なSKUは原則としてフロースルーの対象外にします。ただし、ロット情報の取得を受入工程まで前倒しし、WESがロットデータをリアルタイムに読み取れる場合は例外です。

失敗3：フロースルーをKPI目標にする

あるオペレーション責任者は、フロースルーがコストを削減すると聞いて「フロースルー率 ≥ 50%」というKPIを設定しました。達成のために、倉庫は2週間保管すべき貨物をフロースルーさせました。出荷ステージングは山となり、週末の再格納のために臨時労働者を雇い、1か月で6桁の余分な費用を使いました。フロースルー率は結果の指標であり、目標ではありません。**目標は総荷役コストの最小化です。**フロースルーは一つのレバーであり、ゴールではありません。

直感に反する判断：ワンタッチ多い方が安いこともある

逆説的な見方を言います。フロースルーが多ければ多いほど良いとは限りません。最も極端な反例——書籍通販の倉庫で、SKUが残酷なほど分散し、1パレットに40+品目ありました。彼らのWESは50%のフロースルー率を算出しましたが、ブレークバルク・フロースルーの人件費は1個あたり約$1.10、通常の格納＋ピック合計は1個あたり約$0.75でした。**フロースルーはフォークリフトの移動を節約しますが、ブレークバルク・フロースルーは人手の仕分け労働を消費します。**帳簿の両側を数えなければなりません。

計算式はシンプルです。