化粧品製造業向けロットトレーサビリティシステム開発の発注/外注/依頼/委託方法について

化粧品製造業向けロットトレーサビリティシステムの発注は、原料ロットから配合・充填・包装・出荷先までを正逆方向に追跡できる要件を定め、標準機能と個別開発の範囲を分けて委託先を比較することが成功の近道です。

化粧品OEM・ODMの現場では、得意先ごとに処方や包材、検査項目が変わり、紙・Excel・既存ERP・秤量器の情報が分散しやすいです。そのため「ロット番号を画面で見られるか」だけでなく、問題のある原料がどの製品と出荷先に影響したか、回収対象をどこまで絞れるか、稼働後に誰が保守するかまで含めて発注条件を整理する必要があります。本記事では、パッケージ、クラウド、ローコード、スクラッチ開発の選び方から、RFP、契約、費用相場、見積比較、発注後の検収までを発注担当者の視点で解説します。

▼全体ガイドの記事
・化粧品製造業向けロットトレーサビリティシステム開発の完全ガイド

化粧品製造業向けロットトレーサビリティシステムの発注で決めること

発注前に決めるべきことは、システムの機能一覧だけではありません。どの製造イベントを正本として記録するか、どこまでを標準機能に合わせるか、既存の基幹システムや現場機器とどの方式で接続するかを決めることが重要です。

最低限、原料・包材の入荷ロット、受入検査、保管場所、秤量実績、配合、バルクや半製品、充填・包装、完成品ロット、出荷先を一つの履歴としてつなげます。完成品ロットから使用した原料へ戻る「正展開」と、原料ロットから影響を受ける製品・出荷先へ進む「逆展開」の両方が必要です。再秤量、仕掛品の戻し、廃棄、返品、ラベル再発行も対象に含めるかを発注仕様に書いておくと、後から追加開発になりにくいです。

たとえば原料ロットAがバルクロットBとCに分かれ、Bが完成品P・Qに、Cが完成品Rに使われた場合を想定します。原料Aの不具合が判明したとき、P・Q・Rの製造数と出荷先を数分で抽出できる設計なら、回収範囲を確認しやすくなります。単なる在庫数量の管理では、この変換関係を再現できないため注意が必要です。

化粧品では、品目・処方・成分・規格・有効期限・得意先別の包材や表示を管理する必要があります。製造指図に対する秤量量の許容差、投入した原料の実績、工程中の検査結果、承認者、使用設備、作業者をひも付けると、品質保証部門が後から証跡を確認しやすいです。GMP関連の記録や出荷判定を紙で残す場合でも、システム上のロット履歴と対応関係を明確にします。

厚生労働省が公表した令和6年度の医薬品等自主回収一覧には、化粧品の成分表示の誤りを理由として対象ロットを自主回収する事例が掲載されています（出典: 厚生労働省「令和6年度医薬品等自主回収一覧（クラスII）」、2025年公表）。発注時には効率化だけを訴求せず、ロットの特定、出荷履歴、回収判断、原因調査を支える品質保証基盤として要件を作ることが大切です。

「トレーサビリティを強化する」という目的は、そのままでは見積比較に使いにくいです。たとえば、原料から出荷先までの追跡に要する時間、棚卸差異、手入力回数、秤量・投入ミス、回収対象の特定時間、製造記録の承認待ち時間などに分解します。現状値を計測できていない場合は、発注前の1週間だけでもサンプル製品を選び、担当者が何分かけて履歴を探しているかを記録します。

発注形態はパッケージ・クラウド・スクラッチからどう選びますか？

発注形態の結論は、標準化できる業務が多いほどパッケージやクラウドが向き、化粧品特有の多段階配合・設備連携・拠点ルールが競争力に直結するほどスクラッチや大規模な個別開発が候補になるということです。ただし、最初から方式を固定せず、現場業務を分解して「標準機能で合わせる部分」と「差別化のために作る部分」を分けて評価します。

パッケージは、生産計画、在庫、ロット、原価、品質などの基本機能を短期間で利用しやすい方式です。発注時には機能数の多さより、原料ロットから製品ロットへの正逆展開、処方・配合マスターの版管理、品質検査、期限管理、出荷判定が標準でつながるかを確認します。標準機能に業務を寄せるFit to Standardが可能なら、アドオンの保守負担を抑えやすいです。

一方で、得意先別の処方、特殊なOEM受注、再加工、仮想在庫、独自帳票をすべて追加すると、パッケージの更新時に影響調査が必要になります。デモの段階で「標準」「設定変更」「追加開発」「対象外」を機能ごとに表示してもらい、導入費だけでなく3年程度の保守・アップデート費も比較します。

クラウド型は、サーバーを自社で用意せず、在庫・ロット管理など必要な機能から段階導入しやすい点が特徴です。ネクスタのSmartF公式サイトでは、初期費用50万円から、月額5万円からの価格を掲げ、必要な機能やライセンス数で料金が変動すると説明しています（出典: 株式会社ネクスタ「生産管理クラウドシステムSmartF」公式サイト、2025〜2026年確認）。これは標準機能を使う場合の公開価格であり、化粧品固有の処方、データ移行、秤量器、ラベルプリンター、個別帳票の費用を含むとは限りません。

クラウドを発注するときは、月額料金だけでなく、APIの利用範囲、データ保管場所、バックアップ世代、障害時の現場継続、通信断時の入力、解約時のデータ返却、ベンダーのリモート保守方法を確認します。計量器や製造設備を接続する場合は、クラウドと工場内ゲートウェイを組み合わせる構成も候補にし、工場ネットワークをどこまで開放するのかを要件化します。

設備や計量器とのリアルタイム連携、複数段階の配合、拠点ごとのOEMルール、既存ERP・WMS・LIMSとの複雑なデータ連携がある場合は、個別開発が必要になることがあります。ただし、初回から全工場・全機能を作るのではなく、1ラインまたは1工場で、ロット照会、原料投入照合、出荷先抽出、回収帳票のように効果を測りやすい領域をMVPにします。

MVPで重要なのは画面の見栄えではなく、ロット親子関係と在庫イベントが正確に蓄積されることです。将来の製品・原料・配合・検査マスターをどのシステムが正本として持つか、APIやETLでどの粒度を連携するかを先に決めます。小さく始める場合でも、後から多拠点へ広げられるデータモデルと権限設計を契約成果物に含めます。

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

RFPは、欲しい画面を並べる資料ではなく、製造現場の事実と発注後の評価方法をそろえる資料です。現状業務、対象範囲、機能要件、非機能要件、連携条件、移行データ、導入体制、見積フォーマット、選定スケジュールを同じ書式で提示すると、ベンダーごとの前提差を比較しやすくなります。

原料入荷、受入検査、保管、払出、秤量、配合、熟成、バルク、充填、包装、最終検査、出荷、返品、回収の順に、誰が、いつ、何を、どの端末で記録するかを書き出します。標準フローだけでなく、原料の分割・混合、再秤量、投入量が許容差を超えた場合、仕掛品を戻す場合、廃棄やラベル再発行の場合も記載します。

各工程では「必須入力」「自動取得」「承認が必要な項目」「後から訂正できる条件」を分けます。たとえば秤量器の実績を自動取得するなら、端末番号、時刻、作業者、原料ロット、許容差、通信エラー時の扱いまで決めます。こうした現場シナリオをRFPに入れると、機能一覧だけでは分からない実装難度を見積書へ反映しやすいです。

機能要件には、原料・資材・製品のロット別入出庫、期限、在庫移動、配合・成分・BOM、製造指図、秤量・投入、工程実績、検査、承認、出荷、返品、廃棄、回収を含めます。特に「製品ロットから使用原料を追跡する」「原料ロットから影響製品と出荷先を追跡する」「影響数量を集計する」「帳票を出力する」という四つを、実データに近いサンプルで検証できるようにします。

非機能要件には、利用者数、同時接続数、応答時間、バックアップ頻度、復旧目標、監査ログの保存期間、権限分離、暗号化、時刻同期、脆弱性対応、障害時の代替運用を入れます。2025年4月に経済産業省が中小規模の製造事業者向け工場セキュリティ解説書を公表しているため、クラウドやIoTを含む場合は、アカウント管理だけでなく工場ネットワークのゾーン分離、遠隔保守、端末資産管理、復旧訓練も確認項目にします。根拠は経済産業省「中小規模の製造事業者向け工場セキュリティ解説書」（2025年）に示されています。

RFPでは、対象工場数、製品・原料・包材の件数、月間製造ロット数、利用者・端末台数、既存システム、連携機器、移行対象年数、帳票数、教育対象人数、稼働希望時期を分かる範囲で提示します。件数が未確定なら、少・中・多の三つの前提を示し、それぞれの追加費用を見積もってもらいます。

また、見積書を「要件定義」「設定」「個別開発」「連携」「データクレンジング・移行」「テスト」「教育」「本番切替」「保守」「機器」に分けるよう指定します。総額だけを比較すると、安い見積にテストや移行が含まれていないことがあります。提案書には、対象外、顧客側の作業、追加費用が発生する条件、想定リスク、導入後の体制も書いてもらいます。

契約形態と発注プロセスはどう設計しますか？

化粧品工場のシステム発注では、要件が固まる前の調査・企画と、仕様に基づく開発・導入を同じ契約に詰め込まないことが安全です。まず現状調査やRFP作成支援を委託し、その成果をもとに製品選定・要件定義を行い、開発と導入の契約へ進む段階方式にすると、発注者が比較・修正できる余地を残せます。

現状調査、業務整理、RFP作成支援、製品比較、要件定義の初期段階は、作業時間や体制を定める準委任契約が使われやすい領域です。業務の複雑さや既存データの品質を確認する前に、完全な成果物と固定価格を約束すると、前提変更が追加請求や品質低下につながることがあります。

準委任で発注する場合は、月次の作業報告だけでなく、業務フロー、課題一覧、決定事項、未決事項、要件候補、データ項目一覧、次工程の見積前提を成果物として定義します。担当者の稼働を買う契約でも、次の意思決定に使える記録が残るようにすることが重要です。

仕様が固まった開発、画面・API・帳票の実装、データ移行ツール、テスト計画書などは、請負契約で成果物と検収条件を明確にする方法が考えられます。請負だからといって「納品したら終わり」にせず、正逆トレース、秤量許容差、権限、監査ログ、通信断、ラベル再発行、回収シナリオを受入テストに含めます。

契約書や個別契約書には、仕様変更の定義、追加見積の手続き、著作権・利用権、第三者ソフトウェア、データの所有権、秘密保持、再委託、障害時の責任分界、瑕疵対応、保守のサービスレベルを記載します。製造現場の要望を止めるのではなく、変更要求を一覧化して、費用と納期への影響を双方が承認してから反映する運用にします。

発注プロセスは、現状調査、RFP配布、提案・デモ、候補絞り込み、要件定義、契約、設計・開発、移行リハーサル、受入テスト、教育、並行稼働、本番切替、安定化の順に分けます。各段階の終了条件と、次段階へ進まない場合の中止・見直し条件を決めておくと、問題を抱えたまま全額を投資するリスクを下げられます。

選定委員会には、情報システム、製造、品質保証、倉庫、購買、経理、現場の代表を含めます。特定部署だけで決めると、現場端末や承認手順が実運用に合わないことがあります。発注者側のプロジェクト責任者、業務側の決裁者、データ移行の責任者、ベンダー窓口を明確にし、会議体とエスカレーション経路も契約前に確認します。

化粧品向けロットトレーサビリティシステムの費用相場と内訳

2026年時点で、化粧品向け専用システムの価格を一律に示せる相場はありません。費用は、対象工場・製品・原料の数、ロットの分割や混合の複雑さ、端末・秤量器・ラベル機器、既存ERPやWMS・LIMSとの連携、データ移行、品質保証の記録要件で大きく変わります。以下は企画段階で比較するためのレンジであり、正式見積ではありません。

汎用クラウドを在庫・ロット中心で小さく導入する場合は、初期30万〜100万円、月額5万〜20万円程度が企画上の比較レンジになります。化粧品向けクラウドやパッケージを設定し、処方・品質・期限を追加する場合は、初期100万〜500万円、月額5万〜30万円または年額保守を目安にします。SmartF公式の初期50万円から、月額5万円からという公開価格は、このうち標準機能を段階導入する場合の実例です。

1工場のロット追跡MVPで、バーコード、秤量器、ERPの一部連携、データ移行、教育、テストまで含める場合は、800万〜2,000万円程度が一つの推定レンジになります。1〜数工場で生産・品質・在庫・出荷を統合する場合は2,000万〜5,000万円程度、複数拠点でMES・WMS・LIMS・設備連携まで含むスクラッチ開発では5,000万円〜1億円以上になる可能性があります。いずれも機能と件数の前提を置いた推定で、特定金額を保証するものではありません。

製造業向けシステムの推定では、PMの人月単価を90万〜150万円、SEを65万〜110万円、PGを50万〜90万円程度とするレンジがあります（出典: NotebookLM Q&A「生産・製造」費用相場整理、2026年確認）。この単価だけで総額を決めず、要件定義、基本設計、実装、連携、テスト、教育、移行に誰が何人月関わるかを確認します。

目安として、総額の60〜80％が人件費になりやすく、要件定義が10〜12％、設計・環境構築が22〜24％、実装が48〜50％、テストが15〜17％程度という配分で見積を読む方法があります（出典: NotebookLM Q&A「生産・製造」費用相場整理、2026年確認）。化粧品向けでは、連携仕様の確認、マスター整備、回収シナリオのテスト、現場教育が増えやすいため、実装費だけが大きい見積は内容を細かく確認します。

初期費用のほかに、クラウド利用料、ユーザー・端末ライセンス、保守、バックアップ、監視、問い合わせ対応、法令・脆弱性対応、機器の保守、通信費、データ保存、追加帳票、拠点追加の費用が発生します。パッケージやスクラッチでは、年間保守を初期費用の15〜25％程度と推定するケースもありますが、サポート時間や対象範囲で変わるため、見積書の条件を確認します。

見積比較では、3年総額または5年総額で、初期構築、月額・年額、機器更新、追加ユーザー、データ移行、教育、制度変更対応、障害対応を並べます。特に「保守費に軽微な改修が含まれるか」「新しいOSやブラウザへの対応は誰が行うか」「現場停止を伴う更新の責任者は誰か」を質問します。安い初期費用が、運用開始後の個別請求によって高くなる場合もあるためです。

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

委託先は、製造業の導入実績があるという理由だけで決めず、化粧品の配合・成分・期限・品質・OEM運用をどこまで理解しているかを確認します。提案書の機能一覧よりも、サンプルデータを使った正逆トレースのデモ、異常系の対応、機器連携、移行・教育の計画を比較すると、発注後の実現性が見えやすくなります。

実績確認では、会社名や導入社数だけでなく、原料入荷からバルク、充填、包装、出荷までを対象にしたか、配合や成分の版管理があるか、秤量器やハンディ端末と接続したか、回収・監査の帳票を使っているかを聞きます。可能であれば、同じ規模・同じOEM形態の顧客に、導入期間、追加開発、現場教育、稼働後の問い合わせ、期待と違った点を確認します。

公開事例では、内田洋行のコスメサイエンス導入事例が、販売・購買・品質・生産・原価・在庫を対象にし、秤量機・入出庫管理システムと連携したと紹介しています（出典: 株式会社内田洋行「化粧品OEMメーカー コスメサイエンス導入事例」、2026年確認）。また、システムエグゼのKolmar Vietnam事例では、最小限の標準機能で始め、将来のカスタマイズと多言語操作を評価したと説明されています（出典: 株式会社システムエグゼ「Kolmar VietnamにおけるEXEX生産管理の導入事例」、2024年公開）。このような事例を、自社の工場・拠点・データ条件に置き換えて質問します。

候補企業には、原料ロットAが製品ロットP・Qへ使われ、Pの一部が出荷先X・Yへ出荷されたというサンプルを渡します。そのうえで、Pから使用原料をたどる、Aから影響製品をたどる、影響数量を集計する、出荷先別の回収リストを出すという操作を実演してもらいます。操作回数、検索結果の根拠、帳票の出力、権限の違い、履歴の訂正方法を記録します。

次に、通信断、重複ロット、秤量許容差超過、原料期限切れ、ラベル再発行、仕掛品戻し、廃棄、承認前の出荷を想定します。正常系だけなら使いやすく見えても、製造現場の例外処理が紙や担当者の判断に残ることがあります。ベンダーが未対応の場合は、追加開発の費用・期間・保守への影響を提案書に明記してもらいます。

見積比較表には、要件定義、画面・帳票、マスター、ロット・在庫、配合・品質、バーコード、計量器、ラベル、ERP・WMS・LIMS連携、権限・監査ログ、移行、テスト、教育、切替、保守を行ごとに並べます。各行には、標準・設定・追加開発・対象外、担当者、前提件数、納期、検収方法を記載します。

特にデータ移行は、抽出、変換、重複排除、コード統一、期限やロットの欠損確認、移行リハーサル、本番移行後の照合まで含むかを確認します。Excelの品目コードやロット表記が統一されていない場合、移行作業が想定以上に増えます。発注者側がデータを用意する契約でも、クレンジングのルールと受入条件は共同で定めます。

価格が最も低い会社を選ぶのではなく、同じ範囲で比較できる状態にしたうえで、総額、納期、リスク、保守性、現場定着を総合評価します。たとえば見積額が低くても、回収シナリオのテスト、機器接続、教育、障害時の代替運用が対象外なら、稼働後に追加費用や品質リスクが発生します。

発注後に起こりやすい失敗と対策

ロットトレーサビリティの導入は、システム会社に任せれば完了するものではありません。現場の入力、マスターの責任者、品質保証の承認、既存システムの正本、稼働停止の許容時間を発注者側が決める必要があります。発注前に、起きやすい失敗をプロジェクト計画へ織り込みます。

現行台帳をそのままシステムへ移せば短期導入できるとは限りません。同じ原料に複数のコードがある、ロット番号の表記が工程ごとに違う、仕掛品と完成品の区別がない、期限や廃棄理由が欠けているといった状態では、追跡結果の信頼性が下がります。発注前に代表的な製品と原料を抽出し、移行できないデータ、補正が必要なデータ、廃棄するデータを分類します。

データクレンジングの責任をベンダーだけに置くと、業務上の意味を誤る可能性があります。品質保証、製造、倉庫、情報システムがコード体系と履歴の正しさを確認し、ベンダーは変換ツールと検証結果を提出する分担が適しています。移行リハーサルで、移行前後の在庫数量とロット件数が一致するかを確認します。

単体テストや画面確認だけでは、ロット履歴の欠落を発見できません。原料受入から出荷までの総合テストを行い、実際に使うラベル、端末、秤量器、既存システムのデータを接続します。通信が途切れた場合、重複送信が起きた場合、検査不合格の原料が払出された場合に、どの担当者がどう復旧するかも試します。

稼働前には、品質保証部門と現場が参加する回収訓練を実施します。原料ロットを一つ選び、影響製品、在庫、出荷先、数量、未出荷品、回収連絡対象を抽出するまでの時間を測ります。教育では操作説明だけでなく、ロットを誤入力した場合の訂正、ラベル再発行、障害時の紙運用からの復旧、承認者の交代を扱います。

複数工場を同時に切り替えると、問題の原因がシステム、マスター、教育、連携のどこにあるか分かりにくくなります。最初は1ラインや1工場で、対象製品と利用者を限定し、追跡時間、棚卸差異、入力ミス、秤量エラー、回収対象の特定時間を導入前後で比較します。KPIが改善し、現場が運用できることを確認してから対象を広げます。

段階展開では、共通マスター、ロット番号の採番、権限、API、帳票の標準を先に定めます。工場ごとの独自運用をすべて別仕様にすると、保守が複雑になります。現場で変えるべき業務と、システムで統一すべきデータを分け、追加開発の判断基準を運用会議で維持します。

よくある質問（FAQ）

発注前に多い疑問を、費用、導入範囲、委託先選びの観点からまとめます。自社の工場条件や既存システムによって答えが変わるため、回答をそのまま仕様にせず、RFPの確認項目に置き換えてください。

標準機能を使うクラウドの小規模導入なら、公開価格として初期30万〜100万円、月額5万〜20万円程度が比較の起点になります。化粧品固有の配合・品質・機器連携・移行・教育を含む1工場MVPは800万〜2,000万円程度、複数工場の統合は2,000万〜5,000万円程度を企画上の推定レンジとしますが、正式な金額は要件と件数で変わります。

在庫・ロット・検査など標準化しやすい領域から始めるならクラウドやパッケージが候補です。多段階配合、特殊なOEMルール、設備のリアルタイム連携、複数拠点の統合が競争力に直結する場合はスクラッチや個別開発を検討しますが、最初から全範囲を作らず、1工場のMVPでデータモデルと現場定着を検証する方法が適しています。

化粧品OEMや類似するプロセス製造の実績、正逆トレース、配合・成分、品質検査、秤量器・ラベル機器、ERP・WMS・LIMS連携の実績を確認します。候補を同じサンプルデータでデモさせ、通信断、許容差超過、返品、ラベル再発行、出荷後の回収まで説明できるかを比較し、導入後の保守窓口、再委託、データ所有権、追加費用の条件も契約前に確認します。

一括委託は窓口をまとめやすい一方、発注者が要件や見積前提を検証しにくい場合があります。現状調査・RFP作成・製品選定を準委任で切り出し、要件と成果物を確認してから開発請負へ進む段階方式にすると、契約上の責任と意思決定を分けやすいです。一括にする場合でも、フェーズごとの成果物、検収、変更管理、解約・中止条件を明記します。

まとめ

化粧品製造業向けロットトレーサビリティシステムを発注するときは、まず原料・包材の入荷から配合、バルク、充填、包装、出荷、返品・回収までの履歴を定義します。そのうえで、パッケージ・クラウド・ローコード・スクラッチの標準範囲と個別開発範囲を分け、RFPに現場の例外処理、連携、移行、テスト、教育、保守まで記載します。

最終的には、正展開・逆展開ができること、処方・成分・期限・品質記録を扱えること、秤量器や既存システムと接続できること、通信断や回収に対応できることを確認します。見積書は初期費用だけでなく、データクレンジング、端末・機器、教育、テスト、保守、将来の拠点追加まで含めて比較します。検収条件には、実際の製造データに近い回収シナリオを必ず入れます。

複数社の提案を比べるときは、会社の知名度や最安値だけでなく、化粧品の製造イベントと自社の例外処理を理解しているか、現場と品質保証が使い続けられるかを評価します。1ライン・1工場のMVP、移行リハーサル、並行稼働、回収訓練を経て、追跡時間や入力ミスなどのKPIを確認し、次の拠点や機能へ展開する進め方が現実的です。

発注の目的はシステムを納品してもらうことではなく、必要なロット履歴を正確に残し、品質保証と現場判断を速くすることです。自社の製品・原料・設備・拠点条件を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を創業。