SaaS値上げの実行ロードマップ｜契約更新を軸にした価格改定の進め方

SaaSの値上げ発表後に噴き出す混乱は、値上げ幅の大きさから生まれるのではありません。私たちが実施した65名調査では、金額そのものへの不満で解約に至ったのは8%にとどまる一方、説明不足・通知方法・タイミングといった伝え方の問題は解約率20〜37%に達しました（出典: SaaS値上げ、解約の引き金は「金額」ではなく「伝え方」だった）。混乱の源は「いくら上げるか」ではなく、「どの契約群から、どの移行案で、誰の承認で切り替えるか」が発表の時点で決まっていないことです。

本記事は、この未決事項をどの順で潰すかを、契約更新を軸にした実行手順として整理します。単価そのものの議論、つまり何%上げるべきかという論点はここでは扱いません。

“

あわせて読みたい

価格設定の全体像は「プライシングとは？」で整理しています。

---

私たちの立場

私たちは、価格改定に不満を持った利用者を対象にした独自調査を2本公開しています。BtoB SaaS利用者65名への調査（SaaS値上げ、解約の引き金は「金額」ではなく「伝え方」だった）と、BtoCサブスク利用者121名への調査（サブスク値上げへの不満調査）です。本記事は、その2本が示したデータを、契約更新カレンダーと移行案という実行手順に落とし込む役割を担います。

同じシリーズの「価格変更のやり方」は、値上げ幅より先に適用対象と伝え方を決めるべきだという順序論をすでに主張しています。本記事はその主張を繰り返しません。順序が決まったあとの実行段階、つまり契約群をどう分け、どの移行案を当て、発表後に何を見るかを扱います。

その上で、私は次のように考えています。年契約が混ざるBtoB SaaSの値上げは、全件を一斉に切り替えるのではなく、契約更新日を軸にした分割切替（更新日ドリブン切替）を標準形にすべきです。根拠は65名調査が示した8%対20〜37%という差です。更新日を軸にすれば、契約群ごとに個別説明の時間を確保でき、伝え方リスクが集中しやすい一斉告知を避けられます。

ただし、この立場には境界があります。月額セルフサーブが中心のBtoCサブスクでは、121名調査が示す通り、不満は継続の中で吸収されやすく（解約10.7%、継続66.1%）、一斉改定と代替プランの提示を組み合わせる方が運用が軽い場合があります。更新日ドリブン切替が効くのは、契約更新という区切りが実際に存在する商材です。区切りの薄い月額サブスクにそのまま持ち込むと、かえって管理の手間だけが増えることがあります。

この65名調査は、「値上げそのものが顧客を失う原因である」という前提を検証する目的で実施したものです（SaaS値上げ、解約の引き金は「金額」ではなく「伝え方」だった、2026年2月4日実施・有効回答65件）。結果は前提を裏切るものでした。金額そのものへの不満は怒りの強さで見ると全理由中最高（高不満以上率68.0%）でありながら、実際の解約率は8%にとどまり、60%が継続利用していました。一方、説明不足・通知方法・タイミングといった伝え方の問題は、実際の解約率が20〜37%に達していました。この差を見て以降、私たちは値上げの設計を「値上げ幅の議論」からではなく「誰に、どの順で、どう伝えるか」から始めるべきだという立場を取っています。

---

前提: 更新日ドリブン切替とGrandfatheringを定義する

以降で使う2つの言葉を、先に定義しておきます。定義があるほうが、後の主張に反論しやすくなります。

更新日ドリブン切替（⇔一斉改定）: 契約更新カレンダーをもとに契約群を分割し、群ごとに異なる説明時期と切替日を置く方式です。全契約に同じ発効日を当てる一斉改定と対になります。契約更新という区切りが実際に存在する商材でのみ機能し、区切りが薄い商材には向きません。

Grandfathering（旧条件温存）: 既存契約に旧価格・旧条件をしばらく残す移行案です。ただし、期限と切替先を決めずに残すのは設計ではなく先送りです。「いつまで残すのか」「切替時にどの案へ移るのか」の2つが揃って初めて、Grandfatheringは移行案と呼べます。

---

値上げの全体像

ガードレールの言語化、契約更新カレンダーでの対象群の分割、移行案の設計、告知、発表後の観察。5つのステップを、更新日ドリブン切替という軸で並べ直したものが上の図です。まず、この順序をなぜ先に決めておく必要があるのかを見てから、各ステップの詳細に入ります。

なぜ骨組みを先に決めるか

値上げは「いくら上げるか」から入ると、あとで契約や運用が追いつかなくなります。先に骨組みを決めておくと、社内の説明と実施順序がぶれにくくなります。

値上げ後に混乱しやすいのは、価格表そのものよりも、例外の置き方と説明のずれです。単価を決める前にこの表の4行を埋めておくと、後から個別に「なぜあの顧客だけ違う説明なのか」と聞かれる場面が減ります。

---

値上げの5ステップ

ステップ1: 改定理由とガードレールを言語化する

最初に決めるのは値上げ幅ではなく、「何を守るための改定か」です。ここが曖昧だと、値上げ後に個別交渉が増えたときに判断がぶれます。

先にそろえたい入力項目

• プランごとの粗利帯
• 利用量のばらつき
• 高工数アカウントの共通点
• 更新時に出やすい要望
• 営業がよく使う値引き理由

率を先に決めて、その率をどう正当化するかをあとから探すのは順番が逆です。先に条件を並べておけば、値上げ幅の議論はその条件から絞り込まれていきます。

ステップ2: 契約更新カレンダーで対象群を分ける

SaaSの値上げは、全件一斉よりも契約更新に沿って切り替えた方が実行しやすい場面が多くあります。特に年契約、月契約、個別見積もりが混ざる商材では、更新日ドリブン切替が欠かせません。

ここで大切なのは、対象群ごとに「いつ話すか」と「何を見せるか」を切り分けることです。更新順に沿って動けば、社内の準備が一度に爆発することもありません。

ステップ3: 移行案を3つの型で整理する

値上げ時の不満は、価格そのものより「選べる余地がない」と感じたときに強くなりがちです。移行案をいくつか持っておくと、価格改定を押し付けだけで終わらせずに済みます。

前提で定義したとおり、Grandfatheringは期限と切替先を決めて初めて移行案になります。「とりあえず旧条件のまま」で残すのは移行案ではなく先送りで、あとから誰にいつ切り替えるかを決め直す作業が発生します。

実例による検証ではなく、公開されている調査データを突き合わせて考えると、旧条件をただ長く残すことのリスクは「選べる余地」の欠如という切り口から見えてきます。次に示すBtoC121名調査のデータは、代替プラン・移行措置の有無が解約行動を最も分けた要因だったことを示しています。旧条件温存が長引くほど管理コストは積み上がりますが、その負担に見合うほど解約を防げているとは限りません。旧条件をそのまま延ばし続けるより、次に移れる代替プランを早い段階で示すほうが、Grandfathering自体の期限をはっきりさせやすいと考えられます。

移行案を複数持つことの効果は、121名調査でも裏付けられています。解約者と非解約者を分けた要因のうち、差が最も大きかったのは「代替プラン・移行措置がなかった」（+22.4pt）でした。一方、金額そのものへの不満はほぼ差がありません（-3.8pt）。選べる余地の有無が行動を分けるという構図は、BtoBの契約でも参考にできます。

ステップ4: 告知文面と社内運用をそろえる

価格改定の発表では、文面そのものよりも、窓口ごとの説明がそろっているかが重要です。メール、商談、アプリ内メッセージ、請求画面で言っていることがずれると、それだけで不信感が強まります。

文面に入れておきたい項目

1. 発効日
2. 対象となる契約群
3. 旧条件が残る場合の期限
4. プラン変更や縮小の選択肢
5. 問い合わせ窓口と社内の受け渡し先

社内でそろえたいもの

• 営業向けの説明メモ
• CS向けの会話台本
• 請求チーム向けの切替手順
• よく出る質問への短い返答集
• 例外承認の申請フォーム

65名調査では、6.2%が「請求時に初めて価格改定を知った」と回答しています。割合としては小さくても、請求という窓口で初めて知らされることは説明不足・通知方法の問題として扱われやすく、解約の引き金になりやすいカテゴリです。窓口間で言い回しがずれていないかは、発表前のロールプレイで初めて気づけることが多いものです。

ステップ5: 発表後のログを見ながら微修正する

値上げは、発表した時点では終わりません。むしろ発表後の数週間で、どこに詰まりが出るかが見えてきます。ここで見るべきなのは、単一の数値よりも、どの論点で止まっているかです。

もし私が発表後に最初に見るとしたら、問い合わせの主題と解約理由メモの2つに絞ります。65名調査で解約に効いていたのは金額そのものではなく、説明不足（実解約率20.0%）と通知方法（同37.5%、n=8のため傾向としての数字）だったためです（SaaS値上げ、解約の引き金は「金額」ではなく「伝え方」だった）。ダウングレード申請や商談メモは価格そのものへの反応を映しやすい一方、調査が示す構図をそのまま当てはめるなら、そこだけを見ていると解約の実質的な引き金を見落とすリスクがあると考えています。

発表後に見るログを決めずに始めると、声の大きい案件にだけ引っ張られやすくなります。どのログを週次で見るか、誰が更新するかまで先に決めておくと、微修正の質が上がります。あわせて、本文の表だけでは拾いきれない運用の細部が3つあります。解約理由メモは自由記述のままにせず同じ形式で残すこと。例外承認は件数の増減だけでなく中身、つまりどの条件が繰り返し出ているかを見ること。そして最初の告知で反応が薄かった契約群に対して、2回目の案内や個別説明の対象をあらかじめ決めておくことです。

---

逆に、一斉改定でよい契約構造は何か

ここまでは、更新日ドリブン切替を標準形として扱ってきました。ここで一度、材料を逆から見ておきます。更新日ドリブン切替が要らない、あるいは負担の方が大きい契約構造とはどのようなものでしょうか。

契約更新日という区切りがそもそも薄い商材はその筆頭です。月額セルフサーブが中心で、実質的にいつでも解約・変更できる契約群では、121名調査が示す通り不満があっても継続に流れやすく（継続66.1%）、更新日を軸にした分割よりも一斉改定と代替プラン（安いプラン、機能限定プランなど）の提示を組み合わせた方が運用が軽くなります。契約群の数が少なく、更新月がすでに分散している場合も、あえて分割の管理コストを払う理由は薄れます。もう一つ、ステップ1で見た承認者や値引き理由の整理ができていない状態で分割だけ導入すると、個別説明の運用が追いつかず、例外対応がかえって重くなります。

つまり、更新日ドリブン切替が効くのは、契約更新という区切りが実在し、かつその区切りごとに個別説明を運用できる体制がある場合に限られます。この条件が崩れているなら、一斉改定の方が合理的です。

もう一つ、この記事では扱わなかった問いを開けたまま残します。価格改定を毎年の定例行事にすべきかどうかです。更新順、利用量の偏り、例外承認の増え方を見ながら都度契約群を絞る今回のロードマップと、あらかじめカレンダー化して年次で回す運用は、負荷のかけ方が異なります。今のところ私は、都度絞る側に寄っていますが、実行数が増えれば判断が変わるかもしれません。

---

関連記事

SaaS値上げ、解約の引き金は「金額」ではなく「伝え方」だった｜65名不満調査レポート

本記事の土台になっている調査です。金額不満の解約率8%に対し、伝え方の問題は20〜37%。この差が、更新日ドリブン切替を勧める根拠になっています。

価格変更のやり方｜値上げ幅より先に決めるべきこと

「何%より先に、適用対象と伝え方を決める」という順序論はこちらで扱っています。本記事はその先の実行段階、つまり契約更新カレンダーと移行案の設計を担います。

サブスク値上げへの不満調査｜121名に見る継続と解約の分岐

更新日ドリブン切替が効きにくい商材の参考になる調査です。BtoCサブスクでは不満があっても66.1%が継続しており、一斉改定と代替プランの組み合わせが軽い場合があります。