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