2025年1月25日·1分で読めます

コード不要のStripeサブスクリプション：収益漏れを招くミス

コード不要でStripeのサブスクリプションを構築する際に、Webhook処理、トライアルロジック、プロレーション、支払い失敗のリトライを見直して収益漏れを防ぐ方法。

サブスクリプションで収益が漏れ始める場所

サブスクリプションの収益漏れは、めったに劇的に現れません。小さく繰り返されるミスとして現れます：顧客がアクセスを持ち続けるべきでないのに保持している、アップグレードで正しく請求されない、クレジットが二重に適用される、など。ひとつのエッジケースが数週間静かに繰り返されることがあります。特にサブスクリプションが拡大するとそうなります。

コード不要でStripeサブスクリプションを構築している場合でも、課金にはロジックが必要です。Stripeは請求エンジンですが、アプリが「アクティブ」をどう定義するか、機能をいつ解放するか、更新や支払い失敗にどう反応するかを決めます。ノーコードツールは多くの作業を省きますが、あなたのルールを推測してはくれません。

多くの漏れは次の4つに起因します：

Webhookの処理が正しくない（イベントの見逃し、重複、順序の誤り）
トライアルが期待どおりに終了しない（キャンセルや未払い後もトライアルアクセスが続く）
プラン変更時のプロレーション（アップグレードやダウングレードで不足請求や意外なクレジットが発生）
支払い失敗とリトライ（ダニング中にアクセスが残る、または早すぎて切れる）

よくあるパターンは「ハッピーパスでは動作する」です。購読し、アクセスを得て、最初の請求書が支払われる。ところが実際にはカードが失敗したり、顧客がサイクル途中でアップグレードしたり、誰かがトライアル中にキャンセルしたり、Stripeが夜間に支払いを再試行したりします。アプリが一つのフィールドだけを確認したり、一つのイベントだけをリッスンしていると、無料の時間を与えたり、二重クレジットを生んだりします。

AppMasterのようなプラットフォームを使えば、画面やフローを素早く作れます。リスクはデフォルトのフローが正しい課金ポリシーと等しいと誤解することです。アクセスルールを定義し、バックエンドがStripeイベントに一貫して反応することを検証する必要があります。

どちらをアクセスの真実の源にするか決める

コード不要でStripeサブスクリプションを運用するなら、後で多くの漏れを防ぐ決定があります：今この瞬間にユーザーがアクセスを持っているかをどのシステムが決めるか。

一般的に2つの選択肢があります：

Stripeを真実の源にする：アクセス判断が必要なときはいつでもStripeでサブスクリプションの状態を参照する
自分のデータベースを真実の源にする：アクセス状態を保存し、請求イベントが起きたときに更新する

後者はアプリにとって高速で、Webやモバイルで一貫性を保ちやすいですが、確実に更新されることが前提です。

実務的なアプローチとしては：請求はStripeを真実の源にし、アクセスはあなたのデータベースを真実の源にする。データベースは手で編集したり「支払い済みにする」ボタンで変更してはいけません。Stripeイベントから派生させ（必要に応じて照合する）、更新するべきです。

そのために安定した識別子が必要です。最低でもユーザーまたはアカウントレコードに次を保存してください：

Stripeの customer ID（誰が支払っているか）
Stripeの subscription ID（どのプランか）
最新の invoice ID（プロレーションを含む何が請求されたか）
最新の payment_intent ID（実際に支払いが試みられたもの）

次に、プロダクト内で各サブスクリプション状態が何を意味するかを定義してください。画面や自動化、Webhookを構築する前に、シンプルなルールとして書き出しましょう。

多くのチームが使う明確なデフォルトポリシーの例：

active：フルアクセス
trialing：trial_endまでフルアクセス、その後ステータスを再確認
past_due：短期間の限定アクセス（例えば閲覧のみ）
unpaid：有料機能をブロック、請求ページとデータエクスポートは許可
canceled：period_endまではアクセスを保持し、それ以降ブロック（許可する場合）

「永遠の無料」ギャップを避けてください。もし past_dueでフルアクセスを許すなら、（あなたが保存する）日付に基づいた明確な締め切りが必要です。曖昧な「あとで直す」では不十分です。

AppMasterで構築する場合、アクセス決定をビジネスロジックとして扱ってください：アカウントに現在のアクセス状態を保存し、Stripeイベントから更新し、WebとモバイルのUIが一貫してそのフィールドを参照するようにします。これによりStripeイベントが遅延したり順序が入れ替わっても挙動が予測可能になります。

Webhook：見逃しや重複処理を防ぐパターン

Webhookは収益漏れが静かに始まる場所です。Stripeはイベントを複数回送ることがあり、順序が入れ替わったり、数時間後に配信されることもあります。すべてのWebhookを「遅延している可能性がある」かつ「重複して届く可能性がある」と見なし、それでも正しくアクセス更新できるように設計してください。

重要なイベント（通常は無視できるイベントも）

実際のサブスクリプション状態の変化を表す小さなイベントセットに絞ってください。多くのセットアップでは次で十分です：

checkout.session.completed（Checkoutでサブスクリプションを開始したとき）
customer.subscription.created、customer.subscription.updated、customer.subscription.deleted
invoice.paid（課金期間が実際に支払われた瞬間）
invoice.payment_failed（支払われなかった瞬間）

多くのチームは charge.updated や payment_intent.* のようなノイジーなイベントに過剰反応し、矛盾したルールを作りがちです。請求とサブスクリプションをうまく扱えているなら、低レベルのイベントは混乱を招くだけのことが多いです。

冪等性（Stripeの再送時に二重で解放しない）

StripeはWebhookを再送します。もし invoice.paid を見るたびにアクセスを付与していると、顧客が追加の時間や二重の権利を得ることになります。

シンプルなパターン：

まず irreversible な操作を行う前に event.id を処理済みとして保存する
同じ event.id を見たら早期に終了する
何が変わったか（ユーザー/アカウント、サブスクリプションID、以前のアクセス状態、新しいアクセス状態）を記録する

AppMasterでは、これはデータベーステーブルと「既に処理済み？」をチェックするBusiness Processのフローにきれいに対応します。

イベントの順序：遅延や順序入れ替わりに備える

customer.subscription.updated が invoice.paid より先に届くとは限りませんし、すべてのイベントが順序どおりに来るとも限りません。期待する順序ではなく、最新のサブスクリプションと請求書の状態に基づいてアクセスを決めてください。

矛盾が見えたら、Stripeから現在のサブスクリプションをフェッチして照合してください。

また、サポートの問い合わせに備えて生のWebhookペイロードを少なくとも30〜90日保持しておくことをおすすめします。「なぜアクセスを失ったのか」「なぜ二重請求になったのか」といった問いに対する監査証跡になります。

無料アクセスや請求混乱を生むWebhookの誤り

WebhookはStripeが「実際に起きたこと」を伝えるメッセージです。アプリがそれを無視したり、間違ったタイミングで反応すると、無料でアクセスをばらまいたり、一貫性のない請求挙動を生んだりします。

よくあるミスは、支払いが集まった瞬間ではなく、Checkoutが完了したときにアクセスを付与することです。checkout.session.completed は顧客がサブスクリプションを開始したことを意味しますが、最初の請求書が支払われたことを意味しない場合があります。カードの失敗、3Dセキュアの放棄、一部の支払い手段の後払いなどがあるため、アクセスについては invoice.paid（または請求書に紐づく成功した payment_intent）を有効にする瞬間と見なしてください。

もう一つの漏れの原因はハッピーパスのイベントだけを聞いていることです。サブスクリプションは時間とともに変化します：アップグレード、ダウングレード、キャンセル、一時停止、past_due状態。サブスクリプション更新を処理しないと、キャンセルした顧客が数週間アクセスを保持することになります。

注意すべき4つの落とし穴：

フロントエンドを信頼して「サブスクリプションはアクティブだ」と伝えてくるのをそのまま受け入れる（Webhookからデータベースを更新すること）
Webhook署名を検証していない（偽リクエストでアクセスが切り替わる可能性）
テストと本番イベントを混同する（例：本番でテストモードのWebhookを受け入れる）
一つのイベントタイプだけを扱い、他は「そのうちうまくいく」と想定する

実際の失敗例：顧客がCheckoutを完了し、アプリがプレミアムをアンロックしたが、最初の請求書が失敗した。失敗イベントを処理しなければ、支払われていないのにプレミアムが維持されます。

AppMasterのようなノーコードプラットフォームでStripeサブスクリプションを構築する場合でも目的は同じです：サーバー側に一つのアクセス記録を持ち、支払い成功・失敗・サブスクリプション状態の変化が検証されたときだけそれを変更してください。

トライアル：終わらない無料時間を避ける

本番対応のバックエンドを作る

サブスクリプションルールを反映するAPIを備えたGoバックエンドを生成します。

バックエンドを構築

トライアルは単なる「支払いが無料」ではありません。顧客が何を使えるか、どのくらいの期間か、次に何が起きるかという明確な約束です。最大のリスクはトライアルをUI上のラベルとして扱い、時間で制御されるアクセスルールとして扱わないことです。

トライアルアクセスがプロダクトで何を意味するかを決めてください。フルアクセスか、機能や座席数、使用量が制限されるか。トライアル終了前にどうリマインドするか（メールやアプリ内バナー）、カード未登録のときに請求ページで何を表示するかも決めてください。

アクセスはローカルの真偽値（例：is_trial = true）ではなく、検証できる日付に紐づけてください。Stripeがトライアル付きでサブスクリプションを作成したときにトライアルアクセスを付与し、トライアルが終わったらサブスクリプションがアクティブかつ支払い済みでない限りトライアルアクセスを削除してください。trial_ends_at はユーザーのボタンでなく、Stripeイベントから更新しましょう。

カード収集のタイミングが「永遠の無料」に最も入り込みやすい場所です。カードを収集せずにトライアルを始めるなら、コンバージョンパスを計画してください：

トライアル終了前に「支払い方法を追加する」ステップを明確に表示する
カードなしでトライアル開始を許すかどうかを決める
コンバージョン時に支払いが失敗したら、すぐにアクセスを減らすか短期間の猶予を設ける
アプリ内で正確なトライアル終了日を常に表示する

エッジケースは重要です。サポートがトライアルを延長したり、ユーザーが初日にキャンセルすることがあります。ユーザーがトライアル中にアップグレードし、新しいプランを即時に期待することもあります。単純なルールを選び、常に一貫させてください：トライアル中のアップグレードはトライアル終了日を維持するか、トライアルを終了して今すぐ請求を開始するか、どちらかを明確にして可視化しましょう。

よくある失敗パターン：ユーザーが「トライアル開始」をクリックしたときにトライアルアクセスを付与し、トライアル終了時にユーザーが「キャンセル」をクリックしたときだけ削除する。タブを閉じたりWebhookが失敗したりすると、アクセスが残ってしまいます。ノーコードアプリ（AppMasterを含む）では、フロントエンドの手動フラグではなくStripeのWebhookで受け取るサブスクリプション状態とトライアル終了タイムスタンプに基づいてアクセスを決めてください。

プロレーション：プラン変更時の誤請求を防ぐ

アイデアから動くフローへ

課金、ステータス、アップグレード用の画面を備えた最小限のサブスクフローを出荷します。

プロトタイプ作成

プロレーションは顧客がサイクル途中でプランを変更したときに、利用した分だけ請求を自動調整する仕組みです。アップグレード、ダウングレード、数量変更（座席など）、価格変更時にStripeはプロレーション請求を作ることがあります。

最も一般的な収益漏れはアップグレード時の過少請求です。アプリが新プランの機能をすぐに付与するが、課金変更の適用が後になったり、プロレーション請求が未払いのままだったりすると、顧客は次の更新まで無償でより良いプランを使えます。

プロレーションポリシーを選び、それに従う

アップグレードとダウングレードを同じ扱いにしてはいけません（意図的にそうしたい場合を除く）。

シンプルで一貫したポリシー例：

アップグレード：即時適用し、差額を今請求する（プロレーション）
ダウングレード：次回更新で適用（サイクル途中での返金は行わない）
数量の増加（座席追加）：即時適用でプロレーション請求
数量の減少：次回更新で適用
任意：年契約など特別なケース以外は「プロレーションなし」を勝手に使わない

Stripeをコード不要で使う場合（AppMasterなど）、プラン変更フローとアクセス制御ルールがこのポリシーと一致していることを確認してください。アップグレードで今請求するなら、Stripeがプロレーション請求の支払いを確認するまでプレミアムを解放しないでください。

座席や使用量階層でのサイクル途中の変化は複雑になりがちです。チームが25日目に20席追加し、27日目に15席減らした場合、ロジックが一貫していないと追加席に対して請求されなかったり、混乱するクレジットが発生して返金やサポートチケットにつながったりします。

クリック前にプロレーションを説明する

プロレーションによる争いは驚きの請求書が原因となることが多いです。確認ボタンの近くに短い一文を追加してポリシーとタイミングを明示してください：

「アップグレードは即時開始され、差額を prorated で今請求します。」
「ダウングレードは次回請求日に反映されます。」
「座席を追加すると即時請求、削除は次サイクルから反映されます。」

期待を明確にすればチャージバックや返金要求、「なぜ二重請求された？」という問い合わせを減らせます。

支払い失敗とリトライ：ダニングとアクセスを正しく扱う

支払い失敗はサブスクリプション設定が静かにお金を漏らす場所です。請求失敗後もアクセスを開いたままにすると、支払われないサービスを提供してしまいます。逆に早すぎてアクセスを停止するとサポートチケットや不要な解約につながります。

把握すべき状態

失敗したチャージの後、Stripeはサブスクリプションを past_due、さらに unpaid（設定によってはキャンセル）へ移行させます。これらを区別して扱ってください。past_due は通常回復可能でStripeが再試行を続けている状態です。unpaid は請求書が支払われておらずサービスを停止すべき状態です。

コード不要でStripeサブスクリプションを運用する際、よくあるミスは一つのフィールド（例：「subscription is active」）だけをチェックして請求失敗に反応しないことです。アクセスは請求のシグナルに従うべきで、推測に頼ってはいけません。

収益を守るためのシンプルなダニングプラン

リトライスケジュールと猶予期間をあらかじめ決め、それをアプリで強制できるルールとして実装してください。Stripeは再試行を処理しますが、リトライ期間中にアクセスをどうするかはアプリ側の決定です。

実用的なモデル：

invoice.payment_failed で：アカウントを「支払い問題」とマークし、短い猶予期間（例：3〜7日）はアクセスを維持する
サブスクリプションが past_due の間：アプリ内にバナーを表示し「カード更新」を促す
支払いが成功したとき（invoice.paid または invoice.payment_succeeded）：支払い問題フラグを解除しフルアクセスを復元する
サブスクリプションが unpaid になった、またはキャンセルされたとき：閲覧のみや主要操作のブロックなどを行う（単に請求ページを隠すだけにしない）
最新の請求書ステータスと次の再試行時刻をログに残し、サポートが状況を把握できるようにする

無限の猶予を避けるために、あなた側でハードデッドラインを保存してください。最初の失敗イベントを受け取ったときに猶予終了時刻を計算し、後のイベントが遅延または見逃されてもそれを適用するようにします。

「カード更新」フローでは、顧客が新しい情報を入力しただけで問題が解決したと仮定しないでください。Stripeが支払いの復旧（請求書が支払われた、または成功した支払いイベント）を示して初めて回復を確認してください。AppMasterでは、支払い成功のWebhookが到着したときにユーザーをアクティブに戻し、機能を解除し、確認メッセージを送るといったBusiness Processが明確に作れます。

例：ある顧客の経路と4つの共通落とし穴

サブスクリプションをモバイルにもたらす

課金ステータスとアカウントアクセス用のネイティブiOS/Android画面を追加します。

モバイルを構築

Mayaは14日間のトライアルにサインアップしました。カードを入力してトライアルを開始し、10日目にアップグレードし、その後銀行が更新時の支払いを拒否しました。これは普通に起きることで、収益漏れが発生しやすい典型的な流れです。

タイムラインとアプリがするべきこと

トライアル開始：Stripeがサブスクリプションを作成しトライアル終了を設定します。通常 customer.subscription.created が来て、セットアップによっては今後の請求書が見えるでしょう。アプリはサブスクリプションがトライアル中ならアクセスを付与し、トライアル終了日時を記録して自動でアクセスを変更できるようにします。

落とし穴1：サインアップ成功時のみアクセスを付与し、トライアル終了時に更新しない。

トライアル中のアップグレード：Mayaは10日目にBasicからProへ変更します。Stripeはサブスクリプションを更新し、請求書やプロレーションを生成するかもしれません。customer.subscription.updated、invoice.created、invoice.finalized、その後支払いがあれば invoice.paid といったイベントが見えます。

落とし穴2：「プランが変更された」ことを即時の支払い確定と見なし、請求が未確定または後で失敗しても有効にしてしまう。

更新：14日目に最初の有料期間が始まり、次の月に更新請求が試みられます。

落とし穴3：一つのWebhookに頼って他を見逃し、invoice.payment_failed 後にアクセスを除去しなかったり、または invoice.paid 後にアクセスを除去してしまったりする（二重処理や順序入れ替わり）。

カード失敗：Stripeが請求書を未払いにし、設定に基づいて再試行を開始します。

落とし穴4：短い猶予期間を設けずに即時にユーザーをロックアウトしてしまう。

サポートが素早く問題解決するために保存すべき情報

小さな監査証跡を保持してください：Stripeの customer ID、subscription ID、現在のステータス、trial_end、current_period_end、最新の invoice ID、最後の成功支払日、最後に処理したWebhookイベントIDとタイムスタンプ。

Mayaがサポートに連絡したとき、チームはすばやく2つの質問に答えられるべきです：今Stripeは何と言っているか、そしてアプリが最後に何を適用したか。

QAチェックリスト：ローンチ前に請求挙動を検証する

Webhookを安全にする

Business Process Editorでidempotencyチェックを組み込んだ安全なStripe webhook処理を行います。

ワークフロー作成

請求はスイッチではなくテストすべき機能です。ほとんどの収益漏れはStripeイベントとアプリがアクセスについて決める間のギャップで発生します。

まず「Stripeは課金できるか？」と「アプリはアクセスを付与するか？」を分けて考え、実際に出荷する環境で両方をテストしてください。

ローンチ前のセットアップチェック

テスト環境と本番環境の分離を確認：キー、Webhookエンドポイント、商品/価格、環境変数
Webhookエンドポイントのセキュリティを確認：署名検証を有効にし、署名なしや不正なイベントは拒否する
冪等性を確認：繰り返しのイベントで余分な権利、請求、メールが発生しないこと
ロギングが使える状態にする：event ID、customer、subscription、および最終的なアクセス決定を保存する
マッピングを検証：各ユーザーアカウントが正しく1つのStripe customerに紐づいていること（マルチカスタマールールがある場合は明確にする）

AppMasterでは通常、Stripe統合、環境設定、Business Processフローが各Webhookイベントと結果としてのアクセス変更に対してきれいな監査証跡を記録することを確認します。

サブスクリプション挙動のテストケース

これらを短いスクリプト化されたQAセッションとして実行してください。実際の役割（通常ユーザー、管理者）を使い、アプリで「アクセスON/OFF」が何を意味するかを書き出してください。

トライアル：トライアルを開始、トライアル中にキャンセル、期限切れ、延長1回、支払い成功時にのみコンバージョンが行われるか確認
プロレーション：サイクル途中でアップグレード、ダウングレード、同日に2回プラン変更を行うなど。請求書とアクセスがポリシーに一致するか確認
クレジット/返金：クレジットや返金を発行し、プレミアムアクセスを永遠に保持しない（または早すぎに削除しない）ことを検証
支払い失敗：更新失敗をシミュレートし、リトライのタイミングと猶予期間を確認、アクセスがいつ制限/削除されるか検証
回復：支払い失敗後に支払いを完了し、アクセスがただちに（かつ一度だけ）戻ることを確認

各テストで3つの事実を記録してください：Stripeのイベントタイムライン、あなたのデータベース状態、ユーザーが実際にアプリでできること。これら3つが一致しないとき、それが漏れの原因です。

次のステップ：安全に実装し、請求を予測可能に保つ

請求ルールを平易な言葉で書き、特定の条件にします：アクセスがいつ始まるか、いつ止まるか、「支払われた」とは何を指すか、トライアルがどう終わるか、プラン変更で何が起きるか。二人が読んで異なる結果を想像するなら、そのワークフローはお金を漏らします。

そのルールを繰り返し実行できるテスト計画に落とし込み、課金ロジックを変更するたびに実行してください。専用のStripeテスト顧客と固定スクリプトを用意するだけで「適当にクリックして様子を見る」よりも優れています。

テスト中は監査証跡を残してください。サポートやファイナンスは「なぜこのユーザーがアクセスを保持したのか」「なぜ二重請求になったのか」といった迅速な回答を必要とします。主要なサブスクリプションと請求書の変更（ステータス、現在期間の日付、トライアル終了、最新の請求書、payment_intentの結果）をログに残し、WebhookイベントIDを保存して何が起きたか証明できるようにしてください。

コード不要で実装する場合でも AppMaster (appmaster.io) は構造を一貫させるのに役立ちます。Data Designerで課金データをモデル化（PostgreSQL）、Business Process Editorでidempotencyチェックを含むStripe webhookを処理し、WebとモバイルUIが読む単一の「アクセスの真実」フィールドでアクセスを制御できます。

最後に、本番を想定したドライランを行ってください：同僚がサインアップし、アプリを使い、アップグレードし、支払いが失敗し、それを修正する。すべてのステップが書面化したルールに一致するなら準備完了です。

次のステップ：AppMasterで最小限のStripeサブスクリプションフローを構築し、ローンチ前にQAチェックリストを実行してみてください。