受注システム、配車システム、倉庫システムに必要なデータはある。それでも、同じ出荷をシステム間で結び付けられず、集計に時間がかかっている――。こうした場合は、番号の形式だけでなく、その番号が何を識別しているかを確認する必要があります。
受注番号は注文を、便番号は運行を、拠点コードは組織や場所を識別します。それぞれが表す対象は異なるため、番号を一つにそろえるだけでは、正しい対応関係は作れません。
物流データ統合では、まず記録の単位を決め、番号が重複しない範囲を確認します。そのうえで、受注・出荷・運行を結ぶ対応表と、拠点などの情報を管理するマスタを整えます。
本記事では、情報システム・データ担当者に向けて、集計の誤りを防ぎながら物流データをつなぐ方法を解説します。以下のキーや管理表は社内設計の例であり、物流効率化法で一律に指定された形式ではありません。
1．最初に「一行が何を表すか」を決める
データを結び付ける前に、それぞれの表の一行が何を表しているかを確認します。この記録の細かさを、データの「粒度」と呼びます。
例えば、次のような違いがあります。
| データ | 一行が表す対象の例 | 識別に使う項目の例 |
|---|---|---|
| 受注明細 | 一つの受注に含まれる一つの明細 | 受注番号、明細番号 |
| 出荷明細 | 一回の出荷に含まれる一つの明細 | 出荷番号、明細番号 |
| 運行実績 | 一回の運行 | 運行を一意に識別する番号 |
| 施設訪問実績 | 一つの運行における一回の立ち寄り | 運行ID、訪問ID |
実際の識別項目は、各システムの採番ルールによって異なります。表に示した項目だけで、必ず一意になるという意味ではありません。
また、同じ車両が一日に複数回運行する場合、車両番号だけでは運行を識別できません。同じ便が一つの施設を複数回訪れる場合も、便番号と施設コードだけでは訪問を区別できないことがあります。
まずは対象を一つ選び、「この表の一行は何か」を関係部門で合意しましょう。
2．番号が重複しない範囲を確認する
受注番号や便番号を、そのまま全社共通キーにしない
あるシステム内では重複しない番号でも、別会社、別拠点、別年度のデータと合わせると重複する場合があります。
例えば、A社とB社の双方に「受注番号000123」が存在することはあり得ます。この番号だけで結合すると、別の注文を同じものとして扱うおそれがあります。
そのため、キーの候補を検討するときは、次の点を確認します。
- 番号を発行する会社・システム・拠点はどこか
- どの範囲で番号の一意性が保証されているか
- 年度や日付が変わると番号が再利用されるか
- 訂正・取消・再発行で番号が変わるか
- 一つの番号に複数の明細や履歴が存在するか
必要に応じて、発行元システム、会社コード、受注番号、明細番号などを組み合わせます。ただし、項目を増やせばよいのではなく、実際の採番ルールに合っていることが重要です。
データベースでは、複数列を組み合わせて一意性を管理できます。例えばPostgreSQLの主キーは、単一列または複数列で構成でき、重複とNULLを認めない仕組みです。PostgreSQL公式文書「Constraints」
元の番号と、統合後のIDを両方残す
統合先で独自のIDを付ける場合も、元のシステム名と元の番号を残します。
例えば、統合先の「出荷ID」と、倉庫システムの「出荷番号・明細番号」を対応付けておけば、集計結果から元の記録を確認できます。
ただし、新しいIDを付けることと、同じ出荷かどうかを判定することは別です。連番などを付与しただけでは、システム間の対応関係は確定しません。
表記を整える前に、コードの意味を確認する
「0012」と「12」が同じコードかどうかは、元システムの仕様によります。先頭のゼロ、ハイフン、英字の大文字・小文字を、確認せずに削除・変換しないようにしてください。
変換が必要な場合は、元の値と変換後の値を分けて保存し、適用したルールを記録します。
3．受注・出荷・運行は、対応表でつなぐ
受注と出荷、出荷と運行は、必ず一対一になるわけではありません。
一つの受注が複数回に分けて出荷される「分納」もあれば、複数の出荷を一つの便に積む「積み合わせ」もあります。中継輸送では、同じ貨物が複数の運行区間を通ることもあります。
このような場合は、受注・出荷・運行を無理に一対一で結ばず、対応関係を別の表で管理します。
例えば、次のような情報を持たせる方法があります。
- 受注明細IDと出荷明細ID
- 出荷明細IDと運行ID・区間ID
- その対応関係に属する数量と単位
- 予定か実績かの区分
- 対応を確認した根拠と確認状況
一つの出荷明細を複数便へ分ける場合は、各便に割り当てた数量を記録します。中継輸送では、出荷数量の集計と区間別の輸送実績の集計を分け、同じ貨物を複数区間で運んだ数量を、そのまま出荷数量に足さないようにします。
また、受注データと出荷データの両方にある数量を、同じ意味の数量として合計しないことも重要です。
4．仮想例：分納と積み合わせを区別する
以下は説明のための仮想例であり、実在企業の実績ではありません。同一商品・同一入数のケースを扱い、各出荷明細は表に示す一便だけで輸送されたものとします。
受注明細A100-01の100ケースを、60ケースと40ケースに分けて出荷します。さらに、別の受注明細A200-01の30ケースを、後半の便に積み合わせます。
| 受注明細ID | 出荷明細ID | 運行ID | 当該便で輸送した数量 |
|---|---|---|---|
| A100-01 | S01 | T01 | 60ケース |
| A100-01 | S02 | T02 | 40ケース |
| A200-01 | S03 | T02 | 30ケース |
この例では、受注明細は2件、出荷明細は3件、運行は2便です。表が3行あるからといって、3便とは数えません。
数量についても、次のように集計対象を分けます。
- A100-01に対応する出荷数量：60＋40＝100ケース
- T02で輸送した数量：40＋30＝70ケース
- 全出荷数量：60＋40＋30＝130ケース
もし、受注明細A100-01の「受注数量100ケース」を二つの出荷行に付け、その列を合計すると200ケースになります。元の受注数量が、分納先の行数だけ繰り返し表示されるためです。
結合後の表では、「表示されている数値」と「そのまま合計してよい数値」を区別してください。
5．拠点マスタは、コード・役割・有効期間を管理する
同じ名称や住所だけで、同じ拠点と判断しない
「東京センター」という名称が複数存在したり、一つの建物に複数の事業者や荷受け場所が入っていたりすることがあります。
また、請求先、納品先、出荷元、実際に貨物を受け渡す施設は、同じとは限りません。
拠点マスタには、社内の統合拠点IDに加えて、元システム、元コード、名称、所在地、拠点の役割などを整理します。必要に応じて、施設と、その内部のバースなどを別の管理単位にします。
標準コードを利用する場合は、そのコードが何を識別するものかも確認してください。例えばGLNは、事業者や部門、物流センターなどの物理的な場所、電子的な場所を識別するGS1の標準コードです。GS1 Japan「GLN（企業・事業所識別コード）」
標準コードがある場合でも、自社で集計したい施設単位との対応を確認する作業は必要です。
最新の情報で、過去の実績を不用意に書き換えない
拠点の統廃合や担当組織の変更があった場合、最新マスタだけで過去の実績を集計すると、当時とは異なる区分に振り分けられることがあります。
「当時の組織・拠点区分で見る」のか、「現在の区分に組み替えて比較する」のかを決め、両者を区別します。
履歴を残す設計では、マスタやコード対応表に適用開始日・終了日などを持たせ、対象の業務日付に対応する情報を参照する方法があります。こうした有効期間を用いた履歴管理は、データ分析モデルの設計でも使われています。Microsoft Learn「スター スキーマとPower BIでの重要性」
対応表を使う際は、一つの元コードが、同じ役割・同じ時点で意図せず複数の統合先に結び付かないかも確認しましょう。
6．未照合・重複・訂正を、別の状態として扱う
データが結び付かない理由は一つではありません。
元の番号が欠けている場合もあれば、相手側のデータがまだ届いていない場合、取消済みの場合、候補が複数ある場合もあります。
これらを一律に「データなし」とせず、状態を分けて管理します。
| 状態 | 確認する内容 |
|---|---|
| キーが未記録 | 元システムから再取得できるか |
| 対応先が見つからない | 更新の遅れ、対象期間、コード体系に違いがないか |
| 対応候補が複数ある | 分納・積み合わせなのか、誤った結合なのか |
| 同じキーの行が複数ある | 重複取込なのか、正当な明細・変更履歴なのか |
| 取消・訂正がある | どの記録が有効で、集計へどう反映するか |
日付や数量が似ているだけで、同じ出荷と確定しないことが重要です。推測による候補は、確認済みの対応関係と区別して残します。
また、キーの欠損を一律に「0」などの共通値へ置き換えて結合すると、本来無関係な記録同士がつながるおそれがあります。未確認の記録は、実在する同一取引として結合しない設計にしてください。
7．結合できたかだけでなく、集計が正しいかを検証する
データ統合の確認は、「エラーなく処理が終わった」で完了にはなりません。
次のようなテストを行います。
- 一意であるべきキーに、欠損や重複がないか
- 対応表が参照している受注・出荷・運行が存在するか
- 分納や積み合わせが、想定した対応関係になっているか
- 結合後に、数量・重量・金額が意図せず増減していないか
- マスタの有効期間に重複や空白がないか
- 同じデータを再取り込みしても、実績が二重に増えないか
- 取消・訂正が、定めたルールどおり反映されるか
分納などによって結合後の行数が増えること自体は、必ずしも誤りではありません。どの対象を数えているかと、数量などが意図どおり集計されているかを確認します。
データベースの外部キー制約は、参照先に存在しない値の登録を防ぐなど、表同士の整合性を保つために利用できます。ただし、存在する別の出荷へ誤って結び付けた場合まで、業務上の正しさを保証するものではありません。PostgreSQL公式文書「Foreign Keys」
システムの検査と、業務担当者による元記録の確認を組み合わせましょう。
8．管理担当と変更ルールを決める
結合キーやマスタは、最初に作って終わりではありません。システム変更、拠点の追加、採番ルールの変更などに合わせて、管理を続ける必要があります。
役割分担は、例えば次のように整理できます。
- 情報システム・データ担当：キー設計、結合処理、検査、変更履歴を管理する
- 物流企画：集計対象と指標を定義し、結果の業務上の妥当性を確認する
- 営業・調達・倉庫・配車担当：番号や実績の意味、分納・取消などの扱いを確認する
- マスタ管理担当：コード対応、適用日、追加・変更の承認を管理する
これは社内運用の例です。自社の組織に合わせ、判断が分かれた場合の確認先も決めます。
変更時には、変更理由、適用開始日、影響する集計、過去データを再計算するかどうかを記録してください。元データの取得日時や処理ルールの版も残しておくと、数値が変わった理由を説明しやすくなります。
物流効率化法への対応では、統合と算定を分けて考える
荷主の判断基準では、物流の状況把握、デジタル技術の活用、物流データの標準化などが示されています。国土交通省「荷主の判断基準等」
ただし、データが正しく結び付いたことと、法定報告の条件を満たしたことは別です。
例えば、荷待ち時間等の報告には、計測対象や計測方法について公式の案内があります。社内の拠点コードや便番号を、そのまま法定報告の施設・運行の単位として使えるかは、個別に確認する必要があります。国土交通省「定期報告」
社内分析用のデータから報告値を作る場合は、対象範囲、計算式、除外条件、元記録との対応を説明できるようにしましょう。
まとめ
物流データ統合では、受注番号・便番号・拠点コードを機械的に連結するのではなく、それぞれが何を識別しているかを確認することが出発点です。
一行の単位と番号の一意性を整理し、分納や積み合わせは対応表で管理します。拠点マスタには必要な履歴を残し、未照合や訂正を区別したうえで、件数・数量・金額を検証します。
まずは一つの取引や配送区間について、受注から出荷、運行、施設訪問までを追ってみてください。元の記録へ戻れる対応関係を作ることが、信頼できる集計と改善判断につながります。
本記事は、2026年10月27日時点で確認した公式資料・技術文書に基づく一般的な実務解説です。具体的なキー構成や管理方法は、自社システムの仕様と業務ルールに合わせて設計してください。
出典・参考資料
［1］Constraints（PostgreSQL 18公式文書）
［2］GLN（企業・事業所識別コード）（GS1 Japan）
［3］スター スキーマとPower BIでの重要性を理解する（Microsoft Learn）
［4］荷主（第一種・第二種）の判断基準等（国土交通省）
［5］定期報告（国土交通省）
