この記事の対象: ShopifyでのEC構築・リニューアルを検討していて、定期購入（サブスクリプション）の導入を迷っている事業者
この記事で分かること: 導入前に自社で決めるべきこと／アプリで足りる範囲と制作会社に頼む範囲の境目／選定時に見る場所
定期購入は「アプリを入れれば始められる」と紹介されることが多い機能です。実際、商品ページに「定期購入」の選択肢を出すだけなら、作業としては短時間で終わることもあります。
問題はその先です。定期購入を入れた瞬間から、決済・在庫・問い合わせの3つが同時に増えます。しかも増え方が読みにくい。単発販売なら「注文が来たら送る」で完結していたものが、「次回いつ、どこに、何を、いくらで送るか」を店側が保持し続ける仕組みに変わるためです。
この記事では、アプリの機能一覧ではなく、導入前に自社で決めておくべきことと、どこまでアプリで足りて、どこからテーマ改修やカスタム開発が必要になるかの線引きを整理します。制作会社に相談する前に読んでおくと、見積もりの中身が理解できるようになります。
定期購入で本当に増えるのは「運用」である
単発販売と定期購入の構造的な違い
単発販売のECは、注文が発生したその時点で情報が確定します。住所も、金額も、数量も、注文が入った瞬間のスナップショットで固定される。
定期購入はここが違います。契約が生きている限り、顧客情報が「これから使われる予定のデータ」として残り続けます。
単発販売
- 注文時点で情報が確定する
- 発送したら関係が終わる
- カード情報は決済時のみ使う
- 在庫は注文分だけ読めばよい
定期購入
- 契約が生きている間ずっと更新され得る
- 次回の予定を店側が保持する
- カード情報を継続利用する前提になる
- 数か月先の在庫を読む必要がある
この違いから、運用の負担が生まれます。「カードの有効期限が切れた」「引っ越したので届け先を変えたい」「今月は余っているので1回飛ばしたい」——単発販売では発生しなかった問い合わせが、契約数に比例して増えていきます。
契約が積み上がったときに起きること
商品も客層も違えば発生件数は変わるので、ここでは件数ではなく「何が起きるか」と「誰の時間が消えるか」を整理します。
| 発生すること | 起きる理由 | 対応の中身 |
|---|---|---|
| 決済失敗 | カードの有効期限切れ、限度額、カード再発行 | 顧客への連絡、カード再登録の案内、再課金 |
| 配送先・配送日の変更依頼 | 引っ越し、旅行、受け取れない曜日 | 管理画面で該当契約を探して修正 |
| スキップ（1回休み）の依頼 | 前回分が消費しきれていない | 次回配送日・次回課金日の変更 |
| 解約の申し出 | 消費ペースが合わない、価格、飽き | 契約停止、理由の記録、引き止め対応の判断 |
| 数量・商品の変更 | 家族構成の変化、味やサイズの変更 | 契約内容の編集、差額の扱いを判断 |
一件あたりの作業は数分でも、契約が積み上がるほど毎月まとまった時間が消えます。しかも配送サイクルの締め日前後に集中するため、月末や月初に負荷が寄ります。
ここで効いてくるのが、顧客が自分で操作できる範囲をどこまで作るかという設計です。マイページからスキップと配送先変更ができれば問い合わせは大きく減り、できなければ全部メールと電話で来ます。この判断は導入前にしかできません（後から作ることはできますが、そのときは追加の開発費がかかります）。
よくあるつまずき方を、具体的な場面で
抽象的に「運用が大変」と言っても伝わりにくいので、実際に起きる形で3つ挙げます。
1. 決済失敗が静かに積み上がる
月1回配送のコーヒー豆を売っているストアで、カードの有効期限切れによる課金失敗が数件発生したとします。アプリは自動でリトライしますが、期限切れは何度リトライしても通りません。顧客には「カードを更新してください」というメールが自動送信されますが、迷惑メールに入って気づかれない。結果、顧客は「なんとなく届かなくなった」まま離脱し、店側も管理画面の失敗一覧を見ていないので気づかない。売上が減った理由が、数か月後まで分からないという状態が生まれます。
対策は難しくありません。決済失敗の一覧を週次で見る担当を決め、自動メールが2回不発なら電話またはSMSに切り替える、と手順を決めておくだけです。仕組みではなく運用の問題なので、導入時に決めておかないと誰もやりません。
2. 「今月だけ止めたい」がすべて電話で来る
マイページにスキップ機能を出していないと、この依頼は全部メールと電話になります。しかも締め日直前に集中します。対応する人は、管理画面で顧客を検索し、契約を開き、次回配送日を1か月後ろにずらす。この作業自体は数分ですが、締め日前の数日に集中すると他の業務が止まります。
さらに厄介なのは、次回配送日をずらしたつもりが、次回課金日は動いていなかったという取り違えです。アプリによって両者の連動の仕方が違うため、操作した人の理解が浅いと「課金だけ走って商品が出ない」という事故になります。
3. 縛りの説明が画面に出ていない
「初回半額、3回継続が条件」という設計にしたのに、条件が商品ページの下部に小さく書かれているだけ、というケースです。顧客は2回目で解約しようとして、できない、あるいは違約金を請求される。ここで「聞いていない」というやり取りが発生します。
条件の明示は、商品ページ・カート・購入確認画面の3か所に出すのが基本線です。どこに何をどう出すかは、アプリの標準ウィジェットで足りるかテーマ改修が要るかが分かれるポイントでもあります。
始める前に決めておくべき5項目
制作会社に相談する前に、社内で答えを出しておくと話が早い項目を挙げます。ここが決まっていないと、アプリ選定も見積もりも進みません。
この5つが決まってはじめて、アプリの機能要件が書けます。逆に言えば、決まる前にアプリを比較しても意味がありません。
1. 課金モデル：都度配送型か、前払い一括型か
定期購入と呼ばれるものには、大きく2つの型があります。
都度配送型は、配送のたびに課金するモデルです。毎月コーヒー豆を送る、隔月でサプリを送る、といった消耗品の販売がこれにあたります。日本のD2Cで「定期便」と呼ばれているものの多くはこの型です。
前払い一括型は、期間分をまとめて先に受け取るモデルです。オンライン講座の年間会員、コミュニティの月額課金、デジタルコンテンツへのアクセス権などが該当します。物理的な配送が伴わないケースが多いのが特徴です。
この2つは、必要な機能がかなり違います。
| 都度配送型 | 前払い一括型 | |
|---|---|---|
| 主な用途 | 消耗品・食品・化粧品 | 会員権・デジタルコンテンツ |
| 在庫連動 | 必須 | 不要または限定的 |
| 配送日の管理 | 中核機能 | ほぼ不要 |
| スキップ機能 | 必要 | 概念がない |
| 解約時の返金 | 次回以降の停止で足りる | 日割り・月割りの判断が要る |
| 運用の重さ | 重い | 軽い |
自社がどちらかを最初に確定してください。「両方やりたい」場合は要件が倍になるので、フェーズを分けることを勧めます。
2. 顧客がどこまで自分で操作できるか
これが運用コストを決める最大の変数です。次の5つについて、顧客セルフサービスにするか、店側の手作業にするかを決めます。
- 解約
- 次回配送日の変更
- スキップ（1回休み）
- 配送先の変更
- 数量・商品の変更
すべてセルフにすれば問い合わせは最小になりますが、解約が簡単になるぶん継続率は下がります。すべて手作業にすれば解約は減りますが、対応する人の時間が消え、顧客の不満も溜まります。
判断の材料として、特定商取引法や消費者契約法の観点から、解約導線を過度に分かりにくくする設計には法的なリスクがある点は押さえておいてください。「電話でしか解約できない」「解約ボタンをフッターの奥に隠す」といった設計は、行政指導や返金対応につながる可能性があります。適法性の最終判断は専門家の領域ですが、解約導線はマイページから到達できる位置に置くのを基本線とするのが安全です。
制作会社の立場から言うと、ここを曖昧にしたまま進む案件が一番揉めます。「解約はマイページからできるようにしてください」と一行だけ書かれた要件で作ると、解約前に引き止めのアンケートを出したかった、といった話が受け入れテストの段階で出てくる。画面遷移のレベルで決めておくと手戻りがありません。
具体的には、次の粒度まで文章にしておくと発注書として機能します。
- マイページのどのメニューから解約に入れるか
- 解約ボタンを押した直後に何を表示するか（確認だけか、引き止め提案を挟むか）
- 引き止めを挟むなら、提示するのは「スキップ」か「頻度変更」か「割引」か
- 解約理由を選択式で取るか、取らないか。取るなら選択肢は何か
- 解約完了後にメールを送るか
3. 縛りと特典をどう設計するか
「初回半額、ただし3回の継続が条件」といった設計をするかどうかです。
継続回数の縛りを入れる場合、次のことが必要になります。
- 購入時点で条件を明示する画面表示（商品ページ・カート・確認画面）
- 縛り期間中の解約をシステムでどう扱うか（ブロックする／違約金を請求する／人が判断する）
- 顧客からの「解約したい」に対する応答の型
システム側でブロックする場合、アプリの機能で対応できるか、テーマ側の実装が要るかが分かれます。多くのサブスクアプリは「最低継続回数」の設定を持っていますが、その回数に達していない顧客が解約ボタンを押したときに何が表示されるかは実装によって違います。何も説明のないエラーが出るだけの実装だと、そのまま問い合わせになります。ここは比較検討の段階でデモ環境を触って確認すべきポイントです。
なお、縛りを入れずに「継続するほど割引率が上がる」形で継続を促す設計もあります。運用は軽くなり、クレームの種も減りますが、割引の原資を用意できるかどうかが前提になります。どちらが自社に合うかは、粗利率を見て決める話です。
4. 決済手段をどこまで受けるか
定期購入は「保存された決済手段を店側が繰り返し使う」仕組みなので、対応できる決済手段が単発販売より狭くなります。
クレジットカードは基本的に問題ありません。一方で、コンビニ払い・代金引換・銀行振込のように、購入のたびに顧客の能動的な操作が必要な決済手段は、定期購入との相性が悪い、あるいは対応していないケースがほとんどです。
自社の顧客層でカード以外の比率が高い場合、定期購入に乗せられる顧客が最初から限られるということになります。これは施策の効果見込みそのものに関わるので、アプリ選定より先に確認してください。判断材料は自社の実データです。過去の注文を決済手段別に集計すれば、カード比率はすぐ出ます。
5. 管理画面を触る人を決める
意外に抜けるのがこれです。定期購入の運用は、誰か一人が毎日〜週に数回、管理画面を見る前提で成り立ちます。
- 決済失敗した契約の一覧を確認する
- 変更依頼を反映する
- 翌月の配送予定数を見て発注をかける
この作業を担当する人が社内にいるのか、外注するのか。担当者が変わったときの引き継ぎはどうするのか。運用体制が用意できないなら、定期購入は入れないほうがいいというのが正直なところです。機能は動いていても、放置された決済失敗が積み上がって売上が静かに減っていく、という状態が一番よくありません。
アプリで足りる範囲と、テーマ改修が要る範囲
Shopifyの定期購入は、Shopifyの標準機能であるサブスクリプションAPI（Subscription APIs）の上に、サードパーティのアプリが機能を載せる構造になっています。この構造を理解しておくと、「なぜこれはアプリの設定でできて、これはできないのか」が読めるようになります。
3つの層に分けて考える
Shopify本体（Subscription APIs）
- 契約データの保持
- 継続課金の実行
- 決済手段の保存
サブスクアプリ
- プランの作成・管理
- 顧客用マイページ
- 決済失敗時のリトライ
- 管理画面のUI
テーマ（Liquid）
- 商品ページの選択UI
- カート・カート内の表示
- 訴求のための独自セクション
下の層ほど自由に作れるが、作るぶん費用と保守が発生する。
アプリの多くは、商品ページに埋め込むウィジェット（購入オプションの選択UI）を提供しています。テーマに対応していればブロックを挿入するだけで表示され、ここまでは設定作業の範囲です。
線引きの目安をまとめます。
| やりたいこと | 判定 |
|---|---|
| 商品ページに「都度購入／定期購入」の選択肢を出す | アプリの標準ウィジェットで足りることが多い |
| 定期割引率をプランごとに設定する | アプリの設定範囲 |
| 顧客マイページでスキップ・解約させる | アプリが提供するページで足りる（デザインは制約あり） |
| ウィジェットの見た目をブランドに合わせて作り替える | テーマ改修が要る |
| 定期購入専用のLP・訴求ページを作る | テーマ改修（セクション追加） |
| 「定期便だけの限定商品」を一般顧客に見せない | 要件次第。多くの場合カスタム実装 |
| 定期購入者だけに別価格を出す | 実装が複雑。要件を詰める必要あり |
| 基幹システム・WMSと契約データを連携する | カスタム開発（API連携） |
| 複数商品を自由に組み合わせるカスタムボックス | 専用アプリ、またはカスタム開発 |
大まかには、「Shopifyの管理画面の中で完結する話」はアプリで足り、「顧客が見る画面の見た目を変える話」と「外部システムと繋ぐ話」は制作会社の作業になると捉えておくと外れません。
見た目を作り替えるときに注意すること
アプリが提供するマイページは、多くの場合アプリ側のドメインやiframe、あるいはアプリが用意したテーマ拡張の中で描画されます。ここのデザインをどこまで変えられるかはアプリによって大きく違い、CSSで色とフォントを変えられる程度のものから、テンプレートごと差し替えられるものまで幅があります。
ブランドサイトとして統一感を求めるなら、比較検討の段階でこの点を必ず確認してください。「マイページだけ明らかに別サイトに見える」という状態は、後から直そうとすると高くつきます。
確認の仕方は単純です。デモ環境でマイページを開き、ブラウザの開発者ツールで中身がiframeかどうかを見る。iframeなら、外側からCSSで手を入れる余地はほぼありません。アプリ側が用意した設定画面で変えられる範囲が上限になります。
アプリを選ぶときに見る場所
日本のShopifyストアで使われている定期購入アプリには、Shopify自身が提供する Shopify Subscriptions、海外で広く使われている Recharge、Seal Subscriptions、Appstle Subscriptions、日本語対応と国内商習慣への対応を打ち出した 定期購買（Mikawaya Subscription） といった選択肢があります。
ただし、ここで「どれがおすすめか」を断定するつもりはありません。料金体系も機能も更新されるうえ、必要な機能は前章で挙げた5項目の答えによって変わるためです。最新の料金・機能は必ず各アプリのApp Storeページと公式サイトで確認してください。
代わりに、比較のときに実際に見るべき箇所を挙げます。
最終更新日とレビューの新しさ
Shopify App Storeの各アプリページには最終更新日が表示されます。ここが長く動いていないアプリは、Shopify本体の仕様変更に追随できていない可能性を疑ってください。定期購入はShopifyのAPIに深く依存する機能なので、更新の止まったアプリを使うのは将来のリスクです。
レビューも、総数と星の数より直近のレビュー内容を読むほうが役に立ちます。仕様変更で壊れた、サポートが返ってこない、といった話はここに出ます。星5のレビューが古く、星1のレビューが新しいアプリは要注意です。
日本語対応の「どこまで」
「日本語対応」と書かれていても、実態は3段階に分かれます。
| 段階 | 内容 |
|---|---|
| 顧客画面のみ日本語化できる | ウィジェットとマイページの文言を自分で書き換えられる |
| 管理画面も日本語 | 運用担当者が英語を読まずに済む |
| サポートが日本語 | 障害時に日本語でやり取りできる |
運用を担当する人が英語に不慣れなら、2段階目以上を条件にしてください。海外製アプリでは、文言の書き換えはできても管理画面は英語のまま、という1段階目にとどまるものがあります。
見落としやすいのが、顧客に自動送信されるメールです。決済失敗の通知や次回配送のリマインドが英語のまま出ていた、というのは実際に起きます。デモ環境で、顧客宛メールのテンプレートが編集できるかまで見てください。
サポートの応答手段と時間帯
定期購入で障害が起きると、顧客のカードに意図しない請求が飛ぶ、あるいは請求が飛ばずに商品だけ出ていくという形で金銭に直結します。単なる表示崩れとは緊急度が違います。
- 問い合わせ手段はメールのみか、チャットもあるか
- 時差はどれくらいか（返答が翌営業日になる可能性）
- 日本の代理店やパートナーが窓口を持っているか
海外製アプリを選ぶ場合、日本時間の夜に投げた質問の返信が翌日以降になる前提で運用設計してください。緊急時に自社側で何を止められるか（プランの販売停止、ウィジェットの非表示）を先に把握しておくと、待っている間の被害を抑えられます。
自社テーマとの相性
使っているテーマがOnline Store 2.0に対応していれば、アプリブロックの埋め込みが可能で、導入は素直に進みます。古いテーマ（vintage theme）を使い続けている場合、アプリのウィジェットを手動でLiquidに埋め込む作業が発生し、テーマ更新のたびに壊れるリスクを抱えます。
テーマ自体の選び方については、こちらで判断軸を整理しています。
移行のしやすさ
「合わなかったら別のアプリに乗り換えればいい」と考えがちですが、定期購入アプリの乗り換えは単発販売のアプリとは難易度が違います。
契約データそのものはShopify側に残りますが、アプリ独自に持っている情報——顧客ごとのカスタム設定、割引ルール、送信済みメールの履歴、スキップの回数など——はアプリの外に出せないことがあります。移行ツールを持っているアプリもありますが、稼働中の契約を止めずに移すのは相応の手間です。
最初の選定で、将来やりたいことまで含めて要件を書いておく理由がここにあります。
導入後に効いてくる4つの論点
導入時点では見えにくいものの、運用が始まると必ず出てくる話をまとめます。
月額の積み上がり
サブスクアプリの料金体系には、契約数や取引額に上限を設けた無料プランを持つもの、月額固定のもの、取引額に対する手数料が乗るものがあります。同じアプリでも、契約数が増えると上位プランに移る設計になっていることが多いので、導入直後の金額ではなく、目標契約数に達したときの金額で比較してください。
注意したいのは、Shopifyストアには定期購入アプリ以外にもアプリが積み上がるという点です。レビュー、ポイント、メール配信、配送日指定——一つひとつは小さくても、合計すると無視できない固定費になります。
この構造は、月額制のWeb制作サービスと同じ性質の問題を抱えています。判断の考え方はこちらの記事が参考になります。
繰り返しますが、各アプリの最新の料金は必ず公式のApp Storeページで確認してください。 料金体系は改定されますし、既存ユーザーだけ旧プランに据え置かれるケースもあります。
表示速度への影響
サブスクアプリのウィジェットは、商品ページにJavaScriptを追加します。1つなら誤差の範囲ですが、他のアプリと合わせて何本もスクリプトが積まれると、商品ページの読み込みが目に見えて遅くなります。
商品ページは購入直前の画面なので、ここの速度低下は売上に直結します。導入前後でLighthouseやPageSpeed Insightsのスコアを測っておき、悪化幅を把握してください。測るのは導入前と導入直後の2回、同じ商品ページ・同じ条件で行うのが前提です。悪化が大きい場合、ウィジェットの読み込み方（遅延読み込みにする、必要なページだけで読む）をテーマ側で調整する余地があります。これは制作会社の作業範囲です。
アプリを外したときに残るもの
アンインストールしても、テーマのコードにアプリが書き込んだ断片が残ることがあります。特に、vintage themeに手動で埋め込んだウィジェットのコードや、アプリが追加したカスタムCSSは自動では消えません。
さらに重要なのは、アプリを外すと稼働中の定期購入契約がどうなるかです。多くのアプリでは、アンインストール後に契約の管理ができなくなり、顧客のマイページも機能しなくなります。契約自体はShopify側に残るため、課金だけが走り続けて誰も止められない、という最悪のケースも起こり得ます。
アプリを外すときは、稼働中の契約をすべて処理してからが原則です。この手順もアプリごとに違うので、選定時にドキュメントを確認しておいてください。
運用マニュアルがないと事故が起きる
前章でも触れた運用担当の話は、導入後に一番効いてきます。定期購入の管理画面は、単発注文の管理画面より情報量が多く、操作も複雑です。少なくとも次の3点は、担当者が理解していないと操作ミスが顧客に届きます。
- 「次回配送日」と「次回課金日」が別の概念であること
- 契約を編集したとき、次回から反映されるのか今回から反映されるのか
- 決済失敗したときのリトライが自動で何回走り、何回目で止まるのか
導入時に運用マニュアルを作る工数を、制作費とは別に見込んでおいてください。制作会社に依頼するなら、この作成を見積もりに含めるか確認しておくとよいでしょう。スクリーンショット付きで、よくある依頼への対応手順（スキップ・住所変更・解約・再開）を並べるだけでも、担当者交代時の事故は大きく減ります。
立ち上げをフェーズに分ける
すべてを一度に作ろうとすると要件が膨らみ、決められないまま止まります。実務では次のように分けると進みます。
フェーズ1：最小構成で動かす
対象商品を1〜2点に絞り、アプリの標準ウィジェットと標準マイページのまま公開します。目的は売上より運用の実測です。どんな問い合わせが、どのくらいの頻度で来るのかを自社のデータとして取ります。
フェーズ2：問い合わせの多い順に潰す
実測で分かった上位の問い合わせを、セルフサービス化またはFAQで潰します。ここで初めて「マイページのどこに何を置くか」を、推測ではなく実績に基づいて決められます。
フェーズ3：見た目と訴求を作り込む
ウィジェットのデザイン調整、定期購入専用の訴求ページ、初回特典の設計はここです。運用が回る目処が立ってから投資するほうが、無駄が出ません。
フェーズ4：外部システムと繋ぐ
基幹システムやWMSとの連携は最後です。契約の内容や運用フローが固まる前に繋ぐと、仕様変更のたびに連携部分を作り直すことになります。
この順番を守ると、フェーズ1で「やっぱり自社商品には合わない」と分かった場合の損失も小さく済みます。
効果をどう測るか
定期購入は「入れた」で終わらせず、続ける価値があるかを数字で見る必要があります。業界平均のような外部の数字を追うのではなく、自社の数字を定義どおりに測り続けることが重要です。最低限、次の4つを定義しておいてください。
| 指標 | 定義の例 | 見る目的 |
|---|---|---|
| 定期購入の申込率 | 対象商品の注文のうち、定期を選んだ割合 | 訴求とUIが機能しているか |
| 継続率 | n回目の配送を迎えた契約数 ÷ 初回配送した契約数 | どの回で離脱が起きるか |
| 解約率 | 当月の解約数 ÷ 月初の稼働契約数 | 全体の目減りペース |
| 決済失敗率 | 当月の課金失敗数 ÷ 当月の課金試行数 | 運用の取りこぼし |
特に見るべきは継続率を「n回目」で刻むことです。単月の解約率だけを見ていると、「2回目で大きく落ちる」のか「6回目あたりから緩やかに落ちる」のかが分かりません。前者なら初回体験（同梱物、届くまでの日数、量）に問題があり、後者なら飽きや消費ペースのミスマッチです。打ち手がまったく違います。
解約理由の選択肢を設計しておくのも、ここで効いてきます。「価格が高い」「量が多い」「使い切れない」「品質が合わない」「一時的に不要」——このうち「量が多い」が上位なら、解約ではなく配送間隔の変更を提案する導線を足せば済みます。理由を取っていないと、この打ち手にたどり着けません。
Shopifyを事業の基盤として見るなら
定期購入を検討する段階まで来ているストアは、Shopifyを単なる「商品を売る場所」ではなく、事業の基盤として使い始めているはずです。
その視点で言うと、定期購入の導入は「コーポレートサイトとECをShopifyに統合する」という選択と地続きです。定期購入の顧客はブランドとの接点が長く続くので、会社としての姿勢や思想を伝える場所が同じドメインにあるかどうかが効いてきます。
Shopifyを企業サイトと兼用する考え方についてはShopifyをコーポレートサイトと兼用する構成の記事で詳しく整理しているので、サイト全体の設計を考えている段階なら合わせて読んでみてください。
構築費用の全体像を掴みたい場合は、こちらが参考になります。
また、Shopifyでできることの限界を先に把握しておくと、定期購入まわりの要件も現実的に書けるようになります。カスタマイズの制約についてはShopifyでできないこと｜依頼前に知るカスタマイズの限界にまとめています。
導入判断のチェックリスト
ここまでの内容を、判断に使える形に落とします。次の項目に答えられない状態なら、定期購入の導入はまだ早い段階です。
事業として
- 定期購入で売る商品は、本当に定期的に消費されるものか
- 単発で買ってくれている顧客のうち、リピートしている人はどれくらいいるか
- 定期購入で得たい成果は「売上の安定」か「LTVの向上」か「新規獲得の武器」か
設計として
- 都度配送型か、前払い一括型か
- 解約・スキップ・変更は、顧客がセルフでできるか
- 縛りと特典をどう設計するか
- カード以外の決済を受けるか
運用として
- 管理画面を定期的に見る担当者は決まっているか
- 決済失敗が出たときの連絡フローは決めたか
- 契約数が増えたときの対応時間を見積もったか
- 担当者が交代したときの引き継ぎ資料を作る予定はあるか
費用として
- アプリの月額と手数料が、目標契約数に達したときいくらになるか試算したか
- テーマ改修が必要な範囲を切り分けたか
- 運用マニュアル作成の工数を見込んだか
このうち「事業として」の3項目が埋まらないなら、定期購入より先にやるべき施策があります。リピートが起きていない商品に定期購入を付けても、契約は増えません。
よくある質問
Shopifyの定期購入はアプリなしでできますか
Shopify本体にサブスクリプションの仕組み（Subscription APIs）はありますが、それを使うにはアプリが必要です。Shopify自身が提供する「Shopify Subscriptions」を含め、何らかのアプリを入れる前提になります。アプリなしで実現しようとするとカスタム開発になり、費用と保守負担が跳ね上がるため現実的ではありません。
定期購入の導入にどれくらい期間がかかりますか
アプリを入れて標準のウィジェットを商品ページに出すだけなら短期間で動きます。一方、要件を決める段階（課金モデル、解約導線、縛りの設計）と、ウィジェットの見た目をブランドに合わせる改修、運用マニュアルの整備まで含めると、数週間から数か月の幅を見ておくのが現実的です。期間の大半は開発ではなく要件決めに使われるため、社内の意思決定が速いほど短くなります。
途中で別の定期購入アプリに乗り換えられますか
技術的には可能ですが、単発販売用のアプリを入れ替えるのとは難易度が違います。契約データはShopify側に残る一方、アプリ独自に持っている割引ルールや設定は移せないことがあり、稼働中の契約を止めずに移行するには手間がかかります。最初の選定時に、将来やりたいことまで含めて要件を書いておくことを勧めます。
コンビニ払いや代引きで定期購入はできますか
購入のたびに顧客の操作が必要な決済手段は、定期購入との相性が悪く、対応していないことがほとんどです。定期購入は基本的にクレジットカードが前提と考えてください。自社の顧客層でカード以外の決済比率が高い場合、定期購入に乗せられる顧客がそもそも限られることになるので、施策を始める前に過去の注文を決済手段別に集計して確認してください。
解約をしにくくすれば継続率は上がりますか
短期的には上がりますが、勧めません。特定商取引法や消費者契約法の観点から、解約導線を過度に分かりにくくする設計には法的なリスクがあり、行政指導や返金対応につながる可能性があります。加えて、無理に引き止めた顧客はレビューやSNSでの評判という形で跳ね返ります。解約はマイページから到達できる位置に置いたうえで、解約前に「スキップ」「配送間隔の変更」を提案するほうが、結果として継続につながります。
まとめ
Shopifyで定期購入（サブスク）を始めるときに、アプリ選びから入るのは順番が違います。先に決めるのは次の点です。
- 課金モデル（都度配送型か、前払い一括型か）——ここで必要な機能が半分決まる
- 顧客のセルフサービス範囲——運用コストを決める最大の変数
- 運用担当者——用意できないなら導入を見送る判断もある
そのうえでアプリを比較するときは、機能一覧ではなく、最終更新日・日本語対応の段階・サポート体制・自社テーマとの相性・移行のしやすさを見てください。料金は変わるものなので、必ず各アプリの公式ページで最新を確認します。
そして、アプリで足りるのは「管理画面の中で完結する話」まで。顧客が見る画面の見た目と、外部システムとの連携は制作の領域です。ここを切り分けて見積もりを取れば、金額の内訳が読めるようになります。
定期購入は、入れれば売上が安定する魔法の機能ではありません。リピートが起きている商品を、より買いやすくする仕組みです。小さく始めて、問い合わせの実測をもとに広げる。その順番を守るかどうかで、導入後の景色は大きく変わります。
