製造業のモダナイゼーション｜密結合を解くシステム刷新とAI活用

製造業のモダナイゼーションとは、長年使い続けてきた生産管理・原価計算・品質管理・受発注などのレガシーシステムを、業務ロジックを失わずに新しい技術基盤へ段階的に移行する取り組みです。

単に言語やサーバーを置き換えるのではありません。システム同士の依存関係を整理し、データとAIを活用できる状態をつくることが本来の目的です。

製造業では、工場の稼働を止められないことに加え、Excelや夜間バッチを介して業務が複雑に絡み合っているため、他業界よりも刷新の難易度が高くなります。そこで現実的なのが、①現行資産のアセスメント、②AIを活用した変換と人によるレビュー、③現新比較テストによる検証の3段階で進める方法です。

本記事では、情報システム部門のご担当者が社内提案にもそのまま使えるよう、密結合の解き方、技術別の移行パターン、進め方、費用の考え方までを解説します。

製造業のモダナイゼーションとは？システム刷新・マイグレーションとの違い

「システム刷新」「マイグレーション」「モダナイゼーション」は混同されがちですが、目的と範囲が異なります。まずは言葉の違いを整理し、そのうえで製造業ならではの事情を見ていきましょう。

モダナイゼーション・マイグレーション・リプレースの違い

最も大きな違いは、既存の業務ロジックをどう扱うかです。

項目	モダナイゼーション	マイグレーション	リプレース
目的	業務ロジックを活かし、変化に強い基盤へ再構築する	現行機能をそのまま新しい環境へ移す	パッケージなどの新システムに置き換える
主な範囲	アーキテクチャ・データ・運用まで	言語・OS・DB・インフラ	業務プロセス全体
業務ロジック	可視化して継承・改善する	ほぼそのまま移行する	パッケージの標準に合わせて再設計する
向いているケース	自社独自のノウハウがシステムに組み込まれている	機能に不満はないが基盤が老朽化している	業務を標準化してよい領域

それぞれの手法の詳しい比較は「モダナイゼーションとマイグレーションの違い」で、全体像は「システムモダナイゼーションの全体像」で解説しています。

では、なぜ製造業ではこうした刷新が後回しになりやすいのでしょうか。

なぜ製造業ではレガシーシステムが残りやすいのか

製造業には、システムを長く使い続けやすい構造的な理由があります。

• 設備・製品のライフサイクルが長い：生産設備は15年、20年と使われることも多く、それに接続するシステムも同じだけ使い続けられます。
• 工場・ラインごとの個別最適：同じ会社でも工場ごとに生産方式やコード体系が異なり、システムが工場単位でカスタマイズされています。
• 現場改善の積み重ねがコードになっている：日々の改善活動で追加された例外処理や計算ルールが、仕様書に残らないままプログラムに埋め込まれています。
• 作った人がいない：開発を担当したベテランや外部ベンダーの担当者が退職・交代し、全体を説明できる人がいなくなっています。

こうした状態は「レガシーシステムの問題点」でも詳しく取り上げています。

2026年、製造業がモダナイゼーションを先送りできない3つの理由

「今は動いているから問題ない」という判断は、2026年の製造業ではリスクが大きくなっています。ここでは先送りできない理由を3つに整理します。

保守限界と技能継承：ベテラン退職でシステムがブラックボックス化

1つ目は、システムを理解している人材がいなくなるリスクです。

経済産業省などがまとめた「2026年版ものづくり白書」で紹介された調査では、技能継承が「うまくいっている」「ややうまくいっている」と答えた企業は合わせて約3分の1にとどまります。技能継承に苦戦する企業は3社に2社という状況です。

この課題は現場の技能だけでなく、システムの知識にもそのまま当てはまります。原価計算のロジックや例外処理の意図を知る人が退職すると、システムは誰も触れない 「ブラックボックス」 になります（関連記事：システムのブラックボックス化とは）。

さらに、基盤側の期限も迫っています。Windows 10のサポートは2025年10月に終了し、SAP ERP 6.0の標準保守も2027年末に終了予定です。OSやミドルウェアが古いままでは、改修したくてもできない状態に陥ります。

保守の問題は、社内だけでは終わりません。

サプライチェーン全体に波及するサイバーリスク

2つ目は、セキュリティリスクがサプライチェーン全体に広がることです。

2022年3月には、部品サプライヤーのシステム障害（サイバー攻撃）を受けて、トヨタ自動車が国内14工場28ラインの稼働を停止しました（MONOist）。1社のシステムの弱点が、取引先の生産まで止めてしまう例です。

サポートが終了したOSやミドルウェアは、セキュリティ更新が受けられません。経済産業省も「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」で、工場のシステムを含めた対策の考え方を示しています。

そして3つ目の理由は、守りではなく攻めの側にあります。

データ・AI活用の前提条件になる

3つ目は、レガシーシステムがデータとAI活用の壁になることです。

IPA（情報処理推進機構）の「DX動向2025」では、日本企業は「レガシーシステムはない」「ほとんどがレガシーシステムである」の回答割合がいずれも日米独3か国で最も高く、刷新が済んだ企業と進んでいない企業に分かれている状況が示されています。前年度からの変化も小さく、刷新は「頭打ち」と分析されています。

予知保全、需要予測、品質検査AIなどは、部門ごとに分断されたデータのままでは十分に機能しません。製造業のモダナイゼーションは、AI活用のスタートラインに立つための投資でもあります（関連記事：レガシーシステムがデータ・AI活用の壁になる理由）。

製造業システムの「密結合」とは？刷新を難しくする本当の原因

製造業のモダナイゼーションやシステム刷新が難航する理由として、「COBOLやVB6などの古い言語」が挙げられがちです。しかし実際の現場では、言語が古いことよりも、業務同士が見えない形でつながっていることの方が大きなリスクになります。

生産管理・MES・品質・原価・購買をつなぐ見えない依存関係

製造業の基幹システムは、生産管理を中心に、MES（製造実行システム）、品質管理、原価計算、購買・EDI、在庫管理などが相互にデータをやり取りしています。

問題は、そのつながりの多くが設計書に書かれていないことです。たとえば次のようなケースがよく見られます。

• BOM（部品表）の変更が原価計算に波及する：生産管理側で品目構成を変えたところ、翌月の原価計算で想定外の差異が出る。
• 夜間バッチの実行順序に依存している：在庫引当→MRP計算→発注データ作成の順番が崩れると、翌朝の発注が誤る。
• コード体系を複数システムで共有している：品目コードや工程コードの桁数を1つ変えるだけで、品質記録や出荷システムまで改修が必要になる。

このような依存関係を把握しないまま一部だけを刷新すると、「新システムは正しく動くのに、隣の業務が壊れる」という事態が起こります。

さらに見落とされやすいのが、正式なシステム一覧に載っていない仕組みです。

Excel/VBA・Access・CSV連携が生む「影のシステム」

製造現場では、部門ごとに作られたExcelマクロ（VBA）やAccessのツールが、正式なシステム同士をつなぐ役割を担っていることが少なくありません。

• 生産計画をExcelで調整し、CSVで生産管理システムへ取り込む
• 検査結果をAccessで集計し、品質報告書を作成する
• 購買担当者が独自マクロで発注データを加工してEDIへ送る

こうした 「影のシステム」 は、刷新の範囲から漏れやすく、移行後に「必要な帳票が出ない」「データの受け渡しができない」といった問題の原因になります。VBAやVB6の資産をどう扱うかは「VB6／VBAモダナイゼーション」で詳しく解説しています。

情報系の中だけでなく、工場の設備との境界にも注意が必要です。

IT（情報系）とOT（制御系）の境界をどう扱うか

製造業のシステムは、生産管理や原価などの IT（情報系） と、PLC・SCADAなど設備を動かす OT（制御系） に分かれます。

一般的に、モダナイゼーションの対象はIT側です。OT側は設備メーカーの保証や安全基準が関わるため、別の計画で扱うのが基本です。

ただし、両者の 接続部分（インターフェース） は必ず対象に含めるべきです。設備から実績データを受け取る仕組みや、作業指示を送る仕組みが変われば、現場の運用に直接影響します。刷新範囲を決める際は、「どこまでをITとして刷新し、どの接続仕様を維持するか」を最初に明確にしておきましょう。

製造業に多いレガシー技術と移行パターン一覧

製造業の現場でよく使われているレガシー技術と、主な移行先を一覧にまとめました。製造業のモダナイゼーションを計画する際、自社のシステムがどこに当てはまるかを確認する目安としてご活用ください。

レガシー技術	製造業での典型的なシステム	主な移行先	移行時の注意点	詳しい解説
COBOL／RPG（オフコン・メインフレーム）	原価計算、会計、受注管理	Java／Python	計算ロジック・端数処理の継承	COBOL移行で業務ロジックを守る方法
VB6／VBA／Access	生産管理クライアント、現場ツール	C#（.NET）、Python、Webアプリ	影のシステム化、帳票の再現	VB6／VBAモダナイゼーション
Java Struts	受発注Web、EDI、取引先ポータル	Spring Boot	依存ライブラリと回帰リスク	Struts→Spring Boot移行
Lotus Notes	品質報告、稟議・ワークフロー	SharePoint／intra-mart	文書と承認履歴の移行	―
オンプレミスDB・夜間バッチ	在庫管理、MRP計算	クラウドDB、ジョブ管理基盤	実行順序と処理時間の確保	マイグレーションの進め方

技術の種類がわかったら、次は「どの手法で移行するか」を決めます。

手法の選び方：リホスト・リライト・リビルド・リプレース

モダナイゼーションの手法は、主に次の4つです。

1. リホスト：プログラムはそのままに、サーバーやOSだけを新しい環境へ移す。
2. リライト：業務ロジックを保ったまま、新しい言語へ書き換える。
3. リビルド：業務を整理し直し、アーキテクチャから作り直す。
4. リプレース：ERPなどのパッケージ製品に置き換える。

製造業では、「その業務が自社の競争力の源泉かどうか」 と 「技術的な老朽化の度合い」 の2軸で判断すると整理しやすくなります。

• 会計・人事など標準化しやすい業務：パッケージへのリプレースが有力です。
• 生産計画・原価計算・品質管理など独自ノウハウが詰まった業務：ロジックを継承できるリライトやリビルドが向いています。
• 老朽化はしているが業務上の不満が少ないシステム：まずはリホストで延命し、段階的に次の手を打つ方法もあります。

製造業のモダナイゼーションの進め方【5ステップ】

ここからは、製造業のモダナイゼーションを実際に進める手順を5つのステップで解説します。基本となる考え方は、「アセスメント → AI支援による移行 → テストによる検証」 の順に、根拠を確かめながら一歩ずつ進めることです。

全体の流れは「マイグレーションの進め方」もあわせてご覧ください。

Step1：現行資産のアセスメント（コード・DB・バッチ・帳票・設備I/F）

製造業のモダナイゼーションは、現行システムの全体像を棚卸しするところから始まります。対象はソースコードだけではありません。

• プログラムとその呼び出し関係
• データベースのテーブル構造と更新元
• 夜間バッチ・ジョブの実行順序
• 帳票・CSV・EDIなどの入出力
• 設備やMESとのインターフェース
• 正式な一覧に載っていないExcel／Accessツール

アセスメントで何を確認すべきかは「レガシーシステムアセスメント」、結果をどうまとめるかは「アセスメントレポートで確認すべきこと」で解説しています。

棚卸しができたら、次はその中に埋もれている「業務のルール」を取り出します。

Step2：業務ロジックの可視化（原価計算・MRP・ロット管理）

製造業で特に重要なのが、原価計算、MRP（資材所要量計画）、ロット・トレーサビリティなどの業務ロジックです。

これらは長年の改善で例外処理が積み重なっており、コードを読まなければ正しい仕様がわからないことがほとんどです。最近では、AIを使ってソースコードから処理内容を読み解き、仕様書として整理する AIリバースエンジニアリング が有効な手段になっています（関連記事：AIリバースエンジニアリング）。

可視化したロジックは、必ず現場の担当者に確認してもらいましょう。「コード上はそう動くが、実は使っていない処理」もここで判明します。

Step3：優先順位と範囲の決定（工場・ライン単位の段階移行）

すべてを一度に刷新する「ビッグバン移行」は、製造業では特にリスクが高い方法です。

アセスメントの結果をもとに、業務への影響度、技術的な老朽化度、依存関係の少なさから優先順位をつけます。そのうえで、特定の工場やライン、あるいは独立性の高い業務から段階的に移行するのが現実的です。

優先順位の具体的な決め方は「モダナイゼーションの優先順位と範囲の決め方」をご覧ください。

Step4：AI支援による変換と人によるレビュー

移行対象が決まったら、コード変換に入ります。生成AIを活用すると、コード変換やドキュメント作成の工数を大きく減らせます。

ただし、AIの出力をそのまま本番に使うのは危険です。AIは、もっともらしいが誤ったコードを生成すること（ハルシネーション）があります。AIが変換し、エンジニアが業務ロジックの観点でレビューするという役割分担が欠かせません（関連記事：マイグレーションへのAI活用、生成AIのハルシネーションと移行リスク）。

Step5：現新比較テストと工場を止めない切替

最後に、新システムが旧システムと同じ結果を出すことを確かめます。

製造業では、同じ入力データを新旧両方に流し、原価・所要量・在庫などの計算結果を突き合わせる「現新比較テスト」 が特に有効です。あわせて、既存機能が壊れていないかを確認する回帰テストも行います（関連記事：マイグレーションテストの全体像、回帰テストで旧システムの振る舞いを守る、移行後に業務ロジックを検証する方法）。

切替のタイミングは、連休や棚卸し、生産の閑散期など生産計画に合わせて設定します。一定期間は新旧を並行稼働させ、問題があればすぐに戻せる切り戻し手順も事前に用意しておきましょう。

AIは製造業のモダナイゼーションをどこまで加速できるか

ここ数年で、生成AIはモダナイゼーションの進め方を大きく変えつつあります。一方で、「AIに任せればすべて自動で移行できる」わけではありません。AIの得意・不得意を正しく理解することが、成功への近道です。

AIが得意な作業：コード解析・仕様書復元・テストケース生成

AIが特に力を発揮するのは、大量のコードを読み、整理する作業です。

• ソースコード全体の構造解析と依存関係の抽出
• コードからの仕様書・設計書の復元
• 旧言語から新言語へのコード変換の下書き
• テストケースやテストデータの生成

数十万行規模のコードを人だけで読み解くには、多くの時間と人手が必要です。AIを使えば、この初期調査とドキュメント化の期間を大きく短縮できます。

では、人は何を担うべきなのでしょうか。

人が判断すべき領域：品質基準・例外処理・現場運用

AIが出した結果が「業務として正しいか」を判断するのは、人の役割です。

• 品質基準：どの程度の差異まで許容するか、何をもって合格とするか
• 例外処理：特急品、返品、設計変更など、まれだが重要なケースの扱い
• 現場運用：画面や帳票が現場の作業手順に合っているか

特に製造業では、計算結果のわずかな違いが原価や品質記録に影響します。AIで生成したコードの品質をどう担保するかは「AIで移行したシステムの品質を守るテスト」で詳しく解説しています。

AIの価値は、コード変換だけにとどまりません。

ベテランの暗黙知を「AIが使える形式知」に変える

製造業のモダナイゼーションで見落とされがちな価値が、暗黙知の形式知化です。

ベテラン担当者の頭の中にしかない「この品目はこう計算する」「この取引先だけ例外」といった知識を、アセスメントとAIリバースエンジニアリングを通じて仕様書や業務ルールとして残すことができます。

先に触れた技能継承の課題に対しても、システムの知識を文書として残すことは有効な対策になります。整理された業務ルールとデータは、将来の生成AIやAIエージェント活用の土台にもなります。

製造業のモダナイゼーションでよくある失敗と対策

ここまでの進め方を踏まえ、製造業のモダナイゼーションでよく見られる失敗パターンと、その対策を整理します。

よくある失敗パターン5つ

失敗パターン	主な原因	対策
言語を置き換えただけで終わる	目的が「古い言語からの脱却」だけになっている	データ活用や保守性など、刷新後のゴールを先に決める
Excel／VBAツールを見落とす	正式なシステム一覧だけで範囲を決めた	現場ヒアリングとファイル調査で影のシステムを洗い出す
繁忙期に切替が重なる	生産計画を考慮せずにスケジュールを組んだ	連休・閑散期に合わせ、切り戻し手順も用意する
新旧で計算結果が合わない	テストデータと比較観点の準備が不足していた	本番相当のデータで現新比較テストを計画する
ベンダーに丸投げする	業務ロジックの確認責任が曖昧だった	業務部門が確認する工程と承認基準を明確にする

パートナー選びで確認すべき点は「モダナイゼーションベンダーの選び方」で解説しています。

失敗を避ける準備ができても、社内の承認が得られなければプロジェクトは始まりません。

経営層の稟議を通すための説明ポイント

モダナイゼーションは「今すぐ売上が増える投資」ではないため、稟議で後回しにされがちです。経営層に説明する際は、次の4点を押さえると伝わりやすくなります。

1. 何もしない場合のコスト：保守費の増加、障害時の生産停止リスク、担当者退職による属人化リスクを具体的に示す。
2. リスクの見える化：アセスメント結果をもとに、依存関係や移行難易度を数字と図で示す。
3. 段階的な投資計画：最初から全体予算を求めず、「アセスメント → 一部業務の移行 → 横展開」と段階ごとに判断できる計画にする。
4. 刷新後の効果指標（KPI）：保守工数、障害件数、データ取得までの時間など、刷新後に測れる指標を決めておく。

特に3つ目の 「まずはアセスメントから」 という進め方は、承認のハードルを下げるうえで有効です。

費用と期間の考え方：段階投資でリスクを抑える

製造業のモダナイゼーションの費用は、システムの規模や状態によって大きく変わります。ここでは、金額の目安よりも先に押さえておきたい考え方を整理します。

費用・期間を左右する要因

主に次の要因によって、費用と期間が決まります。

• プログラムの規模：ソースコードの行数、画面・帳票・バッチの数
• インターフェースの数：MES、EDI、設備、他システムとの連携の多さ
• ドキュメントの状態：設計書が残っているか、最新の状態か
• 対象となる工場・拠点の数：段階展開の回数
• 並行稼働の期間：新旧を同時に動かす期間の長さ

正確な見積もりのためにも、最初にアセスメントで現状を把握することが重要です。

オフショア×AIでコストとスピードを両立する

コストと期間を抑える方法として、オフショア開発と生成AIの組み合わせがあります。

HBLABでは、AIを活用することで工数を30〜50％削減し、アセスメントと文書化の期間を約40％短縮した実績があります。たとえば、約20万行のJava StrutsシステムをSpring Bootへ移行した事例では、総工数約150人月、期間9か月で対応しました。

ベトナムのエンジニアチームとAIを組み合わせることで、品質を保ちながら国内だけで進めるよりも現実的なコストでの移行を目指せます。

業界別に見るモダナイゼーションのポイント（製造・金融・小売・物流）

モダナイゼーションの基本的な進め方は業界を問わず共通ですが、重視すべき制約は業界ごとに異なります。製造業の特徴を、他業界と比べて整理しました。

業界	特有の制約	代表的なシステム	特に注意すべき点
製造	工場を止められない、設備との連携	生産管理、原価、品質、MES	業務間の密結合、IT／OTの境界
金融	規制対応、高い可用性	勘定系、融資・決済	COBOL資産、監査証跡
小売	繁忙期の負荷、店舗数	POS、在庫、EC	季節変動への耐性、店舗展開
物流	リアルタイム性、取引先連携	WMS、TMS	出荷データの連携、24時間運用

製造業は、業務の連鎖が長く、1か所の変更が工場全体に波及しやすい点が最大の特徴です。そのため、他業界以上にアセスメントと検証に時間をかける価値があります。

製造業のモダナイゼーションならHBLABへ

HBLABは、アセスメント → AI支援による移行 → テストによる検証の3段階で、レガシーシステムのモダナイゼーションを支援しています。

• AI Assessment Tool：ソースコードをアップロードするだけで、AIが構造・依存関係・移行難易度を分析します。
• AIを活用した移行：COBOL、VB6／VBA、Java Strutsなど、製造業に多いレガシー技術の移行に対応しています。
• 検証を重視した品質保証：ISTQBゴールドパートナーとして、現新比較テストや回帰テストで「旧システムと同じ結果」を確認します。
• 信頼できる体制：ISO/IEC 27001:2022認証、CMMIレベル3を取得し、AWSアドバンストティアサービスパートナーにも認定されています（詳細）。

サービスの詳細は「HBLABのモダナイゼーションサービス」、ソリューションの背景は「Modernization Solution（Migurei AI Inside）提供開始のお知らせ」をご覧ください。そのほかの関連記事は「モダナイゼーション記事一覧」にまとめています。

よくある質問（FAQ）

Q1. 設計書が残っていなくてもモダナイゼーションできますか？

はい、可能です。ソースコードやデータベースの構造をAIで解析し、仕様書を復元するところから始められます。ただし、復元した内容は必ず現場の担当者と確認しながら進めることが重要です。

Q2. 工場を止めずにシステムを移行できますか？

多くの場合、可能です。工場・ライン・業務単位で段階的に移行し、一定期間は新旧を並行稼働させます。切替は連休や閑散期に合わせ、問題があればすぐに戻せる手順を準備します。

Q3. ERP導入とモダナイゼーション、どちらを選ぶべきですか？

業務によって使い分けるのがおすすめです。会計など標準化しやすい業務はERPなどのパッケージ、生産計画や原価計算など独自ノウハウが強みになっている業務は、ロジックを継承できるモダナイゼーションが向いています。

Q4. 中小製造業でもモダナイゼーションは必要ですか？

規模にかかわらず、担当者の退職やOSのサポート終了といったリスクは共通のため、中小企業にとっても製造業のモダナイゼーションは避けて通れない課題です。中小製造業では、まず影響の大きいシステムを1つ選んでアセスメントし、小さく始めるのが現実的です。

Q5. AIで変換したコードの品質は大丈夫ですか？

AIの出力をそのまま使うのではなく、エンジニアによるレビューと、新旧の結果を突き合わせる現新比較テストで品質を確認します。AIは作業を速くする道具であり、正しさの判断は人が担います。

Q6. 期間はどのくらいかかりますか？

規模や範囲によって大きく異なります。参考として、HBLABでは約20万行のJava StrutsシステムをSpring Bootへ移行した事例で、期間は9か月でした。まずはアセスメントで規模を把握することで、現実的な計画を立てられます。

まとめ

本記事では、製造業がシステム刷新を進める際のポイントを解説しました。

• 刷新を難しくする本当の原因は、古い言語よりも、生産管理・品質・原価・購買などの業務が見えない形でつながる 「密結合」 です。
• 技能継承の難しさ、サプライチェーン全体のサイバーリスク、データ・AI活用の必要性から、2026年は先送りのリスクが大きくなっています。
• 進め方の基本は、アセスメント → AI支援による変換と人のレビュー → 現新比較テストと段階的な切替です。
• 経営層には、何もしない場合のコストと、アセスメントから始める段階的な投資計画で説明すると承認を得やすくなります。

工場を止めずに、業務ロジックを守りながら進めることが、製造業のモダナイゼーションを成功させる鍵です。まずは自社システムの依存関係を把握するところから始めてみてください。