プランのダウングレードUX：適用時期・上限・既存の作業を伝える

プランのダウングレードは、すでに業務で使っているものに対して、何ができるかを変えます。料金が下がることと、使えなくなる機能の一覧を示すだけでは不十分です。確定する前に、いつ切り替わるのか、既存のデータやプロジェクトはどうなるのか、どの操作が使えなくなるのか、アカウントの管理者が何を取り消せるのかを説明します。

確認画面を閉じたあとも、それらの説明を参照できるようにします。翌日ワークスペースに戻った人が、古いメールを探したり、失敗する操作を試したりしなくても、変更を予約した状態なのか、すでに下位プランが適用された状態なのかを区別できることが大切です。

画面を作る前に、ダウングレードの条件を定義する

GitHubのダウングレード手順（英語）では、個人・組織アカウントの利用者に、次の請求日から使えなくなる機能の確認を求めています。ProからFreeへ移ると、非公開リポジトリで高度なコードレビュー機能が使えなくなるなど、具体的な影響も示されています。設計で参考になるのは、この具体性です。新しいプラン名だけでなく、どの作業に影響するかを説明しましょう。ただし、GitHubのリソースの扱いを、別の製品のルールとしてそのまま使うことはできません。

以下では、架空のプロジェクト管理アプリと、Harborというワークスペースを例にします。請求管理者のDanaは、2026年10月20日にStudioからCoreへの変更を予約します。切り替わるのは次の請求期間の開始時点、2026年11月1日00:00 UTCです。これらのプラン、日付、上限、ルールは、説明用のこの例だけのものです。

Harborには、ウェブサイト、モバイルアプリ、顧客ポータル、サポートセンター、ブランドライブラリの5件のアクティブなプロジェクトがあります。Coreでは、プロジェクトの新規作成・複製・復元に、アクティブなプロジェクト3件という上限が適用されます。すでにその上限を超えているプロジェクトは、従来の権限の範囲で引き続き閲覧・編集できます。ダウングレード自体によって削除もアーカイブもされません。アーカイブしたプロジェクトはアクティブ件数に含まず、復元すると件数が増えます。

請求を管理する権限と、プロジェクトの権限を分ける

この例では、請求管理者がプラン変更を予約し、適用前の予約を取り消せます。ただし、その役割だけでプロジェクトの内容を開いたり、アーカイブしたりできるわけではありません。ほかの役割も、同じように明確に定義します。

Danaには利用量の合計を示しつつ、閲覧が制限されたプロジェクトの名前は開示しません。一覧に含められるのは、Danaが見る権限を持つタイトルだけです。プランの上限に阻まれた編集者に必要なのは、理由と、権限を持つ相手への連絡先であり、操作できる請求管理ボタンではありません。下位プランによる制限と権限の不足は、操作が使えない別々の理由です。

確定した時点と、切り替わる時点を分ける

Stripeのカスタマーポータル設定（英語）では、期間終了時のダウングレードは任意の設定であり、その設定のデフォルトは即時の更新です。期間終了時に変更するオプションは、同じ商品の価格間での変更に適用されます。これは、切り替え時期が設定によって変わることを示す例であり、すべてのサブスクリプションが更新日までダウングレードを待つというルールではありません。

Harborの確認操作は、「11月1日からのCoreへの変更を予約」とし、正確な時刻とタイムゾーンを添えます。それまではStudioが有効であることを説明します。将来の変更に「今すぐダウングレード」と書いたり、予約直後にCoreを現在のプランとして表示したりしないようにします。

あとから参照する概要には、具体的な日付を使います。「12日後」では、メールやスクリーンショットを見返したときに情報が古くなります。本人の現地時刻も表示する場合は、そのことを明示し、保存された適用時点が、請求詳細、確認画面、通知の間で一致するようにします。ブラウザーの時計が午前0時になっただけでは、サーバーで新しいプランが適用された証拠にはなりません。

既存の作業と、新しく増やす作業を分けて説明する

「上限を2プロジェクト超えています」では件数は分かっても、その結果は分かりません。Harborの影響の概要では、閲覧、編集、アーカイブ、新規作成、復元を区別する必要があります。この例では、既存の作業への制限を意図的に緩くしています。別の製品では、異なる条件が必要かもしれません。

計算を明示します。Harborの5件のうち2件をアーカイブすると、アクティブなプロジェクトは3件になります。上限ちょうどなので、まだ新規作成はできません。さらに1件、合計3件をアーカイブすれば残りは2件となり、作成権限のある人が1件追加できます。超過分が現在2件だからといって、「2件アーカイブすれば新規作成できます」と案内してはいけません。

整理の提案を、ダウングレードを完了するための必須条件にしないようにします。この例のルールでは、Danaは5件すべてがアクティブなままでもCoreへの変更を予約できます。また、閲覧者または請求管理者という役割だけでは、新規作成の権限はありません。プラン上限の確認は、役割による権限確認に加わるものであり、それに代わるものではありません。

漠然と警告せず、何を決めるのかを確認する

最終確認には、Harbor、Studio → Core、適用時点、現在の利用量、具体的に制限される操作をまとめます。確定ボタンのそばに、「既存の5プロジェクトは、現在の権限を維持します。新規作成や復元には、アクティブなプロジェクトが3件未満である必要があります」と、結果を示します。確認していた内容を失わずに戻れる、通常の戻る導線も用意します。

Danaが確定するときに、現在のプラン、利用量、権限、予約済みの変更を再確認します。別の管理者がプランを変更したり、違う予約を入れたりしているかもしれません。事前の説明と比べて重要な影響が変わるなら、その違いを説明し、改めて判断してもらいます。ほかの人の予約を、黙って上書きしてはいけません。

リクエストを処理している間は、成功したように見せずに二重送信を防ぎます。結果が不明なら、再試行を案内する前に、ワークスペースに実際に記録された予約状態を取得します。成功メッセージで伝えるべきなのは、Danaがボタンを押したことではなく、予約が記録されたことです。

予約を見える状態に保ち、対応している範囲で取り消せるようにする

予約後の請求ページには、「現在のプラン：Studio」と「変更予約：2026年11月1日00:00 UTCからCore」の両方を表示します。プロジェクトへの主な影響も改めて示し、再訪時も同じ影響の概要を確認できるようにします。一時的なトースト通知を、将来の制限についてのワークスペースの記録の代わりにしてはいけません。

Harborでは、適用前であれば請求管理者がダウングレードの予約を取り消せます。操作名は「サブスクリプションを解約」ではなく、「ダウングレードの予約を取り消す」とします。成功したら、Studioが継続し、ダウングレードの予約が残っていないことを示します。取消リクエストと適用時点が重なった場合は、サーバーの結果を確認します。すでにCoreが有効になったあとで、取消可能だと約束してはいけません。

11月になる前に、利用量が変わることもあります。Harborのアクティブなプロジェクトが6件になったら、概要も6件に更新します。5件を現在の件数であるかのように残してはいけません。既存の作業を扱うルールは変わりませんが、新しいプロジェクトのために空きを作る作業量は変わっています。影響を受けるプロジェクト管理者に知らせる際も、権限のない相手に請求額や閲覧制限のあるプロジェクトの詳細を開示しないようにします。

制限に直面する場所で、その理由を説明する

Coreが有効になったことを確認できたら、現在のプランとして表示します。新規作成の操作のそばには、「アクティブなプロジェクトは5件です。Coreでは、アクティブ件数が3件未満のときに新規作成できます。既存の編集者は引き続き作業できます」といったメッセージが役立ちます。既存のプロジェクトは表示し続けましょう。ワークスペース全体をアップグレード要求画面で覆うと、Harborで説明したルールに反します。

その人が実行できる操作だけを案内します。プロジェクト管理者なら、自分がアーカイブできるプロジェクトを確認できます。編集者なら、適切な管理者に連絡できます。作成権限はあっても、最後の空きを別の人が先に使ってしまうことがあります。その場合は、入力済みのプロジェクト名を保持し、サーバーが作成を拒否したあとで、更新された件数を説明します。作成待ちのプロジェクトが、すでに存在するかのように見せてはいけません。

請求の変更と機能の利用権をまだ整合させている途中なら、その状態を正確に説明します。予約時刻を過ぎたという理由だけで「Core適用中」と表示したり、バックエンドで変更が確認されたあともStudioのバッジをいつまでも残したりしないようにします。どの情報を正式なプラン状態とするか、どう正常な状態に戻すかを、開発担当者と決めておきます。

機能を再び使えるようにすることと、請求を変えることを分ける

この例では、ダウングレードを予約しても即時の請求は発生せず、現在の期間分のクレジットも発行されません。Coreの継続料金は、新しい請求期間から適用されます。未払いの請求書や別途の請求が、ダウングレードによって消えるわけではありません。該当する請求見積もりを取得しましょう。税金やほかの項目で金額が変わる可能性があるのに、広告用の料金表だけから確定額を計算して約束してはいけません。

適用前なら、予約を取り消すことでStudioを維持できます。適用後にStudioへ戻るのは、新たなプラン変更であり、それ自体の価格、適用時点、必要な支払い確認があります。確定前にそれらの条件を示し、サービス側で新しい利用権が確認されてから機能を戻します。請求の履歴まで取り消せないのであれば、この操作を「元に戻す」と呼ばないようにします。

返金、クレジット、データの保持、アクセスの回復は、それぞれ別の方針の問題です。クレジットを提供する製品なら、何に充当でき、いつ適用されるかを伝える必要があります。回復を保証できない製品なら、「アップグレードすればすべて元どおり」という言葉で、その限界を隠してはいけません。決済サービスの設定だけで、ワークスペースのデータ保持方針が決まるわけではありません。

PixsoでHarborのプラン変更画面を設計する

Pixsoのファイルで、この架空アプリの3画面を作り、つなげます。Harborへの影響の事前確認、変更予約の概要、新規作成が使えない適用後のCoreワークスペースです。プロジェクト数、日付、役割、ルールの文言をそろえます。これらはキャンバス上で設計するサブスクリプション画面であり、Pixso自体の請求管理画面ではありません。

同僚にDanaの役を担当してもらい、変更を予約したあと、請求ページに戻ってもらいます。現在のプランを特定し、11月1日に何が起きるかを説明し、まだ適用されていないダウングレードだけを取り消せるでしょうか。2回目は、適用後のプロジェクト管理者の役で試します。2件をアーカイブすれば新しい1件を作れるかを尋ねましょう。その理由を聞くと、実際の上限が画面から伝わっているかが分かります。

Pixsoで、条件が伝わるプラン変更フローをデザインする →

最後に、利用件数の変更、請求管理者の権限取り消し、競合する予約、結果が不明な応答、適用時点と重なる取消をテストします。目標は、プラン変更のリクエストが成功することだけではありません。どの作業を続けられるか、特定の操作がなぜ制限されるか、自分の権限で実際に使える回復手段はどれかを、利用者が理解できることです。