提案書や見積もりの説明文をAIで下書きする仕組みと作り方のポイント

提案書や見積もりに添える説明文は、顧客ごとに内容を変える必要があります。そのため、担当者が毎回、過去の文書を探しながら一から書いているという会社もあるでしょう。書く人によって表現や詳しさが違い、上司の確認に時間がかかることもあります。

こうした作業では、AIに下書きを作らせ、担当者が確認して仕上げる仕組みが考えられます。この記事では、提案書や見積もりの説明文をAIで下書きする仕組みと、作るときに気をつけたい点を順に見ていきましょう。

なお、ここで紹介する内容は一般的な構成の例です。実際の設計は、扱う商品や社内の承認の流れによって変わります。

説明文の作成に時間がかかる理由

提案書や見積もりの説明文を書く作業には、いくつかの手間が含まれています。顧客の要望を読み取り、それに合う商品や作業内容を選び、選んだ理由を分かりやすい文章にまとめる作業です。

多くの場合、参考にするのは過去に作った似た提案書でしょう。ただ、共有フォルダの中から似た案件を探すのに時間がかかったり、古い価格や仕様が残った文書を参考にしてしまったりすることがあります。

書き手による差も課題の一つです。経験の長い担当者は要点を押さえた説明を書けても、経験の浅い担当者は何を書けばよいか迷いがちです。AIによる下書きは、こうした手間と差を小さくすることを目的に検討されます。

下書きを作る仕組みの全体像

AIで説明文の下書きを作る仕組みは、おおむね次の流れで組み立てます。

1. 担当者が、顧客の要望や案件の条件を画面に入力する。
2. システムが、過去の提案書や商品資料から関係する部分を検索する。
3. 入力内容と検索結果をひな形とあわせてAIに渡し、説明文の下書きを作る。
4. 担当者が下書きを確認・修正し、提案書や見積書に組み込む。

2の検索には、社内の資料を検索してから回答を作るRAGという仕組みを使うのが一般的です。仕組みの詳細はRAGとは？社内の資料を参照して答えるAIの仕組みで説明しています。

3の「ひな形」とは、説明文の構成や見出し、書く順番を決めた型のことです。たとえば「お客様の課題」「ご提案の内容」「選定の理由」「進め方」のように構成を決めておけば、誰が使っても同じ形の下書きが出てきます。

下書きの質を左右する3つの要素

AIが作る下書きの質は、AIのモデルの性能だけで決まるわけではありません。実務では、次の3つの要素が大きく関わります。

1つ目は、参照する過去の提案書の選び方です。受注できた提案書や、上司が良い例として認めた文書を選んで登録すると、下書きもそれに近い書き方になりやすくなります。古い価格や終了した商品が書かれた文書は、登録の対象から外しておきましょう。

2つ目は、ひな形と指示文の作り込みです。文の長さ、使ってよい表現と避けたい表現、顧客の呼び方など、社内の書き方のルールを指示文に含めます。言葉で説明しにくいルールは、良い例と悪い例を添えると伝わりやすくなるはずです。

3つ目は、入力画面の設計です。担当者が自由な文章で要望を入力するだけでは、必要な情報が抜けることがあります。業種、予算の目安、希望の時期といった項目を入力欄として用意すれば、下書きに必要な情報をそろえやすくなるでしょう。

金額と条件はAIに書かせない

見積もりに関わる説明文で、もっとも注意が必要なのは金額や数量、納期などの数字です。AIは文章を作るのは得意でも、計算や数字の転記を間違えることがあります。

このため、金額や数量はAIに文章として書かせず、見積もりシステムや表計算ファイルの値をそのまま差し込む設計にしておくと安全です。AIには説明の文章だけを作らせ、数字の部分はシステムが埋める形にします。

値引きや支払い条件、保証の範囲のような契約に関わる内容も、AIに判断させるべきではありません。社内で決められた文言を固定の文章として用意し、条件に応じて選ぶ仕組みにするのが無難です。

最後に、担当者が提出前に必ず内容を確認する手順を残しておきます。AIの下書きは、あくまで担当者が仕上げるための材料として扱ってください。

汎用のAIツールで試す場合と開発する場合

まずは、汎用の対話型AIツールに過去の提案書の一部を貼り付けて、下書きを作らせてみる方法もあります。どのくらい役に立つかを確かめるには手軽な方法でしょう。ただし、顧客の情報や社内の価格を外部のサービスに入力してよいかは、事前に社内のルールを確認する必要があります。

汎用のツールで手応えがあれば、次の段階として専用のアプリを開発する選択肢が出てきます。専用のアプリでは、過去の提案書の検索、ひな形の固定、見積もりシステムとの連携、閲覧権限の管理をまとめて組み込むことも可能です。既製ツールと開発の比べ方は、既製のAIツールと独自開発、どちらを選ぶかで整理しています。

導入後に確かめたいこと

下書きの仕組みを使い始めたら、担当者がどのくらい手直ししているかを記録しておくと改善に役立ちます。修正の多い箇所が分かれば、ひな形や指示文、参照する文書のどこを直せばよいかが見えてくるはずです。

確かめたいのは、下書きを作ってから提出するまでの時間、上司の確認で差し戻された回数、担当者が使い続けているかどうかといった点です。導入前の状態も同じ観点で記録しておけば、効果を比べやすくなります。

使われなくなった場合は、その理由を担当者に聞いてみてください。入力の手間が多い、下書きの書き方が自社に合わないなど、理由によって直す場所は変わります。

打ち合わせメモから下書きを作る例

架空の業務支援会社が、問い合わせ管理の改善提案を作る場面を考えます。顧客の要望は「対応状況が分からなくなることを減らしたい」。候補は問い合わせ一覧と担当者への通知機能で、導入時期と予算は未確定という想定です。

AIへの入力は、メモを一つの文章に詰め込まず、確認できた事実と検討中の案を分けます。聞いていない条件を、AIが自然な提案書にするために補ってしまうのを防ぐためです。

期待する下書きは、「問い合わせごとに担当者と対応状態を記録し、一覧で確認できる運用をご提案します。既存メール環境との接続方法を確認したうえで、実装する範囲を決定します」という内容です。

「問い合わせの見落としを完全になくします」「翌月から運用できます」と書かれていれば修正します。前者は効果の保証、後者は未確認の納期を含むためです。文章の滑らかさより、確認済みの内容だけで提案しているかを先に見ます。

過去の提案書をそのまま使わない

過去の文書は、構成や説明の参考として役立ちます。ただし、その案件だけの価格、特別対応、顧客名が含まれている場合があります。新しい顧客への下書きに混ざらないよう、参照する範囲を整理してください。

たとえば、過去の提案から「課題を説明する順番」を参考にし、今回の提供範囲は現行のサービス説明から取り出します。過去の文書に書かれた実績や成果を、新しい案件の見込みとして書かせないことも必要です。

資料ごとに用途を分けると確認しやすくなります。「表現の見本」「現行仕様の根拠」「今回の条件」を区別し、どの部分を何のために渡すかを決めます。資料の状態に問題がある場合は、社内データの整理から進めると手戻りを減らせます。

下書きから提出までの確認手順

担当者は、まず顧客の課題と提案内容が対応しているかを確認します。今回の例なら、見た目の改善や分析機能の説明が長くても、担当者と対応状態を確認する話が抜けていれば、依頼に合っていません。

次に、未確認事項が断定へ変わっていないかを見ます。予算、開始日、利用人数、連携範囲などは、入力時の状態と照合します。未確認の項目を文章から削るだけではなく、次の打ち合わせで確認する項目として残すと、提案後の行動につながります。

最後に、固定の金額や契約条件を差し込み、見積書と説明文が一致するかを確認します。AIに金額を生成させない場合でも、別の案件の値を差し込む実装ミスはあり得ます。案件番号と見積もりの版を合わせ、提出対象が正しいことを確認してください。

修正履歴から改善する場所を見つける

修正が多かった文章は、「顧客の条件が不足」「資料の選択が違う」「ひな形が合わない」「根拠のない断定」に分けて記録します。すべてを指示文の問題として直すより、原因に合った対処を選べます。

たとえば利用人数を毎回聞き直しているなら入力欄を追加します。今回の対象外の機能が毎回入るなら、資料の選び方と対象外の指定を見直します。担当者が完成文を整えるまでの手間を追うことで、下書き生成だけが速くなった状態から、提出までの作業を改善できます。

まとめ

提案書や見積もりの説明文は、過去の文書と商品資料をもとにAIが下書きを作り、担当者が確認して仕上げる形にすると取り入れやすい業務です。下書きの質は、参照する文書の選び方、ひな形と指示文、入力画面の設計で大きく変わります。金額や契約条件はAIに書かせず、システムの値や固定の文言を使う設計にしておくと安心です。

最初は、件数の多い提案書や見積もりを一種類選び、良い例とされる過去の文書を集めるところから始めてみてください。

e-Grantsでは、RAGやLLMを使った文書作成支援などのAIアプリケーションについて、課題の整理から設計・開発、公開後の保守運用まで対応しています。提案書や見積もりの作成にAIを使いたい方は、AIアプリケーション受託開発のページをご覧ください。