第13章：論理的な交渉・説得術

この章で作れる成果物

この章を読み終えると、次の成果物を作れる状態を目指します。

• sales / negotiation task brief: 営業ヒアリング、提案、反論処理、交渉の目的、相手、意思決定点、情報分類、承認者を定義する設計メモ。
• account / stakeholder context pack: 顧客、相手部門、意思決定者、利用者、影響者、制約、既存関係を整理する文脈資料。
• discovery question map: 相手の業務課題、判断基準、制約、導入条件、未確認事項を聞き出す質問設計表。
• needs / constraints matrix: 相手の表面的要求、背景ニーズ、制約、懸念、受け入れ条件を分ける表。
• proposal strategy canvas: 提案骨子、価値仮説、根拠、リスク、実行条件、次アクションをまとめる設計表。
• claim-evidence-offer map: 主張、根拠、提示価値、相手メリット、確認すべき前提を紐づける表。
• objection / concern register: 反論、懸念、質問、回答方針、根拠、保留条件、回答責任者を整理する台帳。
• negotiation option / BATNA map: 選択肢、代替案、譲歩可能範囲、非交渉条件、合意しない場合の対応を整理する地図。
• concession / approval log: 譲歩、条件変更、承認者、期限、見返り、リスクを残す交渉ログ。
• agreement / follow-up memo: 合意事項、未決事項、条件、担当、期限、次回確認を残す合意後メモ。

第12章では、会議設計、議事録、意思決定ログ、合意形成を扱いました。本章では、その会議や顧客接点で整理した論点を、営業ヒアリング、提案骨子、反論処理、交渉へ展開します。

交渉や説得の目的は、相手を言い負かすことではありません。相手の意思決定を支援し、双方が守れる条件を明確にし、合意後に実行できる状態を作ることです。AIは、質問案、提案骨子、反論整理、交渉シナリオ、合意メモの草案作成に役立ちます。ただし、相手への約束、価格、契約条件、リスク受容、譲歩判断は人間が責任を持ちます。

本章とAI活用の標準業務フロー

本章は、AI活用の標準業務フロー（1枚） のうち、主に次の工程に対応します。

• 1. タスク定義: ヒアリング、提案、反論処理、交渉の目的、相手、意思決定点、合意条件を決める。
• 2. 情報分類: 顧客情報、価格、契約条件、個人情報、競合情報、社内原価、未公開情報を分類する。
• 3. 文脈設計: 相手の状況、関心、制約、既存関係、過去の合意、未解決論点を account / stakeholder context pack にする。
• 4. 出力仕様: discovery question map、proposal strategy canvas、objection / concern register、negotiation option / BATNA map、agreement / follow-up memo の形式を定義する。
• 5. 手段選択: ヒアリング、提案書、1枚サマリー、デモ、見積、会議、メール、非同期レビューを使い分ける。
• 6. 生成: AIに質問案、提案骨子、反論候補、譲歩案、合意メモ草案を作らせる。
• 7. 評価: CARE+、相手の判断基準、根拠、リスク、契約・承認条件、実行可能性で点検する。
• 8. ファクトチェック: claim-evidence-offer map と meeting evidence pack で、主張、数値、引用、条件を確認する。
• 9. 編集・承認: 人間が提案内容、見積、譲歩、契約条件、回答範囲を承認する。
• 10. ログ化・再利用: 採用版の提案骨子、反論回答、譲歩ログ、合意メモ、再利用条件を残す。

AIに「説得力のある提案を作って」と依頼する前に、誰のどの判断を支援するのか、何を約束してよいのか、何を要確認として残すのかを設計します。

13.1 この章で扱う業務課題

営業、提案、交渉で起きる失敗は、話し方や押しの強さだけでは説明できません。多くは、相手理解、根拠、合意条件、承認範囲の設計不足から生じます。

• 相手の課題を確認する前に、自社の提案説明を始めてしまう。
• 相手の表面的要求と、背景にある制約や判断基準を分けていない。
• 提案書の主張、根拠、価格、リスク、実行条件がつながっていない。
• AIが作った反論回答を、契約や法務確認なしにそのまま使う。
• 値引き、納期短縮、追加対応などの譲歩を、承認者や見返りなしに約束する。
• 反対意見を「抵抗」と見なし、重要な受け入れ条件として扱えていない。
• 合意したはずの内容が、見積、契約、議事録、次回アクションに反映されない。
• 顧客名、価格、契約条件、競合情報、個人情報を不用意に外部AIへ渡してしまう。

本章では、交渉を「口頭の駆け引き」ではなく「相手の判断と合意後の実行を支える成果物群」として扱います。

13.2 sales / negotiation task brief

13.2.1 交渉前に定義すること

sales / negotiation task brief は、ヒアリング、提案、反論処理、交渉の目的と制約を定義するメモです。

【sales / negotiation task brief】
案件名:
利用場面: 初回ヒアリング / 提案前確認 / 提案説明 / 条件交渉 / 契約前確認 / 継続提案
相手:
相手の役割: 利用者 / 推薦者 / 決裁者 / 購買 / 法務 / 情報システム / 現場責任者
こちらの目的:
相手の意思決定点:
今回確認したいこと:
今回約束してよいこと:
今回約束してはいけないこと:
情報分類: 公開 / 社内限定 / 顧客情報 / 契約情報 / 個人情報 / 競合情報 / 社内原価
AI利用環境: 外部AI / 社内AI / AI利用不可 / 手作業中心
参照資料: meeting minutes / decision log / proposal skeleton / 見積 / 契約条項 / FAQ
未確認事項:
想定される反論:
承認者:
合意後に残すログ:
再利用条件:

brief がないまま交渉に入ると、相手の反応に合わせて場当たり的に条件を変えやすくなります。特に、価格、納期、契約、サポート、情報セキュリティに関わる回答範囲を先に決めます。

13.2.2 合意しない条件を決める

交渉では、合意する条件だけでなく、合意しない条件を決めます。

AIには条件候補を整理させられますが、非交渉条件、譲歩範囲、承認者は人間が決めます。

13.3 account / stakeholder context pack

13.3.1 相手を個人ではなく意思決定構造で見る

account / stakeholder context pack は、相手組織の文脈、関係者、判断基準、制約を整理する資料です。

【account / stakeholder context pack】
案件名:
顧客 / 相手組織:
現状の関係:
既存契約 / 過去提案:
今回の背景:

| 関係者 | 役割 | 関心事 | 判断権限 | 懸念 | 必要な根拠 | 接点履歴 | 次に確認すること |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 部門長 | 決裁者 | 投資対効果、リスク | 最終承認 | 導入負荷 | 1枚サマリー、費用対効果仮説 | 前回説明済み | 承認条件 |
| 現場担当 | 利用者 | 使いやすさ、現場負荷 | 推薦に影響 | 運用定着 | デモ、運用手順 | ヒアリング予定 | 現行課題 |
| 情報システム | 技術確認 | security、運用、ログ | 制約提示 | 権限管理 | セキュリティ資料 | 未接触 | 確認プロセス |
| 購買 | 条件調整 | 価格、契約、支払条件 | 契約条件に影響 | 予算 | 見積、契約条件 | 既存取引あり | 交渉窓口 |

相手を「担当者」だけで見ていると、提案が誰の判断を通ればよいのか分からなくなります。AIにステークホルダー整理を依頼する場合も、事実と推測を分けて出力させます。

13.3.2 情報分類と相手情報の扱い

営業や交渉では、顧客情報、契約情報、競合情報、個人情報が混ざります。AI利用前に、次のように扱いを決めます。

• 顧客名、担当者名、契約条件、価格、課題詳細は、原則として社内ルールに従い分類する。
• 外部AIへ渡す場合は、匿名化、抽象化、または社内承認を前提にする。
• 競合名や他社条件は、出所、確認日、共有可否を記録する。
• 個人の評価、感情、交渉スタイルを断定的にAIへ分類させない。
• 契約・法務・security に関わる回答は、専門部門確認を前提にする。

13.4 discovery question map

13.4.1 ヒアリングを質問リストで終わらせない

discovery question map は、相手の課題、判断基準、制約、合意条件を確認するための質問設計表です。

【discovery question map】
| 目的 | 質問 | 確認したいこと | 回答の使い道 | 深掘り条件 | 記録先 |
| --- | --- | --- | --- | --- | --- |
| 背景確認 | 今回検討が必要になった背景は何ですか | 起点、期限、既存決定 | account / stakeholder context pack | 期限が近い場合 | sales / negotiation task brief |
| 課題確認 | 現在どの業務で困っていますか | 業務課題、影響範囲 | needs / constraints matrix | 抽象的な場合 | discovery question map |
| 判断基準 | 採用可否は何で判断しますか | 評価軸 | proposal strategy canvas | 複数部門が関わる場合 | account / stakeholder context pack |
| 制約確認 | 予算、契約、security、運用で制約はありますか | 非交渉条件 | negotiation option / BATNA map | 専門確認が必要な場合 | concession / approval log |
| 反対意見 | 導入しない理由があるとすれば何ですか | 懸念、受け入れ条件 | objection / concern register | 強い懸念がある場合 | objection / concern register |
| 次アクション | 次に誰が何を確認しますか | 担当、期限 | agreement / follow-up memo | 決裁者不在の場合 | agreement / follow-up memo |

良い質問は、相手を追い詰めるためではなく、相手が判断に必要な情報を一緒に整理するために使います。

13.4.2 質問の型

【事実確認】
- 現在の業務フローはどうなっていますか。
- どの資料、ログ、数値で確認できますか。
- いつから、どの範囲で起きていますか。

【解釈確認】
- その状況を、どのような課題として見ていますか。
- 影響が大きい理由は何ですか。
- 関係者によって見方は違いますか。

【判断基準確認】
- 採用する場合、何が満たされている必要がありますか。
- 価格、品質、速度、リスクのうち、何を優先しますか。
- 決裁者が最も気にする論点は何ですか。

【制約確認】
- 変更できない条件は何ですか。
- 法務、security、購買、運用の確認は必要ですか。
- いつまでに決める必要がありますか。

【合意条件確認】
- 条件付きなら受け入れられる点はありますか。
- どの懸念が解消されれば次へ進めますか。
- 次回までに誰が何を確認しますか。

AIには質問候補を作らせられますが、相手の立場、関係性、守秘義務、契約上聞いてよい範囲は人間が調整します。

13.5 needs / constraints matrix

13.5.1 表面的要求と背景ニーズを分ける

needs / constraints matrix は、相手の発言を、要求、背景ニーズ、制約、懸念、受け入れ条件に分ける表です。

【needs / constraints matrix】
| 発言 / 要求 | 種別 | 背景ニーズ | 制約 | 懸念 | 受け入れ条件 | 要確認 |
| --- | --- | --- | --- | --- | --- | --- |
| 価格を下げてほしい | 要求 | 予算内で導入したい | 今期予算 | 効果が不明 | 範囲限定 / 分割 / 成果確認 | 購買条件 |
| 現場負荷を増やしたくない | 懸念 | 運用定着を重視 | 人員不足 | 導入後に使われない | 操作手順 / サポート | 現場確認 |
| security確認が必要 | 制約 | リスクを避けたい | 社内規程 | 情報漏えい | 資料提出 / ログ条件 | 情シス確認 |
| 早く始めたい | 要求 | 期限に間に合わせたい | 決裁日 | 品質低下 | 段階導入 | スケジュール |

要求だけを見ると、価格や納期の交渉に見えます。背景ニーズと制約を見ると、範囲調整、段階導入、支払い条件、レビュー条件など、別の選択肢が見えます。

13.5.2 事実、推測、感情を分ける

交渉では、相手の感情や不安も重要です。ただし、感情を事実として扱うと、提案や合意条件が不正確になります。

AIに会話メモを整理させる場合は、この種別分類を出力仕様に入れます。

13.6 proposal strategy canvas

13.6.1 提案骨子を意思決定順に作る

proposal strategy canvas は、第10章の proposal skeleton を、相手の判断基準に合わせて交渉・提案用に具体化する表です。

【proposal strategy canvas】
案件名:
相手の意思決定点:
推奨案:
代替案:
今回求める反応:

| 要素 | 内容 | 根拠 | 相手メリット | リスク / 条件 | 承認者 |
| --- | --- | --- | --- | --- | --- |
| 課題 | 提案書初稿作成が属人化している | ヒアリングメモ | 品質ばらつきの低減 | 対象範囲確認 | 相手部門長 |
| 提案 | 社内AIを使った初稿作成支援を限定導入する | proposal skeleton | レビュー観点の標準化 | 情報分類が前提 | 自社責任者 |
| 実行 | 3案件で試験する | agreement / follow-up memo | 低リスクで検証 | 対象案件未確定 | 双方担当 |
| リスク | 顧客情報の混入を避ける | data classification card | 安全な試験 | 社内AI限定 | 情報システム |
| 依頼 | 対象案件とレビュー担当を決める | decision log | 次回までに進められる | 契約確認は保留 | 相手担当 |

提案は、自社が売りたいものの説明ではなく、相手が判断できる情報の順序で構成します。

13.6.2 claim-evidence-offer map

claim-evidence-offer map は、提案の主張、根拠、提示価値を紐づける表です。

【claim-evidence-offer map】
| 主張 | 根拠 | 提示価値 | 相手メリット | 前提 / 限界 | 要確認 |
| --- | --- | --- | --- | --- | --- |
| 限定試験から始めるのが妥当 | 課題メモ、情報分類 | 小さく検証する導入案 | リスクを抑えられる | 全社導入判断ではない | 対象案件 |
| レビュー品質を標準化できる | document review checklist | チェック観点 | 属人化を減らす | 効果数値は試験後測定 | 評価指標 |
| 顧客情報を保護できる | data classification card | 入力制御 | security懸念を下げる | 社内AI環境が前提 | 情シス確認 |
| 次回判断までに材料をそろえられる | agreement / follow-up memo | 宿題分解 | 判断が進む | 担当と期限が必要 | 承認者 |

根拠が弱い主張は、提案の中心に置かず、仮説または要確認として扱います。

13.7 objection / concern register

13.7.1 反論を防御ではなく設計材料にする

objection / concern register は、反論や懸念を、回答方針、根拠、保留条件へ整理する台帳です。

【objection / concern register】
| 反論 / 懸念 | 背景 | 回答方針 | 根拠 | 回答してよい範囲 | 保留条件 | 回答責任者 |
| --- | --- | --- | --- | --- | --- | --- |
| 効果が見えない | 投資判断 | 試験で測定する | 評価rubric | 測定方針 | 数値保証を求められた場合 | 提案責任者 |
| 情報漏えいが不安 | security | 入力範囲を制限する | data classification card | 社内AI / 匿名化方針 | 契約条件確認 | 情報システム |
| 現場負荷が増える | 運用 | 対象を限定する | agreement / follow-up memo | 試験範囲 | 工数見積未確認 | 現場責任者 |
| 価格が高い | 予算 | 範囲、支払条件、段階導入を比較する | 見積 | 価格構成 | 値引き承認が必要 | 営業責任者 |
| 契約上問題ないか | 法務 | 専門確認へ回す | 契約条項 | 確認プロセス | 条項解釈 | 法務担当 |

反論は、相手が受け入れるための条件を示していることがあります。相手を説得する前に、懸念を事実、制約、未確認事項へ分けます。

13.7.2 回答してはいけない範囲

反論処理で重要なのは、すぐ答えることではなく、答えてよい範囲を守ることです。

• 効果数値を保証しない。未測定なら、測定方法と確認時期を示す。
• 契約条項、法的責任、IP、privacy は専門部門確認なしに断定しない。
• 値引き、無償対応、納期短縮を承認なしに約束しない。
• 他社条件、競合情報、顧客固有情報を不用意に話さない。
• AIが生成した回答を、根拠確認なしに相手へ送らない。

13.8 negotiation option / BATNA map

13.8.1 選択肢を複数持つ

negotiation option / BATNA map は、合意に向けた選択肢と、合意しない場合の対応を整理する地図です。BATNAはBest Alternative to a Negotiated Agreementの略で、「合意できなかった場合の最善の代替案」として扱います。相手を脅す材料ではなく、自社の判断基準として使います。

【negotiation option / BATNA map】
交渉論点:
目標条件:
最低受け入れ条件:
非交渉条件:
自社BATNA:
相手BATNAの仮説:
相手BATNA仮説の根拠 / 確認状態: 未確認 / 確認中 / 確認済み
相手BATNA仮説を提案本文へ採用する条件:

| 選択肢 | 相手メリット | 自社メリット | リスク | 必要承認 | 見返り条件 | 採用条件 |
| --- | --- | --- | --- | --- | --- | --- |
| 標準案 | 予定通り導入 | 利益率を維持 | 価格懸念が残る | 通常承認 | なし | 予算内 |
| 範囲縮小案 | 初期費用を抑える | リスクを抑える | 効果範囲が限定 | 営業責任者 | 対象機能限定 | 試験導入 |
| 支払条件調整 | キャッシュフロー改善 | 総額維持 | 回収リスク | 経理確認 | 契約期間延長 | 与信確認 |
| 段階導入 | 現場負荷を抑える | 継続提案可能 | 導入期間が延びる | 双方承認 | 次フェーズ条件 | 成果確認 |
| 合意しない | 無理な条件を避ける | 損失回避 | 関係維持が課題 | 営業責任者 | 次回再提案 | 非交渉条件抵触 |

相手BATNAは、相手本人の確認や信頼できる根拠がない限り仮説です。未確認の仮説は提案本文の事実へ昇格させず、確認状態と採用条件を残します。

13.8.2 譲歩は単独で出さない

譲歩は、相手の受け入れ条件とセットで扱います。

譲歩は、concession / approval log に記録します。

13.9 concession / approval log と agreement / follow-up memo

13.9.1 譲歩と承認を記録する

【concession / approval log】
| 論点 | 提示条件 | 変更後条件 | 変更理由 | 見返り | リスク | 承認者 | 承認状態 | 記録先 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 初期費用 | 標準価格 | 範囲限定で調整 | 予算制約 | 契約期間延長 | 利益率低下 | 営業責任者 | 要承認 | 見積 |
| 納期 | 標準納期 | 優先対応 | 顧客期限 | 機能範囲限定 | 品質リスク | PM | 条件付き | project log |
| サポート | 標準サポート | 初月追加支援 | 定着支援 | 回数制限 | 無償範囲拡大 | 部門長 | 承認済み | 契約補足 |

ログがない譲歩は、後から説明できません。交渉中に口頭で出した条件も、最終提案、見積、契約、合意メモに反映します。

13.9.2 合意後メモを作る

agreement / follow-up memo は、合意内容を実行へつなげるメモです。

【agreement / follow-up memo】
案件名:
合意日:
相手:
合意事項:
条件付き合意:
未決事項:
反対意見 / 懸念:
譲歩内容:
承認者:
次アクション:
担当:
期限:
必要資料:
契約 / 法務確認:
情報分類:
公開範囲:
再利用条件:
見直し条件:

第12章の decision log とつなげることで、「何を合意したか」「なぜそうなったか」「次に誰が何をするか」を追跡できます。

13.10 AIとの協働境界

13.10.1 AIに任せる範囲

AIに任せやすい作業は、構造化、抜け漏れ確認、複数案作成、ロールプレイです。

• sales / negotiation task brief から質問案を作る。
• ヒアリングメモを needs / constraints matrix に分類する。
• proposal strategy canvas の草案を作る。
• claim-evidence-offer map の抜け漏れを確認する。
• objection / concern register に反論候補と回答方針を整理する。
• negotiation option / BATNA map の選択肢候補を出す。
• agreement / follow-up memo のドラフトを作る。
• 相手役のロールプレイを通じて、説明の弱点を洗い出す。

13.10.2 AIに任せない範囲

次の判断は、人間が行います。

• 相手へ何を約束してよいか。
• 価格、値引き、納期、契約条件、サポート範囲の変更可否。
• 顧客情報、契約情報、競合情報、個人情報をAIへ渡してよいか。
• 法務、security、privacy、IP、購買条件に関わる回答。
• 相手の発言をどう解釈し、どの懸念を正式な条件として残すか。
• BATNA、最低受け入れ条件、非交渉条件。
• 合意書、見積、契約、議事録へ反映する最終内容。
• 交渉結果に責任を持てる状態か。

13.10.3 プロンプト例

【背景】顧客への社内AI試験導入提案に向けた営業ヒアリングを準備しています。
【目的】相手の課題、判断基準、制約、反対意見を確認したいです。
【入力】sales / negotiation task brief、前回meeting minutes、提案書レビュー課題メモがあります。
【制約】顧客名、価格、契約条件は含めません。未確認事項は断定しないでください。
【依頼】discovery question map の草案を作ってください。
【出力形式】目的、質問、確認したいこと、回答の使い道、深掘り条件、記録先の表にしてください。
【確認観点】相手の意思決定点、制約、合意条件が確認できる質問になっているかを最後に点検してください。

AI出力を採用する前に、相手へ聞いてよい内容、守秘義務、関係性、回答範囲を人間が確認します。

13.11 よくある失敗

13.11.1 ヒアリング前に提案してしまう

相手の課題、判断基準、制約が分からないまま提案すると、説明はできても判断材料になりません。discovery question map で、先に聞くべきことを設計します。

13.11.2 要求をそのまま受け取る

「安くしてほしい」「早くしてほしい」は表面的要求です。needs / constraints matrix で、背景ニーズ、制約、受け入れ条件を分けます。

13.11.3 根拠の弱い価値訴求をする

効果を断定すると、信頼を失います。claim-evidence-offer map で、主張、根拠、前提、限界を確認します。

13.11.4 反論をその場で潰そうとする

反論は、相手の受け入れ条件を示す情報です。objection / concern register に残し、回答してよい範囲と保留条件を分けます。

13.11.5 承認なしに譲歩する

値引き、納期短縮、無償対応、契約条件変更は、あとで大きなリスクになります。concession / approval log に承認者と条件を残します。

13.11.6 合意を実行文書に落とさない

口頭合意だけでは、実行時に認識がずれます。agreement / follow-up memo に、合意事項、未決事項、担当、期限、見直し条件を残します。

13.12 人間が最終判断すべき点

AIと協働しても、次の判断は人間が行います。

• ヒアリング、提案、反論処理、交渉の目的と到達点。
• 相手へ提示してよい情報、提示してはいけない情報。
• 顧客情報、契約情報、競合情報、個人情報の扱い。
• 価格、納期、サポート、契約条件の譲歩可否。
• 相手の発言を、事実、解釈、仮説、感情、制約のどれとして扱うか。
• どの反論にその場で答え、どの反論を保留するか。
• BATNA、最低受け入れ条件、非交渉条件。
• 法務、security、privacy、IP、購買、経理への確認要否。
• 合意事項、未決事項、次アクションをどう記録するか。
• 交渉結果に責任を持てる状態か。

章末演習

演習13-1：sales / negotiation task brief を作る

自分が近く行う営業ヒアリング、提案、条件調整のいずれかを1つ選び、sales / negotiation task brief を作ってください。相手、意思決定点、約束してよいこと、約束してはいけないこと、情報分類、承認者を明示してください。

演習13-2：discovery question map を作る

演習13-1の案件について、discovery question map を作ってください。相手の課題、判断基準、制約、合意条件を確認できる質問を設計してください。

演習13-3：proposal strategy canvas を作る

ヒアリング結果をもとに、proposal strategy canvas を作ってください。推奨案、代替案、根拠、相手メリット、リスク、承認者を分けてください。

演習13-4：objection / concern register を作る

想定される反論や懸念を5件以上挙げ、回答方針、根拠、回答してよい範囲、保留条件、回答責任者を整理してください。

演習13-5：negotiation option / BATNA map を作る

価格、納期、契約、サポートなどの交渉論点を1つ選び、複数の選択肢、最低受け入れ条件、非交渉条件、必要承認を整理してください。

理解度チェック

□ sales / negotiation task brief を使い、目的、相手、意思決定点、情報分類、承認者を定義できる □ account / stakeholder context pack で、意思決定者、利用者、影響者、制約を整理できる □ discovery question map で、課題、判断基準、制約、合意条件を確認する質問を設計できる □ needs / constraints matrix で、要求、背景ニーズ、制約、懸念、受け入れ条件を分けられる □ proposal strategy canvas と claim-evidence-offer map で、提案の主張、根拠、価値、リスクを紐づけられる □ objection / concern register で、反論、回答方針、保留条件、回答責任者を整理できる □ negotiation option / BATNA map で、選択肢、代替案、譲歩範囲、非交渉条件を管理できる □ concession / approval log と agreement / follow-up memo で、譲歩、承認、合意後の実行を記録できる □ AIに任せる範囲と、人間が最終判断する範囲を分けられる

章末の要点

• 交渉や説得は、相手を言い負かす行為ではなく、相手の意思決定と合意後の実行を支援する業務プロセスです。
• sales / negotiation task brief は、目的、相手、意思決定点、約束してよい範囲を定義する入口です。
• account / stakeholder context pack は、相手組織の意思決定構造、関心、制約を整理します。
• discovery question map は、相手の課題、判断基準、制約、合意条件を確認する質問設計表です。
• needs / constraints matrix は、要求、背景ニーズ、制約、懸念、受け入れ条件を分けます。
• proposal strategy canvas と claim-evidence-offer map は、提案の主張、根拠、提示価値、リスクを紐づけます。
• objection / concern register は、反論を防御対象ではなく、受け入れ条件を見つける材料として扱います。
• negotiation option / BATNA map は、複数の選択肢、代替案、非交渉条件を明確にします。
• concession / approval log と agreement / follow-up memo は、譲歩、承認、合意内容を実行へつなげます。

次章への橋渡し

第13章では、営業ヒアリング、提案骨子、反論処理、交渉を、AIと協働して成果物化する方法を扱いました。次の第14章では、日常業務におけるメール、チャット、報告、相談、提案、マルチモーダル資料の扱いへ展開します。

• 前章: 第12章：効果的な会議・議論術
• 次章: 第14章：日常業務での実践
• リライト方針: 2026年版リライト契約と分割計画