機能のサンセット：依存している顧客を解約させずに機能を廃止する方法

著者: Tracy N · 更新日: 2026年5月4日

次のようなシナリオが、単純なプロダクト上の意思決定をリテンション危機に変えてしまいます。アカウント全体の4%しか利用していない機能が、上位10社のうち3社にとっては欠かせないものである場合です。プロダクトチームはその機能のサンセットを決定します。メンテナンスコストが利用状況に見合わず、アーキテクチャ的には新しい機能の方が理にかなっており、96%のアカウントは廃止されても気づかないでしょう。紙の上ではその決定は妥当に見えます。

そして30日前の通知が送られます。CSはその週、顧客と同タイミングで初めて知ります。依存している顧客は、たまに使うだけのユーザーの4%ではありません。その機能を中心にワークフローを構築し、チームをトレーニングし、場合によってはAPIを介して統合した人たちです。さらに彼らは、契約更新ブックの中でも意味のある割合のARRを占めています。顧客はエスカレーションします。CS（カスタマーサクセス）は承認済みの説明文も、移行プレイブックも、決定がいつどのような経緯でなされたかも把握しないまま電話を受け続けます。これはリスクアカウント管理の教科書的なケースです。サンセット後に最も解約しやすいアカウントは、通知が届く前からウォッチリストに入っているべきだったアカウントと同じです。

その後に続く解約は避けられないものではありません。プロセスの失敗から生じるものです。CSの関与が遅すぎたのです。

機能が廃止される理由と、コミュニケーションにおけるその意味

機能が廃止される理由によって、CSが顧客との会話をどのように組み立てるべきかが変わります。理由を誤って伝えたり、型通りの説明をしたりすると、コミュニケーションが形式的なものになり、顧客の実際の体験から乖離してしまいます。Gartnerのプロダクト廃止フレームワークが「6M」（メッセージ、動機、意味、軽減、移行、方法）を用いているのは、廃止の理由ごとに6つの次元すべてで異なるアプローチが必要だからです。

技術的負債： 機能のメンテナンスコストが、利用状況に見合っていない場合です。正直な伝え方は「より多くの顧客のために役立つ機能を開発するため、エンジニアリングリソースを再配分しています」というものです。これは説明できる理由であり、SaaSのプロダクト経済学を理解している顧客は、率直に伝えれば納得します。

戦略的転換： プロダクトが、その機能と合わない方向へ進む場合です。顧客はプロダクトが自分たちのニーズから離れていくと感じるかもしれません。CSは戦略的方向性を、顧客が気にする観点で説明できる必要があります。最もよく使っている機能にとってその転換は何を意味するか。代わりに何が構築されるか。

統合： 新しい機能が2つの古い機能を置き換えますが、完全な1対1の置き換えではない場合です。これはCSにとって最もリスクの高いシナリオです。「より良いものを作った」というのは、個々の顧客の観点からは正しくないことが多いからです。新機能が顧客の特定のユースケースをサポートしていない場合、統合は彼らにとって損失となります。そのことは率直に伝えてください。

コンプライアンスまたはセキュリティ： 機能がリスク要因になった場合です。これは外部からの要件であり、プロダクトの方針によるものではないため、最も伝えやすい理由です。顧客はコンプライアンスを理解しています。喜ばないかもしれませんが、明確な説明があれば受け入れます。

これらの理由はそれぞれ、顧客との会話の切り出し方が異なります。「常に改善しています」という型通りのフレーズは、どのケースにも当てはまりません。しかし最悪の結果をもたらすのは、間違ったメッセージだけではありません。間違ったプロセスです。

主要データ：機能のサンセットとリテンションリスク

• Gainsightの顧客リテンション調査によると、機能廃止に関連する**B2B SaaS解約の79%**は、サンセットプロセスへのCS早期関与により防ぐことができます。
• ChurnZeroのベンチマークデータによると、90日以上前に機能廃止を通知した企業は、30日前通知の企業と比べて、影響を受けたアカウントの解約率が3.2倍低くなっています。
• Totangoのリテンション分析によると、機能サンセット時に契約更新期間内にあるアカウントは、CSMからプロアクティブな移行サポートを受けない限り、更新期間外のアカウントと比べて解約確率が2.7倍高いという結果が出ています。

ミスアライメントの失敗パターン

最悪のリテンション結果をもたらすパターンは、企業間で共通しています。これはCS・プロダクトのミスアライメントの8つの警告サインの一つでもあります。CSが顧客へのメール送信と同時にCCに入っている場合、関係性はすでにプロセスレベルで壊れています。

1. プロダクトが、CSのインプットなしにロードマップ会議でサンセットを決定する
2. 法務またはプロダクトオペレーションが廃止通知を作成する
3. メールが顧客に送られる際、CSは同時にCCに入れられる（事前ではなく）
4. CSMは承認済みの説明文もプロダクトの経緯も把握しないまま顧客からのエスカレーションを受ける
5. リスクアカウントが把握されるのは、契約更新の会話が始まってからで、30〜90日遅すぎる
6. 個々のCSMが非公式な延長対応や回避策を交渉し、誰も意図していない前例を作る

正しいプロセスはこれを完全に逆転させます。CSはサンセット決定が確定する前に関与し、外部への通知が出される前にリスクアカウントが特定され、CSMは最初の顧客会話が行われる前に承認済みの説明文でブリーフィングを受けます。

ステップ1：誰がその機能に依存しているかを特定する

このステップは、サンセットのタイムラインが設定された後ではなく、前に行うべきです。

重要な区別は、「利用」と「依存」の違いです。過去1年間に1回だけ機能を使った顧客はユーザーです。その機能を中心にワークフローを構築し、繰り返しのプロセスで使用し、またはAPIで統合した顧客は依存者です。これらはリスクプロファイルとして全く異なります。

利用データは誰が触れたかを教えてくれます。 プロダクトアナリティクスでは、過去90日間にその機能を使ったアカウント、利用頻度、利用が増えているか減っているかを確認できます。これは必要条件ですが、十分条件ではありません。

依存データは誰が外せないかを教えてくれます。 CSはプロダクトデータが示さないことを知っています。QBRでこの機能に言及した顧客、サポートチケットで問い合わせた顧客、チームをトレーニングした顧客などです。これはCSが、利用指標だけではプロダクトが把握できないサンセットの会話に持ち込むインテリジェンスです。

サンセット前のCSインプットプロセスは次のようになります。プロダクトはサンセット候補をCSリーダーシップと共有します。CSリーダーは5〜7営業日で顧客記録、QBRメモ、サポート履歴を確認し、リスク階層化されたアカウントリストを返します。ティア1（高依存・高ARR）は、メールが送られる前にCSMから個別のプロアクティブアウトリーチを受けます。ティア2（中程度の依存）は廃止通知メールを受け取り、48時間以内にCSMがフォローアップします。ティア3（依存が低い、またはない）は標準の廃止通知メールを受け取ります。サンセットのコミュニケーションが出る前に営業と共同リスクアカウントレビューを実施することで、ティア1アカウントの中に別途保護すべき拡大商談が進行中のものがないかを把握できます。

この分類は、CSが適切なデータにアクセスできる場合にのみ機能します。顧客インパクトスコアリングは、サンセットだけでなく、あらゆるプロダクト変更に最も影響を受けるアカウントを定量化する再現可能なフレームワークを構築することで、このプロセスを形式化します。

「依存」が実際に意味すること：

• その機能が、文書化された成功基準に記載されている
• 過去12ヶ月のQBRまたはヘルスチェックで言及された
• その機能を使ったAPI統合がある
• 過去90日以内にサポートチケットを提出している
• CS のヘルススコアがその機能の利用状況と相関している

ステップ2：サンセットのタイムラインを設定する

どれくらいの通知期間が十分か。正直な答えは「影響を受けるアカウントの依存度と移行の難しさによる」です。Gartnerの解約防止調査では、ソフトウェア購入者の60%が、後悔した購入決定を理由に契約をキャンセルしており、十分な通知なしに強制的な機能移行を求められることがその典型的なきっかけです。

参考となるフレームワーク：

プロダクトとCSのタイムライン調整は自然なことです。プロダクトは速く進めたい。技術的負債にはコストがかかり、廃止予定の機能を生かし続けるほど、エンジニアリングの労力が増します。CSはより時間が必要です。移行の会話には時間がかかり、高ARRのアカウントに短い移行期間を強いると解約リスクが生じます。

タイムラインの会話におけるCSのインプットは拒否権ではありません。ただし、必要なリスクシグナルです。適切な形式は「この3つのアカウントが最も解約リスクが高いと判断しています。それぞれのARR、契約更新日、移行難易度の評価がこちらです。これに基づき、30日ではなく90日の期間を推奨します」というものです。これは変化が難しいからより多くの時間を求めているのではありません。ARRを根拠にしたビジネスケースを提示しています。

廃止通知と強制終了期限の区別も重要です。廃止通知は「[日付]以降この機能は利用できなくなります」と伝えるものです。強制終了は実際の執行日です。高依存のアカウントには、廃止通知と強制終了の間に通常の通知期間以上の猶予を設けることを検討してください。一部の企業はエンタープライズアカウントに交渉による延長を提供していますが、慎重に対応する必要があります（後述のアンチパターンを参照）。

ステップ3：コミュニケーションの内容・タイミング・担当者

誰が伝えるか：

ティア1アカウント（高ARR・高依存）の場合、CSMが直接会話で伝えます。メールではなく、専用の電話です。CSMがアカウントに電話し、状況を説明した後、廃止メールが議論の書面確認として送られます。顧客はCSMと話す前にメールを見るべきではありません。

ティア2アカウントの場合、廃止メールを先に送り、48時間以内にCSMがアウトリーチします。フォローアップでのCSMの役割は、影響を理解し、移行の会話を始めることです。

ティア3アカウントの場合、廃止メールが主なコミュニケーション手段です。CSは問い合わせに対応します。

メッセージに含めること：

• 廃止される機能（内部名称ではなく、分かりやすく記載）
• 理由（平易な言葉で。上記4つの理由を参照）
• 有効日（廃止通知日と強制終了日の両方）
• 代替手段（ある場合、代替手段が同等かどうかを正直に記載）
• 利用可能な移行サポート（ドキュメント、専用セッション、API移行のためのエンジニアリングサポート）
• 質問の連絡先

メッセージに含めないこと：

• 決定が間違っていたと示唆するお詫び（「ご不便をおかけして申し訳ありません」という言葉は、顧客への共感ではなく決定への後悔を示します）
• 曖昧なタイムライン（「近い将来」では顧客が計画を立てられません。具体的な日付を伝えてください）
• 顧客が求めていない代替案の押しつけ（「新しいレポートツールもご利用いただけます！」というのは、否定的なお知らせの中でのアップセルに聞こえます）
• 企業的な楽観的フレーミング（「プラットフォームを合理化できることを嬉しく思います！」というのは、ワークフローの変更を求められている顧客には響きません）

3つのシナリオ向けコミュニケーションテンプレート：

シナリオA：直接的な代替機能がある場合の廃止 「[機能名]は[日付]に廃止されます。同じニーズに対応するため[代替機能]を開発しました。[コアユースケース]のためのより強固な基盤と考えています。[代替機能]は[具体的な方法]で[具体的な機能]を処理します。移行ドキュメントを用意しており、専用の移行セッションも対応可能です。CSMに連絡してスケジュールを調整してください。」

シナリオB：直接的な代替機能がない場合の廃止 「[機能名]は[日付]に廃止されます。この機能は単一の同等品に置き換えられません。[率直な理由の説明。] お客様の使い方に基づくと、[回避策または代替アプローチ]がコアニーズに対応できると考えます。CSMが今週連絡を取り、お客様の具体的な状況を理解し、確実に前進できる道筋を確保します。」

シナリオC：コンプライアンスまたはセキュリティによる廃止 「[機能名]は[日付]に廃止されます。この決定は[規制/セキュリティ要件]によって求められており、すべての顧客に影響します。お客様側での調整が必要なことは理解しています。[移行パス。] CSMが移行をサポートするために連絡します。」

ステップ4：移行の会話

代替機能がある場合： すべての顧客にとって代替機能の方が優れていると思い込まないでください。明示してください。「新しい機能は[X]の処理方法が異なります。多くの顧客にとっては改善ですが、移行について話す前に、お客様の具体的なワークフローを理解したいと思います。」このアプローチはより誠実であり、顧客が自分で問題を発見する前にギャップを特定するため、より良い移行結果を生みます。機能定着戦略プレイブックがここで活用できます。代替機能への移行は、一度の通知ではなく、新機能を発表するのと同じ体系的な定着アプローチを必要とします。

直接的な代替機能がない場合： CSは3つのことを提供できます。回避策のドキュメント、カスタム設定サポート、将来的に根本的なニーズに対応するかもしれないものへのロードマップの可視性です。CSが提供できないのは、適切なティアで事実として確認されていない限り、代替機能がまもなく来るという約束です。

顧客が移行パスは自分たちのユースケースに合わないと言った場合： これはCSだけの会話ではなく、プロダクトの会話です。この瞬間のCSMの役割は、具体的なギャップをキャプチャしてプロダクトにエスカレーションすることです。「[会社]の顧客は、代替品が対応していない[特定の機能]に依存しています。彼らが必要としているのはこれです。PMと30分話せますか？」製品対応、交渉によるタイムライン、文書化された回避策のどれが結果になるかはプロダクトの決定です。しかし、CSMが適切な人たちの前に持っていく役割を果たします。

ステップ5：リテンションリスク管理

レッドゾーン： サンセット機能に依存していて、かつ契約更新期間内にあるアカウントです。これらのアカウントは廃止通知が出される前にCSMから連絡を受ける必要があり、CSMは外部へのコミュニケーションが行われる前に各アカウントのリテンション計画を持っている必要があります。顧客教育はその計画の重要なレバーです。最も一般的な混乱点に対処した移行ガイドは、移行期間中のサポートエスカレーションを大幅に削減します。

リテンション計画は複雑である必要はありません。次の質問に答えられれば十分です。アカウントの移行パスは何か、タイムラインはどうか、CS側で完了まで責任を持つのは誰か、そして顧客がサンセットを理由に更新を検討しているというシグナルを出した場合のエスカレーション先はどこか。

ARR上位アカウントに関わるサンセット前にCSリーダーシップがプロダクトに持ち込むもの：

サンセットが確定する前に、CSリーダーシップはプロダクトに次の内容を提示すべきです。ARR別の影響を受ける上位10アカウントのランク付きリスト、その契約更新日、依存レベル、移行難易度の見積もりです。これは拒否権の要求ではありません。ビジネスリスクのブリーフィングです。この情報により、プロダクトチームのサンセットタイムラインと特定アカウントのカスタム対応の必要性に関するリスク計算が変わります。

交渉による延長： 特定の高ARRアカウントに標準の通知期間より長い猶予を与えることは正しい場合もあります。ただし慎重に管理する必要があります。一つの非公式な延長は、他のすべての影響を受けるアカウントがいずれ知ることになる前例を作ります。一つのアカウントに延長を認めた場合、その延長がすべてのティア1アカウントに適用されるのか、またはそのアカウントだけなのかをリーダーシップレベルで決定し、その決定を文書化してください。

リテンション結果をプロダクトにフィードバック： サンセット完了後、影響を受けたアカウントに何が起きたかを追跡してください。何件が正常に移行したか。何件が解約したか。何件が例外や交渉を必要としたか。そのデータは、プロダクトとの振り返りに入れるべきであり、次のサンセットのプロセス（適切な通知期間やCSのインプットがどれほど早く必要かなど）に反映されるべきです。HBRの顧客リテンションに関する調査は、適切な顧客を失うコストは解約指標に現れる以上に高いことがほとんどであると指摘しており、サンセット後のリテンションデータをプロダクト計画の最も価値あるインプットの一つとしています。

アンチパターン

リリースノートにサンセットを隠して誰も気づかないことを期待する。 一部の顧客は何ヶ月も気づかないかもしれません。しかし依存している顧客はすぐに気づき、事前に警告がなかったため驚かされたと感じます。気づかなかった顧客は問題ありません。気づいた顧客が通知を受けていなかった場合、それが解約リスクです。

CSが永遠にサポートしなければならないカスタム回避策を提供する。 移行の会話で、顧客の即時の問題をその特定のケースにしか機能しない回避策で解決したいという誘惑があります。その回避策はその後無期限のサポート義務になります。CSがサンセット移行で提供するいかなる回避策も、スケーラビリティについてプロダクトのレビューを受けるべきです。継続的なCSの労力が必要な場合、それは回避策ではなく、誰も合意していない恒久的な対応となります。

エンタープライズ顧客に前例を作る非公式な期限延長を行う。 「契約年度末まで残しておきます」とCSMがリテンションの電話で非公式に伝えると、プロダクトが同意していない義務が生まれ、エンジニアリングが維持しなければならず、他の顧客もいずれ知って同じことを要求します。延長はCSリーダーシップを通じて、プロダクトの明示的な承認を得る必要があります。

コミュニケーションメールでサンセットを「エキサイティングなニュース」としてフレームする。 ワークフローの変更を求められている顧客は興奮していません。「[機能]を廃止することでプラットフォームを進化させることをとても嬉しく思います」というような言葉は、ベンダーが変化をどう見るかと顧客がそれを体験する方法の乖離を示します。率直に伝えてください。ニュースはニュースです。

CS・プロダクト共同サンセットチェックリスト

サンセット決定が確定する前：

• CSが利用データを確認し、影響を受けるアカウントの依存リスク評価を返した
• 契約更新期間内のアカウントを特定しフラグを立てた
• CSリーダーシップがARR上位リスクアカウントをプロダクトに提示した
• 移行難易度に関するCSのインプットを参考にサンセットタイムラインを設定した

外部へのコミュニケーションが出る前：

• ティア1アカウントにCSMが直接会話で連絡を取った
• 承認済みコミュニケーションテンプレートが準備され、プロダクトと法務のレビューを受けた
• CSMブリーフィングが完了：すべてのCSMがサンセットの理由、移行パス、承認済みの説明文を把握している
• 移行パスを拒否するアカウントのためのエスカレーションパスが定義されている

移行期間中：

• ティア1アカウントの移行進捗についてCSとプロダクトが週次で確認している
• 移行の会話で浮上したプロダクトのギャップがプロダクトにエスカレーションされた
• エンタープライズアカウントからの延長要求はCSリーダーシップがレビューし、プロダクトの明示的な承認を得た

サンセット完了後：

• 影響を受けたすべてのアカウントのリテンション結果を文書化した
• CSとプロダクトで振り返りを実施し、うまくいったことといかなかったことを把握した
• 将来のサンセットのためのプロセス改善に合意し文書化した

顧客向け変更とリリースノートの責任者の問いはこのチェックリストと直結しています。コミュニケーション成果物の明確なオーナーシップこそが、各ステップをCSとプロダクトの隙間に落とすことなく適時に実行させるものです。そしてサンセットが未対応ニーズのより広いパターンを浮き彫りにしているアカウントには、顧客とのフィードバックループのクローズプロセスがそのインサイトを活かし、プロダクト意思決定の方法を恒久的に改善するための場所です。

5ステップ サンセットプレイブック

5ステップ サンセットプレイブックは、CS・プロダクト共同の機能廃止プロセスの5つのフェーズを体系化したものです。ステップは順番に実行され、いずれかを省略することが防げたはずのサンセット解約の最も一般的な原因となります。

ステップ1：依存関係の特定。 サンセットのタイムラインが設定される前に、CSが利用データと顧客記録を確認し、ユーザーと依存者を区別します。リスク階層化されたアカウントリストを返します。ティア1（高依存・高ARR）、ティア2（中程度の依存）、ティア3（依存が低い、またはない）。このステップは外部へのコミュニケーションが計画される前に完了している必要があります。

ステップ2：タイムライン設定。 CSとプロダクトが、依存・移行マトリクス（低依存・容易な移行は30日、高依存のAPI統合アカウントは90〜120日、重大なワークフロー依存は120日以上と交渉によるタイムライン）を用いて通知期間に合意します。CSのインプットは拒否権ではありません。ARRを根拠にしたリスクシグナルです。

ステップ3：コミュニケーション設計。 3つのシナリオ（代替あり、代替なし、コンプライアンス主導の廃止）に対応する3つの異なるテンプレート。ティア1アカウントはメール送信前にCSMとの直接会話を受けます。ティア2アカウントはメールの後、48時間以内にCSMアウトリーチを受けます。ティア3アカウントは標準メールを受け取ります。テンプレートは顧客に届く前にプロダクトと法務のレビューを受けます。

ステップ4：移行の会話。 アカウントごとの移行サポートと、移行パスが顧客の特定のユースケースをカバーしない場合の明確なエスカレーションパス。提供するいかなる回避策も、恒久的なサポート義務になる前にプロダクトのスケーラビリティレビューを受ける必要があります。

ステップ5：リテンション追跡と振り返り。 サンセット後：影響を受けたアカウントの中で正常に移行したもの、解約したもの、交渉による例外が必要だったものを文書化します。CSとプロダクトで振り返りを実施します。結果を次のサンセットのプロセスにフィードバックします。

Rework分析： 機能廃止における最も一貫したプロセスの失敗は、コミュニケーションテンプレートや通知期間ではありません。ステップ1です。依存関係の特定ステップを省略した企業は、すべての影響を受けるアカウントを同じように扱います。つまり高ARRのAPI統合アカウントが、偶発的なユーザーと同じ30日のメールを受け取ります。データは明確です。90日以上前に通知した企業は、30日前通知と比べて影響アカウントの解約率が3.2倍低くなっています（ChurnZeroベンチマークデータ）。しかし通知期間は結果の一部にすぎません。メールが届く前にCSMから直接電話を受けたアカウントは、通知期間に関わらず、メールを先に受け取ったアカウントより大幅に良いリテンション結果を示しています。ステップ1こそが、どのアカウントが電話を必要とするかを教えてくれます。それなしでは、すべてのアカウントがメールを受け取ります。

関連記事

• ロードマップを過約束せずにCSが伝える方法
• 顧客とのフィードバックループのクローズ
• 顧客向け変更の責任者（リリースノート、アプリ内）
• 「作ったのに誰も使わない」問題
• プロダクト意思決定のための顧客インパクトスコアリング
• リスクアカウント管理
• 共同リスクアカウントレビュー
• 機能定着戦略