EC倉庫：SKUが多く、注文件数が多く、1件あたりの点数は少ない

EC倉庫は卸売倉庫と何が違うのか：棚とトートによる小口ピッキング、一日中流れ込む注文、バッチ・クラスターピッキング、梱包ライン、そして販促ピークの乗り切り方。

同じ朝に卸売倉庫とEC倉庫に入ると、違いは最初の1分で分かります。卸売倉庫はパレット単位で出し入れし、1日数十件の大口注文が中心。EC倉庫は逆です：消費者が一日中スマホで注文し、倉庫は数千件の小さな注文を荷物に変えます。この建物のほぼすべての設計——高層ラックではなく棚、パレットではなくトート、ドック班ではなく梱包ライン——は1つの事実から生まれます：顧客が買うのはパレットではなく1点ずつの商品だということです。

まず注文の姿を見る：3つの数字がすべてを説明する#

SKU数は大：中規模のEC倉庫でも5,000から50,000種類の商品を置きます。スマホケースから電気ケトルまで。注文件数も大：平日で数百件、販促では数万件。1件あたりの点数は小：大半は1〜3点で、単品注文が多数派のことも珍しくありません。この3つの数字を頭に入れれば、この記事の残りはその帰結です：在庫は「少しずつ、すべて手の届く場所に」、ピッキングは「多くのロケーションを回って少しだけ取る」、そして一日の勝敗はピッキングではなく梱包で決まります。

だからEC倉庫全体は「バラす」ことを前提に設計されます。貨物はケースやパレットで入ってきても、早い段階で単品にバラして棚に置きます。顧客の注文単位が単品だからです。その後のすべての工程——ピッキング、照合、梱包——は単品単位で動き、パレット単位の発想のままの工程があると、ライン全体が遅くなります。

保管とピッキングフェイス：棚とトートが主役#

EC倉庫の作業の心臓部は棚エリアです：ビンと仕切りのある棚が並び、すべて手の高さ、SKUごとに1フェイス。作業者はトートを載せたカートを押して通路を回り、ビンから1〜2点取って、スキャンして、次へ進みます。ケースやパレットも存在しますが、後方や上方の予備在庫として置かれ、役割はピッキングフェイスへの供給だけ。棚配置の実務ルール：注文の大半に現れる20%のSKUは梱包エリアから最も歩行距離の短い場所へ。その道のりは1日に何千回も繰り返されるからです。

ピッキングフェイスはすぐ空になるため、補充は常態化した脇仕事です：ビンが減ったら予備在庫を前に出し、次のピッキングの波が来る前に満たします。初心者はこの仕事を軽く見て、手の空いた人に任せがち。ベテランは計画に組み込みます。フェイスが1つ空だと、遅れるのは1件ではありません。そのSKUを含むすべての注文が同じ棚の前で止まります。

Docklifyでは、この分業はロケーションタイプに対応します：ピッキングフェイスは picking タイプのロケーションとして作成され、パレット単位の storage ロケーションとは別に管理されます（WMS → Locations）。これにより、ピッキングタスクは作業フェイスから取り、補充と棚卸しはフェイスと予備在庫を別物として扱えます。

注文は一日中流れ込む：倉庫は締め切りとウェーブで回る#

明日の分を今日計画できる卸売倉庫と違い、EC倉庫は朝の時点ではその日全体を見通せません。注文は店舗から分刻みで流れ込み、建物全体が締め切り時刻を中心に回ります：例えば16:00までに支払われた注文は当日出荷を約束し、それ以降は翌日。仕事は少しずつ放出されます——1〜2時間ごとに注文のバッチを出す——ことで、ピッキング、梱包、配送業者の集荷が同じ歩調を保ち、閉店前に一気に溢れるのを防ぎます。締め切りは顧客への約束であり、内部の期限はすべてその約束から逆算したものです。

Docklifyでは、受注側は OMS です：販売注文は手入力、CSVインポート、マーケットプレイスや店舗からのチャネル取込、Merchant Portal経由、CRM商談からの転換で入ります。wms_syncモードでは、OMSはWMSの利用可能在庫を読むだけで、放出済みの注文をWMSへ出庫伝票として送ります——ピッキング、梱包、出荷はすべてWMS側で行われ、出荷の進捗はOMSの注文タイムラインに戻ります。

ピッキング：1回の移動でできるだけ多くの注文をさばく#

Order Pick——1人・1注文・1トリップ——は最も単純なモードで、例外ケースでは今も正解です：行数の多い大口注文、壊れ物や高額品、混ぜると危険なもの。その代償は歩行です：1日3,000件の注文がそれぞれ単独で通路を回れば、シフトの大半はピッキングではなく移動に消えます。だからEC倉庫でのデフォルトの問いは「注文をまとめるかどうか」ではなく「どうまとめるか」です。

バッチ／クラスターピッキングは、トリップを統合することで答えます。作業者はトートを多数載せたカート——1トートが1注文——を押し、棚を1回だけ回り、取った商品をそのまま正しいトートに入れます。ピックと仕分けが1つの動作で完了します。同一SKU・同一ロケーションの行は、カート上の全注文を横断して1ストップに統合されます：同じスマホケースを求める10件の注文は、10回ではなく1回の歩行と1回の手伸ばしで済みます。成立させる規律は絶対です：1トート1注文、入れる前に必ずスキャン——1回の入れ間違いは、顧客が先に気づく誤出荷になるからです。

Docklifyでは、出庫伝票から WMS → Outbound Orders → Create pick task でピッキングタスクを生成します。モードは3つ：Order Pick、Batch Order Pick、Wave Pick。Cluster Pick のモバイルフローは厳密です：まずカートを紐付け、統合行をピックし、トートごとに確認して、カートを解放——トートごとの内訳が後から再構成されるのではなく、その場で記録されます。

Wave Pick は逆の群衆のためのものです：数種類の売れ筋SKUに対する数千件の単品注文、販促時の典型です。注文単位で歩く代わりに、チームは全注文を横断してSKU単位でピックします——売れ筋を一度に大量にLPNへ——注文とのひも付けは、統合エリアや梱包台で商品をスキャンするときに行います。後の仕分け1工程と引き換えに、今の歩行を大幅に削減します。同じ少数のSKUが何百回も繰り返される場合にだけ割に合います。

Docklifyでは、ウェーブは即興ではなく計画します：ウェーブテンプレートから手動またはスケジュールでウェーブを放出し（WMS → Wave Release）、フィルタで出庫伝票をグループ化し、Wave Monitor でウェーブごとのピッキング進捗を確認します——配送業者の締め切りが来る前に、販促ウェーブの遅れを監督者が察知できます。

梱包ライン：単品が荷物になる場所#

梱包は作業台の寄せ集めではなく、1本のラインです。トートが到着し、各商品を受注と照合してスキャン——このスキャンがピッキングミスを安く止める最後の機会——適切な段ボールを選び、緩衝材を入れて封をし、計量し、配送業者の送り状を印刷して貼ります。作業台1台で1件を1〜3分で処理し、そのリズムは前段のピッキングウェーブが安定して供給します。ここに行列ができる原因は、手が遅いことではありません。注文構成に対して台が足りない、肝心な段ボールサイズが肝心な時に切れている、ラインが飲み込める量より大きなウェーブを放出している、のいずれかです。

Docklifyでは、このラインは Packing Station（WMS → Packing Station）です：注文の呼び出し方はピッキング方式に連動します——Order Pick は注文番号・LPN・タスク番号、Cluster Pick はカート番号やトート番号、Wave Pick は LPN をスキャン——その後、同じ画面で pack-verify で1点ずつ照合し、分割梱包またはそのまま出荷し、計量し、送り状を印刷し、出荷を確定します。

ラベルの後、荷物は配送業者とルート別に一時保管の山へ仕分けされ、集荷時間帯を待ちます。この最後のバッファは受動的に見えますが、一日の成否を決めます：集荷を逃せば、時間通りに梱包した千個の荷物も遅配になります。成熟した拠点は販促時に一時保管スペースを必死に守ります。溢れた荷物が通路に置かれると、その後ろのフォークリフトやカートすべてが遅くなるからです。

販促ピークを乗り切る：物量は3〜10倍#

販促は一日を少し忙しくするのではありません。その形を変えます。注文は通常の3〜10倍の速さで押し寄せ、単品の売れ筋注文の比率が跳ね上がり、締め切りは前倒しになり、配送業者も独自の集荷上限を加えます。乗り切れる倉庫は、その週に頑張る倉庫ではなく、数週間前から準備した倉庫です：売れ筋を事前にピック、あるいは梱包まで済ませ、梱包材を深く在庫し、作業台を増設し、臨時スタッフをまず最も単純な工程で慣らしておくことです。

• ウェーブを小さく刻む。小さく頻繁なピッキングウェーブは梱包への供給を均し、遅れているウェーブを締め切り時ではなく1時間以内に露呈させます。
• 予測できるものは事前に梱包する。標準的な組み合わせの主力SKUはピーク前に箱詰めしておけば、ピーク時はラベルを貼るだけです。
• 地味なものを深く備蓄する：各サイズの段ボール、テープ、送り状、プリンタリボン。ピークで負けるのは人手不足より段ボール不足のほうが多いのです。
• 受入をどかす。最大の日は入荷トラックを止めるかオフピークにずらし、ドックドアとフォークリフトを出荷専用にします。
• ピッカーより先に梱包台を増やす。ピッキングを速くしても行列が伸びるだけ。トートを発送可能な荷物に変えるのは梱包だけです。

返品はECの影の流れです：かなりの割合の荷物が戻ってきます。特に衣類で顕著です。返品荷物は独立した返品エリアで開封・検査され、検査に合格した商品だけが販売可能在庫に戻り、残りはリワークか廃棄へ。返品を片手間の雑用として扱うと、誰かがすでに着た服が販売可能在庫に静かに混ざっていきます。

Docklifyでは、返品フローには RMS（SaaS → RMS）という専用の場所があります：返品の受入と検査は正方向の在庫とは別に処理され、返品された商品は明示的な処分判断を通してのみ販売可能在庫に戻ります——床に独立した返品エリアを設けるのと同じ分離です。

EC倉庫で初心者が踏みやすい落とし穴#

• 卸売の習慣で小口注文を回す：注文ごとに1人を単独で送る、あるいは在庫をケース単位でしか置かず、どの注文もケースを開けるところから始まる。
• ピッキングフェイスを飢えさせる。計画的な補充がなければ、優秀な作業者ほど空のビンの前で待ったり、自分で予備在庫まで歩いたりしてシフトを消耗します。
• 梱包台を面積ではなく1時間あたりの注文件数で数えないこと。最初の販促で、天井はピッキングではなく梱包だと気づきます。
• 巨大なウェーブを放出する。大きなウェーブは効率的に見えて、梱包ラインと統合スロットを何時間も静かに埋めてしまいます。
• 返品エリアより棚が近かったという理由で、返品を検査なしに正方向在庫へ混ぜること。

EC倉庫は、たくさんの小さな約束を時間通りに荷物へ変える機械です。ピッキングフェイスを満たし続け、歩行を統合し、梱包ラインを守り、ピークが来る前に備える——あとはリズムの問題です。

本記事で使ったDocklify機能#

• ピッキングフェイスを picking ロケーションとして作成し、storage ロケーションと分離管理 — WMS → Locations
• 注文の入口は5通り、wms_sync で放出済み注文をWMS出庫伝票へ連携 — OMS
• ピッキングタスクは Order Pick、Batch Order Pick、Wave Pick の3方式。Cluster Pick のカート紐付けとトートごとの確認 — WMS → Outbound Orders → Create pick task
• ウェーブテンプレート、スケジュール／手動のウェーブ放出、Wave Monitor でウェーブごとの進捗確認 — WMS → Wave Release
• pack-verify、分割梱包、計量、送り状印刷、出荷確定を1画面で — WMS → Packing Station
• 返品の受入と検査を正方向在庫と分離 — SaaS → RMS