ERP

ロケーション管理とは：固定・フリー・ダブルトランザクションの使い分けとロケーションコード設計をSQLで実装

流通系システムが業界にもたらす影響

ロケーション管理とは、倉庫の棚や区画に「A-03-12-2」のような住所を振り、どの品目がどの棚に何個あるかを棚番単位で記録する管理方法です。品目ごとの在庫数だけでは、棚に100個あると分かっても、取りに行く場所は分かりません。この記事では、固定ロケーション・フリーロケーション・ダブルトランザクションの違いと向く倉庫、列・連・段のロケーションコードの桁設計、棚番マスタと棚別在庫のデータモデル、補充指示と格納先提案のSQL、Excelで回せる規模の上限までを、実装者の目線で示します。

まとめ：ロケーション管理の実装で先に決める方式・コード体系・補充の基準

ロケーション管理を作る前に決めることは3つです。1つ目は方式で、品目ごとに置き場を決める固定ロケーション、空いた棚に置くフリーロケーション、ピッキング棚は固定にして保管棚はフリーにするダブルトランザクションのどれにするかです。2つ目はロケーションコードの体系で、倉庫・列・連・段を何桁で表し、番号の順を作業者の歩く順と一致させるかを決めます。3つ目はダブルトランザクションを選んだ場合の補充基準で、ピッキング棚の下限と上限を品目ごとに持たせます。

データモデルでは、在庫を「品目×棚番×ロット」の単位で持つことが出発点です。品目単位の在庫表に棚番の列を1つ足す設計では、同じ品目が2つの棚に分かれた瞬間に破綻します。ハンディ端末で棚番を読む運用を用意できないなら、フリーロケーションは選びません。ここだけは条件によらず言い切れます。

ロケーション管理の定義と、棚番を住所として在庫に結びつける仕組み

ロケーション管理の中身は、在庫の数を「どこに」の軸で分解することです。在庫管理システムが品目ごとの数を持つのに対し、ロケーション管理はその数を棚ごとに割り振って持ちます。

ロケーション管理の定義：品目単位の在庫を棚番単位の在庫に分解する考え方

品目P-100の在庫が42個という記録は、在庫管理としては正しくても、ピッキングの指示には使えません。ロケーション管理では、同じ42個を「A-01-01-1に12個、S-01-01-1に30個」と棚番ごとに持ちます。棚番は倉庫内の住所で、ロケーション番号とも呼ばれます。

この分解により、出荷指示の時点でどの棚から何個取るかを決められます。棚卸も棚番の順に数えて記録と照合でき、差異が出た棚を特定できます。入出庫の履歴や引当を含む在庫管理システム全体の機能の中でのロケーションの位置づけは、在庫管理システムの入出庫管理と引当の仕組みを解説した記事で整理しました。倉庫業務全体を担うWMSの機能一覧はWMS（倉庫管理システム）の機能と導入判断の記事が扱っています。

Odooの親子階層とバーコードに見る、ロケーションをシステムで表す方法

市販のERPもロケーションを階層で持ちます。オープンソースERPのOdooでは、Odoo 19.0の公式文書「Locations」に、各ロケーションへ親ロケーション（Parent Location）を指定して階層を作る方法が書かれています。例として挙がっているのはWH/Stock/Zone A/Refrigerator 1で、倉庫・在庫区画・ゾーン・冷蔵庫の4段です。

同じ文書では、ロケーションにバーコードを登録し、スキャンしたときにその場所での作業を識別させる設定も説明されています（Barcodeアプリが必要）。棚番を人が目で読んで手入力する運用と、ラベルを読み取る運用では、入力ミスの起きやすさが桁違いです。自社で作る場合も、棚番マスタにはラベル印字用の値を持たせ、ハンディ端末で読み取る前提で設計します。

ロケーションコードの付け方：倉庫・列・連・段の桁数と並び順の設計

ロケーションコードは一度ラベルを貼ると変えにくい値です。棚の増設や配置換えが起きても体系を崩さずに済むよう、最初に桁数と並び順を決めておきます。

列・連・段の4階層コードを固定桁でゼロ埋めし、文字列の順を歩く順にそろえる理由

棚の住所は、ゾーン（区画）・列（通路）・連（通路沿いの棚の何台目か）・段（下から何段目か）の4階層で表すのが一般的です。各階層の桁数は固定にします。

階層 桁と文字種 例
ゾーン 英字1桁 A（ピッキング）・S（保管）
列 数字2桁 01〜99
連 数字2桁 01〜99
段 数字1桁 1〜9

桁を固定する理由は、文字列として並べ替えたときの順番です。ゼロ埋めしない「A-2-5」「A-10-1」「A-3-12」を文字列順に並べると、次のように10列目が2列目より前に来ます。

-- ゼロ埋めなし：A-10-1, A-2-5, A-3-12 の順（10列目が先頭に来る）
SELECT v FROM (VALUES ('A-2-5'), ('A-10-1'), ('A-3-12')) AS t(v) ORDER BY v;

-- ゼロ埋めあり：A-02-05, A-03-12, A-10-01 の順（列の順に並ぶ）
SELECT v FROM (VALUES ('A-02-05'), ('A-10-01'), ('A-03-12')) AS t(v) ORDER BY v;

この結果は、同じ値をSQLite 3.50.4で並べて確認しました。帳票やExcelのフィルタは文字列順で並ぶことが多いため、ゼロ埋めをしないと棚卸表が通路の順に並ばず、作業者が倉庫内を行き来します。

通路の左右で奇数と偶数を分ける付け方と、増設に備えて番号を空ける判断基準

1本の通路の両側に棚がある倉庫では、左側の棚に奇数、右側に偶数の連番を振ると、通路を1往復する間に番号の順で取り回せます。片側ずつ1から振ると、通路の奥で折り返したあとに番号が戻るため、ピッキングリストの順と歩く順が一致しません。

番号を空けておくかどうかを判断する基準は、棚の増設の予定です。2年以内に棚を足す計画があるなら、列番号を10おきに振る（01・11・21）か、ゾーンの英字を1つ予約しておきます。計画が無いなら詰めて振ります。空き番号だらけの体系は、作業者が「この番号の棚はどこか」を覚えにくくするためです。

棚番ラベルのバーコード化：GS1のAI(254)と社内コードを使い分ける判断基準

棚番ラベルのバーコードには、社内で決めた文字列をそのままCode128などで印字する方法と、GS1の標準形式を使う方法があります。GS1のアプリケーション識別子一覧では、AI(254)「GLN extension component」が英数字最大20桁（形式N3+X..20）と定義され、場所のGLNを表すAI(414)（数字13桁）と組み合わせて使うことが必須とされています。

判断は単純です。棚番を読むのが自社のハンディ端末だけなら、社内コードを印字する方法で十分です。3PL（物流の外部委託先）や取引先のシステムが同じラベルを読む場合に限り、GLNとAI(254)の形式を検討します。前の章の「A-03-12-2」は9文字なので、どちらの方式でも20桁の上限内に収まります。

固定ロケーション・フリーロケーション・ダブルトランザクションの違いと向く倉庫

3つの方式は、置き場所を誰が決めるかで分かれます。固定は事前にマスタで決め、フリーは入庫のたびに決め、ダブルトランザクションは棚の役割ごとに両方を使い分けます。

固定・フリー・ダブルトランザクションの比較表と、方式ごとに作る仕組みの違い

方式 置き場の決め方 向く倉庫 作る仕組み
固定 品目ごとにマスタで固定 品目数が少なく入れ替えが少ない 固定割当マスタ
フリー 空いた棚に都度格納 品目の入れ替えが多い・保管量の波が大きい 棚別在庫と格納時のスキャン
ダブルトランザクション ピッキング棚は固定・保管棚はフリー 出荷頻度が高く保管量も多い 上の両方と補充指示

固定ロケーションは、作業者が置き場を覚えられるので、システムが止まっても出荷が続けられます。弱点は、季節品の入れ替えのたびに割当を見直す手間と、欠品中の品目の棚が空いたまま場所を取ることです。フリーロケーションは棚を詰めて使えますが、棚別在庫の記録が1件でも狂うと、その品目は倉庫中を探すことになります。ダブルトランザクションは両者の弱点を補う代わりに、ピッキング棚へ補充する作業と、その指示を出す仕組みが増えます。

電子部品のように品目数が多く小さい在庫でフリーロケーションを選ぶ条件

電子部品の倉庫は、品目数が数千から数万になり、1品目あたりの体積はリールやトレイ1つ分と小さいのが典型です。品目ごとに棚を固定すると、在庫が数個の品目にも1区画を割くことになり、棚の多くが空気を保管します。このような倉庫ではフリーロケーションを選ぶ理由がはっきりしています。

条件は2つあります。リールや袋ごとに品番とロット（メーカーのデートコード）を印字したラベルを貼れること、格納と出庫のたびに棚番と現品ラベルの両方をスキャンする運用を守れることです。ロット単位の先入先出しや期限の近い順の出庫を組み合わせる場合のルールは、販売管理システムのロット管理とFEFO引当の判断軸で扱っています。

ロケーション管理のデータモデル：棚番マスタ・固定割当・棚別在庫の3テーブル

ロケーション管理のテーブルは、棚そのものを表すマスタ、品目と棚の固定の結びつき、棚ごとの在庫数の3つに分けます。以下はPostgreSQLの構文で書いた例です。

棚番マスタと棚別在庫テーブルの列設計：品目×棚番×ロットで在庫を持つ形

CREATE TABLE location (
  location_code text    PRIMARY KEY,               -- 例 A-01-01-1
  zone          text    NOT NULL,
  aisle         integer NOT NULL,                  -- 列
  bay           integer NOT NULL,                  -- 連
  level         integer NOT NULL,                  -- 段
  area          text    NOT NULL CHECK (area IN ('ピッキング','ストック')),
  walk_seq      integer NOT NULL,                  -- 歩く順の通し番号
  is_active     boolean NOT NULL DEFAULT true
);

CREATE TABLE location_stock (
  location_code text    NOT NULL REFERENCES location,
  item_code     text    NOT NULL,
  lot_no        text    NOT NULL DEFAULT '',       -- ロット管理しない品目は空文字
  qty           integer NOT NULL CHECK (qty >= 0),
  received_on   date    NOT NULL,                  -- 先入先出しの判定に使う
  PRIMARY KEY (location_code, item_code, lot_no)
);

棚番の文字列とは別に、列・連・段を数値の列で持っているのは、「3列目より奥の棚」のような範囲の条件を文字列の切り出しなしで書けるようにするためです。walk_seqは、ピッキングの歩く順を棚番の文字列順から切り離すための列です。通路の左右で奇数と偶数を振った場合、文字列順と歩く順は一致しないため、この列で並べ替えます。

lot_noを主キーに含めているのは、同じ棚に同じ品目の別ロットが並ぶ場合があるためです。NULLを主キーに入れられないので、ロットを持たない品目は空文字で表します。

固定ロケーションの割当を履歴つきで持ち、部分一意インデックスで二重割当を防ぐ設計

固定ロケーションの割当は、季節品の入れ替えなどで変わります。割当を上書きすると「先月この品目はどの棚にあったか」が分からなくなるため、有効期間つきの行で持ちます。

CREATE TABLE item_location (
  item_code     text    NOT NULL,
  location_code text    NOT NULL REFERENCES location,
  min_qty       integer NOT NULL,                  -- 補充を出す下限
  max_qty       integer NOT NULL,                  -- 補充で満たす上限
  valid_from    date    NOT NULL,
  valid_to      date,                              -- NULLなら現在有効
  CHECK (min_qty < max_qty)
);
-- 現在有効な割当の中だけで、1品目1棚・1棚1品目を強制する
CREATE UNIQUE INDEX one_pick_loc_per_item ON item_location (item_code)     WHERE valid_to IS NULL;
CREATE UNIQUE INDEX one_item_per_pick_loc ON item_location (location_code) WHERE valid_to IS NULL;

PostgreSQLの公式文書11.8 Partial Indexesは、条件つきの一意インデックスが、条件を満たす行の中だけで一意性を強制し、満たさない行は制約しないと説明しています（Example 11.3）。この性質により、過去の割当行は何件残っても、現在有効な割当だけが1品目1棚に制限されます。SQLiteで同じ定義を作り、有効な割当を持つ品目へ2つ目の棚を足す挿入と、使用中の棚へ別品目を割り当てる挿入がどちらも一意制約違反で拒否されることを確認しました。

在庫引当との接続：受注引当では棚番を空け、出荷引当で棚別在庫から割り当てる流れ

ロケーション管理は、引当の2段目で効いてきます。注文確定時の受注引当では品目と数量だけを押さえ、出荷指示の直前の出荷引当で、どの棚のどのロットから何個取るかをlocation_stockから決めます。引当明細のlocation_code列を受注引当ではNULLにしておき、出荷引当で埋める設計です。

引当明細の状態遷移や解除の処理は、在庫引当の受注引当と出荷引当の違いをSQLで実装した記事で示しています。本稿のlocation_stockは、その記事の出荷引当が参照する棚別の在庫にあたります。

ダブルトランザクションの補充指示と格納先提案をSQLで出す実装

ダブルトランザクションで新たに作るのは、ピッキング棚への補充指示です。フリーロケーションの保管棚には、入庫時の格納先提案も要ります。

ピッキング棚が下限を割った品目へ、入庫日の古い保管棚から補充数を配分するSQL

補充指示は、ピッキング棚の在庫が下限以下になった品目について、上限まで満たす数を保管棚から取る指示です。複数の保管棚に分かれている場合は、入庫日の古い棚から順に取ります。

WITH pick AS (                       -- 下限を割ったピッキング棚
  SELECT il.item_code, il.location_code AS to_loc, il.max_qty,
         coalesce(sum(ls.qty), 0) AS pick_qty
    FROM item_location il
    LEFT JOIN location_stock ls
      ON ls.location_code = il.location_code AND ls.item_code = il.item_code
   WHERE il.valid_to IS NULL
   GROUP BY il.item_code, il.location_code, il.min_qty, il.max_qty
  HAVING coalesce(sum(ls.qty), 0) <= il.min_qty
), src AS (                          -- 保管棚を入庫日の古い順に累積
  SELECT p.item_code, p.to_loc, p.max_qty - p.pick_qty AS need,
         ls.location_code AS from_loc, ls.lot_no, ls.qty,
         sum(ls.qty) OVER (PARTITION BY p.item_code
                           ORDER BY ls.received_on, ls.location_code) - ls.qty AS before_qty
    FROM pick p
    JOIN location_stock ls ON ls.item_code = p.item_code AND ls.qty > 0
    JOIN location l ON l.location_code = ls.location_code AND l.area = 'ストック'
)
SELECT item_code, from_loc, lot_no, to_loc,
       least(qty, need - before_qty) AS move_qty
  FROM src
 WHERE before_qty < need
 ORDER BY item_code, before_qty;

架空データで計算すると、次のようになります。P-100は下限20・上限60で、ピッキング棚A-01-01-1に12個しかないため、48個の補充が必要です。保管棚はS-01-01-1（9月1日入庫・30個）とS-01-02-1（10月5日入庫・40個）にあり、古いS-01-01-1から30個、S-01-02-1から18個の2行の指示が出ます。P-300は下限10に対して8個なので、上限30まで22個をS-02-01-1から取ります。ピッキング棚に25個あるP-200（下限10）は指示に出ません。この3行は、同じSQLをSQLite 3.50.4でleastをminに置き換えて検算した結果です。

下限の決め方は、1日の出荷数の1日分から2日分が目安です。補充は1日1〜2回のバッチで出すことが多く、その間にピッキング棚が空になると、作業者が保管棚まで取りに行くことになります。

フリーロケーションの格納先候補を空き棚から動線順に出すSQLと、Odooの格納規則

格納先の提案は、在庫が0の保管棚を歩く順に並べるだけでも始められます。

SELECT l.location_code
  FROM location l
 WHERE l.area = 'ストック' AND l.is_active
   AND NOT EXISTS (SELECT 1 FROM location_stock s
                    WHERE s.location_code = l.location_code AND s.qty > 0)
 ORDER BY l.walk_seq
 LIMIT 3;

このSQLが格納先を提案する際の前提は、「1つの棚に1品目」です。小物を1つの棚に混載するなら、棚の容量と品目の体積も持たせる必要があります。Odooはこの部分を設定で持っており、Odoo 19.0の公式文書「Storage categories」では、棚が新しい品目を受け入れる条件を「空のときだけ」「同じ品目があるときだけ」「混載を許可」の3つから選び、最大重量や品目ごとの上限数量も設定できる仕様です。同じ文書には、入荷数量が提案先の容量を超えても複数の棚へ自動で分割はしない、という制約も書かれています。

Odoo 19.0の公式文書「Putaway rules」は、格納先の決め方を「指定の棚」「前回使った棚（Last Used）」「保管カテゴリから近い棚（Closest Location）」から選ばせています。自社で作る場合も、最初は前回使った棚を第1候補、空き棚を第2候補にする2段で足ります。

ピッキングリストを棚番マスタの歩く順で並べ替え、倉庫内の移動を縮める出力

出荷指示から作るピッキングリストの並べ替えに使うのは、注文の順ではなくwalk_seqの順です。注文O-1にP-300とP-100、注文O-2にP-200がある例では、棚の順にA-01-01-1（P-100）、A-01-02-1（P-200）、A-01-03-1（P-300）と並び、通路を1回通るだけで3品目を取れます。注文番号の順のままだと、O-1のP-300を取りに3番目の棚まで行き、P-100のために1番目へ戻ることになります。

複数の注文をまとめて取るトータルピッキングでは、この並べ替えの効果がさらに大きくなります。自動倉庫やソーターと組み合わせる場合の判断は自動倉庫の方式別の違いとWMS連携の記事で扱っています。

Excelでのロケーション管理が通用する規模と、システム化に切り替える判断基準

倉庫のロケーション管理をExcelで始める会社は多く、条件がそろえば実際に回ります。ここでは、どこまでがExcelの守備範囲かを条件で言い切ります。

倉庫のロケーション管理をExcelで回せる条件：品目数・更新者・方式の上限

Excelで回せるのは、固定ロケーションで、品目数が数百まで、ファイルを更新する担当者が1人の倉庫です。この場合、品目コード・棚番・在庫数の3列の表で、棚番の列をゼロ埋めした固定桁にしておけば、並べ替えで棚卸表とピッキング順が作れます。

破綻するのは、フリーロケーションをExcelで管理しようとしたときです。入庫のたびに棚番を書き換える更新が1日数十回発生し、複数人が同じファイルを触ると、上書きで棚番の記録が消えます。記録が1行消えた品目は、倉庫のどこにあるか誰にも分からなくなります。

フリーロケーションをハンディ端末なしで始めて失敗する形と、システム化の進め方

失敗する典型は、保管効率を上げるためにフリーロケーションへ切り替え、格納の記録を紙に書いて後でまとめて入力する運用です。入力までの数時間、その品目はシステム上どこにも無い状態になり、その間の出荷で欠品扱いが起きます。格納した瞬間に棚番と現品をスキャンして記録する仕組みが無いなら、固定ロケーションのままでいるほうが確実です。

フリーロケーションやダブルトランザクションに進む段階では、棚番マスタ・棚別在庫・補充指示を既存の在庫管理や販売管理とつなぐ開発が必要になります。パッケージのWMSでは補充の基準や格納の規則が業務に合わない場合は、在庫管理システム開発で、方式とコード体系を要件定義で先に決めてから設計に入ります。

よくある質問

ロケーション管理の設計や運用について、検索の多い質問に答えます。

固定ロケーションとフリーロケーションはどちらを選べばよいですか？

品目数と入れ替えの頻度で決めます。品目数が数百までで、取り扱い品目が年に数回しか変わらないなら固定ロケーションです。品目数が数千を超える、季節で品目が大きく入れ替わる、保管量の波が大きいといった倉庫ではフリーロケーションが向きます。ただしフリーロケーションは、格納と出庫のたびに棚番をスキャンする仕組みが前提です。出荷が多い品目だけ固定にするダブルトランザクションは、両方の条件が混ざる倉庫で選びます。

ロケーション番号は何桁にすればよいですか？

倉庫の規模で各階層の上限を決め、桁を固定します。通路が99本、棚が1通路あたり99台を超えない倉庫なら、ゾーン英字1桁・列2桁・連2桁・段1桁の6桁（区切り記号を入れて9文字）で足ります。桁を固定してゼロ埋めするのは、文字列として並べたときに通路の順と一致させるためです。複数の倉庫を1つのシステムで管理する場合は、先頭に倉庫コードを足します。

ロケーション管理とWMSは何が違いますか？

ロケーション管理は在庫を棚番単位で持つ管理方法で、WMSはそれを含む倉庫業務全体のシステムです。WMSには、ロケーション管理のほかに入荷検品・格納指示・ピッキング・梱包・出荷・棚卸といった作業ごとの機能があります。品目数の少ない倉庫では、販売管理や在庫管理のシステムに棚番の列を持たせるだけでロケーション管理が成り立ち、WMSを導入しないこともあります。

ダブルトランザクションの補充はいつ行えばよいですか？

ピッキング棚の在庫が品目ごとの下限を割ったときに、上限まで満たす数を補充します。補充指示は、午前の出荷作業の前と午後の締めの後など、1日1〜2回のバッチで出すのが一般的です。下限は1日の出荷数の1日分から2日分を目安にし、補充の間にピッキング棚が空にならないように決めます。出荷のピークがある日は、指示の回数を増やすか下限を一時的に上げます。

棚卸でロケーションの在庫が合わないときはどう直せばよいですか？

まず品目の合計数が合っているかを確認します。合計が合っていて棚ごとの数だけがずれている場合は、置き場所の記録漏れなので、実際にあった棚へ在庫を移す訂正の記録を作ります。合計がずれている場合は、入出庫の記録漏れか破損・紛失です。いずれも在庫数を直接書き換えず、訂正理由つきの移動や調整の履歴として残すと、同じずれが再発したときに原因の作業を追えます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.07　テックブログ ファインズの不正アクセスと153万件の予約者情報｜予約システムを使う店舗の報告と通知の手順
  2. 2026.10.19　テックブログ コミックシーモア不正アクセスで会員情報流出：再開時期・パスワード再設定と運営側のログ点検
  3. 2026.10.16　テックブログ バーガーキング情報漏洩どうしたらいい？約1,118万件の対象確認・補償・退会とメールの真偽
  4. 2026.10.15　テックブログ リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  5. 2026.10.15　テックブログ 銀のさら不正アクセス：最大650万件の対象確認と窓口、パスワード変更・退会の手順

RELATED POSTS 関連記事

一覧へ戻る

目次