毎年、更新の 60〜90 日前に同じレターが届きます。価格が上がりました。プロダクトミックスがシフトしました。検討すべき新しいエージェントティアがあります。会話は価格議論として枠づけされます。多くのレベニューリーダーはこのレターをスタートの号砲として扱います。違います。レターが届くまでに交渉はほぼ終わっています。レバレッジは前の 90 日で構築されているはずだったのに、ほとんど誰も構築しません。これが誰もやりたがらない監査であり、更新数値を意味のある形で動かす唯一のものです。
なぜ今これが重要なのか
Salesforce の価格は読みやすくなるどころか、難しくなっています。SaaStr の Jason Lemkin は昨年それをドル建てで記録しました。彼のチームは Salesforce の人間ユーザーを 10 人以上から 2 人に減らしましたが、年間請求額は約 83% 上がりました。AI エージェントが人間がかつて使っていたよりはるかにプラットフォームを使っているからです（SaaStr、2026）。シート数の行はもはや唯一重要な行ではありません。Service ライセンス、Integration プラットフォームのティア、サンドボックスアドオン、Community シート、エージェントキャパシティはすべて同じ請求書に乗っており、そのほとんどは更新と更新の合間に再スコープされません。価格だけで交渉できるディスカウントは小さい。プロダクトラインを丸ごと取り除くことで交渉できるディスカウントは違います。
更新レター問題
更新レターは設計上、価格の会話です。前年契約に対するパーセント引き上げを示し、いくつかの新しい SKU を参照し、固定ウィンドウ内での署名を求めます。それが招く会話は狭い：引き上げのうちどれだけをベンダーが返してくれるか。より広い会話、私たちは何のスコープに支払っており、まだ必要なスコープは何か、はベンダーがあなたに持ってほしくない会話です。プレ更新監査がそれを強制します。
診断はシンプルです。前年契約を 1 行ずつ見てください、Sales ライセンス、Service ライセンス、Platform ライセンス、Integration プラットフォームのティア、サンドボックスティア、Community ティア、エージェントキャパシティ、Premier サポート。各行について 2 つの問いに答えてください。誰がこれを使っているか、半分に削ったら何が変わるか。どちらの答えもわからないなら、その行は監査対象です。
シートの 3 カテゴリ：Active、Passive、Ghost
Salesforce のシート監査はユーザーライセンスを 3 つのバケットに分けます。それぞれで交渉の動きが異なるため、バケットが重要です。
Active シート
過去 30 日以内にログインし、コア機能を使い、現在の組織図上の名前付きロールに紐づいています。これらは保持するシートです。Active 数が次の契約のアンカーになります。
Passive シート
過去 90 日以内にログインしているがほとんど使っていない。読み取り専用の挙動、たまのダッシュボード閲覧、レコード作成や編集はなし。多くは Exec や Finance のシートで、Platform ライセンス、読み取り専用ライセンスにダウングレードできるか、運用上の影響なく完全に外せます。ミッドステージのインスタンスのほとんどは 15〜30% の Passive を抱えています。
Ghost シート
90 日ログインなし、退職者に割り当てられたまま、あるいはデプロビジョニングされなかったサンドボックスユーザーに割り当てられたまま。これは削減します。Ghost 数は監査の中で最も簡単な行であり、チームが自分自身に最も驚く行です。ブラウンフィールドの Salesforce インスタンスに対する真剣な監査では、有償シート数の 10% を超える Ghost 率が日常的に見つかります。
Integration プラットフォームと「残るコスト」計算
Salesforce 隣接の Integration プラットフォームのティアは、監査における最大の単一レバーであり、最も後回しにされる判断です。パターンは一貫しています。チームは 2〜3 年前に特定のインテグレーション、ERP のハンドオフ、Billing 同期、データウェアハウスのパイプ、を解決するためにそのティアを購入し、そのインテグレーションは構築されて静かに引退したか、より安い iPaaS に置き換えられたか、完成しなかったか、のいずれかです。誰もそれを残すべきかという問いを所有しなかったため、行は契約に残りました。
正しい診断は「残るコスト」の計算です。プラットフォーム上のすべてのアクティブなインテグレーションをリストアップしてください。それぞれについて、何をしているか、誰が依存しているか、よりリーンな代替（HubSpot Operations バンドル、Zapier フロー、サーバーレスインテグレーション）への移行コストを記録してください。すべてのアクティブなインテグレーションの移行コストの合計が、来年のプラットフォームティアより意味のある形で低いなら、プラットフォームはサンセット候補です。
90 日プレ更新監査プレイブック
監査は形はストレートで、ディシプリンには容赦がありません。「更新前に見る」と言うチームは決してやりません。カレンダーに 90 日ウィンドウを置くチームはやります。
3 つのワークストリームを並行で走らせます。第一にシート監査：ログインログを引き出し、すべてのユーザーライセンスを Active / Passive / Ghost フレームに対して分類し、各ダウングレードまたは削除判断に名前を付けます。第二にプロダクト監査：契約上のすべての非シート製品にオーナーをマッピングし、ユースケースを特定します。第三にインテグレーション監査：すべてのパイプ、すべての API コンシューマー、すべてのサンドボックスアドオン。アウトプットは 1 画面に収まる単一のスプレッドシートで、価格とは独立に来年欲しいスコープを正確に伝えます。
監査をスイッチ脅威として使うとき（と、使わないとき）
監査はそれ自体がレバレッジです。監査と信頼できる代替案はもっとレバレッジです。監査と空のスイッチ脅威は、監査だけよりもレバレッジが少なくなります。ベンダーのアカウントチームが脅威がパフォーマンスだと気づいた瞬間、ポジションは崩壊します。
正直なテスト：更新が変わらず返ってきたら、今年実際に移行を実行するか。Yes、HubSpot、Microsoft Dynamics、Pipedrive 移行が真にスコープされ、コスト化され、ロードマップに乗っている、なら、更新会話で名指しするのはフェアです。No なら、監査を名指しし、監査に仕事をさせてください。Harvard Business Review の強力なサプライヤーとの交渉に関する基礎的な記事は、別の言葉で同じ点を述べています。洗練されたカウンターパーティを生き残るレバレッジは、実際に行使できるものだけです（HBR、2015）。この種の会話を 1000 回回したアカウントチームに対してブラフをかけるのは、負ける取引です。
現場で見たパターン
DACH のウェルスマネジメント企業が、約 50 ユーロのシート単価上昇を伴う更新サイクルに入りました。本能はシート単価に押し返すことでした。代わりにプレ更新監査を回しました。監査は、内部でよりリーンなパイプに置き換えられて 18 か月間 1 つのインテグレーションだけを担っていた Integration プラットフォームティアを表面化させました。90 日以上人間がログインしていない 2 つの Service ライセンスを表面化させました。サポートポータルの成長とともに静かに膨れ上がった登録ユーザー単位課金の Customer Community ティア、基本的な Experience Cloud SKU 変更で再価格設定すれば数分の 1 になる、を表面化させました。それぞれは単独では大きな数字ではありません。積み重ねれば提案された引き上げより大きくなりました。再交渉された契約は、上ではなく前年の数値を下回って着地しました。会話は価格ではなく、スコープに関するものでした。監査がレバレッジでした。
解決策：プレ更新プレイブック
今後 2 四半期以内に Salesforce 更新を控えるチームへ、プレイブックは同じです。
- 90 日ウィンドウを開いてください。更新レターが届く前に監査をカレンダーに置きます。レターの後では遅すぎます。そこから先はベンダーがタイムラインを支配します。
- ログインログを引き出し、すべてのユーザーライセンスを分類してください。Active、Passive、Ghost。各ダウングレードまたは削除判断に名前を付けます。Ghost 数だけで通常監査の費用が出ます。
- すべての非シートプロダクト行にオーナーをマッピングしてください。Service ライセンス、Platform ライセンス、サンドボックスティア、Premier サポート、Community シート、エージェントキャパシティ。各行にオーナーとユースケースを与えます。どちらも持たない行は除去候補です。
- Integration プラットフォームの「残るコスト」計算を回してください。すべてのアクティブインテグレーションをリストアップし、各代替の移行コストを算出し、プラットフォームティアがサンセットかを判断します。
- スイッチ問題を正直に判断してください。信頼できる移行をロードマップにコミットするか、名指ししないか、どちらかです。洗練されたアカウントチームにブラフをかけてはいけません。
- 監査後の依頼を書面で送ってください。欲しいスコープ、保持するシート、除去するプロダクトを名指しした、具体的な行単位のカウンタープロポーザル。ベンダーのディスカウント会話は、彼らのスコープではなくあなたのスコープに対して枠づけられます。
- 監査を毎年回してください。ブラウンフィールドのインスタンスはカスタムプロパティと同じように、更新と更新の合間にライセンスを静かに積み上げます。
この 7 つを実行すれば、更新会話は短く、ディスカウントは本物になります。スキップすれば、ディスカウントはアカウントチームが与えると決めるものになり、それは更新レターが既に織り込んでいたディスカウントです。
Checkpoint がどう関わるか
Salesforce ライセンス監査は、Checkpoint で回す引き継ぎスタック作業の大半を占めます。プレ更新監査はスコープされ、行単位で、書面のカウンタープロポーザル付きで提供します。更新ウィンドウが今後 2 四半期以内なら、今こそ持つべき会話です。
出典
- Lemkin, Jason. The AI agent seat problem is real (Salesforce spend up 83% year over year). SaaStr、2026。saastr.com
- Paranikas et al. How to negotiate with powerful suppliers. Harvard Business Review、2015 年 7-8 月。hbr.org