ECカートとは、注文を成立させるための仕組み

ECカートとは、ネットショップで商品をカートに入れてから注文が確定するまでを成立させる仕組みのことです。実店舗の買い物かごとレジを、そのままウェブ上に置き換えたものだと考えると分かりやすくなります。

ただし、この言葉は2つの意味で使われています。ここを取り違えると、資料を読んでも話がかみ合いません。

結論

狭い意味でのECカートは、かごと決済の画面だけを指します。広い意味でのECカートは、商品管理・受注管理・顧客管理・メール配信まで含んだ運営システム全体を指します。サービスを選ぶ場面でこの言葉が出てきたら、ほぼ必ず後者の意味です。

実際に店舗を動かし始めると、作業時間を占めるのはかごの画面ではありません。注文が入ってからの受注処理や在庫の調整、お客様への連絡やリピート施策は、すべて同じシステムの上で動きます。だから「カート」という小さな名前のまま、運営の土台そのものを指す言葉になりました。

同じものを指す呼び方がいくつもあります

「ECカート」「カートシステム」「ECカートシステム」「ショッピングカートシステム」「ASPカート」は、どれもほぼ同じものを指しています。呼び方が揃っていないのは、提供する会社ごとに自社サービスの説明として言葉を選んできたためです。機能の違いではないため、言葉の選び方からサービスの優劣は読み取れません。

ECカート・ECサイト・ECモールは、指している範囲が違う

検索でよく並ぶ言葉を、範囲の広い順に整理します。この5つを区別できると、比較記事を読むときに「何と何を比べている記事なのか」が分かります。

言葉指しているもの具体例自社のドメインか
ECサイト店舗そのもの。サイト全体自社のオンラインストア自社
ECカート
(カートシステム)
ECサイトを動かすシステム全体BASE、Shopify、カラーミーショップ自社
ショッピングカートかごと決済の画面・機能だけ「カートに入れる」ボタンから後の画面自社
ECモール出店する場所。集客の場楽天市場、Amazon、Yahoo!ショッピングモール側
ECカート事業者
(ベンダー)
カートシステムを提供する会社カートの開発・提供元該当しない

いちばん混同されるのは、ECカートとECモールです。両者は競合する選択肢のように並べられますが、性質がまったく違います。

ECカートは、自社のドメインで独立した店舗を構える仕組みです。集客は自力で行う必要があり、代わりに顧客データが自社に残ります。ECモールは、すでに人が集まっている場所に出店する仕組みです。集客は任せられますが、手数料が高く、顧客データを自由には使えません。

どちらが優れているという話ではありません。認知を取りに行く段階ではモールが効き、リピートで利益を積む段階では自社カートが効きます。

両方を併用している事業者も多くいます。その場合に問題になるのは在庫です。自社カートとモールで同じ在庫を売ると、片方で売れた分がもう片方に反映されるまでの間に、在庫がないものを売ってしまいます。併用を前提にするなら、在庫を一元管理する仕組みをどちらに置くかを先に決めてください。カート側に寄せるか、在庫管理の専用サービスを間に挟むかの二択になります。

カートに入れてから注文が確定するまでに起きていること

「ECカートの仕組み」を調べる人が本当に知りたいのは、ここだと考えています。買う人の画面に見えるのは「注文完了」の1枚だけですが、その裏では5つの処理が順番に走っています。

注文が確定するまでに走る5つの処理 カートの保持、届け先と決済方法の受け取り、在庫の引き当て、決済の与信、受注データの生成が順に実行される。どの段階で止まっても注文は成立せず、段階ごとに現れる症状が異なる。 1 カートに商品を保持する 期限切れで中身が消えると、買い直してもらえない 2 届け先と決済方法を受け取る 入力項目が多いほど、この画面で離脱が増える 3 在庫を引き当てる 引き当てが甘いと、同じ在庫を二重に売ってしまう 4 決済の与信をとる カード会社が承認しないと、ここで止まる 5 受注データを作る ここから先が、発送と入金の作業になる 5つすべてが成功して、初めて注文が確定する

1つ目は、カートの中身を保持する処理です。 商品をかごに入れた状態は、ブラウザ側とサーバー側の両方に記録されます。この保持期間はサービスによって違い、短いと、あとで買おうと思って戻ってきたお客様のかごが空になります。

2つ目は、届け先と決済方法を受け取る処理です。 ここで入力してもらう項目の数が、そのまま離脱率に跳ね返ります。会員登録を必須にするかどうかも、この段階の設計です。

3つ目は、在庫の引き当てです。注文を受け付けた時点で在庫を確保しないと、同じ最後の1点を複数のお客様に売ってしまいます。

引き当てのタイミングはサービスごとに違います。注文が確定した瞬間に減らす方式が一般的で、かごに入れただけでは在庫は動きません。つまり在庫が1点の商品を10人が同時にかごへ入れられる状態は、仕様どおりです。買えるのは先に注文を確定させた1人だけで、残りの9人は最後の画面で止まります。アクセスが集中するセールのときほど、この差が目立ちます。

4つ目は、決済の与信です。クレジットカードの場合、カード会社に利用枠を確認して仮押さえします。ここで承認が下りなければ、注文は成立しません。

5つ目は、受注データの生成です。ここで初めて「注文」という1件のデータができます。発送や入金の作業は、このデータを起点に進みます。

この5段階のどこで止まっても、お客様から見える結果は同じです。「買えなかった」という一言になります。カートの不調を調べるときは、どの段階で止まっているかを切り分けるところから始めます。

ECカートが標準で持つ機能と、持っていない機能

ECカートシステムには、商品管理・受注管理・顧客管理・メール配信・クーポンといった機能が標準で付いてきます。どのサービスを選んでもこのあたりは揃っていて、差が出るのは設定の細かさです。機能ごとの比較は別の記事で表にまとめています。

ここで整理しておきたいのは、むしろ逆側です。ECカートが持っていない領域を知らないまま契約すると、運営を始めてから足りないものに気づきます。

カートに含まれる

  • 商品情報と在庫数の管理
  • 注文の受付とステータス管理
  • 会員情報と購入履歴
  • 注文通知・メルマガの配信
  • クーポンとポイント
  • 売上の集計画面

含まれないことが多い

  • 倉庫での保管とピッキング
  • 配送伝票の作成と追跡番号の登録
  • 会計ソフトへの売上連携
  • 問い合わせの管理
  • 広告運用とアクセス解析
  • 複数販路の在庫一元管理

右側は、外部のサービスやアプリで補う領域です。だからカートを選ぶときは、機能の数より「必要な外部サービスとつながるか」を見たほうが外しません。

逆に、自分で用意しなくてよいものもあります。クレジットカード情報の取り扱いです。ASP型のカートでは、カード番号を店舗側のサーバーに保存しない仕組みが標準です。決済の入力画面を決済代行会社側に預けるか、カード番号をその場でトークンに置き換えて扱います。自社でカード情報を抱えないため、万一サイトに侵入されてもカード番号そのものは流出しません。この仕組みを自力で作るとなると負担が大きく、カートを借りる利点のひとつになっています。

もう1つ、機能一覧には出てこない項目があります。売上の入金サイクルです。カート自体の機能ではなく、決済代行会社の締め日と入金日で決まります。当社も自社ブランドのECを運営していて、売上が入金されるまでに困ったことがあります。画面に表示される売上の数字と、口座に入る日付は別物です。契約前に締め日と入金日を確認しておくと、資金繰りの計画が立てやすくなります。

注文フォームではなく、ECカートが必要になる理由

商品が数点しかない段階なら、問い合わせフォームやメールで注文を受けることもできます。実際、その形で始める事業者もいます。ではどこからカートが必要になるのかを整理します。

観点注文フォームECカート
複数商品の購入1回の送信で1商品が前提まとめて買えて数量も変えられる
合計金額の計算受け取った側が計算する送料と割引を含めて自動で計算する
在庫の反映反映されない注文の確定と同時に減る
決済あとから請求して入金を確認する注文と同時に完了する
購入履歴フォームの回答として残る顧客ごとに紐づいて残る

境目になるのは、確認作業の量です。フォームで受けた注文は、金額と在庫を人が確かめてから返信します。1日に数件なら苦になりませんが、件数が増えるとこの確認が運営時間の大半を占めます。しかも確認の途中で在庫が切れると、注文を受けたあとに謝る展開になります。

もう1つの境目は、リピートを狙うかどうかです。フォームの回答は注文の記録にしかなりません。誰が何を何回買ったかを追えないため、再購入を促す施策が組めません。カートは購入履歴を顧客に紐づけて持つため、ここから先の打ち手が増えます。

逆に言えば、商品が1種類で、受注が月に数件で、リピートを前提にしないなら、フォームで足ります。カートは注文を取る道具というより、注文が増えたあとの確認作業を自動化する道具だと考えてください。

ECカートの種類は、開発の自由度で分かれる

ECカートは、作り方によって5つに分かれます。上から順に、自由度と費用が上がります。

  1. ASP(SaaS)型

    ベンダーのシステムをインターネット経由で借りる形式です。BASE、STORES、カラーミーショップ、makeshop、Shopifyがここに含まれます。「ASPカート」という呼び方もこの型を指します。

  2. クラウドEC型

    借りる形式のまま、個別のカスタマイズに対応できる型です。月額は数十万円規模になります。

  3. パッケージ型

    製品を買い取って自社サーバーに構築します。改修の自由度は高く、保守の責任も自社に移ります。

  4. オープンソース型

    無償で公開されたソフトを使います。ライセンス費用はかかりませんが、構築と保守に技術者が必要です。

  5. フルスクラッチ

    ゼロから開発します。要件が特殊な大規模事業者が選ぶ型です。

多くの事業者はいちばん上のASP型で足ります。月額数千円から始められて、サーバーの保守もベンダー側が持つためです。型ごとの向き不向きと費用の実額は、比較記事のほうで詳しく扱っています。

「無料のECカート」は、何が無料なのか

無料で使えるECカートはあります。ただし無料なのは初期費用と月額費用だけです。売れたときに売上から引かれる手数料は、どのプランでも必ずかかります。

サービス・プラン初期費用月額売れたときにかかるもの
BASE
スタンダード
0円0円決済手数料3.6%+40円
サービス料3%
STORES
フリープラン
0円0円決済手数料5.5%〜
カラーミーショップ
フリープラン
0円0円決済手数料は有料プランと別体系

料金は2026年10月時点の公式サイトの内容です

各社の料金体系とプラン構成は予告なく変更されます。上の金額はBASE、STORES、カラーミーショップの公式ページの記載です。各社の料金体系とプラン構成は予告なく変更されるため、契約前には必ず公式サイトで最新の金額を確認してください。

カラーミーショップのフリープランの決済手数料は、有料プラン向けのカラーミーペイメントとは別の体系です。上記のプラン一覧には記載がないため、この記事では金額を書いていません。申し込みの前に、カラーミーショップのヘルプで最新の条件を確認してください。

BASEのスタンダードプランを例にすると、決済手数料3.6%とサービス料3%を合わせて、売上の6.6%に加えて1件40円が引かれます。月商10万円なら手数料は6,600円ほどで、固定費0円の身軽さが効きます。しかし売上が伸びると、この料率がそのまま重くなります。

同じBASEのグロースプランは月額19,980円(月払い)で、決済手数料2.9%、サービス料0円です。固定費はかかりますが料率は下がります。両者を比べると、どこかで総額が逆転します。

月商別に見た、月額0円プランと有料プランの手数料総額 月商10万円では月額0円のスタンダードプランが安く、月商100万円では月額のかかるグロースプランが安くなる。逆転するのは月商54万円あたりである。 スタンダード(月額0円・6.6%) グロース(月額19,980円・2.9%) 月商10万円 6,600円 22,880円 月商50万円 33,000円 34,480円 月商100万円 66,000円 48,980円 1件40円の加算を除いた概算。逆転は月商54万円あたり

計算すると、逆転するのは月商54万円あたりです。月額0円が得かどうかは、売上の規模で決まります。売れるかどうかを確かめる段階では固定費0円が合理的で、売上が立ち始めたら料率で選び直すのが現実的な進め方です。

もう1つ、料率の表に現れにくい費用があります。カート標準の決済ではなく外部の決済サービスを使うと、追加の手数料がかかる場合があることです。たとえばShopifyのBasicプランでは、Shopifyペイメント以外を使う取引に2%が加算されます。

出典:Shopify(料金プラン)

当社も自社ブランドのShopifyサイトを運営していて、手数料が思ったより大きいと感じた経験があります。越境ECでは、さらに為替の手数料もかかります。料率は1件ごとには小さく見えますが、年間の総額で見ると固定費と同じ重さになります。

カートを用意しても、注文の約7割は完了しない

ここまでカートの中身を見てきましたが、入れただけでは注文は増えません。カートに商品を入れたお客様の多くが、購入まで進まずに離れます。

Baymard Instituteが50件の調査を平均した結果では、カート放棄率は70.22%です。10人がかごに商品を入れて、7人が買わずに去る計算になります。カートの設定を考えるときは、この水準を出発点に置いてください。

ただし、この7割すべてが改善できる離脱ではありません。同じ調査では、米国の利用者の42%が「見ていただけで、買う予定がなかった」と答えています。かごを比較や保存のために使う行動は普通であり、ここは避けようがありません。

意味があるのは、残りの理由です。

買う気があったのに離脱した理由(米国の利用者) 送料や手数料などの追加費用が高いという理由が40%で最も多く、配送が遅い20%、カード情報を預けるのが不安19%、会員登録が必須18%、決済が長く複雑17%、サイトのエラー17%、決済手段が足りない9%が続く。 追加費用が高い(送料・税・手数料) 40% 配送が遅かった 20% カード情報を預けるのが不安 19% 会員登録が必須だった 18% 決済の手順が長く複雑 17% サイトにエラーが出た 17% 使いたい決済手段がなかった 9% Baymard Institute調べ(複数回答・「見ていただけ」を除く)

最も多いのは「送料や税、手数料などの追加費用が高かった」で40%です。次が配送の遅さ、カード情報への不安、会員登録の必須化と続きます。

この並びを見ると、上位の理由のほとんどがカートの設定で手が届く範囲にあります。商品を売る力ではなく、カートの設定で取り戻せる離脱が上位を占めています。

カートの設定で見直せること

  • 送料と手数料を、かごに入れる前の段階で表示する
  • 会員登録なしで買えるゲスト購入を有効にする
  • コンビニ払いやID決済など、使われる決済手段を追加する
  • 入力項目を削り、郵便番号から住所を自動で補完する
  • 自分でテスト注文を入れて、止まる箇所がないか確かめる

一方で、配送の速さや信頼感はカートの設定だけでは動きません。倉庫や物流、サイト全体の作りに関わります。カートを替えれば売れるという話ではなく、どの離脱なら設定で手が届くかを分けて考える必要があります。

なお、この調査は米国の利用者を対象にしています。日本では使われる決済手段も配送の事情も違うため、数字がそのまま一致するとは限りません。順位の傾向を参考にしつつ、自社の数字は自分のカートで測ることをおすすめします。

平均値ではなく、自社の数字を測る

70.22%という平均を知っても、自分の店舗がどうなっているかは分かりません。測り方は単純です。かごに商品が入った回数と、注文が完了した回数を並べるだけです。

Googleアナリティクス4を入れているなら、add_to_cartイベントとpurchaseイベントの回数を比べます。カートシステム側の解析画面に、同じ数字が用意されていることもあります。

見るときは3段階に分けてください。かご、決済情報の入力、注文完了の3つです。どの段階から次へ進めていないかが分かると、直す場所が1つに絞れます。かごから入力画面へ進まないなら送料や合計金額の見せ方の問題で、入力画面から完了へ進まないなら項目の多さか決済手段の問題です。

比べる相手は業界平均ではなく、自社の先月の数字にしてください。商材の単価や客層で水準は変わるため、平均との差を気にしても打ち手は出てきません。

目的別に、次に読む記事

ECカートが何かを押さえたら、次は自分の状況に合う話題へ進みます。

まとめ

ECカートとは、注文が確定するまでを成立させる仕組みであり、実務では受注管理や顧客管理まで含んだ運営システム全体を指します。カートに入れてから注文が確定するまでには5つの処理が走り、どこで止まってもお客様には「買えなかった」という結果しか見えません。

無料で使えるカートはありますが、無料なのは初期費用と月額費用だけです。売れたときの料率は必ずかかります。BASEの2つのプランで試算すると、月商54万円あたりで月額0円プランと有料プランの総額が逆転します。最初から1つに決め切るのではなく、売上が伸びた時点で選び直す前提で考えてください。

そしてカートを用意しても、かごに入った注文の約7割は完了しません。離脱理由の上位は追加費用の見せ方や会員登録の必須化であり、カートの設定で手が届く範囲にあります。サービスを選ぶ作業と同じくらい、選んだあとの設定に時間を使う価値があります。