ある日突然、契約しているSaaSから「プラン料金改定のお知らせ」というメールが届く。開いてみると、来月から月額料金が2割、3割と上がっている。担当者としては「高くなったから今すぐ乗り換えを検討しなければ」と反射的に思うかもしれないが、実際にはそれ以外にも選択肢がある。プランを縮小して同じサービス内でコストを抑える、機能を絞って使い続ける、あるいは今回は見送って様子を見る、という道もある。
この記事では、SaaSの値上げ通知を受け取った担当者が、パニックにならずに「乗り換え」「縮小」「継続」のどれを選ぶべきかを判断するための手順を解説する。乗り換えは一見すると分かりやすい解決策に見えるが、実際にはデータ移行・現場への再教育・契約切り替えのコストが発生し、値上げ分を回収するのに何年もかかるケースがある。逆に、プラン変更や交渉だけで十分なケースも多い。まずは焦って動く前に、自社の状況を整理することから始めたい。
値上げ通知が来たら最初にやること
値上げ通知を受け取ったとき、最初にすべきことは「乗り換え先を探す」ことではない。まず、通知の内容そのものを正確に把握することだ。
具体的には次の3点を確認する。
- 値上げ幅と時期: 何%、あるいは何円上がるのか。いつから適用されるのか。契約更新のタイミングと同時か、契約期間中の一方的な改定か
- 値上げの理由: 円安・為替影響、インフラコスト増、新機能追加に伴う価格改定など、SaaS事業者側が説明している理由
- プラン体系の変更有無: 単純な値上げなのか、プラン区分自体が変わって上位プランへの実質的な誘導になっているのか
特に3点目は見落とされやすい。SaaSの値上げは「同じプランのまま価格だけ上がる」パターンと、「旧プランが廃止されて新プランへの移行を迫られる」パターンがある。後者の場合、新プランには使っていない機能がバンドルされていて、実質的な値上げ幅が通知に書かれている数字より大きくなっていることがある。契約しているプランの詳細ページや、事業者が公開している価格改定のお知らせページを実際に開いて確認してほしい。
値上げ通知を受け取った時点でやるべきなのは「反応」ではなく「事実確認」。数字の印象だけで動くと、後述する乗り換えコストの見積もりを誤る。
事実確認が終わったら、次の段階として自社の利用実態を洗い出す作業に進む。ここを飛ばして乗り換え先の比較検討を始めてしまうと、「そもそも今のプランを使いこなせていなかった」という基本的な見落としに気づけないまま、無駄な移行作業に踏み切ってしまう。
利用実態を洗い出す: 契約プランと実際の使用量のギャップ
値上げへの対応を考える前に、自社が契約しているプランと、実際の利用状況にギャップがないかを確認する。値上げは「使っている分」に対してだけでなく、「契約している上限」に対してかかることが多いため、上限を持て余していれば、値上げ後もプランを縮小するだけで実質的な負担増を打ち消せる可能性がある。
確認すべき項目は次の通りだ。
| 確認項目 | チェック内容 |
|---|---|
| 契約プランの上限 | ユーザー数・ストレージ容量・API呼び出し回数など、契約上のキャパシティ |
| 実際の使用量 | 管理画面の利用状況レポートやダッシュボードで確認できる実数 |
| アクティブ率 | 付与されているアカウントのうち、直近1〜3ヶ月でログインしているのは何割か |
| 使っている機能範囲 | 上位プラン限定の機能を実際に使っているか、それとも下位プランでも足りるか |
多くのSaaSは管理画面に「利用状況」「アカウント管理」のようなメニューがあり、ここでアクティブユーザー数やストレージ使用率を確認できる。もし契約しているユーザー数の半分以下しかアクティブでない、あるいは容量の3割程度しか使っていないという状況なら、値上げされたプランのまま契約を続けるより先に、プランのダウングレードや不要アカウントの削減を検討したほうが早い。
この棚卸し作業自体は、契約中の全SaaSを対象に定期的に行っておくべき性質のものでもある。特に部署ごとに個別契約が発生しやすい会社では、そもそも使われていないシャドーITの契約が値上げの通知を受け取っていた、というケースも珍しくない。使っていないSaaSの見つけ方や棚卸し手順そのものについては、以下の記事で詳しく扱っている。
洗い出しの結果、「契約プランを持て余している」ことが分かれば、次に検討すべきは乗り換えではなくプランの縮小・見直しになる。
選択肢1: プランを縮小する
値上げ後のプランがオーバースペックだと分かった場合、最初に検討すべき選択肢はプランの縮小だ。乗り換えに比べて実行のハードルが低く、既存データやワークフローをそのまま維持できるという大きな利点がある。
プラン縮小で検討するパターンには次のようなものがある。
- ユーザー数を減らす: 退職者や異動者のアカウントが残ったままになっていないか確認し、不要なアカウントを削除・凍結する
- 下位プランへのダウングレード: 使っていない上位機能（高度な権限管理、外部連携、大容量ストレージなど）がある場合、それらを含まない下位プランに切り替える
- 年払いへの変更: 月払いのまま契約している場合、年払いへの切り替えで実質的な値引きが適用されるサービスもある
- アドオン・オプションの見直し: 本体プランとは別に契約しているオプション機能で、使用頻度の低いものを解約する
ダウングレードを検討する際は、下位プランで失う機能が業務に本当に不要かを、実際にその機能を使っている現場の担当者に確認してから決めることが重要だ。情シス・総務側の判断だけでプランを落とし、後から「あの機能がないと困る」と現場から苦情が来るケースは避けたい。
またプラン変更のタイミングにも注意が必要だ。契約期間の途中でダウングレードすると、日割り計算されず変更が反映されるのが次の更新月からになるサービスもある。契約書や利用規約、あるいはサポート窓口に「いつから新プランの料金が適用されるか」を確認してから手続きを進めるのが確実だ。
選択肢2: 値上げ自体を交渉する
見落とされがちだが、値上げ通知が来たからといって、その金額をそのまま受け入れる以外に道がないわけではない。契約規模や契約年数によっては、価格交渉の余地が残っていることがある。
交渉の余地が生まれやすい状況としては、次のようなものが挙げられる。
- 契約ユーザー数が多く、事業者側にとって解約されると影響の大きい顧客である
- 契約から数年が経過し、長期契約者向けの優遇や個別対応の交渉実績がある事業者である
- 競合サービスへの乗り換えを実際に検討している、あるいは相見積もりを取得済みである
- 年払いへの切り替えや、複数年契約への切り替えを引き換えに提示できる
ただし、すべてのSaaSが個別交渉に応じるわけではない。特に月額数千円〜数万円程度の小規模契約や、セルフサーブ型（営業担当が付かず、Web上で契約が完結するタイプ）のSaaSでは、価格は一律で交渉の余地がないことが多い。一方、契約金額が大きく、営業担当者や導入支援担当が付いているエンタープライズ向けの契約であれば、更新のタイミングでカスタマーサクセス担当や営業窓口に相談する価値はある。
交渉する際は、感情的に「高すぎる」と伝えるのではなく、次のような材料を用意して臨むと話が進みやすい。
交渉時に準備しておきたい材料の例
・自社の利用実績（契約年数、ユーザー数の推移、利用頻度）
・値上げ後の金額が予算やコストパフォーマンスの観点で見合わない具体的な理由
・代替サービスの候補と、それぞれのおおまかな価格帯（あくまで交渉材料であり、実際に乗り換える前提でなくてもよい）
交渉が不調に終わった場合でも、「相談した」という事実と、その際に得た回答（今回は難しいが来年度は検討するなど）は記録しておくと、翌年以降の判断材料になる。
選択肢3: 乗り換えを検討する
プランの縮小や交渉でも吸収しきれないほどの値上げ、あるいはサービス自体への不満が以前から積もっていた場合は、乗り換えの検討に進む。ただし乗り換えは、縮小や交渉に比べて桁違いにコストと時間がかかる選択肢であることを踏まえておく必要がある。
乗り換えを検討する際に見落としがちなコストには、次のようなものがある。
- データ移行の工数: 既存データを新サービスの形式に合わせて変換する作業。データが汚れている（表記ゆれや重複がある）場合はデータクレンジングが別途必要になる
- 現場の再教育コスト: 操作方法が変わることへの現場の抵抗と、教育にかかる時間
- 並行稼働期間のコスト: 完全移行までの間、旧サービスと新サービスを並行して契約する期間が発生する場合がある
- 連携先システムの見直し: 会計ソフトや他のSaaSと連携している場合、その連携設定も作り直しになる
- 契約解除に伴う違約金・返金なし規定: 契約期間中の解約で違約金が発生したり、前払い分が返金されないケースがある
これらのコストを積み上げると、値上げ幅が年間数万円〜十数万円程度であれば、乗り換えの初期コストのほうが大きくなり、数年かけてようやく元が取れる、あるいは元が取れないまま次の乗り換えを迎える、という結果になることも珍しくない。乗り換えを検討する際は「今の値上げ額」だけでなく、「乗り換え初期コスト÷値上げによる年間差額」で、何年で回収できるかという視点を持つことをおすすめする。
一方で、値上げが単なるきっかけであり、以前から機能不足・サポート品質・操作性への不満が積み重なっていたのであれば、値上げは乗り換えを実行する良いタイミングになりうる。「値上げされたから」という理由だけでなく、「以前から不満があったところに値上げが背中を押した」という整理をしておくと、社内での説明もしやすくなる。
乗り換えを決めた場合、実務としてまず必要になるのが現在のデータを取り出せるかどうかの確認だ。この点は以下の記事で詳しく扱っているので、乗り換えを決めた段階で必ず目を通しておいてほしい。
選択肢4: 何もせず今のまま契約を続ける
意外に見落とされがちだが、「今回は値上げを受け入れてそのまま使い続ける」というのも正当な選択肢の一つだ。特に次のような場合は、無理に乗り換えや縮小を急ぐ必要はない。
- 値上げ幅が小さく、乗り換えや縮小の検討にかかる工数のほうが割高になる
- 業務上不可欠なシステムで、他社サービスとの連携が深く、代替が現実的でない
- 直近で人員異動・繁忙期など、システム移行に社内リソースを割ける状況にない
ただし「今回は見送る」という判断をした場合でも、それを放置してよいわけではない。次回の更新タイミングや、次に値上げ通知が来たタイミングで再検討できるよう、判断した理由と時期を記録に残しておくことをおすすめする。稟議や社内説明が必要な会社であれば、稟議の形で「今回は継続、ただし◯年後に再評価する」という一文を残しておくと、後任者への引き継ぎ材料にもなる。
よくある値上げの理由パターンと、それぞれの対応の違い
SaaSの値上げ通知に書かれている理由によって、今後も同様の値上げが続くのか、それとも今回限りの一時的なものなのかを、ある程度推測できる。理由のパターンごとに考え方を整理しておく。
為替・インフラコスト増を理由とする値上げ
海外製のSaaSで、サーバー費用やライセンス費用がドル建てになっている場合、円安が進むと日本向けの価格改定が行われることがある。この種の値上げは事業者の一存で止められるものではないため、一度の値上げで終わらず、為替の動向次第で今後も続く可能性がある。乗り換えを検討する場合は、乗り換え先が国内製のSaaSか海外製かによって、同じ為替リスクを抱えるかどうかが変わる点も判断材料にしたい。
プラン体系の刷新を理由とする値上げ
「より分かりやすい料金体系にするため」「機能追加に伴い」といった説明とともに、旧プランが廃止され新プランへの移行が案内されるケースがある。この場合、実質的な値上げ幅は新旧プランの機能差を踏まえないと正確に把握できない。新プランに含まれる機能のうち、自社が実際に使う機能がどれだけあるかを確認し、使わない機能のためにコストを払っていないかを見極める必要がある。
インボイス制度・税制対応を理由とする値上げ
消費税の扱いや適格請求書対応のコストを理由に挙げる事業者もいる。この種の値上げは業界全体・制度全体に関わるものであるため、同業他社への乗り換えでも同様の値上げに直面する可能性が高く、乗り換えによる回避効果は薄いことが多い。
単純な価格改定（理由の説明が乏しい値上げ）
具体的な理由が明示されず「サービス品質向上のため」といった抽象的な説明にとどまる値上げもある。この場合は、事業者側の収益改善が主目的であることが多く、今後も定期的に値上げが行われる可能性を念頭に置いておいたほうがよい。過去に何度値上げがあったかを、契約時からの請求履歴やメールの通知履歴で確認しておくと、今後の見通しを立てやすくなる。
乗り換えの投資回収年数を計算する
「選択肢3: 乗り換えを検討する」で触れた回収年数の考え方を、もう少し具体的に数式化しておく。判断に迷ったときに、この計算を実際に行ってみることをおすすめする。
回収年数 = 乗り換えにかかる初期コスト ÷ (値上げ後の年間費用 - 乗り換え先の年間費用)初期コストには、データ移行にかかる外注費用や人件費（自社で対応する場合は工数×時給換算）、現場教育にかかる時間、並行稼働期間中の二重契約費用などを含める。乗り換え先の年間費用が今より安くなるとは限らない点にも注意したい。値上げを機に乗り換えを検討していても、比較検討の結果、乗り換え先のほうが総額で高くつくケースは実際にある。
- 回収年数が1年未満: 乗り換えの経済合理性は高い。ただし業務への影響度も別途評価する
- 回収年数が1〜3年程度: 契約更新サイクルや、システムの重要度と照らし合わせて判断が分かれる
- 回収年数が3年を超える、またはマイナス（乗り換え先のほうが高い）: 乗り換えより、縮小・交渉・継続を優先したほうがよいことが多い
この計算はあくまで金銭的なコストの比較であり、「使いにくさへの不満」「サポート対応の遅さ」といった数値化しにくい要素は含まれていない。数値化しにくい不満が大きい場合は、回収年数がやや長くても乗り換えに踏み切る判断もありうる。その場合は、金銭的な理由だけでなく、業務効率や従業員の負担軽減という非金銭的な効果も含めて、社内で説明できるように整理しておくとよい。
社内での説明・稟議の通し方
値上げへの対応方針が固まったら、次は上長や経営層への説明が必要になる場面が出てくる。特に乗り換えや新規契約を伴う場合、金額の規模によっては稟議が必要になる会社が多い。ITに詳しくない決裁者に向けて説明する際は、次の3点を軸に整理すると伝わりやすい。
- 現状維持した場合のコスト: 値上げを受け入れて契約を続けた場合、年間でいくらかかるか
- 対応した場合のコストと効果: 縮小・交渉・乗り換えのいずれを選んだ場合、コストがどう変化し、何年で回収できるか
- 対応しなかった場合のリスク: 何もせず放置した場合に起こりうること（コスト増だけでなく、サービス終了リスクなども含む）
決裁者は費用対効果と実行時期を重視する傾向が強いため、「なぜ今このタイミングで判断が必要なのか」（契約更新月が近い、値上げの適用日が迫っているなど）を明記しておくと、稟議が通りやすくなる。稟議書の具体的な書き方や、ITに疎い決裁者への説明の工夫については、以下の記事で扱っている。
判断フレームワーク: 4つの選択肢をどう振り分けるか
ここまで紹介した4つの選択肢を、実際にどう使い分ければよいかを整理する。
- まず利用実態の洗い出しを行い、契約プランを持て余していないかを確認する
- 持て余している場合は、プランの縮小を優先的に検討する
- 縮小しても値上げ分を吸収しきれない、または契約規模が大きい場合は、交渉の余地があるか確認する
- 交渉が不調、またはそもそも交渉の余地がない小規模契約で、かつサービス自体への不満が以前からある場合に、乗り換えを検討する
- 乗り換えの初期コストが値上げ差額に見合わない場合は、今回は契約を継続し、時期を決めて再評価する
この順番を守る理由は単純で、下に行くほど実行コストと時間が大きくなるからだ。乗り換えは「最後の手段」ではないが、「最初に検討する手段」でもない。値上げ通知が来た瞬間に乗り換え先の比較サイトを検索する前に、まず自社の契約内容と使用実態を見直す方が、結果的に早く・安く解決することが多い。
なお、この判断は担当者一人の裁量で完結する場合もあれば、金額規模によっては上長への説明やIT導入補助金の活用検討が必要になる場合もある。特に乗り換えに伴う新システムの導入費用がまとまった金額になる場合は、IT導入補助金の対象になるかどうかも合わせて確認しておくと、意思決定の材料が増える。ただし補助金は年度ごとに公募要領が変わるため、必ず最新の公募要領を確認したうえで検討してほしい。
会社の状況別に見る判断の傾向
同じ値上げ通知でも、会社の規模やシステムの位置づけによって、選びやすい選択肢の傾向は変わってくる。あくまで一般的な傾向であり、必ずこの通りにすべきという話ではないが、判断の出発点として参考にしてほしい。
従業員数が少なく、情シス担当が実質ひとりの会社
乗り換えにかかる工数を捻出しづらいため、まずはプラン縮小や不要アカウントの削除で対応できないかを優先的に検討したい。乗り換えを決断する場合も、一度にすべての業務を移行しようとせず、影響範囲の小さい部署・機能から段階的に移行するなど、自分ひとりで対応しきれる規模に作業を分割する工夫が必要になる。日々の業務と並行して大規模な移行プロジェクトを進めるのは現実的に難しいため、繁忙期を避けて計画を立てることも重要だ。
複数の部署がそれぞれ個別に契約しているSaaSの値上げ
値上げ通知が届いても、契約主体が現場部署で情シス側が把握していないケースがある。この場合、まず契約の実態（誰が契約し、誰が請求書を確認しているか）を確認することが最初のステップになる。値上げへの対応を検討する前に、そもそも全社的にどれだけの数の同種SaaSが契約されているかを棚卸しすると、統合によるコスト削減の余地が見つかることもある。
基幹業務（会計・人事・生産管理など）で使っているSaaSの値上げ
影響範囲が広く、乗り換えの失敗が業務停止に直結しやすいため、多少の値上げであれば継続を選び、乗り換えは慎重に検討する会社が多い。仮に乗り換えを決めるとしても、テスト運用期間を十分に確保し、並行稼働でリスクを抑えながら移行する進め方が現実的になる。
単機能のツール（チャット、タスク管理、名刺管理など)の値上げ
代替サービスが多く、乗り換えのハードルが比較的低い領域では、値上げをきっかけに乗り換えを検討しやすい。データ移行の規模も基幹システムに比べて小さいことが多く、回収年数の計算をしても短期間で元が取れる結果になりやすい傾向がある。
乗り換え・縮小を実行する前の最終チェックリスト
方針が固まったら、実行に移す前に次の項目を確認しておくと、着手後のトラブルを減らせる。
- [ ] 契約書・利用規約で解約時の違約金や返金規定を確認したか
- [ ] 現在のプランでの解約・縮小の申請方法と、反映されるタイミング（即時か、次回更新月かなど）を確認したか
- [ ] 乗り換える場合、データのエクスポート方法と対応形式を事前に確認したか
- [ ] 現場の利用者に対して、変更内容とスケジュールを事前に周知したか
- [ ] 連携している他のシステム・SaaSへの影響を洗い出したか
- [ ] 決裁が必要な金額規模の場合、稟議・承認を得ているか
- [ ] 今回の判断内容と理由を、システム管理台帳や記録に残したか
このチェックリストのうち、特にデータのエクスポートまわりは見落とすと取り返しがつかない項目になる。解約手続きを先に進めてしまい、後からデータが必要になって取り出せなくなるという事故は実際に起きやすい。乗り換え・縮小いずれの場合でも、データを一度手元に確保してから契約変更の手続きに進む順序を徹底したい。
特にkintoneのような基盤系SaaSの値上げは慎重に判断する
業務システムの土台として使っているkintoneのような基盤系SaaSの場合、単純な料金比較だけで乗り換え判断をするのは危険だ。基盤系SaaSは多くの業務プロセスや他システムとの連携が乗っているため、乗り換えの影響範囲が単機能のSaaSより大きくなりやすい。
kintoneのように業務の基盤として使われているサービスからの移行タイミングの見極め方については、以下の記事で詳しく解説している。値上げがきっかけであっても、実際に移行すべきかどうかの判断軸は共通しているため、あわせて参考にしてほしい。
基盤系SaaSに限らず、複数のシステムやSaaSを組み合わせて運用している会社では、1社への依存を避けて複数のベンダーに分散するマルチベンダーという考え方もある。ただし分散にはメリットだけでなくデメリットもあるため、安易に「1つに依存しているから危険」と判断せず、自社の運用体制に見合った形を検討することが望ましい。
値上げ以外の観点も含めて定期的に見直す仕組みを作る
今回のように値上げ通知をきっかけに個別のSaaSを見直すことも重要だが、本来は値上げの通知が来るたびに慌てるのではなく、定期的に契約中のSaaS全体を棚卸しする仕組みを社内に作っておくのが望ましい。
具体的には、次のような運用ルールを検討したい。
- 半年〜1年に1回、契約中の全SaaSの利用状況とコストを一覧化する棚卸しの機会を設ける
- 契約更新月をあらかじめカレンダーで管理し、更新の1〜2ヶ月前にリマインドが来るようにしておく
- 新しいSaaSを契約する際は、契約者・用途・年間費用・更新月をシステム管理台帳に記録しておく
こうした台帳の整備は、今回のような値上げ対応だけでなく、担当者の異動・退職時の引き継ぎでも役立つ。台帳の作り方については以下の記事にまとめているので、まだ整備できていない場合はあわせて取り組んでおくことをおすすめする。
値上げ通知は、担当者にとって煩わしい出来事に見えるかもしれないが、見方を変えれば「契約を見直す強制的なきっかけ」でもある。慌てて乗り換え先を探す前に、まずは自社の利用実態を確認し、縮小・交渉・乗り換え・継続の順で検討するという型を持っておけば、次に値上げ通知が届いたときも落ち着いて対応できるはずだ。
次回は、業務の基盤となっているSaaSやシステムを乗り換える際に、社内のどの部署にどんな影響が出るかを事前に洗い出す「移行影響範囲の整理」について取り上げる予定だ。乗り換えを決めた後の実務フローとして、あわせて押さえておきたいテーマになる。
