MES移行をフルスクラッチ・オーダーメイドで進めるとき、新システムを作ること自体は決まっている前提で、論点は既存データの移し方と移行ツールの選び方にあります。PLC・生産設備との接続や、カットオーバーの体制、内製と外部委託の分担も欠かせません。
トレーサビリティデータの移行設計や、PLC・老朽化設備連携の扱いを軽視すると、新システムの機能自体は優れていても、稼働直後に品質保証上の重大な事故や生産ラインの混乱を招きかねません。取り返しのつかない事態に至るおそれもあります。
- 対象：移行するデータと業務条件
- 工程：計画からカットオーバーまで
- 確認：データと本番作業
本テーマに関する全体ガイドは、次の記事をご覧ください。
▼全体ガイドの記事
・MES移行の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
MES移行とフルスクラッチ・オーダーメイド開発の関係（移行実務という論点）
MES移行とフルスクラッチの関係を整理すると、同じ「フルスクラッチ」でも、選ぶべきかを判断する場面と、選んだあとに既存資産をどう移すかを進める場面では、押さえる視点がまったく異なります。そこで、まず本記事が扱う論点の位置づけを明確にしておく必要があります。
7記事群との違い（手法選定ではなく移行実務そのもの）
MESのモダナイゼーションは、フルスクラッチに相当する「リビルド」を含む5つの技術的アプローチの使い分けを論じています。MES刷新は投資規模を経営層にどう説明するかを、MES更改は動かせない期限内での実現可能性を扱います。
MESのリニューアルは現場オペレーターの操作体験の独自性を、MESのリアーキテクチャは生産ドメインの構造の再設計を扱います。MESリプレイスはビルド・バイの判断、MES改修は部分対応で済むかの見極めが論点です。7記事群は、いずれもフルスクラッチを選ぶべきかという上流の判断軸を扱います。
これに対し本記事のMES移行は、フルスクラッチで新システムを作ること自体はすでに決まっている前提で扱います。論点は、既存の生産実績・品質・トレーサビリティデータを新システムへどう移すか、PLC・老朽化設備との接続をどう引き継ぐか、工場休止日のどのタイミングでカットオーバーするかという、実行段階の設計です。
フルスクラッチ移行で発生する固有のデータ移行課題
フルスクラッチでMESを再構築しても、実績収集ロジックやUIだけを新しくし、古いデータモデル（生産実績データベース・トレーサビリティ管理の構造）を流用すると、処理速度や拡張性のボトルネックは解消されません。
フルスクラッチは、ゼロから作り直せる分、データモデルを抜本的に見直せます。一方で、旧システムのロット番号・製造履歴・検査結果の紐付け構造とまったく異なる新データモデルへ、既存資産を移し替える必要があります。
そのため、パッケージへの載せ替え（リプレイス相当）に比べて、データ移行の難易度がひときわ高くなります。この点が、フルスクラッチ移行に特有の課題です。
生産実績・品質・トレーサビリティデータの移行設計
フルスクラッチ移行の中核は、性質の異なる2種類のデータの移行設計です。2種類とは、静的な品目マスタと、動的な生産実績・品質・トレーサビリティデータです。それぞれに特有の課題があるため、設計方針も個別に決める必要があります。
静的マスタデータの移行設計（品目マスタ・BOM構造の変換）
長年運用してきた自社スクラッチのMESほど、品目コードの採番ルールや、BOM展開・工程マスタの持ち方が独自の複雑な構造になっていることが多いです。そのため、新しいデータモデルへの変換・マッピング作業には、相応の時間がかかります。
品目コードの重複・欠損・表記揺れを洗い出すクレンジングと並行して、新旧のBOM構造・工程構造がどう対応するかを1件ずつ定めます。その対応を、データマッピング表として作成することが欠かせません。
発注側は、旧システムの採番ルールをそのまま踏襲するのか、この機会に体系そのものを見直すのかを、オーダーメイド開発を依頼する段階でベンダーと明確に合意しておきます。これが、後工程での大規模な手戻りを防ぐポイントです。
ロット番号・製造履歴・検査結果という動的データの移行方針（分離設計・凍結タイミング）
過去数年分の完了済みの生産実績や検査データをすべて新システムに移そうとすると、データ量が膨大になり、移行期間中のダウンタイムが長引く原因になります。そこで、法定保存期間や社内規程で定められたトレーサビリティ要件を確かめたうえで、直近の稼働データだけを新システムに移し、過去データは参照専用の別データベースに分ける設計が現実的な選択肢です。
ロット番号・製造履歴・検査結果は、大部分を事前にロードしておきます。そのうえで、切替直前のごく短い時間だけ現場のデータ更新を凍結する「フリーズウィンドウ」を設け、その間の差分だけを反映させる方式が有効です。
移行後の確認では、件数だけでなく、部品・製品間の紐付け（親子関係）が新旧で一致するかも見ておく必要があります。この照合を自動で行う仕組みは、オーダーメイド開発のスコープにあらかじめ含めておきます。これは、稼働直後の品質保証リスクを防ぐための要になります。
移行ツール・データ変換ロジックの選択（オーダーメイドか汎用ツールか）
フルスクラッチを選ぶと、移行そのものを担うツールやスクリプトをどう調達するかという判断も生じます。
汎用のETL（データ抽出・変換・ロード）ツールを使うか、自社データの特殊性に合わせて移行ツールをオーダーメイドで開発するかは、費用と精度のトレードオフです。
自社専用にクレンジングと変換をフルスクラッチ開発する場合、「使い捨てプログラム開発費」が追加で発生することが一般的です。その額は、小・中規模で数百万円、大規模で複雑なレガシーデータになるほど1,000万円〜数千万円規模になります。どちらの方式を採るかは、発注前にベンダーと明確に合意しておく必要があります。
汎用ETLツールとオーダーメイド移行スクリプトの使い分け・費用感
移行専用ツールを使うか、オーダーメイドの移行スクリプトを開発するかは、主に3つの観点で決まります。
- 旧システムのデータ構造：長年の改修で独自の文字コードやデータ型が混在している場合、市販のETLツールでは対応しきれず、独自の変換スクリプトの方が確実です。
- 変換の複雑さ：複数のシステムにまたがり条件分岐を伴う変換が必要な場合は、GUIベースのETLツールより、フルスクラッチのスクリプト開発の方が柔軟に対応できます。
- コストが一過性かどうか：データ移行は本番移行時とリハーサル時だけに発生します。
そのため、高額な汎用ETLツールのライセンスを導入・維持するより、使い捨ての移行スクリプトを自社や委託先で開発した方が、トータルコストを抑えられる場合があります。
生産実績・品質・トレーサビリティデータを対象に、自社専用のクレンジングと変換をフルスクラッチ開発する場合は、「使い捨てプログラム開発費」が追加で発生することが一般的です。その額は、小・中規模で数百万円、大規模で複雑なレガシーデータになるほど1,000万円〜数千万円規模になります。
費用の差が大きいため、発注前にこの3つの観点を整理し、どちらの方式を採るかをベンダーと明確に合意しておく必要があります。
PLC・老朽化設備連携用の変換ミドルウェアを個別開発する判断
独自の通信規格を持つ老朽化したPLCは、フルスクラッチで構築した新しいMESと直接デジタル連携できないケースが頻出します。この場合は、工場側にエッジゲートウェイ（IoTゲートウェイ）を置き、古いプロトコルをOPC UAやMQTTといった標準的な通信方式に変換する中間層を個別開発する判断が必要になります。
外部連携の一部にあたるAPI化・連携基盤の整備費用は、中堅企業規模で500万円〜2,000万円（開発期間3〜8ヶ月）が目安とされ、現場のIoT機器・エッジデバイスのハードウェア調達・設定費用は別途加算されます。API連携基盤（iPaaS）で上位の生産管理システムと現場設備を疎結合化しておくと、MES側の刷新が現場機器に影響しにくく、将来の再移行や設備更新の負担も抑えられます。
全ラインを一度に切り替えると、連携エラーが工場全体に波及するリスクがあります。そのため、特定のライン・工程からパイロット的に導入し、新システムとPLC・生産設備とのデータのやり取りが正しく行われるかを検証してから、全体に展開するのが実務上安全です。
工場休止日を活用した移行タイミングとカットオーバー当日の体制
データ移行と移行ツールの準備が整っても、いつ、どんな体制でカットオーバーするかという実行計画を誤ると、フルスクラッチ移行は台無しになりかねません。
生産カレンダーからの逆算設計
決算期や生産の最繁忙期にシステム停止（ダウンタイム）を起こすと、致命的な機会損失に直結します。そのため、フルスクラッチのオーダーメイド開発を発注する段階から、年間の生産計画・受注カレンダーを逆算しておきます。移行時期は、GW・お盆・年末年始・計画停止日といった工場休止日に厳密に合わせ、開発ベンダーともスケジュールを共有します。
開発の完了が遅れた場合でも、カットオーバーを繁忙期にずらし込むのではなく、次の工場休止日まで待てるよう、開発スケジュールに余裕を持たせておくことをお勧めします。
ロールバック体制とオーダーメイド開発ベンダーへの発注ポイント
予期せぬトラブルの際に、即座に旧MESへ戻して生産を継続できる切り戻し（ロールバック）の手順と判断基準を事前に準備しておくことは、フルスクラッチ移行における必須要件です。判断基準は、移行計画の段階でIT部門だけでなく工場長など現場責任者とも合意しておく必要があります。
たとえば時間の面では、本番当日午前4時などの始業前デッドラインまでに抽出・変換・ロードが完了しないときです。データの面では、トレーサビリティデータに1件でも欠損が見つかったときや、在庫数・部品ロット数の丸め誤差が許容値を超えたときです。連携の面では、PLC・WMSとの連携がタイムアウトしたときです。
オーダーメイド開発を発注する際は、機能要件に加えて、ロールバック手順の構築・検証まで開発スコープに含めるかを、ベンダーと明確に合意しておきます。ロールバック対応が開発スコープに含まれていないと、いざというときに頼れる体制がなく、致命的なトラブルへの対応が後手に回るおそれがあります。見積もり比較の段階で、この点を必ず確認しておくことをお勧めします。
内製と外部委託の使い分け、発注前の準備
新システムのフルスクラッチ開発を外部に委託するとしても、移行実務のどこまでを内製で担うかは、プロジェクトの進行スピードと品質に直結する判断です。
移行実務の内製と外注の分担
業務知識が欠かせない工程は内製で担うのが、実務上の定石です。品目コードの採番ルールや自社独自のBOM構造の整理方針、トレーサビリティ項目の定義は、自社の生産方式を知る社内で決めます。一方、ETLツール・移行スクリプトの構築、PLC連携用の変換ミドルウェアの技術実装、移行リハーサルの実施は、技術的な専門性が高いため外部委託するのが一般的です。
自社の生産方式や品質管理の実態を最も理解しているのは、生産技術部門と品質保証部門です。この業務知識をベンダーに丸投げすると、要件定義の段階で重要な仕様を見落とすリスクが高まります。
逆に、データ変換ロジックやレガシーPLC接続の実装まで内製で担おうとすると、専門知識が不足して移行後にトラブルを招きかねません。そのため、自社の強みと外部の専門性を組み合わせる必要があります。
発注前に用意すべき移行要件概要書
発注前に移行要件概要書を用意すると、複数のベンダーから比較しやすい見積もりとスケジュール提案を得やすくなります。概要書には、移行対象の生産実績・品質・トレーサビリティデータの量と現状の品質を書きます。連携が必要な外部システム（PLC・老朽化設備・上位の生産管理システム・WMSなど）の一覧と、生産カレンダーから逆算した希望カットオーバー時期も載せます。
依頼先を選ぶ際は、フルスクラッチの新規開発実績だけでなく、「既存MESからのデータ移行・カットオーバー実務」を手がけた実績があるかを重点的に確認すべきです。新規構築の実績が豊富でも、既存システムの構造や連携実態を読み解いて安全に移した経験がなければ、「生産ラインを止めずに移す」場面で想定外のトラブルを招くリスクが高まります。
実質の総費用は、ベンダーへの開発支払額に、並行稼働期間中の重複インフラ費や社内工数を加えて考えます。その場合、ベンダー支払額の1.3〜1.5倍程度を見込んでおくのが安全です。
まとめ
ここまで、移行データの設計と移行ツールの選択を中心に、PLC・老朽化設備との接続、カットオーバーの体制、内製と外部委託の分担、発注前の準備まで解説しました。
7つの姉妹記事群が、フルスクラッチを選ぶべきかという上流の判断を扱うのに対し、本記事が扱うMES移行は、構築が決まったあとの実行管理とリスク管理です。既存資産の移行、PLC・老朽化設備との接続の引き継ぎ、工場休止日を使ったカットオーバーの体制が、その中心になります。
移行要件概要書を用意したうえで、既存MESからの移行実績を持つ信頼できるパートナーに、早めに相談することをお勧めします。
▼全体ガイドの記事
・MES移行の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。