SKU管理システムの開発は、商品バリエーションごとの在庫を正しく定義し、要件整理から定着までの6フェーズを順に進めるのが基本です。
色・サイズ・容量違いが増えると、ECモールや倉庫、POS、基幹システムの在庫が合わなくなり、現場はExcelや個別のCSVで調整し続けることになります。
▼全体ガイドの記事
・SKU管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SKU管理システムの全体像
SKU管理システムは、商品名を登録する台帳にとどまらず、在庫の動きまで追いかける仕組みです。商品バリエーションを最小単位のSKUとして定義し、そのSKUについて、どこに何個あり、どの受注に引き当てられ、いつ入出庫されたかを一貫して管理します。最初にデータの境界と業務上の責任者を決めておくほど、後工程の作り直しを抑えられます。
SKU・商品コード・JANの役割の分け方
SKUは在庫を数える最小単位です。例えば同じTシャツでも、白・Mと黒・Lは別SKUとして扱い、それぞれに在庫数と価格を持たせ、原価や発注点も個別に管理します。
一方で、商品コードは社内の商品管理番号、JANは流通上のバーコード番号として使われることがあり、3つが常に同じ値になるとは限りません。実際に、スマレジEC・一元管理の公式ガイドでも、出品商品マスタと商品SKUマスタを分け、商品SKUマスタを全店舗の在庫管理における最小単位として説明しています（出典: スマレジEC・一元管理「商品登録・在庫連携全体の流れ」、2026年7月更新）。
要件整理では、SKUコードを誰が採番し、変更や廃番を誰が承認するかを決めておきます。モールの商品番号やPOSの商品コード、仕入先の品番をそのまま主キーにすると、販路追加や仕入先変更で重複が起きやすくなります。そこで、社内で一意なSKU IDを持ち、外部コードは連携用の別項目として保持する設計が、将来のシステム追加にも対応しやすい方法です。
商品マスタと在庫履歴の一体管理
最低限のデータ項目は、親商品、SKU、JAN・バーコード、単位です。そのうえで、販売価格と原価、仕入先、拠点、棚番を持たせます。在庫では、実在庫、有効在庫、確保在庫を分けて持ちます。
受注残、入荷予定、発注点、安全在庫も在庫の項目として持ち、入出庫履歴も残します。重要なのは、現在庫の数値だけを上書きしないことです。入荷、出荷、返品、キャンセルの理由に加え、拠点間移動、棚卸差異、廃棄も履歴として残し、現在庫がどの取引から算出されたかを追跡できるようにします。
食品や化粧品、医薬品を扱う場合は、ロット番号、賞味期限・使用期限、先入先出のルールも初期項目に含めます。セット品やバンドル商品がある場合は、親となるセットSKUと構成品SKUの関係、出庫時にどの在庫を減らすかを定義します。発注や受注の連携では、実在庫と受注引当後の有効在庫を分けることで、売り越しと過剰な在庫確保を防ぎやすくなります。
業態別に優先する機能
ECや小売では、複数モールや店舗で売れた瞬間に有効在庫を同期することが中心課題です。卸では、入荷予定、仕入先、受注残、部分出荷に加え、得意先別の引当ルールが重要になります。
製造業では部品表や構成品、工程別の在庫が加わり、食品・医薬品ではロットや期限、回収時のトレーサビリティが優先されます。
自社の業務をこのように分類しておくと、使わない機能まで作らずに済むため、費用の抑制にもつながります。
SKU管理システム開発の進め方
開発は、現場のデータと業務ルールを整理してから、製品や開発方式を決めるのが順序です。6つのフェーズは、それぞれ完了条件と成果物で確かめながら進めます。
フェーズを飛ばすと、設計段階でSKUの重複が判明したり、稼働直前に返品や棚卸の処理が不足していたりします。こうした手戻りを避けるため、各フェーズを順に進めます。
フェーズ1：要件整理による現状と目標の把握
最初に、商品台帳やSKU・JAN一覧、各拠点の在庫表を集め、受注データや入出庫実績、返品記録、棚卸差異も用意します。SKU数や拠点数、販路数は、実数で記録します。ほかに、月間の受注件数と出荷件数、ハンディ端末台数、ロット・期限の有無も実数で押さえます。
旧台帳の中身では、重複コードや空欄、単位の揺れ、旧SKU、在庫マイナスを洗い出します。
「在庫を一元化したい」という要望は、在庫差異率、欠品率、棚卸時間、出荷リードタイム、売り越し件数などのKPIに置き換えます。成果物は、現状業務フロー、課題一覧、SKU採番規則を軸に、次のものをそろえます。
- マスタ項目定義：商品やSKU、拠点ごとの項目と、その意味
- 連携一覧：連携するシステムと、連携の方向
- 権限一覧：役割ごとに操作できる範囲
- 非機能要件：セキュリティや復旧など、機能以外の条件
- 移行対象データ一覧：旧台帳から移すデータの範囲
特に、どの時点で在庫を減らすか、返品を検品前と検品後のどちらで戻すか、棚卸差異を誰が承認するかを決めます。これらが未確定のまま選定を始めると、製品比較が機能数の競争になり、実際の業務への適合性を判断できなくなります。
フェーズ2：Fit to Standardを軸にした選定
SaaS、業務パッケージ、スクラッチ開発、ハイブリッドの4方式を、標準機能と独自要件の境界から比べます。
- SaaS：入出庫、棚卸、権限、操作ログなど、差別化につながりにくい機能は標準機能を優先すること
- 業務パッケージ：標準でできる範囲と追加部分を分けて見積もり、過剰なカスタマイズを避けること
- スクラッチ開発：独自の引当、セット品、価格計算、製造構成など、競争優位に直結する部分の追加開発
- ハイブリッド：既存SaaSと、独自SKUマスタやAPIハブの組み合わせ
比較では、機能の有無だけでなく、代表的な100〜500SKU、1拠点、1販路を使ったデモやPoCを依頼します。入荷、受注引当、部分出荷を一つのシナリオで実演してもらい、現場担当者が迷わず操作できるかを確かめます。実演では、返品と棚卸差異、欠品とキャンセルの場面も含めます。
質問票では、APIの認証方式、レート制限、再送を中心に、重複受信の扱いを聞きます。あわせて、CSVの文字コード、データ出力、解約時の返却条件も確かめます。
フェーズ3：設計・開発でのデータと連携の境界の確定
設計では、商品やSKU、拠点、ロケーションに加え、在庫残高と在庫変動、受注を中心に、どのテーブルや画面で扱うかを決めます。実在庫、有効在庫、確保在庫、受注残の計算式を文書化し、在庫を減らすイベントを一つに定義します。対象には、次の業務も含めます。
- 受注と返品：引当、返品
- 仕入れと在庫の予定：入荷予定、発注
例えば、受注受付時に確保し、出荷確定時に実在庫を減らす設計なら、キャンセルや欠品時の戻し方も同じ設計書に記載します。外部連携では、ECモール、POS、WMSを中心に、どのシステムを正とするかを決めます。カートやERP、会計、購買も対象になります。
連携では、連携項目と送受信のタイミングを決め、失敗時の再送、重複排除、通信断、監視方法を定義します。
権限は、マスタ編集者、倉庫作業者、承認者、閲覧者、システム管理者に分け、変更履歴と在庫調整理由を残します。個人情報や配送先情報を扱う場合は、MFA、最小権限、暗号化、バックアップ、復旧目標、APIキー管理も設計に含めます。
フェーズ4：実データに近い異常系までのテスト
単体テストだけでなく、入荷から出荷、返品、棚卸、発注までの業務シナリオを通しで検証します。正常系では、SKU登録、バーコード入荷、受注引当、ピッキング、出荷確定、在庫同期の順に、数が一致するかを確認します。
異常系では、同じ注文の二重受信、APIの再送、通信断、部分出荷、キャンセルを試します。さらに、在庫マイナス、日跨ぎ、CSVの全角半角、期限切れロット、棚卸差異も試しておきます。テスト結果、残課題、再テスト日、承認者を記録してから、稼働判定を行います。
受入テストでは、機能が動くことに加えて、倉庫作業者が指定時間内に処理できるか、担当者が在庫差異の理由を追跡できるか、現場端末の通信が不安定な場所でも復旧できるかを確認します。テストデータには、代表的なSKUに加え、色やサイズの多い商品、セット品、廃番、ロット・期限付き商品を含めます。
フェーズ5：データ移行と段階展開を分けた稼働
移行前には、旧台帳から不要なSKU、重複コード、欠損項目、単位の違い、古い価格を整理し、変換ルールを確定します。移行対象を一度に増やすより、まず代表的なSKUで試行移行を行い、件数や在庫残高を中心に照合します。照合では、JANや拠点、ロットや期限、価格も確かめます。
本番切替では、旧システムの更新停止時刻と最終差分の反映、棚卸基準日、切替責任者、障害時の切り戻し方法を決めておきます。全拠点・全販路をまとめて切り替えるより、1拠点や1ブランドから始める段階展開が現実的です。新旧システムを長期間二重入力すると、かえって差異が増えるため、並行期間と終了条件を短く明確にします。
稼働初週は、在庫差異、連携エラー、出荷遅延、問い合わせ件数を毎日確認します。あわせて、重大な不具合の連絡先と対応時間を現場に共有します。
フェーズ6：KPIと運用責任者による定着と改善
稼働後は、業務が改善したかで評価します。KPIには、在庫差異率、欠品率、売り越し件数、棚卸時間、出荷リードタイム、返品処理時間、連携エラー件数を設定し、導入前の実績と比べます。
月1回の運用会議で、SKU追加、商品廃番、棚番変更、権限変更、連携エラーの再発を確認し、改善の優先順位を決めます。定着には、拠点ごとに現場のスーパーユーザーを置き、操作手順だけでなく「なぜそのタイミングで処理するのか」まで教育することが欠かせません。例えば、出荷前に手動で在庫を減らすと二重計上になる場合は、禁止事項と正しい代替手順を画面の近くに掲示します。
発注側は、マスタの登録・変更、在庫調整、棚卸承認の責任者を明文化し、担当者が異動しても運用が止まらない状態を目指します。
SKU管理システムの費用相場とコストの内訳
費用は、SKU数や拠点数、販路数のほか、月間出荷件数や連携数によって変わります。ロット・期限、ハンディ端末、移行データの品質も費用を左右します。
以下の数字は、SKU専用の公的統計ではなく、公開料金と業務システムの人月単価、一般的な連携・移行工数を組み合わせた、導入判断用の目安です。
税込・税別や、端末、バーコードプリンター、倉庫作業費、データクレンジングの扱いは、別途確認が必要です。
SaaS・パッケージの初期費用と月額の条件
標準機能中心の小規模SaaSは、初期設定や移行支援を含めて0万〜30万円程度、月額3,000円〜15万円程度が一つの目安です。ただし、プランごとにユーザー数、ロット・期限、外部連携、サポート範囲が異なるため、月額だけで比べてはいけません。
- zaico：公式料金で、スターターが月額8,980円、ベーシックが月額49,800円、プロフェッショナルが月額15万円から
- らくらく在庫（EC多店舗向け）：初期費用無料で、500〜30,000SKUの枠に対し、月額3,000円〜55,000円を店舗数に応じて掛ける
- 中堅SaaSやパッケージ：設定・教育・APIまたはCSV連携を含め、初期30万〜300万円、月額1万〜50万円程度になるケースがある
zaicoとらくらく在庫の金額は、2026年8月に確認した公式料金です（出典: 株式会社ZAICO「料金プラン」、グリニッジ株式会社「らくらく在庫 料金」）。らくらく在庫では、セット販売やFBAマルチチャネル連携などにオプション料金が加わります。中堅SaaSやパッケージの実際の金額は要見積もりです。
スクラッチ・連携型の費用の幅
費用の目安は、作る範囲によって次のように分かれます。
- MVPスクラッチ：独自要件を絞ったSKU管理で、初期300万〜1,000万円程度、開発期間3〜6か月程度
- 中規模の連携型：EC、WMS、ERP、POS、ハンディ端末をつなぐ構成で、初期1,000万〜3,000万円程度、期間は6〜12か月程度
- 全社基幹型：大量SKUや複雑な受発注・生産・物流を含み、3,000万円〜1億円超、12〜24か月以上になる可能性があります
いずれも公開統計の一律価格ではなく、SKU数、拠点、連携、移行、テストを前提にした推定レンジです。
人月単価の目安は、リサーチノートで確認した2026年時点の参考値として、PMが月90万〜150万円、SEが月65万〜110万円、PGが月50万〜90万円です。中小開発会社は月80万〜120万円、大手SIerは月150万〜200万円程度です。発注先や体制によって変わるため、単価だけでなく、何人月をどの工程に配分するか、どの成果物をどの検収条件で受け入れるかも確かめます。
移行・端末・保守を含めた3年総額での比較
初期費用以外に発生する項目は、次の3つに分けて見ます。
- 開発にかかる項目：要件定義、マスタクレンジング、データ移行、API開発、テスト、教育
- 導入と利用の費用：現場立ち会い、端末・ラベルプリンター、クラウド利用料、ユーザー追加、拠点追加、API利用料
- 保守の費用：保守、障害対応、バックアップ、データ返却費用
月額が安く見えても、拠点やSKU、ユーザー、連携先が増えたときの従量課金で総額が変わるため、同じ前提で1年目と3年目を試算します。
見積りの一般的な配分として、Q&Aで確認した参考値では、人件費が総費用の約60〜80%、要件定義が工期の約25%、テストが15〜17%程度です。これは案件ごとの正式な相場ではなく、工数配分を考えるための目安です。
要件定義やテストを削ると、後から仕様変更や手戻りが増え、当初工数の1.3〜1.5倍に膨らむ可能性があるため、安さだけで判断しないことが大切です。
SKU管理システムの見積もりを取る際のポイント
見積もりの品質は、依頼時にどれだけ業務条件をそろえられるかで決まります。開発会社に任せきりにせず、SKUのサンプル、現在の台帳、業務フロー、連携先、目標KPIを渡し、同じ前提で比べられるRFPにします。
見積書は、合計金額だけでなく、含む作業と含まない作業、前提条件、変更時の扱いを確認してください。
RFPに記載する数量・業務ルール・データ品質
SKU数と年間の増加数、拠点数は、見積もりの規模を決める数字です。業務の条件は、商品構成から発注までの5つの観点に分けて書くと、各社が同じ前提で見積もれます。
- 商品構成：商品とSKUの関係、棚番の有無
- 販路と件数：販路数、月間の受注・出荷件数、同時利用者数
- 端末：バーコード種類、端末台数
- 在庫の扱い：ロット・期限、セット品、返品・キャンセル・部分出荷
- 発注と在庫：発注点、安全在庫、棚卸頻度
連携では、EC、POS、WMSを中心に、システム名と連携方向を整理します。ERPや会計、購買も対象です。
連携方式として、リアルタイムかバッチか、APIかCSVか、連携失敗時の担当者も明記します。
データ移行では、旧台帳の件数に加え、重複率や必須項目の欠損率、コードの桁数、単位の揺れ、過去在庫の残す年数を示します。SKUサンプルは、通常商品、色・サイズ違い、セット品、廃番、ロット・期限付き商品を含めます。これにより、単純な一括登録を想定した安い見積もりと、クレンジングや変換を含む現実的な見積もりを区別できます。
同じシナリオと3年総額による複数社の比較
候補は、SaaSベンダー、パッケージ提供会社、受託開発会社に分けて選びます。比較表には、初期費用、月額、ユーザー・SKU・拠点の上限を中心に並べます。加えて、次の項目も比較表に入れます。
- 連携とデータ：API・CSV連携、データ出力、解約時の返却
- 業務機能：ロット・期限、セット品、ハンディ対応
- 導入と保守：移行支援、教育、保守時間、障害時のSLA
価格が非公開のサービスは、推測で埋めず、「要見積もり」と明記します。
提案を受けたら、同じ100〜500SKUのサンプルと同じ業務シナリオでデモを実施します。さらに、現場担当者には、入荷検品、棚入れ、ピッキング、出荷、返品、棚卸差異の操作を試してもらいます。管理者には、マスタ変更、在庫調整、権限、監査ログ、CSV出力を確認してもらいます。
導入後の伴走者が誰か、問い合わせの一次窓口がベンダーか開発会社かも、契約前に確かめます。
セキュリティ・契約・将来の変更費用の確認
非機能要件には、ロール別の最小権限、MFA、通信中と保存時の暗号化を中心に記載します。そのほかに、次の項目も入れます。
- アクセスと記録：IP制限、操作・変更履歴
- 復旧と通知：バックアップ、RTO・RPO、障害通知
脆弱性対応、APIキー管理、データの書き出しと削除も含めます。在庫システムは止まると出荷や販売に直結するため、機能要件と同じ重さで確認します。
IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版でも、クラウドサービスの安全利用やバックアップ、インシデント対応が扱われています（出典: IPA、2026年3月公開）。顧客や配送先の個人データを委託する場合は、委託先の選定基準、契約上の安全管理措置、再委託の事前報告・承認を中心に確認します。そのほかに、監査、事故時の連絡、終了後の返却・消去も確かめます。
個人情報保護委員会の通則ガイドラインでも、委託先の安全管理措置を事前に確認し、契約に取り扱い状況の把握を盛り込むことが示されています。定期的な監査も求められています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。
受託開発の場合は、設計書、API仕様、テスト結果に加えて、インフラ設定、ソースコード、運用手順書も含め、その帰属と利用権を確認します。
契約では、SKUや拠点、連携先を増やす場合の単価を書面に残します。ユーザーや端末を増やす場合の単価も、あわせて明記します。保守契約の時間外対応も、同じ書面で確認しておきます。
さらに、初期構築が終わった後に自社で変更できる範囲を把握しておくと、ベンダー依存と予想外の追加費用を抑えられます。
SKU管理システムについてよくある質問（FAQ）
SKU管理システムを選ぶときは、名称よりも、在庫の最小単位、マスタの責任者、在庫が減るタイミング、連携の正となるシステムを確認します。開発前によく出る疑問に、ここで順に答えます。
SKU管理システムと在庫管理システムは何が違いますか？
SKU管理システムは、商品バリエーションごとの最小単位を軸に、在庫、受注、入出庫、発注、棚卸を管理する仕組みです。在庫管理システムは、より広い呼び方で、SKU単位を扱う製品もあれば、倉庫や資材、固定資産を中心に扱う製品もあります。
色・サイズ・容量が必要な場合は、SKU単位の登録・引当・履歴ができるかを確認します。ロット・期限、セット品、販路連携が必要な場合も、同じように確認します。
パッケージとスクラッチはどちらを選ぶべきですか？
標準化できる入出庫、棚卸、権限、ログを早く導入したい場合は、SaaSやパッケージが向いています。
独自の引当、複雑な構成品、製造や取引先固有の業務が競争力に直結する場合は、API連携やスクラッチ開発を検討します。
最初から全面スクラッチにせず、標準製品でコア業務を始め、差別化要件だけを疎結合に追加する方法も有効です。
開発期間と費用の目安はどれくらいですか？
標準機能中心の小規模SaaSは即日〜1か月程度で始められる場合があり、設定・教育・連携を含む中堅SaaSやパッケージは1〜4か月程度が目安です。
MVPスクラッチは3〜6か月、EC・WMS・ERP連携型は6〜12か月程度が一つの目安です。ただし、費用は初期300万〜1,000万円、連携型1,000万〜3,000万円程度など幅があります。SKU数、拠点、連携、移行、テストを明示して見積もりを取り、特定の金額をそのまま自社案件に当てはめないでください。
Excelから移行するときに何を準備すべきですか？
まず、商品・SKU・JANを軸に、データを一覧にして集めます。一覧には、価格・原価・単位を入れます。仕入先・拠点・棚番も、同じ一覧に加えます。現在庫・ロット・期限も、あわせて含めます。集めた一覧は、重複、欠損、表記揺れ、廃番がないかを確認します。
次に、新システムの必須項目と旧台帳の列を対応付け、変換できないデータを洗い出します。代表SKUで試行移行を行い、件数と在庫残高を照合してから、本番の最終差分と切替手順を決めることが安全です。
まとめ
SKU管理システムの開発では、機能を増やす前に、SKUの定義、マスタの責任者、在庫の確定タイミング、連携の正となるシステムを決めておくことが欠かせません。
要件整理から定着までの6フェーズを、成果物と完了条件で管理すれば、現場で使われる仕組みに近づけます。
6フェーズを通じた業務とデータの一貫性
特に、商品コードやJANをそのままSKUの主キーにしないこと、受注引当と実在庫を分けること、返品・キャンセル・棚卸差異を履歴として残すことが要点です。さらに、標準機能で足りる部分はSaaSやパッケージを活用し、独自の業務価値がある部分だけを追加開発すれば、初期費用と将来の保守負担を抑えやすくなります。
公開料金の有無にかかわらず、3年総額とデータ返却条件まで比較してください。
見積依頼前の自社の判断材料
はじめに、SKU数や拠点数、販路数を確認し、代表的なSKUのサンプルを準備します。さらに、月間出荷件数、ロット・期限、連携数を押さえ、端末台数と現在の在庫差異率も確かめます。
そのうえで、現場の困りごとを「棚卸に何時間かかるか」「売り越しが何件あるか」「返品処理がどこで止まるか」のように具体化します。要件とデータをそろえたRFPを複数社へ渡し、同じシナリオのデモと3年総額の見積もりを比較すれば、価格だけでは見えない適合性を判断できます。
SKU管理システムの導入を検討している場合は、まず現状の業務フローとデータ項目を整理し、標準化できる部分と独自開発が必要な部分を切り分けることから始めてください。
▼全体ガイドの記事
・SKU管理システム開発の完全ガイド
開発を相談する前に役立つ無料ホワイトペーパーを2冊紹介します。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。