既存顧客の月額を上げるとき、通知文より先に決める三つのこと

A&Aの考え方

既存顧客の月額を上げるとき、通知文より先に決めることは三つです。一つ目は、新しい価格をいつから適用するか。二つ目は、適用日が請求期間の途中に来たとき、生じる差額をどの請求書にいつ出すか、あるいは出さないか。三つ目は、新しい価格での決済が通らなかったとき、契約を新価格に変えたままにするか、元の価格に留めるか。この三つが決まっていれば、通知文は「決まったことを伝えるだけ」の文書になります。逆にこの三つが空のまま通知すると、文面は丁寧でも、顧客ごとに違う請求書が出てから問い合わせが始まります。

A&Aの考え方

値上げの相談でまず出てくるのは、たいてい文面です。どう書けば離れないか、何パーセントまでなら許されるか。ただ、通知のあとに創業者の時間を実際に奪うのは、金額への抗議よりも「この金額は何ですか」という請求書の問い合わせと、決済が通らなかった顧客への個別対応です。前者は適用日と差額の扱いから生まれ、後者は決済失敗時の扱いを決めていないことから生まれます。どちらも文面の問題ではなく、変更をどの経路で実行するかの問題です。そして、その経路は請求の仕組み側に既に用意されています。以下では Stripe の公開ドキュメントを一次資料として、その経路が何を決めさせるのかを読みます。Stripe を使っていない場合でも、決めるべき三項目は同じです。

A&Aの考え方

この二分法は、値上げを考えるときの出発点になります。価格の変更は必ず前者、つまり顧客の請求書に金額として現れる側です。だから「通知して、管理画面で価格を差し替える」という手順は、それ自体が顧客の請求書を書き換える操作になります。A&A の読み方としては、ここで一度立ち止まる価値があります。値上げは交渉ではなく、顧客の請求書に新しい行を発生させる操作だと捉え直すと、決めるべきことが「いくら」から「どの行が、いつ、いくらで出るか」に変わります。

A&Aの考え方

この例が示しているのは、適用日が「いつから新価格か」だけでなく「差額がいくらになるか」も同時に決めてしまうという構造です。請求期間の途中で上げれば、顧客の請求書には平月には出ない二行が出ます。日本語の通知で「来月から」と書いたつもりでも、顧客の請求日が月初でなければ、その「来月」は請求期間の途中に当たります。顧客ごとに契約開始日が違えば、同じ文面を送っても請求書は顧客ごとに違う形になります。ここでの決定は、A&A の見方では二択に落ちます。次回の請求日を適用日に合わせて差額をゼロにするか、途中から適用して差額を出すと決め、その二行が出ることを先に伝えるか。どちらでもよいのですが、決めずに送ると後者になります。

A&Aの考え方

つまり「通知してから計算する」必要はありません。通知文を書く前に、顧客ごとの請求書を読み、差額の実額を確認したうえで文面を書けます。これは A&A が勧める順番です。顧客が十数件なら、一件ずつ試算しても作業そのものは短時間で済みます。ただし前提を一つ明示しておきます。出典が示すこの試算はAPI呼び出しであり、管理画面を操作して済む作業ではありません。後述する決済失敗時の経路も同じで、更新時にパラメータを渡す必要があります。つまりこの記事が勧める順番は、開発作業を伴います。自分で書かない場合は、その工数を見込んでください。そのうえで、秒単位という性質から来る落とし穴があります。試算した金額をそのまま通知文に書き、数日後に日割り基準日（proration_date）を渡さずに変更を実行すれば、顧客の請求書に出る金額は通知した数字と一致しません。一円の差でも、書いた数字と違えば問い合わせの理由になります。

A&Aの考え方

この三択は、そのまま通知文の文面に対応します。none を選ぶなら通知文は「次回のご請求から新価格です。当月の追加請求はありません」と書けます。always_invoice を選ぶなら「本日付で差額のご請求書をお送りします」と書く必要があります。create_prorations のまま放置すると、差額の項目はできるが請求のタイミングは条件次第になり、通知文に書ける確定した文が作れません。A&A の判断としては、顧客が十数件規模で全員が同条件なら none を既定にする価値があります。説明すべき数字が一つ減り、通知文が一行で済むからです。仕組みを多く使うことが目的ではありません。未払いがある顧客への戻しについては、未払いを精算してから価格変更を実施する、という順番を社内規則にしておくのが単純です。

A&Aの考え方

ここが、値上げの実務で最も見落とされる分岐だと A&A は考えます。「価格を上げる」操作と「新しい価格で支払われる」ことは別の出来事であり、既定では前者だけが起きます。カードの有効期限が切れている顧客、与信枠に余裕のない顧客は、通知に同意していても決済で止まります。そのとき既定の経路では、契約上は新価格、実際には未回収という状態が残り、巻き戻しは手作業になります。保留付き更新を選べば、支払いが失敗した通常の場合は「元の価格のまま、変更は保留」という状態に揃います。ただし出典は、停止中のサブスクリプションを再開する試行では支払いが成功しなくても保留付き更新が適用されると明記しているので、「必ず元の価格に留まる」とは言えません。そして猶予は最長 23 時間、請求期間の終わりが近ければそれより短いため、これは「待ってくれる仕組み」ではありません。期限内に支払方法を更新してもらうための連絡が前提になります。もう一つ実務上の罠があります。うまくいかないからといって価格変更をもう一度実行すると、その更新に items が含まれるため、出典の記述どおり保留中の更新は取り除かれます。再試行は仕組みを壊す操作になりえます。この経路を使うには更新時に payment_behavior=pending_if_incomplete を渡す必要があり、管理画面の操作では代替できません。そして自動課金以外の収納（銀行振込や請求書払い）の顧客にはこの経路自体が使えないため、別の手順を用意する必要があります。従量項目を持つサービスでは、保留が期限切れになった月の使用量が請求できなくなる点も、値上げの実行日を選ぶ理由になります。

A&Aの考え方

この事例を「成功例として真似する」材料として読むと誤ります。同ページが掲げる ARR 4 億ドルや毎月 460 万クレジットという数字は、一人や少人数の会社の予測には使えません。A&A がこの事例から取り出すのは別の点です。すでに有料顧客がいる状態で、課金方式そのものを足す変更が実際に行われており、それが請求の仕組み側の作業として記述されているという事実です。この順番は、値上げでも同じです。先に方式と経路を決め、そのうえで顧客に伝える。ただし転移しない範囲を明確にしておきます。同ページは新しい製品のための従量課金の追加を述べたもので、既存顧客の価格引き上げ、途中期間の日割り、決済失敗時の扱いについては何も書いていません。この節が支えているのは「稼働中の課金を変える作業が請求の仕組み側の設計として扱われている」という一点だけです。ベンダーが 2 週間と述べているのは実装の期間であって、顧客への説明や移行の合意に要する期間ではありません。小さな会社ではむしろ後者が長くなります。

A&Aの考え方

ここまでの内容を、通知文を書く前に埋める表にします。左の列が決める項目、中央が決めないまま通知した場合に起きること、右が通知文に書ける形です。右の列まで埋まって初めて、通知文を書き始められます。逆に言えば、右の列が書けないなら、それは文面の問題ではなく決定が済んでいないということです。

A&Aの考え方

この記事は、いくらに上げるべきか、値上げが妥当かを判断しません。一次資料である Stripe のドキュメントは、価格の妥当性について何も述べていません。A&A も適正価格の目安を示さず、値上げによる解約率や受注への影響を示しません。そうした数値を当社は測っていません。契約上の通知義務、通知期間、取引条件の変更に関する取り扱いは、顧客との契約と適用される法令に依存します。本記事は業務設計の範囲にとどまり、法的な可否を判断するものではありません。

A&Aの考え方

仕様面の限界も明示します。引用した挙動はいずれも 2026 年 10 月 4 日に閲覧した時点の記述です。保留付き更新の対応属性、最長 23 時間という期限、日割りの既定値はいずれも変わりうるため、実装の直前に原文を読み直してください。決済代行として Stripe を使っていない場合、同じ経路があるとは限りません。手作業で請求書を発行している場合、「支払い成功を条件に価格変更を有効化する」という仕組みは存在せず、同じ結果を得るには社内の手順として運用するしかありません。また、顧客数が少なく全員が同条件なら、日割りを作らず次回請求から新価格にし、差額の説明を省く方が総手間が小さい場合があります。仕組みを多く使うことが目的ではなく、通知後の個別対応を減らすことが目的です。