上位プランの機能だけ頼まれたとき：開ける前に戻し方を決める
上位の機能を一社にだけ開けるかは、実装の速さではなく、あとで戻せるかで決めます。
この記事の要点
- 個別に開けるか、プランに足すか、別プランかは、戻し方で選ぶ
- 二件目までは個別に開け、誰に何を開けたかを表に書く
- プランに足すと、そのプランの既存契約者の全員に届く
- プランの側の変更が既存の契約に届くのは、次の請求期間から
目次
三択は戻し方の違いで選ぶ
A&Aの考え方
月額で続けて売っているものがあると、いつか必ず頼まれます。「上のプランのあれだけ、うちにも付けてもらえませんか」。受託の保守契約でも、自社で作ったツールのプランでも、起きることは同じです。
A&Aの考え方
そのたびに、多くの会社は自社のコードへ、その顧客だけの例外の処理を足します。例外の処理のことを、以下では分岐と書きます。誰に何を開けたのかがコードの中にしか残らないので、値上げも機能の廃止も切り出せなくなります。
A&Aの考え方
選べる道は三つあります。自社のコードに分岐を足して、その一社にだけ開ける。その機能をプランの定義に足す。その機能を含む別のプランを作る。
A&Aの考え方
この記事を書いている Automate & Augment (A&A) は、AIサービスの値付けと機能の構成を、設計から実装まで引き受けています。その立場から見ると、三つはたいてい「どれがいちばん速いか」で選ばれています。分岐を一行足すのがいちばん速いので、個別対応が続きます。
出典に基づく事実
決済と請求を引き受ける Stripe は、どの顧客がどの機能を使えるかを請求側で決める方法について、資料を公開しています。資料は最初の用途として、新しい値段を出すことも、変えることも、試すことも、コードを書き直さずにできる点を挙げています。
出典に基づく事実
同じ会社が公開した顧客事例に、AIとの対話でアプリやサイトを作れるサービス Lovable の話があります。同社の共同創業者は、新しい商材を足すのはずっと簡単になったと話しています。以前は独自のコードが要った作業が、今は Stripe 側の短い設定で済む、という説明です。
A&Aの考え方
足すときの手間は、どちらももう小さいということです。分岐を書くのも、請求側で機能を決めるのも、作業そのものは小さく収まります。速さで選ぼうとすると、三つのあいだに差が出ません。
A&Aの考え方
差が出るのは、戻すときです。個別に開けた一件は、自社のコードを直せば閉じられます。プランの定義に足した一件は、請求側で商品から機能を外します。別のプランを作った場合は、そのプランの販売をやめます。やめても、すでにそのプランを契約している人は、契約を変えるまで使い続けます。
A&Aの考え方
戻す手順が三つとも違うので、三択はそこから選びます。
二件目までは個別に開けて表に書く
A&Aの考え方
先に書いておくと、三択を考えるのが早すぎる段階があります。顧客が数社しかなく、何を機能と呼ぶかがまだ動いている時期です。
A&Aの考え方
この時期に請求側で機能を決めると、名前を付ける作業そのものが高くつきます。売り方がまだ固まっていないので、半年後には別の切り方をしているからです。
A&Aの考え方
A&A は、同じ依頼が三件目に来たところで線を引きます。二件目までは自社のコードで個別に開けます。そのかわり、誰に何をいつ開けたかを一枚の表に書きます。
仮想例
たとえば、社員数人でAIの文字起こしサービスを売っているとします。表の列は、顧客名、開けた機能、開けた日、元のプラン、戻す条件の五つです。行が増えるのは、依頼が来たときだけです。
A&Aの考え方
この表が効くのは、依頼を数えられるようになるからです。コードの分岐は探さないと数えられませんが、表は行数で数えられます。
A&Aの考え方
三件目が来た機能は、もう一社だけの要望ではありません。そのときに初めて、プランの定義に足すか、別のプランを作るかを考えます。
A&Aの考え方
逆に、三件目が来ない機能は個別のままで構いません。一社のために作った例外を、全員の料金表に載せる理由がないからです。
| 選ぶ道 | 届く相手と時期 | 戻すときにすること |
|---|---|---|
| 自社のコードで個別に開ける | 開けた一社だけ。コードを直した時点から | 自社のコードを直して閉じる |
| プランの定義に足す | そのプランの既存契約者の全員。次の請求期間の開始から | 請求側で、商品から機能を外す |
| その機能を含む別のプランを作る | そのプランをこれから契約する人だけ。契約した時点から | そのプランの販売をやめる。契約中の人は契約を変えるまで使える |
プランに足すと既存の全員に届く
出典に基づく事実
Stripe の資料では、ある顧客がある機能を使える状態そのものに名前が付いています。資料はこれを利用権（Entitlements）と呼びます。機能を付けた商品を顧客が買うか、契約した時点で、その顧客がその機能を使える利用権が作られる、と書かれています。
A&Aの考え方
ここに、個別対応との違いがあります。個別に開けるときの相手は一社です。機能をプランの定義に足すときの相手は、そのプランを契約している人の全員になります。
出典に基づく事実
同じ会社が公開した Lovable の事例には、公開時のプラン構成が書かれています。個人向けの無料枠と、有料枠がありました。有料枠は、上の段ほど月に使える量（クレジット）が増え、特定の機能も付く形でした。その後、チームで一緒に使えるプランや、使える上限をさらに引き上げたプランにも広げた、と書かれています。
A&Aの考え方
A&A はこの経過を、一社ごとに個別に開けるのではなく、プランを足すことで要望に応えた例だと読みます。なおこのページは、決済基盤の側が自社の顧客事例として公開したもので、外部の検証ではありません。ただしこれは、自分たちの製品を売る、A&A よりずっと大きな会社の話です。顧客が十社ほどの事業にそのまま移せるものではありません。移せるのは、使う量と使える機能を分けて考える、という点だけです。
A&Aの考え方
一社に開けたつもりが、全員への約束になります。この違いは、断る理由にもなります。「あなたにだけ開けます」と言えなくなるかわりに、「このプランに足すかどうかで検討します」と言えるようになります。
A&Aの考え方
別のプランを作る道を選ぶと、相手はもっと狭くなります。届くのは、そのプランをこれから契約する人だけです。そのかわり、料金表に行が一本増えます。
A&Aの考え方
名前の付け方には、この記事で扱わない制約があります。
出典に基づく事実
Stripe の資料によると、機能には名前と、一つずつ見分けるための識別キーを付けます。名前はあとから編集できますが、識別キーは機能を作ったあとは編集できない、と書かれています。アーカイブすれば、その識別キーは再び使えるようになるとも書かれています。
A&Aの考え方
機能の名前と識別キーの決め方は、既存記事「AI SaaSの有料プランを増やす前に：料金表と使える機能を一致させる」で書きました。
プランの側の変更は次の請求期間から届く
出典に基づく事実
Stripe の資料には、反映の時期についての注意書きがあります。すでにある契約では、商品の機能を変えても、その機能の利用権ができるのは次の請求期間の開始時だ、というものです。
A&Aの考え方
つまり「今すぐ開ける」と「プランに足す」は、別の約束です。個別に開けるなら今日から使えます。プランに足したときに既存の契約者へ届くのは、その人の次の請求期間の開始からです。
仮想例
架空の日付で言うと、毎月十日が請求日の顧客がいて、今日その機能をプランに足したとします。その顧客の画面に機能が出るのは来月の十日です。商談でその場から使わせたいなら、プランに足すだけでは間に合いません。
出典に基づく事実
やめる側の記述もあります。資料には、機能を使わない状態にしまう操作が書かれています。資料はこれをアーカイブと呼びます。しまった機能は、編集も、新しい商品への追加もできません。ただし既存の商品に付いたままなら、その機能の利用権はこれまでどおり作られる、と書かれています。しまう操作は取り消せない、とも明記されています。商品から機能を外す操作は、これとは別に用意されています。
A&Aの考え方
読み取れるのは、機能の販売をやめる判断と、すでに約束した相手から取り上げる判断が別だということです。売るのをやめても、すでに買った人の手元からは消えません。
A&Aの考え方
取り上げるには、商品から機能を外します。注意書きは、商品の機能を変えたときは次の請求期間の開始からだと書いています。だから外す操作もここに含まれると読めます。ただし、外す場合を名指しした記述はありません。断定はせず、実装の前に現行の資料で確かめる項目として扱います。
A&Aの考え方
個別に開けた一件なら、戻すときに触るのは自社のコードだけです。開けた日と戻す条件を表に書いてあれば、戻す判断もその表の上でできます。
まとめ
A&Aの考え方
一社から上位の機能を頼まれたときの三つの道は、実装の速さではなく、戻すときの手順で選びます。
A&Aの考え方
二件目までは個別に開けたままで構いません。そのかわり、誰に何をいつ開けたか、どうなったら戻すかを一枚の表に書きます。
A&Aの考え方
プランの定義に足すと、相手は一社ではなく、そのプランの既存契約者の全員になります。
A&Aの考え方
プランの側で機能を変えたとき、既存の契約に届くのは次の請求期間の開始からです。商談のその場から使わせる約束は、プランの側だけでは守れません。
上位の機能を一社にだけ求められたときの三択は、実装の速さではなく、戻すときの手順で選びます。個別に開けた一件は自社のコードを直せば閉じられ、プランの定義に足した一件は請求側で商品から機能を外し、別のプランを作った場合はそのプランの販売をやめます。二件目までは個別に開けたままで構いません。そのかわり、誰に何をいつ開けたか、どうなったら戻すかを一枚の表に書きます。プランの定義に足すと、相手は一社ではなく、そのプランの既存契約者の全員になります。プランの側で機能を変えたとき、既存の契約に届くのは次の請求期間の開始からです。商談のその場から使わせる約束は、プランの側だけでは守れません。
よくある質問
個別に開けた機能を、あとからプランの定義に足すことはできますか。
できます。順番として自然なのはそちらです。ただし足した時点から、そのプランの既存契約者にも同じ機能が届きます。届くのは各自の次の請求期間の開始からです。先に開けていた一社の分岐は、同じ機能を開ける場所が二つ残らないように、届いたことを確かめてから外します。
三件という数に根拠はありますか。
出典にはありません。A&A が、名前を付ける作業の重さと、個別の分岐を抱える重さが釣り合う所として置いた線です。顧客数が多い事業なら二件目で、作り始めたばかりなら五件目でも構いません。数そのものより、依頼を数えられる形にしておくことのほうが効きます。
受託の保守契約でも同じように考えられますか。
考え方は同じです。違うのは、請求側で機能を定義する道が使えるとは限らないことです。その場合は三択の二つ目と三つ目が、契約書の別表を直すか、別の契約の型を作るかに置き換わります。戻し方から選ぶところと、二件目までは一枚の表で持つところは変わりません。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Entitlements
Stripe · undated documentation page; no publication or update date shown
確認日 2026-10-22 - Riding the AI boom: How Lovable grew into a vibe-coding juggernaut with Stripe
Stripe · undated customer story page; no publication or update date shown
確認日 2026-10-22