製番管理システム開発の完全ガイド

製番管理システムは、受注や製造の案件ごとに発番した製番を親キーに、設計・手配・実績・原価をつなぐ業務システムです。量産やロット管理とは、業務に応じて使い分けます。

導入判断に必要な機能、進め方、費用、会社の選び方、導入後の運用を、この一記事で見渡せます。

▼関連記事一覧
・製番管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・製番管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・製番管理システム開発の見積相場や費用/コスト/値段について
・製番管理システム開発の発注/外注/依頼/委託方法について

製番管理システムの全体像と向いている企業

製番管理、ロット管理、併用を生産形態ごとに並べた図
仕様の個別性と生産の繰返し方が、管理単位を分ける目安です。

製番管理システムは、注文や製造案件を起点に情報を集める業務システムです。受注時に発番した製番を親キーにして、案件に関わる情報を一つにつなぎます。

個別BOMや図面、手配、作業実績を製番に関連付けます。さらに、検査や外注、出荷、売上、原価も同じ製番でつなぎます。こうしておくと、製番をたどって進捗や使用部品、作業者、仕入先、完成原価まで追跡できます。

製番管理の基本は「番号」ではなく案件の親キー

製番を案件の親キーとして働かせるには、次に挙げる情報と運用を設計しておく必要があります。

  • 製番の関係:親製番と子製番、1受注に複数製番を持つ条件
  • 構成と変更:BOM版数、代替部品、設計変更の適用日
  • 原価と発番:原価を締める時点、発番・取消・再発番の扱い

番号だけの連番では、分納品や再加工部品、共通在庫の材料、複数の子製番を持つ装置のように、案件の形が一つに定まらない場合を表しにくくなります。

また、設計変更の前に発注した部品があるとき、変更後のBOMだけに上書きすると、発注済みの数量と実際の製造状態が分からなくなります。

要件定義の段階では、共通部品をどの製番へ配賦するかも決めておきます。手書きの台帳で管理する場合も、発番元を一本化し、重複や欠番を監査できる状態にしておくと、後工程の照合作業を減らせます。

個別受注生産と量産・ロット管理の使い分け

管理単位は、生産形態と追跡したい情報に応じて選び分けます。

  • 製番管理:仕様が受注ごとに異なる装置、機械、産業設備、受注組立品に向きます。
  • ロット管理:同じ製品を繰り返し作り、原料や完成品をロット単位で管理する業務に合います。
  • 併用:受注生産と量産が混在する企業で、製番とロットを組み合わせる構成を検討します。

案件ごとの図面、納期、部品手配、個別原価を追いたい企業や、保守のときに出荷した個体の部品や検査履歴へ戻りたい企業には、製番管理が適しています。さらに、営業や設計、購買、製造、経理が同じ番号で話せる共通言語にもなります。

食品・化学・医薬品などでは、製番よりも製造ロット、賞味期限、原料ロット、品質検査の関連付けが重要な場合があります。そのため、業務に応じてロット管理やMRPを中心に設計します。

ポイント

自社の生産形態が個別受注か量産かを見極め、製番を親キーにした管理単位で案件を追えるかを、導入を判断する目安にします。

製番管理システムの主な機能と種類

中央の製番から受注設計、手配工程、実績品質、原価出荷へ広がる図
工程ごとの情報が共通の製番を介して結び付きます。

機能の目的は、受注から出荷までを製番でつなぎ、現場の入力と経営の集計が同じ事実を参照できる状態をつくることです。発番は、その起点になる機能です。

導入時は、機能の数よりも、自社の製番フローで必ず扱う情報が標準機能に含まれているかを確かめます。

中核となる製番別BOM・手配・実績・原価

製番別のBOM、手配、実績、原価は、同じ製番でつなぐことで受注から請求までを追えるようになります。その中核機能は、業務の流れに沿って次の4つに分かれます。

  • 受注と設計:案件登録・発番、製番別BOM、図面・仕様書の版管理。
  • 手配と工程:所要量計算、購買・外注手配、工程計画、製造指示。
  • 実績と品質:作業時間・完成実績の登録、検査・不適合の記録。
  • 原価と出荷:製番別原価の集計、出荷・請求との連携。

BOMは数量だけでなく、代替部品や支給品、設計変更日も扱えると、例外をExcelへ逃がさずに済みます。共通部品や子製番については、扱えるかを個別に確かめます。

原価管理では、材料費から経費までを製番ごとに集計し、見積原価と実績原価の差を確かめます。

作業の開始・完了・中断は、スマートフォンやタブレットで記録できます。バーコードやQRコードで製番を呼び出せば、転記ミスも減らせます。ただし、入力項目が多すぎると定着しにくいため、初期導入では納期や数量、不良理由など意思決定に直結する項目から始めます。

クラウド・パッケージ・半完成品・スクラッチの比較

方式によって初期投資や業務への合わせ方が違うため、特徴を並べて比べます。

  • クラウド型:初期投資を抑えやすく、バックアップや更新を自社で抱えにくい方式。
  • 製造業向けパッケージ:BOM、MRP、購買、工程、原価をまとめて整えやすい方式。
  • 半完成品:固有の見積計算や帳票を残しながら、土台の開発量を抑えられる方式。
  • フルスクラッチ:独自工程や設備連携が競争力の中心となる場合の候補。

クラウド型は、複数拠点や外出先から同じ製番を見やすい利点があります。一方で、通信が切れたときの入力、データの置き場所、認証方式は確認が必要です。

また、更新で画面やAPIが変わる場合の影響も確かめます。標準機能に業務を合わせられる企業や、まず受注と進捗の状況を見たい企業に向きます。

フルスクラッチでは、発注側にも要件定義、テスト、保守の要員を継続して確保する必要があります。さらに、製番と原価の中核はパッケージで持ち、現場入力や承認、個別帳票はSaaSやローコードで補う構成も候補になります。

システム同士はAPIやファイル連携でゆるく結び、どのデータを正とするかを決めておきます。変更の頻度と重要度に応じて境界を引くと、全業務を一製品に詰め込むより、長期の保守費用を抑えやすくなります。

製番管理システム開発・導入の進め方

例外業務の整理、代表案件の検証、段階導入の順につなぐ図
現場の例外を含む検証をはさんで、導入範囲を広げます。

導入を成功させるには、製品を選んでデータを移すだけでなく、採番規則やBOM更新の責任者を含む運用ルールを先に決めておく必要があります。実績入力の時点や原価を締めるルールも、同じ段階で決めます。

そのうえで、現場の例外を含む業務で検証します。一括で切り替えるより、代表的な製品群や工場から小さく始め、運用ルールとマスタを整えながら広げるほうが安全です。

▶ 詳細はこちら:製番管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

現状業務と例外パターンの製番単位での整理

見積から請求、アフターサービスまでの業務を、製番が登場する順に描きます。そのうえで、通常の案件とは違うケースも洗い出します。

  • 納期・数量:分納や納期変更。
  • 設計・部品:設計変更、欠品、代替部品。
  • 製造・品質:再加工、不良、外注からの戻り。
  • 在庫:共通在庫からの引き当て。

電話やExcelだけで処理している作業は、担当者への聞き取りと、実際に使っている帳票をもとに確かめます。

品目コードや仕入先、工程、BOM版数などのマスタを一覧にして、部署ごとの違いを洗い出します。特に、部品コードが部署ごとに異なると、導入後も集計が分断されます。

誰が登録と承認を行い、いつ変更を反映するかも決めておきます。そうすれば、画面だけが新しくなり、運用が旧来のままになる失敗を避けられます。

要件定義とPoCによる「通しの一案件」の検証

要件定義とPoCでは、業務要件を固めたうえで、例外を含む案件を検証します。

  1. 要件定義で業務や連携を明文化し、受注から出荷までの検証シナリオを作ります。
  2. PoCでは、簡単な案件より、設計変更や欠品、代替部品、分納、再加工などの代表例を選びます。

要件定義では、発番条件や親子製番、BOM版管理を明文化します。在庫引当から品質履歴までの項目も、文章として残しておきます。

権限や監査ログ、保存期間などに加えて、既存システムとの連携も明文化します。

シナリオでは、発番とBOM展開から、発注・入荷、作業実績・検査を経て、出荷・原価までを順に確かめます。

PoCでは、通信が切れたときのタブレット入力や、複数の製番への部品配賦を確かめます。過去BOMの参照や、原価締め後の訂正履歴も含めて検証します。

デモで操作できた機能と、本稼働時に追加開発が必要な機能は、分けて記録します。

段階導入と並行稼働による現場の停止リスクへの備え

導入範囲と切り替え方法は、段階ごとに決めます。

  1. まず受注、製番、BOM、手配、進捗を稼働させ、次に実績収集や品質、原価、会計・在庫・WMS・CAD・PDMとの連携を追加します。
  2. 全機能を一度に動かす場合でも、リリース単位と責任者を分けて、マスタ移行、教育、受入テスト、障害対応、旧システムへ戻す条件を決めます。

本稼働前には、実データに近い形で受注から出荷までを総合テストします。テストでは、入力漏れや重複発番、権限不足を想定します。在庫のマイナスや予定と実績の差、外部連携の遅延にも備え、判断する人と復旧の方法を決めます。

現場には操作方法だけでなく、製番を登録する理由も伝えます。未登録が原価やトレーサビリティに与える影響を説明すると、定着しやすくなります。

ポイント

例外を含む一案件を通して検証でき、運用ルールとマスタが整っていれば、導入範囲を広げる判断材料になります。検証で見つかった例外が運用ルールで扱えるかも、目安になります。

製番管理システムの費用相場と開発期間

費用は、製番数や利用者数、BOMの複雑さによって変わります。そのほか、拠点数や既存連携、教育の量も影響します。

製番管理だけを対象とした公的な統計価格はありません。そのため、以下は製造業向け業務システムの相場と公開価格を組み合わせた、2026年8月時点の目安です。公開価格は市場平均ではなく、個別見積の起点になるものです。

▶ 詳細はこちら:製番管理システム開発の見積相場や費用/コスト/値段について

方式別の初期費用の幅:数十万円から1億円超

初期費用は、方式やカスタマイズの範囲で変わります。そこで、費用と導入期間を方式別に比べてみます。

  • クラウドSaaS:初期費用0〜60万円程度、導入は即日から数週間が目安です。
  • 製造業向けパッケージ:ライセンス・設定は数十万〜数百万円、製番対応・連携込みで300万〜1,500万円程度の場合があります。
  • 半完成品:個別開発を加える場合は500万〜2,000万円程度です。
  • フルスクラッチ:小規模300万〜1,000万円、中規模1,000万〜5,000万円、大規模5,000万円〜1億円以上を見込む場合があります。

製造業向け生産管理製品の公式料金ページには、製番管理版を含む月額12.4万円からの公開例があります(出典: 製造業向け生産管理製品の公式料金ページ、2026年確認)。

総額は、ユーザー数や導入支援、保守などの条件で変わります。そのため、月額に加えて、5年間の利用料や初期設定から追加開発までの費用を合計して比べます。

見積における開発費以外のTCOの内訳

見積では、初期導入の費用と運用の費用を分けて確認します。

  • 導入時:企画・要件定義、基本設計、画面・帳票、BOM・品目・製番マスタ整備。
  • 移行・稼働準備:API・EDI連携、バーコード端末、データ移行、テスト、教育、並行稼働、保守。
  • 運用時:月額利用料、サーバー、端末、通信、バックアップ、監視、保守、法改正対応、更新検証、マスタ運用、社内工数。

「一式」とだけ書かれていると、標準機能と追加開発の境界が分かりません。製番別原価や設計変更、外注戻り、共通部品の扱いは追加費用になりやすいため、シナリオ単位で確認します。

一般的な業務システムでは、保守運用費を初期費用の年15〜25%程度と見るケースもあります。ただし、契約内容によって異なるため、障害対応や休日対応の時間、データ復旧、追加ユーザー料金を確認します。

開発期間の目安:小規模3か月から大規模2年以上

開発期間は方式と規模で変わります。そこで、方式ごとの目安を並べて確認します。

  • 標準クラウド:設定は即日から数週間が目安です。
  • パッケージ:導入は1〜6か月が目安です。
  • 半完成品:カスタマイズは3〜9か月が目安です。
  • フルスクラッチ:小規模3〜6か月、中規模6〜12か月、大規模12か月〜2年以上が目安です。

期間は、プログラムの量のほかに、要件を決める速さやマスタの品質で変わります。既存連携や、受入テストに使える現場の時間も関係します。

短納期が優先なら、発番から出荷までの基本の流れを先に稼働させ、高度な原価配賦や設備連携は後続の段階に分けます。

後の拡張を見込んで、APIやデータ項目を、権限や履歴まで含めて設計します。特に、製番を単なる文字列として保存しておくと、親子関係や版管理を後から足すときに、大きな移行費がかかります。

ポイント

費用は方式と規模で幅が大きく、契約条件でも変わります。月額だけでなく5年間の総額と、開発期間に影響する要件決定の速さで比べると、判断しやすくなります。

製番管理システムの開発会社・ベンダーの選び方

知名度や機能一覧に加えて、自社に近い生産形態や、製番別原価・設計変更の運用経験を確かめます。実績件数よりも、例外業務の質問に対して、標準機能と設定、追加開発、業務変更を分けて説明できるかを評価します。

実績の見方:業種名でなく製造形態と業務範囲

導入実績は、自社との近さを示す観点で確認します。

  • 生産形態:個別受注、繰返生産、受注組立と量産の混在。
  • 導入範囲:BOM版管理、外注工程、品質、実際原価、会計・在庫連携。
  • 運用実績:入力定着、マスタ更新、追加開発、保守の応答、稼働後の改善。

同規模の利用企業に、切り替え時の困りごとや、使われなくなった機能を聞いてみると、提案書には出にくい運用上のリスクを把握できます。

デモで再現すべき設計変更や欠品の場面

デモでは、一つの案件を通して、設計変更や現場入力、経営集計まで確かめます。

  • 案件の流れ:受注登録、発番、BOM展開、部品手配、入荷、作業実績、検査、出荷、原価集計。
  • BOM変更:旧版・新版、発注済み部品、代替部品をどう扱うか。
  • 分納と端末:同じ製番で追跡し、検索、バーコード読取、取消、通信不安定時の保存、権限表示を試す。
  • 経営集計:予定・実績原価、納期遅延、仕掛、外注費、不良を同じ製番で集計する。

画面の見やすさに加えて、異常が起きたときに履歴をたどり、原因を説明できるかも選定の基準になります。

RFPで比べる連携・セキュリティ・契約後の体制

RFPと提案の確認では、対象範囲から契約後の運用まで、順に確かめます。

  • RFPの範囲:対象拠点、利用者数、製番数、製品群、既存システム、連携方式、移行データ、帳票、テスト範囲、稼働希望日。
  • 見積の質問:BOM版管理の標準対応、実際原価の締め、共通部品の配賦、通信断時の実績登録、API・追加開発費。
  • 工場セキュリティ:ITと設備・OTを含む対策を、提案内容に含めます。
  • 外注取引の法令:製造委託などに関する取引適正化の法令。
  • 電子取引データ:保存要件と、法務・経理との対応方針。

工場と接続する場合は、ネットワークの分離やアカウント管理を確かめます。バックアップやログ監視、脆弱性への対応に加えて、障害が起きたときに操業を続けられるかも見ておきます。

経済産業省は2025年4月、中小規模の製造事業者向けに工場セキュリティ解説書を公表しています(出典: 経済産業省「中小規模の製造事業者向け工場セキュリティ解説書」、2025年)。

外注先との取引記録や、電子的な注文・納品・検査データを製番と関連付ける場合は、法令への対応も要件に含めます。

公正取引委員会によると、取適法は2026年1月1日に施行されました。製造委託などに関する取引適正化の枠組みが変わっています(出典: 公正取引委員会「取適法」、2026年)。

財務省の令和7年度改正関係資料では、電子取引データは一定の要件に従って送受信・保存する必要があると整理されています(出典: 財務省「令和7年度改正関係資料」、2025年)。そのうえで、法務・経理と、保存期間や訂正削除履歴、検索性、権限を確認します。

▶ 詳細はこちら:製番管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら:製番管理システム開発の発注/外注/依頼/委託方法について

ポイント

実績は業種名より自社に近い製造形態で見て、デモでは設計変更や欠品の場面を試し、例外への説明の具体性で比べます。RFPでは、契約後の体制まで同じ条件で並べられるかが目安になります。

導入後に見るべきKPIと失敗しない運用設計

導入効果は、現場や経営の判断がどれだけ早く正確になったかで測ります。そのため、稼働前に基準値を記録しておきます。

製番データから毎月同じ方法で集計できるKPIを決めます。指標を増やしすぎないよう、納期や原価、在庫、品質、入力定着の中から代表的な指標を選びます。

納期・原価・在庫・品質・入力定着の測定

製番データから、導入効果を判断する領域ごとに指標を選びます。

  • 納期:納期遵守率、工程遅延日数、設計変更の現場反映時間。
  • 原価:見積と実績の差、材料費・労務費・外注費、赤字案件の検知。
  • 在庫・品質:仕掛金額、滞留日数、欠品停止、不良率、再加工時間、検査記録の検索時間。
  • 入力定着:実績登録率、入力遅延、重複製番、未紐付け件数。

これらを追えば、単なる在庫台帳では見えない効果も把握できます。登録率が低いときは、項目の多さ、端末の遠さ、通信の不安定さ、マスタ検索の難しさを調べます。

日次の短いレビューで未紐付けを直し、月次でKPIと業務ルールを見直します。

本稼働前に決める運用責任者と変更ルール

データの責任者と変更の流れを決めておき、本稼働後も製番を共通キーとして運用します。

  • 担当範囲:設計はBOM版、購買は仕入先・リードタイム、製造は実績、経理は原価締めを担います。
  • 変更手順:申請、承認、反映、旧版保存を定め、不在時にも処理できるようにします。
  • データの分断防止:図面は共有フォルダ、進捗はExcel、外注実績はメール、原価は月末手計算という状態を避けます。
  • 共通キー:すぐに統合できない場合も製番を共通キーにし、正となるデータの保管先を決めます。

導入範囲の境界をはっきりさせておけば、同じ案件を別々の名前で管理してしまう事態を防げます。

ポイント

導入前に基準値を記録し、納期、原価、在庫、品質、入力定着の指標を毎月同じ方法で追えるかを、運用が続くかの判断の目安にします。

製番管理システムに関するよくある質問

検討の初めには、導入の必要性やExcelからの移行、クラウド利用、費用の考え方がよく尋ねられます。比較の初めに確かめたい質問と判断の軸を紹介します。

製番管理とロット管理は何が違いますか?

製番管理は、個別の注文や製品を識別し、設計や部品、作業、原価を案件単位で追跡します。一方、ロット管理は、同じ条件で生産したまとまりを追跡します。

個別受注生産では製番が基本で、繰返生産や期限・品質の追跡ではロットが基本です。両方が混在する場合は、製番とロットを関連付けます。

Excelで管理していますがシステム化するべきですか?

進捗や部品、設計変更などを複数人で扱い、更新漏れや転記が起きているなら、システム化を検討できます。

Excelの表をそのまま画面にせず、製番や品目、BOM、実績のデータ構造と運用を先に整理します。そのうえで、一つの製品群で発番から出荷まで試し、効果と課題を見て範囲を広げます。

製番管理システムはクラウドでも利用できますか?

クラウドでも利用できます。複数の拠点や外部の設計・購買担当者が、同じ製番を参照しやすい方式です。

通信が切れたときの入力や認証、データの所在を確認します。バックアップや更新の影響も見ておきます。設備・業務ネットワークの分離や外部公開の範囲は、情報システム部門と工場部門の両方で判断します。

費用を抑えるには何から見直せばよいですか?

まず、対象範囲と例外の優先順位を見直します。競争力に直結しない帳票や承認は、標準機能へ寄せます。

失敗したときの影響が大きい領域に、予算を配分します。製番別原価やBOM版管理、現場実績などが該当します。

複数社に同じRFPを渡し、5年間のTCOで比べると、見積の抜けを見つけやすくなります。TCOには初期費用だけでなく、移行や教育、保守、更新検証も含まれます。

まとめ:製番を経営と現場の共通キーにすることが成功の条件

製番管理システムは、番号を発行するための道具にとどまらず、受注ごとに異なるBOMや設計変更、部品手配、工程実績、個別原価などをつなぐ基幹業務の仕組みです。

納期と採算を判断できるようにしつつ、量産やロット管理が中心の業務には無理に当てはめず、個別受注との混在状況に合わせて管理単位を設計します。

導入前に押さえる三つの要点

導入の判断では、製番の設計とシステム方式、検証と運用を一続きに確かめます。

  • 製番の設計:親子関係、BOM版数、代替部品、設計変更、原価締め。
  • 方式の比較:生産形態と変更頻度に応じた、標準・設定・追加開発・業務変更の見極め。
  • 運用の検証:例外を含むPoCの実施と、導入後の納期・原価・在庫・品質・入力定着の測定。

まずは一つの製品群でのRFPと検証シナリオの作成

全社の機能一覧を並べる前に、代表的な案件を選び、受注から出荷・原価確定までの流れを一覧にします。製番や品目、BOMなどの現状データも集めます。

開発会社やベンダーには、同じシナリオで提案とデモを依頼します。判断では、初期費用に加えて5年間のTCOを見ます。さらに、現場入力のしやすさや、変更後の履歴の説明、契約後の保守体制も含めます。

▼関連記事一覧
・製番管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・製番管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・製番管理システム開発の見積相場や費用/コスト/値段について
・製番管理システム開発の発注/外注/依頼/委託方法について

 

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。