SKU管理システム開発の完全ガイド - ブログ

SKU管理システムは、商品を在庫や出荷の単位であるSKUで管理し、受注から棚卸までの記録をつなぐシステムです。マスタ整備、在庫の定義、機能の選定を順に進めると、売り越しや在庫差異を減らせます。

各テーマの詳細は、次の関連記事で確認できます。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

SKU管理システムの全体像

商品分類と数量の記録を分けると、在庫の変化を追いやすくなります。

SKU管理では、商品名と、販売や保管の単位を分けて考えます。同じ商品名でも色やサイズが違えば、在庫の引当先や発注点が異なるため、通常は別のSKUになります。

SKUの定義と商品コード・JANとの違い

商品識別子の役割を分けて理解しておくと、SKUの登録や照合で迷いにくくなります。

SKU：Stock Keeping Unitの略で、在庫を数え、発注し、出荷する最小の管理単位です。色やサイズが違えば、別の単位として扱います。
SKUの例：同じ親商品でも、白いTシャツのMサイズと黒いTシャツのLサイズは、それぞれ別の単位です。
商品コードとJAN：社内で管理する識別子と、流通上のバーコード規格に基づく識別子があります。SKUコードと同じとは限りません。
マスタ管理：商品の基本情報は、SKUコード、JAN、親商品、単位に分けます。価格、原価、仕入先も別項目にし、採番者と変更承認者を決めます。

「商品名＋色＋サイズ」だけをSKU名にすると、旧商品の引き継ぎやセット品、仕入先コードとの照合でつまずきやすくなります。

公開されている在庫管理サービスでも、JAN、ロット、仕入、発注点、安全在庫、拠点は、それぞれ個別に扱う設計が一般的です（出典: 在庫管理サービスの公式機能資料、2026年8月確認）。

親商品・SKU・在庫履歴の関係

在庫の数字を正確に追うには、商品の分類と在庫履歴がどう結び付くかを先に整理しておくことが必要です。

親商品：同じデザインなどをまとめた単位です。
SKUと在庫：SKUは具体的なバリエーション、在庫は拠点・棚・ロットごとの数量を指します。
在庫履歴：受注引当後、出荷・返品・移動・棚卸差異のたびに記録される履歴です。
在庫状態：在庫数を直接書き換えず、実在庫、確保在庫、受注残、入荷予定に分けて持ちます。

「販売可能数＝実在庫−確保在庫＋入荷予定を含めるか」というルールは、明文化して関係者で共有します。導入の成否は、在庫状態の定義と変更履歴の設計に左右されます。

ポイント

SKUの定義、親商品と在庫履歴のつながり、販売可能数のルールを社内でそろえられるかが、全体像を理解できたかの目安です。どれか一つでもあいまいなら、検討の前に決め直します。

SKU管理システムの種類と業務別の選び方

扱う業務の広がりに応じて、システムの範囲も変わります。

SKU管理システムには、単体の在庫管理や倉庫管理のシステムがあります。ECの受注と在庫を連携させるものや、販売・購買・生産まで含む基幹システムなどもあります。選ぶ際は、在庫の正本をどこに置くか、現場作業をどこまでシステム化するかを基準にします。

EC・小売で使うSKU管理

複数のECを運営する場合は、受注を集約し、チャネルごとの在庫を同じSKUにひも付けます。

コード管理：社内SKUを正本にし、外部チャネルの商品コードを対応表で結ぶ方法。
注文処理：取り込み、引当、キャンセル、返品、出荷完了の各時点を、事前に定めておく作業です。

連携していても、各時点が曖昧なままでは、売り越しが発生します。

公開料金の一例では、500〜30,000SKUに対して月額3,000〜55,000円を、店舗数分支払う体系になっています（出典: 在庫連動サービス公式料金ページ、2026年8月確認）。

セット販売、別品番のひも付け、外部倉庫との連携はオプションになりやすいため、必要な機能を加えた金額で比べます。

製造・卸・食品で使うSKU管理

製造・卸・期限管理のある商品では、SKU以外に管理する情報の範囲を決めておきます。

製造・卸：仕入先、入荷予定、拠点間の移動、構成品、発注点が主な管理対象です。
食品・化粧品・医薬品：ロット番号、賞味・使用期限、入荷日に加え、先入れ先出しの出庫順も持たせます。
セット・ケース商品：単一SKUとして扱うか、構成品の在庫を減らして販売可能数を計算するかで、在庫計算と返品処理が変わります。

期限を後から追加すると、過去データの再整理が難しくなります。そのため、対象となる品目を先に分類しておきます。

代表商品を使い、構成品が欠けた場合の扱い、分解・組み替えの履歴、ケース入数とバラ数の換算を試します。

SKU管理システムに必要な機能

機能が有るかどうかに加えて、管理の細かさ、担当者、履歴の使い方も確認します。SKUマスタの所有者と在庫が確定する時点が曖昧だと、システム間で数字が一致しません。

マスタ・在庫・入出庫の基本機能

基本機能は、商品データ、在庫状態、入出庫履歴の三つに分けて確認します。

マスタ：商品、SKU、バリエーション、セット品を登録します。JAN・バーコード、単位、価格、原価、仕入先も持たせます。
在庫状態：拠点、倉庫、棚番と、実在庫、確保在庫、受注残を分けて持ちます。入荷予定、発注点、安全在庫も含めます。
履歴：入荷、出庫、返品、移動、棚卸、在庫調整を、一つの履歴にまとめて検索できる形です。

バーコードやQRコードを使う場合は、端末、ラベル発行、誤読時の手入力、通信断後の再送を確かめます。

ハンディ端末では、操作回数と片手での操作しやすさが生産性に直結します。そのため、高機能なダッシュボードよりも、現場が毎日間違えずに入荷検品と出荷検品を行えることを優先します。

EC・POS・WMS・ERPとの連携

連携要件では、対象システム名に加えて、データごとの責任と例外処理を定めます。

連携仕様：正本、API・CSV、送信頻度を決めます。重複受信、再送、キャンセル・部分出荷の扱いも含みます。
責任システム：データごとに、責任を持つシステムを一つ決めます。
例外の検証：通信断、タイムアウト、二重送信、在庫マイナス、返品後の再販売を、テストで実際に試すことです。

たとえば、受注はECから受け、SKUマスタは基幹から配布し、在庫は倉庫の確定結果を在庫正本へ返します。

APIにも、相手側の反映遅延やメンテナンスがあります。そのため、連携ログに受付時刻、処理結果、エラー内容、再送回数を残しておくと、障害の原因を切り分けやすくなります。

2025〜2026年の導入では、AI-OCRによる納品書の読み取り、需要予測による発注候補、画像認識による検品補助も選択肢に入ります。ただし、在庫数や発注をAIに自動で確定させず、候補の根拠と元データを表示する設計にします。担当者が承認や差し戻しをできるようにします。

誤読や季節変動があるため、導入効果は自動化率だけでなく、修正率と欠品率も合わせて評価します。

ポイント

機能比較では、機能の有無に加えて、管理の細かさ、担当者、履歴の使い方をそろえて見るのが目安です。SKUマスタの所有者と在庫が確定する時点は、連携の前に決めておきます。

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

実データで確かめてから、稼働範囲を広げる流れです。

開発は、現状のSKUと在庫の流れを洗い出す工程から始めます。画面作成より前に、例外処理も確認します。

標準機能と追加開発の範囲を分けておくと、費用と納期のぶれを抑えられます。

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

現状調査とSKUマスタの棚卸し

現行データと管理の責任を棚卸しすると、移行の前に整える範囲が見えてきます。

収集データ：商品台帳、SKUコード、JAN、EC・POSコードを集めます。倉庫在庫、受注残、仕入先、棚番も対象です。
不整合の確認：重複コード、表記ゆれ、単位違い、廃番SKU、同じJANに複数商品が付くデータの洗い出し。
決めること：業務フロー、項目一覧、SKU変換表、課題一覧、登録・承認者、販売開始時点を、この段階で決めます。

マスタの所有者が部署ごとに分かれている場合は、採番ルールと変更申請の手順を設けます。データクレンジングを省くと、重複在庫や欠品を新システムの問題と誤認しやすくなります。

要件定義とPoC・MVP

要件定義では、SKU数、拠点数、倉庫数、販売チャネル数を確定させます。加えて、月間受注件数、月間出荷件数、端末台数、ロット・期限の有無、連携数も決めます。

非機能要件：権限、監査ログ、バックアップ、復旧時間、利用時間帯、API制限です。
PoC：全社に広げる前に、代表的な100〜500SKU、1拠点、1販路を実データで試す段階です。
業務検証：入荷、検品、棚入れ、受注引当を通し、出荷、返品、棚卸、差異調整までを一周します。
成功条件：在庫差異率、棚卸時間、出荷リードタイム、売り越し件数などのKPIで、成否を決めます。

移行・連携テスト・段階展開

移行の条件と検証手順を固めてから、対象を絞った単位で稼働を始めます。

旧・新コードの対応表、対象期間、在庫基準時刻、受注範囲、返品・キャンセルの扱いを決めておきます。
複数回リハーサルを行い、件数に加えて、SKU別在庫明細、ロット、棚番、引当状態を照合します。
CSVの文字コード、API再送、重複受信、通信断、部分出荷、日をまたぐ処理を、実データで検証します。
1拠点か1ブランドで稼働させ、KPIを見ながら範囲を広げていきます。
操作の説明に加えて、誤出荷、棚卸差異、返品、在庫調整の際の判断基準も教えます。

切り替え後の問い合わせ窓口、障害時の手動運用、旧システムの参照期間も事前に決めておくと、現場の混乱を抑えられます。

ポイント

進め方は、現状調査、要件定義とPoC、移行・連携テスト・段階展開の順に、実データで確かめながら進めるのが目安です。標準機能と追加開発の範囲は、早い段階で分けておきます。

SKU管理システムの費用相場と内訳

費用は、SKU数、拠点数、販路数、連携数、端末台数で変わります。そのほか、ロット・期限、移行データの品質、導入支援の範囲も費用に影響します。

次の数字は、在庫・販売・物流を含む業務システムの一般的な目安です。税込・税別のほか、端末、バーコードプリンタ、データクレンジング、倉庫作業費は、別途確認が必要です。

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

導入タイプ別の初期費用・期間

標準機能で始めるSaaSから全社の基幹システムまで、要件の広がりに応じて費用と期間が変わります。

小規模SaaS：初期費用は0万〜30万円程度、月額は3,000円〜15万円程度です。
中堅向けSaaS・パッケージ：初期費用は30万〜300万円程度、導入期間は1〜4か月です。
MVPのスクラッチ開発：独自要件を含み、300万〜1,000万円程度、3〜6か月の規模です。
中規模開発：EC・WMS・ERPとの連携を含み、1,000万〜3,000万円程度、期間は6〜12か月。
全社基幹など：複雑な受発注や生産の連携を含み、3,000万円〜1億円超、12〜24か月以上になる場合があります。

標準機能を短期間で使いたい場合は、小規模SaaSが候補になります。公開料金のあるサービスでは、初期費用無料や30日間の試用期間を設ける例もあります。

これらの数字は、人月単価と一般的な工数から算出した推定レンジで、公開統計ではありません（出典: 業務システム開発の人月単価・工数を基にした2026年時点の試算）。

初期費用以外にかかるコスト

初期費用以外も含めて、見積もりの内訳と継続費用を確かめます。

工程別内訳：要件定義、マスタ整備、画面・API設計、実装を分けます。連携、テスト、移行、教育、稼働後支援は別に示してもらいます。
仕様変更：要件定義を削ると、工数が当初の1.3〜1.5倍に膨らむ可能性があります。そのため、安さだけで選ぶ判断は避けます。
継続費用：SKU・拠点の追加、API回数、ユーザー・端末、保守が対象です。出力、更新、障害対応、解約時の返却費用も含まれます。
3年総額：導入後3年間の総額で比べます。月額10万円の差は、3年で360万円です。拠点や利用者が増えたときの料金も確かめます。

人件費は総費用の約60〜80%を占めるという見方があります（出典: 業務システム開発の工数配分に関するQ&A、2026年確認）。また、要件定義は工期の約25%、テストは15〜17%程度という見方もあります（出典: 業務システム開発の工数配分に関するQ&A、2026年確認）。

ポイント

費用は、初期費用だけでなく、工程別の内訳、継続費用、3年総額で比べるのが目安です。税込か税別か、端末や倉庫作業費などの別途費用は、見積もりの段階で押さえておくのが安全です。

SKU管理システム開発会社・サービスの選び方

選定で見るのは、自社の在庫業務を正しく再現できるかです。方式ごとに、導入期間や適合性が異なります。

SaaS：短期間の導入と標準化に強い方式です。
パッケージ：業務テンプレートを使いやすいのが特徴です。
スクラッチ：独自要件に柔軟に対応できます。
ハイブリッド：既存サービスに独自のSKUマスタとAPIハブを組み合わせる方式です。コア在庫を保ちながら、差別化部分を加えやすい点が利点です。

業務適合性と実績の確認

候補を絞るときは、自社業務への適合実績と、条件をそろえた比較が重要です。

近い実績：SKU数、拠点、出荷件数、業界、商材の面で、自社と似た実績があるかを見ます。マスタ所有者、ロット・期限への対応も確かめます。
例外業務：セット品、返品、部分出荷、棚卸差異への対応を聞きます。
デモ：自社のSKUを使い、入荷から返品まで操作してもらいます。サンプル画面だけで判断しないためです。
RFP：自社の利用条件を整理して伝える文書です。
見積比較：同じ条件で2〜3社から取り、機能の抜けと費用を並べて比べます。

RFPには、SKU数、月間入出荷、拠点、販路を記載します。外部システム、端末、移行件数、ピーク時の処理量も書きます。

欠品、キャンセル、返品、ロット切替に加え、在庫マイナス、通信断、二重送信のテストも、提案に含めるよう依頼します。

導入支援・保守・契約の確認

支援の範囲、障害対応、契約終了後の扱いは、導入前に確かめておきます。

導入支援：初期設定、移行、現場教育、稼働立ち会い、運用設計のうち、どこまでが含まれるかを確かめます。
保守確認：受付時間、復旧目標、バックアップ頻度、メンテナンス通知、バージョンアップ方針、API仕様変更の扱い。
成果物：設定値、マスタ項目、連携仕様、テスト結果を受け取れるかどうかです。
受託契約：ソースコード、設計書、API仕様、インフラ設定、テスト証跡、データ返却方法を、契約書に明記します。
個人情報：委託先、秘密保持、再委託の事前報告・承認を決めます。事故連絡、終了時の返却・削除、監査方法も確かめます。

個人情報保護委員会は、委託先の安全管理措置を事前に確認し、再委託先を含めた取扱状況を把握するよう示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

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

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

ポイント

開発会社やサービスは、自社の在庫業務を正しく再現できるかで判断します。方式、実績、デモ、保守、契約の各項目は、その判断を支える材料になります。

セキュリティと運用で見落としやすい点

SKU管理システムは、在庫のほか、仕入価格、取引先、顧客、配送先、担当者の情報に触れることがあります。

「クラウドだから安全」「社内システムだから安全」と決めつけず、業務データの範囲とアクセス経路を整理します。

中小企業向け情報セキュリティ対策ガイドライン第4.0版は2026年7月に最終更新され、クラウドの安全利用やバックアップも扱っています（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」、2026年7月）。

権限・ログ・バックアップ

権限管理、操作記録、復旧の面から、情報と在庫を守る設定を確かめます。

役割別の権限：管理者、商品マスタ、倉庫、店舗、閲覧者で分けます。価格閲覧、在庫調整、CSV出力は制限します。
認証と記録：多要素認証、暗号化、IP制限の有無を確かめます。操作やマスタ変更の履歴、在庫調整の理由も残します。
復旧と保管：復旧目標（RTO）と戻せる時点（RPO）を決めたうえで、復元訓練を行います。
運用要件：APIキー、障害通知、ログ保存、データ出力、解約時の返却・削除を要件に含みます。

退職や異動の際に、権限をすぐ止められる運用も整えます。バックアップは、実際に復元できるかを確認します。

二重管理と属人化を防ぐ運用設計

更新先と担当者を一つにまとめ、稼働後の指標を改善につなげます。

Excelの用途：二重入力では、数字が合わなくなることがあります。参照、移行、例外申請の用途に絞り、日常の更新先は一つにします。
責任者：商品登録、在庫調整、返品、棚卸承認の担当者と、代替担当を決めます。
月次確認：毎月、在庫差異率、欠品率、売り越し件数、棚卸時間、出荷リードタイム、返品処理時間を追います。
原因分析：悪化したときは、機能不足だけでなく、SKU重複、検品漏れ、連携遅延、現場ルール違反も調べます。

KPIと改善会議を運用に組み込むと、導入効果を継続的に高められます。

よくある質問

導入の判断に必要な観点から、SKU管理システムでよくある疑問に答えます。自社の要件に当てはめ、候補サービスや開発会社に聞く質問として使ってください。

SKU管理はExcelでもできますか？

SKU、拠点、販路が少なければ、Excelで台帳を始めることもできます。

同時編集、入出庫履歴、引当、返品が必要になると、重複入力や更新漏れが起きやすくなります。ロット・期限、複数チャネルへの即時反映まで加わると、この傾向はさらに強まります。

Excelで管理している間に、SKU数、更新頻度、差異件数を記録しておくと、システム化の判断材料になります。

何SKUからシステム導入を検討すべきですか？

判断は、運用の複雑さと差異の影響を見て行います。SKU数は、その材料の一つです。

判断軸：拠点数、販路数、出荷量、更新頻度、ロット・期限の有無です。
小規模SaaS：1〜5,000SKU、1〜数拠点、標準機能が中心なら検討しやすい目安です。
専門システム：複数販路、倉庫連携、棚番、期限管理があるなら、早めに比べておきます。
少数SKU：SKUが少なくても、売り越しや棚卸差異が経営課題であれば、導入効果が出る可能性があります。

スクラッチ開発とSaaSはどちらがよいですか？

標準的な入出庫、棚卸、権限、ログを短期間で使うなら、SaaSやパッケージが向いています。

独自の引当、複雑な構成品、特殊な承認、既存基幹との深い連携が競争力に直結するなら、スクラッチやハイブリッドを検討します。

最初に全機能を作り込まず、標準機能では足りない要件の価値と保守の負担を比べます。

既存データの移行で最も注意することは何ですか？

旧・新コードの対応表と基準時刻は、先に確定させます。在庫状態、ロット・期限、廃番の扱いも、先に決めておきます。

件数だけを移行しても、親商品とSKUの関係や単位が崩れていれば、発注や出荷で誤りが起きます。

移行リハーサルで代表SKUの明細と全体件数を照合します。差異を説明できる状態で、本番へ進みます。

まとめ

SKU管理システムは、SKUマスタと在庫状態・履歴を中心に、受注、発注、入出庫、出荷、返品、棚卸をつなぐ業務基盤です。

導入前に、SKUと商品コードの違い、在庫の正本、ロット・期限、セット品、連携の境界を決めておくと、機能比較や見積もりの精度が上がります。

導入前に整理する項目

SKU数、拠点数、販路数、月間出荷件数、端末台数を数えます。さらに、ロット・期限、セット品、ケース単位の有無も整理しておきます。

外部連携の方式、マスタの所有者、在庫が確定する時点を決めておきます。費用は、初期費用だけでなく、3年総額、移行、保守、復旧、データ返却まで比べます。

小規模な試行と、KPIによる展開

本番展開の範囲は、現場の業務で効果を確かめてから判断します。

代表SKUと実際の業務シナリオでPoCを行い、入荷から返品・棚卸までを確認します。
稼働後は在庫差異率、欠品率、売り越し件数、棚卸時間、出荷リードタイムを測ります。
効果が確認できた拠点・ブランドから展開範囲を広げます。

業務ルールとデータ品質の改善を続けることで、システムを長く使える基盤にできます。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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