コラム ｜ 物流データ収集技術 #8 ｜ 2026年8月25日

マスタデータとイベントデータ
─物流データを分析可能にする「整理の型」

データ活用の相談の場で、こんなやり取りが起きることがあります。

「先月のピッキング作業、エリア別の生産性を見たいんですが」
「作業実績のデータはあります。ただ、ロケーションの表記が揃っていなくて……」

データは確かに存在している。件数も十分ある。それなのに、集計しようとすると手が止まる。この「あと一歩」で止まる典型的な原因の一つが、マスタデータです。

#1（バーコード・RFID・OCR）の最後で、「読み取る技術より、読み取ったコードの設計のほうが難しい」という話に触れました。今回はその論点を正面から扱います。

1. 物流データは、性格の異なる2種類に分けられる

倉庫で発生するデータは、大きく2つに分類できます。この区別を意識するだけで、データの整理はかなり進みます。

イベントデータには、共通する構造がある

物流のイベントデータは、種類が違っても構造がよく似ています。おおむね次の要素で構成されます。

▼ イベントデータの基本構造

ピッキング実績も、入庫実績も、検品実績も、この形に当てはまります。そして「どこで」「誰が」「何を」の部分は、マスタを参照するためのコードが入ります。イベントデータ単体では、コードの羅列にすぎません。

イベントデータ（ピッキング実績）の例

この記録から「Aエリアの生産性」や「常温品と冷蔵品で作業時間に差があるか」を知るには、ロケーションコードや商品コードからマスタを引いて属性を得る必要があります。マスタが整っていなければ、この時点で分析は止まります。

2. 物流で特に重要な3つのマスタ

商品マスタ

「何を扱っているか」の台帳です。分析で使われるのは、コードや名称そのものより、そこに紐づく属性です。

「1時間あたり何個ピッキングできたか」という数字だけでは、生産性の良し悪しは判断できません。小さな商品を大量に取ったのか、重い商品を少数取ったのかで、意味がまったく違うためです。商品マスタの属性があって初めて、比較できる指標になります。

ロケーションマスタ

「どこで作業・保管するか」を定義する台帳です。倉庫内の棚や間口に付けられた番地の一覧と、その属性を持ちます。

作業者マスタ

「誰が作業したか」を定義する台帳です。ただし、この扱いには注意が必要です。

分析で使う属性としては、経験区分（新人・熟練）、所属チーム、雇用区分、担当工程などが挙げられます。個人を特定しない形での集計であれば、教育計画や人員配置の検討に活用できます。

3. 「マスタが汚い」とは、どういう状態か

現場でよく耳にする「マスタが汚い」という言葉。具体的には、次のような状態を指します。

あるある①：商品コードが1つに定まっていない

同じ商品が、場面によって違うコードで呼ばれています。

これ自体は避けられないことです。問題は、これらを相互に変換する対応表が整備されていない場合に起きます。片方のデータでは「A-1234」、もう片方では「4901234567894」となっていて、同じ商品だと機械的に判定できません。

さらに厄介なのが、1つの商品に複数のコードが紐づいている、あるいはシステムによって異なるコードで管理されているケースです。リニューアル前後の商品、荷姿違い、旧梱包の在庫。現場では区別して扱っているが、あるシステム上では同じ商品として扱われている——といった状況が生まれます。

あるある②：ロケーションの表記が揃っていない

同じ棚を指しているはずの番地が、システムや帳票によって違う書き方になっています。

同じ場所を指す表記の例

ハイフンの有無、ゼロ埋めの桁数、区切り方。人間が見れば同じだとわかりますが、単純に文字列として比較すると、システム上は別の値として扱われます。

この揺れは、複数のシステムを併用している現場や、増築・レイアウト変更を重ねた倉庫で起きやすくなります。「旧棟はこの命名規則、新棟は別の規則」といった具合です。

あるある③：ロケーションが増減する

棚の増設、レイアウト変更、繁忙期の臨時保管スペース。ロケーションは意外と変わります。

問題になるのは、マスタに登録されていないロケーションが実績データに現れるケースです。現場が臨時に使い始めた場所のコードが、マスタには存在しない。この実績は、エリア別に集計しようとすると「該当なし」に落ちます。

あるある④：作業者IDの欠番と使い回し

作業者マスタは、人の入れ替わりがある分だけ管理が難しくなります。

退職者のIDが残り続ける。 マスタに登録されたまま、実績には現れない。件数を数えると人数が実態より多く見えます。

IDが使い回される。 退職者のIDを新しい人に割り当てると、過去の実績と現在の実績が同一人物のものとして集計されてしまいます。

マスタに登録される前に作業が始まる。 派遣スタッフやスポット要員の場合、仮のIDや共通IDで作業が記録されることがあります。この実績は個人単位の分析から漏れます。

4. 見落とされやすい論点——「いつ時点のマスタか」

マスタ整備の話で最も見落とされやすいのが、時間の扱いです。

通常のマスタは、現在の状態を表します。一方でイベントデータは、過去に起きたことの記録です。この2つを突き合わせるとき、どの時点のマスタを使うのかという問題が生じます。

具体例

ある商品が、7月まではAエリアに保管され、8月からBエリアに移されたとします。

7月のピッキング実績を、現在のマスタ（Bエリア）で集計すると、7月にはBエリアで作業していたことになります。実際にはAエリアでの作業だったにもかかわらず、です。

同様のことは、商品カテゴリの見直し、担当チームの変更、ロケーションの再編でも起こります。

対処の考え方

どれが正解ということはなく、分析の目的によって選びます。組織変更をまたいだ長期比較が必要なら履歴の管理が要りますし、直近数か月の改善サイクルを回すだけなら最新マスタで十分なことも多くあります。

5. 整理の型——イベントを中心に、マスタを周りに置く

分析用にデータを整理するとき、広く使われている考え方があります。イベントデータを中心に置き、その周りにマスタデータを配置するという構造です。

▼ イベントを中心に据えた構造

この形にすると、集計の切り口を後から自由に変えられます。商品カテゴリ別で見たければ商品マスタを、エリア別で見たければロケーションマスタを参照するだけです。イベントデータそのものを作り直す必要はありません。

逆に、イベントデータに商品カテゴリなどの属性を直接持たせてしまうと、カテゴリ定義を変更した際に、過去データとの整合性をどう保つかという問題が生じます。

6. マスタ整備は、どこから手をつけるか

マスタ整備は、始めてみると際限がありません。全社の商品マスタを完全に統一しようとすれば、大きなプロジェクトになりかねません。

現実的な進め方は、KPIから逆算して必要な範囲に絞ることです。

Step 1：出したいKPIを1つ決める

「エリア別のピッキング生産性」「温度帯別の作業時間」など、具体的な指標を1つに絞ります。

Step 2：そのKPIに必要なマスタ属性を洗い出す

「エリア別のピッキング生産性」であれば、必要なのはロケーションマスタのエリア区分だけです。棚の高さも保管形態も、この段階では要りません。

Step 3：実績データに現れるコードが、マスタに揃っているか確認する

ここが実務の山場です。実績データに登場するロケーションコードを一覧にして、マスタと突き合わせます。マスタにないコード、表記が揺れているコードが必ず出てきます。

この作業は機械的に実施できます。「実績には現れるがマスタにないコード」の一覧を出すだけで、整備すべき範囲の全体像がつかめます。

Step 4：整備のルールを決める

表記を統一するのか、変換表を作って吸収するのか。既存システムの出力を変えられない場合は、後者を選ぶことになります。

まとめ：整理の型を持つと、議論が具体的になる

「データがあるのに分析できない」という状況は、多くの場合、マスタとイベントの関係が整理されていないことに起因します。

この2つを分けて捉えると、議論が具体的になります。「マスタが汚い」ではなく、「ロケーションコードの表記が3種類あって、変換表がない」。「データが使えない」ではなく、「実績に現れる商品コードの2割がマスタに存在しない」。問題が特定できれば、対処の範囲と工数も見積もれます。

そして、この整備は一度で終わるものではありません。商品は入れ替わり、レイアウトは変わり、人も入れ替わります。マスタを維持し続ける運用まで含めて設計しておくことが、データ活用を続けるための条件になります。