提案書をAIでチェックする｜顧客要望とのズレを確認する活用例

提案書をAIでチェックするときは、顧客の要望と提案文を対応させ、「抜けている要望」と「根拠なく追加した約束」を両方向から確認します。文章が整っているかに加え、対象範囲、納期の意味、提供する成果物が合っているかを見る作業です。

この記事は、すでに作った提案書を顧客へ送る前の点検を扱います。サービス紹介PDFの改訂を題材にした架空の例で、実際の顧客案件、受注実績、特定のAIを実行して得た出力ではありません。

顧客の要望・提案書・自社の対応条件を揃える

顧客の要望と提案書の二つだけでも、記載の抜けや食い違いを探せます。ただし、「こちらがその条件を提供できるか」を見るには、自社で確認した対応範囲も必要です。

材料	確認できること	その材料だけでは決めないこと
顧客のメール・商談記録	希望、困っていること、必要な場面、対象外の範囲	自社が受けられる納期や、合意済みの提供条件
作成済みの提案書	何を提供すると書いたか、どの日付を約束したか	顧客がその条件を承認したか
自社の確認済み対応条件	標準の成果物、対応できる範囲、別途確認が必要な項目	今回の案件でまだ決めていない例外

資料には短い番号を付け、AIが示した指摘を原文へ戻せるようにします。商談記録に「できれば」「社内で確認中」と書かれている場合、その部分を取り除いて確定条件に変えないことも確認点です。

架空例：12ページの資料改訂に、余分な約束が混ざった

顧客から届いたメールの内容を、確認用に項目へ分けた例です。Rは顧客の要望、Pは提案書の記載、Cは自社の対応条件を表します。

【顧客の要望】
R1：日本語12ページのサービス紹介PDFを改訂したい。
R2：原稿と写真は支給する。追加撮影は不要。
R3：11月6日の営業会議で内容を確認したい。
R4：編集可能なデータが必要かどうかは、社内で確認中。
R5：英語版は今回は対象外。
R6：事例ページに、導入のプロセスを載せたい。

【作成済みの提案書】
P1：日本語12ページのサービス紹介PDFを納品します。
P2：写真撮影からデザインまで、一式で対応します。
P3：11月6日までに最終納品します。
P4：編集可能なPowerPointデータを標準で納品します。
P5：日本語版と英語版を同時に制作します。

【自社の確認済み対応条件】
C1：支給された原稿・写真を用いた日本語PDFの編集・デザインを扱う。
    追加撮影は今回の対応範囲に含めない。
C2：標準の成果物はPDF。編集データの提供は、要否と形式を確認して別途調整する。

P1はR1と対応していますが、それだけで提案全体が適合しているとは言えません。撮影や英語版が加わり、顧客が内容を確認したい日が最終納品日に変わっています。さらに、事例ページへ何を載せたいかが提案から抜けています。

六つの要望を照合し、修正と確認を分ける

次の表は、上の架空資料からMakeAIが作成した照合例です。「提案文を直せる項目」と「顧客や社内へ確認する項目」を同じ扱いにしません。

対応関係	見つかる問題	次の対応
R1 ↔ P1	日本語・12ページ・PDFは一致	この範囲を維持し、他の文と矛盾しないか確認
R2・C1 ↔ P2	不要で、対応範囲にもない追加撮影が入っている	支給写真を使用する記載へ修正
R3 ↔ P3	会議での内容確認という希望が、最終納品の約束に変わっている	会議時点で必要な完成度、初稿日、最終納品日を確認
R4・C2 ↔ P4	要否も形式も未確定なのに、PowerPoint納品を標準扱いしている	編集データの必要性と提供条件を確認事項へ戻す
R5 ↔ P5	対象外の英語版が追加されている	今回の範囲から外す
R6 ↔ 対応する記載なし	導入プロセスを載せたい要望が抜けている	事例ページの構成へ反映し、必要な原稿を確認

「日付が一致しているから問題なし」というチェックでは、R3とP3の違いを見落とします。同じ日付でも、初稿の提出、内容の確認、最終納品では行うことが違います。数値だけでなく、その条件が何を意味するかまで照合します。

提案へ新しいアイデアを加える場合は、必須の対応範囲と、任意の提案を区別します。顧客が求めていないものを提案すること自体が誤りではありませんが、合意済みの標準内容のように混ぜると、何を確認すべきかが分からなくなります。

AIには、要望からと提案書からの二方向で点検させる

要望から提案書を見ると、抜けを探せます。提案書から要望や自社条件を見ると、どこにも根拠のない約束を探せます。片方だけで点検すると、すべての要望に答えていても、余分な納期や成果物を追加した文が残ることがあります。

Anthropicの公式プロンプトガイドでは、長い文書を扱う際に関連する箇所を先に抜き出す方法が説明されています。ここでも、評価だけを出させず、指摘の元になった資料と記載を残す形にします。

作成済みの提案書を、顧客へ送る前に点検してください。

材料：
R：顧客の要望・商談記録
P：提案書の本文
C：自社の確認済み対応条件

まず、各資料の条件に番号を付けて整理してください。
次に、二方向で照合してください。
A. 顧客の要望ごとに、提案書の対応箇所を探す。
B. 提案書の約束ごとに、顧客の要望または自社条件の根拠を探す。

出力：
・元の条件と、提案書の対応箇所
・一致／抜け／食い違い／未確定の断定／任意提案としての確認が必要
・その判断に使った短い記載と資料番号
・その場で直す候補
・顧客または社内へ確認する項目

同じ日付でも、初稿・確認日・最終納品日を区別してください。
「希望」「検討中」を「合意済み」に変えないでください。
根拠がないことと、提供できないことを同じ意味にしないでください。
提案書の採否や受注確度は採点せず、確認用の指摘表だけを作ってください。

AIが挙げた「一致」も確認対象です。資料番号が存在するか、条件の一部分だけを拾っていないかを見ます。文章を丸ごと書き換える前に指摘表を確かめると、変更理由を追いやすくなります。

直せる文を直し、決まっていない条件は残す

架空例では、支給素材、日本語PDF、英語版を対象外にする点は、材料から修正できます。範囲の説明を整えた編集例は次のとおりです。

ご支給の原稿と写真を用いて、日本語12ページのサービス紹介PDFを改訂します。事例ページには導入プロセスを示す構成を含めます。今回の制作範囲に、追加撮影と英語版の制作は含めません。

一方、11月6日までにどこまで仕上げるかと、編集データの扱いは、確認後に確定する項目です。提案書の完成稿にする前に、次の確認メモを残します。

確認1：11月6日の営業会議では、構成案・初稿・最終版のどれが必要か。
確認2：その確認結果をもとに、初稿の提出日と最終納品日を設定できるか。
確認3：編集データは必要か。必要なら、形式と提供範囲をどうするか。
確認4：導入プロセスの説明に使う、支給原稿と写真は揃っているか。

これは未確定事項を置き換えるために作った候補です。実際の調整結果を反映し、担当者が確認してから提案書を送ります。「要確認」の印を消すだけで、条件が決まったことにしないようにします。

送信前には、修正後に増えた約束も確認する

AIへ修正を頼んだ後、新しい文に「無料で対応」「回数の制限なし」「必ず間に合う」などの条件が加わっていないかを見ます。元の指摘が解消されても、別の箇所で提供範囲が広がっていれば、もう一度根拠へ戻します。

この点検では、表現の自然さ、誤字、社内の承認などを別の確認として残します。要望との一致だけで提案全体の採否は決まりません。まず一つの提案書について、担当者が原文へ戻れる指摘表を作り、どの確認が必要かを共有するところから始めてください。

資料の版と対象を固定してから照合する

顧客のメールが複数あり、提案書も何版かある場合は、今回どの材料を照合するかを先に決めます。古い要望へ新しい提案書を当てると、既に合意して変更した内容まで食い違いとして出ることがあります。対象資料の名称、日付、版、適用する案件を記録してください。

案件：［案件名・識別番号］
要望の資料R：［メールの日付、商談記録の版］
提案書P：［ファイル名、版、作成日］
自社条件C：［対応範囲の資料、確認日］
今回は使わない旧案：［旧版と除外理由］
追加の合意：［誰と、いつ、何を変更したか。記録があるもの］

「最終版」というファイル名だけで決めず、担当者が送付予定の版を確認します。添付資料に価格表やスケジュールがあるなら、それも対象へ含めます。本文には正しい納品日があっても、別添の工程表に古い日付が残る場合があるためです。

要望を一つずつ対応させ、未記載と対象外を区別する

要望の対応表では、記載が見つからなかった項目と、明示的に対象外にした項目を分けます。R6の導入プロセスは提案に必要な内容が抜けた状態ですが、R5の英語版は顧客が今回の対象外とした内容です。同じ「書かない」でも意味が違います。

状態	判断する材料	対応表に残すこと
対応あり	要望と提案の具体的な箇所	一致する条件と参照位置
未記載	要望はあるが提案に対応箇所がない	追加する内容と、材料が足りるか
対象外	顧客または自社の確認済み条件	対象外の根拠と提案での示し方
未確定	希望や確認中という記録	確定する人と必要な質問
任意の追加提案	必須範囲から独立した提案	実施の可否、費用、日程を確認する条件

AIが提案書の別の箇所を対応先として挙げた場合も、同じ要望へ答えているかを確認します。「事例を掲載」とだけ書いてあっても、顧客が求める導入プロセスまで含むとは限りません。語が似ているかではなく、相手が求めている成果物と内容が揃っているかを見ます。

優先して直すのは、作業と約束が変わる食い違い

指摘が多い場合は、まず対象範囲、成果物、金額、日程、承認条件など、後の作業が変わる点から確認します。言葉の細かな重複や語尾は、その後で整えます。AIの指摘件数が多いこと自体を、提案書の良し悪しの点数にする必要はありません。

今回の例では、追加撮影と英語版の混入を先に直し、11月6日に必要な完成度と編集データの要否を確認します。その後で、導入プロセスを掲載する構成と必要な支給素材を詰めます。編集データが必要か不明な段階で、形式をPowerPointへ決めることはしません。

指摘ID：F-03
対象：P3「11月6日までに最終納品」
根拠：R3は「11月6日の営業会議で内容確認」
判断：同じ日付だが、作業の意味が異なる
修正候補：会議用に必要な状態を確認し、初稿と最終納品を分けて記載する
確認する人：［営業担当と制作担当］
完了条件：確認結果を提案書とスケジュールの両方へ反映する

確認先を決めずに「要確認」とだけ残すと、提案書の締め切りまで未確定が残る場合があります。誰が何を確認し、どの文へ反映すれば完了かを一緒に書くと、担当者へ作業を渡しやすくなります。

修正後は、直した条件だけでなく関連する箇所も見る

撮影を範囲から外した場合、作業内容の一文だけを直しても、工程表の「撮影日」や料金内訳の「撮影費」が残るかもしれません。提案書全体で関係する表現を探し、同じ条件へ揃えます。AIには、指摘した項目が影響する箇所を一覧にする補助を頼めます。

F-02の修正により、追加撮影は今回の範囲へ含めません。
提案書全体から、撮影を前提としている記載を探してください。
作業内容、成果物、工程、料金の説明、顧客へ依頼する準備を分けて示します。
まだ文を変更せず、該当箇所と、今回の条件に合わせて確認する点を出してください。

この確認では、新しい条件へ合わせるためにどこを直すかを探します。顧客が支給する写真の確認や素材の受領まで不要になったとは限りません。追加撮影を外したことと、写真を使わないことを混同しないようにします。

営業と制作の確認結果を、一つの表へ集める

営業担当は顧客の希望を把握していても、制作側が日程と形式を提供できるかは別途確認する必要があります。逆に制作側が実現できる案でも、顧客が求めているとは限りません。指摘表に顧客確認と社内確認の欄を設け、どちらが終わったかを区別します。

たとえば編集データについて、顧客が必要と回答しただけでは、形式、納品範囲、費用が全て決まったわけではありません。自社の提供条件を確認し、提案書へ反映してから送付します。確認記録は口頭の記憶だけでなく、後から担当者が参照できる場所へ残してください。

最後に、全ての修正指摘が解決したか、未確定が残る場合は提案書上でどう示したかを確認します。「AIが問題なしと答えた」を承認の代わりにはせず、顧客へ送る担当者が条件を確認します。元の要望を整理する段階なら、商談メモを事実・仮説・未確認・次の行動に分ける方法から準備できます。