D2Cのカート・基幹システムをどう選ぶか — 汎用型と定期通販特化型の分かれ道
Shopifyのような汎用ECプラットフォームと、ecforceのような定期通販特化型では、得意な領域が違います。どちらを選ぶかの判断軸を整理します。
D2Cのカート選定でよく起きるのは、機能一覧を横に並べた比較表を作って、かえって判断できなくなることです。機能はどれも「ある」と書かれるので、差がつきません。
差がつくのは 何を標準で持っていて、何をアプリや開発で足す設計になっているか です。ここから見ると、選択肢は大きく2つの系統に分かれます。
先に結論を書きます。 D2Cのカートは「汎用型ECプラットフォーム（Shopifyなど）」と「定期通販特化型プラットフォーム（ecforceなど）」の2系統に分かれ、どちらを選ぶかは事業の売上に占める定期契約の比率で決まります。比率が高いほど特化型が有利、低いほど汎用型の自由度が効きます。以下、その判断軸と比較の進め方を順に整理します。
システムの仕様と料金は頻繁に変わります。ここに書くのは判断の軸で、個別製品の現在の対応状況は必ず公式資料と実機のデモで確認してください。
D2Cのカートシステムにはどんな系統があるか
D2Cのカートは、標準機能がどこまで定期通販寄りかで大きく2系統に分かれます。「構築方式」（ASP・SaaS型／パッケージ型／オープンソース型／フルスクラッチ型）でも分類されますが、実務上判断に効くのは方式そのものより標準機能の寄せ方です。現在主要な選択肢のほとんどはASP・SaaS型に集約されているため、この記事では機能の系統で比較します。
構築方式の違いは、開発力をどれだけ自社（または委託先）が持ち続けるかの違いです。
| 構築方式 | 何を持つか | 向く場面 |
|---|---|---|
| ASP・SaaS型 | ベンダーがサーバー・保守・法改正対応を持つ | 早く立ち上げたい、開発体制を持たない |
| パッケージ型 | ソフトウェアを購入し自社サーバーで運用 | 標準に近い形で一定のカスタマイズも欲しい |
| オープンソース型 | ソースを自社で保持し、改修・保守も引き受ける | 自由度を最優先し、開発体制がある |
| フルスクラッチ型 | 要件定義から設計・開発まで自社で発注する | 既存の型に合わない独自の業務フローがある |
オープンソース型を定期通販で使う場合に何を背負うことになるかは、EC-CUBEで定期購入はできるかに具体的にまとめています。
汎用型ECプラットフォーム（Shopify など）とは
汎用型ECプラットフォームとは、カートとしての土台が広く、定期購入などの機能をアプリで足す設計のシステムです。
- 強み：立ち上げが速い。デザインの自由度が高い。海外展開や多チャネル販売に強い。アプリのエコシステムが大きい
- 弱み：定期通販に固有の機能（引き上げ、同梱物制御、CRM連携、コールセンター運用）はアプリの組み合わせ次第。組み合わせが増えるほど、連携部分が壊れやすくなる
選定の要点はアプリ側にあります。詳細はShopifyで定期販売を始めるにまとめました。
定期通販特化型プラットフォーム（ecforce など）とは
定期通販特化型プラットフォームとは、日本の定期通販・単品リピート通販の運用を前提に、定期契約の管理・引き上げ・CRM・広告計測を標準機能として持つシステムです。
- 強み：定期通販の運用に必要な機能が最初から揃っている。日本の商習慣・決済・法対応との噛み合わせが前提になっている
- 弱み：汎用ECとしての自由度は汎用型に劣る。単品リピート通販の型から外れる売り方をしようとすると、逆にやりにくくなることがある
特化型どうしの比較軸は定期通販カートシステムの選定基準に分けて整理しています。
D2Cのカートはどちらを選ぶべきか
| 判断軸 | 汎用型が向く | 定期通販特化型が向く |
|---|---|---|
| 商品点数 | 多い（カタログ型） | 少ない（単品〜数SKU） |
| 売上の主軸 | 都度購入が中心 | 定期契約が中心 |
| 獲得方法 | SEO・SNS・多チャネル | 広告主体、LPからの獲得 |
| 引き上げ・アップセルの重要度 | 低〜中 | 高 |
| コールセンター運用 | 使わない／外部 | 中核業務として回す |
| 海外展開 | 予定がある | 国内に集中 |
| デザインの自由度 | 重視する | 標準の型で回したい |
判断が割れたときは、「事業の売上の何割が定期契約から来るか」で決めてください。 ここが高いほど特化型が効き、低いほど汎用型の自由度が効きます。
機能一覧の比較表だけで判断できないのはなぜか
ベンダーの資料をそのまま並べても判断できません。機能はどれも「ある」と書かれるため差がつかず、次の観点で聞き直す必要があります。
「できる」の中身を分解する。 標準機能なのか、オプション費用なのか、開発が必要なのかで、実際のコストは桁違いになります。
費用を3〜5年後・件数10倍になった前提で試算する。 従量課金・売上連動の課金体系が多いため、立ち上げ時の金額で比較すると判断を誤ります。
運用に何人必要かを聞く。 機能があっても、それを回す人が要るなら人件費がかかります。同じ業務を何人で回している事例があるかを確認してください。CS体制であれば、問い合わせ件数と1件あたりの対応時間から必要人数を逆算できます。
サポート体制を確認する。 障害時や繁忙期の問い合わせにどのチャネル（電話・メール・チャット）で、どれくらいの時間で応答するか。専任担当がつくかどうかも聞いてください。
出口を確認する。 将来別のシステムへ移る場合、契約データとカード情報（トークン）を引き継げるかどうか。カードの再登録が必要な移行は、実質的に全顧客に一度解約してもらうのと同じです。移行時の実務は定期通販のカート移行で失敗する順序にまとめています。契約前に確認する価値があります。
D2Cカートの費用はどんな要素で決まるか
月額プランの金額だけでは比較になりません。 カートの費用は初期費用・月額固定費・従量課金・オプション費用の4つが独立して積み上がり、事業規模が上がるほど従量課金の比重が増えます。
- 初期費用：契約時に一括で発生する費用。構築方式やデータ移行の有無で変わります
- 月額固定費：プランごとに定額で発生する費用。多くの場合、受注件数などの上限がプランに紐づきます
- 従量課金・売上連動費：受注件数や決済金額に応じて増減する費用。事業が伸びるほど比重が上がるため、立ち上げ時の見積もりでは実態を把握できません
- オプション・開発費：標準にない機能を追加する際の費用。「できる」と説明された機能がこの費用の対象になっていないか、契約前に確認してください
ecforceを例にした費用の分解はecforceの費用は何で決まるかにまとめています。他の製品でも同じ4分類で聞き直せば、横並びで比較できます。
D2Cのカートシステムはどんな手順で選ぶか
- 立ち上げの意思決定の1〜6を先に固める（特に決済手段）
- 決済手段に対応するシステムだけに候補を絞る
- 自社の運用フローを1本、実機のデモで最初から最後まで通してもらう
- データのエクスポート形式を実際に出してもらう
- 件数10倍での費用を試算する
3が最も効きます。何を見ればいいかは機能一覧ではなく、次の章で挙げる具体的な業務の場面です。
実機デモでは具体的に何を確認すればよいか
結論を先に書きます。 「これはできますか」という質問への回答ではなく、自社の実データに近い条件で目の前の画面を動かしてもらってください。次の5つの場面を同じ条件（同じ商品・同じ顧客属性）で通せるかを見ると、機能一覧では見えない差が出ます。
| 場面 | デモで確認すること |
|---|---|
| 初回→2回目の継続分析 | 初回から2回目までの継続率を、自社が使いたい切り口（流入経路・商品・定期回数）で今すぐ画面上に出せるか |
| 決済失敗時のリカバリ | カード期限切れ・残高不足を検知した後、通知・リトライ・カード更新導線までが自動か、どこかで人手の作業が要るか |
| 問い合わせの分類 | 入電・メール・チャットの問い合わせ内容が、解約理由などの区分に沿って集計された状態で見られるか、それとも人力で分類し直すのか |
| MA（メール・LINEなど）の下書き作成 | 定期回数や購入商品に応じたシナリオメールが、テンプレートから下書きとして出てくるか、ゼロから文面を書くことになるか |
| 定期変更（周期変更・休止・解約）の承認 | 引き止めオファーの提示順序や、変更の承認ルート（自動か人の確認が要るか）をシステム側で制御できるか |
この5つは、初回離脱・決済失敗・解約引き止めといった、定期通販の継続率を左右する実務そのものです。デモで「できます」と言われた項目は、契約前にその場で操作してもらってください。
定期契約の比率がまだ読めない段階ではどう判断するか
売上規模がまだ小さく、定期契約の比率も読めていない段階では、決め切らないという判断 もあります。都度購入で立ち上げてリピート率を実測し、定期化の見込みが立ってから特化型に移る、という順序です。
移行コストは発生しますが、間違った前提で作り込んだシステムを捨てるコストより小さいことがあります。
自社がどの段階にいるかは、グロース診断で整理できます。
よくある質問
Q. 汎用型と定期通販特化型、どちらを選ぶか迷ったときの決め手は
事業の売上の何割が定期契約から来るかで決めてください。この比率が高いほど特化型が効き、低いほど汎用型の自由度が効きます。
Q. ベンダーの機能一覧を並べた比較表だけで判断できないのはなぜですか
機能はどれも「ある」と書かれるため差がつきません。「できる」の中身が標準機能なのかオプション費用なのか開発が必要なのかで実際のコストは桁違いになるため、そこを分解して聞き直す必要があります。
Q. 実機のデモで最も見るべきポイントは何ですか
機能一覧ではなく、自社の注文が1件、受注から出荷、2回目の配送、周期変更、解約まで通るかを見てください。特に初回→2回目の継続分析、決済失敗時のリカバリ、問い合わせの分類、MAの下書き作成、定期変更の承認という5つの場面を、自社の実データに近い条件でその場で操作してもらうと、機能一覧では見えない差が分かります。
Q. カートの費用はどこを分解して比較すればよいですか
初期費用・月額固定費・従量課金（売上連動を含む）・オプション費用の4つに分けて聞いてください。特に従量課金は事業が伸びるほど比重が上がるため、立ち上げ時の金額だけで比較すると件数が伸びたときに想定が外れます。
Q. 定期契約の比率がまだ読めない段階でも、特化型か汎用型かを決め切る必要がありますか
必ずしもありません。都度購入で立ち上げてリピート率を実測し、定期化の見込みが立ってから特化型に移るという順序もあります。移行コストは発生しますが、間違った前提で作り込んだシステムを捨てるコストより小さいことがあります。
