定期通販カート比較 — 候補3例を同条件で比べる手順と8つの観点
ecforce(製品)、W2(製品群)、Shopify+定期アプリ(組み合わせ方式)の3例を、同じ条件・同じ質問・同じデモで比べる手順を整理します。公式の説明で確認できる入り口と、自社で確認する点を分け、8観点の質問をつけています。

カート・システムの全体像D2Cのカート・基幹システムをどう選ぶか — 汎用型と定期通販特化型の分かれ道
定期通販のカートを探し始めると、製品名で検索して機能一覧を並べたくなります。ところがこの領域は、製品ごとに公開されている情報の粒度が違います。料金が明示されているものも、問い合わせが前提のものもあり、機能は「できる」の一言で終わっていることがあります。その状態の一覧表では、判断はできません。
そこでこの記事は、候補3例を取り上げ、同じ条件・同じ質問・同じデモで比べる手順を示します。3例は種類が異なります。ecforceは製品、W2は製品群(公式サイトに複数の表記があります)、Shopifyはアプリと組み合わせる方式です。市場の代表例や推奨順を示すものではなく、手順を具体的に見せるための例です。先に3例の確認先を示し、次に選び方の流れ、最後に8つの観点を扱います。
仕様や料金は更新されます。ここでは個別製品の優劣を断定せず、確認先と確認のしかたを書いています。表の確認日は2026年10月19日です。契約前に最新の公式資料と実機のデモで確かめてください。
比べる候補3例と、確認の入り口
| 候補例(種類) | 公式の確認先 | 確認日 | 公式の説明で確認できる構成・機能の入り口 | 自社適用を確認する点 |
|---|---|---|---|---|
| ecforce(製品) | LP・広告URL作成のヘルプ | 2026-10-19 | 広告URLとテンプレートを紐づけ、フォーム一体型のLPを作る手順が公式ヘルプにある | 自社の契約での利用範囲、料金、受注・物流、決済の対応範囲 |
| W2(製品群。W2 Repeat/W2 Commerce Repeat) | W2 Repeatのページ、W2 Commerce Repeatのページ | 2026-10-19 | 定期購入サイクル、受注自動化、MA/CRMが公式に説明されている。公式サイトには2つの表記のページがあり、同一の製品・契約かは確認できていない | 対象の製品とプラン、料金資料の内容、標準/追加の区分 |
| Shopify+定期アプリ(組み合わせ方式) | Shopify Subscriptionsのヘルプ | 2026-10-19 | 定期購入にはアプリを使う構成として説明されている | 利用するアプリごとの決済対応、費用、運用 |
この表は、候補を網羅したものでも、順位をつけたものでもありません。3例は種類が違うため、機能範囲・費用・適用条件が同じだとは言えません。表の「公式の説明で確認できる構成・機能の入り口」の欄は、公式説明を整理したものです。自社に同じ範囲が適用されるかは、「自社適用を確認する点」に沿って公式資料と書面の回答で確かめてください。この記事は、確認できていない金額や機能を書きません。特化型と汎用型のどちらが合うかはD2Cのカート・基幹システムをどう選ぶか、個別の製品はW2 Repeat(リピートプラス)、ecforceとShopifyの比較、Shopifyで定期販売を始めるで扱っています。ecforceで広告用のLPを作る流れはecforceのLP作成手順にまとめています。
選び方の流れ:条件→除外→同条件のデモ→費用→決定
- 選定条件を決める:消費ペース、販売モデル、使いたい決済手段、主な獲得チャネル、定期が売上に占める見込みを書き出します。
- 除外要件を決める:満たさなければ候補から外す条件です。たとえば使いたい決済手段が定期課金に対応していない場合です。
- 同条件でデモを受ける:全候補に同じシナリオを通してもらいます。
- 費用と追加作業を並べる:月額だけでなく、標準・追加費用・設定や開発が必要、の区分で比べます。
- 決める:除外要件を満たした候補の中から、運用できる人数と出口の条件で決めます。
次は流れを示すための説明用の仮例です。実在の事業者や製品の結果ではありません。
仮例:単品販売から定期に広げる食品の事業者。クレジットカード決済が中心で、出荷は外部倉庫に任せる。除外要件は「カード決済で定期課金ができない」「契約データを書き出せない」の2つ。3つの候補に同じ条件表を渡し、書面で「標準」と答えた機能と「別契約」と答えた機能に分けて記録した。除外要件を満たした候補で同じデモを行い、追加作業の合計と担当者の人数を並べて決めた。
記入済みの選定シートの例(説明用の仮例)
カート・基幹システム選定シートの記入のイメージです。値はすべて仮の条件です。
| 項目 | 記入例(仮) |
|---|---|
| 12か月後の月間受注 | 仮に数百件 |
| 必須の決済手段 | クレジットカード(定期課金で必須) |
| 除外要件 | 契約データを書き出せない/定期課金に対応しない決済のみ |
| 外部連携 | 外部倉庫への受注連携、広告計測 |
| 候補A/B/C | 各社の回答区分(標準・追加・設定が必要・未対応・回答待ち) |
| 回答待ちの数 | 決定前にゼロにする |
| 運用の人数 | 管理画面を使う担当者2名の仮定 |
| 決定理由 | 除外要件を満たし、追加作業が最も少なかった候補 |
まだ決められないときは、カートを乗り換えるべきタイミングも参考になります。
観点1|決済
| 質問 | なぜ聞くか |
|---|---|
| 使いたい決済手段のうち、定期課金に対応しているのはどれか | 対応外なら検討から外れる |
| 定期に使えない手段は、定期商品のチェックアウトで非表示になるか | 決済できない注文が出るのを防ぐ |
| カード有効期限の自動追従に対応しているか | 期限切れ由来の停止が減る |
| 決済失敗時のリトライ回数と間隔は設定できるか | 設定できない製品がある |
| 失敗時の顧客通知は自動か。文面は編集できるか | リカバリに関わる |
決済手段は定期課金との相性が違います。クレジットカードは自動課金や更新を組みやすく、口座振替は継続利用に向く一方で手続きや反映に日数がかかる場合があります。後払いやキャリア決済は、条件により向き不向きが分かれます。主軸を何にするかは、カート選定より先に決めてください。
観点2|顧客のセルフサービス
マイページで顧客ができる範囲は、問い合わせ件数と継続率に関わります。次回配送日の変更・スキップ・周期変更、数量や商品の変更、支払い方法や配送先の変更、解約まで到達できるかを確認します。「解約は電話のみ」という設計になっていないかも見てください。
観点3|引き上げ
単品購入者と定期契約者を同じ顧客として紐づけられるか、経過日数でメールやLINEを出し分けられるか、引き上げ経由の契約を通常の定期と区別して集計できるかを確認します。集計できないと、引き上げ率が測れません。
観点4|データの取り出し
契約単位のデータ(開始日、状態、回数、次回配送日、解約日、解約理由)をCSVで出せるか、APIやWebhookで取得できるか、解約理由の選択肢を設定して集計できるかを確認します。管理画面の解約率が自社の定義と一致するとは限らないため、生データを出せるかが重要です。出せないとコホート分析ができません。
観点5|表示要件
日本の定期販売には特定商取引法の表示義務がかかります。2回目以降の価格と支払総額、最低継続回数の条件を売り場に表示できるか、申込み時の確認で必要な事項を出せるかを確認します。要件は契約条件で変わるので、公式の案内もあわせて見てください。
観点6|費用
| 質問 | 意図 |
|---|---|
| 初期費用・月額・従量部分の内訳 | 同じ形で比べる |
| 契約件数が今の10倍になった場合の月額 | 従量課金は成長すると効く |
| 売上連動の課金があるか。率と上限は | 利益率に影響する |
| 機能ごとの区分(標準/追加費用/設定や開発が必要) | 「できる」の中身を分解する |
立ち上げ時の金額だけで比べると、伸びたときに判断が変わります。追加作業にかかる人手や外注費も、費用として並べてください。
観点7|運用に必要な人数
同規模の事業者がこの業務を何人で回しているか、受注から出荷指示までに人手が要る工程はどこか、導入から稼働までの期間はどれくらいかを聞きます。機能があっても回す人が要るなら、人件費がかかります。
観点8|出口
契約前に必ず確認してください。他システムへ移行するとき、契約データを引き継げるか、そしてカード情報(トークン)を引き継げるかです。引き継げない場合は、顧客にカードの再登録をお願いする運用が必要になります。再登録は、それだけで全員が解約になるわけではありませんが、案内をしても手続きに進まない顧客が出て、その契約が止まる可能性があります。割合は事業や案内の仕方で変わります。入口だけを見て決めず、出口の条件も確認してください。移行の技術的な順序は定期通販のカート移行で失敗する順序にあります。
デモで通すべきこと
機能一覧ではなく、自社の注文を1件通してもらいます。
- LPから定期商品をカートに入れる
- 使いたい決済手段でチェックアウトする
- 申込み時に必要な事項が出ている
- 受注データが出荷指示に流れる
- 顧客がマイページで次回配送日を変更する
- 顧客がスキップする
- 2回目の配送が自動で立つ
- 決済を失敗させ、リトライと通知を確認する
- 顧客が解約する(理由の記録まで)
- 契約データをCSVで書き出す
8を飛ばさないでください。決済が通っていない注文が出荷される事故は、定期通販で起きやすいものの一つです。ただし、デモや確認は、ベンダーが用意したデモ環境やテスト用の手順で行います。
よくある質問
Q. 機能一覧の比較表を作りましたが判断できません
各社とも「できる」と書くため、差がつきません。標準、追加費用、設定や開発が必要、未対応、回答待ちの区分で書面の回答を取り直してください。
Q. 料金が非公開の製品はどう比較しますか
初期・月額・従量の内訳に加え、契約件数が10倍になった場合の月額を聞いてください。同じ条件表を全候補に渡すと、回答をそろえられます。
Q. 取り上げた3例は、主要な製品や推奨の順ですか
いいえ。種類の違う3例を使って、同じ条件で比べる手順を示したものです。代表性や順位を示すものではなく、自社の候補は条件と除外要件から選んでください。
Q. 何を最初に確認すべきですか
使いたい決済手段が定期課金に対応しているかです。合わなければ、他が揃っても運用できないため、最初に候補が絞れます。
Q. 情報が少ない製品は避けるべきですか
情報の少なさは、製品の良し悪しとは別の問題です。8観点を書面で質問し、回答の具体性を確認してください。
Q. 乗り換えは後からでもできますか
契約データとカード情報を引き継げるかによります。入口の検討時点で、出口の条件を確認してください。
8観点をそのまま送れる質問リストと、候補3社まで記入できる評価シートをカート・基幹システム選定シートにまとめています。判断が割れている場合は、ご相談ください。


