この記事は2026年4月13日に書いておる。たった半年前、バイブコーディングはまだ説明が必要じゃった
この記事は 2026年4月13日 に書いておる。
ほんの半年前なら、「バイブコーディング」と言っても、たぶん多くの人が「それ何？」という顔をしとったはずじゃ。
AIに話しかけながらアプリを組む。
画面を作る。
ログインを通す。
DBにつなぐ。
それを、ゴリゴリ実装できる人だけの話ではなく、個人開発者やひとり社長でも普通に触れる。
そんな空気は、まだ今ほど強くなかった。
じゃが今はどうじゃ。
「Claude Code すごいよな」
「これ、もう1人でアプリ作れるな」
「昨日まで無かったものが、今日もう触れる」
そんな会話が、かなり自然に出るようになった。
実際、ここ半年でアプリを形にする速度は一気に変わった。
雑に要件を話すだけで、LPのたたき台が出る。管理画面が出る。ログイン画面が出る。小さなSaaSや社内ツールなら、「まず形にして触る」まで一気に走れる。
前なら数週間かけていた最初の試作が、今は数時間、下手すると数十分で出てくる。
あっという間にアプリを作れる時代 が、ほんとうに来たんじゃよ。
作る速度が上がった今こそ、「どう売るか」「どう継続課金に変えるか」が次の勝負どころになる。
じゃが、その次で急に止まる人が多い。
アプリ本体は作れた。ログインもできる。画面も整った。便利ツールや小さなSaaSなら、もう形にできる。実際、note のような買い切り販売なら、なんとか売れるところまで持っていける。
でも、ここから景色が変わるんじゃ。
「本当は月額で出したい」
「毎月ちゃんと使ってくれる人から、継続的に売上が立つ形にしたい」
「でも支払いが止まった時に、利用権限までちゃんと止める仕組みがわからん」
「Webhook とか Supabase とか出てきた瞬間に、急に“開発者の世界”に戻される感じがする」
ここで心が止まるのは自然じゃ。
アプリを作る能力がないのではない。売り方を変えるための裏側の設計だけ、急に別の筋肉を使うからなんじゃよ。
しかもバイブコーディングでアプリを育ててきた人ほど、ここで独特の不安が出やすい。
「フロントは見える。けど、裏側は見えん」
「コードはAIが書いてくれる。けど、本当にこれで金を扱って大丈夫なんか？」
「買い切り販売はなんとなく回せた。じゃが月額になると、止める責任まで発生する」
このへんで急に、楽しさより怖さが勝ちやすいんじゃ。
じゃがのう。ここは越えられる。
しかも、思っているより“巨大なバックエンド工事”をしなくても越えられるんじゃよ。
この記事では、その怖さをほどきながら、Stripe + Supabase でサブスク課金システムを作る全体像を、初心者向けにまとめる。
主役は「難しいサーバー構築」ではない。
主役は、課金状態と利用権限をズレずにつなぐ最小構成じゃ。
サブスク化すると、アプリ側にも「契約が続いている前提」の画面設計が生まれる。売って終わりではなく、使い続けてもらう導線が必要になる。
サブスク化できると、売って終わりの販売から抜け出せる
最初に、ここをしっかり共有しておきたい。
サブスク課金システムを作る意味は、「月額決済ができるようになる」だけではない。
アプリの売り方そのものが変わるんじゃ。
買い切り販売は、始めやすい。商品を1つ作って、販売ページを置いて、1回払ってもらったら終わり。構造が単純じゃから、最初の販売手段としてかなり優秀じゃ。
じゃが、買い切り販売には、どうしても次の特徴がある。
- 売上が毎回ゼロから積み上がる
- 新規販売が止まると売上も止まる
- アップデートや保守を続けても、収益が直結しにくい
- 既存ユーザーに対して、継続的な価値提供と収益化を結びつけにくい
ここでサブスク化できるようになると、見える未来が一段変わるんじゃよ。
- 継続利用が継続収益につながる
- 機能改善が売上に返ってきやすい
- 無料体験や低価格プランから入り口を広げやすい
- 「とりあえず使ってみる」の心理的ハードルを下げやすい
- ユーザーとの関係を、単発購入ではなく継続利用として育てやすい
ここがかなり大きい。
買い切り販売だと、「売れたか、売れないか」で終わりやすい。
サブスク販売だと、「今月どう使われたか」「継続してもらえる価値は何か」「どこを改善すると離脱が減るか」という視点が自然に入ってくる。
つまりサブスク課金システムは、単なる決済の部品ではない。
アプリを“育てる前提”の商売に変える土台
なんじゃ。
ここを持てるかどうかで、個人開発の息の長さが変わる。
お主がもし「せっかく作ったアプリを、単発販売で終わらせたくない」と感じているなら、その感覚はかなり正しいぞい。
サブスク化は理想論だけでは続かん。固定費の軽さと、売れてから費用が乗る構造まで見えていると一歩踏み出しやすい。
AI代を除けば、固定費ほぼ0円で開発開始はできる
ここは希望が持てるポイントじゃ。
2026年4月12日時点で公式情報を確認した限り、AI利用料を除けば、サブスク課金システムの開発開始そのものは固定費ほぼ0円で始めやすい。
大枠はこうじゃ。
Supabaseには Free Plan があるStripeは初期費用や月額固定費なしで開始できるStripe Billingは従量課金で、売れてから手数料が発生する- フロントの公開先も無料枠から始めやすい
たとえば Supabase の公式ドキュメントでは、Free Plan として無料プロジェクトで始められることが案内されておる。Stripe 側も、少なくとも日本向け料金ページでは初期費用や月額固定費を前提にした書き方ではなく、決済成功ごとの手数料が示されておる。
ここで大事なのは、“無料で売り続けられる” と “固定費なしで始められる” は別の話 だと理解することじゃ。
売上が出たら、もちろん Stripe の決済手数料はかかる。日本向け料金ページでは、2026年4月12日時点の案内で国内カードの成功取引1件あたり 3.6% と記載がある。さらにサブスク管理に Stripe Billing を使うなら、Billing取引額に対して 0.7% の料金も案内されておる。
つまり、売れた後にはコストが発生する。
じゃが、これはむしろ健全じゃ。
最初から毎月重い固定費が積み上がる構造ではなく、まず作って、まず売って、その後に比例して払う という形だからこそ、個人開発で試しやすいんじゃよ。
この感覚は大事じゃ。
「サブスク課金システムなんて、お金のある会社が組むもの」
そう思っておるなら、その思い込みはかなり薄くしてよい。
AI代さえ別で見ておけば、技術的な入口は思っているより低いんじゃ。
Stripe の料金ページ。初期固定費よりも、決済や請求に応じた従量の考え方が中心じゃと確認できる。
Supabase 側も、まずは無料枠から試しやすい。読者に「法人インフラを最初から抱え込まなくてよい」と伝える補助になる。
サブスク課金システムを作るのに必要なツール一覧
ここで一度、必要な道具を整理しよう。
お主が今から標準ルートで進むなら、まず必要なのは次の5つじゃ。
1. AI開発環境
Codex、Claude Code、Cursor のように、コード生成や修正を進める環境じゃ。
ここは、お主がすでに一番回しやすいものを使えばよい。大事なのは「どのAIを使うか」より、「再生成・修正・比較を繰り返せること」じゃ。
課金まわりでは、最初の一発で正解が出ることは少ない。
だからこそ、何度も出し直して育てられる環境のほうが強い。
2. Git管理
GitHub のようなリポジトリ管理じゃ。
これは軽視してはいかん。課金まわりは、見た目の崩れではなく「状態管理の崩れ」が怖い。変更前後の差分を追えないまま進めると、どこで壊れたか見えなくなる。
バイブコーディングでは特に、「AIが直したはずなのに別の所が変わっていた」が起きる。だから Git は保険ではなく、ほぼ必須装備じゃよ。
GitHub は派手な機能を全部覚える必要はない。まずは差分が残ること、戻れること、この2つの価値が大きい。
3. Stripe
これは決済と契約の専門家じゃ。
具体的には、
- カード決済
- 月額請求
- 請求失敗の検知
- カスタマーポータル
- 解約導線
- 請求履歴
このへんを担当してくれる。
自前でカード情報を持たずに済む、というだけでも大きい。お主が本当に作りたいのはアプリ本体であって、決済代行会社になることではないからのう。
Stripe のトップページ。決済だけでなく、Billing や Checkout まで含めて課金基盤を任せる前提が見えやすい。
この記事では、Stripe の中でも Billing を使って月額の契約管理を扱う、という位置づけで進める。
4. Supabase
これはアプリ側のデータ置き場であり、今回の記事では利用権限台帳の置き場じゃ。
後で詳しく説明するが、Stripe が「お金と契約の正本」を持ち、Supabase が「アプリで今この人を使わせてよいか」を見る台帳を持つ。
この分担にすると、頭の中がかなり整理しやすい。
Supabase は「巨大なバックエンド製品」ではなく、まずはアプリ側の台帳を置くDBと捉えると一気にわかりやすくなる。
5. デプロイ先
アプリを公開する場所じゃ。
無料枠で始めるなら Cloudflare Pages などが候補になりやすい。最初の公開先としてはかなり軽く、フロントを置いて試すには相性がよい。細かな上限や運用条件は後で見直せばよく、最初は「まず公開して、課金導線を通す」ことを優先すれば十分じゃ。
つまり、最初に必要なのは「大規模なインフラ」ではない。
AI開発環境、Git、Stripe、Supabase、デプロイ先
この5点があれば、かなり戦える。
逆に言えば、これ以上の道具を最初から増やしすぎると、読者は途中で迷子になりやすいぞい。
公開先も、最初は Cloudflare Pages のように軽く始められるものが相性よい。アプリ本体・DB・決済の三点セットを小さく通す感覚が大事じゃ。
この5つを、どう連携させるのか
ここまでで道具はそろった。
じゃが、読者が次に迷いやすいのは「で、これらはどうつながるんじゃ？」という部分じゃろう。
ここを先に一本の流れで見ておくと、その後の Stripe 画面や Webhook の説明がかなり入りやすくなる。
役割を一言で分けると、こうじゃ。
AI開発環境は作るGitHubは変更履歴を残すCloudflare Pagesはアプリを公開するStripeはお金と契約の正本を持つSupabaseはアプリ側の利用権限台帳を持つ
実際の流れは、次のようになる。
AI開発環境で、アプリ本体と課金まわりのコードの下書きを作る- できたものを
GitHubに置き、差分が追える状態にする - フロント側のアプリを
Cloudflare Pagesに公開する - ユーザーがアプリ内でプランを選び、支払い開始ボタンを押す
- アプリが
Stripe Checkoutを呼び出し、支払い画面へ渡す - 支払い結果を
StripeがWebhookで知らせる - その通知を受けた処理が、
Supabaseのsubscriptions台帳を更新する - アプリはその台帳を見て、「今この人を使わせてよいか」を判定する
見た目の入口はアプリじゃが、実際の支払い画面は Stripe Checkout に渡す。この受け渡しが連携の分かれ目じゃ。
つまり、見た目の入口はアプリじゃが、契約の正本は Stripe にある。
そして、日々の利用可否を判断するためのアプリ側の写しを Supabase に持つわけじゃ。
この分担にすると、頭の中がかなり整理しやすい。
「お金の正本はどこにあるんか」
「利用権限はどこで見るんか」
「どのタイミングで状態が書き換わるんか」
この3つが分かれるからじゃ。
読者がここで持つべき感覚は、全部を1か所でやろうとしない ことじゃよ。
決済は決済の専門家に任せる。
公開は公開の場所に任せる。
アプリ側は「今使っていい人か」を見る。
この整理ができると、サブスク課金システムは急に現実的になる。
5つの道具を別々に覚えるより、「誰が正本を持ち、誰が利用可否を決めるか」で見ると流れが一気につながる。
Stripeアカウント開設で、最初にどこを触るのか
ここは、読者が実際に手を動かしやすいように、かなり実務寄りで書いておく。
「Stripeを使う」と言われても、最初はどの画面を見ればよいかわからんからのう。
やることは大きく3段階じゃ。
- アカウントを作る
- ダッシュボードの基本の場所を把握する
- 商品・価格・開発者設定を見る
アカウント作成で最初に意識すること
Stripe のアカウント作成自体は身構えるほど重くない。メールアドレス、事業情報、受け取り用の銀行情報など、一般的な決済サービスとして必要な項目を埋めていく流れじゃ。
この時点で大事なのは、「いきなり全部を理解しよう」とせんことじゃ。
最初に必要なのは、商品を作る場所と、開発用のキーを見る場所だけ把握すること なんじゃ。
最初に覚える画面は3つだけでよい
ダッシュボードに入ると、情報が多く見える。ここで閉じたくなるんじゃよな。
じゃが、最初は3か所だけ見れば十分じゃ。
- 商品と価格を作る場所
- 開発者向けのAPIキーを見る場所
- Webhook関連の設定を見る場所
売上分析や細かい請求書設定、税務設定、支払い方法の拡張などは、最初から全部追わんでよい。
読者がまず作りたいのは、サブスク課金システムの最小構成じゃ。
そこに必要な画面だけ見ればよい。
Checkout は「自前で決済画面をがんばって作る」のではなく、Stripe 側へ安全に渡すための標準ルートとして理解するとよい。
商品と価格を作る時の考え方
ここで作るのは、「何をいくらで売るか」という販売ルールじゃ。
たとえば、
- 月額980円のライトプラン
- 月額2980円のプロプラン
- 年額29800円の年額プラン
こういう形で Stripe に登録する。
この時に大事なのは、価格の見せ方よりも「アプリ側で識別しやすい名前にすること」じゃ。
後でAIにコードを書かせる時、price_xxx をただ貼るだけでは読みにくい。だから最初から、自分の頭の中では ライト月額 プロ月額 のように意味が見える状態で整理しておくとよい。
APIキーとWebhook設定は“怖がらなくてよい”
ここで急に「秘密鍵」「署名」「Webhookシークレット」と出てきて、心が止まりやすい。
じゃが、やっていることはシンプルじゃ。
- APIキー: アプリが Stripe に話しかけるための鍵
- Webhookシークレット: Stripe から来た通知が本物かどうか確かめるための鍵
この2つを後で .env に入れる。難しい魔法ではなく、単に「誰と誰が話しているかを確かめるための合言葉」と思えばよい。
ここは実際のスクリーンショットがあるとかなり安心感が出る節じゃ。本文でも後で画像を入れたいところじゃな。
Supabaseアカウント開設で、最初に見るべき画面
Stripe と並んで、読者がもう1つ止まりやすいのが Supabase じゃ。
ここも最初に全部理解する必要はない。
むしろ、最初に見る画面を絞ったほうが安心して進める。
覚えるべきなのは、まず4か所じゃ。
- プロジェクト作成画面
- Table Editor
- SQL Editor
- Project Settings の API / URL まわり
Supabase はDBまわりの導線がはっきりしておる。読者にはまず Table Editor と SQL Editor の2点だけ覚えてもらえば十分じゃ。
プロジェクト作成で必要なのは「DBを1つ用意する」感覚だけ
Supabase に登録すると、「データベース」「認証」「ストレージ」「Edge Functions」など、いろいろ見えてくる。ここでまた閉じたくなる人が多い。
じゃが、今回の最小構成で最初に必要なのは、アプリ側の台帳を置くDBが1つあることだけじゃ。
だからこの段階では、
- プロジェクトを作る
- リージョンを選ぶ
- DBパスワードを控える
このくらいで十分じゃ。
ストレージをどうする、関数をどうする、細かいRLSをどうする、という話は、最初から全部まとめて背負わなくてよい。
最初に開くのは Table Editor と SQL Editor
読者にとって一番大事なのは、「ここで表を作るんじゃな」と理解することじゃ。
Table Editor は、表を見たり確認したりする場所。
SQL Editor は、AIが作った CREATE TABLE 文を貼ったり、必要な修正を入れたりする場所。
バイブコーディングとの相性で言えば、最初は SQL Editor がかなり強い。
なぜなら、AIに「このテーブルを作るSQLを書いて」と頼んで、そのまま持ってきやすいからじゃ。
逆にGUIで全部ぽちぽち作ろうとすると、途中で「どこを変えたか」が見えにくくなることもある。
後で必要になるのは URL と鍵
Project Settings 側では、後でアプリから Supabase に接続するための URL や鍵を見ることになる。
ここも Stripe と同じで、「難しい設定」ではなく、「アプリがどのDBに話しかけるかを決める住所と合言葉」と思えば十分じゃよ。
読者が最初に怖がるのは自然じゃが、やっていることはそこまで異質ではない。
Stripe も Supabase も、アプリが外部サービスと話すための接続先を設定しているだけなんじゃ。
認証や接続設定も、後から必要になった時に場所がわかれば十分じゃ。最初から全部理解しようとせんでよい。
バイブコーディングで最初にAIへ投げる導入プロンプト
ここもかなり重要じゃ。
バイブコーディングで失敗しやすい理由の1つは、AIに投げる最初の指示が広すぎることなんじゃ。
たとえば、
「Stripeでサブスク課金機能を作って」
これでは広すぎる。AIはそれっぽいコードを返すかもしれん。じゃが、読者が欲しいのは“それっぽい課金画面”ではなく、支払い状態と利用権限がズレない構成じゃ。
だから最初のプロンプトは、次のように範囲を絞るのがよい。
Next.js と Supabase を使っている既存アプリに、Stripe のサブスク課金を追加したい。
目的:
- 月額プランを1つ販売したい
- 支払い成功で有料機能を開放したい
- 支払い失敗や解約で利用権限を止めたい
前提:
- 認証は既にある
- アプリ側のDBは Supabase を使う
- Stripe Checkout と Stripe Customer Portal を使いたい
やってほしいこと:
1. Supabase に必要な users / subscriptions のテーブル設計案
2. Stripe Checkout を開始する API Route
3. Stripe Webhook を受けて subscriptions を更新する処理
4. subscriptions の status を見て有料機能を開閉する方針
まずは全体設計と実装順を出して。
AIに最初に頼む粒度としては、このくらいの「表をどう作るか」から始めると崩れにくい。
このプロンプトのよいところは、AIに“完成品を丸投げ”していないところじゃ。
最初に欲しいのは、構造と順番なんじゃよ。
さらに、実装の途中では次のように細かく分けて投げると強い。
Supabase の subscriptions テーブルを設計したい。
最低限必要なカラムを提案して。
要件:
- user_id で users と紐づく
- stripe_customer_id を保持する
- plan を保持する
- status を active / past_due / canceled / unpaid で扱いたい
- current_period_end を保持したい
SQL の CREATE TABLE 文と、各カラムの役割説明もつけて。Stripe Checkout を開始する Next.js API Route を書いて。
要件:
- ログイン中ユーザーの user_id を使う
- users テーブルの stripe_customer_id がなければ作成する
- price_id は環境変数から読む
- 成功後は /billing/success に戻す
- キャンセル後は /billing に戻すStripe Webhook を受けて Supabase の subscriptions テーブルを更新するコードを書いて。
扱うイベント:
- checkout.session.completed
- invoice.paid
- invoice.payment_failed
- customer.subscription.deleted
要件:
- 署名検証を入れる
- event id を保存して重複処理を防ぐ
- status と current_period_end を更新するこうやって小さく切ると、AIの出力はかなり安定する。
AIを回す時ほど、指示を小さく切って差分で追える環境が効いてくる。ここでも Git 的な見通しの良さは強い。
バイブコーディングのコツは、AIに万能の完成品を期待することではない。
責任のある境界を人間が先に言葉にし、実装の速度をAIに稼がせること
なんじゃよ。
利用権限台帳の実物イメージ。最初はこの列だけでよい
ここで、読者がいちばん安心しやすい形まで落としておこう。
subscriptions と言われても抽象的じゃ。だから、最初は「こんな列がある表を1枚作る」と思えばよい。
最小構成なら、たとえばこうじゃ。
| 列名 | 役割 |
|---|---|
id | 行を一意に識別するID |
user_id | 自分のアプリのユーザーID |
stripe_customer_id | Stripe上の顧客ID |
stripe_subscription_id | Stripe上のサブスク契約ID |
plan | どのプランか |
status | active past_due canceled unpaid など |
current_period_end | 今回の利用期限 |
created_at | 作成日時 |
updated_at | 更新日時 |
これを見ると、「意外と少ないな」と感じるはずじゃ。
実際、最初はこのくらいで十分なんじゃよ。
読者が最初にハマりやすいのは、「将来必要になりそうなもの」を最初から全部入れたくなることじゃ。
- 請求書番号
- 領収書URL
- 返金履歴
- 割引クーポン
- 利用ログ
- アフィリエイト流入
こういうものは、必要になった時に後から足せる。
じゃが、「今この人を使わせてよいか」を判定するために必要な情報は意外と少ない。
ここを削ぎ落として考えるのが、最小構成のコツじゃ。
AIにテーブル設計を頼む時も、「余計な列を増やさず、まずは利用権限台帳として成立する最小構成を出して」と添えると、かなりよい結果になりやすい。
Stripe 側でも、サブスクは「継続支払いのライフサイクル」として扱われる。台帳設計と合わせて見ると理解しやすい。
まず全体像。サブスク課金システムは何でできているのか
Supabase や Webhook が怖く見えるのは、部品を先に見てしまうからじゃ。
先に全体像をつかもう。
サブスク課金システムは、実は次の4つでできておる。
- 申し込みを受ける場所
- お金を処理する場所
- 契約状態を持つ場所
- 利用可否を判定する場所
今回の記事の標準ルートに当てはめると、こうなる。
- 申し込みを受ける場所: お主のアプリ
- お金を処理する場所:
Stripe - 契約状態を持つ場所:
Supabase - 利用可否を判定する場所: お主のアプリ
これだけ見ると、案外シンプルじゃろ。
ここで大事なのは、どこか1か所に全部やらせようとしないことじゃ。
Stripe に全部やらせようとすると、アプリ側の権限制御が見えなくなる。
Supabase に全部やらせようとすると、請求や決済ロジックまで背負うことになる。
アプリ本体に全部やらせようとすると、今度は決済の責任が重くなりすぎる。
だから、役割を分ける。
この分割こそが、初心者でも扱いやすい構造を作るんじゃ。
アプリ、Stripe、Webhook、Supabase の役割を4つに割ると、「何をどこで持つか」がかなり見えやすくなる。
Webhookとは何か。怖そうに見えるが、自動通知と思えばよい
Webhook は、名前で損しておる。
言葉だけ聞くと、なんだか難しそうじゃろ。
じゃが、意味はかなり単純じゃ。
Webhook = ある出来事が起きた時に、別のシステムへ自動で知らせる仕組み
これだけなんじゃ。
今回なら、
- ユーザーが支払った
- 支払いが失敗した
- サブスクを解約した
こういう出来事が Stripe 側で起きた時に、「今こうなったぞい」とアプリ側へ知らせる。その自動通知が Webhook じゃ。
たとえるなら、Stripe がレジで、Webhook は裏方へ渡す伝票みたいなものじゃな。
レジで会計が完了しただけでは、店の裏側の棚卸しは変わらん。
伝票が飛ぶ。
裏方がその伝票を見て、「この人は有料会員になった」「この人は支払い失敗中じゃ」「この人は解約済みじゃ」と台帳を書き換える。
それと同じじゃよ。
ここで大事なのは、Webhook 自体を怖がらんことじゃ。
怖いのは Webhook ではなく、通知が来た時に何を更新するかを決めていない状態 なんじゃ。
つまり本当の論点は、通知の仕組みではなく、通知後のルールじゃよ。
Webhook は難解な魔法ではなく、出来事を受け取るための標準の通知口じゃと捉えると怖さが減る。
StripeとSupabaseは、それぞれ何を担当するのか
ここが整理できると、頭の中がかなり静かになる。
まず Stripe は、お金と契約の専門家じゃ。
Stripe に任せるものは、次のようなものじゃ。
- カード決済
- 月額請求
- 請求失敗の検知
- 請求履歴
- Checkout画面
- Customer Portal
- 解約受付
アプリ側では Supabase を通して「いまの状態」を読むだけに寄せると、責任の境界がかなりきれいになる。
つまり、決済代行として信頼性が必要な部分は、なるべく Stripe に任せる。
一方で Supabase は、アプリ側の台帳係じゃ。
Supabase に持たせるのは、たとえば次のような情報で足りる。
user_idstripe_customer_idplanstatuscurrent_period_end
これだけあれば、「今このユーザーを有料扱いにしてよいか」は十分判定できる。
ここで大事なのは、Supabase に請求の専門知識を背負わせようとしないことじゃ。
請求の正本は Stripe に置く。
アプリで使う利用権限の正本は Supabase に置く。
この分け方をしておくと、頭の役割分担もコードの責任分担もかなりきれいになるぞい。
請求と契約の複雑さは Stripe 側に寄せ、アプリ側は権限判定に集中する。この分業が最小構成ではかなり効く。
利用権限台帳が1枚あると、課金停止と利用停止がつながる
ここでようやく subscriptions の話が出てくる。
じゃが、いきなり subscriptions テーブル と言うと、急にDB設計の話に見えてしまう。
まずはこう考えてくれい。
これは顧客管理システムではなく、利用権限台帳じゃ。
見ていることは、かなり少ない。
- 誰が
- どのプランで
- いつまで
- どんな状態で
- 使ってよいか
利用権限台帳で見るべき軸は本当に少なくてよい。列を増やすより、判定の軸を絞るほうが先なんじゃ。
この5点を見るだけなんじゃ。
台帳はDBで持つ。
だから最小構成では、本当に1枚の表で足りる。
Supabase の中では、それが subscriptions テーブルになる。じゃが、読者の頭の中では最初は「使っていい人リスト」でよいんじゃよ。
そしてアプリ側では、この台帳を見て判定する。
activeなら使えるpast_dueなら猶予ルールを見るcanceledなら期限まで使うか即停止するかを仕様で決めるunpaidなら止める
この時、かなり重要なのは「止める条件を人間が決める」ことじゃ。
支払い失敗の瞬間に即停止するのか。
3日間は猶予するのか。
解約しても請求期間の末日までは使わせるのか。
このルールは事業判断でもある。ここをAI任せにすると、あとで読者が一番困るんじゃよ。
逆に言えば、ここさえ決めてしまえば、コードはかなり楽になる。
支払い成功、失敗、解約のたびに裏側で何が動くのか
ここは、サブスク課金の心臓部じゃ。
最低でも、次の3パターンを押さえれば、かなり全体が見える。
1. 支払い成功
Stripe で課金成功。
Webhook が飛ぶ。
Supabase の台帳が active に更新される。
アプリはその状態を見て、有料機能を開く。
この時点で、「支払い画面が終わったから有料にする」のではなく、「台帳が更新されたから有料にする」と考えるとブレにくい。
2. 支払い失敗
Stripe で支払い失敗。
Webhook が飛ぶ。
Supabase の台帳が past_due または unpaid に更新される。
アプリは仕様に応じて、有料機能を止めるか、短い猶予を与える。
ここを曖昧にすると、「もう払われていないのに使い続けられる」という、いちばん痛い穴になりやすい。
Webhook の受け口は、支払い成功だけでなく失敗や解約の扱いを固める時にも効いてくる。
3. 解約
ユーザーが Stripe のポータルで解約する。
Webhook が飛ぶ。
Supabase の台帳が cancel_at_period_end 相当、または canceled に変わる。
アプリは「今すぐ止めるのか」「利用期限までは使えるのか」を、その状態に沿って判定する。
ここで「なるほど、ただのイベント処理じゃな」と思えたら十分じゃ。
サブスク課金システムは、巨大な怪物ではない。
状態更新の連鎖を、丁寧に設計しているだけ
なんじゃよ。
支払い成功 支払い失敗 解約 の3パターンが台帳の状態をどう変え、その後の利用可否へどうつながるかを一枚で見ておくとブレにくい。
この順で作れば迷いにくい。最小構成ロードマップ
ここからは実務じゃ。
思いついた順に作ると、たいてい崩れる。課金まわりは特に、「見える部分」から作りたくなるんじゃが、それをやると後で裏側が追いつかなくなる。
ワシのおすすめは、次の順じゃ。
Stripeに商品と価格を作るSupabaseにusersとsubscriptionsを作る- アプリから
Stripe Checkoutへ飛ばす Webhookを受け取る入口を作るWebhookを受けてSupabaseの台帳を更新する- アプリの有料機能側で、台帳を見てON/OFFを判定する
Stripe Customer Portalをつなぐ- 支払い失敗と解約までテストする
この順のよいところは、毎段階で「今どこまで動いているか」が見えやすいことじゃ。
たとえば、
- 商品が作れた
- Checkoutに飛べた
- 支払い後に
Webhookが届いた - 台帳が書き換わった
- 有料機能が開閉した
このように、小さく確認できる。
逆に、
- 先に管理画面を作り込む
- 先に細かい請求履歴を設計する
- 先に例外パターンを増やしすぎる
こう進めると、途中で視界が曇る。
特に初心者のうちは、「最小で通る一本道」を作るほうが圧倒的に強いぞい。
公開先もロードマップの一部じゃ。最初から凝らず、まずは課金導線が通る環境を一つ持てば十分じゃ。
ユーザー向けのアカウント画面は、ここまであれば十分じゃ
サブスク課金システムというと、裏側の話ばかり考えがちじゃ。
じゃが、ユーザーに見える画面も大事なんじゃよ。
というのも、ユーザーが自分の契約状態を確認できんと、問い合わせが一気に増えるからじゃ。
最初のアカウント画面としては、次の5つが見えれば十分じゃ。
- 現在のプラン名
- 次の更新日、または利用期限
- 現在の契約状態
- 「プラン管理」または「請求を管理する」ボタン
- 解約後の表示文言
たとえば、
現在のプラン: Pro次回更新日: 2026-05-12契約状態: 利用中請求管理を開く
こういう表示があるだけでも、かなり安心感が出る。
ここで無理に自前の請求管理画面を作り込まなくてよい。
むしろ、請求書やカード変更や解約は Stripe Customer Portal に渡したほうが軽いんじゃ。
つまり、お主のアプリ側では、
- 今どういう状態かを見せる
- 請求や解約の操作は
Stripe側へ送る
この役割に寄せるのがよい。
これもバイブコーディング向きじゃな。
AIには「アカウント画面に現在プラン、更新日、契約状態、請求管理ボタンを表示して」と頼めば、かなり素直にUIを出してくれる。
そのうえで、裏側は subscriptions の状態を読ませればよい。
ユーザー向け画面は、プラン名、更新日、契約状態、請求管理ボタンが見えていれば最初のMVPとしてはかなり強い。
バイブコーディングでは、どこをAIに任せると強いのか
ここもかなり大事じゃ。
AIに丸投げしてはいかん、という話ではない。
任せる場所を選べば、かなり強い んじゃよ。
AIに任せやすいのは、次の部分じゃ。
Stripe Checkoutを呼ぶAPIの雛形Supabaseテーブル定義のたたき台Webhook受信処理の土台- 管理画面の一覧UI
- 状態別の分岐コード
- テストコードの下書き
- エラーメッセージや案内文の草案
一方で、人間が先に決めるべきなのはこっちじゃ。
- どのプランを売るか
- 解約した時にいつ止めるか
- 支払い失敗で何日猶予するか
activepast_duecanceledunpaidをどう扱うか- 何をもって「使える」と判定するか
つまり、AIに速度を出してもらう前に、停止条件だけは人間が決める のがコツじゃ。
ここを先に決めれば、あとはAIにかなり手伝ってもらえる。
逆にここを曖昧にしたままだと、見た目はできておるのに、運用で事故る。
金を扱うコードは、派手さより責任の境界が大事なんじゃよ。
将来的に処理を分けたくなっても、最初は全部を複雑化せず「必要になったら切り出せる」と知っておけば十分じゃ。
料金プラン設計で、最初から悩みすぎないことも大事じゃ
サブスク課金システムの実装に入ると、今度は「価格をどうするか」で止まりやすい。
これも自然じゃ。
月額980円にするのか、1480円にするのか、2980円にするのか。無料体験を入れるのか、入れないのか。ライトとプロの2プランにするのか、最初は1プランに絞るのか。
ここで注意したいのは、価格設計の迷いでシステム実装を止めないことじゃ。
最小構成を通したい段階では、次のように決め打ちしてよい。
- まずは1プランだけ
- 月額だけ
- 無料体験なし、または短期間だけ
- 解約導線は
Stripe Customer Portalに任せる
これで十分じゃ。
価格は後から見直せる。じゃが、課金システムが1回も通っていない状態では、価格議論をしても机上の空論になりやすい。
逆に、1プランでもサブスク運用が回り始めると、次の判断ができるようになる。
- 低価格プランが必要か
- 年額を作る意味があるか
- 無料体験のほうが登録率が上がるか
- 既存買い切りユーザー向けの移行特典を作るか
つまり最初は、価格の正解を当てることより、価格付きで回る構造を持つことのほうが大事なんじゃ。
ここもAIに相談できる。
個人開発の小さなSaaSをサブスク販売したい。
最初は1プランだけで始めたい。
前提:
- 買い切り販売からの移行を考えている
- まずは最小構成で運用を通したい
- 継続率よりも、まず導入のしやすさを重視したい
この条件で、価格設計のたたき台を3案出して。こういう聞き方をすると、価格そのものより「どういう戦い方をするか」が見えやすくなるぞい。
料金設計を考える時は、Stripe 側で商品と価格をどう切るかまで含めて見ると、実装とのつながりが見えやすい。
管理者側で最低限見たい画面も、最初から決めておくと強い
読者はユーザー画面に意識が向きやすい。じゃが、運用を始めると、管理者側で見たいものも出てくる。
最初から大げさな管理画面を作る必要はない。じゃが、最低限ほしい景色はあるんじゃ。
たとえば次のような一覧じゃ。
- ユーザー名またはメールアドレス
- 現在のプラン
- 契約状態
- 利用期限
stripe_customer_id- 更新日時
この一覧があるだけで、サポート時にかなり助かる。
ユーザーから「払ったのに使えません」と言われた時、subscriptions を見れば、
- そもそも
activeになっているか past_dueで止まっているか- 期限切れなのか
- ひも付けが抜けているのか
が一気に見える。
つまり管理画面は、豪華なダッシュボードである必要はない。
台帳を人間が読める形にしておくこと
これが大事なんじゃ。
ここもAIにかなり任せやすい。
Supabase の subscriptions テーブルを一覧表示する管理画面を作りたい。
表示したい項目:
- email
- plan
- status
- current_period_end
- stripe_customer_id
- updated_at
要件:
- status ごとに色分け
- 期限切れが近いものは目立たせる
- 読み取り専用でよいこのくらい具体的に頼めば、かなり実用的な管理画面が返ってきやすい。
買い切り販売では、売れたかどうかだけ見ていれば済んだ。じゃが、サブスク運用では「今どういう状態の人が何人いるか」が見えること自体に価値があるんじゃよ。
ユーザー向けの請求変更や解約をどこへ逃がすかまで見えていると、管理画面を作りすぎずに済む。
ユーザーへの案内文も、サブスクでは地味に重要じゃ
課金システムというと、コードやDBに意識が向きがちじゃ。
じゃが、実際には文言もかなり大事じゃよ。
なぜなら、ユーザーが不安になるのは、たいてい“状態が見えない時”だからじゃ。
たとえば、次の文言があるだけでも、かなり印象が変わる。
現在のプラン: Proプラン次回更新日: 2026年5月12日解約後も次回更新日までは利用できますお支払いに失敗しています。カード情報を更新してください請求情報の変更や解約は、請求管理ページから行えます
こういう案内がないと、ユーザーは勝手に不安になる。
「もう解約されたのでは」
「二重課金されるのでは」
「支払いに失敗したけど、今どういう状態なのかわからん」
ここで問い合わせが増える。
だから、サブスク課金システムは“決済できれば終わり”ではない。
状態を伝える言葉まで含めて設計するもの
なんじゃ。
これもAIにかなり任せやすい分野じゃな。
SaaS の請求管理ページに表示する案内文を作って。
想定状態:
- 利用中
- 解約済みだが次回更新日までは利用可能
- 支払い失敗
- 利用停止
トーン:
- 不安をあおらない
- 何をすればいいかがすぐわかる
- 短く、やさしい日本語こういう部分まで記事に入れておくと、読者は「自分でも一連を作れそうじゃ」と感じやすくなる。
ユーザーに見せる文言と、実際に請求変更や解約を逃がす場所がつながっていると、問い合わせはかなり減る。
テストで必ず確認したいこと。正常系より異常系が大事じゃ
ここは、読者が油断しやすいところじゃ。
動いた瞬間に「できた」と言いたくなる。わかる。じゃが、サブスク課金は正常系より異常系で差がつく。
最低でも、次は必ず確認してほしい。
- 支払い成功後に
activeへ更新される - 支払い成功後に有料機能が開く
Webhookが2回飛んでも二重反映しない- 支払い失敗で
past_dueまたはunpaidに変わる - 支払い失敗後に意図した通り権限が止まる
- 解約後に「即停止」か「期限まで利用可」かが意図通りに動く
Stripe Customer Portalから戻ってきた後も状態表示が崩れない- テスト価格IDと本番価格IDを取り違えていない
この一覧を見ると、「やっぱり難しいんじゃないか」と思うかもしれん。
じゃが、全部いっぺんにやらんでよい。
むしろ、1つずつ確認するんじゃ。
まず正常系。
次に支払い失敗。
最後に解約。
この順でよい。
Stripe にはテストモードがあるから、ここはかなり助かる。最初から本番カードで試す必要はない。
AIにもテスト観点をそのまま投げてよい。
Stripe サブスク課金のテスト観点を一覧化して。
前提:
- Supabase の subscriptions テーブルで利用権限を判定している
- 支払い成功、支払い失敗、解約を扱う
出してほしいもの:
- 正常系テスト
- 異常系テスト
- Webhook 重複処理の確認項目
- 本番前チェックリストこういうプロンプトで観点を洗い出させるのも、かなり有効じゃよ。
テストは最後のおまけではない。Stripe 側にも検証の導線があると知るだけで、異常系の腰が軽くなる。
読者が最初の1週間でやることは、ここまでで十分
20,000字級の記事になると、どうしても読者は「結局、最初に何をすればええんじゃ？」と迷いやすい。
だから最後に、最初の1週間の行動だけ切り出しておく。
1日目
Stripeアカウント作成Supabaseプロジェクト作成- Git でブランチを切る
2日目
Stripeに商品と価格を作る- テスト用の価格IDを控える
Supabaseにusersとsubscriptionsを作る
3日目
- アプリから
Stripe Checkoutに飛ぶ処理を作る - テストモードで画面遷移を確認する
4日目
Webhook受信処理を作る- 支払い成功時に
activeへ更新されることを確認する
5日目
- アプリ側で有料機能のON/OFF判定を入れる
active以外の時の表示を整える
6日目
Stripe Customer Portalをつなぐ- 解約後の動きを確認する
7日目
- 支払い失敗シナリオを確認する
- 異常系チェックリストをつぶす
これだけでよい。
最初から「完璧なサブスク基盤を作る」と考えると重い。
じゃが、「1週間で最小構成を通す」と考えると、急に現実味が出るじゃろ。
そして、この“最小構成が通った”という体験が、その後の拡張よりも何倍も大きいんじゃよ。
公開後に少しずつ機能を足したくなっても、土台を小さく通してから広げればよい。最初から全部背負わんでよいんじゃ。
スプシでもできる。じゃが、標準ルートとしては勧めない
ここは、お主がかなり気にしていた論点じゃな。
結論から言うぞい。
Google スプレッドシート でも、極論やれなくはない。
購入者一覧を持って、状態を書き換えて、利用可否を判定する。発想としては確かに可能じゃ。
じゃが、標準ルートとして勧めるには弱い。
理由は次の通りじゃ。
- データ構造が崩れやすい
- 同時更新に弱い
Webhookの再送や重複処理を扱いにくい- 権限制御の責任が増えやすい
- 将来プラン追加や管理画面拡張をした時に苦しくなりやすい
スプシは「見える」から安心感がある。これはわかる。
じゃが、安心感と正規ルートは別の話じゃ。
サブスク販売を真面目にやるなら、最初から表として扱いやすいDBに置いたほうがよい。
その意味で Supabase はちょうどよい。
難しすぎず、軽すぎず、あとで伸ばしやすい。
だからこの記事では、スプシでもできるが、ちゃんとサブスク販売するなら Supabase のほうがよい と言い切る。
読者を迷わせないためじゃ。
スプシの安心感に引っ張られそうな時ほど、「表をちゃんとDBとして持てる」ことの価値を思い出すとブレにくい。
よくあるつまずきと、その場での考え方
最後に、読者が止まりやすいところも拾っておく。
「課金は通ったのに、有料機能が開かない」
これは多い。
原因の多くは、「ブラウザの成功画面」と「台帳の更新」を混同しておることじゃ。
成功画面が開いたことではなく、Webhook を受けて Supabase の状態が active になったことを根拠に有料化する。この原則を守ると崩れにくい。
「解約したのに、まだ使える」
これは仕様未定義で起きやすい。
“即停止” にするのか “請求期間末まで利用可” にするのかを先に決めねばならん。
コードの問題ではなく、事業ルールの問題なんじゃよ。
「支払い失敗をどのくらい厳しく扱うべきかわからない」
ここは迷う。
じゃが、最初は厳密な正解を探しすぎなくてよい。
たとえば、
- 失敗直後は
past_due - 数日後も回復しなければ
unpaid unpaidで利用停止
このくらいの単純なルールから始めても十分じゃ。
「バックエンドをわかった気になれない」
これも自然じゃ。
じゃが今回の構成では、やっていることは意外と少ない。
Stripeで出来事が起きるWebhookが飛ぶSupabaseの台帳が更新される- アプリがその台帳を見る
これだけなんじゃ。
“全部わかる” を目指すより、“今どこが何をしているか言える” を目指すほうが前に進めるぞい。
標準ルートを一本に絞るなら、見える管理画面とDBの素直さがある Supabase を軸に考えるほうが迷いにくい。
裏側の処理は、最初から全部を理解しきれなくてもよい。あとから切り出せる余地があると知るだけで十分前へ進める。
ここまで読んだお主へ。サブスク課金は“裏側の恐怖”ではなく“売り方の武器”じゃ
最後に、もう一度だけ大事なことを言うぞい。
サブスク課金システムを作る話になると、どうしても人は「難しい技術」に意識を持っていかれやすい。
じゃが、本当に大事なのはそこだけではない。
お主が欲しいのは、Webhook に詳しい自分になることではないはずじゃ。
欲しいのは、
- ちゃんと月額で売れること
- 払ってくれている人に気持ちよく使ってもらえること
- 払っていない状態がズルズル残らないこと
- アプリを改善し続ける意味が、売上に返ってくること
この未来じゃろ。
つまりサブスク課金システムは、技術そのものよりも、商売の形を育てるための武器なんじゃ。
ここが腹落ちすると、Stripe も Supabase も、ただの難しい単語ではなくなる。
「その未来を作るための道具なんじゃな」
と見えるようになる。
ここまで来れば、もう十分強いぞい。
まとめ
バイブコーディングでサブスク課金システムを組む時に大事なのは、難しいバックエンドを征服することではない。
売り方を変えるために、
- 何を
Stripeに任せるか - 何を
Supabaseに持つか - どの状態で利用権限を止めるか
この3点を素直に分けることじゃ。
2026年4月12日時点の公式案内ベースで見ても、AI代を除けば固定費ほぼ0円で開発開始は狙える。だからこそ、ここで止まるのはかなりもったいない。
お主が次にやるべきことは、たった1つじゃ。
Stripe に商品を1つ作り、Supabase に利用権限台帳を1枚作る。
まずはそこからでよい。
そこまでできれば、買い切り販売しかできなかった状態から、月額で育つアプリへ一歩進めるぞい。
本当にお疲れ様じゃったな。ここを越えると、アプリの売り方そのものが変わってくる。また会おうぞい。