IT営業の提案書に生成AIを使うなら、最初に任せる工程を決め、出力された技術説明を根拠へ戻して確認できる形にします。構成案や文章の下書きが整っても、機能、対応条件、費用、納期が確認されたとは限りません。
本記事では、取得済みの商談情報と製品資料を使い、下書きから確認までを進める方法を紹介します。特定のAIサービスの推奨や、作成時間の短縮実績を示すものではありません。
生成AIへ任せる工程を小さく決める
まず、提案書の全体を一度に完成させるのではなく、対象工程を決めます。例えば、入力済みの情報から見出しを作る、重複した説明を整理する、確認が必要な主張を一覧にする、といった使い方です。
IPAの教材は、生成AIの出力がもっともらしくても事実ではない場合があることを説明し、信頼できる情報源で確認するよう案内しています。IPA「ツール利用」17ページ
AIが書いた文を「そのまま使える説明」と「確認するための仮案」に分ける工程を、最初から作業に含めます。技術的な実現可否や個別の契約条件を、文章の自然さだけで判断しないことが基本です。
1. 入力する資料と条件を整理する
利用するAIについて、社内で認められた用途、入力できる情報、保存や共有の設定を確認します。IPAの教材も、個人情報や機密情報の入力に注意し、利用規約・設定と社内ポリシーを確認するよう示しています。生成AI利用時の注意点
入力に使えると確認した資料には、参照先と版を付けます。以下は整理例です。
| 入力 | 残しておく条件 |
|---|---|
| 顧客の課題 | 誰のどの発言か、確認済みの範囲 |
| 必須の要件 | 合意済みか、担当者の希望か、未確定か |
| 製品・サービス資料 | 版、確認日、該当するプランや構成 |
| 価格や納期 | 有効な条件、社内で確認した範囲 |
| 対象外の事項 | 今回は提案しない機能、別途確認する作業 |
顧客名を置き換えただけで、他の情報も入力可能になるとは限りません。契約条件、構成情報、組み合わせから分かる案件情報も含め、共有できる範囲を確認します。入力できない資料を必要とする場合は、その資料をAIへ渡さず、人が確認する工程へ分けます。
2. 文章と根拠の対応表を一緒に作らせる
提案書の下書きだけでなく、「何を根拠に書いたか」を出力させると、確認対象を並べやすくなります。次は、利用が認められた資料を渡す場合の指示例です。特定の出力品質を保証するものではありません。
目的：ITシステム導入の提案書の構成案を作成する。
使用する情報：添付した利用許可済み資料A・Bと、確認済み要望の一覧。
出力するもの：
1. 提案書の見出しと各節の要点
2. 技術的な主張ごとの対応表
主張／根拠資料と箇所／適用条件／未確認事項
3. 提案前に確認が必要な質問
条件：
資料にない機能、実績、数値、価格、納期を補わない。
根拠がない箇所は「未確認」とする。
条件付きの機能から、その条件を省略しない。
顧客の希望と、実現可能と確認された事項を分ける。資料への参照が出力されても、実際にその箇所があるかを確認します。指示に従った形式になっていることと、内容が正しいことは別だからです。
3. 技術的な主張を、原文と適用条件へ戻して確認する
次の表は、架空の製品資料を使った確認例です。実在製品の機能や自社の提供条件を示していません。
| AIの下書き | 資料の記載・状況 | 確認後の扱い |
|---|---|---|
| 既存システムと自動連携できる | 特定の接続方式だけが記載されている | 対象システムがその方式に対応するか確認 |
| すべてのデータを移行できる | 一部のデータ形式のみ対応と記載 | 対応形式へ限定し、残りを未確認にする |
| 運用作業を半減できる | 削減量を示す根拠がない | 数値を削除し、検証する項目へ戻す |
| 来月から利用できる | 個別の導入日程は未確認 | 日程を確約せず、必要な作業と確認先を整理 |
確認するのは文の正誤だけでなく、その説明が今回の顧客条件に当てはまるかです。公式資料に機能があっても、プラン、地域、バージョン、構成などの条件が合わなければ、今回の提案で利用できるとは限りません。
資料間で説明が違う場合は、更新日と対象範囲を確認し、解消するまで断定を避けます。根拠を確認できない主張は、追加調査する、表現を限定する、提案から外す、のいずれかで扱います。
4. 顧客の要望と提案する範囲を照合する
技術説明が正しくても、顧客が解決したい課題と一致しているかは別に確認します。IPAの要件定義の解説は、業務上の要求を整理し、システム化要求へ具体化する流れを示しています。IPA「要件定義とは？」
例えば「二重入力を減らしたい」という課題に対し、提案が画面の見た目の改善だけになっていないかを確認します。この場面は説明用の仮例です。見た目の改善が不要という意味ではなく、目的との対応を確かめるための問いです。
確認表には次を残します。
- どの要望に、どの提案項目が対応するか。
- 対応しない要望と、その理由は何か。
- 顧客側で必要な作業や、利用上の前提は何か。
- 実現性が未確認の項目を、確定事項と混ぜていないか。
文章を整える際にも、対象外や条件の記載を削らないようにします。「簡潔にする」という修正で、提案の意味が変わっていないかを確認してください。
5. 提出前の確認と、試行の評価を分けて残す
社外へ渡す版では、技術説明を担当者が確認し、価格・納期・対応範囲は社内の決められた確認経路で確定させます。AIの下書きから修正した箇所と、残る未確定事項も記録しておくと、次の提案で古い条件を流用していないか確かめられます。
IPAの情報セキュリティ解説も、生成AIの回答の検証を省かないよう注意を促しています。IPA「情報セキュリティ10大脅威2025」生成AIのコラム、31〜32ページ
試行の良し悪しは、下書きの生成時間だけでなく、根拠確認と修正にかかった時間、見つかった誤り、確認できずに削除した主張も含めて振り返る方法があります。数件の試行だけで受注率の改善を断定せず、まずは同じ種類の資料で、品質を保って作業を進められるか確認します。
最初は一つの提案書の一節を対象にし、文章と根拠の対応表を作るところから始めてください。提案に必要な情報整理や技術担当との連携を含む職務全体は、IT営業の仕事内容でも紹介しています。