複数モールで在庫は共通、販売価格はモールごとに変えたいとき、どこで何を管理するか

対象と結論

同じ商品を自社のShopifyと楽天市場などのモールに並べている店が対象です。在庫は一つ。でも販売価格まで同じにするとは限らない。モールの手数料やポイント分を価格に乗せる、自社ショップだけ会員価格を出す、といった理由で、販売先ごとに違う価格を持ちたくなります。ところが在庫と価格を同じ経路で流すと、片方で直した価格がもう片方を上書きしたり、在庫だけ流したいのに価格まで揃ってしまったりする。

在庫と価格で管理元を分ける。それがこの記事の答えです。分けるだけ。在庫は一つの管理元から各販売先へ一方向に流し、モール側では触らない。販売価格は販売先ごとに別の管理元で持ち、モール同士で同期させない。この二つを項目ごとの表にしておくと、標準機能と商品一覧の表（CSV）の手作業で足りるのか、一元管理サービスや自作が要るのかが、表の空欄から見えてきます。

運営者の時計店 Timeseek（timeseek.net）では、一点物を複数の販売先に出すときにこの問題に当たりました。同じ個体は一度しか売れないので在庫は共通にしたい。一方で価格は販売先ごとに変えたい。この記事はそのとき決めた「どの項目を誰が更新し、取消や返品でどう戻すか」の整理で、売上や件数の実績を示すものではありません。モールごとに在庫を分けて持ちたい店や、販売先が自社ショップだけの店には当てはまりません。

条件を確認

自分の店に当てはめる前に、次の5点を書き出します。

1. 販売先: 自社ショップのほかに、どのモールに出しているか。今後増やす予定はあるか
2. 更新元: 在庫を減らす・増やす操作はどこで起きるか（受注、入荷、棚卸、店頭販売）
3. 頻度: 一日の注文件数と、在庫が動く回数。同じ商品が別の販売先で同じ日に売れることがあるか
4. 取消・返品: 注文の取消と返品が月に何件あり、在庫へ戻す判断を誰がしているか
5. 既存の一元管理: すでに契約している在庫連携や受注管理のサービスがあるか。あるなら、価格も同期する設定になっていないか

4番目を軽く見ると、あとで効いてきます。取消はすぐ在庫に戻してよい。返品は違います。商品が戻ってきて状態を確かめるまで戻せない。この二つを同じ「在庫を戻す」で扱うと、検品前の商品がモールに再出品されます。一点物なら、そのまま二重販売の入口です。

項目の管理元・更新方向・例外処理

項目ごとに「どこが正か」「どちら向きに流すか」「決まりから外れたときにどうするか」を一行で決めます。次の表は、自社ショップ（CH-A）と一つのモール（CH-B）の2販売先を想定した例です（架空データの例）。

空欄が残る行が、まだ決めていない部分です。空欄は宿題です。とくに「例外処理」が空の行は、手動運用でもサービス導入でも、そこで止まります。

一点物の在庫の状態は四つ

在庫が1点しかない商品は状態の数が少ないので、状態の移り変わりを表にできます。管理元の在庫と、注文が入っていない側の販売先の表示を並べます。

「発送済み」から返品で戻すとき、自動で販売中へ戻さない。この一行がこの表の要点です。返品された一点物は検品して初めて売れる状態に戻るので、在庫の数字だけ先に1へ戻すと、傷が増えた商品を元の説明のまま売ることになります。

注文・取消・障害で在庫がどう動くかを、10件のテストで確かめる

在庫は「販売可能」から注文で「引当中」へ移り、出荷で「出荷済み」になります。取消は「引当中」を「販売可能」へ戻す。返品は「出荷済み」を「検品中」へ移し、確認後に「販売可能」か「販売不可」のどちらかへ進める。この流れを崩す操作が、次の表の異常系です。

Timeseek で扱うような時計を想定した例の3商品で、期待結果と失敗したときの症状を並べます（架空データの例）。データ上の名前は DEMO-101〜103 で、DEMO-101は在庫1の一点物、DEMO-102は在庫3、DEMO-103は在庫0で、CH-Bの販売価格はどれもCH-Aより高く登録してあります。

T3とT5とT8が、この記事で名前を挙げる失敗条件です。同時注文を先着で処理する仕組みがなければ、一点物は手動運用でもサービス導入でも二重販売が起こりえます。反映が5分おきなら5分の間、1分おきなら1分の間は、どの方法でも起こる。連携で防げるのは反映間隔の外側だけなので、内側は取消の手順で受け止めます。返品を受け付けた時点で自動的に在庫へ戻す設定も、一点物や中古品では切ります。厄介なのはT8です。連携が黙って止まり、誰も気づかないまま数日たつと、売り切れのはずの商品がモールで売れます。

連携が要るかどうかの目安

五つの条件を埋めたら、次の順で判断します。これは筆者の目安で、店ごとの実測から引いた境界ではありません。

• 販売先が Shopify 一つなら、連携は要らない。標準の在庫数だけで足りる
• 販売先が二つ以上でも、注文が日に数件で、担当者が一人で営業時間内に処理できるなら、手動のルールで始め、T1・T4・T8を人の手で確かめる
• 営業時間外にも注文が入る、担当者が複数いる、販売先が三つ以上になったら、一元管理サービスか自作の連携を比較する
• 販売先ごとに価格を変える、商品コードの付け方が販売先で違うなど、標準の連携に収まらない条件があるなら、自作か依頼の範囲を先に切り分ける

五つの条件は店舗の条件を整理するに入れておくと、比較へ持ち越せます。店舗名やメールは要りません。

無料・標準機能で足りる場合

一日の注文が数件で、同じ商品が別の販売先で同じ日に売れることがまれな店なら、仕組みは要らない場合があります。決まりで足ります。管理元を Shopify の在庫に決め、モール側の在庫を日に一度、商品一覧の表（CSV）か手入力で合わせる。販売価格はもともと各モールの管理画面で別々に登録するので、流さなければそれだけで別管理です。必要なのは仕組みより決まりです。「モール側で在庫を直接触らない」「取消はすぐ戻す、返品は検品後に戻す」の二つを紙一枚に書き、更新する人と時刻を決めます。

Shopifyの標準機能で販売先ごとの価格や在庫をどこまで扱えるかは、対象モールと現行の仕様で変わります。この記事では検証していないので、複製した環境で先に試します。

足りないと分かるのは、次の場合です。同じ商品が別の販売先で同じ日に売れる。手入力の遅れで売り越しか欠品表示が起きた。販売先が3つ以上になった。すでに一元管理サービスを契約していて、価格まで同期する設定になっている。どれかに当てはまったら、次の比較に進みます。

比較

同じ表と同じ10件のテストを、標準機能・サービス・自作・依頼のどれで満たすかの比較です。料金は公式ページで読んだものを確認日つきで書き、見直しは30日ごとです。

一元管理サービスを候補にするのは、販売先が増えたか、同時注文が現実に起きているか、すでに契約しているかのどれかです。候補に問い合わせるときは、上の表の7行をそのまま質問にします。価格の同期を切れるか、返品を自動で在庫に戻さない設定があるか、同時注文をどう扱うか。この3点は、導入前に文書で答えをもらいます。

料金は課金単位から確認します。ネクストエンジンは公式の料金ページに、基本料金3,000円（税抜）で受注200件まで、初期費用0円、30日間の無料トライアルと書かれています（確認日 2026-09-09。超過分の単価は同じページで確認）。CROSS MALL は「月額固定で受注件数や金額による課金はない」と本文にあり、金額は画像で本文にないので未確認のままです。両社とも、初期設定やサポート、モール接続の追加が含まれるかを確認日と有効期限つきで記録し、期限が切れた料金で計算しません。同じ期間と件数で構成を並べる構成と費用を比べる計算機（架空例）は、この整理の練習に使えます。CROSS MALL とネクストエンジンについて、運営者の提携は未確認で、紹介リンクは置かず、末尾に開示を載せています。

進め方は一つ選びます。一元管理サービスを入れるなら、上の表の10行をそのまま質問にして、ネクストエンジンか CROSS MALL の公式ページで対応範囲と料金を確かめてから申し込みます。提携が確認できたら、ここに通常のリンクと区別した紹介リンクを置きます。Claude Code で自分で作る場合と、社内や今の開発先に渡す場合の資料は、上の管理元の表と10件のテストを架空データで動かす実装資料にまとめる予定で、まだ作成していません。できしだい、この記事の下に載せます。それまでは実装資料の一覧にある他の記事の資料が型の参考になります。どちらも表と10件のテストを先に渡し、T1から一件ずつ通しながら進めます。設計に迷う場合だけ、相談から条件を送れます（任意。受託は初期の範囲外です）。資料はどの進め方でも同じもので、見るのに登録も紹介リンクの利用も要りません。

導入・検証・戻し方

本番の在庫と価格は書き換えず、複製した環境か架空データで進めます。実行ログのない手順は提案です。

1. 販売先ごとに、在庫と価格をいまどこで更新しているかを書き出し、管理元の表の空欄を埋める
2. 価格の同期があれば切り、在庫だけを管理元から各販売先へ流す設定にする
3. 例の3商品（DEMO-101〜103）を、本番とは別の試し用の環境に登録し、T1〜T10を順に実行して結果を記録する
4. 実行できない項目は「未実行（not_run）」と記録し、本番のモールの口座が要る項目は「外部待ち（blocked_external）」と書く
5. 変更した設定とファイルの一覧を作り、本番の在庫・価格に触れていないことを確かめる
6. 本番の切り替えは、T3・T5・T8の結果と戻し方の共有が済んでから、別の承認で行う

戻し方は一つです。連携を止めてから管理元の在庫数を商品一覧の表（CSV）で各販売先へ手で反映します。価格は連携に載せていないので、戻す対象に入りません。一元管理サービスを外す場合は、解約後にモール側の在庫が更新されなくなる時刻を確かめ、その時点の在庫数を記録してから手入力へ戻します。本番の戻し作業は自動で走らせず、対象と影響を確かめてから手で行います。

検証と制約

実店舗での検証は未実施です。管理元の表、状態の表、10件のテストは、架空の2販売先と3商品で作った架空データの例で、Timeseekや他店の実績ではありません。二重販売や欠品表示が何件減ったかは測っていないので、効果を数字では示せません。

ネクストエンジンと CROSS MALL について、この記事で確認日つきで書いたのは、公式ページの料金の記載と、対応モール一覧で Shopify が「受注のみ」と書かれていることまでです（2026-09-09）。在庫を Shopify から流せるか、価格の同期を切れるか、返品を自動で戻さない設定があるかは、両社とも未確認で、契約前に文書で確かめます。紹介制度のページが公開されていることは確認しましたが、運営者の提携、報酬、新規対象の条件は確認していません。ネクストエンジンには一般向けの紹介制度と事業者向けのパートナー制度が別にあり、この記事ではどちらも案内しません。この記事に紹介リンクはありません。将来置くとしても、通常のリンクと区別する属性を付けます。

Shopify と各モールをつなぐ仕組み（API）や標準機能で、価格を除いて在庫だけを流せるかは、現行の仕様を検証環境で確かめるまで断定しません。公開している商品ページに検索エンジン向けの裏側のデータ（構造化データ）を出している場合は、その販売先の価格と在庫を画面と一致させます。販売先ごとに価格が違っていても、自社ページの構造化データに載せるのは自社ページの価格だけです。

出典

• G01: 役に立つ、人を第一にしたコンテンツ（Google、確認日 2026-09-07）
• G02: Google Web Search spam policies（Google、確認日 2026-09-07）
• G06: CROSS MALL partner（CROSS MALL、確認日 2026-09-07。公開ページの確認のみで、本人提携は未確認）
• G07: ネクストエンジン Business Partner（ネクストエンジン、確認日 2026-09-07。公開ページの確認のみで、本人提携は未確認）
• G08: ネクストエンジン 紹介制度（ネクストエンジン、確認日 2026-09-07。一般向けの別制度で、この記事では案内しない）
• P11: CROSS MALL 料金プラン（CROSS MALL、確認日 2026-09-09。月額固定の記載。金額は画像で未確認）
• P12: ネクストエンジン 料金（ネクストエンジン、確認日 2026-09-09）
• P13: ネクストエンジン 対応モール・カート（ネクストエンジン、確認日 2026-09-09。Shopify は受注のみ）
• V301: Google Search generative AI optimization guide（Google、確認日 2026-09-07）
• V306: Structured data general guidelines（Google、確認日 2026-09-07）
• V308: Qualify outbound links（Google、確認日 2026-09-07）
• V323: Google merchant listings（Google、確認日 2026-09-07）
• S12: Claude Code best practices（Anthropic、確認日 2026-09-06）

紹介関係の開示: この記事で名前を挙げたCROSS MALLとネクストエンジンについて、運営者の紹介提携は未確認です。紹介リンクは置いていません。資料を見るのに登録や紹介利用は要りません。