CROSS MALL（クロスモール）は、複数のECモールやカートにまたがる商品・在庫・受注・発注・仕入を一元管理するクラウド型サービスです。チャネルごとの連携機能、在庫更新のタイムラグ、サイト数に応じた料金、POS・WMSなど外部システムとの役割分担を確認すると、自社に合うか判断しやすくなります。
CROSS MALL（クロスモール）とは？複数ECのバックヤード業務を一元管理するサービス
CROSS MALLは、株式会社アイルが提供するEC運営向けの一元管理サービスです。複数のモールや自社ECを個別に操作するのではなく、商品登録、在庫管理、受注処理、発注・仕入管理などを一つの基盤で扱えるようにします。公式にはASPソフトとも案内されており、複数アカウントでの利用やアカウントごとの権限設定にも対応しています。
対象となるのは、次のようなEC運営のバックヤード業務です。
- 複数店舗への商品登録・編集・複製
- 各チャネルの在庫更新、在庫配分、確保在庫の管理
- 注文ステータス、メール、帳票、送り状用データの管理
- 発注候補、発注書、入荷、発注残の管理
- 店舗別・商品別・カテゴリ別の注文分析
- 実店舗のPOS、卸、基幹システム、WMSなどとの連携
特に、同じ商品を複数の販売先で扱い、店舗ごとの在庫更新や注文処理に手間がかかっている事業者に向いています。一方で、販売計画を自動で立てたり、例外注文をすべて無人で処理したり、倉庫内の作業全体を単独で担ったりするサービスではありません。定型処理をシステムに任せ、判断が必要な注文や現場作業を人や別システムが担当する構成として考えることが重要です。
CROSS MALLで扱える主な業務と、自動化できる範囲
CROSS MALLの機能は、商品を準備し、注文を受け、在庫を補充し、販売状況を分析する流れに沿って見ると理解しやすくなります。自動化できるのは、条件が明確で繰り返し発生する処理が中心です。
商品登録・複製で複数店舗への展開を効率化する
商品情報を一括登録・編集し、店舗ごとの価格や説明などを管理できます。既存店舗の商品を別の店舗へ複製する際は、引き継ぐ項目を対応付けたり、キーワードやURLをあらかじめ設定したルールで置き換えたりできます。
そのため、新店舗の開設やセール時の一括編集では、店舗ごとに同じ情報を入力し直す作業を減らせます。ただし、商品登録に対応していないチャネルでは利用できません。また、複製先の必須項目や審査基準まで自動的に満たす機能ではないため、登録後の確認は必要です。
受注管理と定型処理の自動化
複数チャネルの注文を集約し、注文ステータスの管理、メールの一括送信、受注票・納品書・送り状用データの出力などを行えます。送り状番号を取り込んだ後、発送メールに差し込む運用も可能です。ただし、送り状用データの出力と、送り状発行ソフトや配送会社側での発行処理は分けて考えます。
受注処理では、検索条件と実行する処理をルール化できます。たとえば、入金待ち・出荷待ち・要確認への振り分け、送料や手数料の変更、配送便の変更、ギフト明細の追加などが対象です。実注文がどのように処理されるかを事前にシミュレーションできるため、本番稼働前に条件漏れを確認できます。
通常注文のように条件が明確な注文は自動処理し、住所不備や注文備考など判断が必要な注文は「要確認」に回す、という分担が基本です。住所不備の自動検知・修正、離島の判定、メール便不可商品の具体的な判定方法、ブラックリストとの照合条件については、配送ルールや利用する外部サービスによって確認範囲が変わります。公式サイトで課題として紹介されていることだけを根拠に、各処理が完全自動化できるとは判断しないでください。
発注・仕入とセット品管理で補充・在庫連動を整える
発注点、適正在庫、ロットなどを設定すると、発注候補データを作成できます。仕入先別の発注書発行、予定納期・発注残の管理、入荷数の登録にも対応しています。在庫を発注時に反映するか、仕入時に反映するかを選べるため、納品前の商品を在庫として扱う運用では納期遅延時のルールも決めておく必要があります。発注内容を別担当者が確認してから確定する二重チェックも設定できます。
セット品は、構成する単品と必要数量を登録して管理します。セット商品が売れたときに構成商品の在庫を減らし、単品が売れたときにもセットの販売可能数を調整できるため、単品と福袋、まとめ売り、セール用商品を同時に販売する運用で役立ちます。
たとえば、1セットに商品Aを2個、商品Bを3個使う場合、構成品だけを基準にした販売可能セット数は、AとBの在庫から算出される少ない方が上限になります。SKU、色・サイズ、構成数量の登録を誤ると在庫連動も崩れるため、商品コードとセット構成の整備が前提です。
注文分析を仕入れ・販売施策の判断材料にする
注文データは、全サイト集計のほか、店舗別・商品別・カテゴリ別に確認できます。週推移や期間比較、ベスト・ワースト、滞留在庫の確認にも対応しているため、どの店舗・商品が売れているかを把握し、発注量や販売施策を検討する材料にできます。
これは、分析結果をもとに担当者が仕入れや商品施策を判断するための機能です。利益分析、広告効果の自動判定、需要予測までを標準で行う機能とは限りません。注文分析データの保持期間はオプションを含め最大2年と案内されているため、必要な保存期間や出力方法は事前に確認します。
対応チャネルと機能別の連携範囲をどう確認するか
CROSS MALLは多くのモールやカートに対応していますが、サービス名が一覧にあることと、必要な機能をすべて使えることは同じではありません。導入前には、利用チャネルごとに「在庫」「商品登録」「受注」のどこまで必要かを照合します。
| チャネルの例 | 在庫 | 商品登録 | 受注 |
|---|---|---|---|
| 楽天市場、Yahoo!ショッピング、au PAY マーケット、メルカリShops | ○ | ○ | ○ |
| futureshop、ショップサーブ、makeshop、メルカート、アラジンEC | ○ | ○ | ○ |
| Shopify、BASE、ecforce | ○ | — | ○ |
| Amazon | ○ | 条件付き | ○ |
| Qoo10、TikTok Shop、ANA Mall、JAL Mallなど | ○ | — | ○ |
| EC-CUBE | 条件付き | 条件付き | 条件付き |
| 自社サイト・個別カート | 要相談 | 要相談 | 要相談 |
対応状況は変更される可能性があるため、最新の公式対応モール・カート一覧で確認してください。Amazonの商品登録は、既存カタログに登録済みの商品データを管理する条件があり、新規カタログ作成まで対応するとは限りません。EC-CUBEはバージョンや構成の個別調査が必要です。
条件付き連携・自社サイトでは何を確認すべきか
自社サイトや個別対応のカートでは、次の項目を整理してから相談すると、連携可否と費用を判断しやすくなります。
- 利用中のサービス名とバージョン
- API連携かCSV連携か
- 商品・在庫・受注・出荷のどのデータを連携するか
- 連携方向と更新頻度
- 商品コード、SKU、必須項目の対応関係
- 別途アプリ、初期設定、追加開発が必要か
BカートやShopify（BtoB）のように、連携アプリや別途費用が条件となる場合もあります。対応チャネルの一覧は、契約や追加費用まで含めた一律の利用保証ではありません。
モール・カートの仕様変更時に確認すること
モールやカートの仕様変更に対して、ASP側で更新対応が行われる点はクラウドサービスの利点です。ただし、変更の適用時期や影響する機能はチャネルごとに異なります。商品項目、決済、配送、受注取込などのどこが変わるのか、自社設定の見直しが必要かを、導入後も案内に沿って確認します。
在庫連携の仕組みと運用上の注意
CROSS MALLでは、注文に応じて複数サイトの在庫を更新し、サイトごとの在庫配分や確保在庫を設定できます。在庫連携対応のチャネルを利用し、各店舗の商品・SKUが正しく紐付いていることが前提です。
更新時間を踏まえて少量在庫を配分する
在庫更新は、注文発生から各サイトへの反映まで平均5〜10分が目安です。実際の反映時間は、モール側の受信・反映状況にも左右されます。そのため、在庫が1個しかない商品を複数サイトで同時に販売する場合、在庫連携だけで売り越しを完全に防げるとは考えない方が安全です。
売れ筋や在庫僅少商品では、サイトごとの販売数量を配分し、返品・交換用の確保在庫を差し引いて公開する方法を検討します。販売機会を優先するのか、売り越し回避を優先するのかを商品群ごとに決めておくと、在庫が減ったときの判断がぶれにくくなります。
実棚・倉庫在庫とのズレは正本と補正手順を決めて扱う
公開情報だけでは、CROSS MALL上の在庫を「実在庫」または「理論在庫」と定義することや、棚卸差異を一覧で確認する専用機能の有無までは確定できません。一方で、在庫はCSV・手入力による上書きや加算・減算、APIによる更新が案内されています。
実店舗や倉庫を含む場合は、次の役割を導入前に決めます。
- 実棚在庫の正本を、CROSS MALL、POS、WMS、基幹システムのどれにするか
- 商品・SKU・倉庫など、どの単位で差異を照合するか
- 棚卸差異を誰が確認し、どの方法で補正するか
- 返品・キャンセル・入荷遅延時に在庫をどう戻すか
- 連携失敗時に、どのシステムから再処理するか
「在庫を一元管理できる」という説明だけで、物理在庫との差異確認まで自動化されると判断しないことが大切です。
CROSS MALLの料金体系と見積もり時の確認点
2026年9月15日に確認した公開料金では、初期費用は0円、受注件数・受注金額による従量課金はありません。商品点数のプランとサイト数によって月額が決まります。金額は税抜です。
| プラン | 商品点数上限 | 1サイトあたり月額 |
|---|---|---|
| プラン1000 | 1,000点 | 10,000円 |
| プラン3000 | 3,000点 | 15,000円 |
| プラン5000 | 5,000点 | 20,000円 |
| プラン15000 | 15,000点 | 25,000円 |
15,000点を超える場合は営業担当への相談とされています。料金の詳細は公式料金ページで確認できます。
サイト数はモール数ではなく店舗数として考える
料金上のサイト数は、モールの種類ではなく管理する店舗数で考えます。同じモール内の複数店舗も、それぞれ1サイトとして数えます。
たとえば、プラン3000で楽天市場を2店舗、Yahoo!ショッピングを1店舗管理する場合は、次の計算です。
15,000円 × 3サイト ＝ 月額45,000円（税抜）
この計算には、別のプランや追加費用を含めていません。店舗追加の予定がある場合は、現在の店舗数だけでなく将来のサイト数でも試算します。
基本料金以外に確認したい費用・契約条件
自社サイトの個別連携では、初期設定費が別途見積もりとなる場合があり、仕様によっては連携できないこともあります。アラジンオフィスなどの基幹システム連携も、公開料金に含まれるとは限りません。
見積もりでは、基本月額だけでなく次の費用を確認します。
- 標準対応外サイトの初期設定・追加開発費
- 連携アプリやAPI接続の費用
- WMS、物流、送り状、POS、基幹システム側の契約費
- オプション、必要機器、データ移行の費用
- 商品点数の数え方、最低契約期間、解約・プラン変更条件
商品点数にSKUやセット商品がどう含まれるか、追加アカウントの条件、分析データの保存期間と延長費用も、契約前に確認しておくと見積もりとの差を抑えられます。
実店舗・卸・WMSと連携する場合の役割分担と導入準備
ECだけでなく実店舗、卸、自社倉庫や外部倉庫も運用する場合は、CROSS MALLが担う範囲と、POS・基幹システム・WMSに任せる範囲を分けて設計します。接続できるかだけでなく、どのシステムを正本にするかが重要です。
POS・卸・基幹システムとの連携条件
POS側がCROSS MALLのAPIに対応していれば、実店舗での販売をEC在庫へ反映する構成を取れます。CSV連携は個別相談です。アラジンオフィスとは、商品マスタ・在庫・注文の連携が案内されています。
一方、卸の売掛・買掛、請求・支払などの業務までCROSS MALL単体で処理できるとは限りません。EC・店舗・卸で共通にする商品コードや在庫の範囲、受注データの連携方向、基幹側で処理する業務、接続開発と費用を個別に確認します。
OMSとWMSの役割を分けて考える
CROSS MALLは、商品・受注・在庫・発注をつなぐOMS（受注・販売管理の基盤）として考えられます。一方、WMS（倉庫管理システム）は、入出庫、ピッキング、検品など倉庫内の作業を支援するシステムです。
CROSS MALL単体で受注を集約しても、倉庫のロケーション管理やバーコード検品まで十分に行いたい場合は、WMSとの連携を検討します。連携先としてWMSや物流サービスが掲載されていても、商品マスタ・在庫・受注・出荷のどこまで連携するか、同期方向、再処理、追加費用、障害時の責任分担はサービスごとに異なります。
導入前に整えるデータ・ルールと受けられる支援
公式の導入フローでは、問い合わせ、業務ヒアリング、申し込み、商品データチェック、専任担当との打ち合わせ、設定・操作案内を経て利用を開始します。導入までの流れでは、商品データの確認や運用準備を含む進め方が案内されています。
利用者側では、次の項目を事前に整理します。
- 商品コード、SKU、セット構成、店舗別の必須項目
- 商品・在庫・受注を連携するチャネルと連携しないチャネル
- 販売在庫、確保在庫、返品・交換用在庫の方針
- 通常注文、要確認注文、予約・取り寄せなどの振り分け
- 既存システムからの移行範囲と切り替え時の差分在庫
- 複数担当者の権限、在庫補正・例外受注・発注確定の担当者
- サポートの対応範囲、受付時間、稼働後の支援条件
導入支援がある場合でも、社内の商品データや例外処理のルールが自動で整うわけではありません。実際の注文データを使い、通常処理と例外処理の両方をテストしてから稼働させると、運用開始後の手戻りを減らせます。
まとめ
CROSS MALLは、複数ECの商品・在庫・受注・発注・仕入をまとめて管理するクラウド型サービスです。導入判断では、利用チャネルごとの機能対応、平均5〜10分が目安の在庫更新を踏まえた少量在庫の運用、商品点数プランと店舗数で決まる料金、POS・基幹システム・WMSとの役割分担を確認します。
定型的な商品展開や受注処理は効率化しやすい一方、実棚との差異、例外注文、複雑な外部連携、店舗ごとの必須項目は別途設計が必要です。自社のチャネル一覧、SKU構成、在庫の正本、受注サンプル、必要な外部連携を整理してから見積もりとデモを受けると、導入後の適合性を判断しやすくなります。