Claudeで価格交渉の値引き条件と想定問答を整理する — Projectsで商談前に練習

価格交渉の準備でいちばん詰まるのは、想定問答そのものではありません。「どこまで下げてよいか」「下げる代わりに何をもらうか」「どこで断るか」が人によって違い、準備のたびに頭の中で作り直していることです。

この3点を社内ルールとして文章にし、ClaudeのProjectに置くと、商談前の準備が変わります。ルールに沿った想定問答の作成と、買い手役を相手にしたロールプレイが、同じProjectの中で繰り返せるからです。この記事では、ルールの書き方、Projectへの置き方、練習のさせ方、社外秘の守り方を順に見ます。

値引きのルールをProjectに置くと何が変わるか

Projectは、チャット履歴とナレッジ(資料の置き場)を持つ独立した作業スペースです。資料をアップロードし、背景を与えたうえで、Claudeとその文脈に絞った会話ができます。無料アカウントを含む全ユーザーが使えますが、無料プランで作れるのは5つまでです。

営業の価格交渉に向く理由は、2つの置き場が分かれている点にあります。

• プロジェクト指示: 全チャットに適用される振る舞いの指定です。「社内ルールの範囲でのみ値引きを提案する」といった枠を置きます。
• プロジェクトナレッジ: 値引き表、過去の条件、商品の仕様書など、参照させたい資料を置きます。

どちらもそのProject内のすべてのチャットで使われます。逆に、チャットをまたいだ文脈の引き継ぎは起きません。ナレッジに追加した情報だけが、別のチャットに持ち越されます。この性質は、後の「ロールプレイの結果をルールに戻す」の節で効いてきます。

なお、営業チームの競合比較カードを作る場合は、Claudeで営業バトルカードライブラリを構築する方法が扱う領域です。ここで置くのは競合の情報ではなく、自社の値引き判断の基準です。

ルールは「値引き幅・代替条件・断る線」の3種類に分ける

ルールを1つの長文にまとめると、Claudeにもメンバーにも読みにくくなります。次の3種類に分けて書くと、想定問答でも練習でも使い回せます。

値引き幅は「何%まで」だけでなく、誰の承認でどこまで動けるかを段階で書きます。担当者が自分で決められる範囲が曖昧だと、練習中に買い手役がその曖昧さを突いてきても、正解が決まりません。

代替条件は、値引きを渡す前提条件として書きます。「値引きするなら年間契約」「支払いを前倒しにするなら追加の割引」のように、取引の形になっているほうが、Claudeの出す想定問答も交換の形になります。

断る線は、数字より言い回しが肝です。断る理由を1つ添え、代わりに出せるものを示す形にします。

ルールの書き方の例(架空)

以下は、架空のSaaS「Aサービス」を想定した書き方の例です。数字はすべて仮のもので、実際の社内ルールに置き換えて使います。

# 価格交渉ルール(Aサービス・新規契約)
 
## 値引き幅
- 担当者の判断: 定価から10%まで
- 営業部長の承認: 10%超〜20%まで
- 20%超: 受けない。代替条件で対応する
 
## 代替条件(値引きを渡すときに必ずセットで受け取る)
- 10%超: 年間契約であること
- 15%超: 年額の一括前払い
- 事例掲載の同意は、上記とは別の追加特典として扱う
 
## 断る線
- 定価の30%を超える要求: 応じない
  理由の一言: 「同条件のお客様との公平性を保つため」
  代案: 利用ユーザー数の段階導入を提案する
- 他社の見積書の提示だけを根拠にした要求: 見積書の範囲(機能・期間)の確認を先に求める

ここで置いたのは判断の基準だけです。個別の顧客名や、特定の商談の最終提示額は含めていません。含めない理由は、後の社外秘の節で扱います。

手順1: Projectを作り、指示とナレッジを分けて置く

Projectsへは、左側のProjectsから入るか、claude.ai/projectsを直接開きます。右上の「+ New Project」で作成します。

作成時に名前と説明を入れますが、名前と説明の内容はClaudeには渡りません。値引きのルールや前提を説明欄に書いても、Claudeは読めないということです。ルールは必ずプロジェクト指示かナレッジに置きます。

置き分けは次のとおりです。

1. プロジェクト指示に、役割と守る枠を書く。ルールの全文ではなく、「ナレッジの価格交渉ルールを根拠にする」「ルールに無い値引きは提案しない」といった振る舞いを書く
2. ナレッジに、上で書いたルールの文書を置く。価格表や商品仕様書も、ここに入れる
3. 保存する

プロジェクト指示の例を示します。

あなたは当社の営業担当を支援する、価格交渉の準備アシスタントです。
- 値引きの提案は、ナレッジの「価格交渉ルール」に書かれた範囲だけで行う。
- ルールに書かれていない条件を聞かれたら、推測せず「ルールに記載なし」と答え、
  確認すべき相手(営業部長など)を示す。
- 値引きを提案するときは、必ず代替条件とセットにする。
- 回答の末尾に、根拠にしたルールの項目名を書く。

「ルールに記載なし」と答えさせる一文が重要です。これが無いと、ルールの空白をClaudeがもっともらしい数字で埋める余地が生まれます。根拠の項目名を末尾に書かせる指定は、出力をルールと突き合わせるときの目印になります。

ナレッジが大きくなっても、有料プラン(Pro、Max、Team、Enterprise)ではプロジェクトの容量が近づくとClaudeが自動でRAGモードに切り替わり、容量が最大10倍まで広がります。仕組みの違いはClaude ProjectsのRAG検索の仕組みと全文投入との違いにあります。値引きルールの文書は短く保つと、メンバーが読み返しやすくなります。

手順2: 商談ごとの想定問答を作らせる

ルールを置いたら、商談の前提を伝えて想定問答を作らせます。前提は、チャットの冒頭に毎回書きます。ナレッジに置いたルールは自動で参照されますが、今回の商談の条件は別だからです。

次の商談の想定問答を作ってください。
- 相手: 製造業、従業員300名、情報システム部の部長
- 提案内容: Aサービス、50ユーザー、年間契約を想定
- 相手の関心: 予算が厳しく、他社との相見積もり中
値引きを求められる場面を5つ想定し、それぞれ
(1)相手の言い方 (2)こちらの返答案 (3)根拠にしたルール項目 を表にしてください。

出力が返ったら、まず3列目の根拠項目を見ます。ルールに存在しない項目名が書かれていたら、その行の返答案は採用しません。ルールの文言と返答案の数字を、1行ずつ照らし合わせる作業が、担当者に残る仕事です。

商談の前提は、顧客名を伏せた属性で書くのが安全です。上の例も、業種・規模・部署だけにしています。

手順3: 買い手役のロールプレイで練習する

想定問答は読んで終わりになりがちです。声に出して返す練習には、Claudeに買い手役を演じさせます。

開始用のプロンプトは次のような形です。

これから価格交渉のロールプレイをします。あなたは買い手側の部長役です。
予算は厳しく、定価の25%引きを求めて粘ります。
私が返答するまで待ってください。1回の発言は3文以内にしてください。
私が「講評」と入力したら、ロールプレイを止めて、私の返答のうち
ルールを超えた箇所と代替条件の出し忘れを、根拠のルール項目つきで挙げてください。

買い手役の「定価の25%引き」は、ルール上は部長承認を超え、断る線(30%)の手前に当たる位置です。このように、ルールの境目に近い要求を指定すると、練習の価値が上がります。ルールの内側の要求ばかりでは、判断力の練習になりません。

講評では「どこが良かったか」より、ルール違反と代替条件の出し忘れに絞って挙げさせます。ルール違反と出し忘れは、練習の成果を確認しやすい観点です。

ロールプレイの結果をルールに戻す

ロールプレイで「この場面はルールの文言では判断できない」という箇所が出てきます。たとえば、複数年契約での段階的な値引きや、追加ユーザーの単価などです。

ここで押さえておきたい性質は、チャットをまたいだ文脈の共有が無いことです。ロールプレイの中でClaudeが「こう答えるとよい」と整えた方針は、ナレッジに書き戻さない限り、次のチャットには残りません。

運用は次の流れが扱いやすくなります。

• ロールプレイで見つかったルールの空白は、営業部長など決められる人に確認する
• 決まった内容を、ルール文書に1項目として追記し、ナレッジを差し替える
• 追記後に、同じ場面をもう一度練習し、ルールどおりに返答案が出るかを確かめる

メモリはFree・Pro・Maxでは既定でオン、Team・Enterpriseではオーナーが有効にしたときに使えます。各Projectのメモリは、非プロジェクトのチャットとは分かれています。メモリを使いたくない練習のチャットは、最初のメッセージを送る前に、「+」メニューで「Memory」をオフにできます。この方法で始めたプロジェクトのチャットは、プロジェクトのメモリを使わず、追加もしません。

ルールの確定を、メモリや会話履歴に頼らず、ナレッジの文書に集めておくと、誰がどのチャットで練習しても同じ基準になります。

社外秘の扱い: 下限額と共有範囲を決めておく

値引きの下限は、競合に知られれば不利になる情報です。Projectに置く前に、置く内容と共有の範囲を決めておきます。

Projectに置かないほうがよいもの

次のものは、置かずに運用できるなら置かない選択肢を先に考えます。

• 特定の顧客名と、その顧客に出した最終提示額
• 原価や粗利の内訳そのもの(承認段階ごとの下げ幅の表だけで足りることが多い)
• 他社の見積書の原本

練習に必要なのは、判断の基準と代替条件です。顧客の固有情報を入れなくても、基準に沿った練習は成り立ちます。

共有すると誰に何が見えるか

Team・Enterpriseプランでは、Projectを同じ組織のメンバーと共有できます。権限は2段階です。

Can viewでも、ナレッジと指示は見えます。つまり、値引きの下限を書いたルール文書は、閲覧権限を渡した相手に見えます。営業担当全員に見せてよい範囲(担当者判断の10%まで)と、部長だけが知っていればよい範囲を分けたい場合は、Projectを分ける設計もあります。たとえば、全員用の練習Projectには担当者判断の範囲だけを置き、承認段階を含む全文は部長の個人Projectに置く形です。

共有の初期設定にも注意します。作成時に組織全体へ公開すると、他のメンバーがOrganizationタブから見つけて使えるようになります。公開後も、Shareボタンから「Only people invited」に切り替えて非公開に戻せます。共有されたProjectでも、各メンバーのチャット自体は、手動で共有しない限り他のメンバーから見えません。

管理者側の設定として、オーナーはプロジェクトの共有を組織全体で止められます。共有をオフにすると、すでに共有済みの相手はそのままアクセスを保ち、公開プロジェクトは非公開に変わります。共有範囲を絞りたいときは、既存メンバーを共有設定から外す操作が別途必要です。

アーカイブにも落とし穴があります。Projectをアーカイブしても共有権限は解除されず、メンバーも外れません。値引きルールのProjectを使い終えたら、アーカイブではなく、共有メンバーの削除で権限を閉じます。

社内規程との関係

値引きの下限は、営業秘密として管理する対象になりえます。生成AIへの入力と秘密管理性の関係は、営業秘密の秘密管理性は生成AIへの入力で失われるかに整理されています。社内規程に「ClaudeのProjectに置いてよい情報の範囲」を1段落でも書いておくと、置く側の判断が揃います。

練習がうまくいかないときの切り分け

ロールプレイや想定問答で起きやすい不具合と、見る場所です。

ルールに無い値引き率を返してくる: プロジェクト指示に「ルールに記載なし」と答えさせる一文があるかを確認します。無ければ追加します。ある場合は、ナレッジに該当ルールが入っているかを見ます。

買い手役がすぐ折れる: 買い手の性格指定が弱いことが多く、「1回の要求で引き下がらない」「2回目には別の論点を出す」といった行動の指示を足します。

ルール違反を講評で指摘してくれない: 講評の指定を、「ルールを超えた箇所」「代替条件の出し忘れ」の2点に絞ります。「全体の印象を」と頼むと、一般的な交渉のコツに寄ります。

別のチャットで同じ方針が再現されない: 方針がチャット内で整えられただけで、ナレッジに戻っていない状態です。ルール文書に追記します。

契約書の文言まで確認したい: 価格以外の条件交渉は、契約書のレッドラインの領域です。プレイブックを照合して交渉案に変える手順はClaude契約書レッドラインにあります。

刷新が進むProjectsでも同じ置き方でよいか

Claude Codeから順に、プロジェクトを1つの会話とし、複数のスレッドをクラウドで並行実行する新方式が段階的に展開されています。チャットとCoworkの既存のProjectは、今までどおり動き続けます。TeamとEnterpriseは、チャットやCoworkの後に続くとされています。

この記事で扱った、チャット内のProjectの使い方は、既存の方式の話です。新方式の概要はClaude CodeのProjectsが刷新にまとめています。

まとめ

値引き幅・代替条件・断る線を、ナレッジの1文書とプロジェクト指示に分けて置けば、想定問答の作成もロールプレイも同じ基準で回せます。練習で見つかったルールの空白は、チャットの中ではなくナレッジに書き戻します。

共有に進む前に決めるのは、下限額を誰に見せるかです。Can viewでもナレッジは読めるので、見せる範囲ごとにProjectを分けるかどうかが、最初の判断になります。