定期通販（サブスクEC）の構築：継続課金と解約導線の設計

定期通販（サブスクEC）のシステム構築で成否を分けるのは、最初の注文を受ける仕組みではなく、二回目以降の注文を毎回正しく作り、決済し、出荷し続ける仕組みです。定期購入では、顧客によるお届け日の変更、スキップ、商品の入れ替え、配送先の変更、そして解約が日常的に発生します。さらに、カードの有効期限切れや残高不足による決済エラーも一定の割合で起こります。これらの「継続中に起きること」を最初から設計に入れておかないと、運用担当者が毎日手作業で例外を処理することになります。

この記事は、健康食品・化粧品・食品・日用品などを定期便で販売したい、または既存の通販に定期購入の仕組みを追加したいと考えている事業者の方に向けて書いています。定期通販で必要になる機能、継続課金の流れ、スキップや変更の設計、決済エラーへの対応、解約導線の考え方、構築方式の比較、よくある失敗までを一通り説明します。

先に結論をまとめると、定期通販のシステムは「定期契約」と「その契約から毎回生まれる注文」を分けて管理する構造にし、変更・スキップ・解約・決済エラーという四つの例外を、顧客が自分で処理できる画面と運用担当者向けの画面の両方で扱えるようにすることが基本です。

定期通販のシステムが通常のECと違う点

通常のECは「一回の注文」で取引が完結します。定期通販では、顧客と結ぶのは「定期購入の契約」であり、そこから一定の周期で注文が生まれ続けます。この違いが、システムの構造にそのまま表れます。

定期通販の売上は、新規の獲得よりも継続によって積み上がります。そのため、システムの設計で重視すべきなのは、継続している顧客にとっての扱いやすさと、運用担当者が例外処理に追われない仕組みです。

定期通販に必要な主な機能

定期通販で検討対象になる機能を、顧客側と運用側に分けて整理します。

顧客が使う機能

• 定期コースの申し込み：お届け周期（毎月、隔月、○日ごとなど）、初回のお届け日、決済手段の登録
• マイページでの確認：次回のお届け予定日、内容、金額、過去のお届け履歴
• お届け日の変更：次回のみ変更、周期そのものの変更
• スキップ：次回のお届けを一回休む
• 商品・数量の変更：同じコース内で別の商品に入れ替える、数量を増減する
• 配送先・決済手段の変更
• 解約（休止）の手続き

運用側が使う機能

• 定期契約の一覧と検索、契約ごとの変更履歴
• 次回注文の自動作成と、その前の確認・締め処理
• 決済エラーになった注文の一覧と再決済の操作
• 顧客からの電話・メールでの変更を代行入力する画面
• 出荷予定の集計（何日に何をいくつ出すか）
• 解約理由の記録と集計

継続課金の仕組みそのものについては、用語ページ継続課金（サブスクリプション決済）で基本を説明しています。

継続課金の流れを設計する

定期通販の心臓部は、「次回注文の作成」「決済」「出荷」の繰り返しです。この流れを、時間軸に沿って具体的に決めます。

1. 次回お届け予定日から逆算して、注文作成日を決める：たとえばお届け予定日の数日前に、定期契約から次回の注文を自動で作成します。作成日の前日までは顧客がスキップや変更をできる、という締めを設けます。
2. 注文作成時に決済する：登録済みの決済手段で与信または売上確定を行います。決済のタイミングを注文作成時にするか、出荷時にするかは、利用する決済サービスの仕組みと返品・キャンセル時の扱いを踏まえて決めます。
3. 決済が成功した注文を出荷指示に回す：出荷予定日ごとにまとめて、倉庫や物流代行に指示を送ります。
4. 出荷実績を受けて、顧客に通知する：発送完了のメールを送り、マイページにも反映します。
5. 次々回のお届け予定日を計算する：周期に従って次の予定日を設定し、1に戻ります。

この流れで重要なのは「締め」の考え方です。注文が作られたあとに顧客がスキップを希望しても、すでに決済や出荷準備が進んでいれば止められないことがあります。顧客にとって「いつまでなら変更できるか」が分かりやすく示されていることと、運用側の締め処理が一致していることが、問い合わせを減らす前提になります。

決済手段の保存と決済代行の使い方

定期通販では、カード情報などの決済手段を保存して繰り返し使います。カード番号を自社のシステムで直接保持すると、セキュリティ上の負担が大きくなるため、決済代行（PSP）の仕組みを使い、カード情報は決済代行側に預けて自社はその参照キーだけを持つ形が一般的です。決済代行サービスによっては、継続課金の周期管理や自動の再決済まで提供しているものもあり、どこまでを決済代行に任せ、どこからを自社のシステムで持つかが設計の分かれ目になります。

SaaSの月額課金と共通する部分も多いため、SaaSの課金システム実装：サブスク決済と請求書払いの作り方もあわせて参考にしてください。

スキップ・変更の設計：顧客の自己完結を目指す

定期通販の問い合わせの多くは、お届け日の変更やスキップの依頼です。これをマイページで顧客自身が完結できるようにすると、運用負担が大きく下がり、顧客にとっても電話がつながるのを待つ必要がなくなります。

設計で決めておくべき点は次のとおりです。

• スキップできる回数に上限を設けるか：上限を設けない場合、実質的な休止が長く続く契約が残ります。一定回数以上の連続スキップは休止として扱うなど、ルールを決めます。
• 変更の締め：何日前まで変更を受け付けるかを、注文作成日と一致させます。締めを過ぎた場合は「次々回から変更」として受け付けるなど、顧客が迷わない表示にします。
• 商品の入れ替えと価格：コース内で別の商品に変えたときの価格、定期割引の適用条件をあらかじめルール化します。
• 回数特典との関係：「○回目に特典を同梱」などの施策がある場合、スキップした回を数えるかどうかを決めておきます。
• 変更履歴の保存：誰が（顧客か運用担当者か）、いつ、何を変更したかを記録し、問い合わせ時に確認できるようにします。

架空の例：健康食品の定期便

毎月一回お届けの健康食品を販売している事業者を考えます。当初は変更・スキップを電話とメールでしか受け付けておらず、毎月の締め日前に問い合わせが集中していました。マイページに次回お届け日の変更とスキップの機能を加え、締め日をお届け予定日の5日前に統一してマイページ上に明示したところ、電話での問い合わせの多くがマイページでの操作に置き換わり、運用担当者は決済エラーや配送トラブルなど、人が対応すべき案件に時間を使えるようになりました。このように、顧客の自己完結は運用負担の軽減と顧客体験の両方に効きます。

決済エラーへの対応を仕組みにする

定期通販では、カードの有効期限切れ、利用限度額の超過、カードの停止などにより、一定数の決済エラーが毎回発生します。これを放置すると、出荷されない注文と、気づかないうちに離れていく顧客が積み上がります。決済エラーへの対応は、次の流れで仕組みにします。

1. エラーを検知して注文を保留にする：決済が失敗した注文は出荷に回さず、「決済エラー」の状態で止めます。
2. 顧客に通知する：決済手段の更新を案内するメールを送り、マイページから更新できるようにします。
3. 一定期間後に再決済する：決済手段が更新されたら自動で再決済します。更新がない場合も、間隔をあけて数回再試行する設計が考えられます。
4. 期限を過ぎたら運用側で判断する：再試行しても決済できない場合は、その回をスキップ扱いにする、契約を休止にするなどのルールに従って処理し、必要に応じて電話などで連絡します。

通知のメールは、何が起きたのか、顧客が何をすればよいのか、いつまでに対応しないとどうなるのかを短く明確に書きます。

決済エラーの件数と、そのうち回復できた件数を毎月見ておくと、案内文面や再試行の間隔を改善する手がかりになります。

解約導線の設計：分かりやすさと引き止めの線引き

解約導線は、定期通販の設計で最も慎重さが求められる部分です。解約しにくい設計は短期的には継続を伸ばすように見えても、顧客の不信感や苦情、さらには法令上の問題につながるおそれがあります。通信販売の定期購入については、申し込み時の表示や解約方法の示し方に関する規制が設けられており、改正も行われています。具体的な要件は消費者庁などの公的機関の最新情報を確認し、必要に応じて専門家に相談してください。

設計の基本方針としては、次の点を押さえます。

• 申し込み時点で、定期購入であること、お届け周期、各回の金額、解約の条件と方法を分かりやすく示す
• 解約の手続き方法をマイページや案内で明確にし、探さなくても見つかるようにする
• 解約の前に、スキップ、お届け周期の変更、休止といった代わりの選択肢を案内するのはよいが、それを経由しないと解約できない作りにはしない
• 解約理由を任意で聞き、記録して集計する
• 解約手続きの完了と、最終のお届け・請求がいつになるかを明確に通知する

解約理由の記録は、商品やサービスを改善するための貴重な情報です。「量が多すぎる」「お届け周期が合わない」「効果を感じない」「価格」といった理由を集計すれば、コースの設計や周期の選択肢、案内の改善につなげられます。利用データから解約の兆しをとらえる方法については、解約の予兆を検知する：利用データから解約リスクを見つける方法で扱っています。

構築方式の比較と選び方

定期通販のシステムを用意する方法は、主に次の三つです。

判断の軸は、「自社の継続モデルが一般的な定期便の型に収まるか」です。毎月同じ商品を届ける、周期を選べる、スキップできる、といった範囲であれば既製のサービスで十分に対応できることが多くあります。毎回届く内容が変わる頒布会、顧客が組み合わせを選べるボックス、会員ランクに応じた特典、外部の会員基盤との連携など、独自の継続モデルが事業の中核にある場合に、個別開発を検討する意味が出てきます。継続課金モデルの事業設計そのものについては、サブスク事業の始め方：既存商品を継続課金モデルに変える方法も参考にしてください。

運用開始後に見る指標と改善の進め方

定期通販のシステムは、公開して終わりではありません。継続の状況を数字で確認し、コースの設計や画面、案内を改善していく運用が欠かせません。そのためには、システムの設計段階で、どのデータを記録しておくかを決めておく必要があります。

最低限見ておきたいのは、申し込みから何回目で解約が多いか（継続回数ごとの残存状況）、スキップや周期変更の利用状況、決済エラーの発生と回復の状況、解約理由の内訳です。たとえば二回目のお届け前に解約が集中しているなら、初回お届け後の案内や商品の使い方の説明に課題があるかもしれません。スキップが多い顧客は量や周期が合っていない可能性があるため、周期の選択肢を増やす、少量のコースを用意するといった改善が考えられます。

こうした分析は、申し込み日、各回の注文と決済結果、変更・スキップの履歴、解約日と理由が、顧客と契約に紐づいて記録されていれば行えます。逆に、変更履歴を上書きで保存していたり、解約理由を自由記述のメモにしか残していなかったりすると、後から集計できません。指標の設計についてはKPI改善コンサルティングの領域とも重なるため、売上を継続と獲得に分解して見る考え方もあわせて検討してください。指標を見る頻度は月次で十分なことが多く、毎月の振り返りの場で「先月の解約理由の上位」「決済エラーの回復状況」「スキップの多いコース」の三点を確認するだけでも、改善の打ち手が具体的になります。

よくある失敗とその避け方

• 締め日のルールが画面と運用で食い違う：マイページでは変更できるように見えるのに、実際には注文がすでに作られていて反映されない、という状態は問い合わせの原因になります。締めのルールを一つに決め、画面と処理の両方で同じルールを使います。
• 決済エラーの処理が担当者任せになっている：毎月エラーの一覧を見て一件ずつ連絡しているうちに、対応が後回しになり、顧客が離れていきます。通知と再決済を自動化し、人が対応するのは期限切れのものだけにします。
• 変更履歴が残っていない：「スキップしたはずなのに届いた」という問い合わせに、誰がいつ何を変更したのかを確認できないと、対応に時間がかかり、顧客の信頼も損ねます。
• 解約導線を分かりにくくしてしまう：短期的な継続を優先して解約手続きを分かりにくくすると、苦情や評判の悪化につながります。代わりの選択肢を案内しつつ、解約は迷わずにできるようにします。
• 出荷予定を集計していない：定期通販は次回の出荷予定から需要が読めるのが利点ですが、集計していなければ在庫切れや過剰在庫が起きます。出荷予定日ごとの商品別数量を、仕入れや製造の計画に使える形で出力します。

構築前のチェックリスト

• 提供するコースの種類（周期、商品の選び方、回数特典の有無）を整理している
• 変更・スキップの締め日と、スキップ回数の上限を決めている
• 決済のタイミング（注文作成時か出荷時か）と、利用する決済代行サービスを検討している
• 決済エラー時の通知、再決済、期限切れ後の扱いのルールを決めている
• 解約の手続き方法と、申し込み時に表示する内容を整理し、制度面を確認している
• 倉庫・物流代行への出荷指示の方法と締め時刻を確認している
• 電話・メールでの変更依頼を代行入力する運用担当者の体制がある
• 継続回数、解約率、解約理由などの指標を見る仕組みを考えている

よくある質問

Q. 通常販売と定期販売を同じシステムで扱えますか？

扱えます。多くのカートサービスやECプラットフォームは、通常の注文と定期の注文を同じ店舗で受けられます。ただし、在庫の引当や出荷のまとめ方、顧客の会員情報の扱いが両者で共通になるため、定期の注文を通常の注文と同梱するかどうかなどの運用ルールを決めておく必要があります。

Q. 決済エラーはどのくらいの頻度で再試行すべきですか？

一律の正解はありません。顧客が決済手段を更新するまでの時間、出荷を待てる期間、決済代行サービスの仕様によって変わります。最初は通知と数回の再試行で始め、回復できた件数とタイミングを見ながら調整するのが現実的です。

Q. 解約の手続きを電話だけにしてもよいですか？

手続き方法の決め方には、制度上の要件や顧客の利便性の観点から注意が必要です。オンラインで申し込めるのに解約は電話だけ、という作りは顧客の不満につながりやすく、制度面の確認も欠かせません。最新の要件は公的機関の情報や専門家に確認したうえで決めてください。

Q. 既製サービスから個別開発に移ることはできますか？

できますが、定期契約のデータ（周期、次回お届け日、変更履歴）と、決済代行に預けている決済手段の扱いを移行できるかが課題になります。将来の移行を想定するなら、既製サービスを選ぶ段階で、データの出力方法と決済代行の扱いを確認しておくと安心です。

Otsumuに相談できること

毎月同じ商品を届ける定期便で、スキップや周期変更が一般的な範囲に収まるなら、定期通販に強いカートサービスや定期購入アプリを使い、社内で締め日や決済エラーの運用ルールを整えれば十分に始められます。この記事のチェックリストを埋めながら、既製サービスの機能と照らし合わせてみてください。

一方で、頒布会や組み合わせ自由のボックスなど独自の継続モデルを持っている、既製サービスでは決済エラーや変更の処理が手作業に残ってしまう、倉庫や会計との連携まで含めて設計し直したい、という場合は、外部の力を借りて全体の流れから設計した方が早く安定します。

Otsumuは、定期契約と注文の構造、締め処理、決済エラーの流れ、解約導線を事業の目的から逆算して設計し、既製サービスで足りる部分と個別に作るべき部分を切り分けたうえで、必要な機能に絞って開発します。継続モデルの事業設計から相談したい場合は新規事業開発コンサルティング、システム面はEC・通販システム開発でご案内しています。費用は範囲に応じて個別にお見積もりします。

定期便を始めたいが何から決めればよいか分からない、既存の仕組みの運用負担を減らしたい、といった段階でも構いません。30分の無料相談からご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01