対象と結論

自社のShopifyに加えて、楽天市場やAmazonのようなモールにも同じ商品を出している店が対象です。販売先が増えると、在庫を減らす場所、価格を変える場所、注文を受け取る場所がばらばらになり、どれが正しい数字かを人が覚えておく運用になります。CROSS MALLとネクストエンジンは、その状態を一つの管理画面にまとめる候補として名前が挙がる二つです。

結論は、機能の一覧で二つを見比べる前に、価格・在庫・受注のそれぞれについて、どこの数字を正しいとみなすか（正の置き場）と、そこからどこへ流すか（流す向き）を自分の店で決めることです。向きが決まれば、比較の質問は「この向きに沿えるか」の一つに絞れます。決まっていないまま機能表を眺めても、どの行が自分に効くのか判断できません。向きが先です。

販売先が一つしかない店、または販売先が二つでも在庫の増減を手で反映できている店に、一元管理ツールは要りません。入れると更新の経路が一本増えるだけです。増えるだけ。

この要件は、運営者の時計店 Timeseek（timeseek.net）で、自社サイトとモールの在庫は共有し、販売価格は販売先ごとに別に持つ、と決めたときに出てきたものです。売上がどうなったという話ではありません。どの項目をどこで直し、どこへ流し、ずれたときにどう気づくかを決める手順です。両サービスの機能がこの向きに沿えるかは、この記事では未確認です。確かめる手順を本文に置きます。

条件を確認

自分の店に当てはめる条件を五つ挙げます。

  1. 販売先: 自社Shopifyのほかに、同じ商品を出す販売先がいくつあるか
  2. 更新元: 価格・在庫・商品情報を、今どこで直しているか。Shopifyか、モールの管理画面か、手元の表か
  3. 頻度: 在庫の増減と価格の変更が、日に何回、どの販売先で起きるか
  4. 取消・返品: 注文の取消や返品で在庫を戻す作業を、誰がどこでしているか
  5. 既存の一元管理: 受注管理や倉庫のシステムをすでに使っているか。使っているなら、そこが正か

2番目と4番目で、自分の店の「向き」が見えてきます。価格はモールの管理画面で直しているのに、在庫はShopifyで減らしている店は珍しくありません。それ自体は問題になりません。ただ、向きを書き出していないと、ツールを入れたときにどちらが上書きされるかを説明できません。

価格・在庫・受注の更新方向比較

下の表は、項目ごとに正の置き場と流す向きを決め、その向きに反したとき何が起きるかを添えたものです。埋め方は店ごとに違います。行の中身は Timeseek の運用を元にした一例で、正解ではありません。

項目正の置き場流す向き更新のきっかけ向きに反すると起きること
在庫数ShopifyShopify → 各モール注文、入荷、棚卸モール側で手で在庫を直すと、次の同期で元に戻るか二重に減る
販売価格販売先ごとに別流さない販売先ごとの改定一括で流すと、モールの手数料や送料込みの調整が消える
受注各販売先各モール → 一元管理 → Shopifyの在庫注文確定受注が在庫に届かないと、次の注文が売り越しになる
商品情報（名称・画像）ShopifyShopify → 各モール（初回だけ）新規登録毎回流すと、モール向けに書き分けた説明が上書きされる
取消・返品注文を受けた販売先各モール → 一元管理 → Shopifyの在庫取消確定、返品受領在庫が戻らず、一点物が売れないまま残る

この表で肝心なのは価格の行です。「流さない」も向きの一つです。空欄にしない。ここを空欄にしたまま「価格も同期できます」という説明を聞くと、そのまま受け入れてしまいます。在庫は共有しても価格は共有しない、という運用は、ツール側にその設定があるかどうかを先に確かめる項目になります。

在庫の動きと正常・異常のテスト表

向きを決めたら、在庫1の商品で何が起きるかを追います。Timeseek で扱うような時計を想定した例の3商品（データ上の名前は DEMO-IV-001〜003）で並べると次のようになります（架空データの例）。

商品起きたこと期待する状態確認する場所
DEMO-IV-001（在庫1）Shopifyで注文確定各モールの在庫が0になり、購入できない各モールの商品ページ
DEMO-IV-002（在庫1）モールAで注文確定の直後に、Shopifyでも注文二件目が受け付けられない、または受け付けた時点で検知される一元管理の受注一覧と通知
DEMO-IV-003（在庫1）モールAで注文後に取消在庫が1に戻り、全販売先で再び購入できるShopifyの在庫と各モールの商品ページ
DEMO-IV-001（価格改定）Shopifyだけ価格を変更モールの価格は変わらない各モールの商品ページ

DEMO-IV-002が失敗条件です。ここで売り越します。同期が数分おきなら、その数分の間に二つの販売先で同じ一点物が売れます。同期の間隔をどこまで縮められるかはツールごとに未確認で、間隔がある限りこの窓は残ります。売り越しをゼロにする機能があるかではなく、売り越しが起きたときに何分以内に、誰に、どう知らせるかを確かめる項目です。

受け入れテスト

  • IV01-AT1: DEMO-IV-001をShopifyで受注したあと、各モールの在庫が0になる
  • IV01-AT2: DEMO-IV-002の二件目が受け付けられないか、受け付けた時点で通知される
  • IV01-AT3: DEMO-IV-003の取消後に在庫が1に戻り、全販売先で購入できる
  • IV01-AT4: 価格をShopifyで変えても、モールの価格が変わらない
  • IV01-AT5: 連携を止めたあと、Shopifyの在庫数が連携前と一致する

実行していない項目は「未実行（not_run）」と記録し、本番のモール接続が要るものは「外部待ち（blocked_external）」と書きます。この記事の時点では5件とも未実行です。

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

無料で済むのは、在庫の正をShopifyに置き、モール側の在庫を手で合わせる運用が回っているうちです。目安は更新の回数で、在庫の増減が週に数件、価格改定が月に一度なら、手で直しても向きは崩れません。Shopifyの管理画面で在庫数を持ち、モールには売れた分だけ手で反映し、価格は販売先ごとに管理画面で別に持つ。ツールなしでも、上の表の向きはそのまま作れます。Shopify側の販売チャネル連携で対象のモールへ在庫を流せるかは、この記事では未確認です。使えるなら手作業の代わりになるので、有料の候補より先に公式資料で確かめます。

手で回らなくなる合図も表から読めます。同じ日に二つの販売先で在庫が動く商品が出てきた。取消の在庫戻しを忘れて、一点物が売れないまま残った。価格改定のたびに三つの管理画面を開いている。どれか一つでも月に何度も起きるなら、契約か実装の検討に進みます。

すでに一元管理ツールを契約している店は、新しいサービスを比べる前に、今の契約に販売先を足せるかと、その加算額を確認します。既存の利用を新しい契約と同じ土俵で数えない、というのがこの記事の前提です。既存のシステムがある店は、そこを正にしたまま何が足りないかを書き出します。受注管理を別のシステムで済ませている店に受注機能つきのツールを重ねると、受注の正が二つになります。

比較

上の表の向きを、標準機能・アプリやサービス・自作・依頼のどれで作るかの比較です。CROSS MALL とネクストエンジンについて公式ページで確認日つきに読めたのは、対応モール一覧と料金ページの記載までで、機能ごとの可否は未確認と書いています。料金は公式ページで確認し、この記事には書きません。

条件標準機能アプリ・サービス自作依頼
在庫をShopifyからモールへ流す手で反映。Shopifyの販売チャネル連携で対象モールへ流せるかは未確認ネクストエンジン: 対応モール一覧で Shopify は「受注のみ」、自動連携にはアプリが必要と記載（確認日 2026-09-09）。在庫の向きは契約前に確認。CROSS MALL: 対応カート一覧は未確認各モールをつなぐ仕組み（API）の利用条件を確認対応範囲に含む
価格を流さず販売先ごとに持つ管理画面ごとに設定未確認対応対応
受注をまとめて在庫に戻す手で反映未確認対応対応
取消・返品で在庫を戻す手で反映未確認対応対応
売り越し時の検知と通知なし未確認通知先を実装通知先を設計
対応する販売先全て手作業未確認各モールへの接続申請次第見積もり時に確認
追加費用既存契約の範囲ネクストエンジン: 基本料金3,000円/月（税抜、受注200件まで）、初期費用0円、30日無料。CROSS MALL: 月額固定・受注課金なしの記載、金額は未確認。確認日 2026-09-09作業時間と接続の利用条件見積もり
戻し方手作業に戻す解約後に在庫の正がどちらに残るかは未確認連携を止めてShopifyの数を正にする手順を納品
実店舗での検証未実施未実施未実施未実施

料金を比べるときは、金額より先に課金の単位を見ます。ネクストエンジンは公式の料金ページに、基本料金3,000円（税抜）で受注200件まで、初期費用0円、30日間の無料トライアルと書かれています（確認日 2026-09-09。受注件数の超過分の単価は同じページで確認）。CROSS MALL は「月額固定で受注件数や金額による課金はない」と本文にあり、金額は画像で本文にないので未確認のままです。初期費用と月額に何が含まれ、税込か税別か、モール接続の追加や受注件数の超過が含まれないか。そして、その料金をいつ確認し、いつまで有効かを一緒に控えます。確認日のない料金で合計を出しても、次の月には比べ直しになります。架空の料金で構成ごとの合計を並べる計算機は構成と費用を比べる（架空例）にあり、未確認の項目を0円にせず、確認期限が切れた料金では合計を止める作りにしてあります。

課金単位と追加料金の明細計算（新しく契約する場合）

料金ページの数字を、そのまま自店の月額にしないための表です。左から順に、公式ページで確認した課金単位、自店の数量、基本料に含まれるか、確認日と有効期限を埋めます。単価の欄は設けていません。金額は公式ページで確認し、この記事には書きません。

明細項目課金単位（公式ページで確認）自店の数量（架空データの例）基本料に含む／含まない確認日・有効期限
初期費用契約1件1件初期設定の代行を含むか自店で記入
月額基本料契約1件、月ごと12か月何商品・何件・何販売先まで含むか自店で記入
商品数の超過商品またはSKU商品1,200点、SKU 1,800商品とSKUのどちらで数えるか自店で記入
受注数の超過受注1件、月ごと通常月300件、繁忙月480件取消・返品を件数に含むか自店で記入
販売先の追加販売先1つ、月ごと3（Shopify、楽天市場、Amazon）自社ストアを1つと数えるか自店で記入
利用ユーザーの追加1人、月ごと2人閲覧だけの人を含むか自店で記入
追加機能機能ごと販売先別の価格管理基本料に含むか自店で記入
設定代行・有償サポート回、または月ごと未確認未確認自店で記入

年間の見積もりは、初期費用と月額12か月分の合計です。月額は、基本料に商品数・受注数・販売先・ユーザー・追加機能の超過分と追加分を足した額。受注数は月で変わるので、通常月と繁忙月の2回計算し、幅で持ちます。取消・返品が受注数に含まれる契約なら、受注数に取消の割合を上乗せしてから掛けます。

架空の店の数量で読むと、商品1,200点は年間を通してほぼ横ばいなので、上限超過があれば固定費として扱えます。受注は300件と480件で差があり、ここが従量なら繁忙月の額を上限として見ます。販売先は3。来年もう1つ足すなら、4で計算した列も残しておきます。この数量はどれも架空データの例で、実店舗の値ではありません。

どの単位が効くかは店の形で決まります。一点物の専門店は商品数が多く、受注は少なめです。先に効くのは商品数の上限です。消耗品を繰り返し売る店は逆で、受注数の段階が効きます。販売先を増やす途中の店なら、販売先の加算が月額を押し上げます。自店がどれかを先に決めれば、料金ページで最初に見る欄が決まります。これは提案で、サービスごとの課金単位はこの記事で確認していません。

同じ数量で「標準機能のみ」「既成サービス」「個別実装」を並べたいときは、構成と費用を比べる計算機が使えます。表示される料金は画面確認用の架空例で、実サービスの価格ではありません。実際に使うには、出典、対象プラン、確認日、有効期限を自分で入れ替えます。

アプリ・サービスの列を埋めるには、公式資料で表の5項目の可否を確かめ、試用があれば架空の3商品で受け入れテストを流します。既存の契約があるなら、それを新規契約として数え直さないことも確認点です。CROSS MALLとネクストエンジンには紹介制度が公開されていますが、運営者の提携は未確認で、この記事に紹介リンクはありません。

進め方は一つ選びます。一元管理サービスを入れるなら、上の表の5項目と明細の埋まらない欄をそのまま質問にして、ネクストエンジンか CROSS MALL の公式ページと問い合わせで確かめてから申し込みます。運営者の提携は未確認で、この記事に紹介リンクはありません。提携が確認できたら、通常のリンクと区別した紹介リンクをここに置きます。Claude Code で自分で作るなら、上の表と受け入れテスト5件が要件の下書きにあたります。要件・例の3商品・受け入れテスト・戻し方・Claude Code への指示文がそろった時点でこの記事の下に載せますが、現時点では未作成です。型は実装資料の一覧にある他の記事の資料が参考になります。社内や今の開発先へ渡す場合も同じ資料を使います。設計に迷う場合だけ、相談から条件を送れます（任意。受託は初期の範囲外です）。どの方法でも、資料を見るのに登録や紹介リンクの利用は要りません。

導入・検証・戻し方

以下は手順の提案で、実行ログはありません。本番のモール接続で試した記録ができた時点で、この節を実測に差し替えます。

  1. 更新方向比較の表を自分の店の項目で埋め、価格の行に「流す」か「流さない」かを書く
  2. 候補のツールについて、表の5項目の可否と、売り越し時の通知の仕組みを公式資料で確かめ、確認日を残す
  3. 試用または検証用の環境で、例の3商品（DEMO-IV-001〜003）を登録し、受け入れテスト5件を流す
  4. 実行できなかった項目は「未実行（not_run）」、本番接続が要る項目は「外部待ち（blocked_external）」と記録する
  5. 連携を止める手順と、止めたあとに在庫の正をどちらに置くかを、本番接続の前に決めておく
  6. 本番につなぐのは、テスト結果と戻し方の共有が済んでから

戻すときの原則は一つです。連携を止めた瞬間に、Shopifyの在庫数が正であり続けること。それだけです。連携中にモール側で直した在庫があると、止めたあとにどちらが正しいか分からなくなります。連携を止める前に全販売先の在庫数を一覧にし、Shopifyの数と突き合わせてから止めます。順番は逆にしません。商品データを書き換えた場合は、控えを取って内容を照らし合わせてから戻し、本番の戻し作業を自動では走らせません。

検証と制約

実店舗での検証は未実施です。この記事の更新方向比較、在庫の動きの表、受け入れテストは、例の3商品で作った架空データの例で、Timeseekや他店の実績ではありません。導入前後の売り越し件数や作業時間は測っていないので、効果の数字も書いていません。

ネクストエンジンと CROSS MALL について確認日つきで書けたのは、料金ページの記載と、ネクストエンジンの対応モール一覧で Shopify が「受注のみ」と書かれていることまでです（2026-09-09）。在庫だけを流して価格を流さない設定、取消時の在庫戻し、売り越し時の通知、解約時の在庫の扱いは、両社とも未確認で、それぞれの公式資料と現行プランで確かめる項目として残しています。対応する販売先の範囲と、既存契約がある場合の扱いも同じです。

紹介制度については、CROSS MALLの販売パートナー制度と、ネクストエンジンのBusiness Partner制度が公式ページで公開されていることを確認しました。ネクストエンジンにはギフトカードによる一般の紹介制度が別にあり、二つを混同しません。運営者の提携、報酬、新規対象の条件はいずれも未確認で、この記事に紹介リンクはなく、置く場合は通常のリンクと区別する属性を付けます。

価格を販売先ごとに変える運用では、各販売先の表示価格と在庫が実態と合っていることが前提になります。Shopify 側で商品の検索エンジン向けの裏側のデータ（構造化データ）を出している場合は、画面に見える価格・在庫と一致させます。

この記事の検索意図（CROSS MALL ネクストエンジン 比較）は、需要を数値で確認していない仮説です。検索数・順位は未取得のまま、pilot記事として置いています。

出典

  • G06: CROSS MALL partner（CROSS MALL、確認日 2026-09-07。公開されている販売パートナー制度の確認のみで、本人提携は未確認）
  • G07: ネクストエンジン Business Partner（ネクストエンジン、確認日 2026-09-07。公開されている制度の確認のみで、本人提携は未確認）
  • G08: ネクストエンジン 紹介制度（ネクストエンジン、確認日 2026-09-07。ギフトカードの一般紹介制度で、Business Partnerとは別）
  • P11: CROSS MALL 料金プラン（CROSS MALL、確認日 2026-09-09。月額固定の記載。金額は画像で未確認）
  • P12: ネクストエンジン 料金（ネクストエンジン、確認日 2026-09-09）
  • P13: ネクストエンジン 対応モール・カート（ネクストエンジン、確認日 2026-09-09。Shopify は受注のみ）
  • G01: 役に立つ、人を第一にしたコンテンツ（Google、確認日 2026-09-07）
  • G02: Google Web Search spam policies（Google、確認日 2026-09-07）
  • 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）

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