3PLマルチクライアント倉庫：多くの荷主、1つの建物、勘定は別々

3PL倉庫が自社保管倉庫と違う点：荷主ごとのゾーンとロケーション区画、荷主別に分けた在庫帳簿、パレット単位とバラ作業の混在、そして課金ポイント——保管料、作業料、付加価値サービス料——がどこにあるのか。

自社倉庫は自社の商品を保管します：数え間違えても損失は社内で、静かに数え直せば済みます。3PL倉庫は料金を受け取って他社の商品を保管します。その違い1つですべてのルールが書き換わります。ラックの在庫は5社、20社、100社の異なる荷主のもの。各荷主はいつでも「自分の貨物はいくつ残っているか、どこにあるか、今週何が出たか」を問えなければならず、答えには決して隣の荷主の貨物が混ざってはいけません。3PL倉庫が売るものは一言で言えば、「分けられること」と「数えられること」です。

多くの荷主、1つの建物：まず荷主ごとにゾーン分け#

物理レイアウトは荷主リストから始まります。各荷主には専用のエリア：一連のラック通路、床の区画、少なくとも明確に標示されたロケーション範囲の集合。通路の入口には荷主名の標識、パレットラベルには荷主コード、そして混載パレットは禁止です——便利そうに見えても、1パレットに2荷主の貨物を載せません。小さな荷主は通路を共有できますが、ロケーションは決して共有しません。床の上での分離の最小単位は「1ロケーション、1荷主」です。自社倉庫が空きスペースを何でも埋めるのと比べると無駄に見えますが、3PLの建物では、荷主間の空きこそが「どの貨物が誰のものか」を断言できることの対価です。

Docklifyでは、荷主専用エリアを Location Group として表現できます（WMS → Location Groups）：ある荷主用に確保したロケーションをその荷主のグループにまとめておけば、棚入れの提案やタスクルールが境界を守るようになり、「どの通路が誰のものか」を全員の記憶に頼らずに済みます。

在庫帳簿は荷主別に付けなければならない#

2つの荷主がまったく同じ商品——同一SKU、同一の箱、棚での見た目も同じ——を売ることがあります。帳簿上は、それらはたまたま見た目が同じなだけの別々の在庫であり、決して、決して合算しません。利用可能数、引当数、循環棚卸し、破損による除却まで、すべて荷主別に数えます。荷主Aが欠品し、隣の荷主Bに同じ商品が5パレットあっても、Aの注文は待ちます：隣の在庫を借りてAの注文を出荷するのは、マルチクライアント倉庫で許されない罪です。2冊の帳簿を同時に偽ることになるからです。

Docklifyでは、この分離はホワイトボードの注意書きではなく構造です：すべての伝票ヘッダーには Client（荷主）が入ります——出庫伝票は1つの荷主の下で作成され、ウェーブ放出は Client の選択（必須項目）から始まって荷主とフィルタで出庫をグループ化し、引当てはその荷主の在庫をロックします。最初に荷主を間違えると、その伝票には約束できる在庫がそもそも存在しません。システムが帳簿の混同を拒否しているのです。

入庫：貨物に触る前に荷主を確認する#

3PLの建物での受入は、通常より1歩早く始まります：これは誰の貨物か？予約も、書類も、受入タスクも、トラックのドアが開く前に荷主が明記されています。貨物はその荷主の入荷予定と照合して数えられ、ドックでその荷主のコードのラベルが貼られ、それから初めて——その荷主の区画へ——棚入れされます。新人を驚かせるのは混在ぶりです：同じ午前中に、卸売荷主のパレット積み段ボール1コンテナ分と、小さなネット販売業者のサンプル3箱が届きます。パレット単位の入庫もバラの入庫もここでは日常で、同じドックで1時間違いに起きることも珍しくありません。

棚入れルールは荷主ごとに異なります。貨物が違うからです：厳格な先入先出を求める荷主、ロット管理する荷主、賞味期限を見る食品の荷主、隔離スペースを求める返品の多い荷主。倉庫が全館共通ルールを1つ決めることはできません。複数のルールセットを並行して回し、各タスクがどの荷主のものかを覚えるのは人の記憶ではなくシステムでなければなりません。受入速度が建物全体の平均ではなく荷主プロファイル別に見積もられるのは、このためです。

出庫：パレット単位とバラが同じ倉庫で並行する#

同じ二面性が出庫にも貫かれています。B2B荷主の注文はパレット3枚分かもしれません：フォークリフトがラックから降ろし、フィルムを巻き、ラベルを貼り、一時保管へ——その注文は棚のビンにも梱包台にも触れません。次の注文はネット販売荷主の2点：棚からピックし、小さな段ボールに入れて配送ラベルを貼ります。どちらも同じシステムでは単なる出庫伝票で、しばしば同じ1時間の中にあります。3PLチームの腕は、粒度を切り替えても規律を切り替えないこと：パレット単位の注文でもスキャンと書類は欠かさず、2点の荷物でも正しい荷主の帳簿に付けます。

Docklifyでは、出庫伝票はその Client（荷主）の下で作成され、配送先住所はその荷主のアドレス帳から選ぶか、一度入力して保存します。引当てが予約するのはその荷主の在庫だけで、ピッキングタスク——パレット単位かバラか——はその伝票から生成されます。粒度は注文ごとに変わっても、荷主の境界は決して動きません。

お金はどこにあるか：3PL倉庫の課金ポイント#

3PL倉庫の収益は3種類の料金から来ます。保管料は静かなもの：貨物は占有するスペースに対して支払い、パレット単位、立方メートル単位、ロケーション単位で数え、通常は日次でスナップショットされます——30日置かれたパレットは、誰が触ったかに関係なく30日分を払います。作業料は目に見えるもの：人と機械が貨物に仕事をするたび——受入、棚入れ、ピッキング、梱包、積込み——契約がその一手に価格を付けます。付加価値サービス料は交渉可能なもの：ラベル貼付、箱の交換、キッティング、品質検査、写真記録、ギフト包装。これらの価格に普遍的なものはなく、各荷主の契約の中にあります。だから課金の話は常に習慣ではなく料金表から始まります。

多くの3PLの建物での漏れは、価格の間違いではありません。やったのに記録されなかった仕事です。梱包台でついでに貼ったラベル、好意で替えた箱、ある荷主の急ぎのコンテナのための残業——起きたその日に誰も書き留めなければ、請求書には載らず、倉庫は静かに寄付したことになります。床のルールはこうなります：イベントがなければ課金なし。そして監督者がビジネスためにできる最も実務的なことは、記録を10秒で済むようにすることです。

Docklifyでは、価格は荷主の料金表の中にあります（Accounting → Billing → Rate Sheets → New Rate Sheet）：5ステップのウィザードで、モジュール別（WMS、TMS、Drayage、LastMile）にグループ化された課金カタログから項目を選び、単価と段階料金を設定し、双方が電子署名すると、その表がその荷主の唯一の有効バージョンになります。価格変更で履歴を編集することは決してありません。新バージョンを作り、再署名します。

課金側はその後、自動で回ります：完了したタスクは課金用の利用イベントを自動で記録し（受入、棚入れ、ピッキング、梱包など）、保管は毎日スナップショットされ、システムが取得できない項目——ラベル貼付、待機料などの追加分——は決算前に手入力またはCSVインポートで補完します。決算時、エンジンは未請求のイベントを荷主の有効な料金表で1件ずつ価格計算し、請求書ドラフト（MINV-000001、MINV-000002…）を生成します。各行には数量×単価の式が表示されるため、荷主は行ごとに検算できます。

荷主に自分で見てもらう：信頼は機能である#

マルチクライアント倉庫は毎週同じ質問を受けます：自分の貨物はあといくつ残っているか、火曜の注文は出たか、この請求行は何なのか。荷主が3社なら電話と表計算で答えられますが、30社では崩壊します。そして手作業の回答はすべて、違う荷主の数字を違うメールに貼る機会でもあります。拡張できる答えは、硬い壁のあるセルフサービスです：各荷主がログインすると、ちょうど自社の在庫、自社の伝票、自社の請求書だけが見えます——その荷主には完全で、それ以外には不可視です。

Docklifyでは、荷主は Client Portal（Merchant Portal）を通じてその壁を得ます：荷主アカウントが自分で注文し、自社の在庫を確認し、追跡を追います。倉庫チームは承認と実行だけを担当します。ポータルが読むのは倉庫の床と同じ荷主別の帳簿なので、荷主が見ているのはラックに実際にあるもの——誰かが先週金曜に更新した表計算ではありません。

マルチクライアントの建物での日常の規律#

• ラベルはドックで貼る。後回しにしない。荷主コードなしでラックに入ったパレットは、いずれ誰かの推測の対象になり——推測は出荷されてしまいます。
• 棚卸しは常に荷主別に。2荷主の同一SKUを1つの数字に混ぜた循環棚卸しは、何も数えていないのと同じです。
• 好意の作業は当日に記録する。追加のラベル貼付、箱交換、急ぎの作業は、課金イベントが存在してこそ正当な請求になります。記憶は請求書ではありません。
• 両荷主が電話で同意していても、荷主をまたいで在庫を借りないこと——帳簿、賞味期限、ロット記録が後になって食い違い、しかも文書の形で残ります。
• 新規荷主の見積もりは建物の平均ではなく、その荷主のプロファイルから：パレットで入って小包で出る荷主と、パレット単位の荷主では、同じ床の使い方がまったく異なります。

3PL倉庫は、保管業の顔をした約束を守るビジネスです。各荷主の貨物、帳簿、請求書を——床の上でも、システムの中でも、ポータルでも——分けて保てば、他人の財産でいっぱいの建物は、世界で最も説明しやすい場所になります：すべて数が合い、すべて帰属が明らかです。

本記事で使ったDocklify機能#

• 荷主専用エリアを Location Group で表現 — WMS → Location Groups
• 伝票ヘッダーに Client を保持。ウェーブ放出は Client 必須で、荷主とフィルタでグループ化 — WMS → Outbound Orders / Wave Release
• 出庫伝票は荷主の下で作成、配送先はその荷主のアドレス帳から、引当てはその荷主の在庫のみ — WMS → Outbound Orders
• 荷主料金表：5ステップウィザード、段階料金、電子署名 — Accounting → Billing → Rate Sheets
• 完了タスクからの課金イベント自動記録、保管の日次スナップショット、行ごとに式付きの決算請求書 — Accounting → Billing
• 荷主のセルフサービス：注文、自社在庫、追跡 — Client Portal / Merchant Portal