定期購入・サブスクECの構築方法と必要機能

01はじめに｜この記事でわかること

要点： 定期購入・サブスクECをこれから作る方に向けた記事です。どんな機能が要るのか、どの作り方を選ぶのか、費用と期間はどのくらいか。ご相談いただいた案件の数字とあわせてご説明します。

「定期購入をやってみたいのですが、いくらかかりますか」。ここ数年、いちばん増えたご相談です。ただ、金額の前に決めていただきたいことがあります。どこまでをシステムに任せるか、です。

単発の通販は、注文が入って、発送して、終わりです。定期購入は違います。申し込んだ翌月も、その翌月も、システムが注文を作り続けます。作り方が変わる理由は、ここにあります。

2000年創業のWeb制作会社であるZenWeb Japanでは、ECサイトの制作とWebシステム開発を手がけています。定期購入ECの構築でも、うまくいく案件との分かれ目が見えてきました。機能の多さではなく、時間が動く部分をどこまで設計したかです。

まずサブスク事業の全体像をつかみたい方は、以下の動画もご覧ください。

02定期購入とサブスクは作るものが違う

要点： 定期購入は「同じ商品が決まった周期で届く」仕組み、サブスクは「期間中いつでも使える権利を売る」仕組みです。前者は在庫と配送が動き、後者は動きません。この違いが、作るシステムを分けます。

言葉が混ざりがちですが、開発の現場では別物です。届けるモノがあるかどうかで、必要な仕組みが変わります。

• 定期購入（頒布会・単品リピート）。 化粧品や食品が決まった周期で届きます。在庫を引き当て、送り状を出し、配送のたびに決済します。
• サブスクリプション（利用権型）。 動画配信のように、期間中に使える権利を売ります。届ける商品がないぶん、権限の管理が中心です。

この記事では、ご相談の多い定期購入型を中心にご説明します。経済産業省の令和6年度電子商取引に関する市場調査では、物販系のBtoC-EC市場規模が15兆2,194億円、EC化率は9.78%と報告されています。最大分野は食品・飲料・酒類。消費のサイクルがはっきりした商材ほど、この売り方と相性がよい分野です。

中小企業がこの分野をどう見ているかは、日本政策金融公庫総合研究所の調査論文にもまとまっています。

03定期購入ECに欠かせない機能

要点： 周期の設定、次回注文の自動生成、継続課金、マイページからの変更、解約、決済エラーの再試行。この6つがそろって、はじめて定期購入が回ります。どれか1つ欠けると、手作業が毎月発生します。

一般的な機能一覧はECサイトに必要な機能一覧で整理しています。ここでは、定期購入ECの構築でだけ追加で要るものを挙げます。

• 周期の設定。 4週ごと、毎月10日、隔月など。商品ごとに変えられるかも決めます。
• 次回注文の自動生成。 決めた日に注文データを作る処理で、この仕組みの心臓部です。
• 継続課金。 毎回カード情報を入力させずに決済します。決済代行会社の対応が前提です。
• マイページからの変更。 周期の変更、次回のスキップ、お届け先の変更、一時停止。弱いと問い合わせが増えます。
• 解約の受付。 画面から解約できる導線です。電話のみは、後述の法対応で問題になります。
• 決済エラーの再試行。 期限切れや残高不足で止まったとき、いつ何回試すかの設計です。

04ご相談で必須と言われた機能

要点： 定期購入のご相談で「これは必須です」と言われた機能を集計すると、上位は次回注文の自動生成と継続課金です。一方でスキップや周期変更は、後から追加を希望されることが多い機能でした。

初回のヒアリング時に必須と挙がった機能を整理しました。

気になるのは下の3行です。初回はあまり挙がらないのに、公開後の追加要望では上位に来ます。しかも実装が重い機能ばかりです。

運用が始まるまで必要性が想像しにくいからです。毎月の解約対応や決済エラーの電話に追われて、はじめて「自動でやってほしい」となります。ECサイト構築費用の内訳のとおり、後から足す機能は割高です。

05構築の選択肢は大きく3つ

要点： 定期通販に特化したASPを使う、既存のカートを拡張する、独自開発する。この3つです。商品数が少なく条件も単純なら特化型ASP、業務が複雑なら拡張か独自開発が向きます。

選択肢ごとに向き・不向きがはっきり分かれます。

• 定期通販に特化したASPを使う。 必要な機能が最初から入っており、立ち上げが早い方式です。ただし画面や条件の自由度は限られます。
• 既存のカートを拡張する。 ShopifyやEC-CUBEに、定期購入のアプリやプラグインを入れます。足りない部分だけ作り足せるので、多くの案件はここに落ち着きます。
• 独自開発する。 業務のルールが特殊な場合や、基幹システムと深くつなぐ場合の選択です。自由度は高く、費用と期間も大きくなります。

拡張を選ぶなら、土台を先に決めてください。ShopifyとEC-CUBEの比較で違いを整理しています。Shopifyを軸にするならShopify構築の費用と依頼できる範囲を、EC-CUBEならEC-CUBEカスタマイズ費用の相場をご覧ください。どちらの土台でも、「本体に手を入れない作り」を保てるかが分かれ目です。

06方式別｜費用と期間の目安

要点： 特化型ASPの立ち上げは数十万円台、既存カートの拡張は100万円前後から、独自開発は数百万円以上になります。期間はASPで1〜2か月、独自開発なら半年前後を見込んでください。

案件を構築方式ごとに整理しました。金額は初期費用で、月額の利用料は含みません。

いちばん多いのは既存カートに定期アプリを載せる形で、4割近くを占めます。まずここで始めて、手に負えなくなったら個別開発に進む流れが現実的です。

最初から独自開発が要るのは1割ほど。取引先ごとに条件が変わるなど、BtoB向けECサイトの構築で挙げた課題と重なる場合に限られます。

07継続課金の決済で決めること

要点： 継続課金では、カード情報を自社で持たずに繰り返し請求する仕組みを使います。決済代行会社を選ぶ段階で、カード情報の更新に対応しているかを必ず確認してください。

定期購入ECでいちばん静かに損失が出るのが決済まわりです。商品にも接客にも問題がないのに、カードが通らないだけでお客様が離れていきます。

原因の多くは有効期限切れです。カードは数年で更新され、番号が同じでも期限が変わります。これを自動で反映する仕組みが「洗い替え」です。決済代行会社によって対応が分かれます。詳しくはECサイトの決済方法の選び方で整理しています。

決めておきたいのは次の4点です。

1. カード情報をどこに預けるか。 決済代行会社に預ける形が基本です。自社サーバーへの保存は避けてください。
2. 洗い替えに対応しているか。 対応の有無で、期限切れによる失注の量が変わります。
3. 決済エラーのとき、何日後に何回試すか。 3日後と7日後に1回ずつ、といった形で決めます。
4. 再試行しても通らなかったらどうするか。 自動で停止するのか、担当者に通知するのか。この分岐も先に決めます。

08稼働後につまずいた箇所の割合

要点： 公開後に追加の相談をいただいた案件で、つまずいた箇所を集計しました。最も多いのは決済エラーの手作業対応で、次が周期変更の受付です。どちらも設計で防げる部分でした。

棒の長さは、その箇所が原因だった割合です。

上位2つで半分を超えます。どちらも「機能がない」のではなく「機能はあるが人が代わりにやっている」状態です。契約が数百件に増えると、担当者の一日が埋まります。

使い方は簡単です。見積りの段階で、6つの行それぞれに「自動ですか、手作業ですか」と聞いてください。手作業と答えられた箇所が、将来の負担になります。

09解約・スキップ・周期変更の作り方

要点： 変更を受け付けるほど、注文が確定する締め日の設計が重要になります。締め日を過ぎたら次回分は変更できない。この一線をはっきり見せると、お客様も現場も迷いません。

マイページで変更できる項目を増やすと、問い合わせは減ります。ただし、すでに出荷の準備に入った回を後から変えられる問題も出ます。そこで必要になるのが締め日です。

• 締め日を画面に書く。 「次回お届けの7日前まで変更できます」と、マイページに常に表示します。
• 締め日を過ぎたら、次々回に回す。 止めるのではなく次の回に反映すると、納得を得やすくなります。
• スキップと解約を分ける。 「今回はいらない」と「もうやめたい」は別の行動です。スキップの選択肢があると、解約の一部が引き止められます。
• 解約は画面で完結させる。 電話だけの受付は、後述する法対応の面でも避けたい形です。

画面の設計は早めに紙へ落とすと、認識のずれが減ります。ワイヤーフレームの作り方の手順どおり、マイページの画面遷移を書き出してみてください。「変更できる項目」と「締め日」が並ぶだけで、議論が具体的になります。

10最終確認画面で必要な表示

要点： 定期購入では、注文の最終確認画面に表示すべき項目が法律で定められています。2回目以降の金額、各回の分量、請求の時期、解約の条件。この表示は設計の初期に組み込んでください。

2022年6月に施行された改正特定商取引法により、申込みの最終確認画面に必要な表示が明確になりました。定期購入では、初回だけでなく2回目以降の条件も示す必要があります。

消費者庁は事業者向けの資料を公開しており、カートシステム側の対応点もまとめられています。最終確認画面の表示方法に関する消費者庁の参考資料と、特定商取引法ガイドをご確認ください。

構築の面から見ると、注意点は2つです。

• 金額を動的に出す必要がある。 初回価格と2回目以降の価格が違う場合、確認画面で両方を計算して表示します。固定文言では足りません。
• 後付けが難しい。 確認画面はカートの奥にあり、テンプレートの改修範囲が広くなります。前章の集計でも、14%が公開後の修正でした。

制度の運用は更新されることもあるため、公開前に最新の資料を確認しています。詳細は特定商取引法の表記に必要な項目でも扱っています。

11稼働12か月の決済エラー推移

要点： 決済エラーは、稼働から時間が経つほど増えます。カードの有効期限が順に切れていくためです。洗い替えと自動再試行を入れた案件では、エラーの多くがその月のうちに復旧していました。

決済エラー率と、そのうち復旧した割合を並べました。

動きは2つあります。ひとつは、エラー率が時間とともに上がること。カードの更新が順番に来るためです。

もうひとつは、復旧率の差が開くこと。設計を入れた側は8割前後で安定し、入れていない側は3割まで下がります。差の分は、そのまま解約と同じ意味になります。

決済エラーは、お客様が離れた結果ではありません。放っておくと離れる原因になる、というだけです。

集客を強化する前に、ここを直すほうが効果的な場合もあります。ネットショップが売れない原因でも、入口より出口に穴があることは多いとお伝えしています。

12在庫と出荷をどうつなぐか

要点： 定期購入は、翌月以降の出荷予定が先に見えるという特徴があります。この予定を倉庫や基幹システムに渡せると、欠品も過剰在庫も減らせます。

単発の通販では、注文が入るまで需要が読めません。定期購入は、来月何件出るかが今日わかります。

活かすにはシステムをつなぐ必要があります。つなぎ方はECサイトの在庫連携｜倉庫・基幹とつなぐ方法で整理していますが、定期購入ECでは渡す情報が1つ増えます。確定した注文だけでなく、来月・再来月の出荷予定も渡すことです。

連携の形は主に3つです。

• CSVの受け渡し。 決まった時刻にファイルを出し、倉庫側が取り込みます。導入が早い方法です。
• APIでの連携。 在庫数や出荷実績をその都度やり取りします。件数が多い場合に向きます。
• 倉庫システム側に合わせる。 委託先が指定の形式を持つなら、それに寄せるのが最短です。

どの形でも、まず先方の仕様書を入手してください。仕様が固まらないまま見積りを取ると、金額が後から動きます。

13立ち上げでよくある失敗

要点： 多いのは、商品の周期パターンを増やしすぎることです。選択肢が多いほど親切に見えますが、テストも運用も一気に重くなります。まず2〜3種類から始めてください。

これまでに見てきたつまずきです。始める前なら避けられます。

• 周期のパターンを増やしすぎる。 自由な周期を許すと組み合わせが一気に増えます。まずは2〜3種類に絞ってください。
• テスト期間を短く見積もる。 「翌月」を確認しないと動作が見えません。日付を進めた検証環境を用意し、数回分は回してください。
• 初回キャンペーンの条件を後から変える。 走っている契約に遡って適用すると、計算が複雑になります。変更は新規からと決めておくのが安全です。
• 解約の理由を記録していない。 選択肢を用意して残すだけで、次の改善の材料になります。

忘れられがちなのが自動送信メールです。次回発送のお知らせ、決済失敗の連絡、周期変更の完了通知。種類が多く、文面の準備で公開が延びる例をよく見ます。

14依頼前に決めておく5つのこと

要点： 商品と周期、初回の条件、締め日、決済手段、出荷の担当。この5つが決まっていれば、見積りの精度は大きく上がります。文章でなく箇条書きで構いません。

見積り依頼の前に、次の5点をメモしてお渡しください。

1. 扱う商品と、想定する周期。 「化粧水を4週ごと」「お米を毎月10日」のように、具体的に書きます。
2. 初回の条件。 割引の有無、回数の縛り、お試しからの引き上げなど。
3. 変更・解約の締め日。 何日前まで受け付けるか。仮の数字で構いません。
4. 使いたい決済手段。 すでに決済代行会社と契約があれば、その社名も添えてください。
5. 出荷を誰がやるか。 自社か、委託か。委託先が決まっていれば、その仕様書もあわせて。

この5点があると、初回の打ち合わせで具体的な話ができます。曖昧なまま見積りを取ると、各社の前提がそろわず比較になりません。ECサイト制作会社の選び方でも、前提をそろえる大切さをお伝えしています。

まだ商品も固まっていない段階なら、ネットショップ開設の方法から整理するほうが近道です。

15まとめ｜構築を決める3ステップ

要点： 周期のパターンを数え、自動化する範囲を決め、方式をそろえて見積りを取る。この順で進めれば、機能の数ではなく運用の形で判断できます。

進め方を3つにまとめます。

1. 周期のパターンを数える。 3つ以内なら特化型ASPで足り、それ以上なら拡張か独自開発を検討します。
2. 自動化する範囲を決める。 決済エラーの再試行、周期変更、出荷データの受け渡し。この3つを自動にするか手作業にするかを、公開前に決めます。
3. 方式をそろえて見積りを取る。 「この方式で」と前提を書いて依頼すると、比較できる金額が返ってきます。

定期購入は、一度動き出すと毎月静かに売上が積み上がる売り方です。そのぶん、仕組みの小さな穴も毎月積み上がります。最初の設計に手をかける価値は、ここにあります。

定期購入ECの構築はECサイト制作のサービスページから承っています。自社ECとモールのどちらで始めるか迷っている方は、自社ECとモール出店の違いもご覧ください。

16よくある質問

1. 今のECサイトに定期購入を後から追加できますか

追加できることが多いです。ShopifyやEC-CUBEなら、定期購入のアプリやプラグインを載せる形が一般的です。ただし決済代行会社が継続課金に対応している必要があります。

2. 定期購入ECの構築にはどのくらい期間がかかりますか

特化型ASPで1〜2か月、既存カートの拡張で1.5〜3か月、独自開発なら5〜9か月が目安です。翌月以降の動作確認が必要なので、テスト期間は長めに見てください。

3. 解約はマイページからできるようにすべきでしょうか

おすすめしています。電話のみの受付は問い合わせが集中しやすく、法対応の面でも見直しを求められます。引き止めたいなら、解約の前にスキップや周期変更を見せてください。

4. 決済エラーが出たとき、システムは何をしてくれますか

設計しだいです。何日後に何回再試行するか、通らなかったら停止するか通知するかを決めておけば、その通りに動きます。決めていないと、毎月の手作業になります。