Blog

2026.08.13

生産管理システムの費用2026|見積が割れるのはライセンスではない

生産管理システムの費用2026|見積が割れるのはライセンスではない

「3社に相見積もりを取ったら、一番安いところと高いところで数倍違った」——生産管理システムの費用について、タイの日系工場からいただく相談は、かなりの頻度でこの一言から始まります。その差は、ライセンス価格の差ではありません。会社の規模や知名度の差でもありません。差を作っているのは、方式を変えてもほとんど動かない4つの項目を、その見積書に書いているかどうかです。本記事では日本市場の相場を整理したうえで、タイの日系工場を想定した5年総額を3方式に分解し、見積のどこが割れているのかを数字で示します。

生産管理システムの費用相場|提供形態別の価格レンジ

まず、公開されている相場観を確認しておきます。以下は日本国内の相場として各所で示されている数字で、円建てのまま扱います。タイでの調達価格は人件費構造も為替も違うため、後段で別途バーツ建ての試算を示します。

生産管理システムの価格は、提供形態によってレンジが大きく異なります。よく使われる区分は、クラウド型、オンプレミス型(パッケージ型)、スクラッチ開発の3つです。

提供形態初期費用継続費用導入期間
クラウド型0〜100万円月額 3万〜15万円1〜3か月
オンプレミス/パッケージ型100万〜1,000万円以上(ライセンス+インフラ)年間保守費は導入費の5〜15%程度3〜6か月
スクラッチ開発開発費 500万円〜数億円個別見積数か月〜1年以上

(出典に基づく日本市場の相場。単位は円)

この表を見て「レンジが広すぎて相場になっていない」と感じたなら、その感覚が正しいです。特にオンプレミス型の「100万〜1,000万円以上」は上限と下限が1桁、スクラッチ開発の「500万円〜数億円」に至っては2桁違います。相場表として提示されてはいるものの、自社の予算を組む材料としては、そのままでは使えません。

なぜレンジがここまで広がるのか。理由を先に言ってしまうと、これらの数字が指しているのがソフトウェアとインフラの値札だけだからです。同じソフトウェアを買っても、それを自社の業務で使える状態にするまでにかかる費用は、工場ごとに大きく違います。相場表が答えているのは「いくらで買えるか」であって、「いくらで使えるようになるか」ではありません。

クラウド型の価格

クラウド型は初期費用0〜100万円、月額3万〜15万円が相場とされています。導入期間は1〜3か月です。

初期費用がゼロになり得るのは、サーバーやOS、データベースの調達が不要だからです。ベンダー側が用意した環境に、自社のマスタを載せて使い始める形になります。月額料金は利用者数に応じた課金が主流で、ここに幅が出るのは、利用者数と使う機能の範囲の違いです。

費用面で注意すべきなのは、初期費用の低さがそのまま総額の低さを意味しないという点です。月額料金は、使い続けるかぎり毎月積み上がります。初期費用が安いことは、キャッシュフローの観点では確かに有利ですが、5年、7年という単位で見たときの総額はまた別の話です。この論点は後段の当社試算で、バーツ建ての具体的な数字として扱います。

クラウドとオンプレミスの選択そのものについては、クラウド型とオンプレミス型の比較で、費用以外の観点——ネットワーク断への耐性、データの所在、カスタマイズの自由度——も含めて整理しています。

オンプレミス型の価格

オンプレミス型(パッケージ型)は、初期費用がライセンスとインフラを合わせて100万〜1,000万円以上、年間保守費は導入費の5〜15%程度、導入期間は3〜6か月が相場です。

ここで、見積書を読むときに必ず引っかかる論点が1つあります。保守費の率と、その率が何にかかっているのかです。

上記の「導入費の5〜15%程度」とは別に、ソフトウェアライセンス費が50万〜500万円で、保守費はライセンス費の15〜20%が相場とする資料もあります。率だけを比べると15〜20%のほうが高く見えますが、率がかかる分母が違います。導入費全体(ライセンス+インフラ+導入支援)に5〜15%をかけるのか、ライセンス費だけに15〜20%をかけるのか。同じシステムでも、この読み替え方で年間保守費の金額は変わります。

相見積もりを比較するときは、まず「保守費の率」ではなく「年間保守費の金額」を並べてください。率は分母が見えないと比較になりません。保守費の中身をどう分解して読むかについては、業務システムの保守費用の内訳で、率の議論から金額の議論へ移すための整理をしています。

スクラッチ開発の価格

スクラッチ開発は開発費500万円〜数億円、開発期間は数か月〜1年以上とされています。

このレンジは、相場というより「そういう案件もある」という事例の幅に近いものです。スクラッチ開発の費用は、要件の量にほぼ比例します。したがって金額を決めているのは開発会社の単価ではなく、自社が要件として何をどれだけ出すかです。

タイの日系工場でスクラッチ開発が選択肢に上がるのは、多くの場合、既存の生産方式がパッケージの標準機能と合わないときです。特殊な受注形態、日本本社の帳票様式、タイ固有の税務・輸出入書類。これらを丸ごと吸収させようとすると、パッケージのカスタマイズよりスクラッチのほうが素直だという判断は、確かに成り立ちます。ただし、その判断をした瞬間に、要件を出す側の責任が一気に重くなることは意識しておく必要があります。

相場表に載らない3つの隠れコスト

提供形態別の相場に加えて、見落とされやすい費用として次の3つが挙げられています。

  • 並行稼働期間の二重コスト。新旧システムを同時に動かす期間は、同じ実績を二重に入力することになります。この期間の残業代と現場の負荷は、システムの見積書には出てきません。
  • 稼働後の追加カスタマイズ。稼働してから「この帳票が足りない」「この項目を増やしたい」が必ず出ます。稼働前の要件定義でゼロにすることはできません。
  • 解約時のデータ取り出し費用。特にクラウド型で問題になります。契約終了時に自社のデータをどの形式で、いくらで受け取れるのか。契約書に書かれていないことがあります。

この3つは、いずれも「システムそのものの価格」ではなく「システムを使い始め、使い続け、やめるためのコスト」です。本記事が扱うのは、まさにこの領域です。

なお、本記事は製品同士を比較する記事ではありません。どの製品が自社に合うかという観点での比較は、生産管理システム比較2026|費用相場と失敗しない選び方を参照してください。本記事が扱うのは、製品を決めた後——あるいは決める前——に必ず出てくる、見積書の内訳をどう読むかという論点に絞っています。

同じ規模でも見積が割れる理由|生産管理システムの費用は5層に分かれる

同じ工場が同じ要件を出しても、返ってくる見積が大きく割れる。この現象を理解するには、生産管理システムの費用を5つの層に分けて見るのが最も早い方法です。

費目何で決まるか見積に出るか
ライセンス/利用料製品と利用者数必ず出る
導入支援・Fit&Gap業務の複雑さだいたい出る
マスタ整備とデータ移行既存データの件数と精度出ないことがある
外部連携I/F連携先の本数出ないことがある
教育・受入テスト・並行稼働利用部門数と慎重さ出ないことが多い

①と②は、どのベンダーの見積書にも書かれています。製品の値札と、それを設定する工数だからです。ベンダーにとっては自社の売上そのものなので、書き漏らす理由がありません。

割れるのは③④⑤です。この3層には共通する性質があります。作業の主体が発注側にも及ぶということです。

マスタ整備は、最終的には自社の品目マスタを自社で確定させる作業です。外部連携は、相手側システムの仕様を出せるのは自社側です。受入テストは、テストケースを書いて合否を判定するのは自社の業務部門です。つまり③④⑤は「ベンダーがやる仕事」と「自社がやる仕事」の境界が曖昧な領域で、だからこそ見積の段階で落ちやすい。

そして落ちた費用は消えません。プロジェクトが始まってから、追加見積として、あるいは自社の残業として、必ずどこかで現れます。

「安い見積」は安いのではなく短い

相見積もりで極端に安い提案が出てきたとき、実際に起きていることの多くは値引きではありません。見積の範囲が短いのです。①②だけを書いた見積と、①〜⑤をすべて書いた見積を並べれば、前者が安く見えるのは当然です。

この構造は、プロジェクトの終盤で予算超過という形になって表面化します。ERP案件の失敗統計として、Panorama Consulting Groupの2026年ERPレポートを引く二次情報では、ディスクリート製造業のERP案件の73%が目標未達、業界平均は68%とされています。生産管理システムはERPの一部または隣接領域にあたるため、この傾向はそのまま参考になります。

なお、同種の資料では予算超過率として189%や215%といった数字も引かれていますが、出典側の表記が「予算比」なのか「超過分」なのか判然としないため、本記事ではこれを倍率としては扱いません。読者の側でも、この種の数字を見かけたときは分母の定義を確認することをおすすめします。予算に対して何パーセントなのか、予算を超えた分が何パーセントなのかで、意味が大きく変わります。

超過の背景に何があるのかは、費用の話だけでは説明しきれません。組織の側の要因については生産管理システム導入失敗の5つの断層で整理していますので、あわせて参照してください。

5年総額を3方式で分解する|当社試算

ここからは、具体的な工場を想定した試算を示します。以下はすべて当社試算であり、実際の金額は仕様・ベンダー・為替によって変動します。考え方の枠組みとしてご覧ください。単位はすべてTHB(バーツ)です。

前提条件

  • タイ・バンコク近郊の日系工場、従業員120名
  • 生産管理システムの利用者25名、拠点1
  • 外部連携3本
  • 品目マスタ8,000件、取引先マスタ600件、BOM 3,500行
  • 評価期間5年

3方式

  • 方式A:クラウド型(SaaS・標準機能中心)
  • 方式B:パッケージ(オンプレミス)
  • 方式C:スクラッチ開発(現地ベンダー)

初期費用の内訳

費目A クラウドB パッケージC スクラッチ
ライセンス1,600,000
サーバー・OS・DB420,000
要件定義700,000
開発3,200,000
設定/Fit&Gap・導入支援450,000900,000
マスタ整備・データ移行380,000380,000380,000
連携I/F 3本540,000600,000480,000
教育・受入テスト220,000260,000300,000
並行稼働160,000160,000160,000
初期計1,750,0004,320,0005,220,000

連携I/Fは1本あたり、Aが180,000、Bが200,000、Cが160,000で3本分を計上しています。方式によって単価が違うのは、標準コネクタの有無と、開発体制の違いによるものです。並行稼働の160,000は、3方式とも二重入力期間の残業相当として同額で計上しています。

継続費用と追加改修

費目A クラウドB パッケージC スクラッチ
利用料45,000/月(25名×1,800)
年間保守288,000(ライセンスの18%)480,000(開発費の15%)
インフラ運用・ホスティング60,000/年96,000/年
5年の継続費用計2,700,0001,740,0002,880,000

これとは別に、5年間の追加改修をAで300,000、Bで500,000、Cで900,000として計上しています。継続費用計には含まれない、単発の改修費用としての扱いです。

方式Bのライセンスは拠点ライセンスで、利用者数には依存しない前提です。この前提が後段の「利用者数による逆転点」で効いてきます。

5年総額

区分A クラウドB パッケージC スクラッチ
初期費用1,750,0004,320,0005,220,000
5年の継続費用2,700,0001,740,0002,880,000
5年の追加改修300,000500,000900,000
5年総額4,750,0006,560,0009,000,000
生産管理システムの費用2026|見積が割れるのはライセンスではない - figure 1

この前提条件では、5年総額は方式Aが4,750,000、方式Bが6,560,000、方式Cが9,000,000となりました。順位は初期費用でも5年総額でもA < B < Cで変わりません。利用者25名という条件では、クラウド型が費用面で有利です。

ただし、この結論は前提条件に強く依存します。どの前提が効いているのかを、次の2つの節で分解します。

方式を変えても動かない130万バーツ

本記事の中心は、ここから先です。

上の3つの内訳表を、もう一度縦に眺めてみてください。ライセンス、サーバー、開発費——これらは方式によって0にもなれば320万バーツにもなります。方式選定の議論が、この行に集中するのは自然なことです。

しかし、方式を変えてもほとんど動かない行が4つあります。

生産管理システムの費用2026|見積が割れるのはライセンスではない - figure 2
費目A クラウドB パッケージC スクラッチ
マスタ整備・データ移行380,000380,000380,000
連携I/F 3本540,000600,000480,000
教育・受入テスト220,000260,000300,000
並行稼働160,000160,000160,000
4項目の小計1,300,0001,400,0001,320,000

4項目の合計は、A 1,300,000、B 1,400,000、C 1,320,000。3方式とも130万〜140万バーツの帯に収まります

これが本記事の中心命題です。見積が割れるのは、この帯を見積書に書いているかどうかで割れています。ライセンス価格でも、ベンダーの規模でもありません。

なぜ動かないのか

4項目が方式に依存しない理由は、それぞれ明確です。

マスタ整備・データ移行が3方式とも380,000で同額なのは、この作業の対象が自社のデータだからです。品目マスタ8,000件、取引先マスタ600件、BOM 3,500行。この件数は、クラウドを選んでもスクラッチを選んでも変わりません。重複した品目コードを名寄せし、廃番を落とし、単位を統一し、BOMの階層を整える。この作業量は、受け皿がどんなシステムであろうと同じです。

連携I/Fは、方式によって1本あたりの単価が160,000〜200,000、3本分で480,000〜600,000の範囲で動きますが、動く幅は小さい。連携の工数を決めているのは、こちら側のシステムではなく相手側のシステムの仕様だからです。会計システムの仕訳フォーマット、日本本社への実績送信、倉庫システムとの在庫同期。相手が変わらない以上、突き合わせの工数も大きくは変わりません。

教育・受入テストは220,000〜300,000です。テストケースを書き、業務部門が実際に触り、不具合を出して直し、合否を判定する。この作業の量を決めているのは利用部門の数と業務の複雑さで、実装方式ではありません。

並行稼働は3方式とも160,000で同額です。新旧システムを同時に動かす期間に発生する二重入力と、その残業相当。これも実装方式とは無関係です。

4項目が初期費用に占める割合

同じ4項目が、初期費用に占める割合を見ると、方式ごとの見え方の違いがはっきりします。

方式4項目の小計初期費用占める割合
A クラウド1,300,0001,750,00074.3%
B パッケージ1,400,0004,320,00032.4%
C スクラッチ1,320,0005,220,00025.3%

方式Aでは、初期費用の74.3%がこの4項目です。 クラウド型は「初期費用が安い」とされますが、その安さはライセンスとインフラが要らないことによるものであって、4項目が消えるわけではありません。むしろ他が安い分、4項目の存在感が相対的に大きくなります。

そしてここが実務上の落とし穴になります。クラウド型の提案書で「初期費用450,000バーツ」とだけ書かれていた場合、それは表の設定/Fit&Gapの行しか含んでいません。実際には、そこに130万バーツが乗ります。提示された450,000バーツは、初期費用1,750,000バーツのおよそ4分の1にすぎません。約3.9倍の開きは、こういう形で生まれます。

ライセンスは総額の主役ではない

もう1つの角度から見ておきます。ライセンス・利用料そのものが5年総額に占める割合です。

方式対象金額5年総額に占める割合
A クラウド利用料2,700,00056.8%
B パッケージライセンス1,600,00024.4%
C スクラッチライセンスなし・開発費3,200,00035.6%

方式Bでは、ライセンスは5年総額の24.4%にすぎません。にもかかわらず、ベンダー選定の会議で最も時間が使われるのは、この24.4%の値引き交渉であることが少なくありません。残りの費目が議論されないまま契約が進み、稼働直前になって並行稼働の残業とマスタの不備が問題になる——という流れは、何度も見てきた光景です。

方式Aは利用料が56.8%と最も高い比率になりますが、これは5年という期間で累積した結果です。1名あたり月1,800バーツ、25名で月45,000バーツという料金そのものは、稟議の場では小さく見えます。期間で掛け算したときにどうなるかを、契約前に確認しておく必要があります。

利用者42名で逆転する|生産管理システムの選び方を費用から決める

前段の試算は「利用者25名」という前提に立っています。この前提が変われば結論も変わるので、どこで変わるのかを式で押さえておきます。

生産管理システムの費用2026|見積が割れるのはライセンスではない - figure 3

方式Aの5年総額は、利用者数に比例して増えます。

方式Aの5年総額 = 2,050,000 + 108,000 × 利用者数

2,050,000は、初期費用1,750,000と5年間の追加改修300,000の合計です。108,000は、1名あたりの5年分の利用料(1,800バーツ × 60か月)です。

なお、ここでは初期費用は利用者数によらず一定と置いています。実際には教育・受入テストは人数とともに増えるため、逆転点はこれより手前に来ます。

一方、方式Bのライセンスは拠点ライセンスで利用者数に依存しないため、5年総額は6,560,000で横ばいです。

この2本の線がどこで交わるかを見ます。

利用者数方式Aの5年総額方式Bの5年総額安いほう
25名4,750,0006,560,000A
41名6,478,0006,560,000A
42名6,586,0006,560,000B

42名で逆転します。 41名まではクラウド型が安く、42名からはオンプレミスのパッケージが安くなります。

この数字の使い方を、実務に即して2つ書いておきます。

第一に、現在の利用者数ではなく、5年後の利用者数で判断するということです。稼働時25名でも、翌年に生産技術部門と品質保証部門を追加し、その次の年に第二工場の立ち上げで人が増えれば、42名は現実的な射程に入ります。逆に、利用者を増やす計画が明確にないなら、クラウド型の優位は続きます。

第二に、42という数字は前提が変われば動くということです。1名あたり月1,800バーツという単価が1,500バーツなら分岐点は後ろにずれますし、方式Bのライセンスがユーザー数課金なら、そもそもこの比較は成立しません。重要なのは42という数字そのものではなく、クラウド型は右肩上がりの直線、拠点ライセンス型は水平線であり、必ずどこかで交わるという構造のほうです。

見積を受け取ったら、自社の条件でこの2本の線を引いてみてください。交点が自社の想定利用者数より右側にあるならクラウド型、左側にあるならパッケージ型が、費用面では有利という読み方になります。

見積書で確認する4つの数字

ここまでの内容を、見積書を受け取ったときの確認項目に落とし込みます。確認すべきは4つの数字です。この4つが書かれていない見積書は、金額が確定していないと考えたほうが安全です。

1. 連携I/Fの本数

最も金額が動きやすいのがここです。前段の試算は3本を前提にしていましたが、これが9本(+6本)になったときの影響を見ます。

方式1本あたり+6本の追加額5年総額(3本)5年総額(9本)
A クラウド180,000+1,080,0004,750,0005,830,000
B パッケージ200,000+1,200,0006,560,0007,760,000
C スクラッチ160,000+960,0009,000,0009,960,000

3方式とも100万バーツ前後の増加です。連携先が増えるという話は、要件定義の会議では「あとPLCからの実績も取りたいですね」「ハンディの在庫もつなぎたい」といった、ごく軽い一言で発生します。こうした一言が3つ4つ重なると、5年総額が100万バーツ動きます。その感覚を、要件定義の場に持ち込んでください。

見積書には「外部連携 一式」ではなく、連携先の名称と本数を明記してもらうことをおすすめします。相手システム名、方向(送信か受信か双方向か)、頻度(リアルタイムか日次か)。この3点が書かれていれば、後から本数が増えたときにも、増分の根拠が明確になります。

なお、倉庫システム(WMS)との連携は、生産管理システムの案件で最も頻繁に追加される連携先の1つです。WMS側にも同じ構造の費用が発生するため、両方を同時期に検討している場合はWMS費用の内訳もあわせて確認しておくと、連携部分の二重計上や漏れを防げます。

2. 移行するマスタの件数と精度

本試算では品目マスタ8,000件、取引先マスタ600件、BOM 3,500行を前提に、マスタ整備・データ移行を380,000と置いています。

見積書で確認すべきは、件数だけでなく精度の前提です。「8,000件を移行する」という記述と、「8,000件を移行し、重複と廃番を整理し、単位を統一する」という記述では、作業量がまったく違います。前者は転記作業、後者は業務の棚卸しです。

現実の工場では、品目マスタが8,000件あると言いながら、直近1年で実際に使われているのはその一部で、残りは過去の一時品目や重複登録、という状態が珍しくありません。ここを整理せずに移行すると、新システムの検索が使いものにならず、稼働後に結局やり直すことになります。生きている品目が何件なのかは、移行の見積を取る前に自社で数えておくべき数字です。

見積の前提として「発注側がクレンジング済みのマスタを提供する」と書かれているケースもあります。その場合、380,000相当の作業が自社側に残っているという意味です。ベンダーの見積からは消えますが、費用がゼロになったわけではありません。

3. 受入テストのケース数

教育・受入テストは方式によって220,000〜300,000を計上しています。ここで確認すべきは、テストケースを誰が書くか何ケース想定しているかの2点です。

受入テストは「システムが仕様どおり動くか」を確認する工程ではありません。「自社の業務が回るか」を確認する工程です。したがってテストケースは、業務を知っている自社の担当者が書く必要があります。ベンダーが書いたテストケースは、仕様書に書かれたことの確認にしかなりません。

見積書に「受入テスト支援 一式」とだけ書かれている場合、支援の中身を確認してください。テストケースの雛形提供までなのか、テスト実施の立ち会いを含むのか、不具合修正の工数を含むのか。ここが曖昧なまま進むと、テスト期間中に追加見積が出ます。

4. 並行稼働の期間

3方式とも160,000を計上している項目です。金額は小さく見えますが、期間が延びると比例して増えます。

並行稼働は、新旧システムに同じ実績を二重入力する期間です。現場の作業者にとっては単純に手間が2倍になるため、期間が長引くほど入力品質が落ち、「新システムのデータが合わない」という新たな問題を生みます。

見積書では、並行稼働を何か月として計上しているかを確認してください。1か月なのか3か月なのか。そして、その期間の残業代を誰の予算で持つのか。システム予算に入っているのか、製造部門の予算なのか。ここが決まっていないと、稼働直前に部門間の調整が発生します。

タイ工場で上乗せになる費用|多言語化・現地サポート・時差

前段の試算はタイの日系工場を前提にしていますが、日本国内での導入と比べて構造的に上乗せになる費用があります。3つ挙げます。

多言語化

生産管理システムの画面は、日本人管理者が日本語で、タイ人スタッフがタイ語で、本社報告が英語で必要になることがあります。パッケージ製品でタイ語UIに標準対応しているものは限られており、対応していても項目名やマスタの表示名は自社で登録する必要があります。

実務で効いてくるのは、UIそのものよりマスタの多言語表記です。品目名を日本語で登録すれば、現場のタイ人作業者は読めません。かといってタイ語だけにすれば、日本本社への報告時に翻訳が要ります。品目マスタ8,000件に対して日タイ英の3言語を持たせるとなると、マスタ整備の作業量はそのぶん増えます。

どの言語をどこまで持つかは、稼働後に変更すると全件の見直しになるため、要件定義の段階で決めておくべき事項です。

現地サポート

システムが止まったときに、誰が何時間以内に対応するか。ここは日本国内よりも選択肢が限られます。

日本のベンダーが提供するパッケージをタイで使う場合、一次サポートを現地パートナーが担い、二次サポートが日本という体制になることが多くなります。この体制自体は問題ありませんが、保守契約の範囲に現地パートナーの費用が含まれているかは確認が必要です。日本のベンダーとの保守契約とは別に、現地パートナーとのサポート契約が必要になるケースがあります。

サポート費用の水準は、タイ側の人件費構造の影響を受けます。参考として、タイの最低賃金は2026年時点で日額337〜400バーツ、全国平均は約374バーツです。原則として県別に定められ、バンコク、プーケット、チョンブリ、ラヨーン、チャチュンサオの各県と、スラータニー県サムイ郡が上限帯にあたります。さらに、事業主の社会保険料負担が2026年1月に月750バーツから875バーツへ引き上げられました。1人あたり月125バーツ、年1,500バーツの増になります。

これらは直接的にはシステム費用ではありませんが、前段の試算で計上した並行稼働の残業や、現地サポート要員の人件費の背景にある数字です。人件費が上がる方向にある以上、人手で埋める運用は、時間が経つほど不利になります。この点は、初期費用を抑えて運用でカバーするという判断をするときに、頭に置いておくべき前提です。

時差と稼働時間

日本とタイの時差は2時間です。小さいようですが、サポート窓口の稼働時間には効きます。タイの工場が朝8時に始業したとき、日本の窓口は朝10時。夕方、タイが17時のとき日本は19時で、日本側の窓口は閉まりつつあります。

生産管理システムのトラブルは、始業直後(前日の実績が反映されていない)と終業前(当日の実績を締められない)に集中します。つまり時差が最も効く時間帯に、トラブルが集中する構造です。

現地時間で対応できる窓口を持つかどうかは、保守費用の金額に直結します。見積を比較する際は、サポートの対応時間帯をタイ時間で書いてもらうことをおすすめします。「平日9時〜18時」とだけ書かれた見積が、日本時間なのかタイ時間なのかで、実質的なサービス水準は変わります。

投資環境とIT人材の需給

費用の話ばかりが続いたので、環境面の数字も1つ挙げておきます。タイBOIの2026年上期の投資申請は1兆4,730億バーツで、前年同期比37%増となりました。うちデジタル産業が1兆1,150億バーツを占めています。

ただし、この金額をそのまま追い風と読むのは早計です。デジタル産業の申請額の大半はデータセンターやクラウドへの投資で、生産管理システムの実装を担う人材が直接増えるわけではありません。むしろIT人材の需給は逼迫方向にあり、見積の人月単価に効いてきます。導入時期とパートナーの確保を検討する際は、この需給を視野に入れておくとよいでしょう。

生産管理システムの導入の流れと導入期間

生産管理システムの導入の流れは、方式が違ってもフェーズ構成はおおむね共通です。

1. 現状整理と要件定義

現在の受注から出荷までの流れを工程単位で書き出し、どこを新システムで扱うかを決めます。この段階で決めておくべきは、範囲(どの工程まで)、対象(どの製品ラインから)、そして「今回はやらないこと」です。3つ目が最も重要です。

2. 製品選定・方式決定

要件に対して、クラウド型、パッケージ、スクラッチのどれで応えるかを決めます。前段で示した4項目の帯と、利用者数による逆転点が、この段階の判断材料になります。

3. Fit&Gap・設定

パッケージの標準機能と自社業務の差分を洗い出し、設定で埋めるか、運用を変えるか、カスタマイズするかを1件ずつ決めます。ここでカスタマイズを増やすと、後の保守費用と追加改修費が膨らみます。

4. マスタ整備とデータ移行

前述のとおり、方式を変えても作業量が変わらない領域です。件数が多い工場では、このフェーズが全体の日程を決めます。要件定義と並行して着手するのが定石です。

5. 外部連携の実装とテスト

相手システムの担当者との調整が入るため、自社の都合だけでは進みません。連携先が多いほど、日程のリスクが上がります。

6. 教育と受入テスト

業務部門がテストケースを書き、実際に触り、合否を判定します。ここで出た不具合の修正期間を日程に織り込んでおかないと、稼働日が動きます。

7. 並行稼働と本稼働

新旧を同時に動かし、数字が一致することを確認してから旧システムを止めます。

導入期間の目安

当社試算の前提として置いている導入期間は、次のとおりです。

方式導入期間の目安
A クラウド型3〜4か月
B パッケージ(オンプレミス)6〜9か月
C スクラッチ開発9〜14か月

冒頭に示した日本市場の相場では、クラウド型1〜3か月、オンプレミス型3〜6か月、スクラッチ開発は数か月〜1年以上とされています。当社試算の期間がやや長めなのは、外部連携3本と、品目マスタ8,000件・BOM 3,500行の整備を含めているためです。

ここでも、期間を延ばしているのは製品ではなく4項目です。マスタ整備、外部連携、受入テスト、並行稼働。この4つは、方式を変えても短縮できません。導入期間を縮めたいなら、着手するタイミングを前倒しするのが唯一の方法です。特にマスタ整備は、製品を決める前から始められる作業です。

補助金は使えるか|デジタル化・AI導入補助金2026の対象範囲

生産管理システムの費用を検討する際、補助金の活用を検討される方も多いと思います。日本の制度について整理しておきます。

2026年度は、従来のIT導入補助金が「デジタル化・AI導入補助金2026」として実施されています。通常枠の内容は次のとおりです。

区分補助額補助率
1プロセス以上5万円〜150万円未満1/2
4プロセス以上150万円〜450万円1/2(一定要件で2/3以内)

タイ現地法人には使えません

ここが本節で最も重要な点です。

この補助金の対象は、日本国内の中小企業・小規模事業者です。タイ現地法人が現地で導入する費用は対象外になります。

実務上、これは繰り返し確認が必要な論点です。日本本社が主導してグループ全体の生産管理システムを刷新するプロジェクトで、日本の工場分は補助対象、タイの工場分は対象外、という状態が普通に発生します。プロジェクト全体の予算を組む段階でこの前提を外していると、後から数百万円単位で調達計画がずれます。

また、日本本社が費用を負担してタイの工場に導入した場合はどうか、という質問もよくいただきます。制度の趣旨は日本国内の中小企業のデジタル化支援であり、導入先が国外であれば補助対象として認められないと考えるのが妥当です。個別の判断は公募要領と事務局への確認が必要ですが、タイ側の予算は補助金なしで組むという前提で計画したほうが、後で困りません。

タイ側で使える制度

では、タイ側にまったく制度がないかというと、そうではありません。BOIの恩典の中には、デジタル技術の導入に関する支援措置があります。ただし適用条件は業種や投資内容によって細かく分かれており、生産管理システムの導入単体で恩典が受けられるかは、案件ごとの確認が必要です。

前述のとおり、タイBOIの2026年上期の投資申請は1兆4,730億バーツ、うちデジタル産業が1兆1,150億バーツと、デジタル分野への政策的な後押しは強い状況です。すでにBOI認可を受けている工場であれば、既存の恩典の枠内で対応できる部分がないか、確認する価値はあります。

いずれにせよ、補助金や恩典は費用計画の主軸には置かないことをおすすめします。採択されるかどうかは事前には確定せず、また補助対象経費にはソフトウェア購入費やクラウド利用料だけでなく導入設定・研修といった導入関連費も含まれますが、そもそもタイ現地法人がタイで支出する費用は対象外だからです。130万〜140万バーツの帯は、補助金があってもなくても発生します。

よくある質問

生産管理システムの費用相場はいくらですか?

提供形態で大きく違います。日本市場の相場としては、クラウド型が初期費用0〜100万円で月額3万〜15万円、オンプレミス/パッケージ型が初期費用100万〜1,000万円以上で年間保守費が導入費の5〜15%程度、スクラッチ開発が開発費500万円〜数億円とされています。

タイの日系工場を想定した当社試算では、従業員120名・利用者25名・外部連携3本・品目マスタ8,000件という条件で、5年総額がクラウド型4,750,000バーツ、パッケージ型6,560,000バーツ、スクラッチ開発9,000,000バーツとなりました。

ただし、相場表に載っているのはソフトウェアの価格であり、実際の総額はそこに導入作業の費用が乗ります。当社試算では、マスタ整備・データ移行、外部連携I/F、教育・受入テスト、並行稼働の4項目だけで、3方式とも130万〜140万バーツになります。

生産管理システムの価格は何で決まりますか?

ライセンス価格ではなく、次の4つで決まると考えたほうが実態に近いです。連携する外部システムの本数、移行するマスタの件数と精度、受入テストのケース数、並行稼働の期間です。

当社試算では、ライセンス・利用料が5年総額に占める割合は、クラウド型で56.8%、パッケージ型で24.4%、スクラッチ開発では開発費が35.6%でした。パッケージ型の場合、値札にあたるライセンスは総額の24.4%にとどまります。

金額が動きやすいのは連携I/Fの本数です。当社試算で3本から9本に増やすと、5年総額はクラウド型が5,830,000、パッケージ型が7,760,000、スクラッチ開発が9,960,000となり、3方式とも100万バーツ前後の増加になります。

生産管理システムの導入期間はどれくらいですか?

日本市場の相場では、クラウド型が1〜3か月、オンプレミス/パッケージ型が3〜6か月、スクラッチ開発が数か月〜1年以上とされています。

当社試算の前提では、外部連携3本と品目マスタ8,000件・BOM 3,500行の整備を含めて、クラウド型3〜4か月、パッケージ型6〜9か月、スクラッチ開発9〜14か月と置いています。

期間を左右するのは製品ではなく、マスタ整備、外部連携、受入テスト、並行稼働の4項目です。この4つは方式を変えても短縮できないため、日程を縮めたい場合は製品選定を待たずにマスタ整備から着手するのが現実的です。

生産管理システムの導入の流れは?

大きく7つのフェーズに分かれます。現状整理と要件定義、製品選定・方式決定、Fit&Gapと設定、マスタ整備とデータ移行、外部連携の実装とテスト、教育と受入テスト、並行稼働と本稼働です。

このうち、要件定義の段階で最も重要なのは「今回はやらないこと」を決めることです。範囲を決めずに要件を集めると、Fit&Gapで差分が膨らみ、カスタマイズが増え、保守費用と追加改修費が後年まで残ります。

また、マスタ整備は製品を決める前から着手できる唯一のフェーズです。品目マスタの重複整理や廃番の棚卸しは、どのシステムを選んでも必要になる作業なので、検討期間中に並行して進めておくと日程に余裕が生まれます。

タイ工場の生産管理システムに日本の補助金は使えますか?

使えません。デジタル化・AI導入補助金2026(旧IT導入補助金)の対象は日本国内の中小企業・小規模事業者であり、タイ現地法人が現地で導入する費用は対象外になります。

日本本社が主導するグループ全体のプロジェクトであっても、タイ側の導入費用は補助対象外と考えて予算を組むのが安全です。日本の工場分だけが対象になる前提で計画してください。

タイ側ではBOIの恩典にデジタル技術導入に関する支援措置がありますが、適用条件は業種と投資内容によって細かく分かれます。すでにBOI認可を受けている工場であれば、既存の恩典の枠内で対応できる部分がないかを確認する価値はあります。

まとめ

生産管理システムの費用について、本記事の要点を整理します。

相場表に載っているのはソフトウェアとインフラの値札です。 日本市場の相場は、クラウド型が初期0〜100万円・月額3万〜15万円、オンプレミス型が初期100万〜1,000万円以上・年間保守費は導入費の5〜15%程度、スクラッチ開発が500万円〜数億円。レンジが1桁から2桁も開いているのは、これらが値札であって、使える状態にするまでの費用を含まないためです。

費用は5層に分かれ、割れるのは下の3層です。 ①ライセンス/利用料と②導入支援・Fit&Gapはどの見積にも出ます。割れるのは③マスタ整備とデータ移行、④外部連携I/F、⑤教育・受入テスト・並行稼働です。この3層は発注側の作業と混ざるため、見積から落ちやすく、落ちても消えません。

方式を変えても4項目は動きません。 当社試算では、マスタ整備・データ移行、連携I/F、教育・受入テスト、並行稼働の合計が、クラウド型1,300,000、パッケージ型1,400,000、スクラッチ開発1,320,000バーツ。3方式とも130万〜140万バーツの帯に収まります。初期費用に占める割合は、クラウド型で74.3%、パッケージ型で32.4%、スクラッチ開発で25.3%。クラウド型を選んでもこの帯は消えません。

ライセンスは総額の主役ではありません。 5年総額に占める割合は、クラウド型の利用料が56.8%、パッケージ型のライセンスが24.4%、スクラッチ開発は開発費が35.6%です。5年総額はクラウド型4,750,000、パッケージ型6,560,000、スクラッチ開発9,000,000バーツでした。

利用者42名で逆転します。 方式Aの5年総額は 2,050,000 + 108,000 × 利用者数 で表され、拠点ライセンスの方式Bは6,560,000で横ばいです。41名ではAが6,478,000でBを下回り、42名では6,586,000でBを上回ります。判断すべきは現在の利用者数ではなく、5年後の利用者数です。

見積書では4つの数字を確認してください。 連携I/Fの本数、移行するマスタの件数と精度、受入テストのケース数、並行稼働の期間。連携I/Fを3本から9本に増やすだけで、5年総額は3方式とも100万バーツ前後増えます。

タイ側の予算に日本の補助金は乗りません。 デジタル化・AI導入補助金2026の対象は日本国内の中小企業・小規模事業者で、タイ現地法人が現地で導入する費用は対象外です。130万〜140万バーツの帯は、補助金があってもなくても発生します。

TOMAS TECHはバンコクを拠点に、日系製造業の工場IT・FA領域を支援しています。生産管理システムについても、製品を決める前の段階——自社の品目マスタが実際に何件生きているのか、連携が必要な相手システムは何本あるのか、5年後の利用者数はどのあたりに着地しそうか——といった、まだ要件定義書になっていない段階からご相談いただけます。既存システムの一覧と、直近の受注から出荷までの流れが分かる資料があれば、見積の読み方の当たりを付けるところまではお付き合いできますので、検討の初期段階でもお問い合わせページからお気軽にご連絡ください。

参考にした情報源