INSIGHT
AIが書いた提案書で、未確認の機能と納期を約束するな
AIが書いた納期や対応範囲を、会社が引き受けられると確認したか。
顧客へ送る提案を、AIに読みやすく整えてもらった。「既存システムと自動連携」「三か月で本番稼働」「問い合わせへ常時対応」と書かれている。ところが、自動連携は試作段階で、顧客側の接続許可も、運用担当の体制も確認していない。
送信する前に、その三つの約束を抜き出す。文章を整えたことと、提供できる条件を確認したことは別である。機能、納期、対応条件の根拠がないまま、顧客が購入や準備を進める材料にしてはいけない。
未確認の機能・納期・対応条件を含む提案書は、提出、見積提示、契約への転記を止める。
いま差し戻すのは顧客への約束
停止する対象は、未確認条件を含む提案書の提出、その条件を前提にした見積り、契約・発注書への転記、顧客へ開始日を確約する連絡である。「予定」「対応可能」と言い換えても、顧客が購入や準備を判断する材料になるなら、確認なしに残さない。
AIで顧客の要望を整理する。提案の章立てを作る。技術担当へ確認するための初稿を用意する。これらの社内作業は続けられる。公開・提出用には、現在提供中、検証済み、顧客条件付き、開発予定、未確認を分け、未確認は約束欄から外す。
約束を引き受ける技術、日程、運用の担当へ、どの文と見積りを保留したかを渡す。確認のために必ず会議を開くという意味ではなく、誰がどの条件を確認したかを残す。提出期限が近い場合も、確認済みの現行機能だけで提案を作り直すか、顧客へ確認期間を伝える。期限を守るために根拠のない条件を残してはならない。
すでに顧客へ送っていたなら、社内のファイルを直すだけでは足りない。責任者に該当文と送付先を知らせ、何を訂正するか、顧客がその条件を前提に準備していないかを確認する。訂正版を再送した事実と、変更の説明を相手が受け取ったかを分けて記録する。
機能名を提供状態と試験結果へ結ぶ
「自動連携」「高度な分析」「リアルタイム対応」という機能名だけでは、顧客が使える範囲が分からない。提案書の各記述を、提供中、試作、検証済み、個別開発、外部サービス依存に分ける。
機能ごとに、対象利用者、動作する環境、扱うデータ、上限や除外、試験結果、仕様の所有者を結ぶ。社内の試作画面で動いたことと、顧客環境の権限・データ量・接続条件で提供できることは別である。「同様の仕組みで実現できる」と「今回の条件で提供を確認した」も同じにしない。
技術担当は文章の表現だけを校正するのではなく、顧客ができる操作と、できない条件を確認する。営業は、その境界を顧客が判断できる言葉へ直す。試験や仕様の根拠を示せない機能は、検討事項として社内に残し、提案の提供機能から外す。
納期を依存先と完了条件から組み立て直す
AIが過去の提案から「三か月」と書けても、今回の納期を見積もったことにはならない。開始に必要な顧客データ、接続許可、セキュリティ確認、外部サービス、社内担当、顧客レビューを並べ、それぞれの完了条件と担当を置く。
納期は、作業期間だけでなく、いつ開始できるか、何をもって完了とするかで変わる。試験環境の提供、データ移行、受入確認、本番切替、運用開始を同じ「導入」にまとめない。顧客側の作業や外部提供者の回答時期は、確定しているか、仮定かを示す。
遅延する可能性を並べて責任を避けるのが目的ではない。自社が引き受けられる日付と、顧客との共同条件を分けるためである。前提が未確定なら、確定日ではなく、確認する時点と日程を更新する方法を提案に書く。
納期は文章中の数字ではなく、開始条件、作業、依存先、完了確認を関係者が引き受けた結果である。
営業・技術・運用で約束の種類を分担する
営業は顧客の要望と提案範囲、技術は機能・環境・試験、プロジェクト責任者は作業・依存・納期、運用担当は対応時間・問い合わせ窓口・障害時の代替を確認する。決裁者は、未確認と制約を含めて会社が約束する範囲を決める。
NISTの2024年生成AI文書 は、虚偽の出力、人とAIの役割、第三者への依存、継続的な評価などを扱う任意のリスク管理資料である。提案書の法的効力、個別機能の実現性、納期を保証しない。ここでは、AIが作った文、会社が確認した条件、外部の依存先を分ける一般的な観点として使う。
承認表は「確認済み」の一欄にしない。機能、納期、運用・サポートの三欄に、確認者、根拠、制約、未確認を書く。どれかに異論があれば、その約束だけを外す、条件付きにする、顧客との確認へ戻す。担当の肩書きを並べるより、誰がどの約束を確認したかが分かる方がよい。
再開は約束の根拠と変更方法がそろってから
提案の提出を再開する条件は、文面が整ったことではない。少なくとも次を確認する。
- 顧客の要望と、自社が提案する範囲
- 各機能の提供状態、対象環境、制約、試験結果
- 開始条件、完了条件、作業、依存先から作った納期
- 運用時間、問い合わせ、障害・訂正時の対応
- 営業・技術・プロジェクト・運用の確認者と根拠
- 未確認事項を提案から外した、または条件として顧客へ示した記録
- 提出後に条件が変わったとき、社内再確認と顧客の変更合意へ戻す方法
七つがそろった範囲だけを提案へ戻す。検証中の機能は将来の検討として分け、確定納期へ含めない。提出後に前提が変わったら、AIで文だけ直さず、機能、金額、日程、責任分担の変更を社内で再承認し、顧客との合意へ戻す。
再開は提案書の完成ではなく、書かれた約束を会社が根拠と変更手順ごと引き受けた時点で決める。
提案書を送る前に、約束になる一文を抜き出して担当者へ確かめる
提案を送る前に、顧客への約束になる一文を抜き出す。機能なら試験と提供範囲、日付なら作業と前提、サポートなら対応体制へ戻り、引き受ける担当者へ確認する。根拠がない文は、読みやすく書けていても送らない。文章を作った本人が、確認すべき約束を見つけて渡すところから始める。