ロット管理システム開発の発注/外注/依頼/委託方法について

ロット管理システムの発注・外注は、機能一覧だけでなく、原料の受入から製造、検査、出荷、返品までの履歴をどこまで正確に結び付けるかを先に決めることが成功のポイントです。

この記事では、ロット管理システムを外部へ依頼するときの発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の比較方法、開発後の定着までを、製造現場で起きやすい例外処理を踏まえて解説します。

▼全体ガイドの記事
・ロット管理システム開発の完全ガイド

ロット管理システムを発注する前に知っておきたい全体像

ロット管理システムは、原材料、仕掛品、完成品をロット番号で識別し、入荷・使用・加工・検査・保管・出荷の履歴を一つの流れとして記録する仕組みです。数量だけを管理する在庫システムとは異なり、問題が起きたときに「どの原料が、どの製品に使われ、どこへ出荷されたか」を追跡できることが価値になります。発注時は、画面の数よりもこの履歴のつながりを要件にすることが重要です。

たとえば食品工場で出荷後に品質問題が判明した場合、出荷ロットから使用原料をたどるトレースバックと、原料ロットから影響を受ける製品・納品先をたどるトレースフォワードの両方が必要です。農林水産省は食品トレーサビリティを「食品の移動を把握できること」と説明し、取扱記録を保存することで問題品の遡及と追跡ができるとしています（出典: 農林水産省「トレーサビリティ関係」、2026年1月5日更新）。したがって、発注書にはロット番号の採番だけでなく、検索結果に原料、工程、品質判定、出荷先まで表示することを明記します。

発注前に、原料受入、計量、仕込、加工、検査、倉庫移動、出荷、返品、廃棄のどこを対象にするかを区切ります。対象範囲が曖昧なまま「ロット管理一式」と依頼すると、受入ロットと製造ロットの関係、ロットを分割・混合したときの親子関係、再加工品や保留品の扱いが見積もりから抜けやすくなります。まずは一つの製品を例に、原料ロットがどの工程を通り、何個の出荷ロットに分かれるかを紙に書き出すと、必要なデータと画面が見えてきます。

どの発注形態を選ぶべきですか？

発注形態は、クラウド型SaaS、ロット対応パッケージ、MES・既存基幹との連携、個別開発の順に、標準化と自由度のバランスが変わります。小さく早く始めたいのか、複雑な製造ルールをシステムへ深く組み込みたいのかを整理し、製品の知名度ではなく業務との適合度で選びます。将来の拠点追加や設備連携まで考えると、初期費用だけの比較は危険です。

1拠点で入出庫、ロット照会、期限管理、バーコード入力を始めたい場合は、クラウド型が候補になります。サーバーの購入やOS保守を抑えやすく、月額料金で利用できる一方、ロットの混合、特殊な歩留まり、通信断時の入力、帳票の細かな変更が標準機能にないことがあります。契約前に、解約時のデータ返却形式、バックアップの世代数、障害時の復旧目標、利用できるAPI、ユーザー課金の単位を確認します。

生産計画、購買、在庫、原価、販売まで既存業務を整理したい場合は、ロット対応の生産管理パッケージを検討します。標準機能に業務を合わせれば、スクラッチ開発より短期間で導入しやすいことが利点です。ただし、標準外のアドオンを増やしすぎると、アップデートのたびに改修費が発生し、障害時に製品会社と開発会社の責任分界が不明確になります。標準でできること、設定で変えられること、追加開発になることを提案書上で分けてもらいます。

設備、作業者、治工具、検査値、製造指図をロットとリアルタイムに結び付けるなら、MESや周辺システムの個別開発が候補になります。NTTデータ ニューソンの公開事例では、作業者・材料・装置・工程をMESへ登録し、ICタグと製造ロット付きの電子指図書を照合して作業記録を自動保存しています（出典: 株式会社NTTデータ ニューソン「製品トレーサビリティの一括管理の実現」）。この方式は自由度が高い反面、設備ごとの通信仕様、停止時の復旧、現場教育、データ移行まで発注責任が広がります。最初から全工場を対象にせず、1ラインの実証から始める方法が安全です。

RFPと要件整理はどのように進めますか？

RFPは、開発会社へ希望を伝える資料であると同時に、自社の業務認識をそろえるための設計図です。長い機能一覧を作るより、「何を識別し、どのイベントで記録し、誰が承認し、何分以内に検索したいか」を業務シナリオで書くと、会社ごとの提案を比較しやすくなります。現場の担当者、品質部門、情報システム部門、経理・購買の代表を早い段階から参加させます。

RFPには、入荷ロットの登録、原料の払出、製造ロットの採番、検査結果の入力、保管場所の移動、出荷ロットの確定という正常系を記載します。同時に、ロットの分割、複数ロットの混合、再加工、計量誤差、検査保留、出荷停止、返品、廃棄、訂正入力も必ず書きます。現場では例外が少ないから不要なのではなく、例外が発生したときこそ履歴の信頼性が問われます。各シナリオに「入力者」「承認者」「証跡」「修正方法」「過去データの扱い」を添えると、見積もりの抜けを減らせます。

最低限、ロット番号、品目、数量、単位、製造日、入荷日、賞味期限または使用期限、仕入先、産地、保管条件、品質判定、在庫ステータスを検討します。製造業では、材料、人、機械、方法、測定という5Mの情報をどこまで残すかも重要です。品質問題の原因を調べる際に、材料ロットだけ分かっても、使用設備や作業者、検査値が分からなければ再発防止へつながりません。入力項目を増やしすぎると現場が入力しなくなるため、事故対応に不可欠な項目と、分析用の項目を分けます。

生産管理、ERP、販売管理、WMS、品質管理、会計、計量器、バーコード端末、設備など、どのシステムを正とするかを決めます。連携方式はAPI、CSV、EDIなどの候補を書き、連携頻度、エラー時の再送、重複登録の防止、通信断時の扱いまで要件にします。工場をクラウドや外部ネットワークへ接続する場合は、経済産業省が2025年4月に中小規模の製造事業者向けにも工場セキュリティの手順・事例を公表しているため、ネットワーク分離、アカウント権限、ログ保存、バックアップ、脆弱性対応の役割を発注先へ確認します（出典: 経済産業省「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Appendix」、2025年4月）。既存データの移行件数や文字コード、マスタの重複も見積もり条件に入れます。

契約形態は請負と準委任のどちらを選びますか？

契約形態は、完成させる成果物と、業務を一緒に整理するプロセスのどちらを重く見るかで選びます。ロット管理では、発注時点で現場の例外や既存データの品質が分からないことも多いため、要件定義と開発を同じ条件で固定するより、フェーズごとに契約を分ける方法が現実的です。契約書では名称だけで判断せず、成果物、検収基準、変更手続き、責任分界、知的財産、再委託、保守を具体化します。

請負契約では、受託者が合意したシステムを完成させ、発注者が検収する流れを作ります。要件、画面、帳票、連携、性能、テスト結果などの成果物が定義できる場合に適しています。検収条件は「動くこと」ではなく、たとえば指定した原料ロットから対象出荷先を検索できること、ロット分割後も親子関係を辿れること、権限のない利用者が履歴を変更できないことのように、業務シナリオで書きます。未確定要件を請負の固定価格へ押し込むと、後から変更費用や納期遅延が発生しやすくなります。

準委任契約は、要件定義、現場調査、プロトタイプ、移行計画、プロジェクト管理など、専門家が一定の業務を遂行することを委託する形態です。発注者と受託者が現場を見ながら仕様を固める段階に向いています。一方で、完成責任や稼働保証が自動的に得られるわけではないため、会議体、報告内容、作業時間、意思決定者、成果物の扱いを別途合意します。要件定義を準委任で行い、確定した開発範囲を請負へ移す二段階契約も選択肢になります。

ロット管理システムでは、現場テストで新しい例外が見つかることがあります。その場合に、どこまでが瑕疵修正で、どこからが追加開発かを決めておかないと、発注者と受託者の関係が悪化します。受入テストの期間、重大障害の判定、修正期限、データ復旧の責任、第三者製品の不具合、クラウド停止時の対応、保守時間外の費用を契約書と仕様書へ分けて記載します。月額保守は、問い合わせ対応だけか、法改正対応・脆弱性修正・軽微な機能変更まで含むかで価値が変わります。

ロット管理システムの費用相場と見積の内訳

ロット管理システムの費用は、利用方式、拠点数、ユーザー数、対象工程、端末台数、設備・ERP連携、データ移行、帳票、品質・監査要件で大きく変わります。ロット管理専用の公的な市場統計は限られるため、以下は公開価格のある生産管理・ERP・MESと、製造業向けシステムの調査レンジを組み合わせた目安です。特定の金額をそのまま自社の総額と考えず、見積もりの前提条件と範囲をそろえて比較します。

1拠点で標準的な入出庫とロット照会を始めるクラウド型は、初期設定が0円から数十万円、月額が1万円台から15万円程度となる例があります。ロット対応パッケージを生産・在庫・原価まで広げる場合は、初期設定やライセンスを含めて数百万円から1,000万円程度、設備や複数システムとの連携を含むMESは500万円から5,000万円程度が目安になります。多拠点の個別開発や基幹刷新では1,000万円から5,000万円超となる場合があり、全社統合ではさらに大きくなる可能性があります。これらは公開価格と製造業向け案件のレンジから整理した推定であり、要件によって上下します。

公開価格の例では、NECのFactory-ONE 電脳工場が販売管理ベースで月額3.6万円から、MRP版・製番管理版で月額12.4万円から、ハイブリット版で月額14.6万円からと案内しています（出典: NEC「Factory-ONE 電脳工場 価格」、確認時点2026年8月）。これはライセンスの目安であり、導入支援、マスタ整備、端末、連携、移行、教育は別途見積もりです。またVanCreworthのGENでは、2026年4月1日時点の例として、10ユーザー、LOT、サブスク管理、標準サポートを含む月額税別95,450円を掲載しています（出典: 株式会社VanCreworth「製品詳細」）。公開価格は安さのランキングではなく、何が含まれ、何が別料金かを読むために使います。

見積書は、要件定義、現場調査、基本設計、詳細設計、画面・帳票開発、API・CSV連携、バーコードやRFID連携、テスト、データ移行、教育、本番移行、プロジェクト管理に分けてもらいます。特に工数が膨らみやすいのは、既存データの名寄せ、設備ごとの通信確認、ロット分割・混合、複数拠点の在庫引当、履歴訂正、監査ログ、権限設計です。稼働後は、初期開発費の年15〜25％程度を保守予算の目安として置き、OSやブラウザ更新、脆弱性対応、制度変更、端末交換、マスタ変更を含むか確認します。相場のレンジだけでなく、前提と除外項目を比較することが大切です。

委託先の選定と見積比較で確認すべきポイント

委託先は、会社規模や知名度だけで決めず、ロットの粒度、業種、連携範囲、現場への導入力を軸に比較します。食品なら衛生記録・出荷判定・回収、医薬品なら品質と監査、化学品なら保管条件や法令、部品なら製番・設備・検査との関係が異なります。候補会社には同業・同規模の実績だけでなく、ロット分割や混合を含むデモ、稼働後のサポート体制、担当者の経験を確認します。

「製造業で多数の実績」という説明だけでは足りません。原料ロットから製品ロットを追うのか、製品から出荷先を追うのか、ロットを分割・統合するのか、検査値や設備情報を保存するのかを聞きます。日立のFactRiSM導入事例では、紙の記録を電子化し、トレースバックとトレースフォワードによる原因究明や波及範囲の絞り込みを迅速化したと説明されています（出典: 株式会社日立製作所「統合製造実行管理システムFactRiSM 提案・導入事例」）。自社と似た業務シナリオを、導入前の課題、対応方法、稼働後の運用まで説明できる会社を評価します。

相見積もりでは、同じRFPを渡し、対象拠点、ユーザー数、端末数、履歴保存年数、連携先、移行データ量、テスト範囲、教育回数、保守時間をそろえます。そのうえで、各社の見積を「必須」「提案」「オプション」「対象外」に分けます。極端に安い見積は、要件定義や移行、例外テスト、管理工数が含まれていない可能性があります。逆に高い見積でも、セキュリティ、監査、障害対応、現場教育まで含んでいれば、単純な価格差とはいえません。

デモで見るべきなのは、きれいなサンプルデータの登録画面だけではありません。入荷ロットを二つに分け、一方を複数の製品へ使い、検査保留を解除し、返品後に再出荷する流れを実演してもらいます。さらに、バーコードの読み取り失敗、通信断、重複送信、誤入力の訂正、権限のない利用者の検索、監査ログの確認も質問します。開発会社がその場で回答できない場合でも、調査事項と回答期限を記録し、提案力と誠実さを見極めます。

発注後の開発を失敗させない進め方

発注先が決まった後は、開発会社に任せきりにせず、発注者側の意思決定を止めないことが大切です。ロット管理は業務部門ごとに正解が異なるため、プロジェクト責任者、現場代表、品質責任者、情報システム担当を決め、仕様変更と優先順位の判断を一か所へ集めます。会議では進捗率だけでなく、未決定の業務ルール、移行データの課題、テスト消化率、現場の利用状況を確認します。

いきなり全拠点を切り替えるのではなく、製品数と例外が把握しやすいラインや拠点を選びます。パイロットでは、ロット登録完了率、紙やExcelへの戻り件数、トレース検索にかかる時間、棚卸差異、入力エラー、回収対象を特定するまでの時間を測定します。目標値は開発会社が決めるのではなく、現場と品質部門が決めます。結果が悪ければ、機能を追加する前に、入力項目が多すぎないか、端末の位置や通信が適切か、作業手順が分かりにくくないかを見直します。

テストは画面の操作確認だけで終わらせません。旧システムやExcelから移したロットの件数、数量、日付、期限、在庫状態が一致するかを検証し、移行前後でトレース結果が変わらないことを確認します。現場の実データに近い形で、ロットの分割、混合、再加工、検査不合格、保留解除、返品、廃棄、月またぎの在庫をテストします。出荷や製造を止められない場合は、切り替え日、並行稼働期間、紙の代替手順、障害時の復旧手順を文書化してから本番へ進みます。

稼働後にロット番号の重複や品目マスタの表記揺れが起きると、検索の信頼性が下がります。採番ルール、品目・仕入先・保管場所の登録権限、期限変更の承認、訂正入力の理由、月次の棚卸確認、ログの保管期間を運用手順にします。新しい製品や工程を追加するときの申請窓口を決め、現場からの改善要望を優先順位付けします。システムは納品時に完成するのではなく、正しい履歴が日々残る状態になって初めて成果が出ます。

よくある質問

ロット管理システムの発注では、費用だけでなく、既存業務との適合、履歴の正確性、現場での入力しやすさを確認する必要があります。ここでは、外注を検討する企業から特に相談されやすい質問に回答します。

標準的なクラウド型なら初期0円から数十万円、月額1万円台から15万円程度の例がありますが、設備連携や品質・監査機能を含むと数百万円から数千万円の導入費になることがあります。個別開発や大規模連携では、要件定義、移行、テスト、教育、保守まで含めて見積もる必要があります。公開価格は製品利用料の例であり、自社の総額を示すものではありません。

標準的な入出庫や在庫、ロット照会が中心なら、パッケージやSaaSを優先すると導入期間と保守負担を抑えやすいです。独自の配合、複雑なロット分割・混合、設備からの自動収集、顧客向け証明書などが競争力に直結する場合は、パッケージ連携や個別開発を検討します。全機能をスクラッチにする前に、標準機能、設定、周辺アプリ、個別開発の順に切り分けることが安全です。

対象工程、ロットの採番・分割・混合ルール、必要な履歴項目、トレースバックとトレースフォワードの検索条件、利用者と権限、端末、既存システム連携、移行データ、テスト、教育、稼働時期を書きます。正常系だけでなく、返品、廃棄、検査保留、通信断、誤入力の訂正も含めます。各社へ同じ条件を渡し、「標準」「設定」「追加開発」「対象外」を分けて回答してもらうと、価格と提案内容を公平に比較できます。

検収条件、追加開発の扱い、障害対応の時間、データの所有権と返却、再委託先、保守範囲、脆弱性対応、バックアップと復旧、製品終了時の移行支援を確認します。特にクラウド型では、解約後にロット履歴をどの形式で受け取れるかを確かめます。発注者側にも、業務ルールを決める責任者と、受入テストへ参加する現場メンバーを置くことが必要です。

まとめ

ロット管理システムの発注・外注では、最初に「どのロットを、どの工程で、どの粒度で、誰が記録するか」を決めます。そのうえで、SaaS、パッケージ、MES連携、個別開発を比較し、RFPへ正常系と例外系、既存システムとの境界、移行、セキュリティ、保守を盛り込みます。費用は公開価格や一般的な製造業向け相場を参考にできますが、総額は要件と前提条件で変わるため、同じ条件の相見積もりで確認します。

発注前は、(1)回収や問い合わせ時に何分で影響範囲を特定したいか、(2)原料・仕掛品・完成品のどこまでロットを持つか、(3)分割・混合・返品・廃棄をどう扱うか、(4)現場の入力端末と通信をどうするか、(5)どのデータを何年保存するか、(6)誰が検収し、稼働後に誰がマスタを管理するかを決めます。これらが決まるほど、見積もりは比較可能になり、開発会社との認識違いも減ります。

いきなり全社の要件を完成させようとせず、代表的な1製品について、入荷ロットから出荷先までの流れと例外を整理し、候補会社へ相談するところから始めます。現場観察とRFP作成を支援でき、導入後の教育や改善まで伴走できる委託先なら、単なるシステム納品ではなく、ロット履歴が実際に使われる運用を作りやすくなります。

▼全体ガイドの記事
・ロット管理システム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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