長年使い込んだMES（製造実行システム）が肥大化し、改修のたびに想定外の不具合が出る、特定のベンダーや担当者しか中身が分からない、新しい設備やクラウドサービスと連携できない――こうした行き詰まりに直面し、「もう小手先の改修では限界だ」と感じている生産技術・情報システム部門の方は少なくありません。MESのリアーキテクチャは、こうしたレガシー化したシステムの内部構造そのものを作り直し、変化に強い形へと組み替える取り組みです。単なるサーバー移行やバージョンアップとは目的も難易度もまったく異なります。
本記事では、MESのリアーキテクチャの進め方を、現状分析から設計手法、工場を止めない移行手順、費用相場とROIの考え方、そしてよくある失敗パターンまで、実務の流れに沿って体系的に解説します。MESは「止まれば工場が止まる＝売上が止まる」基幹システムであり、進め方を誤ると現場の混乱や多額の追加コストに直結します。これからプロジェクトを立ち上げる方が、工程の全体像と勘所をつかみ、稟議や現場説明にそのまま使えるレベルまで理解できることを目指します。
▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド
MESのリアーキテクチャとは — 延命や入れ替えと何が違うのか
リアーキテクチャという言葉は、システム近代化（モダナイゼーション）の手法の中でも特に「構造の作り直し」を指します。まずは似た言葉との違いを整理し、なぜ今この手法がMESで求められているのかを押さえておきましょう。ここを曖昧にしたままベンダーと話を進めると、想定していたゴールとかけ離れた提案を受け取ることになりかねません。
リアーキテクチャの定義とリホスト・リプレイスとの違い
リアーキテクチャとは、システムが提供する業務機能を維持したまま、その内部構造（アーキテクチャ）を抜本的に組み替えることを指します。具体的には、すべての機能が一体化したモノリシックな構造を、機能ごとに独立したモジュールやサービスへ分割し、外部連携やデータの流れを再設計する作業です。古い言語やフレームワークを最新のものへ置き換えるリファクタリングよりも踏み込み、システム全体の骨格を変えます。
これに対してリホストは、プログラムをほぼそのまま新しいサーバーやクラウドへ移すだけの手法で、いわゆる「リフト＆シフト」です。構造上の問題は残るため、延命にはなっても抜本解決にはなりません。リプレイスは既存システムを廃棄して別のパッケージや新規開発に丸ごと入れ替える手法で、刷新効果は大きい反面、移行リスクとコストが最も高くなります。リアーキテクチャは、業務資産を活かしながら構造の負債だけを返済する、中間的かつ持続性の高い選択肢といえます。
なぜ今MESにリアーキテクチャが必要なのか
多くの製造現場で稼働するMESは、15年から20年にわたり現場の要望を取り込み続けた結果、当初はシンプルだった構造が無数のカスタマイズで複雑に絡み合っています。1つの機能を直すと別の機能が止まる、改修見積もりが年々跳ね上がる、といった症状はモノリス化が限界に達したサインです。OSやデータベースのサポート終了（EOL／EOSL）が迫り、セキュリティ面でも放置できない状況に追い込まれるケースが目立ちます。
さらに、IoTやAIを活用したスマートファクトリー化、クラウドサービスとのデータ連携といった新しい要請に、固い一枚岩の構造では対応しきれません。トレーサビリティの強化や4M（人・機械・材料・方法）管理の高度化を求められても、現状のままでは機能追加すら困難です。延命を続けるほど将来の作り直しコストが膨らむため、構造を組み替えて変化対応力を取り戻すリアーキテクチャが、今まさに必要とされています。
MESリアーキテクチャの進め方 — 全体の流れと工程
リアーキテクチャは、現状分析から始まり、To-Be設計、アーキテクチャ設計、開発、段階リリースへと進みます。ここで重要なのは、いきなり開発に入らず、上流工程に十分な時間を割くことです。製造現場特有の前提工程を飛ばすと、後工程で必ず手戻りが発生します。各フェーズで何を決め、何を成果物として残すべきかを順に見ていきましょう。
現状分析（As-Is）とTo-Be設計・要件定義
最初の工程は、現行MESが抱える機能・データ・連携先を棚卸しする現状分析です。長年の運用で「誰も全体像を把握していない」状態に陥っていることが多いため、ソースコードや設計書だけでなく、現場のキーマンへのヒアリングを通じて、表に出ていない例外処理や暗黙のExcel運用まで洗い出します。この棚卸しの精度が、後のモジュール分割の正確さを大きく左右します。
続いて、あるべき姿（To-Be）を描き、要件定義に落とし込みます。ここで陥りがちなのが、現行機能を一字一句そのまま再現しようとする「現状踏襲」です。リアーキテクチャは構造を変える好機ですから、本当に必要な機能とそうでない機能を仕分けし、標準機能に寄せられる業務は寄せる（Fit to Standard）方針を明確にします。RFPには、性能要件や連携要件、移行方針までを具体的に記載し、複数ベンダーが同じ土俵で見積もれる状態を作ることが重要です。
BOP・マスタ整備という「前提工程」を飛ばさない
MES特有の落とし穴が、BOP（工程順序・作業手順・標準時間といった製造の設計情報）やマスタデータの整備不足です。新しいアーキテクチャをどれだけ精緻に設計しても、その上で動くマスタが整っていなければシステムは機能不全に陥ります。実際、BOPが未整備のままプロジェクトを進め、稼働直前に「動かす元データがない」と発覚して頓挫する事例は珍しくありません。
そのため、リアーキテクチャの計画段階で、マスタ整備を独立した前提工程として工数とスケジュールに組み込みます。品目・設備・工程・標準時間といったマスタを誰がいつまでに整備するのか、責任分担を明確にしておくことが、プロジェクト全体の遅延を防ぐ鍵となります。この工程を軽視すると、開発が完了しても本稼働に移れないという最悪の事態を招きます。
開発・テスト・段階リリースの進め方
アーキテクチャ設計が固まったら、分割したモジュール単位で開発とテストを進めます。リアーキテクチャでは全体を一度に作り替えるのではなく、影響範囲の小さい機能から段階的に切り出していく進め方が安全です。各モジュールを単体テスト、連携を確認する結合テスト、現場業務を模した運用テストの順で検証し、品質を積み上げていきます。
リリースは、まず単一ラインや単一機能でスモールスタートし、効果と安定性を確認してから対象を広げるのが定石です。最初から全工場・全機能を一斉に切り替えるビッグバン方式は、不具合発生時の影響が甚大で、現場が混乱した際の収拾もつきません。小さく始めて検証と改善を繰り返すことで、現場の習熟も進み、定着の成功率が高まります。
リアーキテクチャの設計手法 — 工場を止めない技術設計の勘所
リアーキテクチャの成否は、設計フェーズでの技術判断に大きく依存します。特にMESは、上位のERPや下位の設備と密接につながる「実行層」のシステムであり、その接続設計を誤ると性能破綻や現場停止を引き起こします。ここでは、競合記事ではあまり語られない、実務上の重要な設計の勘所を3つ取り上げます。
ERP（計画層）とMES（実行層）の粒度差と疎結合・非同期連携
ERPとMESの連携設計は、リアーキテクチャで最も注意すべき論点の1つです。ERPは月次や日次といった大きな粒度で計画を扱うのに対し、MESは分・秒単位で製造実績を処理します。この粒度の異なる2つを無理にリアルタイムで密結合させると、トランザクションが集中したときに処理が詰まり、画面が重くなる、応答が返らないといった性能破綻を起こします。
正しい設計は、両者を疎結合とし、メッセージキューやイベント連携を用いた非同期方式でデータをやり取りすることです。MES側でいったんデータを受け止めてから、必要なタイミングでERPへ集約して渡す構成にすれば、片方の負荷や障害がもう片方に直接波及しません。リアーキテクチャは、この連携の作り直しに踏み込める数少ない機会であり、ここを設計しきれるかどうかが将来の安定稼働を決めます。
レガシー設備からデータを取る「レトロフィットIoT」の現実解
製造現場には、20年以上稼働する古いPLCや、独自通信規格の海外製設備が残っているのが普通です。これらは標準的なデータ取得の口を持たないため、MESをリアーキテクチャしても、肝心の製造データを取り込めなければ意味がありません。だからといって設備自体を入れ替えれば、1台あたり数千万円規模の投資になりかねません。
現実的な解は、設備を改修せずに後付けでデータを取得するレトロフィットIoTです。信号線に後付けセンサーを挟む、PLCの接点信号をIoTゲートウェイで吸い上げる、表示パネルをカメラで読み取るといった手段で、既存設備を活かしたままデータ収集網を構築します。新しいMESアーキテクチャを設計する際は、こうしたゲートウェイ経由のデータをどう正規化して取り込むかを、収集層として明確に位置づけておくことが重要です。
モジュール分割とコンポーザブルMES（cMES）という選択軸
リアーキテクチャの中核は、一枚岩だった機能を、実績収集・品質管理・在庫・トレーサビリティといった単位で独立したモジュールへ分割することです。近年は、こうした機能部品を組み合わせて構築するコンポーザブルMES（cMES）という考え方が広がっています。必要なモジュールだけを選んで組み合わせ、現場の変化に応じてノーコードで設定を変えていけるため、固い一枚岩より格段に進化させやすくなります。
「パッケージかスクラッチか」という従来の二項対立も、この潮流の中で変わりつつあります。モジュール単位で標準部品とスクラッチ開発を組み合わせる折衷が現実的になり、近年はAIコード生成の活用でスクラッチ部分の工期やコストが3割から7割圧縮されたという報告も出ています。リアーキテクチャを機に、自社にとって最適なモジュール構成を見極めることが、長期的な投資対効果を高めます。
工場を止めない移行手順 — データ移行と切り戻し計画
MESは止まれば工場が止まる基幹システムです。そのため、移行手順の設計はリアーキテクチャ全体の中でも最大の山場となります。データをどう移すか、新旧をどう切り替えるか、そして万一動かなかったときどう戻すか。この3点を稼働前に詰め切っておくことが、現場を止めないための最大の防衛策です。
データ移行のマッピング・クレンジング・リハーサル
データ移行は、旧システムの項目を新システムの項目へどう対応づけるかを定義するマッピングから始まります。長年の運用で生まれた重複データや欠損データ、表記揺れをそのまま移すと、移行後に在庫不整合や実績の二重計上といったトラブルを招きます。そこで、不要・誤りのデータを整えるクレンジングを丁寧に行い、移行対象を確定させます。
そして欠かせないのが、本番同等の環境で移行を模擬実行するリハーサルです。1回で完璧に移せることはまずなく、想定外のエラーや件数不一致が必ず出ます。最低でも2回から3回はリハーサルを重ね、移行にかかる所要時間と手順、エラー時の対処を確定させておきます。このリハーサル回数を削ると、本番移行当日に予定時間内に終わらず、工場の稼働再開が遅れるリスクが一気に高まります。
一括移行と段階移行のトレードオフ
切替方式には、新旧を一度に入れ替える一括移行と、対象を区切って徐々に切り替える段階移行があります。一括移行は移行期間が短く、新旧並行運用の手間がない反面、失敗時の影響が全社に及ぶリスクを抱えます。段階移行は安全性が高く、リアーキテクチャと相性の良いストラングラーパターン（旧システムを少しずつ新システムに置き換える手法）とも親和します。
ただし段階移行には見落とされがちなコストがあります。新旧が並行稼働する間、両者のデータを同期させる中継プログラムを追加開発する必要が生じ、現場では二重入力の負担も発生します。この移行期間が長引くほどコストが増える点はトレードオフです。対象範囲の区切り方と並行期間の長さを慎重に設計し、安全性と移行コストのバランスを取ることが求められます。
切り戻し（ロールバック）計画と許容ダウンタイム
どれほど準備しても、本番切替で想定外の不具合が起きる可能性はゼロではありません。そこで必須となるのが切り戻し計画です。新システムが正常に動かない場合に、いつまでに、誰の判断で、どの手順で旧システムへ戻すのかを、稼働前に文書として合意しておきます。この発動権限者と判断基準が曖昧だと、現場が止まっている最中に「戻すべきか様子を見るべきか」で時間を浪費し、被害が拡大します。
あわせて、製造を止めてよい許容ダウンタイムを経営層を含めて事前に握っておくことが重要です。たとえば「移行作業は土曜の停止時間内、最大8時間まで。それを超えそうな場合は午前6時の判断で切り戻す」といった具体的な基準を決めておけば、当日の現場は迷わず動けます。切り戻しは「使わずに済むのが理想だが、必ず用意しておく保険」と位置づけ、リハーサルで実際に戻せることまで確認しておきましょう。
費用相場とROI — 稟議を通すために
リアーキテクチャを実行に移すには、経営層の承認が欠かせません。そのためには、費用の相場観を押さえたうえで、投資に見合う効果を説得力ある形で示す必要があります。MESは「入れれば直接儲かる」性質のシステムではないため、ROIの語り方には特有の工夫が要ります。
規模別の費用相場と内訳
MESのリアーキテクチャ費用は、対象ラインの数、連携設備の数、カスタマイズの度合いによって大きく変わります。一般的な目安として、単一ライン中心の小規模なら数百万円から1,500万円程度、複数ライン・複数機能の中規模で1,500万円から5,000万円程度、多拠点・大規模になると数千万円から数億円規模に達します。リアーキテクチャは構造を作り替えるため、設計工程に相応の工数が乗る点が費用の特徴です。
内訳としては、要件定義・設計・開発といった人件費（エンジニアの工数）が中心ですが、見落としやすいのが初期費用以外のランニングコストです。クラウド利用料、保守費、ライセンス費が毎年かかり続けます。特にSaaS型を選ぶ場合、接続設備数やデータ量、アカウント数の増加に応じて従量課金が膨らみ、数年単位ではオンプレミスの総保有コスト（TCO）を上回る逆転現象が起きることがあります。初期費用だけでなく、5年スパンのTCOで比較する視点が欠かせません。なお、条件を満たせばIT導入補助金などの活用も検討できます。
MES特有のROIモデル — 直接効果と間接的リスク回避効果
稟議でつまずく最大の理由は、工数削減や歩留まり向上といった直接効果だけでROIを語ろうとすることです。MESの直接効果は重要ですが、それだけでは投資額に対して数字が見劣りし、経営層を動かしきれないことが少なくありません。MESのROIは、直接効果に「間接的なリスク回避効果」を合算して語るのが定石です。
具体的には、トレーサビリティ強化によってリコールや製品回収が発生した際の被害を最小限に抑えられる効果、属人化を排してベテラン退職時にも製造を継続できる効果、サポート終了したシステムを使い続けるセキュリティリスクを解消する効果などです。たとえば「1度の大規模リコールで数億円の損失が想定されるところ、追跡範囲を限定できれば被害を大幅に圧縮できる」といった形で、回避できる損失を金額換算します。直接効果と間接効果を合わせて提示することで、リアーキテクチャの投資判断が現実味を帯び、稟議が通りやすくなります。
よくある失敗とアンチパターン
リアーキテクチャの進め方を理解したうえで、最後に典型的な失敗パターンを押さえておきましょう。これらは多くの製造業が繰り返し陥ってきた失敗であり、先回りして対策を講じることで回避できます。技術面と組織面の両方に落とし穴がある点に注意が必要です。
過度なカスタマイズによるコスト肥大化
最も多い失敗が、現場のあらゆる例外処理や暗黙のExcel特例をすべてシステムに作り込もうとして、カスタマイズが無限に膨らむパターンです。せっかく構造を組み替えても、過剰なカスタマイズを盛り込めば、再び改修しづらい一枚岩へと逆戻りしてしまいます。これではリアーキテクチャの意味が失われます。
対策は、標準機能に業務を寄せるFit to Standardの方針を貫くことです。本当に競争力の源泉となる固有業務だけをカスタマイズの対象とし、それ以外は標準機能に合わせて業務側を見直します。どこまでを標準に寄せ、どこからを作り込むのか、その線引きを要件定義の段階で明確に合意しておくことが、コスト肥大化を防ぐ最大のポイントです。
IT部門主導による現場の反発・定着失敗
もう1つの典型が、IT部門だけでプロジェクトを進め、現場の声を取り込まないまま新システムを導入してしまう失敗です。現場の作業実態に合わない画面や操作フローを押し付けると、入力負荷が増え、結局は手元のExcelや紙の運用に戻ってしまいます。どれほど立派なアーキテクチャでも、現場で使われなければ価値を生みません。
対策は、要件定義の早い段階から現場のキーマンを巻き込み、当事者として設計に参加してもらうことです。トレーサビリティや4M管理のためのデータ入力も、RFIDやハンディ端末を活用して入力負荷を上げない仕組みを作れば、現場の協力を得やすくなります。リアーキテクチャは技術プロジェクトであると同時に、現場を巻き込む組織プロジェクトでもあるという認識が、定着の成否を分けます。
まとめ
MESのリアーキテクチャは、業務機能を維持しながら肥大化したシステムの内部構造を組み替え、変化に強い形へと作り直す取り組みです。進め方の要点は、現状分析とTo-Be設計に十分な時間をかけ、BOPやマスタ整備という前提工程を飛ばさないこと、ERPとの疎結合・非同期連携やレトロフィットIoTといった技術設計の勘所を押さえること、そしてデータ移行・段階移行・切り戻し計画で「工場を止めない」備えを徹底することです。
費用は規模により数百万円から数億円と幅があり、稟議では直接効果に加えてトレーサビリティや製造継続性といった間接的リスク回避効果を金額換算して示すことが鍵となります。そして、過度なカスタマイズと現場の反発という2大アンチパターンを、Fit to Standardの徹底と現場キーマンの巻き込みで回避することが、定着を成功に導きます。本記事の工程を一つずつ着実に進め、現場を止めずに変化対応力のあるMESへと生まれ変わらせていきましょう。
Q. リアーキテクチャの期間はどのくらいかかりますか
規模によりますが、単一ライン中心の小規模で半年から1年程度、複数ライン・複数機能の中規模で1年から1年半程度が一般的な目安です。現状分析とBOP・マスタ整備に想定以上の時間がかかるケースが多いため、上流工程に余裕を持ったスケジュールを組むことをおすすめします。段階移行を選ぶ場合は、新旧並行稼働の期間も加味して計画してください。
Q. リプレイスではなくリアーキテクチャを選ぶべきなのはどんな場合ですか
現行MESの業務ロジックや蓄積データに固有の価値があり、それを活かしたい場合はリアーキテクチャが適しています。一方、業務そのものを見直して標準的なパッケージに合わせられるなら、リプレイスのほうが結果的に効率的なこともあります。判断に迷う場合は、現状分析の結果をもとに、構造の負債だけを返済すれば足りるのか、業務ごと作り直すべきなのかを切り分けて検討するとよいでしょう。
▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。