A&A INSIGHTS
AI SaaSの有料プランを増やす前に：料金表と使える機能を一致させる
無料版と有料版を分ける一人開発のAI SaaS創業者へ。Stripeの利用権（Entitlements）の資料とLovableの事例から、売る単位を機能キーで定義し、既存契約者への反映が次の請求期間までずれることを公開前に確認する手順を示します。
Read in English
この記事の要点
新しい有料プランは、料金表を書いた時点では提供できません。売る単位をプラン名ではなく機能キーで定義し、アプリがその機能一覧を読んで開け閉めする形にし、既存契約者への反映が次の請求期間の開始までずれることを確認してから公開します。プランを増やすたびにコードの分岐が増える設計のままだと、料金表に書いた約束と実際に使える範囲は必ずずれます。この記事では出典の記述、A&Aの解釈、架空の記入例を分けています。
増やすのはプランではなく、売る機能の一覧
A&Aの考え方
有料プランを一つ増やすときに最初に決めるのは、価格でも名前でもありません。そのプランで新しく売る「機能」を、プランから独立した名前で一覧にすることです。アプリ側の判定を「このお客様はProか」ではなく「このお客様はこの機能を使えるか」に置き換えておくと、次にプランを増やすときに触るのは料金表と対応表だけで済みます。逆に判定がプラン名のままだと、プランを増やすたびにコードの分岐が増え、料金表に書いた約束と実際に使える範囲は少しずつずれていきます。ずれは公開直後には見えません。見えるのは、最初の問い合わせが届いたときです。
出典に基づく事実
Stripeの利用権（Entitlements）の資料は、利用権を「顧客がある機能へ接続できる状態」を表すものと説明し、機能を付けた商品を顧客が購入または契約した時点で、その顧客とその機能に対する有効な利用権（Active Entitlement）をStripeが作成し管理すると書いています。資料はこの仕組みの目的を、自社サービス内部の機能をStripeの商品へ対応させることだと説明し、対応付けを済ませたあとは、顧客の契約状態に応じて、いつ・どの機能について提供を開始または停止すべきかをStripeが通知すると述べています。契約が有効であり続けるあいだ、その顧客は有効な利用権を保持し続けるとも書かれています。加えて、一つの機能は複数の商品に付けられると明記されています。
A&Aの考え方
この最後の一文が、プランではなく機能を単位にする理由です。一つの機能が複数の商品に付くということは、商品（つまりプラン）の側は機能の組み合わせにすぎない、という構造になっているということです。A&Aはここから、一人で開発している事業ほど先に機能の一覧を確定させたほうがよいと考えます。プランは営業の都合で何度でも組み替わりますが、機能は「その利用者が何をできるか」なので、そう頻繁には変わりません。変わらないほうを判定の軸にしておくと、料金表の変更がアプリの変更を呼ばなくなります。Stripeの資料自身も、この仕組みの利点を「コードを変えずに価格を出し、変え、試せること」と表現しています。ただしその利点が効くのは、判定をプラン名から機能キーへ移し終えたあとだけです。
プランの差には「量」と「可否」があり、詰まり方が違う
出典に基づく事実
StripeがLovableについて公開した顧客事例ページには、同社が2024年11月の公開に合わせてStripe Billingで一連の契約プランを用意したと書かれています。その内訳は、個人向けの無料枠と、月次の利用クレジットが段階的に増え、かつ専用の機能が付く有料枠です。さらに2025年にはLovable CloudとLovable AIの公開に合わせてStripeの従量課金の機能を導入し、メーターとレートカードの定義、実使用量の取り込み、実際の消費に基づく請求までを2週間で実施したと記載されています。ページはこれによって従量価格、実時間でのクレジット消費の可視化、支出の見通しが得られたと説明しています。なおこのページはStripeが自社の顧客事例として公開したものです。
A&Aの考え方
この記述のなかに、プラン差の軸が二つ同居しています。「月次の利用クレジットが段階的に増える」のは量の軸で、「専用の機能が付く」のは可否の軸です。A&Aが小さな事業に当てはめるとき重要なのは、この二つが利用者にとってまったく違う詰まり方をする、という点です。量で詰まったとき、利用者は理由を自分で理解できます。残量が減っていき、ゼロになって止まるからです。可否で詰まったときは理由が見えません。ボタンが無い、押しても何も起きない、エラーだけが出る。どれも利用者からは「壊れている」ように見えます。問い合わせが来るのは後者で、しかもその文面には「使えない」としか書かれていないことが多い。つまり可否の設計は、サポートの負荷として跳ね返ってきます。
仮想例
架空の例で書きます。ある一人開発の文字起こしサービスが、月額プランを二つに分けたとします。上位プランの差分は「月の処理時間が3倍」と「話者の自動分割」の二つ。前者は量、後者は可否です。下位プランの利用者が話者分割を試そうとした場面を想像すると、その人の残時間はまだ十分あります。利用者から見れば「使えるはずなのに動かない」状態です。ここで画面に出すべき文は「上限に達しました」ではなく「この機能は上位プランに含まれます」であり、この二つを同じ分岐から出していると、必ずどちらかが嘘になります。量の見せ方そのものについては、既存記事「AI SaaSのクレジット制をどう説明するか：使える量と追加支出を見せる」で扱っています。この記事は可否の側と、その反映のタイミングだけを扱います。
| 料金表に書いた約束 | 実装で抜けやすい点 | 公開前に確認すること |
|---|---|---|
| 上位プランでは高度なレポートが使えます | 判定がプラン名の分岐のままになっている | 判定を機能キーの一覧に変え、プラン追加でコードを触らない形にする |
| 本日から新しい機能を提供します | 既存契約者の利用権は当日には変わらない | 反映は次の請求期間の開始として、告知文とサポート回答を二行で書き分ける |
| 上位プランには専用サポートが付きます | 機能キーをプラン名で付けて後から改名できない | キーは能力の名前で付け、作成前に一覧を確定させる |
| 解約すると使えなくなります | 通知を受けてもアプリ側が閉じていない | 取り消し時に閉じる対象を機能キー単位で列挙し、閉じ損ねの検知を決める |
| プランごとの機能差は一覧のとおりです | 機能が増えて通知の要約に載りきらない | 10件を超える場合のURL経由の取得を、増やす前に実装する |
| クレジットを使い切ると停止します | 量の上限と可否の判定を同じ分岐に入れている | 量と可否を別の判定にし、利用者に出す文言も分ける |
機能キーはあとから変えられない。プラン名で付けない
出典に基づく事実
Stripeの資料は、機能を作るときに名前と一意の識別キー（lookup_key）を指定すると説明しています。このキーは機能ごとに一意であり、別の機能へ再利用することはできないと書かれています。Dashboardからの手順の側には、機能を作成したあとlookup_keyは編集できないこと、そのキーに結び付いた機能を保管（archive）しないかぎり別の機能で使い回せないことが記載されています。さらに保管については、保管した機能は編集できず新しい商品へ追加することもできないが、既存の商品に付いたままであれば引き続き利用権を作ること、保管した機能のlookup_keyは再び使えるようになること、保管の取り消しはできないことが列挙されています。
A&Aの考え方
つまりこのキーは、事業の途中で言い換えが効かない数少ない文字列です。A&Aの解釈では、ここにプランの呼び名を入れるのが最もよくある失敗です。proやbusinessといったキーは、付けた瞬間は自明に見えます。しかし半年後にプラン名を「スタンダード」へ変えた時点で、コードの中だけ古い名前が残ります。しかも保管しても既存商品では利用権が作られ続けるため、その古い名前は静かに残り続けます。キーは、売り方ではなく能力の名前で付けます。話者分割、API接続、書き出し形式の追加といった、料金表を書き換えても意味が変わらない粒度です。逆に言えば、キーを付けようとして能力の名前が出てこない差分は、そもそも機能ではなく値引きや呼び名の違いである可能性があります。
仮想例
架空の対応表で言うと、先の文字起こしサービスなら機能は話者分割と優先処理の二つだけで、商品は「ライト」と「プロ」の二つです。話者分割は「プロ」にだけ付き、優先処理は「プロ」と、後から足す「年間プロ」の両方に付きます。将来「プロ」を廃止して「チーム」へ移すときも、機能キーは動きません。動くのは商品と機能をつなぐ線だけです。対応表は紙一枚で足ります。左に機能キー、右にその機能を含む商品名を並べ、線が一本しかない機能と、二本以上ある機能を見分けられる形にしておきます。
既存契約者に届くのは、公開した日ではなく次の請求期間から
出典に基づく事実
商品に機能を付ける手順の説明には、注意書きとして次の一文が置かれています。既存の契約については、商品の機能変更に対応する有効な利用権が「次の請求期間の開始時」に作成される、というものです。一方、新しく契約した顧客については、契約が最初に有効化された時点で、その顧客が契約している機能の利用権をStripeが作成すると書かれています。また資料は、契約の有効化からアップグレード、ダウングレードなどを含む契約の過程を通じて、対応付けた機能に基づいて顧客の利用権をStripeが更新すると説明しています。
A&Aの考え方
この非対称は、公開当日の説明文をそのまま壊します。料金表を更新して「本日より、プロプランに話者分割が付きます」と告知した日、その文が正しいのは新規契約者に対してだけです。すでにプロを契約している利用者の利用権は、その日には変わりません。A&Aはこれを仕様の欠陥ではなく、告知の書き分けが必要になる前提だと読みます。書き分けは二行で足ります。新しくご契約の方はすぐに、すでにご契約中の方は次回の請求日から。サポートへ「私のアカウントでは出ていない」という連絡が来るのは、この二行が無いときだけです。ここを省くと、仕様どおりに動いているシステムについて、不具合としての問い合わせを自分で作り出すことになります。
仮想例
架空の日付で確認します。毎月12日が請求日の利用者がいて、9月20日に商品へ機能を足したとします。この利用者に利用権が作られるのは10月12日です。その20日間、料金表とその人の画面は一致しません。ここで焦って手作業で開けてしまうと、Stripe側の利用権とアプリ側の状態という、二つの正本ができます。どうしても先に開けるなら、アプリ側の判定に「手動付与」の欄を作り、次の請求日に自動で消える形にしておくほうが安全です。なお、この「次の請求期間の開始」が、途中で請求サイクルを変えた契約や試用期間中の契約でどう振る舞うかは、参照した資料には書かれていません。断定せず、実装前に現行の資料で確認する項目として扱ってください。
Stripeは通知するだけで、開け閉めするのはアプリ側
出典に基づく事実
資料は、対応付けを済ませたあとにStripeが行うことを、顧客の契約状態に応じて、いつ提供を開始または停止すべきか、そしてどの機能についてかを通知することだと説明しています。利用権の変化を伝える仕組みとしては、顧客が契約、アップグレード、ダウングレード、解約をしたときに発火するイベントが説明されており、アプリ側はそのイベントの内容に含まれる一覧に対応する機能やサービスを有効化すべきだと記載されています。解約したとき、または支払い失敗によって契約が自動的に解約されたときは、同じイベントが再び発火し、取り消された機能はその一覧に現れなくなるため、アプリ側は対応する機能を無効化する必要があると書かれています。
出典に基づく事実
API側の手順には、この機能に対する利用権を持つ利用者について、自社のシステムで確実に提供を行うようにと書かれています。そのうえで一覧には上限があり、要約に含まれる利用権の配列は最大10件で、顧客が10件を超える有効な利用権を持つ場合は、内容に含まれるURLを使って完全な一覧を取得するようにと記載されています。また、webhookを待たずに現在の利用権を確認する取得方法も示され、その用途としてアプリの起動時、認可の確認、そしてwebhookの配送が失敗したあとの状態の突き合わせが挙げられています。資料は、解決を速くするために利用権を自社側に保持しておくことを推奨すると述べています。
A&Aの考え方
ここから、一人で運用する場合の実務的な含意が三つ出ます。第一に、契約の正本はStripe側にありますが、実際に機能を閉じるのはアプリ側なので、イベントを受け取れていない期間は「売っていないものが使える」状態が続きます。第二に、機能が10個を超えた瞬間に、イベントの内容だけを信じる実装は静かに壊れます。壊れ方は「一部の利用者の一部の機能だけが有効にならない」という、最も気づきにくい形です。機能を10個まで増やしてから直すより、増やす前にURL経由の取得を書いておくほうが安く済みます。第三に、突き合わせの経路を持っておくこと。配送の失敗は起きる前提で、起動時か日次で一覧を取り直し、自社側に保持した内容と突き合わせます。この三つは、プランを増やすより先に済ませておく作業です。
公開前に埋める六行
A&Aの考え方
以上をそのまま作業に落とすと、新しい有料プランを公開する前に埋める欄は六つになります。一つ目は、このプランで新しく売る機能キーと、その能力を一文で書いた説明。プラン名を含めないこと。二つ目は、そのキーを付ける商品の一覧。複数のプランに同じ機能が入るなら、ここで線が二本になります。三つ目は、既存契約者への反映時点。原則は次の請求期間の開始で、告知文にその一行を入れるかどうかをここで決めます。四つ目は、アプリ側が判定に使う値。機能キーの一覧であって、プラン名でも商品IDでもありません。五つ目は、機能が10件を超えたときの取得経路と、突き合わせを走らせる頻度。六つ目は、取り消し時に閉じる対象と、閉じ損ねたときに気づく方法です。
仮想例
架空の記入例を一件だけ示します。一つ目、話者分割の機能キーは音声を話者ごとに分けて書き出す能力を指す。二つ目、付ける商品は「プロ」と「年間プロ」。三つ目、既存契約者は次回請求日から反映、告知文に二行で明記。四つ目、判定は機能キーの一覧にその機能が含まれるかどうかだけを見る。五つ目、現在は機能4件のため一覧の取得のみ、10件到達前にURL経由の取得を実装、突き合わせは日次。六つ目、取り消し時は書き出し画面の当該項目を非表示にし、実行中の処理は完了まで許可、閉じ損ねは日次の突き合わせの差分で検知する。この六行は道具を使わずに書けます。埋めながら答えが出てこない欄があれば、それはまだ売れる状態になっていない、という意味です。料金表の公開は、その欄が埋まってからで遅くありません。
この記事が決めないことと、次の一歩
A&Aの考え方
限界を三つ書きます。第一に、利用権の同期はアプリ側の認可の実装を置き換えません。ここで扱ったのは「契約としてその機能を売ったかどうか」だけで、その組織の誰が管理者か、どの利用者がその操作をしてよいかは別の層の判断です。第二に、価格そのものと、その価格で買う人がいるかどうかは、この記事の範囲外です。扱ったのは、売ると決めたあとに提供できる状態をどう作るかという工程だけです。第三に、参照したStripeの顧客事例ページはStripe自身が公開した記述であり、独立した監査ではありません。そこに載っている売上や成長の数値は自社の見込みに使えるものではないため、本文では引用していません。仕様についても掲載時点のものとして扱い、実装前に現行の資料で確認してください。
A&Aの考え方
次の一歩は、いま持っている料金表を一枚開いて、プランごとの差分の行を「量」と「可否」に色分けすることです。可否の行だけを抜き出し、それぞれに能力の名前でキーを与える。この作業でキーが5個を超えたなら、判定をプラン名で書いている実装はすでに危うい状態にあります。入口の設計、つまり無料でどこまで試させるかについては、既存記事「一人開発のAIサービスで無料体験を出す前に：試せる仕事と利用上限を決める」で扱っています。顧客獲得から継続までの全体の流れは「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」にまとめています。六行の四つ目と五つ目が自社のコードで具体的にどう書かれるべきか決めきれない場合は、対象の工程を決めた開発として相談してください。
新しい有料プランは、料金表を書いた時点では完成していません。売る単位を能力の名前を付けた機能キーにし、商品との線を対応表に引き、アプリ側の判定を機能キーの一覧に置き換える。そのうえで、既存契約者への反映が次の請求期間の開始までずれることを告知文に二行で書き分け、機能が10件を超えたときの取得経路と、配送失敗に備えた日次の突き合わせを先に用意します。ここまで済んだ六行が埋まって初めて、そのプランは提供できる状態になります。ただし、その価格で買う人がいるかどうかはこの工程では分かりません。それは公開前の需要の確認として、別に扱ってください。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Entitlements (Dashboard setup)
Stripe · no date shown on page; continuously updated product documentation
確認日 2026-09-29 - Entitlements (API integration)
Stripe · no date shown on page; continuously updated product documentation
確認日 2026-09-29 - Riding the AI boom: How Lovable grew into a vibe-coding juggernaut with Stripe
Stripe · no date shown on page; text describes a November 2024 launch
確認日 2026-09-29
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-09-29