↗付きの用語リンクは、別タブで説明を開きます。
クロスマの導入では、モールのAPIを接続するだけでなく、商品情報、注文取得、価格・在庫、出荷方法、通知、例外対応までを一つの運用として整える必要があります。設定項目が多いため、画面の上から順に入力するよりも、実際の業務フローに合わせて進める方が確認漏れを防ぎやすくなります。
クロスマの初期設定を、連携準備から商品・注文・出荷の確認まで順番に整理します。MO-LIBは自社のEC物販でクロスマを利用し、販促支援でも導入時の設定整理に関わっています。
結論：モール接続ではなく、注文完了までの順番で設定する
最初に決めたいのは、どのモールと接続するかだけではありません。商品をどこから取得し、どの在庫を販売可能数として表示し、注文をどの倉庫へ送り、エラーを誰が確認するかまでを一続きにします。
基本の順番は、現状整理、モールAPI、メール・注文取得、商品、価格・在庫、出荷、アラート、テスト注文です。この順番なら、設定した項目が次の工程で正しく使われているかを段階的に確認できます。
| 段階 | 主な確認内容 | 完了の目安 |
|---|---|---|
| 1. 現状整理 | 販売モール、商品コード、在庫拠点、担当者 | 現在の業務フローを説明できる |
| 2. API設定 | Amazon、Yahoo!、楽天市場等の接続情報 | 商品・注文の取得可否を確認できる |
| 3. 注文設定 | 自動取得、通知先、送信元、メール文面 | テスト注文を取り込める |
| 4. 商品設定 | 取得、編集、保存、出品先、商品コード | 少数商品を正しく出品・更新できる |
| 5. 価格・在庫 | モール別価格、安全在庫、在庫連動 | 想定した価格と販売可能数になる |
| 6. 出荷設定 | FBA、自己発送、外部倉庫、配送条件 | 出荷依頼と追跡反映を確認できる |
| 7. 例外対応 | エラー、欠品、キャンセル、通知担当 | 停止時の手順と担当者が決まっている |
1. 設定前に現在の運用を整理する
システムへ入力する前に、現在の注文から出荷までを簡単な図や表にします。特に、モールごの商品コードとAmazon側SKU、在庫を保管する場所、出荷方法、注文確認の担当者を整理します。
- 利用中・追加予定の販売モール
- Amazonと各モールの商品コードの対応
- FBA、自己発送、外部倉庫の使い分け
- 安全在庫と販売可能数の考え方
- 注文、出荷、キャンセル、エラーの担当者
- 連携を停止した場合の手動処理
ここが曖昧なまま自動化すると、通常注文は処理できても、欠品や複数配送などの例外で対応が止まりやすくなります。
2. モールAPIを接続する
クロスマの設定画面には、Amazon、Yahoo!ショッピング、楽天市場、au PAY マーケット、メルカリShops、Qoo10、ShopifyなどのAPI設定が用意されています。必要な認証項目や更新期限はモールごとに異なるため、接続情報と更新日を管理表に残します。
API接続後は、管理画面に「接続済み」と表示されたことだけで完了にしません。代表商品を取得できるか、テスト注文を取得できるか、モール側の変更が反映されるかまで確認します。公開鍵やライセンスキーなど期限のある情報は、更新担当者と確認日も決めておくと安心です。
3. メールと注文自動取得を設定する
注文関連設定では、モールごとの注文自動取得、通知先、購入者へ送るメールの送信元、テンプレート、署名などを確認します。公式マニュアルでは、アカウント発行後や利用再開時に注文自動取得がオフになっている場合があり、設定後の取得まで時間がかかることも案内されています。
そのため、設定直後に注文が見えない場合は、同じ操作を繰り返す前に、モール側の注文状態、API期限、自動取得のON・OFF、クロスマ内の処理状態を順に確認します。取得できない注文がある場合は、出荷遅延を防ぐためモール側での直接処理も含めて判断します。
4. 商品取得・編集・出品の流れを分ける
商品管理では、Amazonからの商品取得、商品情報の編集、編集内容の保存、各モールへの出品・更新を別の操作として考えます。商品情報を変更したあと、保存せずに出品処理へ進むと、意図した内容が反映されない可能性があります。
多数の商品を扱う場合も、最初から全商品を一括処理せず、代表商品で次の点を確認します。
- 商品コードとSKUの対応
- 商品名、説明文、画像、バリエーション
- モールごとの必須項目とカテゴリ
- 併売用商品と専売用商品の区分
- 出品先と公開・非公開の状態
- 物流設定と実際の発送方法
CSV、画像一括編集、店舗コピーは作業時間を短縮できますが、対象店舗と変更範囲を誤ると影響が広がります。実行前のCSV保存や対象件数の確認など、戻せる手順を用意してから使います。
5. 価格・在庫連動を少数商品で確認する
価格設定では、Amazon価格を基準に割合や金額を加減し、モールごとの販売価格へ反映する方法があります。配送料、モール手数料、決済費用、粗利が異なるため、すべてのモールへ同じ加算を設定するとは限りません。
また、共通設定を変更すると取得済みの商品へ広く反映される場合があります。設定変更前に対象範囲を確認し、代表商品で計算結果を確かめてから範囲を広げます。在庫は実数をそのまま表示せず、更新間隔、販売速度、返品、入荷予定を考慮して安全在庫を設けます。
6. 出荷方法と自動処理の範囲を決める
注文管理では、モールから取得した注文、発送方法、自動処理状態、注文処理状態を確認できます。クロスマの公式案内では、FBA、STOCKCREW、オープンロジなど連携対象の在庫について、条件が合えば受注案内、出荷依頼、出荷データ取得、発送完了案内、モール側ステータス更新を自動化できるとされています。
一方、対象外の商品やエラーになった注文では手動対応が必要です。自動化率だけを見るのではなく、「自動処理が停止した注文を誰が、いつ、どの画面で確認するか」を決めます。FBAマルチチャネルを使う場合の詳しい考え方は、楽天・Yahoo!注文をFBAで自動出荷する方法で解説しています。
7. アラートと例外処理を運用ルールにする
設定画面には、複数個注文、高額受注、注文者氏名、仕入れ値などを条件とするアラート項目があります。すべてを通知するのではなく、通常処理から外して確認したい注文を定義します。
- 欠品または在庫差異
- 複数商品・複数配送
- 予約商品や納期違い
- 住所変更・キャンセル
- FBA依頼や出荷通知のエラー
- API期限切れや注文取得停止
エラー時に自動処理を再実行する前に、すでに倉庫へ依頼済みかを確認します。手動依頼へ切り替える場合も、二重発送を防ぐため注文コード、処理日時、担当者、追跡番号を一つの記録に残します。例外処理の整理は、複数モール運営でシステム導入前に整理する例外処理も参考になります。
テスト注文で確認したいこと
| 確認場面 | チェック項目 |
|---|---|
| 商品 | 商品コード、価格、在庫、画像、出品状態が想定どおりか |
| 注文取得 | モールの注文がクロスマへ一度だけ取り込まれるか |
| 出荷依頼 | 指定した倉庫・発送方法へ正しく依頼されるか |
| 出荷結果 | 追跡番号と発送状態がモールへ戻るか |
| メール | 購入者向け文面、送信元、署名、送信時点が適切か |
| 例外 | 欠品、キャンセル、住所不備で処理が止まり通知されるか |
| 復旧 | 手動対応後に二重処理や通知漏れがないか |
テストは通常注文だけで終わらせず、少なくとも一つは例外注文も確認します。本番開始後は、最初の数日間だけでも注文取得、処理停止、出荷結果、在庫反映を毎日読み合わせると、設定漏れを早めに発見できます。
クロスマが候補になりやすい運用
Amazonを主力にしながら複数モールへ販路を広げたい場合や、Amazonの商品情報・FBA在庫を起点に、商品登録、受注、在庫、出荷を整理したい場合は候補になりやすいシステムです。ただし、利用モール、商品構成、倉庫、例外注文、担当体制によって必要な設定は異なります。
機能、料金、対応モール、申込み条件は変更されることがあります。導入を検討する際は、クロスマの最新公式情報・お申し込みをご確認ください。
まとめ
クロスマの初期設定は、APIを接続して終わりではありません。現状整理、API、注文取得、商品、価格・在庫、出荷、アラート、テスト注文までを実際の業務順に確認することが重要です。最初は代表商品と少数のテスト注文で検証し、通常処理と例外処理の両方を確認できてから対象を広げましょう。
掲載情報の確認日：2026年8月29日。機能・料金・画面は変更される場合があるため、利用時は最新の公式案内をご確認ください。
