Jewelry AI、サブスクリプションとクレジット

プランを解約しても、すでに保有しているクレジットは回収されません

三つの出来事が同じ疑問を呼びます。これはアカウントにすでにあるクレジットを取り上げるのか、という疑問です。ここで読み取った根拠の範囲では、どれも取り上げません。自分で行った解約は「変更なし」として分類され、決済が受け取れない場合は残高をそのままにして利用権が猶予状態へ移り、通知されただけのプラン変更は、実際に請求される更新が起きるまで何も生みません。

それぞれの出来事が動かすもの、そのままにするもの

三つの出来事に、三つの別々の答えがあります。どれにおいても、すでに付与されたクレジットが取り戻されることはありません。

自分で行った解約は「変更なし」です。
返金として分類されず、何も回収されず、すでに付与されたクレジットは残ります(apps/api/src/webhooks/revenuecat-events.ts)。
決済が受け取れない場合は、利用権が動き、クレジットは動きません。
利用権は終了ではなく猶予状態に設定され、残高は増えも減りもしません(apps/api/src/webhooks/revenuecat.service.ts)。
別途購入した消費型クレジットには、この請求イベントは当てはまりません。
猶予という考え方がそもそも存在しないため、イベントはそれに作用せず素通りします。
通知されたプラン変更の時点では、まだ何も付与されていません。
変更は記録され、付与は実際に請求される次の更新イベントに委ねられます(apps/api/src/webhooks/revenuecat.service.ts)。

自分で行う解約は停止であり、巻き戻しではありません

ストアからの通知を処理するコードでは、解約はそれが運ぶ理由に照らして調べられます。返金として分類されるのは、カスタマーサポートに帰属する解約だけです。それ以外の解約は、閑散月が近いという理由で販売者が行うごく普通の解約も含めて、すべて「変更なし」として分類されます。何も回収されず、すでに付与されたクレジットはそのままの形で残ります(apps/api/src/webhooks/revenuecat-events.ts、ソースツリー確認日 2026-08-18)。

したがって区別の全体が、たった一つのフィールドに置かれています。理由がまったく届かなければ、そのイベントは返金として評価されません。あるイベントがどのようにして別の理由ではなくその理由を運ぶことになるのかは、このページでは説明しません。返金そのものが残高に何をするのかも説明しません。それは別の問いであり、ここでは決着しません。

目の前の判断にとって役立つ部分は狭い範囲に収まります。プランを止めることと残高を失うことは同じ出来事ではなく、コードはこの二つを結び付けていません。

決済が受け取れないときに動くのは、クレジットではなく利用権です

ストアが請求上の問題を報告しても、その時点で利用が終了するわけではありません。利用権は猶予状態へ移され、残高は両方向ともそのまま置かれます。追加も削除もされません(apps/api/src/webhooks/revenuecat.service.ts)。

猶予という考え方は利用権に属するものであり、別途購入した消費型クレジットには属しません。その種類のクレジットにこの状態は存在しないため、イベントはそれに作用せず素通りします。

このページが述べないことが二つあります。その状態がどれだけ続くのか、そして利用がいつ終わるのかです。どちらも読み取った範囲に含まれていないため、ここには書きません。

プラン変更は、提供される前に通知されます

プランが変わると伝える通知は、クレジットを生みません。変更が通知された状態であり、実際の移行は次の更新イベント、つまり実際に請求が立つ側で処理されます。理由は単純で、この規則がなければ、支払われていない期間に対してクレジットを受け取ることになるからです(apps/api/src/webhooks/revenuecat.service.ts)。

何も生まないことは、破棄されることとは違います。通知は永続的な保存領域に書き込まれ、指し示す商品が解決され、結果がログに記録されます。何も付与しなかったイベントは、そもそも届かなかったイベントと区別できる状態のままです。

実務上これは、切り替えのあとに新しいクレジットが現れないことがその時点での想定どおりの結果であり、切り替えを二度通知しても付与が早まるわけではない、ということを意味します。

解約、切り替え、決済の失効の前に

各項目は、上で説明した分類のいずれかに対応しています。

  • 実際に問うている二つの問いを分ける。支払いを続けるかどうかと、保有している残高がどうなるかは別で、コードもこの二つに別々に答えます。
  • すでに解約している場合、巻き戻しが起きないことを不具合として扱わない。通常の解約の分類は「変更なし」です。
  • 決済が失敗した場合は、利用権が猶予状態にあり残高は変わっていないと考える。このページが示せない期間を前提に作業を組まない。
  • プラン変更を通知した場合は、変更が効かなかったと結論する前に次の更新を待つ。
  • 購入ボタンの下の文言は、どのクレジットが期間とともに失効し、どれが失効しないかについての製品自身の説明として読む。
  • ここに書かれたことを、返金が残高に何をするかの説明として読まない。それはこのページの外側です。

このページが止まるところ

  • 猶予状態がどれだけ続くのか、利用がいつ終わるのか。ここで読み取った情報源に期間やしきい値はありません。
  • 請求上の問題や猶予状態がどれくらいの頻度で起きるのか。頻度はコードを読んで分かる性質のものではありません。
  • 解約がどのようにして返金となる理由を運ぶことになるのか、そして返金が残高に何をするのか。
  • 有効期限の文言の背後にあるサーバー側の事実。確認できたのは、製品がストア画面でそう述べていることと、その位置です。
  • クレジットがどのように消費されるのか、どの順序で消費されるのか、残高がどう計算されるのか。それはシステムの別の部分です。
  • 年単位の契約が期間を通じてどのようにクレジットを提供するのか。読み取っておらず、主張もしません。
  • 金額、価格、プラン名、パック名、通貨。このページの情報源はいずれも裏付けていません。
  • ここで説明したロジックのバージョンが本番で動いているものかどうか。読み取ったのはソースツリーであり、デプロイではありません。

よくある質問

プランを解約すると、アカウントにすでにあるクレジットは失われますか?

解約そのものによって失われることはありません。返金として分類されるのは、ストアからの通知がカスタマーサポートに帰属させた解約だけで、それ以外の解約はすべて「変更なし」となるため、何も回収されず、すでに付与されたクレジットは残ります(apps/api/src/webhooks/revenuecat-events.ts)。返金が残高に何をするのかは別の問いであり、このページは答えません。

決済が失敗しました。利用は終了し、クレジットも取り上げられたのでしょうか?

請求上の問題の経路は、その時点で利用を終了させず、残高にも触れません。利用権は猶予状態へ移され、クレジットは追加も削除もされません(apps/api/src/webhooks/revenuecat.service.ts)。別途購入した消費型クレジットにはこの状態が存在しないため、イベントはそれを素通りします。その状態がどれだけ続くのか、利用がいつ終わるのかは、読み取った情報源に含まれていないためここには書きません。

プランを変更しましたが、クレジットが届きません。変更は失敗したのでしょうか?

変更の通知はそれ自体では何も付与しません。変更が通知され、実際の移行は次に請求される更新イベントで処理されます。これが、請求されていない期間にクレジットが発行されるのを防いでいます(apps/api/src/webhooks/revenuecat.service.ts)。通知は永続的な保存領域に書き込まれ、対象の商品が解決され、結果がログに記録されるため、何も生まなかったことで失われたものはありません。

購入ボタンの下の一文は、決まった日付にクレジットが失効するという意味ですか?

それは製品自身の文言で、サブスクリプションのクレジットは期間の終わりに失効し、別途購入したクレジットパックは失効しない、と述べています。ストア画面にその文言が存在することと位置は確認されています(apps/jewelry-mobile/src/features/purchases/store-screen.test.tsx:436)。背後の挙動はこの面では読み取っていないため、日程ではなく製品の説明として扱ってください。