ERP 連携 生産管理ガイド｜データ契約・再送・取消のRFPと90日PoC

ERP 連携 生産管理で本当に難しいのは、APIをつなぐことではありません。ERPの製造指図を生産管理システムやMESへ渡し、現場実績、材料消費、完成、廃棄、保留をERPへ戻す途中で、「どのシステムの値が正しいか」「同じ取引を二度計上しないか」「順序が逆転したらどうするか」「取消と訂正をどう監査するか」を決めることです。本稿では、タイ工場の生産、経理、SCM、IT/OT責任者向けに、ERP―生産管理/MES間のデータ契約、system of record、ID、再送、オフライン、締め・原価照合、RFP、90日PoC、受入判定を具体化します。

この記事はMES製品のランキングでも、クラウドとオンプレミスの比較でもありません。既存ERPと既存または新規の生産管理/MESを、業務取引として破綻させずにつなぐことに焦点を置きます。結論は、画面やテーブルを直接同期するのではなく、業務オブジェクトごとに正本を一つ決め、命令と実績を分け、各メッセージへ一意な取引ID・版・発生時刻・取消関係を持たせ、再送と照合を平常運転として設計することです。

数値の読み方：IEC、ISA、OPC Foundation、ISO、GS1、NIST、BOIに帰属させた数値や仕様は一次資料に基づきます。一方、90日、P95 2秒/500ミリ秒、重複計上0件、可用性99.5%、RPO/RTO、費用・ROIはRFPを具体化するための提案例または仮定であり、業界標準値や成果保証ではありません。

ERPと生産管理/MESの境界を先に固定する

ISA-95は、Level 4をERPなどの事業計画・物流、Level 3をMESなどの製造オペレーション管理として整理します。IEC 62264-2:2026は、このLevel 3とLevel 4の間で交換する情報を相互に関連する概念オブジェクトモデルとして定義し、インターフェース実装のリスク、コスト、誤りを減らすことを目的としています。

この境界は「ERPは上、MESは下」という製品配置図ではありません。誰が製造オーダーを作るか、誰が設備・シフトへ割り付けるか、誰が作業開始を許可するか、誰が会計在庫と原価を確定するかという責任分界です。先に責任を決めなければ、双方が同じ数量を更新し、片方の訂正がもう片方で上書きされます。

system of recordを業務オブジェクト別に決める

表は出発点であり、全社共通の唯一解ではありません。PLM、WMS、QMS、LIMSが正本になる項目もあります。重要なのは「ERPもMESも編集可能」にしないことです。各項目に作成、承認、配布、訂正、廃止の責任者とSLAを置きます。

タイ MES選定のRFP・90日PoC・受入ガイドはMES自体の選定範囲を扱っています。本稿の範囲は、そのMESとERPの間で製造オーダーと実績を壊さず往復させる契約です。製品選定と連携受入を別の評価票にすると、優れた画面があるのに月末照合できない、という失敗を防げます。

データ契約は項目一覧ではなく業務上の約束

データ契約には、フィールド名と型だけでなく、意味、正本、単位、版、発生条件、順序、再送、取消、エラー責任を含めます。たとえばquantity=10だけでは、10個、10kg、良品10、不良を含む10、累計10、今回増分10のどれか分かりません。

最低限必要なエンベロープ

すべての命令・実績メッセージに、次を共通で持たせます。

• message_id：メッセージを一意に識別するID
• business_object_id：製造オーダー、実績、在庫移動などの業務ID
• event_type：Released、Started、Consumed、Completed、Cancelled等
• schema_version：メッセージ構造の版
• object_version：同一業務オブジェクトの改訂番号
• occurred_at：現場で出来事が起きた時刻とタイムゾーン
• recorded_at：システムが記録した時刻
• source_systemとsource_site
• correlation_id：一連の命令と応答を結ぶID
• causation_id：どのメッセージを原因として生まれたか
• reverses_id：取消・訂正対象の元取引ID

GS1 EPCIS 2.0は、eventIDの一意性、現実の出来事が起きたevent time、リポジトリへ記録したrecord time、現地のtime-zone offsetを区別しています。すべてのERP/MES連携にEPCIS採用を求めるわけではありませんが、時刻とIDを一つの列で済ませない設計例として有用です。

IDは表示コードと内部IDを分ける

タイ工場と日本本社で同じ品目を別コード管理している場合、文字列置換だけの変換表は壊れやすくなります。内部で変わらないグローバルIDを持ち、ERPコード、MESコード、旧コード、顧客コードをaliasとして有効期間付きで対応づけます。単位換算には係数だけでなく、丸め、最小単位、適用日、品目固有条件を持たせます。

ISA-95 Part 7は、異なる名前空間の等価IDと文脈を関連づける技術非依存のalias service modelを扱います。実装は標準製品でなくても構いませんが、ID対応の所有者、衝突、統合、分割、廃止を同じ問題として扱うべきです。

命令と実績を同じ更新にしない

ERPからMESへの製造オーダーは命令です。MESからERPへの生産実績は、現場で起きた事実の報告です。この二つを同じ共有テーブルのステータス更新にすると、誰が状態を進めたか、どこで失敗したか、取消が何を戻すか分からなくなります。

推奨する基本フローは次です。

1. ERPがオーダーをReleaseし、一意な版で送る。
2. 連携層が構文、必須ID、単位、有効版を検証する。
3. MESが受領し、同じオーダー・版への重複を安全に無視する。
4. MESが工程・設備・シフトへ割り付ける。
5. 現場イベントを増分で記録する。
6. ERPが実績を一件ずつ冪等に転記する。
7. 双方が受領・業務転記・却下を別ステータスで返す。
8. 日次照合で残数量、材料、良品、不良、廃棄を突合する。

「APIが200を返した」は業務転記成功を意味しません。HTTP受領、構文検証、業務検証、ERP伝票作成、会計期間受入の段階を分けます。応答には受領時刻、結果、理由コード、作成伝票IDを持たせます。

順序逆転・重複・取消を正常系として設計する

ネットワークやキューを使うと、再送や順序逆転は例外ではなく起こり得る状態です。Exactly-onceを製品機能の一語で保証するのではなく、アプリケーションが同じ業務結果を一度だけ計上する仕組みを受け入れます。

重複を無害にする冪等キー

材料消費なら、site + order + operation + material_lot + sequenceのような業務キーを定義します。同じmessage_idの再送は同じ結果を返し、新しい伝票を作りません。同じ業務キーなのに数量や単位が違えば上書きせず、競合キューへ送ります。重複排除期間は、オフライン端末が戻る最大日数と監査保存期間を踏まえて決めます。

順序逆転は版と前提条件で止める

CompletedがStartedより先に届く、変更版3が版2より先に届くことがあります。オブジェクト版と許可状態を確認し、前提を満たさないイベントを保留します。単純に受信時刻順に並べ替えると、ネットワーク遅延と実際の作業順を混同します。occurred_at、工程シーケンス、オブジェクト版を組み合わせます。

取消はDELETEではなく反対仕訳にする

すでにERPへ転記した材料消費や完成を削除すると監査経路が消えます。元取引を指す取消イベントを作り、数量・金額を反対計上し、その後に正しい取引を新規登録します。締め済み期間の取消は次期間調整になる場合があるため、ERPの会計ルールと品質記録の関係を事前に決めます。MES上の「再オープン」がERP伝票を自動削除する仕様は避けます。

生産実績連携は「増分・累計・状態」を混ぜない

実績数量の主要な設計ミスは、MESが累計10を送り、ERPが10ずつ増分計上することです。メッセージはdelta_quantityかcumulative_quantityかを明示し、単位と符号を持たせます。累計方式なら前回受入値、リセット条件、カウンタ巻戻りを定義します。増分方式ならイベント欠落と重複を監視します。

良品、不良、廃棄、手直し、保留を分ける

製造完了10の内訳が良品8、不良1、品質保留1なら、ERPへ単に10完成と送ってはいけません。数量状態と在庫ロケーションを対応づけ、品質判定後の移動も別イベントにします。手直しは元オーダーへ戻すか、手直しオーダーを作るかを品目群別に決めます。

材料消費と完成の因果を残す

バックフラッシュでは、完成数量から標準BOM消費をERPが計算する場合があります。一方、MESが実ロット消費を送る場合もあります。両方を同時に有効にすると二重消費になります。どの品目・工程を自動払出し、実績払出し、差異調整にするか表で管理し、BOM版と投入ロットを結びます。

日次照合と月次締めを連携機能に含める

連携の完成条件はメッセージが流れたことではなく、ERPとMESの業務残高が説明可能なことです。日次で少なくとも次を突合します。

差異ダッシュボードには件数だけでなく、金額、滞留時間、原因、再処理回数、締め影響を出します。「翌日自動で合う」ことを期待して差異を残すと、月末に大量の手作業が集中します。日次の未転記キューを生産・経理・ITが同じIDで追えるようにします。

製造原価管理システムで月末原価を日次判断へ変えるガイドでは、原価差異を日次で扱う考え方を説明しています。ERP連携の受入では、数量一致だけでなく、標準原価・実際原価・仕掛残・廃棄のどこへ差異が現れるかを同じテストケースで確認します。

オフラインと再送は現場停止を前提に決める

工場ネットワークが切れたとき、端末がローカルで記録を続けるか、工程を止めるかは業務リスクによって変わります。重要なのは「オフライン対応可」ではなく、何を何時間保持し、どの命令版まで実行でき、復旧時にどの順序で再送し、重複をどう無害化するかです。

outbox/inboxパターン

送信側は業務更新とoutbox登録を同じローカルトランザクションで確定します。連携サービスがoutboxを送信し、受信側はinboxへmessage_idを記録してから業務処理します。応答が消えても同じメッセージを再送でき、受信済みなら同じ結果を返します。これは実装パターンであり、データベースや製品だけで自動成立するものではありません。障害注入試験で確認します。

保持期間と復旧優先順位

端末や工場サーバのキュー上限、ディスク暗号化、電源断耐性、時刻ずれ、古い指示の失効を定義します。復旧時は、マスタ版→オーダー変更・取消→開始→材料消費→完成のように依存関係を考慮します。ただし現実のイベント順を一律に書き換えず、前提不足は保留して人が解決できる画面を用意します。

基幹システム連携のセキュリティ境界

NIST SP 800-82 Rev. 3は、OT固有の性能、信頼性、安全要求を考慮したセキュリティ指針を提供します。ERPからPLCへ直接書き込める広い権限を作るのではなく、Level 3の管理されたサービスで業務命令を検証し、必要最小限の信号に変換します。

RFPには、ネットワーク区分、相互認証、サービスアカウントの所有者、秘密情報の保管、最小権限、許可API、証明書更新、ログ、脆弱性対応、リモート保守、バックアップ、復旧演習を含めます。セキュリティ装置追加がタクトや設備可用性へ与える影響も、実ネットワークで測ります。

マスタデータ管理は移行作業で終わらない

ISO 8000-61:2016はデータ品質管理に必要なプロセスを規定し、データ品質向上や組織成熟度評価の参照に使えるとしています。ISOの公式ページでは2022年に確認され、現行版とされています。この事実から特定のデータ品質点数が自動的に決まるわけではありませんが、品質を一度のクレンジングではなく管理プロセスとして扱う根拠になります。

マスタ受入で測る項目

• 一意性：同じ現物を複数IDが指していないか
• 完全性：単位、工程、BOM、原価対象、有効期間が揃うか
• 整合性：ERP、MES、WMS、PLMのaliasが解決できるか
• 妥当性：コード体系、桁、許容値、参照関係を満たすか
• 適時性：承認後、必要なシフトまでに配布されるか
• 追跡性：誰が何をなぜ変更し、どのオーダーから有効か

初回移行件数が合っても、新製品、BOM改訂、代替材、設備追加で品質は下がります。変更申請、二者承認、配布、受領確認、差分照合、ロールバックまで運用にします。

ERP―MES連携RFPの必須項目

1. 業務シナリオと対象外

受注生産、見込生産、バッチ、連続、手直し、外注など対象形態を明記します。自動計画、設備制御、品質判定、原価計算のうち今回含めない範囲も書きます。

2. system of record表

業務オブジェクトとフィールド単位で、作成、承認、更新、取消、参照の責任を決めます。システム名だけでなく部門と役割も書きます。

3. データ契約

JSON/XML/CSVなどの構造、必須項目、単位、コード、タイムゾーン、schema/object version、例、異常例、サイズ、頻度、保持、個人情報を記載します。

4. 取引整合性

idempotency key、順序、重複、遅延、部分成功、取消、訂正、再送回数、dead-letter、手動再処理、監査を指定します。

5. 非機能と運用

ピーク件数、P95/P99応答、バッチ締切、可用性、RPO/RTO、監視、通知、時刻同期、保守時間、サポート言語、障害時責任を定義します。

6. セキュリティとOT制約

通信経路、認証、暗号、権限、秘密管理、ログ、端末、リモート接続、パッチ、PLC変更禁止領域、安全要求を明記します。

7. テスト・移行・終了

正常系だけでなく、再送、逆順、取消、締め済み、単位不一致、停電、ネットワーク断を試験します。データ移行、並行稼働、切替、戻し、契約終了時のデータ・設定・ソース返却も含めます。

90日PoCでインターフェースを受け入れる

90日は本稿の提案期間です。ERPの変更凍結、工場停止、監査、決算日程に合わせて調整します。

PoC対象は一つの工場、一つの製品群、一つの製造形態に絞ります。ただし正常フローを一本通すだけでは不十分です。材料消費応答の直前に回線を切る、同じ完成を100回再送する、取消を完成より先に送る、ERP期間を締める、MES時計をずらす、単位換算を変えるなど、実際に壊れ得る条件を買い手が用意します。

受入基準は業務結果と復旧証拠で決める

以下は提案例であり、工場のタクト、取引量、会計・品質要求に合わせて合意し直します。

受入ではログのスクリーンショットだけでなく、correlation_idからERP伝票、MESイベント、再送、取消、承認まで再構成できるデータを提出させます。集計値が合っても、個別取引が説明できない状態は不合格です。

費用とROIは「連携本数」ではなく複雑性で見る

見積を、業務分析、マスタ整備、API/メッセージ、連携基盤、ERP改修、MES改修、テストデータ、障害試験、監視、教育、並行運用、保守に分けます。インターフェースが一本でも、取消、複数単位、ロット、締め済み処理があれば複雑です。逆にイベント数が多くても共通契約と部品を再利用できれば展開費用を下げられます。

ROIの仮定例

以下は相場ではなく説明用です。月末・日次照合と再入力に月700時間、平均人件費180THB/時間、誤転記・在庫差異・緊急対応の回避便益を月220,000THBと仮定すると、月間粗便益は700×180+220,000=346,000THBです。初期費用4,200,000THB、月額運用90,000THBなら、単純回収は4,200,000÷(346,000−90,000)≒16.4か月です。実際は自動化率、差異回避率、停止損失を保守・標準・上振れの三ケースで測り、PoC後に更新します。

タイ工場で外せない実装条件

多言語の理由コード

エラーを日本語自由文だけで返すと、タイ側が判断できず日本本社へ毎回問い合わせます。UNKNOWN_ITEM、UNIT_MISMATCH、CLOSED_PERIOD、DUPLICATE、MISSING_PREDECESSORのようにコードを共通化し、画面説明と対応手順をタイ語・英語・日本語で管理します。機械判定コードは翻訳で変えません。

タイムゾーンと操業日

タイはUTC+7、日本はUTC+9です。夜勤の操業日、月末締め、サーバ時刻、イベント時刻、記録時刻を混ぜると、同じ実績が別日に見えます。タイムゾーン付きで保存し、production_dayは工場カレンダーから明示的に計算します。単に0時で日付を切りません。

現地サポートと責任分担

L1は現場手順、L2は連携キュー・マスタ、L3はERP/MES製品やコードの修正と分けます。タイ時間の対応窓、休日、夜勤、重大度、一次応答、復旧、エスカレーション先をRFPで決めます。複数ベンダー間で「相手の問題」となるのを防ぐため、共通の取引IDと共同障害演習を契約に入れます。

よくある失敗と修正

失敗1：DBテーブルを直接同期する

業務意味と製品内部構造が結びつき、アップグレードで壊れます。APIまたはメッセージで業務契約を置き、内部テーブル変更を隠蔽します。

失敗2：品目コードだけを合わせる

単位、版、有効日、ロット状態、工場が違えば同じコードでも意味が違います。グローバルIDとalias、有効期間、単位換算を管理します。

失敗3：通信成功を業務成功とみなす

HTTP 200でもERP期間締めや在庫不足で転記に失敗します。受領、検証、転記、却下を分け、ERP伝票IDまで返します。

失敗4：再送ボタンで重複計上する

再送は必ず起きます。message/business keyの冪等性を実装し、同じ取引100回の障害試験を受入にします。

失敗5：取消を削除で実装する

監査証跡と原価関係が消えます。元取引を参照する反対イベントと訂正イベントで残します。

失敗6：正常系だけでPoCを終える

本番問題は逆順、停止、月跨ぎ、単位不一致で起きます。障害注入と日次照合をPoCの中心に置きます。

失敗7：ERPからPLCへ直接書き込む

企業側の変更が設備動作へ直結し、OTの信頼性・安全境界を崩します。Level 3で検証・権限制御し、PLCへ必要最小限の命令だけを渡します。

ベンダー比較は共通テストパックで行う

配点例は、system of recordとデータ契約20、取引整合性25、ERP/MES実装20、運用・照合15、OTセキュリティ10、5年TCO10です。最低条件として、重複計上、監査できない取消、未定義のデータ所有権、ERPからPLCへの過大権限のいずれかが残れば総合点に関係なく不合格とします。

デモでは同じ製造オーダーとイベント一式を全社へ渡します。正常完了だけでなく、重複、逆順、欠損、取消、単位変更、締め済み、ネットワーク断を実行させます。結果は画面の見栄えではなく、作成伝票、残数量、キュー、監査鎖、復旧時間で比較します。

FAQ：ERP 連携 生産管理のよくある質問

ERPとMESはどちらをsystem of recordにすべきですか？

システム単位ではなく業務オブジェクト単位で決めます。一般にはERPが製造オーダー、会計在庫、原価を持ち、MESが工程実行、設備割付、実績イベントを持つ構成が多いものの、PLM、WMS、QMSを含む現行責任に合わせて決定します。

ERP MES連携はリアルタイムである必要がありますか？

すべてをリアルタイムにする必要はありません。作業許可や材料状態は秒単位、完成転記は分単位、原価集計は日次など、意思決定期限で決めます。高速化より、順序・重複・再送・照合の確実性を優先します。

生産実績連携は累計と増分のどちらがよいですか？

どちらも可能ですが、同じ取引で混ぜてはいけません。累計は前回値とリセット、増分は欠落と重複を管理します。数量種別、単位、符号、良品・不良状態を明示します。

基幹システム連携で取消はどう処理しますか？

原則として元取引を削除せず、元IDを参照する反対イベントを計上し、必要なら正しい訂正イベントを追加します。締め済み期間はERP会計ルールに従い、次期間調整や承認経路を定義します。

オフライン後の再送で二重計上を防ぐ方法は？

一意なmessage IDと業務キーを保存し、受信側が処理済み結果を返せる冪等設計にします。outbox/inbox、キュー保持、失効、順序、dead-letter、手動再処理を実装し、回線断と100回再送で試験します。

ERP連携の費用はどう見積もりますか？

API本数より、業務オブジェクト、マスタ、取消、複数単位、ロット、締め、オフライン、障害試験、監視、保守で分解します。一工程のPoC費用と全体展開の5年TCOを分けて比較します。

90日PoCの成果物は何ですか？

SoR表、データ契約、ID/alias辞書、API・メッセージ仕様、正常/異常テスト、日次照合、障害復旧、運用手順、教育、課題、展開TCOを成果物にします。画面と通信ログだけでは不十分です。

まとめ：つなぐのではなく、取引を一致させる

ERP 連携 生産管理の目的はデータ転送ではありません。製造オーダー、材料、完成、不良、在庫、原価を、現場と基幹で同じ業務事実として説明できる状態を作ることです。そのためにsystem of record、IDとalias、命令とイベント、版、順序、冪等性、取消、日次照合、オフライン復旧をデータ契約へ落とします。

TOMAS TECHでは、タイ工場の既存ERP・MES・現場帳票を前提に、連携境界の整理、データ契約、RFP、障害テストを含む90日PoCの検討段階からご相談いただけます。全面刷新を決める前に、一つの製造オーダーを端から端まで追跡し、どこで取引が崩れるかを一緒に可視化します。お問い合わせはこちら。

参照資料

• IEC 62264-2:2026 — Enterprise-Control System Integration
• ISA-95 Series of Standards
• OPC UA Common Object Model: ISA-95
• OPC Foundation: ISA-95
• ISO 8000-61:2016 — Data quality management
• GS1 EPCIS 2.0 Standard
• NIST SP 800-82 Rev. 3 — Guide to OT Security
• Thailand BOI: Q1 2026 investment applications