「生産管理システムが古すぎて、もう作った人も保守できる人もいない」「Excel と紙の指示書で現場が回っているが、人が抜けたら止まる」。製造業の経営者や情報システム担当の方から、こうした相談が増えています。基幹システムの刷新も現場の DX も必要なのは分かっている。けれど、見積もりは数千万円規模、期間は一年以上、しかも止められない生産ラインを抱えながら、という条件の重さに踏み出せない。

本記事は、この状態から現実的に動き出すための進め方を、発注者目線で整理した実務ガイドです。なぜ製造業の DX は止まりやすいのか、AI 駆動開発を組み込むと何がどう変わるのか、生産管理・在庫システムのリプレイスを半分の期間で進める手順、現場へのツール導入を定着させる段階、そして費用と期間の目安まで。AI 駆動開発のクリエイティブスタジオとして、実際の支援で使っている判断基準を、卸売・流通の刷新事例も交えて共有します。

製造業 DX が止まる 3 つの理由

まず、なぜ製造業の DX は他業種より止まりやすいのか。原因を切り分けないと打ち手を間違えるため、典型的な 3 つを押さえておきます。

ひとつ目は、レガシー基幹システムの存在です。生産管理や在庫、受発注を担うシステムが、十数年前に構築されたまま稼働し続けているケースは珍しくありません。当時の開発会社が撤退していたり、保守できる技術者が社内外にいなかったりして、誰も中身を正確に把握できない。手を入れれば何が壊れるか分からないので塩漬けにする、という悪循環に陥ります。新しい仕組みを作ろうにも、この基幹システムとデータ連携できなければ意味がないため、刷新そのものが DX の前提条件になってしまいます。

ふたつ目は、現場の暗黙知です。製造現場では、ベテランが経験で判断している段取り、設備ごとの癖、例外品の扱いといった知識が、ドキュメント化されないまま人に紐づいています。これらをそのままシステム化しようとすると要件が膨れ上がり、要件定義だけで何か月も溶けます。逆に暗黙知を無視して「あるべき業務」だけを実装すると、現場が使わず形骸化します。この暗黙知をどこまで拾い、どこを標準化するかの線引きが、製造業のシステム開発でもっとも難所になります。

みっつ目は、PoC 止まりです。DX の号令で AI やセンサーの実証実験には着手したものの、本番運用への移行で止まる。理由は、PoC が「動くこと」を確かめる段階で終わり、誰が運用し、既存業務とどうつなぎ、どう保守するかという運用設計が抜けているからです。製造業は止められない業務が多く、本番化のハードルが特に高いため、ここでつまずくと「やってみたが定着しなかった」という総括で終わってしまいます。

この 3 つは独立しているようで連鎖しています。レガシーが手を付けられないから暗黙知も移せず、暗黙知が読み解けないから PoC が本番に乗らない。だからこそ、刷新と現場 DX は別々のプロジェクトではなく、ひとつの段階移行として設計するのが現実解になります。

AI 駆動開発で何が変わるか

ここで AI 駆動開発を組み込むと、止まりがちな 3 点それぞれに効きます。前提として、AI 駆動開発とは Claude Code や Cursor のような AI エージェントを実プロジェクトの調査・実装・検証に組み込み、開発の手数を圧縮する進め方を指します（基礎は AI 駆動開発とは何か で整理しています）。

まず、レガシーの読み解きが自動化に近づきます。誰も把握していない既存システムでも、ソースコードやデータベース定義を AI に読ませて、画面ごとの処理の流れや、テーブル間の関係、外部連携の仕様を文章として書き起こさせることができます。人間が一画面ずつ追っていた仕様の棚卸しが、AI の下書きを技術者が検証する形に変わり、調査工程が大きく短縮されます。下書きが正確とは限らないため最後は人が裏取りしますが、ゼロから読むのと下書きを直すのとでは速度が桁違いです。

次に、段階移行を支える実装が速くなります。新旧システムを一定期間つなぐためのデータ連携や、画面ごとに新旧を切り替える仕組みの実装は、手数の多い地道な作業です。ここを AI が下支えすると、移行用のコードを短期間で用意でき、半分の期間という現実的なリプレイスが見えてきます。

そして、現場運用設計に手数を回せます。調査と実装が圧縮されたぶん、本来もっとも時間をかけるべき「現場がどう使うか」の設計に余力が生まれます。PoC 止まりを防ぐ鍵はここにあり、AI は省力化の手段であって、運用に乗せる判断と業務理解はあくまで人の側に残ります。

生産管理・在庫システムのリプレイスを半分の期間で進める手順

ここからは、生産管理・在庫システムのリプレイスを、通常見積もりの半分程度の期間で進めるための具体的な手順を解説します。実際に Rails 系で稼働していた業務システムを段階移行で刷新し、通常の半分の期間と工数で乗り換えた事例（レガシー刷新を半分の期間で実現した事例）の進め方をベースにしています。

既存システムの棚卸しと AI による仕様読み解き

最初にやるのは、新しい設計を描くことではなく、いま動いているものを正確に把握することです。リプレイスの失敗の大半は、現行システムが何をしているかを把握しきれないまま新システムを作り始め、移行直前に「この機能が抜けている」と気づくパターンで起きます。

棚卸しでは、画面一覧、データベースのテーブル構造、外部システムとの連携（会計、EDI、設備からのデータ取り込みなど）、そして帳票の三点を中心に洗い出します。ここで AI 駆動開発が効きます。ソースコードとスキーマを AI に読ませ、画面ごとの処理内容、各テーブルの役割、連携の入出力を文章化させると、人手では数週間かかる読み解きの下書きが短期間で揃います。

ただし、ここで出てくる仕様には「実装されているが実は誰も使っていない機能」や「コードからは読めない運用上の運用ルール」が混在します。そこで、AI が起こした下書きを現場のキーパーソンと突き合わせ、残す機能・捨てる機能・新システムで作り直す機能を仕分けます。この仕分けこそが、期間とコストを半減させる最大の分岐点です。レガシーには使われていない機能が必ず溜まっており、それを丸ごと移植しようとすると工数が倍増します。「現行どおり」を要件にしないことが、半分の期間で進める前提条件になります。

ユーザー操作型 Feature Flag による無停止の段階移行

棚卸しと新システムの設計が固まったら、移行に入ります。製造業のリプレイスで最大の制約は、業務を止められないことです。生産管理が一日止まれば現場が動かず、在庫がずれれば出荷に直結します。だからこそ、ある日いっせいに新システムへ切り替える「一括移行」は避け、機能や部門ごとに少しずつ移す段階移行を採ります。

その中核になるのが、ユーザー操作型の Feature Flag（機能フラグ）です。これは、新機能や新画面を「誰に・どの範囲で見せるか」をコードの修正なしに切り替えられる仕組みです。たとえば、まず情報システム部門だけが新しい在庫画面を使い、問題がなければ 1 つのラインの担当者へ、次に工場全体へ、と公開範囲を段階的に広げます。不具合が見つかればフラグを戻すだけで即座に旧画面へ復帰でき、システム全体を止める必要がありません。

この方式の利点は 2 つあります。ひとつは、現場が新画面に触れた反応を見ながら範囲を広げられるため、暗黙知に起因する想定外を早期に拾えること。もうひとつは、旧システムを並行稼働させながら移せるため、既存ベンダーが保守を続けている間も衝突なく進められることです。新旧のデータをどう同期させるか、いつ旧システムを止めるか、という移行計画とあわせて設計すれば、止められない生産現場でも安全に乗り換えられます。具体的な段階移行の組み立て方は システム刷新サービス でも整理しています。

製造現場の AI ツール導入を定着させる 5 段階

基幹システムの刷新と並んで相談が多いのが、Claude Code や Cursor といった AI 駆動開発ツールを、自社の開発・情報システム部門に定着させたいという要望です。製造業は社内に専任エンジニアが少なく、保守や小さな改修を外部に頼りきっている企業が多いため、ここを内製で回せるようにする意義は大きくなります。導入を形骸化させないための段階を、5 つに分けて示します。

第一段階は対象業務の選定です。いきなり基幹システムの改修に AI を使うのではなく、社内向けの小さなツールや、定型的なデータ集計、帳票出力の自動化など、失敗しても業務が止まらない領域から始めます。最初に勝ちやすい 1 つを選ぶことが、その後の推進力を左右します。

第二段階は環境とルールの整備です。何を AI に入力してよいか、機密情報の線引き、生成したコードのレビュー手順といった運用ルールを先に決めます。ここを曖昧にしたまま広げると、セキュリティ面の不安から現場が萎縮し、かえって使われなくなります。

第三段階は伴走しながらの実践です。最初の数件は、AI 駆動開発に習熟した支援側が現場の担当者と一緒に手を動かし、「どう指示すれば期待どおり動くか」「どこを人が検証すべきか」を実地で共有します。座学の研修より、実際の業務課題を題材に一緒に作るほうが圧倒的に定着します。

第四段階は社内標準の言語化です。うまくいった指示の出し方やレビュー観点を、社内のガイドやプロジェクト設定として文書に落とします。属人化を避け、次の担当者が同じ品質で使える状態を作る工程です。

第五段階は横展開と内製化です。最初の業務で得た成功体験と標準を土台に、対象を別部門や別業務へ広げ、外部依存を段階的に減らしていきます。この一連の進め方は AI 開発ツール導入支援 としても提供しており、製造業の開発・情報システム部門での定着を伴走します。

大切なのは、ツールを配って終わりにしないことです。AI 駆動開発の効果は、現場が日々の業務で繰り返し使い、社内に知見が溜まって初めて持続します。導入は出発点であって、ゴールではありません。

費用と期間の目安

最後に、もっとも気になる費用と期間の目安を整理します。あくまで一般的なレンジであり、対象システムの規模、連携数、現場の数、移行データ量によって幅が出る点は前提としてご理解ください。価格はいずれも税抜です。

生産管理・在庫システムのリプレイスは、おおむね 1,500 万〜4,500 万円が目安になります。小規模で単一拠点、連携が少なく機能も絞れる場合は下限に近づき、複数工場・複数システム連携・大量データの移行を伴う基幹刷新では上限に近づきます。期間は、従来の進め方なら一年前後かかる規模でも、AI 駆動開発で調査と実装を圧縮し、不要機能を捨てて段階移行で進めれば、半分程度に短縮できる余地があります。

費用を左右する最大の要因は、技術の難しさよりも「現行どおりをどこまで諦められるか」です。前述のとおり、レガシーには使われていない機能が溜まっており、それを全部移そうとすると工数が膨らみます。逆に、本当に必要な機能へ絞り込めれば、期間もコストも大きく下げられます。見積もりの段階で、残す・捨てる・作り直すの仕分けに踏み込めるかどうかが、総額を決めると言っても過言ではありません。

現場の AI ツール導入支援は、対象範囲と伴走期間によって別途見積もりますが、まずは一業務に絞って小さく始めれば、初期投資を抑えながら効果を確かめられます。リプレイスと並行して進めれば、刷新後のシステムを自社で改善し続ける体制づくりにもつながります。費用と期間の考え方をさらに詳しく知りたい場合は、無料相談で対象システムを伺ったうえで、現実的なレンジと進め方をお示しします。

まとめ

製造業の DX が止まる原因は、誰も把握できないレガシー基幹、人に紐づいた現場の暗黙知、そして本番に乗らない PoC の 3 つに集約されます。これらは連鎖しているため、基幹システムの刷新と現場の DX を別々に進めるのではなく、ひとつの段階移行として設計するのが現実解です。

AI 駆動開発を組み込めば、誰も読めなくなった既存システムの仕様読み解きを下書きとして自動化し、新旧をつなぐ移行実装を速め、その分の余力を本来時間をかけるべき現場運用の設計に回せます。生産管理・在庫のリプレイスは、不要機能を捨ててユーザー操作型 Feature Flag で無停止に段階移行すれば、通常見積もりの半分程度の期間で進められる余地があります。費用は 1,500 万〜4,500 万円が目安で、「現行どおり」をどこまで諦められるかが総額を決めます。あわせて Claude Code・Cursor の現場定着を 5 段階で進めれば、刷新後も自社で改善し続けられる体制が整います。在庫・倉庫管理システムを止めずに段階刷新する物流・運送業の進め方は 物流・運送業の AI 駆動開発 でも具体化しています。

老朽化した生産管理・在庫システムの刷新を検討しているなら、まずは現状調査と、残す・捨てる・作り直すの仕分けからお手伝いします。システム刷新サービス の内容をご覧いただき、リプレイスの無料相談をお気軽にご利用ください。