月額料金を支払うことで継続的に利用できるサブスク型Webサービスを開発するとき、
「クレジットカード決済を付ければ完成するのでは？」
と考えてしまうことがあります。
しかし、実際のサブスク型Webサービスでは、決済以外にも多くの設計が必要です。
例えば、
- 無料プランから有料プランへ変更する
- 上位プランへアップグレードする
- 月途中でダウングレードする
- クレジットカード決済に失敗する
- 契約を解約する
- 解約後も契約期間終了までは利用できるようにする
- 契約プランによって利用できる機能を変える
といった処理があります。
結論からいうと、サブスク型Webサービスを設計するときは、
「決済」「契約」「プラン」「利用権限」を分けて考えることが重要です。
決済サービスから「支払い成功」という通知を受け取っただけで、そのユーザーが現在どの機能を使えるのかまで正しく判断できるとは限りません。
この記事では、サブスク型Webサービスを開発するときに必要になる、課金・契約・プラン・権限管理・解約・支払い失敗時の処理などを具体例とともに解説します。
サブスク型Webサービスでは何を設計する必要がある？
例えば次のようなサービスを考えてみましょう。
フリープラン
月額0円
- プロジェクト3件まで
- データ保存100件まで
- AI機能なし
スタンダードプラン
月額3,000円
- プロジェクト50件まで
- データ保存10,000件まで
- AI機能利用可能
プロプラン
月額10,000円
- プロジェクト無制限
- データ保存無制限
- AI機能利用可能
- CSV一括出力
- チーム管理
一見すると、
ユーザー
↓
プランを選択
↓
カード決済
↓
利用開始
という単純な仕組みに見えます。
しかし実際には、
- 現在契約しているプラン
- 契約開始日
- 次回更新日
- 契約状態
- 支払い状態
- 解約予約
- 利用可能機能
- 使用量
- 契約変更履歴
などを管理する必要があります。
そのため、サブスクWebサービスでは「決済画面」だけでなく、契約ライフサイクル全体を設計する必要があります。
サブスク設計では「決済」と「契約」を分ける
非常に重要なのが、
「支払い情報」
と
「サービス利用契約」
を同じものとして扱わないことです。
例えば決済サービスから、
「3,000円の支払いに成功しました」
という情報を受け取ったとします。
しかし、それだけでは、
- 何のプランなのか
- いつまで利用できるのか
- 解約予定なのか
- どの機能を使えるのか
までは判断できません。
そのため、システム側では契約状態を別に管理します。
概念的には、
ユーザー
↓
契約
↓
プラン
↓
利用可能機能
という関係です。
さらに、
契約
↓
決済情報
を紐付けます。
このように分離することで、課金方式や決済サービスが変わっても、サービス側の契約ロジックを管理しやすくなります。
サブスク型Webサービスの基本データ構造
実際のWebサービスでは要件によって異なりますが、代表的には次のような情報を管理します。
users
ユーザー情報です。
例えば、
- ユーザーID
- 名前
- メールアドレス
- ログイン情報
- 登録日時
などです。
plans
料金プランを管理します。
例えば、
- plan_id
- plan_name
- 月額料金
- 利用上限
- 利用可能機能
- 有効・無効
などです。
subscriptions
契約情報です。
例えば、
- subscription_id
- user_id
- plan_id
- 契約状態
- 契約開始日
- 現在の契約期間開始日
- 現在の契約期間終了日
- 解約予定
- 解約日時
などを管理します。
payments
決済履歴です。
例えば、
- payment_id
- subscription_id
- 金額
- 決済日時
- 決済状態
- 外部決済ID
などです。
システムによっては、
- invoices
- usage_records
- subscription_history
- plan_features
などを追加します。
重要なのは、ユーザーテーブルに、
plan = “premium”
だけを持たせて終わらせないことです。
サービスが成長すると、契約変更や解約履歴などを扱う必要が出てきます。
サブスク設計で重要な「契約状態」
サブスクリプションには複数の状態があります。
例えば、
- 無料利用中
- トライアル中
- 契約中
- 支払い待ち
- 支払い失敗
- 解約予約
- 解約済み
- 利用停止
などです。
単純に、
有料ユーザー：true / false
だけでは対応できないことがあります。
例えば、
「解約ボタンを押したが、今月末までは利用可能」
という状態があります。
このユーザーは、
解約済み
ではなく、
解約予約中
＋
契約期間終了までは利用可能
と考える必要があります。
そのため、契約状態を明確に定義することが重要です。
契約状態をステートマシンとして考える
サブスクサービスでは、状態遷移を整理すると設計しやすくなります。
例えば、
無料ユーザー
↓
有料プラン申込
↓
決済成功
↓
契約中
↓
解約申請
↓
解約予約
↓
契約期間終了
↓
解約済み
という流れです。
支払い失敗が発生する場合は、
契約中
↓
更新決済失敗
↓
支払い失敗
↓
再決済成功
↓
契約中
または、
支払い失敗
↓
一定期間経過
↓
利用停止
という状態遷移もあります。
このように契約状態を最初に整理しておくと、実装時の条件分岐を減らしやすくなります。
サブスク設計のポイント1．料金プランを整理する
最初に料金プランを整理します。
例えば、
| 項目 | Free | Standard | Pro |
|---|---|---|---|
| 月額料金 | 0円 | 3,000円 | 10,000円 |
| プロジェクト数 | 3 | 50 | 無制限 |
| メンバー数 | 1 | 5 | 30 |
| AI機能 | × | ○ | ○ |
| CSV出力 | × | × | ○ |
| API | × | × | ○ |
この段階で重要なのは、単に料金を決めることではありません。
「何が違うのか」をシステム上の条件として定義する必要があります。
例えば、
Standard
→ AI利用可能
Pro
→ AI利用可能
→ CSV出力可能
→ API利用可能
という形です。
サブスク設計のポイント2．プランと権限を直接結び付けすぎない
小規模サービスでは、
if plan == “pro”:
CSV出力可能
というような設計でも動きます。
しかしプランが増えると条件分岐が大量になります。
例えば、
- Free
- Standard
- Pro
- Enterprise
- 旧Standard
- キャンペーン限定プラン
などが増える可能性があります。
そこで、
プラン
↓
利用可能機能
という形で管理すると拡張しやすくなります。
例えば、
AI機能
Free：利用不可
Standard：利用可能
Pro：利用可能
CSV出力
Free：利用不可
Standard：利用不可
Pro：利用可能
API
Free：利用不可
Standard：利用不可
Pro：利用可能
という形です。
料金プランと機能権限を分離しておけば、将来的なプラン変更にも対応しやすくなります。
サブスク設計のポイント3．プラン変更を設計する
サブスクサービスでは、契約後のプラン変更が発生します。
例えば、
Standard
↓
Pro
へのアップグレードです。
逆に、
Pro
↓
Standard
へのダウングレードもあります。
ここで決めなければならないのが、
「いつから新プランを適用するか」
です。
即時変更
アップグレードした瞬間からPro機能を利用可能にします。
次回更新時変更
現在の契約期間終了後に新しいプランへ切り替えます。
サービスによっては、
アップグレード
→ 即時
ダウングレード
→ 次回更新時
とすることもあります。
これらのルールを仕様として決めておかないと、実装時に判断できません。
サブスク設計のポイント4．日割り計算をどうするか決める
月途中でプラン変更する場合には、日割り計算を行うかどうかも決めます。
例えば、
Standard：月額3,000円
から、
Pro：月額10,000円
へ月の途中で変更した場合です。
方法としては、
- 差額を日割り請求する
- 即時10,000円を請求する
- 次回請求から10,000円にする
などがあります。
どの方法が正しいというものではありません。
サービスの料金体系と利用者への分かりやすさを考えて決めます。
ただし、後から変更すると契約管理や請求処理への影響が大きいため、開発前に整理しておきたい項目です。
サブスク設計のポイント5．解約処理を設計する
解約も重要な設計ポイントです。
例えばユーザーが7月15日に解約したとします。
即時解約
7月15日から利用できなくする。
契約期間終了時解約
7月31日までは利用でき、8月1日から利用不可にする。
多くのサービスでは、支払い済み期間までは利用可能にする設計があります。
この場合、
解約ボタンを押した
＝
即座に利用不可
ではありません。
システムでは、
契約状態：active
解約予約：true
利用終了日：2026-07-31
のように状態を保持する考え方があります。
解約時にはデータをどうするかも決める
サブスクWebサービスでは、解約後のデータ処理も重要です。
例えば、
- 即時削除する
- 30日間保存する
- 90日間保存する
- 無料プランへ移行する
- 閲覧専用にする
などがあります。
例えばプロジェクト管理SaaSで、
Proプラン
↓
解約
↓
Freeプラン
になった場合、
Proで100件作成していたプロジェクトをどう扱うか
という問題があります。
Freeプランの上限が3件だからといって、97件を自動削除するのは適切でない可能性があります。
例えば、
既存データは閲覧可能
＋
新規作成不可
という方法があります。
料金プラン変更時には、データの扱いまで設計することが重要です。
サブスク設計のポイント6．支払い失敗時の処理を考える
クレジットカード決済では、毎回必ず成功するとは限りません。
例えば、
- カードの有効期限切れ
- 利用限度額
- カード停止
- 認証エラー
などによって決済に失敗することがあります。
ここで、
支払い失敗
↓
即時アカウント停止
としてしまうと、ユーザー体験が悪くなる可能性があります。
そこで、
更新決済失敗
↓
ユーザーへ通知
↓
一定期間は利用可能
↓
再決済
↓
成功なら契約継続
↓
失敗が継続したら利用停止
という猶予期間を設ける方法があります。
この猶予期間を「グレースピリオド」と呼ぶことがあります。
決済失敗時に決めておきたい項目
例えば次のような項目です。
- 何回再決済するか
- 何日間猶予するか
- いつユーザーへ通知するか
- いつサービスを停止するか
- 支払い成功後に自動復旧するか
こうした処理は、決済サービス任せではなく、自社サービス側の利用ルールとしても整理しておく必要があります。
サブスク設計のポイント7．Webhookを考慮する
外部の決済サービスを利用する場合、Webhookを利用して決済結果などを受け取る構成がよく使われます。
例えば、
ユーザー
↓
決済サービスで契約
決済サービス
↓
Webhook
自社Webサービス
↓
契約状態更新
という流れです。
Webhookによって、
- 初回決済成功
- 更新成功
- 決済失敗
- サブスクリプション変更
- 契約終了
などのイベントを受け取り、自社データを更新します。
ここで注意したいのが、
フロントエンドの「決済完了画面が表示された」ことだけを根拠に契約を有効化しない
ことです。
決済結果は、サーバー側で信頼できる情報を確認して処理する必要があります。
Webhookでは二重処理も考える
Webhookは同じイベントが複数回送信される可能性も考慮して設計します。
例えば同じ決済成功通知を2回処理すると、
利用期間が2か月延びる
などの不具合につながる可能性があります。
そのため、
イベントID
↓
すでに処理済みか確認
↓
未処理なら実行
というように、同じ処理を複数回実行しても結果が壊れない「冪等性」を考慮することが重要です。
サブスク設計のポイント8．利用量による制限を設計する
サブスクでは「機能を使える・使えない」だけではなく、利用量による制限もあります。
例えば、
Free
月10回までAI利用可能
Standard
月500回まで
Pro
月5,000回まで
という料金体系です。
この場合、
ユーザー
↓
AI実行
↓
今月の利用量を確認
↓
上限未満なら実行
↓
使用量を記録
という処理が必要です。
管理する情報として、
- 利用回数
- API使用量
- ストレージ容量
- 登録件数
- メンバー数
などがあります。
「月間利用量」のリセット方法も決める
例えばAI利用回数を、
毎月1日にリセット
するのか、
契約更新日ごとにリセット
するのかによって処理が変わります。
ユーザーA：
契約日 7月1日
ユーザーB：
契約日 7月20日
の場合、
暦月単位なのか契約期間単位なのかを決める必要があります。
こうした細かな仕様が、後から課金トラブルにつながりやすい部分です。
サブスク設計のポイント9．個人契約と法人契約を分けて考える
BtoB SaaSでは、
「ユーザー本人が契約する」
とは限りません。
例えば、
株式会社A
↓
Proプラン契約
↓
社員20名が利用
という構造があります。
この場合、
ユーザー
→ 契約
ではなく、
組織
→ 契約
→ 複数ユーザー
という設計が必要です。
例えば、
organizations
organization_members
subscriptions
などを分けます。
法人向けSaaSでは権限設計も重要
同じ契約内でも、
オーナー
- 契約変更
- 支払い管理
- メンバー管理
管理者
- メンバー管理
- システム設定
一般メンバー
- 通常機能の利用
というように権限が異なる場合があります。
ここでは、
料金プランによる機能制限
と、
組織内のRBACによる権限管理
を分けて考える必要があります。
例えばProプランだからAPI機能を使えるとしても、一般メンバーまでAPIキーを発行できる必要はないかもしれません。
サブスク設計のポイント10．料金変更に耐えられるようにする
サービスを長期間運営すると、料金改定が起こる可能性があります。
例えば、
旧Standard
月額3,000円
新Standard
月額4,000円
となった場合です。
既存ユーザーには3,000円を継続し、新規ユーザーだけ4,000円にすることもあります。
そのため、
plan = standard
だけで価格を決めていると対応しにくくなります。
料金体系によっては、
- プラン
- 価格
- 適用開始日
- 適用対象
を分離して管理する設計が有効です。
サブスク型Webサービスの代表的な画面
実際にサービスを開発する場合、例えば次の画面が必要になります。
ユーザー向け
- 料金プラン一覧
- プラン選択
- 決済
- 契約状況
- 支払い方法変更
- プラン変更
- 解約確認
- 請求履歴
管理者向け
- ユーザー一覧
- 契約一覧
- 契約詳細
- 決済状態
- プラン管理
- 利用量確認
- 解約状況
- 支払いエラー確認
実際の運用では、ユーザー向け機能だけでなく管理者向け機能も重要です。
管理画面を後回しにすると運用が大変になる
開発初期では、
「ユーザーが契約できればよい」
と考えがちです。
しかし運営開始後には、
「このユーザーはなぜ利用できない？」
「決済は成功している？」
「どのプランを契約している？」
「いつ解約した？」
といった問い合わせが発生します。
管理画面で、
- 契約状態
- 決済履歴
- プラン変更履歴
- エラー
- Webhook処理状況
などを確認できると、運用負荷を下げやすくなります。
【チェックリスト】サブスクWebサービスの要件整理
サブスク型Webサービスを開発する前に、次の項目を整理してみてください。
料金プラン
- プランはいくつあるか
- 月額か年額か
- 無料プランはあるか
- 無料トライアルはあるか
- プランごとの機能差は何か
- 利用上限はあるか
契約
- 契約開始日はいつか
- 契約更新日はいつか
- 自動更新か
- 解約は即時か期間終了時か
- 再契約できるか
プラン変更
- アップグレードは即時か
- ダウングレードはいつ反映するか
- 日割り計算するか
- プラン変更時の既存データをどうするか
決済
- 支払い方法は何か
- 決済失敗時はどうするか
- 再決済するか
- 猶予期間はあるか
- 請求履歴を表示するか
権限
- プランによる機能制限は何か
- 管理者と一般ユーザーを分けるか
- 法人契約に対応するか
- 複数メンバーを招待できるか
解約
- 解約予約を受け付けるか
- 解約後のデータ保持期間は何日か
- 無料プランへ戻すか
- データを削除するか
運用
- 管理者が契約状態を確認できるか
- 手動で契約を変更できるか
- 決済エラーを確認できるか
- 操作履歴を残すか
この段階まで整理すると、必要なデータ構造や画面がかなり明確になります。
サブスクWebサービスでよくある設計ミス
1．ユーザーテーブルにプラン名だけ保存する
例えば、
users.plan = “pro”
だけで管理する方法です。
小規模な試作では使えますが、
- プラン変更
- 解約
- 契約期限
- 支払い失敗
- 契約履歴
などが増えると管理しにくくなります。
契約情報を独立させることを検討しましょう。
2．決済成功と利用権限を同じものとして扱う
決済成功は、サービス利用条件の一部です。
実際には、
- 契約状態
- 利用期間
- プラン
- 権限
なども確認して利用可否を判断します。
3．支払い失敗を考えていない
正常系だけ作ると、カード決済エラー発生時に運用で対応することになります。
サブスクは毎月処理が発生するため、失敗時のフローまで設計しておく必要があります。
4．解約後のデータ処理を決めていない
サービス開始後に、
「解約したユーザーのデータをいつ削除する？」
という問題が発生しやすい部分です。
利用規約や運用方針とも合わせて事前に決めておきます。
5．Webhookの処理失敗を確認できない
決済サービスから通知が来ても、自社システム側の処理が失敗する可能性があります。
そのため、
- エラーログ
- 再処理
- 処理済みイベント管理
などを検討する必要があります。
6．プラン制限をフロントエンドだけで行う
例えばProユーザーだけ利用できるAPI機能について、
画面上のボタンを非表示にするだけ
では十分ではありません。
ユーザーが直接APIを呼び出せる可能性があります。
そのため、バックエンド側でも契約状態や利用権限を確認する必要があります。
サブスク型Webサービスに関するよくある質問
サブスク型Webサービスを作るには決済システムが必須ですか？
有料サブスクをオンラインで自動課金する場合は、何らかの決済手段が必要です。
ただし法人向けサービスでは、請求書払いなどを組み合わせる場合もあります。
サービスの顧客層や料金体系に合わせて決めます。
Stripeなどの決済サービスを使えば契約管理もすべて任せられますか？
決済・請求関連の多くを任せられるサービスはありますが、自社Webサービス上の利用権限や業務ルールまで完全に同じものとして扱えるとは限りません。
決済側の状態と自社サービス側の契約状態をどのように同期するか設計することが重要です。
サブスクのプラン変更は難しいですか？
プラン変更そのものより、
- いつ変更するか
- 差額をどう扱うか
- 利用上限をどう変えるか
- 既存データをどう扱うか
といった業務ルールの整理が重要です。
無料トライアルはどう設計しますか？
例えば、
trial_start_at
trial_end_at
などを管理し、期間中だけ有料機能を利用可能にする方法があります。
トライアル終了後に自動課金するのか、ユーザー自身に契約してもらうのかも決める必要があります。
サブスクを解約したらデータはすぐ削除するべきですか？
サービス方針によります。
一定期間保存して再契約時に復元できるようにする方法や、無料プランへ移行する方法もあります。
個人情報や契約条件も関係するため、データ保持ポリシーとして整理しておくことが重要です。
BtoB SaaSでも同じ設計ですか？
基本的な契約管理の考え方は共通しますが、法人向けでは、
- 組織契約
- 複数ユーザー
- 管理者権限
- 請求書払い
- 個別料金
- 契約席数
などが追加されることがあります。
個人向けサービスより契約モデルが複雑になりやすいため、最初にデータ構造を整理することが重要です。
hiro-dev-labではサブスク型Webサービスの要件整理から相談できます
サブスク型Webサービスを開発するとき、
「Stripeなどの決済サービスを導入する」
ことだけを決めても、システム全体の仕様は決まりません。
実際には、
契約
↓
決済
↓
プラン
↓
利用権限
↓
更新
↓
プラン変更
↓
解約
↓
データ保持
までを一つの流れとして整理する必要があります。
hiro-dev-labでは、Webシステム開発の観点から、
- サービス内容のヒアリング
- 要求整理
- 要件定義
- 料金プラン整理
- 契約フロー設計
- 決済連携設計
- プラン・権限設計
- データベース設計
- Webhook設計
- 管理画面設計
- 認証・権限管理
- Webサービス開発
など、必要な段階から相談できます。
例えば、
「月額課金のWebサービスを作りたいが、どんな機能が必要か分からない」
「決済機能だけでなく、プラン変更や解約まで設計したい」
「法人向けSaaSとして複数ユーザー契約に対応したい」
といった段階でも、サービスの料金体系と利用方法を整理することで必要なシステム構成が見えてきます。
サブスク型Webサービスでは、決済機能そのものよりも、契約状態と利用権限を一貫して管理できる仕組みを設計することが重要です。