生産管理システム マイグレーション｜切替・照合・ロールバック設計

生産管理システム マイグレーションで本当に怖いのは、データが移らないことだけではありません。受注、製造指図、払出、完成、検査、出荷、取消という一連の出来事が、旧システムと新システムで違う意味に解釈されることです。マスタと伝票を予定件数だけ変換できても、保留中の受注が確定扱いになったり、再送された実績が二重計上されたりすれば、工場の状態は一致しません。

したがって成功条件は「何件移したか」ではなく、同じ受注・在庫・実績が旧新で同じ状態遷移になると、証跡付きで証明できることです。本稿ではタイの工場でERP／生産管理／MESを切り替える責任者に向けて、データ契約、ID・単位・時刻、差分照合、並行稼働、再送の冪等性、取消、cutover、ロールバック、業務受入証跡を一つの設計にまとめます。クラウドとオンプレミスの製品比較ではなく、移行を合格させるための記事です。

生産管理システムのデータ移行は「コピー」ではなく状態の再現である

受注番号、品目コード、数量、日付が移っていれば、画面上は成功に見えます。しかし生産管理の数字には、必ず業務上の文脈があります。在庫100個でも、使用可能、検査待ち、品質保留、外注支給、引当済みでは意味が違います。製造実績10個でも、仕掛、工程完了、完成入庫、取消待ちのどこにいるかで、次に許される処理が変わります。

移行対象はテーブルではなく、少なくとも次の三つです。

1. 識別子と属性：受注、品目、BOM、工程、ロット、設備、保管場所、取引先、作業者をどう一意に指すか。
2. 現在状態：数量だけでなく、承認、保留、引当、着手、完了、取消などの業務状態。
3. 状態を作った出来事：いつ、誰が、どの端末・連携から、何を理由に状態を変えたか。

ISA-95は製造オペレーションと企業業務の境界、情報モデル、取引、識別子の別名対応を整理する標準群です。2025年版Part 1を含むISA公式のISA-95概要は、Level 3の製造オペレーションとLevel 4のERP等を技術製品名ではなく活動と情報で分けます。移行設計でも「旧テーブルAを新テーブルBへ」から始めず、「誰がどの業務事実を所有し、どの状態遷移を相手へ通知するか」から始めるべきです。

変換件数が一致しても移行に失敗する六つの理由

第一は、同じ名称でも意味が違うことです。旧システムの「完了」が工程完了を指し、新システムの「完了」が完成入庫まで含むなら、コード変換が正しくても在庫はずれます。

第二は、識別子の粒度が違うことです。旧側では品目と工程の組合せが一意でも、新側では工場、改訂、代替工程まで含めなければ一意にならない場合があります。先頭ゼロ、大文字小文字、全角半角、拠点接頭辞の扱いも衝突を生みます。

第三は、単位換算です。「1 BOX = 20 PCS」が常に同じとは限りません。品目、仕入先、荷姿、適用期間で換算係数が変わるなら、数量と単位と換算根拠を一緒に持つ必要があります。丸め規則が購買、在庫、原価で異なることもあります。

第四は、時刻です。タイ工場のローカル時刻、UTC、日本本社時刻、PLCの未補正時計が混在すると、同じ出来事の順序が逆転します。ISO 8601-1:2019は情報交換に用いる日付・時刻とUTCに基づく時差表現を定めています。移行では表示形式だけでなく、発生時刻、受信時刻、タイムゾーンまたはUTCオフセット、設備時計の品質を記録します。

第五は、再送です。ネットワーク断の後に端末が同じ実績を再送すると、単純なINSERTは二重計上になります。「通信できた」と「一度だけ業務反映された」は別問題です。

第六は、取消と遡及訂正です。月末後の実績訂正、ロット分割のやり直し、出荷取消、バックフラッシュの再計算は、現在値だけを移すと理由と連鎖が消えます。正常系の最終残高が合うだけでは不十分です。

フィールドマッピングより先にデータ契約を作る

データ契約は、API仕様書だけではありません。各業務オブジェクトについて、意味、所有者、識別子、状態、許可される遷移、単位、時刻、版、欠損時の扱い、重複判定、訂正方法、保存証跡を旧新双方が合意したものです。最低限、次の列を持つ一覧を作ります。

データ契約に空欄がある状態でETLを実装すると、開発者が暗黙に意味を決めることになります。空文字を未設定と見るか、有効な「空」の値と見るか。存在しないコードを捨てるか、仮コードへ寄せるか、処理を止めるか。これらは変換ロジックではなく業務判断です。判断者、期限、暫定統制を明記してからコードに落とします。

ID・単位・時刻を正規化し、原値を捨てない

新しい統合IDを作る場合でも、旧IDを上書きしてはいけません。source_system、source_id、target_id、valid_from、valid_toを持つクロスリファレンスを作り、移行バッチ、変換版、実行者を追跡できるようにします。統合後に現場が旧伝票番号を提示しても検索できることが重要です。

単位は数値に埋め込まず、原数量、原単位、換算数量、基本単位、係数、丸め規則を分けます。例えば12.5 kgをPCSに変える業務に固定換算を当てるのではなく、品目の有効版と実測・理論どちらを使ったかまで残します。差異が出たとき、原因を「移行誤り」「マスタ誤り」「現場計量差」に分けられます。

時刻は少なくとも event_time と received_time を分けます。設備や端末がオフラインなら、受信順は発生順になりません。タイの深夜に発生した実績が日本本社の日付では翌日になることもあります。締め日、勤務日、シフト日、会計日は単純なカレンダー日と別の業務属性として扱います。

状態遷移台帳で「同じ業務になったか」を証明する

照合の中心は状態遷移台帳です。旧新の各イベントを、共通の業務キーと標準イベントへ正規化して並べます。例えば製造指図なら、RELEASED → STARTED → PARTIAL_COMPLETE → COMPLETED → CLOSEDを基本線とし、ON_HOLD、CANCELLED、REOPENED、REVERSEDを例外線として持ちます。自社用語は異なっても、比較用の標準状態に投影できれば差分が見えます。

台帳には、業務キー、イベントID、前状態、後状態、数量、単位、ロット、発生時刻、原因コード、操作者、送信元、処理結果、関連イベントIDを残します。取消は元イベントを削除せず、どのイベントを打ち消したかを関連付けます。これで「現在残高は同じだが、誤った履歴を相殺して偶然合った」というケースを区別できます。

GS1 EPCIS 2.0.1は、アプリケーションや企業をまたいで可視化イベントを作成・共有するための公式標準です。自社がEPCISを採用しない場合でも、何が、いつ、どこで、どの業務文脈で起きたかをイベントとして残す考え方は、ロットトレース移行の試験設計に役立ちます。

ゴールデンシナリオは正常系より例外系を厚くする

移行試験用のゴールデンシナリオは、代表的な伝票を一件選ぶだけでは足りません。次のような「工場で困る流れ」を、入力、期待状態、会計・在庫影響、証跡まで定義します。

• 受注数量の増減後に製造指図を分割し、一部だけ出荷する。
• 代替材料を払い出し、余剰を戻し、元ロットと代替ロットを追跡する。
• 同じ実績メッセージを三回送り、業務反映は一回だけになることを確かめる。
• 完了実績を取り消し、仕掛・在庫・原価・トレースが整合して戻ることを確かめる。
• 品質保留ロットを出荷不可にし、解除後だけ引当可能にする。
• オフライン端末の古いイベントが後着しても、順序逆転や二重計上を起こさない。
• BOM改訂日前後に同じ品目を生産し、正しい版と使用量になる。
• 日跨ぎ、月跨ぎ、タイと日本の時差、サマータイムを持つ外部拠点を含めて締めを確認する。
• ERP側の受注取消がMES処理中に到着したとき、拒否・保留・補償処理のどれになるかを確認する。

OPC UA PubSubは、デバイスネットワークからIT／分析クラウドまでデータとイベントを配布するpublish-subscribeモデルを定義しています。OPC UA Part 14 v1.05.06が示すように、配布モデル、メッセージ、設定は重要です。ただしbrokerやAPIの受領成功は、製造指図が業務ルールを通過し正しく計上された証明ではありません。輸送、受信、検証、業務反映、後続処理を別ステータスで監視します。

並行稼働は「二重入力」ではなく比較実験として設計する

旧新二重稼働には三つの主な形があります。一つ目は、旧を正として新へ複製し、新は参照・比較だけに使うshadow runです。業務への影響を抑えやすい反面、新側からの操作や例外処理を十分に試しにくくなります。

二つ目は、利用者が旧新双方へ同じ入力を行うdouble entryです。画面と手順を含めて比較できますが、現場負荷が高く、入力時刻や担当者の違い自体が差分になります。単純に「数字が違う」と判定せず、許容時間差と入力責任を決めます。

三つ目は、製品群、ライン、工程、拠点などで業務責任を分けるphased ownershipです。段階移行しやすい一方、在庫、共通マスタ、ロット追跡、原価が境界をまたぐため、どちらが正本かをオブジェクト単位で定義する必要があります。

二重書き込みは安全策に見えますが、部分成功が起きます。旧だけ成功、新だけ成功、両方成功したが処理順が違う、片方の取消だけ失敗する、といった状態です。二重書きを採用するなら、各書込みのID、結果、再送、補償処理、競合解決、監視担当を設計します。設計できない場合は、単一入力からイベント複製し、比較側を非正本にする方が境界を明確にできます。

並行期間は長ければ安全とは限りません。二重作業による疲労、暫定手順の常態化、差分未処理の蓄積が起きます。「何日動かすか」だけでなく、代表シナリオが何回通り、未解決差分がどの条件まで減り、誰が終了を承認するかを出口条件にします。

差分照合は件数・業務状態・トレース経路の三層で行う

第一層は技術照合です。ファイル数、行数、必須値、型、桁、参照整合性、ハッシュ、最大・最小日付などを確認します。これは欠落や破損を早く見つけるために必要ですが、合格の入口にすぎません。

第二層は業務照合です。受注残、未完指図、工程別仕掛、ロット別使用可能在庫、保留在庫、引当、完成、出荷、取消待ちなどを、同じ業務キーと基準時刻で比較します。集計総数だけでなく、明細、状態、年齢、所有拠点まで掘ります。合計100が一致しても、ロットAが20不足しロットBが20過剰なら不合格です。

第三層は経路照合です。原材料ロットから使用指図、工程実績、完成ロット、出荷先へ前方追跡し、出荷ロットから原材料・設備・検査へ後方追跡します。リンクが途中で切れないか、分割・統合・手直し・代替を正しく辿れるかを確認します。

診断用のカバレッジは次のように定義できます。

状態一致率 = 旧新で終端状態が一致した対象業務キー数 ÷ 対象業務キー総数 × 100

これはTOMAS TECHの整理用指標であり、業界標準の合格率ではありません。分母、除外、基準時刻、許容差、重要度を先に固定します。重要な品質保留や出荷取消は一件の不一致でもGo/No-Goを止める場合があり、平均率で相殺してはいけません。差分は件数だけでなく、原因分類、業務影響、暫定統制、担当者、期限、再試験結果を持つ台帳にします。

再送を安全にする冪等性と取消の設計

冪等性とは、同じ意図の要求を複数回受けても、業務結果を一回分に保てる性質です。単に同じpayloadを無視するだけではありません。送信側が再採番した場合、順序が逆になった場合、内容が変わった再送、取消後の再計上を区別する必要があります。

実務では、送信元システム、業務オブジェクト、イベントID、イベント種別、版または連番を組み合わせた冪等キーを定めます。受信側は「初回処理済み」「処理中」「拒否」「再処理可」「取消済み」を記録し、保持期間を業務上の再送可能期間より短くしません。同じキーで内容が異なる要求は黙って上書きせず、隔離して調査します。

取消はDELETEではなく、元取引を特定する補償イベントとして扱うと追跡しやすくなります。すでに後続の払出、完成、出荷、会計連携がある場合、単純に元状態へ戻れません。どこまで自動逆転でき、どこから承認付き例外になるかを決めます。旧システムに取消コードが一種類しかなく、新システムに複数の理由・状態があるなら、データ移行時に意味を創作せず「旧由来・理由詳細不明」を明示した移行値を設けます。

システム切替計画を時系列の統制に変える

cutoverは本番環境へデータを一度投入する作業ではありません。依存システム、利用者、設備、帳票、ラベル、EDI、会計、倉庫を、決めた順序と判断点で切り替える統制です。AWSのcutoverガイダンスも、取り込み停止、最終バックアップ、最終同期、経路変更、検証を分け、変更後データがある場合のrollbackは単純な接続戻しではないと説明しています。クラウド移行向けの一般論ですが、工場システムにも有効な分解です。

切替runbookには最低限、次を分単位またはイベント単位で書きます。

1. 変更凍結の開始と例外承認者
2. 旧側入力停止または対象範囲の隔離
3. 未送信キュー、未処理伝票、保留ジョブの確認
4. 最終バックアップと復元確認済み世代の特定
5. 増分抽出、変換、投入、技術照合
6. 受注・在庫・実績・トレースの業務照合
7. 端末、ラベル、API、バッチ、EDI、帳票の疎通
8. Go/No-Go会議の入力資料、権限者、期限
9. 新側の入力開始と監視強化
10. rollbackまたはfail-forward判断の最終時刻
11. 旧側を参照専用へ移す条件
12. 引継ぎ、翌シフト確認、日次締め、月次締めの追跡

各行に開始条件、担当、実施者、確認者、期待結果、証拠へのリンク、失敗時の分岐、最大所要時間を持たせます。担当者名だけでなく代替者と連絡経路を決めます。タイ拠点と日本本社で判断者が分かれるなら、時差と通訳を含む意思決定時間をrunbookに入れます。

ロールバック計画は「旧サーバーを起動する」だけでは成立しない

新システムで新規取引が一件も発生していないなら、接続を旧へ戻すrollbackは比較的単純です。しかし新側で受注変更、払出、完成、出荷が発生した後、旧側は古い状態です。画面の向き先だけ戻すと、新側で作られた業務事実が消えます。

そのためロールバック計画は、時間帯ごとに方式を分けます。

• 入力開始前：設定・経路を戻し、旧側を再開する。
• 入力開始後・外部確定前：新側取引を抽出し、旧側へ正規手順で反映できるか、取消して再入力するかを定める。
• 出荷・会計・顧客連携後：単純rollbackではなく、業務を前進させながら障害を直すfail-forwardを含めて判断する。

バックアップが存在しても、復元時間、復元点、設備設定、インタフェース資格情報、端末配布物、ラベル版、未送信キューまで戻せなければ計画ではありません。NIST SP 1339 OT Backup Quick Start Guideは、OTバックアップを変更管理へ組み込み、定期作成、テスト、復旧演習での見直しを求めています。製造設備と接続する場合はNIST SP 800-82 Rev.3が扱うOT固有の性能・信頼性・安全要件も踏まえ、復元試験が生産や安全を損なわない環境と手順を用意します。

ロールバック演習では、データなしの経路戻しだけでなく、新側で発生した取引を旧側へ戻す、または正規の補償取引として再現するところまで試します。Go/No-Go判定者は「技術的に戻せる」だけでなく、出荷、在庫、原価、品質、顧客通知への影響を見て判断します。

業務受入証跡を納品物として残す

UATで担当者が「問題なし」と言っただけでは、後から条件を再現できません。受入証跡は、要件ID、シナリオ、前提データ、操作、期待結果、実績結果、画面・ログ・照合SQL、差分、修正、再試験、承認者、日時、版を関連付けます。タイ語の現場用語、日本語の本社用語、英語のシステム項目がある場合は、承認済み対訳表も版管理します。

証跡パックには次を含めます。

• データ契約と変更履歴
• 旧新ID対応表、未対応・重複・統合の承認
• 移行バッチの入力、出力、ログ、ハッシュ、変換版
• 状態遷移シナリオと結果
• 差分台帳と再試験結果
• 再送、重複、順序逆転、取消、隔離、再処理の試験
• 前方・後方トレース結果
• 性能、締め処理、権限、監査ログの結果
• cutoverとrollbackの演習記録
• 操作教育、参加者、理解確認、未習熟者への対応
• Go/No-Go議事録と署名または承認記録

このパックは監査用だけではありません。稼働後に「移行データの問題か、新運用の問題か、追加改修の問題か」を切り分ける基準になります。

90日PoCで不確実性を潰す実行例

以下はTOMAS TECHが検討の起点として提示する90日モデルであり、市場平均、納期保証、全社移行の標準期間ではありません。対象サイト、ライン、データ量、品質、インタフェース数、停止可能時間、規制、言語、意思決定速度に応じて拡大・縮小してください。目的は90日で本番完成させることではなく、見積と切替判断に必要な不確実性を証拠で減らすことです。

Day 1–30：契約とリスクを見える化する

• 対象製品群または一ラインを決め、範囲外を明記する。
• 受注、指図、払出、実績、在庫、検査、出荷の所有者を決める。
• 旧データをprofilingし、欠損、重複、孤児、未使用コード、時刻不整合を数える。
• ID、単位、時刻、版、状態、取消、再送のデータ契約を作る。
• 正常系より例外系を重視したゴールデンシナリオを承認する。
• cutover制約、停止不可工程、外部接続、法定帳票、顧客要求を整理する。

成果物は、契約初版、データ品質報告、状態遷移図、シナリオ一覧、リスク台帳、仮runbookです。

Day 31–60：移して、再生して、差分を説明する

• 代表マスタと未完取引を変換する。
• クロスリファレンス、変換版、原値保持を実装する。
• 同じイベントを旧新へ流し、状態遷移台帳を作る。
• 重複再送、遅延到着、順序逆転、拒否、取消、再計上を試す。
• 技術・業務・トレースの三層で差分を出し、原因を分類する。
• 日跨ぎ、シフト跨ぎ、月跨ぎを模擬する。

成果物は、変換プロトタイプ、照合ダッシュボードまたは報告、差分台帳、更新済み契約、未決一覧です。

Day 61–90：切替と復旧を演習し、投資判断へ渡す

• 役割付きcutover rehearsalを行い、実測時間を記録する。
• rollbackと、変更後データを扱うfail-forwardを演習する。
• 現場代表がゴールデンシナリオを実行し、受入証跡を作る。
• 未解決差分を重大度、回避策、責任者、期限で整理する。
• 本番wave、停止時間、要員、教育、運用監視、予備日を再見積する。
• Go、条件付きGo、再PoC、No-Goの判断資料を作る。

PoCの合格は「デモが動いた」ではありません。少なくとも、重要な状態遷移が再現でき、差分の原因を説明でき、再送と取消が統制され、cutoverと復旧の実測値が得られ、残余リスクを意思決定者が承認できることです。

RFP・ベンダー評価で確認する質問

生産管理システム データ移行やERP マイグレーションを外部へ依頼する場合、変換件数と作業人日だけで比較しないでください。次の質問を同じ条件で各社へ提示します。

1. 状態遷移の等価性をどのキー、基準時刻、証拠で判定しますか。
2. 旧新IDの衝突、統合、分割、廃止、有効期間をどう管理しますか。
3. 単位換算と丸め差を在庫、購買、原価でどう分けますか。
4. オフライン端末の遅延イベントと重複再送をどう処理しますか。
5. 取消後に後続取引がある場合、どの補償処理を行いますか。
6. 並行稼働中、オブジェクトごとの正本はどちらですか。
7. 差分は誰が、いつまでに、何を根拠に承認しますか。
8. 本番cutover前に何回、どの条件でリハーサルしますか。
9. 新側に取引が入った後のrollbackまたはfail-forwardをどう実証しますか。
10. 移行ツール、スクリプト、ログ、対応表、受入証跡をどの形式で引き渡しますか。

ERPと生産管理の恒常的な役割分担や連携方式を整理したい場合は、ERPと生産管理システムの連携設計を参照してください。新環境をクラウドにするかオンプレミスにするかという選定論点は、クラウド型とオンプレミス型の生産管理システム比較で分けて解説しています。本稿の焦点は、どちらを選んでも必要になる移行証明です。

まとめ：同じ数字ではなく、同じ業務状態を証明する

生産管理システム マイグレーションの合否を、変換件数や画面の見た目だけで決めてはいけません。データ契約で意味を固定し、ID・単位・時刻を追跡可能にし、同じイベントが同じ状態遷移を作ることを差分照合します。並行稼働は比較実験として出口条件を持たせ、再送を冪等にし、取消を履歴付きの補償処理として扱います。cutoverは時系列のrunbookで統制し、変更後データを含むrollback／fail-forwardを演習し、業務受入証跡を残します。

完全な無差分を唱えることより、重要な差分を漏らさず検出し、原因、影響、責任者、期限、暫定統制を説明できることが実務上の強さです。旧新で同じ受注・在庫・実績が同じ業務状態へ進むと証明できて初めて、移行は「データコピー」から「操業を引き継げる変更」になります。

移行範囲やデータ品質がまだ固まっていない段階でも、状態遷移、照合キー、cutover／rollbackの前提を一緒に棚卸しできます。タイ工場で生産管理システムの更新やERP マイグレーションを検討中であれば、TOMAS TECHへお問い合わせください。製品選定前の90日PoC設計や、既存計画の第三者レビューからでもご相談いただけます。

FAQ：生産管理システム マイグレーションの実務

生産管理システム データ移行では何を最初に決めますか？

対象テーブルではなく、業務オブジェクトの正本、識別子、状態遷移、単位、時刻、版、取消、再送、受入証拠を定義するデータ契約から始めます。その後に旧新フィールドをマッピングします。先にマッピングすると、意味の未決を変換コードへ埋め込みやすくなります。

ERP マイグレーションと生産管理システム移行は同時に行うべきですか？

一律の正解はありません。同時切替は暫定連携を減らせますが、原因切り分けとrollbackが複雑になります。分割切替は範囲を絞れますが、旧新間の一時インタフェースと正本管理が必要です。受注、品目、指図、在庫、実績、会計の依存関係と停止制約でwaveを決めます。

並行稼働は必須ですか？

必須ではありません。shadow run、二重入力、段階的な業務所有にはそれぞれ利点と負荷があります。停止可能時間が十分で、リハーサルとrollbackが強固なら直接切替も候補です。並行稼働を行う場合は、期間ではなく、通過シナリオ、未解決差分、承認者という出口条件を置きます。

システム切替計画のGo/No-Go条件は何ですか？

重要な状態遷移の一致、未処理キュー、在庫・受注残・仕掛の照合、外部接続、端末・帳票、重大欠陥、復元可能性、要員、意思決定期限を条件化します。平均の一致率だけでなく、品質保留や出荷取消など一件でも停止すべき項目を別に定めます。

ロールバック計画にバックアップがあれば十分ですか？

十分ではありません。復元時間、復元点、設定、端末、インタフェース、未送信キューを含めて演習し、新システムで発生した取引をどう旧側へ戻すか、またはfail-forwardするかを決める必要があります。復元を試していないバックアップは、利用可能性が証明されていません。

再送による二重計上はどう防ぎますか？

送信元、業務キー、イベントID、種別、版を用いた冪等キーと処理台帳を設けます。同じイベントの再送は同じ業務結果を返し、内容が異なる同一キーは隔離します。取消・再計上は元イベントとの関連を残し、別の正規イベントとして処理します。

90日PoCで本番稼働まで終わりますか？

本稿の90日モデルは本番完成を保証するものではありません。対象範囲でデータ契約、変換、状態照合、例外処理、cutover、rollbackを検証し、全体計画と見積の不確実性を減らすための計画例です。規模とリスクに応じて期間と範囲を調整します。