AIビジネスの提案書に何を書く？自動化できる範囲を説明する

AIビジネスの提案書には、対象業務、完成するもの、AIが担う処理、人が確認する判断、実施条件を記載します。「自動化できます」だけでは、顧客が何を準備し、どこで責任を持つか分かりません。正常に動く場合と、対象外や停止時の対応を示すと、有料サービスとして買う範囲を判断しやすくなります。

提案の一枚目で、対象を限定する

冒頭に顧客のどの仕事を助けるかを書きます。「業務効率化」ではなく、問い合わせの分類、定期報告の下書き、支給資料の整理など具体的な工程にします。対象を広く見せるために、まだ確認していない仕事まで含めないようにします。

顧客が現在どう進めているかを聞き、提案によって変わる工程と残る工程を分けます。顧客が話した事実、こちらの理解、仮定を区別し、現状の説明も確認してもらいます。誤った現状から作る改善案は、機能が優れていても仕事に合わない可能性があります。

聞き取りの具体化は困る仕事を聞く方法へ渡せます。提案書は面談の記録を長く並べるものではなく、提供する仕事を合意するための資料です。

処理と判断を分けて図式化する

入力、AI処理、確認、承認、外部への反映という順番で書くと、どこまで自動にするかを示しやすくなります。AIが下書きを作ることと、顧客へ送ることは別です。外部送信や公開がある場合は、承認者と実行の条件を明記します。

処理を自動化する部分でも、情報不足や対象外の入力が来たときに止まれる条件が必要です。人が確認する場合は、誰が、何を見て、いつ返答するかを示します。「人が最終確認」と一行書くだけでは運用の負担を判断できません。

外注範囲の基本は依頼する工程と残す判断を参照できます。AIサービスの提案では、生成後の確認と、顧客の権限が必要な動作をさらに分けて示します。

仮定例：問い合わせ整理を提案する

仮定として、企業へ問い合わせの分類と担当者向け要約を提供するとします。対象は、指定の受付窓口へ届く文章です。AIが分類と要約を行い、人が内容を確認して担当部署へ渡します。顧客への返信や契約の判断は含めません。

提案書には、分類の候補、要約の項目、対象外の相談、人へ渡す条件を記載します。顧客が情報を確認できない場合、すべての問い合わせを自動対応する提案には変えません。限定した範囲を示し、必要なら別工程として検討します。

この案件の詳細は問い合わせ対応支援の分担へ渡せます。提案書へ業界全体の成功率や削減額を置くのではなく、この顧客の対象と試行条件を示すことが重要です。

含まない仕事を書く理由

対象外には、自分が判断できない専門事項、提供しない開発、無期限の保守、未確認の外部連携などがあります。顧客が当然含まれると思いやすい工程を優先して書きます。注意書きを大量に並べるより、目的を達成するために誰が担うかを示す方が理解しやすくなります。

例えば原稿制作だけを提供するなら、サイトへの公開、画像の購入、公開後の分析が含まれるかを分けます。顧客の代わりに商品条件を決める仕事まで含めないことも示します。提供範囲が狭いから不十分とは限らず、必要な仕事を選べる提案にできます。

発注設計の情報は依頼前に揃える条件へ渡せます。提案側も、顧客へ何を用意してもらえば約束した仕事をできるかを具体化する必要があります。

実施条件に、顧客の準備を含める

支給資料、アクセス権、担当者、確認時間、使用環境を列挙します。顧客が準備できるか、準備にどれくらい時間がかかるかを確認します。資料が未確定の場合は、情報整理を先に行う案や、対象を限定して試す案を示します。

顧客の情報をAIへ入力するなら、使用する環境とデータの扱いを説明します。許可が必要な条件を、料金を了承したから自動的に満たしたと扱わないようにします。基本はAI利用契約と入力情報へ渡せます。

既存ソフトの権限が必要な場合は、何を閲覧し、何を変更するかを示します。作業に不要な管理権限を受け取らない設計も検討します。接続できることと、顧客がその操作を許可していることは別です。

効果の説明は、仮説と確認方法に分ける

「時間を減らせる可能性がある」という仮説なら、現在の時間と導入後の全作業を比較する方法を示します。生成だけでなく、入力、点検、修正、承認を含めます。試作で短い出力が出たことを、そのまま業務改善の実績として紹介しません。

品質の評価も具体化します。必要な項目がある、原情報と一致する、対象外では止まる、顧客が使用できる形式などを確認します。評価者と対象の例を決め、好みと事実の誤りを分けます。

試行へ進む場合は有料で確かめる条件を使えます。提案時点で分からない効果を保証するより、何を測り、どの結果で本格導入を判断するかを合意します。

日程と料金を、工程へ対応させる

調査、構成、制作、確認、修正、納品の順に日程を示します。顧客の返答待ちを含む工程では、必要な返答の時期を明記します。遅れた場合にどの納期へ影響するか分かる形にします。

料金には各工程の対象と、追加になる条件を示します。月額の支援なら何が毎月提供されるか、納品型なら何を受け取れば完了するかを分けます。見積書の基本は納品物と別料金を参照できます。

新しい対象を追加するときは、同じ料金へ含められると推測しないようにします。情報、確認、連携の条件が違えば原価も変わります。顧客へ変更の影響を示してから合意します。

停止と終了を提案書に置く

情報不足、利用環境の変更、誤り、顧客の中止などの場合に誰へ連絡し、どの処理を止めるかを示します。代替の手作業や元へ戻す方法が必要なら、その範囲も説明します。受託側が不在でも顧客が状況を確認できる記録を用意します。

契約終了後の成果物、資料、履歴、アクセス権をどう扱うかも記載します。導入時の便利さだけでなく、やめる際の負担を理解できることが、法人の判断を助けます。実際の権利や保存条件は、個別の契約と情報に合わせて確認してください。

提出前に三つの資料を照合する

提案を短くする場合も、条件へ戻れる参照先を残します。商談の説明用の一枚には目的と範囲を置き、詳細の資料に情報管理や停止の手順をまとめる方法があります。短い資料だけが社内で共有されても、全自動や無制限の対応と誤解されない表現にします。

顧客から質問が来たら、提案書のどこが不明だったかを記録します。同じ質問が続くなら、口頭で補うだけでなく資料へ反映します。条件の変更を求められた場合は、変更後の版を作り、過去の版との違いを示して承認してもらいます。

説明を終えた段階では、発注が確定したかを別に確認します。好意的な返答や社内検討の了承は、作業開始の許可とは限りません。契約と必要な情報が揃う前に、本制作を進める計画にはしないようにします。

提案書、見積書、作業案内で対象と条件が一致しているかを点検します。提案書では全自動、見積書では下書きのみ、といった不一致を残さないようにします。顧客の協力、確認、追加料金も同じ条件に揃えます。

提案に向くのは、実際に担える工程を説明し、対象外と実施条件を共有できるサービスです。AIで何でもできるという印象を作るより、顧客が何を依頼し、どの判断を残すかを選べる資料にしてください。