ECでは、商品名、商品説明、SKU、JANコード、価格、商品画像、在庫数、重量・サイズ、発送日数、返品条件、販売状態など、一つの商品を販売するために多くの情報を登録します。これらの情報は、商品を作ったサプライヤーでしょうか、販売者でしょうか、運営会社でしょうか、それとも倉庫でしょうか。答えは、項目によって異なります。原材料や製造方法を最もよく知っているのはサプライヤー、販売価格を決めるのは販売者、倉庫にある数を最も早く確認できるのは倉庫です。ただし、詳しい人が自由にECサイトを書き換えればよいわけではありません。「情報を作る人」「入力する人」「内容を確認する人」「公開・変更を承認する人」の4つを分ける必要があります。

この役割が曖昧だと、サプライヤーが価格を勝手に変更した、倉庫が在庫を増やしたが入荷記録がない、運営会社が商品説明を修正し事実と違う内容になった、古いパッケージ画像が掲載された、販売終了商品が購入できる状態だった、誰が変更したか分からない、といった問題が発生します。

この記事で示す役割分担は一般的な運用例です。実際の担当範囲は、売買契約、出店契約、物流契約、プラットフォームの仕様などに合わせてください。

先に結論｜「決める人」と「入力する人」を分ける

たとえば、販売価格を5,000円から5,500円へ変更する場合です。

運営会社が画面へ入力していても、運営会社が価格を決めたとは限りません。倉庫が在庫を更新していても、倉庫が商品の販売方針を決めるわけではありません。

身近な例で考えると「学校の成績表」

学校の成績表には、名前、出席日数、各教科の成績などが載っていますが、一人がすべてを自由に書くわけではありません。生徒の基本情報は学校が管理し、各教科の評価は担当教員が付け、出席日数は出欠記録から集計し、記載内容を担任が確認して学校として配付します。ECの商品情報も同じです。商品の製造者、販売者、倉庫、EC担当者が、それぞれ知っている情報を持ち寄り、誰かが全体を確認して購入者へ公開してよい状態にします。

1．ECに関わる4つの役割

2．まず「誰が正しい情報を持っているか」を考える

すべての項目を、EC運営担当者だけで決めることはできません。項目ごとに、情報源が異なります。

最も詳しい人が情報を提供し、販売者が販売条件として問題ないか確認します。

3．商品名は誰が決める？

商品名には、サプライヤーやブランドオーナーが定める「正式商品名」（例：落花生ペースト120g）と、検索や購入者の理解を考慮した「EC表示用商品名」（例：千葉県産落花生を使った無糖ピーナッツペースト120g）があります。EC表示用商品名は販売者・運営担当が作成しても構いませんが、正式名称と矛盾していないか、原材料・産地を誤っていないか、実際にない特徴を加えていないかを確認します。

4．商品説明は誰が作る？

商品管理サービスには商品説明の下書きを生成する機能がありますが、生成内容の品質と正確性を確認するよう案内されています。AIや外部ライターが作成した文章も、元となる商品情報→説明文の下書き→サプライヤーによる事実確認→販売者による表示確認→公開承認という流れで確認します。

5．商品コード・SKUは誰が設定する？／6．JANコード・GTINは誰が設定する？

商品コードは商品全体を自社内で識別するコード、SKUは色・サイズ・容量など在庫を分ける単位です。基本的には販売者や在庫管理を統括する会社がルールを決めます。一度使用したSKUを変更すると、過去の注文、在庫データ、倉庫、売上集計、ECモール、返品・交換、API・CSV連携に影響するため、担当者だけで決めません。

GTIN・JANコードは、EC運営担当が自由に作る内部コードではありません。GS1 Japanでは、商品のブランドを持つ事業者がGS1事業者コードを使って商品ごとに設定すると説明しています。不明な場合は推測した数字を登録せず、ブランドオーナーへ確認します。

7．販売価格は誰が決める？

購入者へ販売する価格は、原則として販売者が決めます。サプライヤーは仕入価格、希望小売価格、最低発注量、卸条件、価格改定予定を提供できますが、EC上の最終販売価格、送料、値引き、セール期間などは販売契約や事業方針に基づいて販売者が決定します。

ECサービスでは、商品作成・編集、原価編集、販売価格編集、在庫管理などを別々の権限として設定できる場合があります。商品説明を直す担当者に、価格を自由に変更できる権限まで与える必要はありません。

8．商品画像は誰が管理する？

「画像を受け取ったから自由に使える」とは限りません。提供元と使用範囲を記録します。

9．在庫数は誰が更新する？／10．倉庫は販売価格を変更しない／11．販売可能在庫は誰が決める？

入荷、出荷、破損、紛失、返品、廃棄、棚卸し差異など、実在庫が変わる場面を最も早く把握できるのは、実際に商品を受け取り保管し出荷する倉庫です。ただし、倉庫が自由にECサイト上の販売数を直接変更するのではなく、倉庫システムの記録を基準在庫へ連携する方法が一般的です。

倉庫にある実在庫と、ECで販売できる数量は同じとは限りません。

実在庫は倉庫、引当在庫は受注・在庫管理システム、販売不可在庫は倉庫、安全在庫は販売者・在庫責任者が管理し、販売可能在庫はこれらをまとめてシステムで計算します。倉庫だけ、販売者だけで決めるものではありません。

12．重量・サイズは誰が確認する？／13．発送までの日数は誰が決める？

商品本体の重量・縦横高さ・材質・形状は主にサプライヤーが提供しますが、送料計算に使うのは梱包後の重量・サイズであり、箱の大きさ、緩衝材を含む重量、温度帯、使用する配送サービスは主に倉庫・物流担当が確認します。

倉庫が「通常1日で出荷できる」と回答しても、EC上で必ず「翌日発送」と約束できるとは限りません。注文締切時刻、決済確認、繁忙期、検品作業などを考慮し、倉庫が実務上の所要時間を伝え、販売者が余裕を含めた表示条件を決定・承認します。

14．一つの項目を複数の場所で更新しない

サプライヤーの表、運営会社の商品マスタ、ECサイトの管理画面など、同じ商品情報を複数箇所で個別に更新すると、内容が一致しなくなります。

項目ごとに正しい元データを決め、その場所から各システムへ反映します。営業資料は5,000円、商品マスタは5,500円、ECサイトは4,800円という状態を避けます。

15．商品情報の変更フロー

商品情報を変更するときは、口頭やチャットだけで依頼しません。

変更申請には、対象の商品コード・SKU、変更する項目、変更前・変更後、変更理由、適用開始日、緊急度、元となる資料、影響する販売先、依頼者、承認者を記載します（例：対象SKU「JM-001-ST-120」、変更項目「内容量」、変更前150g→変更後120g、理由「パッケージ・商品仕様変更」）。一つの項目変更が、商品名・商品説明・画像・重量・価格・JANコード・倉庫在庫など複数の情報に影響する場合があります。

16．変更の種類ごとに承認者を変える

17．緊急時は「承認を待たず止める」権限も必要

商品に安全上の問題がある、誤った価格で大量注文が入っている、在庫がないのに販売が続いているといった場合は、通常の承認を待たずすぐ販売を止める必要があります。問題発見→商品を一時停止→責任者へ報告→影響する注文を抽出→原因を確認→修正・承認→販売再開という流れで対応し、停止後には必ず理由と操作履歴を残します。緊急時は、公開停止の権限を持つ担当者を複数用意します。

18．権限は必要な範囲だけ付ける

担当業務に必要のない権限を与えないことで、誤操作の範囲を小さくできます。

19．削除より「停止・廃番」を使う

販売終了した商品を完全に削除すると、過去注文、売上、返品、問い合わせ、在庫履歴を追えなくなる可能性があります。そこで「下書き」「確認待ち」「公開予定」「販売中」「一時停止」「在庫切れ」「販売終了」「廃番」「緊急停止」といった状態を用意します。商品削除の権限は、限られた管理者だけにします。

20．RACIで役割を整理する

役割分担を明確にする方法の一つがRACIです。R｜実行担当（実際に作業する人）、A｜最終責任者（最終的に承認・判断する人。原則として一人）、C｜相談先（実行前に意見や確認を求める人）、I｜共有先（完了後に結果を知らせる人）を項目ごとに整理します。

在庫調整、安全在庫、配送方法、緊急販売停止なども同じ考え方で整理できます。この表は一例であり、契約や運営体制に合わせて変更します。

21．小規模ECで一人が兼任する場合／22．担当者が休んでも止まらない体制

小規模なECでは、一人が商品仕入れ・登録・価格設定・在庫管理・出荷・公開確認をすべて担当することがあります。一人で担当すること自体が問題ではありませんが、作業の役割は分けて考えます（午前：登録する立場／午後：確認する立場／公開前：承認する立場）。元資料と登録画面を並べて確認する、登録直後ではなく時間を空けて確認する、公開前チェックリストを使う、変更前データを保存するといった方法が使えます。

商品情報を一人だけが管理していると、休暇や退職時に更新できなくなります。正式な商品マスタ、商品コードのルール、変更申請書、承認者一覧、緊急停止手順、サプライヤー・倉庫連絡先、主担当と副担当を用意します。副担当には、実際に操作できる権限と手順を用意します。名前だけ決めても、ログインできなければ代行できません。

23．変更履歴を残す

商品情報を上書きするだけでは、変更理由が分かりません。変更ID、商品コード・SKU、変更項目、変更前・変更後、変更理由、依頼者、登録者、確認者、承認者、適用日時、影響先を記録します。在庫についても、数量だけでなく調整理由と履歴を確認できる仕組みが有効です。

24．公開前の確認項目

よくある失敗

実際のケースで考えてみよう｜ジャムの内容量とパッケージを変更する

サプライヤーから「いちごジャム150g→120gへ変更、9月1日切替、新パッケージ画像あり、価格見直しが必要」と連絡がありました。

Step5｜関係者が確認：商品仕様はサプライヤー、価格・販売条件は販売者、在庫・梱包は倉庫、画面表示・リンクは運営担当が確認します。Step6｜販売者が公開を承認：承認後、9月1日に新商品を公開します。旧商品は削除せず、在庫終了後に「販売終了」へ変更します。Step7｜公開後に確認：新商品が購入できるか、価格・内容量表示・画像・送料が正しいか、倉庫やモールへ正しく反映されているかを確認します。一つの商品変更でも、4者の情報を合わせる必要があります。

商品情報管理を設計する12の質問

1. 商品情報の正式な提供者は誰ですか？サプライヤー、ブランドオーナーなどを決めます。
2. 商品マスタはどこにありますか？複数の表を正式版にしないようにします。
3. 商品説明を誰が作成しますか？事実情報と販売表現を分けます。
4. 販売価格を誰が決定しますか？入力者ではなく、決定責任者を決めます。
5. 在庫の正式な元データはどこですか？倉庫、在庫管理システムなどを決めます。
6. 梱包後サイズを誰が測りますか？現物と梱包方法を確認できる担当者を決めます。
7. 誰がシステムへ入力しますか？販売条件を決める人と分けます。
8. 誰が入力内容を確認しますか？元資料と照合する担当者を決めます。
9. 誰が公開を承認しますか？購入者に対する販売責任を持つ人を決めます。
10. 緊急停止は誰ができますか？主担当と副担当を設定します。
11. 変更履歴はどこに残しますか？変更前後、理由、承認者を記録します。
12. 担当者不在時は誰が代行しますか？ログイン権限と手順まで確認します。

やってみよう｜承認者診断ツール＆RACI自己診断チェッカー

変更したい項目を選ぶだけで、一般的な運用例における承認者・確認者の目安が分かります。さらに、自社の項目ごとの最終責任者（RACIのA）を選んで、役割分担を自己診断できます。入力内容はこのブラウザにのみ保存され、外部へは送信されません。

アウトプットワーク｜商品情報の役割分担表を作ろう

販売する商品を一つ選んでください。分からない項目は担当者の判断で埋めず、「未確認」と記録してください。

理解度チェッククイズ

よくある質問

今回のまとめ

商品情報と在庫は、一人の担当者が自由に更新するものではありません。今回覚えておきたいポイントは、次の5つです。

1. サプライヤーは商品の事実情報を提供する
2. 販売者は価格・送料・販売条件を決定し、公開へ責任を持つ
3. 運営会社は、承認された内容を商品マスタやECへ登録する
4. 倉庫は、入荷・在庫・破損・梱包など現物に関する情報を更新する
5. 情報提供・登録・確認・承認を分け、変更履歴を残す

商品情報の管理では、誰が画面を操作したかだけを見るのではありません。誰が事実を提供したか→誰が販売条件を決めたか→誰がシステムへ入力したか→誰が内容を確認したか→誰が公開を承認したか。この流れを明確にすることで、間違いが起きたときも、どこを確認すべきか分かります。

獲得バッジ

文：横田和也／解決ドットコム編集部