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

SKU管理システムとは、商品を色・サイズ・容量・仕様などの最小単位（SKU）で識別し、在庫・受注・発注・出荷・棚卸の状態を一貫して管理する仕組みです。Excelや販売チャネルごとの在庫表を置き換えるだけでなく、正しいSKUマスタと在庫履歴を一つの流れでつなぐことが、売り越しや在庫差異を減らす最短ルートです。

本記事では、SKUと商品コードの違い、業務システムの種類、必要な機能、開発・導入の進め方、2026年時点の費用相場、開発会社・サービスの選び方までをまとめて解説します。自社のSKU数や拠点数、販売チャネル、ロット・期限管理の有無を整理し、過不足のないRFPと見積もり比較につなげられる構成です。

SKU管理システムの全体像

SKU管理を理解するポイントは、商品名を管理することと、販売・保管する単位を管理することを分けて考えることです。同じ商品名でも、色やサイズが異なれば在庫の引き当て先も発注点も変わるため、通常は別のSKUとして扱います。

SKUとは何ですか？商品コードやJANとの違い

SKUはStock Keeping Unitの略で、企業が在庫を数え、発注し、出荷する最小の管理単位です。たとえば白いTシャツのMサイズと黒いTシャツのLサイズは、同じ親商品に属していても別SKUです。商品コードは社内で付ける識別子、JANは流通上のバーコード規格に基づく識別子であり、SKUコードと必ず同じとは限りません。

「商品名＋色＋サイズ」をSKU名に埋め込むだけでは、旧商品の引き継ぎやセット品、仕入先コードとの照合で破綻しやすくなります。SKUコード、JAN、親商品、単位、価格、原価、仕入先を別項目で持ち、誰が採番し、変更を承認するかまで決めることが重要です。公開されている在庫管理サービスのSKU項目でも、JAN、ロット、仕入、発注点、安全在庫、拠点などを個別に扱う設計が一般的です（出典: 在庫管理サービスの公式機能資料、2026年8月確認）。

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

システム上は、親商品、SKU、在庫の三層を分けると整理しやすくなります。親商品は「同じデザインの商品」などのまとまり、SKUは販売・保管する具体的なバリエーション、在庫はSKUがどの拠点・棚・ロットに何個あるかを表します。受注が入ると在庫を引き当て、出荷・返品・移動・棚卸差異が発生するたびに履歴を残す流れです。

在庫数を直接上書きする運用は、後から差異の理由を追えません。実在庫、確保在庫、受注残、入荷予定を分けて持ち、「販売可能数＝実在庫−確保在庫＋入荷予定を含めるか」というルールを明文化します。システム導入の成否は画面数よりも、この在庫状態の定義と変更履歴の設計に左右されます。

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

SKU管理システムは、単体の在庫管理、ECの受注・在庫連携、倉庫管理、販売・購買・生産を含む基幹システムなどに分かれます。どれが優れているかではなく、在庫の正本をどこに置くか、現場作業をどこまでシステム化するかで選ぶ必要があります。

EC・小売で使うSKU管理

複数のECモールやカートで販売する場合は、受注を集約し、チャネルごとの在庫を同じSKUへひも付けることが中心課題です。商品ページごとに別コードを作るのではなく、社内SKUを正本として、外部チャネルの商品コードを対応表で管理します。注文の取り込み、引当、キャンセル、返品、出荷完了の各タイミングを定義しないと、連携が動いていても売り越しが発生します。

EC向けでは、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コード、JAN、ECの商品コード、POSコード、倉庫在庫、受注残、仕入先、棚番を集めます。重複コード、表記ゆれ、単位の違い、廃番SKU、同じJANに複数商品がひも付いているデータを洗い出します。成果物は、現行業務フロー、データ項目一覧、SKU変換表、課題一覧です。

ここで「誰が商品を登録し、誰が承認し、どのタイミングで販売可能になるか」を決めます。SKUマスタの所有者が部署ごとに分かれる場合は、採番ルールと変更申請を設けます。移行前のデータクレンジングを省くと、導入後に重複在庫や欠品の原因を新システムの問題と誤認しやすくなります。

要件定義とPoC・MVP

要件定義では、SKU数、拠点数、倉庫数、販売チャネル数、月間受注件数、月間出荷件数、端末台数、ロット・期限の有無、連携数を確定します。機能要件だけでなく、権限、監査ログ、バックアップ、復旧時間、利用時間帯、API制限などの非機能要件も同じ資料に入れます。

いきなり全社展開せず、代表的な100〜500SKU、1拠点、1販路でPoCを行うと、実データで問題を発見できます。入荷、検品、棚入れ、受注引当、出荷、返品、棚卸、差異調整まで一周させ、例外処理を確認します。PoCの成功条件は「画面が動く」ではなく、在庫差異率、棚卸時間、出荷リードタイム、売り越し件数などのKPIで設定します。

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

本番移行では、旧コードと新コードの対応表、移行対象期間、在庫の基準時刻、受注の取り込み範囲、返品・キャンセルの扱いを決めます。移行リハーサルを複数回行い、件数照合だけでなく、特定SKUの在庫明細、ロット、棚番、引当状態まで突合します。連携テストではCSVの文字コード、APIの再送、重複受信、通信断、部分出荷、日跨ぎを実データで検証します。

稼働は1拠点または1ブランドから始め、KPIを確認して拡張します。現場教育は操作説明だけでなく、誤出荷、棚卸差異、返品、在庫調整が発生したときの判断基準まで含めます。切り替え後の問い合わせ窓口、障害時の手動運用、旧システムの参照期間も事前に決めておくと、現場の混乱を抑えられます。

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

費用はSKU数だけでなく、拠点数、販路数、連携数、端末台数、ロット・期限、移行データの品質、導入支援の範囲で変わります。以下は在庫・販売・物流を含む業務システムの一般的な目安であり、税込・税別、端末、バーコードプリンタ、データクレンジング、倉庫作業費は別途確認が必要です。

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

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

小規模SaaSは初期設定や移行支援を含めて0万〜30万円程度、月額3,000円〜15万円程度で、標準機能を短期間に使いたい場合に向きます。中堅向けのSaaS・パッケージは、設定、教育、連携を含めて初期30万〜300万円程度、導入1〜4か月が目安です。公開料金のあるサービスでは、初期費用無料や30日間の試用期間を設けている例もあります。

独自要件を含むMVPのスクラッチ開発は300万〜1,000万円程度、3〜6か月が目安です。EC・WMS・ERP連携を含む中規模開発は1,000万〜3,000万円程度、6〜12か月、全社基幹や複雑な受発注・生産連携は3,000万円〜1億円超、12〜24か月以上になる場合があります。これらは公開統計ではなく、人月単価と一般的な工数から算出した推定レンジです（出典: 業務システム開発の人月単価・工数を基にした2026年時点の試算）。

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

見積書では、要件定義、マスタ整備、画面・API設計、実装、外部連携、テスト、データ移行、教育、稼働後支援を分けて確認します。一般に人件費が総費用の約60〜80%を占め、要件定義は工期の約25%、テストは15〜17%程度という見方があります（出典: 業務システム開発の工数配分に関するQ&A、2026年確認）。要件定義を削ると、後の仕様変更で当初工数の1.3〜1.5倍に膨らむ可能性があるため、安さだけで判断できません。

月額以外には、SKU追加、拠点追加、API回数、ユーザー・端末数、保守時間、データ出力、バージョンアップ、障害対応、解約時のデータ返却が発生します。比較する際は初期費用ではなく、導入後3年間の総額で計算します。月額10万円の差でも、3年間では360万円になるため、利用者数や拠点が増えた場合の料金表まで確認します。

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

選定では、知名度や機能数ではなく、自社の在庫業務を正しく再現できるかを見ます。SaaSは短期導入と標準化に強く、パッケージは業務テンプレートを使いやすく、スクラッチは独自要件に柔軟です。既存サービスと独自SKUマスタ・APIハブを組み合わせるハイブリッドも、コア在庫を安定させながら差別化部分を追加しやすい選択肢です。

業務適合性と実績の確認

候補を比較するときは、自社と近いSKU数、拠点数、出荷件数、業界、商材の実績を確認します。実績の件数だけでなく、商品マスタの所有者、ロット・期限、セット品、返品、部分出荷、棚卸差異に対応したかを聞きます。デモでは、きれいなサンプル画面ではなく、自社の代表SKUを使って入荷から返品までを通しで操作してもらいます。

ベンダーに渡すRFPには、SKU数、月間入出荷、拠点、販路、外部システム、端末、移行件数、ピーク時の処理量を記載します。さらに、欠品、キャンセル、返品、ロット切替、在庫マイナス、通信断、二重送信のテストを提案書に含めるよう依頼します。同じ条件で2〜3社から見積もりを取ると、機能の抜けと費用の違いを比較しやすくなります。

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

導入支援の範囲は、初期設定だけか、データ移行、現場教育、稼働立ち会い、運用設計まで含むかで変わります。障害時の受付時間、復旧目標、バックアップ頻度、メンテナンス通知、バージョンアップ方針、APIの仕様変更も確認します。サービスを導入した後に自社で運用できるよう、設定値、マスタ項目、連携仕様、テスト結果を成果物として受け取れるかも重要です。

受託開発では、ソースコードや設計書、API仕様、インフラ設定、テスト証跡、データ返却方法の扱いを契約に明記します。顧客や配送先の情報を扱う場合は、委託先の選定、秘密保持、再委託の事前報告・承認、事故時の連絡、契約終了時の返却・削除、監査の方法まで確認します。個人情報保護委員会も、委託先の安全管理措置を事前確認し、再委託先を含む取扱状況を把握することを示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

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

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

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

SKU管理システムは在庫だけでなく、仕入価格、取引先、顧客、配送先、担当者情報に触れることがあります。導入時に「クラウドだから安全」「社内システムだから安全」と決めつけず、業務データの範囲とアクセス経路を整理します。中小企業向けの情報セキュリティ対策ガイドライン第4.0版は2026年7月に最終更新され、クラウドの安全利用やバックアップも扱っています（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」、2026年7月）。

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

権限は、管理者、商品マスタ担当、倉庫担当、店舗担当、閲覧者などの役割ごとに最小限で設定します。価格や原価を見られる人、在庫調整ができる人、CSVを出力できる人を分け、退職・異動時にすぐ停止できる運用を作ります。多要素認証、通信・保存データの暗号化、IP制限、操作履歴、マスタ変更履歴、在庫調整理由を確認します。

バックアップは「取っているか」だけでなく、復元できるかを確認します。復旧目標（RTO）と、どの時点まで戻せるか（RPO）を決め、定期的に復元訓練を行います。APIキーの保管、障害通知、ログの保存期間、データのエクスポート、解約時のデータ返却・削除もRFPの非機能要件に含めます。

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

よくある失敗は、旧Excelを残したまま新システムにも入力し、数字が合わなくなることです。Excelを使う場合は、参照専用、移行用、例外申請用など目的を限定し、日常の在庫更新をどちらで行うかを一つに決めます。商品登録、在庫調整、返品処理、棚卸承認の責任者と代替担当も明確にします。

運用開始後は、在庫差異率、欠品率、売り越し件数、棚卸時間、出荷リードタイム、返品処理時間を月次で確認します。数値が悪化したら、システムの機能不足だけでなく、SKUコードの重複、検品漏れ、連携遅延、現場ルール違反を分解して原因を特定します。KPIと改善会議を運用に組み込むことで、導入効果を継続的に高められます。

よくある質問

SKU管理システムを比較するときに多い疑問を、導入判断に必要な観点から回答します。自社の要件に当てはめ、候補サービスや開発会社への質問事項として活用してください。

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

少数SKUで拠点と販路が少ない場合は、Excelで台帳を始めることもできます。ただし、同時編集、入出庫履歴、引当、返品、ロット・期限、複数チャネルへの即時反映が必要になると、入力の重複や更新漏れが起きやすくなります。Excelで管理しているうちに、SKU数、更新頻度、差異件数を記録し、システム化の判断材料にします。

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

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

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

標準的な入出庫、棚卸、権限、ログを短期間で使いたいならSaaSやパッケージが向いています。独自の引当、複雑な構成品、特殊な承認、既存基幹との深い連携が競争力に直結するなら、スクラッチやハイブリッドを検討します。最初から全機能を作るのではなく、標準機能で足りない要件の価値と保守負担を比べて決めます。

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

最も重要なのは、旧コードと新コードの対応表、基準時刻、在庫の状態、ロット・期限、廃番の扱いを先に確定することです。件数だけを移行しても、親商品とSKUの関係や単位が崩れていれば、発注や出荷で誤りが起きます。移行リハーサルを行い、代表SKUの明細と全体件数を突合し、差異を説明できる状態で本番へ進みます。

まとめ

SKU管理システムは、商品名を一覧化するためのツールではなく、SKUマスタと在庫状態・履歴を軸に、受注、発注、入出庫、出荷、返品、棚卸をつなぐ業務基盤です。導入前にSKUと商品コードの違い、在庫の正本、ロット・期限、セット品、連携境界を決めると、機能比較や見積もりの精度が上がります。

導入前に整理する5つの項目

最初に、SKU数・拠点数・販路数・月間出荷件数・端末台数を数えます。次に、ロット・期限・セット品・ケース単位の有無、外部システムとの連携方式、マスタの所有者、在庫確定タイミングを定義します。最後に、初期費用だけでなく3年総額、移行範囲、保守、復旧、データ返却を含む条件で比較します。

小さく試し、KPIで広げる

候補を決める前に、代表的なSKUと実際の業務シナリオでPoCを行い、入荷から返品・棚卸までを確認します。稼働後は在庫差異率、欠品率、売り越し件数、棚卸時間、出荷リードタイムを測定し、効果が確認できた拠点やブランドから段階的に展開します。SKU管理を業務ルールとデータ品質の改善まで含めて進めることで、システムを長く使える基盤にできます。