- 顧客情報を管理するシステムの多くは、ただの記録帳です。何でも記録できても、商談を早くまとめる助けにはなりません。
- 営業チームが本当にほしいのは、提案書の下書きを作り、正しい価格を入れ、似た案件で何が売れたのかを知っているアシスタントです。
- その前に、価格と取引条件の正式版を1か所にまとめておく必要があります。各自が自分のファイルで管理している状態では始められません。
従来のWebサイトやアプリの限界
多くの会社が導入している顧客管理システムは、高価な記録帳のようなものです。営業担当者に商談の内容を入力させはしても、提案書を1通書く手伝いすらしません。そのため営業担当者は今も、古いファイルをコピーして1行ずつ直しています。
従来のCRMは商談後の情報を記録しますが、営業担当者は相変わらず複数のファイルから提案書を組み立てています。価格、作業範囲、例外についての知識は、一部の人の頭の中にしかありません。
提案書づくりが遅れる原因は、たいてい担当者の文章力にはありません。情報が古いプレゼン資料、価格表、メール、一部の人の記憶に散らばっていることが原因です。受注を急ぐと、営業は別のバージョンの条件を使ったり、デリバリーチームが提供できない内容を選んだり、あいまいな契約書を書いて販売後に問題を表面化させたりしかねません。
そこでAI提案コンフィギュレーター（AI Proposal Configurator）には、考える作業と整合性のチェックを手伝う役割が求められます。依頼内容（ブリーフ）の受け取り、ニーズの要件への置き換え、選択肢の整理、価格の計算、承認済みの文言の選択から、例外の承認申請までが対象です。目指すのは、文書を最速で作ることより、根拠と、各項目を確認した人を後からたどれる提案書です。
| 従来の形 | 新しい世代のAIプロダクト |
|---|---|
| 通話の要約、フォローアップのリマインド、メールテンプレートの作成 | ヒアリング内容を要件マップに変え、解決策の選択肢を作り、製品と価格のルールを確認し、提案書を下書きし、リスクに応じて承認を申請する |
AIは読むことと下書きを得意としますが、価格、作業範囲（スコープ）、契約条項は、確認できるシステムとルールから取ってこなければなりません。そのため、いちばん文章のうまいモデルを選ぶことより、CRM、商品カタログ、料金表（Rate Card）、承認フローをつなぐことのほうが大切です。
ビジネスに使える新しい機能
本当に役に立つアシスタントは、この顧客がどんな状況にあるのか、似た案件をどんな提案で受注できたのかを知っています。そのうえで、実際のシステムから引いた価格を入れて最初の版を下書きするので、営業担当者は確認して手を入れるだけで済みます。
プロジェクトの形
ユーザーはCRM上の商談（Opportunity）か会議のメモから始めます。システムが課題、要件、制約、関係者、期限を抜き出し、足りない部分を示して営業担当者に埋めてもらいます。そのあとで提案に入れるモジュールを選び、提案書の骨組みを作ります。画面は人が自由に直せるようにし、各要件と文書中の文言とのつながりを保つべきです。
主な機能
機能としては、ヒアリング支援、要件マトリクス、構成の組み立て、価格・値引きのルール、契約条項のライブラリ、対応能力の確認、承認フロー、文書の自動生成、版の比較などが考えられます。マネージャーは、どの行が標準と違うのか、どの項目が担当者の対応待ちなのかをすぐに確認できます。
技術とシステム連携
システムは、CRM、商品カタログ、料金表、ERPまたはデリバリーの対応能力のデータ、バージョン管理された文書庫とつながる必要があります。AIは要約と文章の下書きに使い、価格、組み合わせの可否、承認権限のロジックは、テストできるルールエンジンに置きます。提案書の記載はすべて、元の要件か参照元までたどれるようにします。
スピード以外の効果
営業は情報探しの時間が減り、戦略を考える余裕が生まれます。経営層は利益率と例外を管理でき、デリバリーチームはスコープのはっきりした仕事を受け取れます。新人にとっては、どんな質問をすべきか、ある種の提案がなぜ合わないのかを学べる育成ツールにもなります。
- 会議の記録から課題、制約、判断基準を切り分ける機能（Meeting-to-Requirement）
- 提供できる部分だけで提案を組み立てるコンフィギュレーター
- 約束、スコープ、未確認の情報を指摘するリスクチェック機能
- 受注・失注の理由を営業プレイブックの改善に生かす仕組み
架空のケース
具体的な利用場面
あるITサービス会社では、AIエージェントが会議の内容を要約し、予算に合わせて3つの案を作ります。システムは提案書を下書きする前に料金表と対応能力を確認し、特別な条件がつく案件はディレクターの承認に回します。
架空のケースで、もう少し詳しく見てみます。あるシステム導入会社が、複数の拠点にまたがる提案書を作る必要に迫られています。AIは会議のメモを読んで要件マトリクスを作り、顧客が確認した事項、前提条件、未解決の質問を分けて整理します。コンフィギュレーターは、営業担当者が選んだスケジュールが対応能力とぶつかっていることに気づき、そのまま文書を送らせずに、段階的な導入計画を提案します。
営業担当者が許容範囲を超える値引きを求めたとき、システムはブラックボックスのように一方的に却下せず、利益率への影響と、引き換えにできる条件を示します。たとえばスコープを減らす、納品の回数を調整するといった条件です。承認者は1つの画面で経緯をすべて確認でき、最終的な文書には、誰がどの例外を承認したのかが記録されます。
約束と納品体制の照合（Promise-to-Delivery Check）
提案書の中の約束は、どれも責任者、対応能力、前提条件、受け入れ基準とひも付いている必要があります。
ひも付けられない約束は、確約として書かず、質問として示します。
範囲、リスク、効果の測り方
開発チーム向け · 技術指標
価格、法的な条件、保証の文言を、AIに確率的な推測で作らせてはいけません。こうした情報は、責任者とバージョンがはっきりしたソースから取得します。指標にはProposal Cycle Time、Rework、Approval Delay、Margin Deviationに加え、受注後のScope Disputeも入れます。早く出せても、デリバリーに負担を生む文書は成功とは言えないからです。
AIは、読みやすくても状況に合わない提案書を作ることがあります。ある顧客のデータを別の顧客の案件に使うことは禁止し、価格と文書のバージョンを必ず保存します。
- Discover：実際の業務を追い、通常のケースと例外の実例を集めます。
- Assist：人が主導権を持ったまま、AIに下書きや提案をさせます。
- Act：テストセットに合格してから、ツールを1つずつ使えるようにします。
- Scale：監視、フォールバック、コスト管理、責任者がそろってから範囲を広げます。
文言が要件までたどれない、価格が料金表と合わない、受注後にデリバリーチームがスコープを直すことが多い、といった状態なら、Assistモードに戻します。システムはまだ、最終版の文書を自動で作れる段階にありません。
BUSINESS & PRODUCT READINESS
よい提案書は、顧客が求めるものと、チームが提供できるものをつなぐ
開発チーム向け · 技術的な詳細
AIに提案書を下書きさせる前に、Pain → Requirement → Solution Component → Assumption → Acceptance Criteriaのトレーサビリティを作ります。責任者や根拠がない部分は、Open Questionとして表示します。こうしておけば、文章はなめらかでも、デリバリーが確認していないスコープを売ってしまう提案書を防げます。
開発チーム向け · 技術的な詳細
Rate Card、Product Rule、Clause、Capacity Signalと、承認された提案書・差し戻された提案書の例を用意します。AIが選択肢を提案するために使う情報と、システムが確定的に計算しなければならないルールを分け、値引き、データへのアクセス、特別なスケジュールといったリスクに応じて承認を設定します。
開発チーム向け · 技術的な詳細
まずPain → Requirement → Solution → Assumption → AcceptanceのTraceability Chainを完成させます。提案書の文言がどの要件にも対応していない場合や出どころがない場合、システムは後から理由をこしらえず、警告を出すべきです。標準の文言と、営業が顧客ごとに書く部分も分けておくと、変更を管理しやすくなります。
まずは頻繁に作り、構成がほぼ決まっている種類の提案書から始めます。よい例、修正が入った例、例外が承認された理由を集め、最初はAssistモードでAIに下書きを手伝わせます。たどれる記録とチェックの仕組みにチームが納得してから、文書の自動生成や自動のワークフローを有効にします。
どんな約束が手戻りを生みやすいか
価格と契約条項の正式版はどこにあるか
提案書を送る前に、誰が対応能力を確認するか
顧客ごとのデータをどう分けているか
営業のプレイブックを、人の腕を縛らずに考える助けになるシステムへ変える
DNA Makerは、営業、プリセールス、プロダクト、デリバリーの各チームと一緒に、提案の流れ全体（Proposal Journey）と、約束と納品体制の対応表（Promise-to-Delivery Map）を作ります。優秀な担当者の質問の仕方、価格のルール、注意点を、要件スキーマとレビューフローに落とし込みます。ビジネス上の内容を承認するのは、引き続きお客様のチームです。
プロトタイプでは、会議の要約、要件マップ、解決策の選択肢、提案書エディターを実際のユーザーに試してもらい、システムが考える助けになっているのか、文章を増やしているだけなのかを確かめます。見るべき点は、営業担当者が前提条件を直せるか、デリバリーの担当者が未確認の事項を把握できるかです。
DNA Makerは、営業に二重入力をさせずにデータをつなぐ、提案書の作業スペースの設計をお手伝いします。要件、製品、価格、契約条項、承認のデータモデルを設計し、修正がどこに影響するのかをユーザーが確認できる画面を用意します。ある顧客のデータが別の顧客の案件に使われないよう、権限も設定します。
私たちが納品する範囲は、プロトタイプ、システム連携、ルールのテスト、AIの評価、文書テンプレート、運用開始後の監視までです。実際の提案書を1種類選び、依頼内容の受け取りから承認までを試しに通してみることから始められます。営業、デリバリー、経理、そしてお客様側の契約担当者が一緒にロジックを確認してから、範囲を広げます。
DNA Makerは、営業用の作業スペース、提案コンフィギュレーター、CRM・ERP・文書管理との連携、AIによるレビュー機能、承認、バージョン管理を開発できます。価格、スコープ、情報漏えいについての評価や、受注後の引き継ぎ資料一式も含められます。
作成に時間がかかり、部署間で何度も修正が行き来する種類の提案書があれば、通った例と差し戻された例をお持ちのうえご相談ください。ルールを見つけ出し、作成期間（サイクルタイム）とスコープの質の両方を測れるプロトタイプを作ります。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
ここに挙げる用語は、提案内容の構成、価格、バージョン、受け入れ基準について話すときに使います。提案書を1か所直したとき、利益率、スコープ、承認のどこに影響するのかを、経営層は開発チームに答えてもらえるようにしておくべきです。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| CPQ | 製品構成（Configure）、価格設定（Price）、見積書作成（Quote）を行うシステム。選択肢、価格、例外を同じルールのもとで扱うので、売れても納品できない提案が減る | パッケージを選ぶと、ルールに沿って価格が計算される | 価格のルールはどこから来ていますか？ |
| Requirement Map | ニーズと制約を整理した構造。各ニーズを解決策、前提条件、受け入れ基準と結びつけるので、提案書のどの部分にも根拠があるかを確認できる | 課題を機能と受け入れ基準に結びつける | 要件は誰が確認していますか？ |
| Versioning | 複数の版を、後から確認できる形で保存すること。修正ごとに版番号、修正者、日時、変更点を残し、判断した日にどの文書やルールが使われていたかがわかるようにする | 提案書がどの月の価格を使ったかがわかる | 承認されたのはどの版ですか？ |
| Acceptance Criteria | 仕事が完了したと認めるための条件（検収の合格ライン）。観察やテストで確かめられる形にして納品前に合意しておけば、「問題なく使える」のように立場によって受け取り方が変わる表現を避けられる | システムが決められた形式でファイルを出力できる | この基準はテストで確かめられますか？ |
| CRM Integration | 顧客管理システム（CRM）とデータをつなぐこと。1回データを送れれば済むわけではなく、データの流れる向き、各レコードの責任者、データが食い違ったときの扱いを決めておく必要がある | 提案書と次のアクションが自動で記録される | 上書きしてはいけないデータはどれですか？ |
関連資料（原典）：https://openai.github.io/openai-agents-js/guides/guardrails/