MES更改(製造実行システムの更改)は、「いつかは着手しなければならない」と分かっていながら、なかなか踏み切れないテーマではないでしょうか。ハードウェアやOSのサポート終了(EOL/EOSL)が迫る、現場がExcelと紙の運用で属人化している、古い設備からデータが取れない——こうした課題を抱えていても、「止まれば工場が止まる」MESだからこそ、更改の進め方を誤れば生産そのものが停止しかねません。だからこそ、製品の機能比較に飛びつく前に、「どう進めるか」という工程設計を先に押さえておくことが何より重要になります。
この記事では、MES更改を失敗させないための進め方を、要件定義からベンダー選定、更改方式の選び方、レガシー設備とのデータ連携、工場を止めない移行手順、費用相場と稟議を通すためのROIモデルまで、工程順に体系立てて解説します。生産技術・生産管理の現場担当者から、情報システム部門、投資判断を行う経営層まで、それぞれが押さえるべき勘所を網羅しました。読み終えたとき、自社の更改プロジェクトの全体像と、つまずきやすいポイントの回避策が明確になっているはずです。
▼全体ガイドの記事
・MES更改の完全ガイド
MES更改とは — 全体像と更改が必要になる背景

MES更改とは、老朽化・複雑化した製造実行システムを、現代の製造現場とビジネス要件に合うかたちへ作り直す取り組み全般を指します。単なるバージョンアップではなく、作業手順管理、製造データの収集・分析、品質・トレーサビリティ管理、実績・進捗管理、設備管理といったMES本来の機能を、「止まらない・つながる・進化できる」基盤として再構築することが目的です。まずは言葉の定義と、更改が求められる背景を整理しておきましょう。
MES更改の定義と「刷新・リプレイス・リアーキテクチャ・改修・移行」の違い
ひとくちにMES更改といっても、その中身は複数の手法に分かれ、それぞれ投資規模とリスクが異なります。「リプレイス」は既存システムを別の製品へまるごと置き換えること、「リアーキテクチャ」はクラウドネイティブなど新しい技術構造へ作り変えること、「改修」は既存資産を活かしながら部分的に機能を追加・修正することを指します。「移行(マイグレーション)」はデータや機能を新環境へ載せ替える工程を、「刷新」はこれらを含む全体的な作り直しを意味することが多く、「更改」はその総称として使われます。
重要なのは、どの手法を選ぶかでコストが一桁変わる点です。全面スクラッチでの刷新は自由度が高い反面、数千万円から数億円規模に膨らむこともあります。一方で改修やリアーキテクチャで既存資産を活かせば、投資を大きく抑えられる場合もあります。自社の現状システムの寿命・拡張性・保守状況を見極め、目的に合った手法を選ぶことがMES更改の出発点です。「とにかく新しく作り直す」と決め打ちせず、残せる資産と捨てるべき資産を仕分けることから始めましょう。
更改が必要になる背景(老朽化・サポート終了・属人化)
MES更改が必要になる典型的な背景は、ハードウェア・OS・データベースの老朽化とサポート終了、ベンダーによる保守打ち切り、そしてExcelや紙による属人化です。担当者の頭の中にしかないノウハウや、特定の人しか触れないマクロが業務を支えている状態は、退職や異動の瞬間に一気に崩れる時限爆弾といえます。Windows ServerやOracle Databaseの旧バージョンがサポート切れを迎えると、セキュリティパッチが提供されなくなり、システムの脆弱性がそのまま放置されることになります。
加えて近年は、スマートファクトリーやIoT活用を進めたくても、10年以上前に構築された古いMESがデータ連携の足かせになるケースが急増しています。経済産業省の「2025年の崖」でも警鐘が鳴らされたとおり、レガシーシステムの維持コストはIT予算の8割を超えることもあり、攻めの投資に予算を回せない悪循環に陥りがちです。更改は「いつか」ではなく、サポート終了スケジュールから逆算して計画的に着手すべきテーマなのです。
更改を放置するリスク(トレーサビリティ欠如と生産継続性の毀損)
MES更改を先送りするリスクは、想像以上に深刻です。最大の脅威はトレーサビリティの欠如で、品質問題が発生したときにロットを追跡できず、リコールや回収の範囲を絞り込めずに損害が雪だるま式に膨らみます。4M(人・機械・材料・方法)の記録が断片的だと、原因究明にも膨大な時間がかかり、出荷停止が長期化します。製造業のリコール1件あたりの平均対応コストは数千万円規模に達することもあり、トレーサビリティの欠如はそのまま経営リスクに直結します。
さらに、サポートの切れたシステムが障害で停止すれば、修理できるエンジニアがすでに社内外に存在せず、生産が数日から数週間にわたって止まる事態にもなりかねません。1日の生産停止が数千万円の機会損失につながる工場では、この継続性リスクこそが更改の最大の動機になります。こうしたリスクを定量的に捉えておくことが、後述する稟議突破のロジックにもつながっていきます。
MES更改の進め方 — プロジェクト全体の流れ

MES更改は、現状分析から本稼働まで、大きく「企画・要件定義」「ベンダー選定」「設計・開発」「移行・テスト」「定着支援」という流れで進みます。一般的にはプロジェクト全体で1年から2年程度を要し、規模が大きいほど長期化します。ここでは、特に失敗が起きやすい上流工程と、製造現場ならではの前提工程に絞って、進め方の勘所を解説します。順序を飛ばすと後工程で必ず手戻りが発生するため、急がば回れの姿勢が結果的に最短ルートになります。
As-Is/To-Be分析・要件定義・RFP作成・ベンダー選定
最初に行うのは、現状の業務とシステムを可視化するAs-Is分析と、あるべき姿を描くTo-Be設計です。現場の作業手順、データの流れ、そして例外処理(暗黙のルールやExcelでの特例対応)まで丁寧に洗い出すことで、更改の対象範囲が明確になります。ここで現場ヒアリングを省略すると、稼働後に「現場で使えない」システムが出来上がり、結局は旧来の運用に逆戻りしてしまいます。
要件が固まったら、RFP(提案依頼書)を作成してベンダーへ提示します。RFPには目的、機能要件、非機能要件(性能・可用性・セキュリティ)、移行方針、予算と納期を具体的に記載することが、精度の高い見積もりと適切なベンダー選定の鍵です。曖昧なRFPは見積もりのブレを生み、後の追加費用の温床になります。最低でも3社程度から提案を取り、技術力・製造業での実績・サポート体制を多面的に比較しましょう。
スモールスタート(単一ライン・単一機能)で効果を検証する
MES更改で全工場・全機能を一斉に切り替えようとすると、リスクとコストが跳ね上がります。おすすめは、1つのラインや1つの機能(たとえば実績収集だけ)に絞ってスモールスタートし、効果と課題を検証してから横展開する進め方です。最初のラインで得られた「現場の使い勝手」「データ取得の精度」「想定外の例外処理」といった知見は、次のラインへの展開で大きな財産になります。
スモールスタートのもう一つの利点は、経営層への効果説明がしやすくなる点です。「このラインで段取り時間が15%短縮できた」「入力ミスが月20件からゼロになった」といった具体的な数字を示せれば、横展開の追加投資について稟議が通りやすくなります。いきなり大規模投資の承認を取りに行くより、小さな成功を積み上げて信頼を獲得する方が、結果的にプロジェクト全体を前に進めやすいのです。
BOP・マスタ整備という「前提工程」を飛ばさない
MES更改で最も見落とされやすく、かつプロジェクトを頓挫させやすいのが、BOP(工程順序・作業手順・標準時間)とマスタの整備です。BOPが紙やExcelに散在していたり、そもそも標準時間が定義されていなかったりする状態でMESを導入しても、システムは正しく動きません。MESは「正確なマスタがある」ことを前提に動くため、マスタ整備は更改の本工程に入る前の必須の前提工程と位置づけるべきです。
品目マスタ、工程マスタ、設備マスタ、BOMとBOPの整合性——これらを地道に棚卸しし、現場の実態と一致させる作業は地味で時間がかかりますが、ここを飛ばすと稼働後に「システムが指示する手順と現場の実作業が食い違う」という事態が頻発します。更改の見積もりやスケジュールには、このマスタ整備の工数を必ず織り込んでおきましょう。前提工程を軽視したプロジェクトほど、終盤で深刻な手戻りに見舞われます。
MES更改の方式選択 — パッケージ・スクラッチ・クラウド・cMES

MES更改の方式は、大きく「パッケージ型かスクラッチ開発か」「オンプレミス型かクラウド(SaaS)型か」という2つの軸で整理できます。それぞれにメリットとデメリットがあり、自社の製造形態・予算・IT体制によって最適解は変わります。ここでは古典的な選択肢の比較に加えて、近年注目される新しい選択軸と、見落とされがちなコストの落とし穴まで解説します。
パッケージ/スクラッチ・オンプレ/クラウドの4象限比較
パッケージ型は、業界標準の機能がそろっており、導入が比較的早く、保守も提供元に任せられる点が強みです。一方で、自社特有の業務にフィットしない部分はカスタマイズが必要になり、過度な作り込みはコスト肥大の原因になります。スクラッチ開発は自社業務に完全に合わせられる反面、開発期間が長く、数千万円から数億円規模の投資と、開発ベンダーへの依存リスクを伴います。
インフラ面では、オンプレミス型は工場内にサーバを置くため、ネットワーク遮断時でも稼働を継続でき、製造現場のリアルタイム性に強いというメリットがあります。クラウド型は初期投資を抑えられ、拡張やバージョンアップが容易ですが、工場とクラウド間の通信が途切れると生産に影響が出るため、現場のバッファ設計が欠かせません。この4象限を、自社の止められない度合いと予算で評価することが方式選択の基本です。
コンポーザブルMES(cMES)とAI駆動開発という新潮流
近年は「パッケージかスクラッチか」という古い二項対立を超える選択肢が登場しています。それがコンポーザブルMES(cMES)です。必要な機能をモジュール単位で組み合わせ、ノーコード・ローコードで現場主導の改善を継続できる仕組みで、ガートナーをはじめとする調査会社も製造業向けの有力なトレンドとして挙げています。一度作り切って終わりではなく、現場の変化に合わせて少しずつ進化させられる点が、変化の激しい製造現場にフィットします。
さらに、AIによるコード生成を活用した開発も急速に広がっています。設計書や画面イメージから自動でコードを生成する手法により、スクラッチ開発の工期やコストが30%から70%程度圧縮された事例も報告されています。「自社業務にフィットさせたいがスクラッチは高すぎる」という従来のジレンマを、cMESとAI駆動開発が緩和しつつあるのが現在のトレンドです。方式選択の際は、こうした新しい選択軸も検討の俎上に載せましょう。
SaaS型MESの「TCO逆転トラップ」に注意する
クラウド(SaaS)型MESは初期投資が小さく魅力的に映りますが、見落とされがちな落とし穴があります。それが「TCO逆転トラップ」です。SaaS型は接続する設備数、蓄積するデータ量、利用アカウント数に応じて従量課金が膨らむ料金体系が多く、稼働開始から数年が経過すると、累積コストがオンプレミス型を上回る逆転現象が起きることがあります。
たとえば導入当初は月額数十万円だった費用が、設備のIoT接続を増やし、全社にアカウントを展開した結果、月額数百万円に膨らむケースは珍しくありません。方式を選ぶ際は、目先の初期費用だけでなく、5年から7年程度のTCO(総保有コスト)で比較することが鉄則です。将来の接続設備数やデータ量の増加を見込んだうえで、シミュレーションしておきましょう。
MES更改特有の関門 — レガシー設備と他システムとのデータ連携

MES更改が一般的な業務システムの刷新と決定的に違うのは、製造設備という「モノ」とつながる点です。ここでつまずくプロジェクトが非常に多く、いわばMES更改特有の関門といえます。古い設備からどうデータを取るか、上位のERPとどうつなぐか——この設計を誤ると、システムは作ったものの「データが流れてこない」「画面が重くて使えない」という事態に陥ります。
古いPLC・海外製設備からデータを取る「レトロフィットIoT」の現実解
製造現場には、稼働20年を超える設備や、独自通信規格の海外製設備が当たり前のように残っています。これらの古いPLCや設備は、最新のMESとそのままでは通信できないことが多く、かといって設備をまるごと入れ替えれば数千万円から数億円の投資が必要になります。そこで現実解となるのが「レトロフィットIoT」、つまり既存設備に後付けでセンサーやゲートウェイを設置してデータを取得する手法です。
たとえば、設備の信号灯(パトライト)に光センサーを取り付けて稼働・停止を検知する、電流値を測定して稼働状況を推定する、といった低コストな手段で、設備本体に手を加えずにデータを取得できます。通信規格が異なる設備には、プロトコル変換機能を持つIoTゲートウェイを介在させます。「全設備を入れ替えないとMES更改はできない」と諦める前に、後付けでどこまでデータが取れるかを検討することが、投資を現実的な範囲に収める鍵です。
ERP(計画層)とMES(実行層)の粒度差 — 密結合の罠と疎結合設計
MES更改で技術的に最も注意すべきなのが、上位のERPとの連携設計です。ERPは月次・日次という比較的長い時間軸で計画を扱う「計画層」であるのに対し、MESは分・秒単位で現場の実績を扱う「実行層」です。この粒度の違いを無視して、両者をリアルタイムに密結合させようとすると、ERP側が秒単位のトランザクションをさばききれず、性能が破綻して画面が重くなり、最悪の場合はシステム全体が停止します。
これを避けるには、ERPとMESを疎結合・非同期で連携させる設計が定石です。具体的には、両者の間に連携用のデータベースやメッセージキューを挟み、MESで発生した細かい実績データを一定間隔でまとめてERPへ渡す、といった作りにします。「リアルタイムで全部つなげたい」という要望をそのまま実装すると後で必ず後悔するため、何を即時連携し、何をバッチでまとめるかを設計段階で切り分けることが、止まらないシステムの条件です。PLM(製品ライフサイクル管理)との連携でも、設計変更が現場へ確実に伝わる仕組みを併せて設計しておきましょう。
工場を止めないMES更改 — データ移行・切替方式・切り戻し

MES更改で何よりも優先すべきは、「工場を止めない」ことです。MESは止まれば生産が止まり、そのまま売上が止まります。だからこそ、新システムへの切り替えは技術的な作業であると同時に、リスク管理のプロジェクトでもあります。データ移行、切替方式の選択、そして万一に備えた切り戻し計画の3点を、稼働前に経営層を含めて合意しておくことが最大の防衛策です。
データ移行のマッピング・クレンジング・リハーサル
旧システムから新システムへのデータ移行は、MES更改で最も神経を使う工程の一つです。旧データの項目を新システムのどの項目に対応させるかを定義する「マッピング」、不整合や重複を取り除く「クレンジング」、そして本番同様の環境で複数回行う「リハーサル」が不可欠です。これらを怠ると、在庫数が合わない、仕掛品が消える、といった不整合が稼働直後に発生し、業務が止まってしまいます。
特に移行リハーサルは、最低でも2回から3回は実施することをおすすめします。1回目で想定外のエラーを洗い出し、2回目で修正を確認し、本番直前のリハーサルで所要時間を計測する、という流れです。移行作業にかかる実時間を正確に把握しておかないと、限られた停止時間内に切り替えが終わらず、生産再開が遅れる事態になりかねません。データ移行は「やってみないと分からない」工程だからこそ、リハーサルへの投資を惜しまないことが肝心です。
一括移行と段階移行のトレードオフ
切替方式には、一括移行(ビッグバン方式)と段階移行(並行稼働方式)があります。一括移行は、ある日を境に旧システムを止めて新システムへ全面的に切り替える方式で、移行期間が短く費用も抑えやすい反面、失敗したときの影響が全工場に及ぶハイリスクな選択です。連休などの長期停止が取れる工場でなければ、現実的に選びにくい場面もあります。
一方の段階移行は、ラインや機能ごとに順次切り替えるためリスクを分散できますが、新旧システムが並行稼働する期間に「データ同期中継プログラム」の追加開発や、現場での二重入力の手間が発生し、移行期間とコストが著しく増大するトレードオフがあります。どちらが正解ということはなく、自社が許容できるダウンタイムと予算、現場の負荷を天秤にかけて選ぶことになります。多くの製造業では、リスクを抑える段階移行を選びつつ、並行稼働期間を可能な限り短く設計するのが現実的な落としどころです。
切り戻し(ロールバック)計画 — 許容ダウンタイムと発動権限
どれだけ準備をしても、稼働初日に予期せぬトラブルが起きる可能性はゼロにできません。そこで欠かせないのが、旧システムへ戻すための切り戻し(ロールバック)計画です。これを稼働前に用意していないプロジェクトが驚くほど多く、いざ問題が起きたときに「戻すべきか、このまま進めるべきか」の判断ができず、現場が長時間混乱する事態に陥ります。
切り戻し計画で明確にすべきは、(1)許容できるダウンタイムの上限、(2)切り戻しを発動する判断基準(どの症状が出たら戻すか)、(3)発動を決定する権限者の3点です。「稼働後2時間以内に基幹機能が復旧しなければ、製造部長の判断で旧システムへ戻す」といったように、誰が・いつ・何を見て決めるかを具体的に決めておきます。この合意を経営層まで含めて事前に取っておくことが、いざというときの被害を最小化する最後の砦になります。
MES更改の費用相場とROI — 稟議を通すために

MES更改の進め方を考えるうえで、避けて通れないのが費用と投資対効果(ROI)の問題です。経営層を説得し、稟議を通すためには、相場感を押さえたうえで、MES特有の効果を正しく定量化する必要があります。ここでは規模別の費用相場と、MESならではのROIの考え方を解説します。
規模別の費用相場と補助金の活用
MES更改の費用相場は、対象範囲と規模によって大きく変わります。単一ラインや特定機能に絞った小規模な更改であれば数百万円から1,500万円程度、複数ラインや工場全体を対象とする中規模では1,500万円から5,000万円程度、複数拠点を含む大規模な刷新になると数千万円から数億円規模になるのが一般的な目安です。これに加えて、保守費用やクラウド利用料といったランニングコストが毎年かかります。
初期費用の負担を軽減する手段として、IT導入補助金やものづくり補助金といった公的支援の活用も検討の価値があります。中小製造業であれば、要件を満たせば導入費用の一部が補助されるため、更改のハードルを下げられます。費用の詳細な内訳や見積もりの取り方については、別記事で詳しく解説していますので、そちらも参考にしてください。
MES特有のROIモデル — 直接効果と間接的リスク回避効果
MES更改の稟議が通りにくい最大の理由は、「入れたら直接いくら儲かるのか」が見えにくい点にあります。MESは生産設備のように直接売上を生むわけではなく、工数削減やペーパーレス化といった直接効果だけでは、数千万円の投資を正当化しきれないことが多いのです。歩留まり改善や段取り時間短縮による効果を試算しても、それだけでは経営層の心に響かないケースが少なくありません。
そこで有効なのが、「間接的なリスク回避効果」を定量化して直接効果と合算する説得ロジックです。トレーサビリティを確保することでリコールや回収の被害を限定できる効果、属人化を解消することで担当者の退職リスクを回避し製造を継続できる効果、サポート切れによる長期停止を防ぐ効果——これらを「もし更改しなければ発生しうる損失額」として金額換算するのです。直接効果に間接的リスク回避効果を加えることで、投資判断の説得力が格段に高まります。MES更改は、攻めの効果だけでなく、守りの価値で語ることが稟議突破の鍵になります。
MES更改でよくある失敗とアンチパターン

MES更改の失敗には、業界を問わず繰り返される典型的なパターンがあります。これらを事前に知っておくことは、自社のプロジェクトで同じ轍を踏まないための最良の予防策です。ここでは特に頻発する2つのアンチパターンと、その回避策を解説します。
過度なカスタマイズによるコスト肥大 → Fit to Standard
最も多い失敗が、現場の「今までどおりにしたい」という要望をすべて受け入れ、過度なカスタマイズを積み重ねてコストが肥大化するパターンです。現場ごとの暗黙ルールやExcelでの特例対応を一つひとつシステムに作り込んでいくと、開発費は当初見積もりの2倍、3倍に膨らみ、さらに保守の難易度も上がってバージョンアップすらできない「塩漬けシステム」が再び生まれてしまいます。
これを防ぐ考え方が「Fit to Standard」です。システムを業務に合わせるのではなく、標準機能に業務を合わせていくことを基本とし、本当に競争力の源泉となる部分だけを例外的にカスタマイズします。「この例外処理は本当に必要か、標準機能で代替できないか」を一件ずつ問い直すことが、コスト肥大を防ぐ唯一の方法です。現場の例外処理をどこまで標準に寄せるかの線引きは、現場キーマンを巻き込んで合意形成しながら進めましょう。
IT部門主導の現場反発・定着失敗 → 現場キーマンの巻き込み
もう一つの典型的な失敗が、情報システム部門だけで計画を進め、現場の声を十分に聞かないまま導入を強行するケースです。どれほど高機能なシステムでも、実際に使う現場の作業者が「使いにくい」「入力の手間が増えた」と感じれば定着しません。結果として旧来のExcelや紙が裏で生き残り、システムと手作業の二重管理に陥り、更改の効果が出ないまま費用だけがかさみます。
回避のカギは、現場のキーマンをプロジェクトの早い段階から巻き込むことです。要件定義やUI設計に現場の意見を反映し、入力の負荷を上げない仕組み(RFIDやハンディ端末、バーコードの活用など)を取り入れることで、現場の納得感と定着率が大きく変わります。トレーサビリティを「使えるデータ」にするには、ロットやシリアルの取得単位、4M(人・機械・材料・方法)の記録タイミングを現場とともに設計することが欠かせません。MES更改は技術プロジェクトであると同時に、変革を現場に根付かせる組織的な取り組みでもあるのです。
まとめ — MES更改の進め方に関するよくある質問

MES更改は、製品の機能比較から入るのではなく、「どう進めるか」という工程設計から始めることが成功の分かれ目です。As-Is/To-Be分析と現場ヒアリングで対象を見極め、BOPとマスタ整備という前提工程を飛ばさず、スモールスタートで効果を検証しながら横展開する——この基本の流れを押さえることが、手戻りのない更改につながります。レトロフィットIoTによるレガシー設備のデータ化、ERPとMESの疎結合設計、切り戻し計画まで含めた工場を止めない移行、間接的リスク回避効果まで含めたROIの提示が、MES更改ならではの勘所です。
Q. MES更改にはどのくらいの期間がかかりますか
規模によりますが、要件定義から本稼働まで、一般的には1年から2年程度を見込んでおくとよいでしょう。単一ラインのスモールスタートであれば半年程度で立ち上げられる場合もありますが、BOP・マスタ整備や移行リハーサルの工数を軽視すると終盤で遅延しがちです。複数拠点へ展開する大規模更改では、全社展開まで3年以上を要することも珍しくありません。重要なのは、スケジュールにマスタ整備とリハーサルの期間を最初から織り込んでおくことです。
Q. 工場を止めずにMES更改はできますか
完全に無停止での切り替えは難しいものの、停止時間を最小化することは十分に可能です。ラインや機能ごとに順次切り替える段階移行を選び、新旧の並行稼働期間を設けることで、リスクを分散できます。あわせて、データ移行リハーサルで切り替え作業の実時間を正確に把握し、許容ダウンタイムと切り戻しの判断基準を稼働前に経営層まで合意しておくことが、止めない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を創業。
