リリースの出方が製品ごとに違う。まずそこを揃える

「MESのバージョンアップ」と一言で言っても、製品によってリリースの周期も呼び名も異なります。2026年時点の主要製品の状況を並べると次のようになります。

製品リリース体系2026年の動き
Siemens OpcenterYYMM形式（2607＝2026年7月版）へ移行済みOpcenter MES Medical Device 2607を2026年8月14日リリース。Kubernetes＋Linuxコンテナ化によりゼロダウンタイム更新を実現
Siemens Opcenter X同じくYYMM形式のSaaS2607を2026年8月14日リリース。中小製造業向けのモジュール型MOM
GE Vernova／Velotic Proficy年次（Proficy 2026）ポートフォリオ全体を階層型のサブスクリプション／ライセンスモデルへ移行。SchedulerはフルSaaS化
Dassault Systèmes DELMIA Apriso年次（Apriso 2026）公式ドキュメントがApriso 2026として提供

ここから読み取れることは2つあります。第一に、リリース間隔が短くなり、かつ「更新しないという選択」が取りにくくなったこと。第二に、更新の技術的コストを製品側が下げにきていることです。コンテナ化によるゼロダウンタイム更新は、その代表例です。

背景には標準側の変化もあります。2025年4月10日に発行されたANSI/ISA-95.00.01-2025は、モジュラー／コンテナ化アーキテクチャ（オンプレミス・クラウド・ハイブリッド）への対応を正式に取り込みました（ISA-95 2025年改訂）。頻繁な更新を前提とした設計が、標準側からも追認された形です。

バージョンアップ費用を決めるのは「カスタマイズがどの層にあるか」

同じ製品、同じ規模でも、更新費用は10倍以上ばらつきます。決定要因はほぼ一つ、カスタマイズを標準の内側に埋め込んだか、外側に置いたかです。

MESのカスタマイズ層とバージョンアップ影響の図 影響が小さい構成 外部アプリ／BI／連携基盤 公開APIのみ利用 設定（コンフィギュレーション） 画面・帳票・ワークフロー・コード体系 標準機能（無改造） ベンダーが更新責任を負う 更新時：回帰テストのみ 数日〜2週間 影響が大きい構成 外部アプリ 内部テーブルを直接参照 独自スクリプト／トリガ 標準処理の途中に割り込む 改造された標準機能 ベンダーの更新責任が及ばない 更新時：全面再検証＋改修 数か月＋別途見積
カスタマイズの置き場所とバージョンアップ時の影響。標準機能に手を入れた層は更新のたびに再検証が必要になる。

右側の構成で特に危険なのは、外部アプリケーションがMESの内部テーブルを直接参照しているケースです。ベンダーはバージョン間でテーブル構造を変更する権利を持っており、それを事前に通知する義務は通常ありません。BIツールやExcelマクロが内部テーブルを直接見ていると、更新のたびに壊れます。

計画は「N-1ルール」と「更新窓」で立てる

現実的な運用方針は次の2つです。

N-1ルール — 最新版（N）ではなく1世代前（N-1）を常用する。最新版の初期不具合を他社が踏んでくれる分、安定性が上がります。ただし、サポート終了までの残り期間を毎年確認しないと、いつの間にかN-3になっていた、という事態が起きます。

更新窓の固定 — 工場の年間カレンダーで、更新可能な停止期間をあらかじめ2回押さえます。多くの工場では長期連休が候補になります。この窓を毎年押さえておくと、「止められないから今年も見送る」という先送りが構造的に起きにくくなります。

そのうえで、更新の判断材料は次の4点です。

  1. サポート終了日（本体、OS、データベース、ブラウザ）
  2. 適用しないと解消しないセキュリティ脆弱性の有無
  3. 自社が要望していた機能が新版に入ったか
  4. ライセンス体系の変更が更新と連動するか

4点目は2026年に重みが増しました。Proficyのように階層型サブスクリプションへ移行する製品では、バージョンアップと同時に課金体系が変わることがあります（MESのライセンス体系、MES予算がCapexからOpexへ）。

検証環境がない工場は、更新できない

意外なほど多いのが、本番環境しか持っていないケースです。この状態では、更新の影響を事前に確認する手段がなく、結果として更新自体ができなくなります。

必要なのは3環境です。

  • 本番 — 実際の生産
  • 検証（ステージング） — 本番と同じバージョン・同じ設定・本番相当のデータ量。更新の予行演習と回帰テストを行う
  • 開発／教育 — 設定変更の試行と、新人の教育

3環境が費用面で厳しい場合、検証環境を常設せず更新時だけクラウド上に一時構築する方法があります。ライセンス上、非本番環境の扱いがどうなるかは製品によって異なるため、契約時に確認しておいてください。ここを確認せずに進めると、更新のたびに追加ライセンス費用が発生します。

よくある質問

バージョンアップの頻度はどのくらいが適切ですか？

オンプレミス型のパッケージであれば、2〜3年に1回を計画上の標準に置き、セキュリティ上の必要が生じたら前倒しする形が現実的です。SaaS型ではベンダー側の更新周期に従うことになるため、選定時に「更新の事前通知期間」と「更新を延期できるか」を確認してください。SaaSでも、Siemens Opcenter Xのように年に複数回のリリースが出る製品では、自社の検証工数を年間計画に織り込む必要があります。

カスタマイズをゼロにできれば更新は楽になりますか？

楽にはなりますが、ゼロは現実的ではありません。目指すべきは「ゼロ」ではなく「標準の外側だけに置く」ことです。具体的には、(1) 標準機能のコードには手を入れない、(2) 独自ロジックは公開APIまたはベンダーが提供する拡張ポイント経由で実装する、(3) 外部システムは内部テーブルではなく公開インターフェース経由で接続する、の3点を導入時の設計原則にしてください。この判断の枠組みはFit to Standard を貫くための意思決定で扱っています。

更新の見積が高すぎる場合、どう交渉すればよいですか？

見積の内訳を「ベンダー起因の作業」と「自社カスタマイズ起因の作業」に分けさせてください。前者は本来保守費に含まれるべき範囲で、後者は自社の設計判断の結果です。この分離をしないまま総額で交渉しても、根拠のない値引き要求になり関係が悪化します。分離させると、次回以降どのカスタマイズを撤去すれば費用が下がるかが具体的に見えます。