「在庫」という同じ語が、3つの違うものを指している
三重管理が起きる根本原因は、システム間で在庫の定義が違うことです。同じ「部品Aが500個ある」という状態を、3つのシステムはこう見ています。
- ERP：金額として500個分の資産がある。会計期間の締めで残高が確定する。関心は評価と引当
- WMS：どの棚のどのロケーションに何個あるか。関心は位置と作業効率
- MES：そのロットは有効期限内か、検査に合格しているか、この指図に投入してよいか。関心は使用可否
この3つは重複しているようで、実は別の問いに答えています。だから「どれか1つにまとめる」という発想は多くの場合うまくいきません。まとめるのではなく、場所ごとに誰が正かを決めるのが実装上の解です。
所有権マップを1枚作る
設計の実作業は、次の1枚の表を埋めることです。行が場所、列がシステム、セルに「正／参照／持たない」を書きます。
この図の要点は、3システムが同じ場所を持っていても、持っている属性が違うことです。ライン側置場については、WMSは関与せず、ERPは金額だけを持ち、数量と状態はMESが正。完成品倉庫については、ロケーションはWMS、状態（出荷可否・保留）はMESという分担になります。
実務では、この表を場所マスタの単位まで細かく作ります。行が20〜40行になるのが普通です。この表を作らずに3システムを繋ぐと、同じ場所を3つのシステムが更新しに来て、最後に更新したものが勝つという状態になります。
設計で決める3項目
1. 正の所在（Source of Truth）を場所単位で決める
「品目マスタはERPが正」のようにマスタ単位で決めるのは容易ですが、在庫残高は場所単位で決める必要があります。1つの倉庫の中でも、原材料エリアはWMS、隔離エリアはMESというように分かれることがあります。
2. 更新の方向を一方通行にする
双方向同期は、必ず競合の解決ルールが必要になり、複雑さが跳ね上がります。原則として、正を持つシステムから他へ一方通行にします。他システムから正へ書き戻す必要が出た場合は、直接更新ではなく「調整依頼」というトランザクションを経由させ、正の側で受け付ける形にします。
3. 同期の方式とタイミング
| 方式 | 遅延 | 実装の重さ | 向く用途 |
|---|---|---|---|
| イベント都度連携（API／メッセージ） | 秒 | 中〜重。再送設計が必須 | 出庫指示、入庫報告、検査合否 |
| 短周期バッチ（15分〜1時間） | 分 | 軽い | 在庫残高の参照同期 |
| 日次バッチ | 日 | 最も軽い | 会計向け残高、マスタ配信 |
| 参照のみ（同期しない） | ― | 最軽量 | 他システムの画面を呼び出して見せる |
最後の「同期しない」を選択肢に入れるのが重要です。参照するだけなら、コピーを持つ必要はありません。在庫の重複保持の何割かは、「見たいから持つ」という理由で発生しており、画面呼び出しやAPI参照で代替できます。
よくある実装の失敗4つ
失敗1：ロケーション体系を3システムで別々に作る。 WMSが A-01-03-2、MESが ライン1前置場、ERPが 1000（プラント）という別体系を持ち、変換表で繋ぐ設計は、拠点追加やレイアウト変更のたびに保守が発生します。最低限、コード体系だけは統一するか、少なくとも1つのシステムのコードを他が参照する形にします。
失敗2：引当をMESとERPの両方でかける。 ERPが計画に基づいて引当をかけ、MESが実際の投入時にまた引当をかけると、同じ在庫が二重に押さえられ、実在庫があるのに「引当済で使えない」という状態が生まれます。引当は計画引当（ERP）と実引当（MES）で意味が違うことを明示し、ERP側の引当は解放条件を設計します。
失敗3：単位変換をシステム間で暗黙にする。 kgとm、巻と本、ケースとピースの変換をどこで行うか。変換係数を複数のシステムが個別に持っていると、係数変更時に片方だけ更新される事故が起きます。変換は1か所に置きます。
失敗4：在庫の「状態」をERPの在庫区分で表現しようとする。 検査待ち、保留、条件付き合格、再作業待ち、廃棄待ちといった状態は、ERPの標準在庫区分（利用可能・品質検査中・保留の3種程度）では表現しきれません。無理に対応させると、区分を増やす改修が発生します。細かい状態はMESが持ち、ERPへは「利用可能／不可」の2値に集約して渡すのが保守しやすい設計です。
製品による実装差
MESの在庫機能は製品ごとの思想差が大きい領域です。選定時に確認すべきは次の3点です。
- 在庫単位の粒度：ロット単位までか、コンテナ／パレット単位まで持てるか。後者を持つ製品は、入出庫・ピッキングの運用をMES側で組めます。
- 倉庫機能の作り込み度：DassaultのDELMIA Aprisoのように製造・品質・倉庫・保全を単一データモデルで扱うMOM製品は、WMSを別途置かずに一定規模までカバーできます。一方、製造実行に特化した製品では倉庫機能が薄く、WMSとの連携設計が前提になります。どちらが良いかは、倉庫作業の複雑さ（自動倉庫の有無、多階層ロケーション、出荷波取り）で決まります。
- 在庫トランザクションの外部公開：在庫の増減イベントを外部へ流せるか。ここが弱いと、仕掛在庫の照合を月次で回す仕組みが作れません。
WMSを導入せず、MESの在庫機能だけで倉庫を回せますか？
倉庫作業の複雑さ次第です。判断の目安は、①自動倉庫やAGVがあるか、②1日の出庫指示が数百件を超えるか、③ロケーションが3階層以上か、④出荷の波取り（複数オーダーをまとめてピックし、後で仕分ける）が必要か、の4点です。1つも当てはまらないなら、MESの在庫機能で十分に回ります。2つ以上当てはまるなら、WMSまたは倉庫制御システムを分けたほうが、結果的に総コストは下がります。中間的なケースでは、MOM型のMES製品が持つ倉庫モジュールで対応できることがあるので、実データでのデモを求めてください。
在庫の実地棚卸は、どのシステムを基準に行いますか？
物理カウントの結果を最初に受けるのは、ロケーションを持つシステム（WMS、なければMES）です。そこで差異を確定し、調整トランザクションとしてERPへ流します。逆にERPで直接調整すると、MESとWMSは差異を知らないまま残り、次の棚卸でも同じ差が出ます。重要なのは、調整の証跡を1本の流れとして残すことです。誰が、いつ、どの在庫単位を、いくつ、どういう理由で調整したかが追えないと、規制産業では監査での指摘対象になります。棚卸差異の調整権限は、現場ではなく在庫管理責任者に限定するのが原則です。
