価格・package・既存顧客移行を一つの証拠系で決める

Executive Summary

• 判断すべきは「何円上げるか」ではなく、どの顧客をどの commercial state へ移すかである。 一つの現行 offer と、変更前に固定した既存顧客 cohort について、現状維持、新規だけ新価格、任意 upgrade、期限付き grandfather、更新時移行、package 再設計を比較する。新規購入率を既存顧客の更新率へ外挿しない。
• price、package、terms は別 version にする。 金額だけを変えたのか、機能・上限・support・value metric を変えたのか、契約上の権利義務を変えたのかを分離する。同時変更の結果から price elasticity や個別機能の価値を推定しない。
• provider の更新成功は顧客同意でも、入金でも、継続価値でもない。 notice → consent / choice → effective subscription → entitlement → invoice / store transaction → settled cash → renewal → maturity を一つの pricing_change_contract_id で結び、join 不能な account をゼロや成功へ丸めない。
• 最初の action は14日間の bounded rehearsal である。 test / sandbox と fully synthetic fixture で cohort 選択、表示、通知、同意、invoice preview、entitlement、失敗、remediation、成熟後採算を通す。14日では長期解約や更新への因果効果を証明できないため、live migration は別承認と実 renewal maturity を要する。

基準日: 2026-08-03
対象: recurring Web SaaS、B2B invoice subscription、Apple / Google の auto-renewable subscription を一人または小規模で運営する technical founder
判断単位: seller × channel × jurisdiction / storefront × current offer / terms / price version × pre-outcome existing-customer cohort × proposed offer / price version × migration path × effective window

この章は product、economics、計測、運用の一般教材であり、法律、税務、会計その他の個別助言ではない。既存契約を変更できるかは、当事者、B2C / B2B、契約期間、更新構造、適用法、定型約款該当性、現在の条項、過去の表示、channel、storefront、個別合意、実際の運用により変わる。live action の前に、実行日時点の一次資料と適切な専門家へ確認する。

本文の架空 account、金額、件数、期間、原価、更新、判断結果はすべて fully synthetic であり、実績、予測、benchmark、推奨 threshold ではない。日付付きの法令・行政・provider の数値は synthetic example ではなく、その確認日時点の public reference fact であるため、実行直前に再確認する。公開物や生成 AI prompt へ氏名、連絡先、住所、契約書、決済情報、credential、実 customer data を入れない。

この章は current offer から成熟後の移行結果までを受け持つ

既存章は価格変更に必要な部品を既に持つ。本章はそれらを上書きせず、exact existing cohort の commercial migrationだけを接続する。

正本	既存章が受け持つ問い	本章が追加する接続
02章	value hypothesis、value metric、plan、price validation、MRR、retention、contribution	current price から proposed price への cohort 別 migration、grandfather complexity、one-time migration cost
03章	料金・更新・取消しの透明な UX、倫理的な行動設計	reference transaction、notice、choice、support receipt を exact cohort event へ結ぶ
06章	日本の B2C 通信販売、契約、規約、表示、税の共通入口	current terms、変更根拠、notice / consent、effective date を channel・customer ごとに fail closed にする
10章	PSP / MoR / ecosystem fee と transaction contribution	Stripe / Paddle / Apple / Google が管理する subscription state と自社の commercial authority を分ける
11章	B2B agreement、quote、invoice、customer authority、renewal dossier	current agreement から proposed agreement / offer へ移る acceptance と effective evidence
19章	intervention、assignment、maturity、small-data、causal claim cap	新規 pricing test と既存 migration の分母を分け、commercial event spine を足す
21章	invoice、provider balance、refund、payout、銀行現金、reserve	price change の refund / dispute / support と成熟後 settled contribution を接続する
23章	一つの current commercial state を誰に、いつ、どの証拠で変更するか	bounded migration decision と remediation receipt

AI 原価の上昇だけで price increase は正当化されない。12章の accepted outcome と full-loaded feature cost を、顧客が反復して得る価値と本章の offer / cohort economics へ接続して初めて候補になる。sunset は値上げの別名ではなく、15章の終了責任へ渡す。

実務へ移す付属物は次の二つである。

• pricing/package/migration 14書式: decision contract、three-layer diff、cohort、authority、fairness、provider、notice / consent、reconciliation、economics、remediation、Codex handoff を複製する。
• SQLite companion: fully synthetic fixture で wrong cohort、version drift、notice / consent 短絡、provider / entitlement / invoice mismatch、未成熟 outcome、cash 昇格、未承認 expansion を fail closed にする disposable な参考実装。一つの assigned account に一つの predeclared target renewal period を置き、複数 cycle を使う場合は account ごとの排他的な maturity state へ先に還元する。

exact decision unit を変更前に凍結する

pricing_change_contract_id / contract_version は、一つの提案、一つの対象 cohort、一つの action map を結ぶ stable key である。ID が一致しても、同意、法的効力、正しい請求、銀行着金、顧客価値を証明するわけではない。

pricing_change_contract_id / contract_version:
decision owner / independent reviewer:
source snapshot checked_at / next_recheck_at:

seller / contracting entity:
channel / provider / merchant-of-record role:
jurisdiction / storefront / currency / tax-display basis:

current product / package / price / terms version:
current interval / quantity / usage meter / discount / tax behavior:
current entitlement / support / cancellation / renewal promise:

proposed product / package / price / terms version:
proposed interval / quantity / usage meter / discount / tax behavior:
proposed entitlement / support / cancellation / renewal promise:

eligible existing-customer rule frozen_at:
exclusions and reason:
migration option / effective window:
notice required / consent required / authority basis / reviewer:

comparison: frozen current-offer cohort | randomized holdout | modelled no-change scenario
primary maturity cutoff / late-event policy:
maximum unexpected charge / access loss / complaint / refund / support / cash exposure:
rollback or remediation owner:
candidate action and claim cap:

cohort は outcome 前の commercial facts で作る。channel、storefront、current product / price、terms version、billing interval、renewal window、discount、payment state、contract type を使い、変更後に「同意した人」「継続した人」「provider event が取れた人」だけへ狭めない。B2B と B2C、Web と store、月次と年次、active と grace / retry、個別契約と標準 offer は原則として別 decision unit にする。

price、package、terms を同じ「値上げ」に押し込まない

差分の主語が違えば、必要な証拠と顧客の選択も違う。 最初に三つの version diff を作る。

layer	含むもの	変更時に必要な問い	誤った短絡
PRICE	amount、currency、interval、quantity、usage rate、minimum、discount、tax presentation	同じ価値・同じ権利の対価だけが変わるか。proration と請求日はどうなるか	list price の差をそのまま realized revenue とする
PACKAGE	feature、limit、seat、storage、usage allowance、SLA、support、export、AI model / quality boundary	誰のどの job と entitlement が増減するか。value metric は同じか	機能削減を「価格据置」と呼ぶ
TERMS	契約期間、更新、解約、返金、変更条項、data / IP、責任、停止、終了	現契約へどう組み入れ、誰がいつ合意し、いつ効力が生じるか	規約URLの更新を既存顧客の合意とする

さらに PRODUCT、PRICE、PACKAGE、TERMS、NOTICE_COPY、MIGRATION_POLICY、provider configuration を別 ID / revision にする。amount を同じにして上限を下げれば economic price は上がり得る。新機能を足して金額も変えれば、観測結果は compound intervention であり、「価格だけの効果」ではない。

差分には少なくとも次を含める。

changed field / old / proposed / customer consequence:
who gains / who loses / who becomes ineligible:
current promise or evidence source:
notice / consent / re-contract review:
provider operation and test receipt:
entitlement migration and export / cancellation path:

価格は value、cost、competition の範囲で候補を作る

value-based pricing は WTP を発明する手順ではない

Hinterhuber の integrative frameworkは、customer economic value、cost-volume-profit、competitive analysis を合わせる。経済価値の一つの表現は次である。

economic value to a segment
  = cost or value of the customer's best feasible alternative
  + credible differentiating value of this offer

代替は創業者が似ていると思う競合だけではない。manual work、spreadsheet、外注、何もしない、別工程への再配置も含む。削減時間を、そのまま削減人件費と増加利益の両方へ足さない。現金支出が実際に消えるのか、空いた能力を再配置できるのか、事故確率と損失をどう見積もるのかを分け、segment と use case ごとに確認する。

この研究は industrial / B2B の概念枠組みと一事例であり、B2C SaaS の causal benchmark ではない。また、古い pricing 文献にある reference price を見えにくくする実装は採用しない。比較しにくい package 名、隠れた将来価格、永続する「通常価格」は、信頼を傷つけ、日本の表示規制とも衝突し得る。

versioning は意味のある self-selection に限定する

Varian の information-goods versioningと Mussa–Rosen の quality modelは、異なる品質・条件の menu から顧客が自己選択する second-degree price discrimination の理論的基礎を与える。ここでの discrimination は経済学上の分類であり、法的適合や属性別ターゲティングの許可を意味しない。

個人開発では、value metric、利用量、automation depth、team control、support / SLA 等、顧客 job と原価に結び付く差で version を作る。既存顧客へ不利益を気付かれにくくするための意図的な品質劣化は避ける。versioning が低 WTP 層の access を増やす場合もあれば、同じ顧客へ不必要な制約を課し welfare を下げる場合もあり、利益や厚生が必ず増えるとはいえない。

elasticity は cohort と intervention が安定したときだけ読む

Marshall の需要の弾力性を比例変化で書けば、own-price elasticity の基本形は次である。価格と数量の単位、期間、eligible population を固定する。

epsilon = proportional change in quantity / proportional change in price

通常の需要では epsilon < 0 である。小さな変化に限る revenue の一次近似は次になる。

delta revenue / revenue ~= (1 + epsilon) * (delta price / price)

Lerner の markup relationは、単一製品、微分可能な需要、利益最大化等の強い仮定の下で (price - marginal cost) / price = -1 / epsilon を結ぶ。これは SaaS の価格計算機ではない。market power、固定費、multi-product、network effect、switching cost、capacity、tax、contract、fairness、long-term retention を無視してそのまま採用しない。

before / after の account 数から elasticity を断定しない。季節、acquisition mix、競合、品質、package、terms、notice、billing failure、store policy が同時に変わる。subscription service の field experimentでも access price、usage price、retention の反応は同じではなかったが、telecom の新サービスから自社の既存 SaaS へ係数を移植できない。

list price ではなく成熟後の完全負荷後 contribution を比較する

本章の primary mature KPI は matured_realized_recurring_contribution_delta とする。

matured realized recurring contribution
  = gross provider-settled recurring consideration allocated to the eligible cohort
  - refunds / credits / disputes / chargebacks
  - PSP or store fees
  - taxes collected for others
  - variable infra / AI / data cost
  - incremental support and founder-time cost
  - allocated one-time migration and remediation cost

matured_realized_recurring_contribution_delta
  = migrated-cohort matured realized recurring contribution
  - frozen comparison or explicitly modelled no-change contribution

gross provider-settled recurring consideration は、providerがsettleした顧客対価のfee・預りtax控除前grossをauthoritative provider statementからbank movementへ照合した値である。bank cashを別の収益として足さない。net payoutしか解けずgrossと控除を一意に復元できない場合は、feeを推測して再控除せずUNKNOWNにする。

これは管理用 metric であり、会計利益、課税所得、銀行残高そのものではない。store proceeds や provider available balance を bank cash とせず、21章で payout と銀行着金を照合する。比較が modelled scenario だけなら、結果は scenario delta であって causal effect ではない。

完全架空例: current cohort 20 account、3 renewal cycle、各 cycle の settled cash 1,200円、完全負荷後 variable cost 300円とする。proposed path は17 account が各 cycle 1,500円を払い、variable cost 360円、migration / remediation が一度だけ10,000円かかると仮定する。

current = (1,200 - 300) * 20 * 3 = 54,000円
proposed = (1,500 - 360) * 17 * 3 - 10,000 = 48,140円
delta = 48,140 - 54,000 = -5,860円

ARPA は上がっても、この架空 horizon の contribution は下がる。break-even retained accounts は (54,000 + 10,000) / ((1,500 - 360) * 3) を切り上げた19 account である。この例は price、cost、retention の推奨値でも、値上げで3 account が失われる予測でもない。

migration option は一つずつ比較する

既存顧客を全員一斉に上げることを default にしない。 commercial option と evidence / safety state を分ける。

option	意味	適する可能性がある条件	主な負債・確認
KEEP_CURRENT	現行 cohort を維持	authority、価値、運用、成熟効果が不明	原価上昇、legacy support、将来の再判断日
NEW_CUSTOMERS_ONLY	新規だけ新 offer / price	新規 WTP を学び、既存契約を動かしたくない	cohort 間の価格差、sales explanation、比較期間
VOLUNTARY_UPGRADE	顧客が新しい価値を選択	新 package の追加価値が明瞭で current path も維持可能	coercion、既存機能の実質的な取り上げ、selection bias
TIME_BOUND_GRANDFATHER	旧条件を明示期間だけ維持	移行準備、予算周期、notice、data export に時間が要る	終了条件、renewal timing、support の二重運用
APPLY_AT_RENEWAL	次の契約更新で新条件へ	更新が新しい合意点となり、proration を避けたい	renewal ごとの notice / consent、年次 cohort の長い maturity
PACKAGE_REDESIGN	value metric、scope、tier を再設計	current package が customer job / cost とずれている	price-only elasticity を主張不可、entitlement migration
SUNSET_WITH_CLOSEOUT	offer を終了し責任を閉じる	維持不能で safe migration 先もない	notice、export、refund、未履行、security / retention、終了費用

grandfather は善意の無料 option ではない。複数の price、entitlement、support rule、invoice path を長く維持する operational liability である。grandfather_until / review_at / eligibility / reactivation rule / support scope / termination path を決め、永続例外を暗黙に作らない。一方、legacy complexity を減らしたいという自社都合だけで、現在の契約上の権利を消さない。

PACKAGE_REDESIGN は migration outcome でなく新 intervention version、SUNSET_WITH_CLOSEOUT は価格戦術でなく終了 action である。法的 authority、顧客安全、正しい請求を満たせない場合は commercial option の比較より先に停止する。

fairness は説明文ではなく choice と実装で作る

reference transaction と loss framing を仮説として扱う

Kahneman, Knetsch, Thaler の fairness surveyでは、直近の取引条件が reference になりやすく、利益を守るための変更と需要急増だけを利用する変更で受容評価が異なった。ただし、1980年代カナダの電話による hypothetical vignette であり、現代の日本 SaaS に同じ効果量を保証しない。

Tversky–Kahneman の reference-dependent modelは、status quo からの不利益が同程度の利益より強く作用し得ると表す。一方、Gal–Rucker の reviewは loss aversion を普遍的法則として扱うことへ異議を示す。したがって「顧客は損失を利益の何倍に感じる」と固定せず、price、失う entitlement、notice timing、選択肢、customer segment ごとの仮説として観察する。

Klemperer の switching-cost modelが扱う learning、transaction、artificial loyalty 等の摩擦は、installed base と将来競争を変える。解約UIの摩擦、data export の困難、再学習、workflow lock-in で顧客が残っても、それは value の証拠ではない。switching cost を retention moat として最大化せず、解約、export、代替比較を実際に使える状態にする。

perceived fairness の guardrail

guardrail	実装すること	避けること
reference	current と proposed の金額、周期、scope、effective date を同じ単位で示す	通貨・周期・quantity を変えて差を見えにくくする
reason	継続する価値、追加・削除される範囲、必要な trade-off を具体化する	「市場環境」だけで押し切る、cost increase を価値の証明とする
choice	維持、任意 upgrade、更新時選択、cancel / export 等の実在する選択肢を示す	notice だけ送り、実質的に拒否不能にする
reversibility	誤 cohort、誤請求、access loss の credit / refund / restore owner を置く	provider UI で不可逆だから救済不能とする
support	到達可能な窓口、期限、response owner、receipt を持つ	解約や問い合わせだけを遅くする
consistency	同じ pre-outcome rule の cohort を同じように扱い、例外理由を記録する	苦情を言った人だけ秘密の価格にする

cost pressure は候補 price の下限や説明要因にはなるが、顧客の支払意思、契約変更権限、適正表示を代替しない。顧客価値を説明することも、同意を誘導する dark pattern の許可ではない。

provider の current mechanics と commercial authority を分ける

以下は 2026-08-03 に確認した official documentation snapshot である。provider の UI、threshold、対象国、API、契約は変わる。実行直前に exact account、storefront、role、current docs を再確認する。

Stripe — new Price を作っても existing subscription は自動移行しない

Stripe Products and Pricesでは、amount を変えるとき既存 Price の unit_amount を書き換えず、新しい Price を作り、旧 Price を archive して過去取引の immutable record を保つ。これは catalog の versioning であり、既存顧客を移せるという契約判断ではない。

Change the price of existing subscriptionsで既存 subscription を置換するときは、exact subscription item ID と new Price ID を指定する。item ID を省くと新旧両方が active になり得る。price 更新時に quantity は default の 1 へ戻るため、現行 quantity を維持するなら明示する。同じ interval / interval count なら billing date は維持されるが、異なる interval への変更は変更日から新周期になり、proration や即時 invoice が生じ得る。

更新時に切り替える候補として subscription schedulesを使えるが、current phase と future phase、二種類の proration behavior、上書きされ得る属性を exact に test する。invoice previewは tax、discount、line、subscription / schedule change の見込額を invoice 作成前に計算できる。それでも preview は actual update、invoice、payment、entitlement、bank cash の証拠ではない。

Stripe は通常、new invoice の支払失敗にかかわらず subscription update を適用し得る。pending updatesは、対応する automatic collection / payment method で、支払成功時だけ変更を適用する path を提供する。失敗時の pending_update、expiry、webhook、schedule との相互作用を扱い、customer.subscription.updated 一件だけで完了にしない。

Apple — preserve と apply、notice と consent は別 state である

App Store Connect Helpでは、price increase を既存 subscriber に適用せず current price を preserve する option と、既存 subscriber へ apply する option がある。increase は storefront、顧客状態、増加幅、直近の変更等により、Apple の notice だけの場合と consent が必要な場合に分かれる。

同ページの current reference facts では、(a) any increase に consent を要する region、(b) current price の50%超かつ所定の absolute difference 超、(c) 同じ subscription で過去12か月に increase を経験、のいずれかで consent が必要とされる。2026-08-03 に確認した日本 storefront では、threshold 起因の consent は current price から50%超、かつ absolute difference が非年次800円超 / 年次8,000円超 の場合であり、800円 / 8,000円ちょうどを含めない。threshold は税・為替等で変わり得るため、storefront 別 thresholdを実行直前に再確認する。weekly / monthly / longer-than-monthly の minimum notice timing も異なり、必要期間を欠くと旧価格で追加 renewal される場合がある。

consent-required increase で顧客が同意しなければ、旧価格での最終 cycle 後に subscription が expire し得る。StoreKit price-increase statesと App Store Server Notifications V2 の notificationType=PRICE_INCREASE, subtype=PENDING | ACCEPTED、および notificationType=EXPIRED, subtype=PRICE_INCREASE を照合し、自社の email 送信を consent とみなさない。effective 後の price increase は App Store Connect 上で reverse できないため、誤りには別の price action、refund / credit、entitlement restore 等の remediation が要る。

Google Play — existing subscriber は legacy price cohort になる

Google Play の subscription guidanceでは、auto-renewing base-plan price を変えると new purchase には新価格が適用され、既存 subscriber は legacy price cohort に入る。Android Publisher API の migratePricesで legacy cohort を終えると current base-plan price へ移り、任意の中間価格へ直接移すことはできず、同じ base plan の prior cohort も終わる。

price decrease は次回 renewal から自動適用される。increase は opt-in または条件付き opt-out である。defaultのopt-in increaseは、developerがtriggerしてから7日間のdeveloper communication windowを経てGoogleの30日前通知が始まるため、current documentation上の最短effective目安は約37日後である。顧客が同意しなければ higher-price charge 前に自動 cancel される。current opt-out policy は対応国・地域、developer standing、頻度、増加幅に制約があり、同じ base plan / country-region で365日内に一度、上限は current price の50%または一日あたりUS$0.17相当の大きい方とされる。developer は少なくとも30日前に、subscription 名、current / new price、effective date、cancel 方法を含む prominent in-app notice を対応 device で示すこと等を certify する。Google 側の notice window は国・地域により minimum 30日または60日である。いずれも実際の対象cohortとConsole上のscheduleを正本にし、37日を普遍的な法定notice日数や全pathの保証値にしない。

Console が opt-out を選ばせることは、日本法や現契約の unilateral change が有効という法律判断ではない。country / region、current terms、standing、frequency、amount、in-app notice、legacy cohort、effective renewal を同じ snapshot で確認する。overlap する後続 migration により旧 migration が CANCELED になり得るため、latest authoritative state を読む。Play Billing Lab と license tester で price change を test できるが、test は live customer outcome を証明しない。

Paddle — catalog Price と subscription item の snapshot は別である

Paddle の Update a priceでは、catalog Price を PATCH /prices/{price_id} で更新できる。しかし、subscription item の complete price objectは item が subscription へ追加された時点の snapshot であり、後から同じ catalog Price を更新しても既存 item の返却 price object へ変更は反映されない。catalog の PATCH 成功を existing subscription migration とみなさない。

既存顧客を変更するときは、Update a subscriptionを subscription ID ごとに行う。items には残したい existing item を含む 完全な desired list を送る。省いた item は subscription から削除されるため、base plan だけを差し替えるつもりで addon を落とさない。billing に影響する item / next billing date の変更には proration_billing_mode を指定し、immediate、next renewal、full、prorated、do-not-bill の意味を exact scenario で選ぶ。

upgrade / downgrade guideの /subscriptions/{subscription_id}/preview は immediate_transaction / next_transaction / recurring_transaction_details を返し得るが、preview は actual subscription、transaction、payment、cash ではない。immediate collection が失敗した場合の on_payment_failure は default の prevent_change と、支払失敗でも subscription を更新する apply_change を区別する。後者を選ぶなら unpaid state と entitlement を別に reconcile し、支払成功と誤認しない。

Paddle subscription historyは、変更の action、actor、source、occurred_at、reason を時系列で取得する。history は「誰がどこから何を変えたか」の証拠であって、customer notice / consent、契約変更権限、transaction settlement、payout、bank cash、mature renewal を証明しない。catalog snapshot、subscription item、preview、update response、transaction、history を別 receipt にする。

日本 B2C は new application と existing-contract change を分ける

最終確認画面は重要だが、既存契約の変更権限を自動で作らない

特定商取引法と消費者庁の通信販売ガイドでは、通信販売の広告に価格・追加負担、支払時期・方法、提供時期、申込期間、撤回・解除、事業者情報、継続条件等の表示を求め、著しく事実と異なる表示や有利誤認を招く表示を禁じる。個人でも営利意思を持って反復継続する事業者は対象になり得る。

法12条の6と通信販売の申込み段階における表示ガイドラインは、internet で契約申込みを行う最終確認画面に、分量・期間、価格、支払、提供、申込期限、撤回・解除等を一覧性をもって表示し、申込みや条件を誤認させる表示を避けるよう求める。subscription では次を明瞭にする。

• indefinite / auto-renewal を含む期間・回数・利用可能量。
• 各回の金額と総額。無期限では、明確に目安と示した一年分等の総額表示を検討する。
• free / discount から有料へ自動移行する時期と、その後の金額。
• 支払時期・方法、提供時期。
• cancel の方法、申出期限、効果、penalty その他の不利益。
• 申込みを確定することが分かる button と、修正可能な確認工程。

配置、文字サイズ、強調、色、画面全体の impression も含めて判断される。「trial」「いつでも解約」だけを強調し、別の場所に反する条件を置かない。電話だけを cancel 方法にするなら実際につながる状態が必要である。ただし、日本で全 SaaS に「契約時と同じ方法で解約」や一律の法定 notice 日数があるとは断定しない。

最終確認画面は new application / re-contract の重要な証拠だが、それだけで current contract の unilateral change authority は生じない。existing migration では current agreement と定型約款変更を別に検討する。通信販売に一般的な無条件の cooling-off はなく、同法15条の3の8日間の返品規定をすべての digital service に適用できる「SaaS cooling-off」と説明しない。

また、電子消費者契約法による consumer の入力ミスと確認・訂正措置の論点は、特定商取引法の最終確認表示と同じ制度ではない。経済産業省の電子商取引FAQも参照し、new consent / re-contract では内容を確認して修正できる画面を持つ。一つの review screen が、表示、錯誤、既存契約変更の全論点を自動で解決するとは扱わない。

「規約を更新し通知した」だけで price increase を有効としない

民法548条の4では、定型約款の個別同意なし変更は、相手方の一般利益に適合する場合、または契約目的に反せず、必要性、内容の相当性、変更条項、その他事情に照らして合理的な場合に限られる。効力発生日を定め、変更内容と日付を適切な方法で周知する手続も必要になる。

法務省の定型約款説明は、「自社都合で変更できる」趣旨の条項があっても一方的変更を常に可能にするわけではなく、顧客影響と軽減措置等も考慮すると説明する。経済産業省の電子商取引準則は、料金引上げを合理的でないと判断されやすい変更例に挙げ、penalty なしの解除権や具体的で非濫用的な変更条項を合理性に肯定的な要素として示す。周知手続をしただけで、不合理な内容が合理的になるわけではない。

すべての website terms が定型約款になるわけでもない。該当しない場合の契約変更は、原則として当事者の合意を検討する。したがって existing B2C price increase の安全な default は、generic change clause と無反応へ依存せず、current contract / terms classification を弁護士と確認し、必要に応じて明示的な新合意、current offer の維持、任意 upgrade、適切な終了・再契約を選ぶことである。これは「すべての unilateral price increase が違法」という断定ではなく、事実ごとの authority review である。

消費者契約法10条等による不当条項の無効可能性も別に確認する。顧客の無反応を常に新条件への同意とする設計や、consumer の権利を一方的に害する条項を、template の一文で正当化しない。

reference price と総額表示を誠実にする

景品表示法は、価格その他の取引条件を実際より著しく有利と誤認させる表示を禁じる。消費者庁の価格表示ガイドラインを基に、根拠のない「通常価格」、終了しない期間限定、存在しない将来価格、比較対象の違う二重価格を使わない。

B2C にあらかじめ価格を表示する場合は、適用範囲を確認したうえで消費税法63条と国税庁の総額表示Q&Aに沿う。tax-inclusive display、invoice、見積、課税事業者の状態は同じ問いではないため、税務判断は税理士へ確認する。

安全に言えることと言えないこと

安全な限定表現	避ける断定
provider 上、この cohort に change を schedule できる	provider が許したので契約上・法律上も有効である
delivery receipt を観測した	顧客が読んだ、理解した、同意した
exact workflow で consent receipt を得た	すべての関連条項が有効で、表示・勧誘にも問題がない
current terms の変更根拠を review 中である	change clause があるので通知だけで自由に値上げできる
最終確認画面で new application の条件を示した	checkout を作れば既存契約も変更できる
current official source ではこの notice / consent path である	日本の全 subscription に同じ法定日数・同じ解約方法が必要である
通信販売に一般的 cooling-off はない	digital service は取消し・解除・返金が一切ない

notice / consent / effective / invoice / cash / renewal / maturity spine

一つの上書き status では、通知済みなのに同意なし、請求済みなのに access は旧 package、provider paid なのに銀行未着金、という矛盾を隠す。 event を append-only にし、occurred_at / recorded_at / effective_at と authoritative source を分ける。

DECISION_CONTRACT_FROZEN
  -> CURRENT_COMMERCIAL_STATE_RESOLVED
  -> AUTHORITY_AND_APPLICABILITY_REVIEWED
  -> NOTICE_APPROVED
  -> NOTICE_SENT
  -> NOTICE_DELIVERED | NOTICE_FAILED | NOTICE_UNKNOWN
  -> CONSENT_ACCEPTED | CONSENT_DECLINED | CONSENT_NOT_REQUIRED_WITH_BASIS | CONSENT_UNKNOWN
  -> PROVIDER_CHANGE_SCHEDULED
  -> PROVIDER_CHANGE_EFFECTIVE | PROVIDER_CHANGE_FAILED | PROVIDER_CHANGE_REMEDIATED
  -> ENTITLEMENT_RECONCILED | ENTITLEMENT_MISMATCH
  -> INVOICE_OR_STORE_TRANSACTION_RECORDED | NOT_APPLICABLE_WITH_BASIS
  -> PAYMENT_SETTLED_AT_PROVIDER | PAYMENT_FAILED | REFUNDED | DISPUTED
  -> BANK_CASH_RECONCILED | STORE_PAYOUT_PENDING | CASH_UNKNOWN
  -> RENEWED | EXPIRED | CANCELLED | CONTRACTED | EXPANDED
  -> VALUE_AND_SUPPORT_OUTCOME_RECORDED
  -> MATURITY_CLOSED | LATE_EVENT_REOPENED
  -> DECISION_REVIEWED

spine state	authoritative evidence の例	まだ言えないこと
notice	approved content revision、対象、provider delivery receipt	読了、理解、同意
consent / choice	exact customer / authority / terms version / timestamp の receipt、または not-required basis	法的有効性の全論点解決、価値受容
effective	Stripe subscription item、App Store renewal info、Play purchase / cohort state	entitlement、invoice、cash
entitlement	app の authoritative access snapshot と reconciliation	正しい請求、継続価値
invoice / transaction	invoice line、store transaction、renewal event	settled provider balance、銀行着金
cash	provider settlement、payout、bank movement の一意な bridge	refund / dispute 終了、会計利益
renewal outcome	renewed、expired、cancelled、contracted、contraction と reason	price change が原因という因果
maturity	predeclared cutoff 後の cash、refund、support、value、late-event policy	horizon 外の long-term retention

store billing に seller invoice が存在しない path は、偽 invoice を作らず NOT_APPLICABLE_WITH_BASIS とし、store transaction / proceeds / payout へ接続する。逆に invoice-based B2B では App Store の consent state を要求しない。N/A、UNKNOWN、0、FAILED を分ける。

stable key のほか、customer_account_id / subscription_id / provider_object_id / current_commercial_state_id / notice_id / consent_receipt_id / entitlement_snapshot_id / invoice_or_transaction_id / payout_id / bank_movement_id / maturity_snapshot_id を一意に結ぶ。PII を分析 table の join key や公開 fixture にしない。

denominator と maturity を先に契約する

eligible existing accounts
  = current commercial state と migration applicability を
    outcome 前に解決できた accounts

notice delivered rate
  = authoritative delivered receipts
    / notice-required eligible accounts

consent completion rate
  = authoritative accepted consent receipts
    / consent-required eligible accounts

effective migration rate
  = exact provider commercial state と entitlement が reconciled した accounts
    / migration-assigned eligible accounts

mature retained rate
  = maturity cutoff 後に paid / entitled / recurring-value outcome が解決した retained accounts
    / migration-assigned eligible accounts

maturity coverage
  = predeclared renewal / cash / refund-dispute / value maturity が解決した accounts
    / migration-assigned eligible accounts

delivery 不明、provider join 不明、late invoice、refund window 未終了、年次 renewal 未到来をゼロにしない。UNKNOWN と unresolved reason を残す。NOT_DUE も mature-retained denominator から落とさず、maturity coverageを併記してcoverage未完了のrateを成功判定へ昇格しない。monthly と annual を同じ calendar 14 days で mature とせず、各 renewal / refund / dispute / value cycle に必要な horizon を先に決める。

新規顧客の conversion、既存顧客の consent、effective migration、first higher-price payment、次回 renewal、成熟 retention は別 denominator である。before / after は記述に留め、price、package、terms、cohort、season、acquisition、product change を安定させた credible comparison がない限り causal elasticity と呼ばない。実験・observational comparison の claim cap は19章を正本とする。

fail-closed の decision precedence を先に置く

STOP_AND_REMEDIATE > PAUSE > UNKNOWN > KEEP_CURRENT / NEW_CUSTOMERS_ONLY / VOLUNTARY_UPGRADE > BOUNDED_MIGRATE > EXPAND_MIGRATION

この順序は売上の良い state が customer harm を相殺しないための優先度である。

• STOP_AND_REMEDIATE: wrong cohort、unexpected charge、required consent 欠落、cancel / export 不通、access loss、invoice / entitlement mismatch、重大な表示誤り、loss cap 超過がある。拡大を止め、refund / credit / restore / correction と customer support を優先する。
• PAUSE: source、contract、provider、reconciliation に変化があり、安全に continuation できない。新規 assignment を止める。
• UNKNOWN: authority、eligible denominator、maturity、cash、support cost 等が解決しない。未知をゼロとして migration しない。
• KEEP_CURRENT / NEW_CUSTOMERS_ONLY / VOLUNTARY_UPGRADE: current contract を強制移行せず、証拠を増やす bounded commercial action である。
• BOUNDED_MIGRATE: exact cohort、loss cap、remediation、maturity が閉じる範囲だけ移す。
• EXPAND_MIGRATION: prior bounded cohort が maturity を通過し、source refresh、independent review、capacity、cash、customer guardrail が揃う範囲だけ広げる。

本章と SQLite companion の next_cohort_n は NEXT_CONTRACT_PROPOSAL_ONLY である。current frozen cohort へ account や migration effect を追加する実行権限ではない。次の cohort を扱うには、新しい pricing_change_contract_id / contract_version、cohort、provider policy、path、cap、maturity chain と人の承認を作り直す。過去の EXPAND_MIGRATION receipt を production mutation へ直接渡さない。

平均 contribution が正でも、required consent failure 一件や誤請求を「許容 churn」として相殺しない。逆に complaint 一件だけで causal conclusion を作らず、事実確認と個別救済を先にする。

14日で live change ではなく migration rehearsal を閉じる

この rehearsal の目的は price elasticity や長期 churn を14日で証明することではない。一つの fully synthetic cohort と test / sandbox provider object で、変更を安全に実行・観測・救済できるかを判定する。

Day 1 — decision contract

pricing_change_contract_id / contract_version、exact decision unit、current / proposed version、comparison、claim cap、最大 customer / cash / support exposure、禁止する external action、owner、independent reviewer を固定する。

Day 2 — current commercial inventory

current product、price、package、terms、contract、discount、interval、quantity、renewal、entitlement、cancel / export、provider object を read-only で照合する。join 不能 account は UNKNOWN にする。

Day 3 — three-layer diff

PRICE / PACKAGE / TERMS の field diff と customer consequence を作る。amount-only と言いながら quantity、interval、tax、discount、scope が変わっていないか確認する。

Day 4 — law and provider applicability

B2C / B2B、jurisdiction / storefront、current terms、定型約款該当性、notice / consent、final-confirmation、tax display、Stripe / Paddle / Apple / Google の current rule を source date 付き card にする。Codex の法的分類は候補であり、人と専門家が確認する。

Day 5 — value and fairness case

best alternative、反復 accepted value、gain / loss、reference transaction、理由、選択肢、cancel / export、support を一頁にする。cost increase を customer value と取り違えない。

Day 6 — migration option and loss map

KEEP_CURRENT / NEW_CUSTOMERS_ONLY / VOLUNTARY_UPGRADE / TIME_BOUND_GRANDFATHER / APPLY_AT_RENEWAL / PACKAGE_REDESIGN / SUNSET_WITH_CLOSEOUT を比較し、wrong cohort、誤請求、同意失敗、access loss、refund、support overload の owner と cap を置く。

Day 7 — cohort dry run

fully synthetic fixture で eligible / excluded / notice-required / consent-required / renewal window を再計算する。同じ query を三回実行して deterministic か確認し、後付け cohort narrowing を禁止する。

Day 8 — notice、choice、confirmation

current / proposed price、period、scope、effective date、cancel / export、support を同じ画面で読める notice と、必要な consent / re-contract / final-confirmation artifact を作る。delivery、read、consent を別 receipt にする。

Day 9 — provider test / sandbox

Stripe invoice preview / schedule / pending update、Paddle subscription preview / update failure、Apple sandbox / server notification、Play Billing Lab 等、該当 path だけを test する。production credential、live customer、実 email、live price / entitlement を変更しない。

Day 10 — end-to-end reconciliation

notice から provider effective、entitlement、invoice / store transaction、settlement、payout / bank placeholder、renewal、maturity まで一件を trace する。provider にない state を成功として補完しない。

Day 11 — synthetic mature economics and stress

price × account ではなく、refund、fee、tax、COGS、support、founder time、migration / remediation を含む matured_realized_recurring_contribution_delta を fully synthetic scenario で再計算する。retention、support、refund、provider failure を別 driver で stress する。

Day 12 — negative path and remediation

wrong item、quantity reset、double price、late consent、failed payment、entitlement mismatch、cancel failure、wrong cohort、notice correction を注入し、pause、credit / refund、restore、customer contact draft、audit receipt が閉じるか確認する。

Day 13 — independent review

owner 以外が cohort、three-layer diff、authority、copy、provider operation、reconciliation、economics、loss cap、Codex artifact を読み、未解決を UNKNOWN に戻す。

Day 14 — bounded decision

指定 precedence で STOP_AND_REMEDIATE / PAUSE / UNKNOWN / KEEP_CURRENT / NEW_CUSTOMERS_ONLY / VOLUNTARY_UPGRADE / BOUNDED_MIGRATE の一つを選ぶ。EXPAND_MIGRATION は rehearsal だけでは選ばず、実 bounded cohort が renewal maturity と independent review を通った後の別 decision にする。選ばれても NEXT_CONTRACT_PROPOSAL_ONLY であり、次の contract version の審査を省略しない。

Codex は照合と下書きを担い、commercial authority を持たない

任せやすい

• product / price / package / terms / provider snapshot の read-only inventory と version diff。
• fully synthetic fixture、cohort query、denominator、maturity、contribution 式の作成と test。
• notice、FAQ、support macro、final-confirmation、B2B amendment draft の比較案。
• Stripe / Paddle test-mode code、webhook fixture、invoice / subscription preview、Apple / Google sandbox test plan。
• event join、missing receipt、wrong quantity、double item、entitlement / invoice mismatch の検査。
• official source URL、checked_at、changed field、recheck trigger の台帳化。
• decision memo と remediation checklist の下書き。

人が承認・実行する

• customer value、最終 price、package、grandfather、loss cap、comparison、fairness の判断。
• current contract、定型約款、法令、税、notice / consent / re-contract の適用判断。
• production Stripe / Paddle / App Store Connect / Play Console、terms、entitlement、price page の変更。
• live customer の対象選定、通知送信、同意依頼、契約変更、請求、credit、refund、cancel、restore。
• complaint、vulnerable customer、access loss、dispute、法的紛争の個別対応。
• bounded migration の開始、停止、remediation、expansion。

Codex に production credential や raw customer document を渡さない。生成された法律説明、provider parameter、金額、cohort query、通知文をそのまま live にしない。source が更新された、account configuration が違う、または output が current evidence と衝突した場合は人が止める。

release 前の最終 checklist

Decision and versions

• pricing_change_contract_id / contract_version と exact decision unit がある。
• current / proposed の product、price、package、terms、provider revision を分けた。
• eligible cohort と exclusion を outcome 前に frozen した。
• new-customer conversion と existing-customer migration を別 decision にした。
• compound change から price-only elasticity を主張していない。

Authority and fairness

• channel、jurisdiction / storefront、B2C / B2B、current contract、notice / consent の applicability を current source と人が確認した。
• provider operation、customer consent、法的効力を同一視していない。
• current / proposed amount、period、scope、effective date、cancel / export、support が比較可能である。
• reference price、discount、trial、urgency、通常価格に根拠がある。
• 無反応、switching friction、問い合わせ困難を value / consent としていない。

Provider and reconciliation

• Stripe item / quantity / interval / proration、Paddle full item list / snapshot / payment-failure behavior、Apple preserve / consent state、Play legacy cohort の該当 path を sandbox で通した。
• notice、consent、effective subscription、entitlement、invoice / store transaction、cash、renewal、maturity が別 receipt である。
• N/A、UNKNOWN、0、FAILED を分け、join 不能を成功へ丸めていない。
• wrong cohort、double item、quantity reset、failed payment、access loss の remediation を rehearsal した。

Economics and decision

• primary に matured_realized_recurring_contribution_delta を置いた。
• refund、fee、tax、COGS、support、founder time、migration / remediation を一度ずつ引いた。
• invoice、provider balance、payout、bank cash、会計利益を分けた。
• monthly / annual、refund / dispute、value cycle に合う maturity cutoff がある。
• decision precedence と loss cap があり、平均利益で required-consent failure や誤請求を相殺しない。
• EXPAND_MIGRATION / next_cohort_n は NEXT_CONTRACT_PROPOSAL_ONLY で、live action は新しい contract version と独立した human approval を要求する。

Findings

pricing の最大の落とし穴は、金額ではなく state の短絡である。 catalog price、契約条件、provider subscription、entitlement、invoice、cash、renewal は別の事実である。一つでも join できなければ、値上げ成功ではなく UNKNOWN または remediation になる。

既存顧客の価格は economic variable であると同時に reference transaction である。 switching friction で残る顧客を value acceptance とみなさず、current / proposed の差、理由、choice、cancel / export、救済を実装する方が、短期 ARPA より長期の信頼と学習を守りやすい。ただし behavioral research から universal effect size は導けない。

platform は migration mechanism を提供するが、commercial authority と outcome を決めない。 Stripe の Price / schedule、Paddle の catalog snapshot / subscription item、Apple の preserve / consent、Google の legacy cohort は異なる state machine である。共通化すべきなのは API call ではなく、exact cohort、version、receipt、maturity、remediation の contract である。

Recommendations

• 一つの current offer と pre-outcome existing cohort を選び、price、package、terms を別 version にして、まず KEEP_CURRENT / NEW_CUSTOMERS_ONLY / VOLUNTARY_UPGRADE を含む migration options を比較する。
• pricing_change_contract_id で notice、consent、effective、entitlement、invoice / transaction、cash、renewal、maturity を結び、primary を matured_realized_recurring_contribution_delta にする。
• 日本 B2C の existing increase は generic change clause と無反応に依存せず、current contract / terms classification、表示、notice / consent、cancel path を current source と弁護士で review する。
• provider rule は実行直前に再取得し、Stripe は item / quantity / proration、Paddle は snapshot / full item list / on_payment_failure、Apple は preserve / consent / expiry、Google は legacy cohort / opt-in / constrained opt-out を sandbox で rehearse する。
• 14日 rehearsal は external action なしで negative path と remediation まで閉じる。live bounded cohort、renewal maturity、independent review を経るまで EXPAND_MIGRATION を選ばない。

Further Questions

• current price は明示的な temporary / introductory price だったか、それとも顧客の reference transaction になっているか。
• price だけが変わるのか、quantity、interval、discount、tax、feature、limit、support、terms も変わるのか。
• exact cohort を seller、channel、storefront、contract / terms、price、interval、renewal、discount、payment state で再現できるか。
• current contract は定型約款に当たるか。変更根拠、必要性、相当性、影響軽減、周知、個別合意を誰が確認するか。
• 顧客が反復して得る accepted value と best alternative は何か。原価上昇以外の customer case はあるか。
• preserve、任意 upgrade、更新時合意、time-bound grandfather のどれが最小の irreversible harm で学習できるか。
• provider state と app entitlement、invoice / transaction、payout、bank movement をどの ID で結べるか。
• annual cohort、refund / dispute、support、value cycle が mature する最終日はいつか。
• complaint、unexpected charge、cancel / export failure、access loss の即時 owner と cash reserve はあるか。
• どの comparison なら descriptive delta を超える主張ができ、どの confound を残すか。

Caveats

• economics と behavioral science は候補、trade-off、仮説を整理する。個別 product の価格、elasticity、churn、fairness、profit uplift を保証しない。古い産業研究や hypothetical survey の係数を現代の日本 SaaS へ移植しない。
• value-based pricing は顧客価値の全額回収や、cost increase の自動転嫁を意味しない。versioning と second-degree price discrimination も welfare、利益、法的適合、公平性を自動で保証しない。
• 日本法の適用は契約と事実で変わる。最終確認画面、notice、consent、change clause、provider workflow の一つだけで existing-contract change の有効性は確定しない。本章は弁護士・税理士等の判断を置換しない。
• Stripe、Paddle、Apple、Google の facts と threshold は2026-08-03の official documentation snapshot であり、UI、API、country / region、account standing、契約、tax / FX により変わる。実行直前に再確認する。
• matured_realized_recurring_contribution_delta は管理用 metric で、会計利益、税務所得、銀行 cash、causal effect ではない。comparison が modelled no-change なら scenario である。
• 14日 rehearsal では long-term retention、annual renewal、rare complaint / dispute、法律上の有効性、customer fairness を確定できない。実 bounded cohort と predeclared maturity、late-event policy、継続監視が必要である。