提案・見積
提案書ファクトチェック(人間検証必須化CL)
社外に出す提案書のドラフトを、根拠資料に照らして1記述ずつ検証するプロンプトです。裏の取れない数値・実績・相手企業への断定を「要検証」として拾い出し、人が最終確認するための一覧に落とします。提案書 ファクトチェック AIの使い方として、AIに提案を書かせるのではなく、書いた提案の裏取りを漏れなくやらせる使い方です。

必要データと準備
用意するのは2種類です。
- 提案書ドラフト:チェック対象。社外に出す予定の本文をそのまま貼ります。
- 根拠資料(裏取りに使える一次情報):自社の製品仕様・料金表・実績データ・過去の事例、そして相手企業との商談議事録。ここに書かれていない情報は、すべて「裏付けなし=要検証」として扱われます。つまりこの資料の充実度が、チェックの精度をそのまま決めます。
商談議事録は、相手企業に関する記述(課題・体制・決裁)の裏取りに効きます。「相手が実際にそう言ったか」を照合できるからです。文字起こしの取り方は共通ガイドを参照してください。提案書・社内資料を外部AIに貼る際は、社外持ち出し・個人情報の扱いに注意してください。
プロンプト本文
あなたは、社外に出す提案書のファクトチェックを担当する検証アナリストです。
提案書ドラフトに書かれた記述を1つずつ、根拠資料に照らして「事実か・推測か・裏が取れないか」を判定し、裏の取れない記述を漏れなく洗い出して、人の最終確認(担当者・有識者レビュー)に回すためのチェック結果を作成してください。
この提案書は相手企業に提示するものです。裏の取れない断定(特に数値・実績・機能・相手企業に関する記述)が残ると、提示した側が責任を問われ得ます。あなたの役割は「文章を良くする」ことではなく、「裏の取れない記述を漏れなく拾う」ことです。
## 提案書ドラフト(チェック対象)
{社外に出す予定の提案書ドラフトの本文をここに貼り付け}
## 根拠資料(裏取りに使える一次情報)
{自社の製品仕様・料金・実績・事例・過去の議事録など、記述の裏付けに使える社内資料をここに貼り付け。ここに無い情報は「裏付けなし」として扱われます}
## 提案の前提(分かれば)
{提案先の企業名・部署/提出先(誰が読むか)/提出予定日。分からなければ「未定」と書く}
## 出力フォーマット
1. チェック結果一覧(提案書のうち、事実・数値・固有名詞・相手企業への言及を含む記述を中心に1つずつ拾い、下記の表で判定する)
| 提案書の記述(原文を短く引用) | 判定 | 根拠(資料の該当箇所を短く引用/無ければ「該当なし」) | 信頼度 | 人間確認 |
- 判定: 「事実(資料に一致)」「推測(資料から導けるが断定は飛躍)」「要検証(資料に裏付けなし・または矛盾)」の3区分
- 信頼度: 高/中/低
- 人間確認: 「不要」または「要(誰に確認すべきか)」
2. 特に危ういトップ3(このまま出すと責任問題になり得る記述。数値・実績・相手企業に関する断定を優先して選ぶ)
3. 送信前の必須確認リスト(提案書を相手に出す前に、人が裏を取るべき項目をチェックボックス形式で。金額・数値・固有名詞・導入時期・相手企業の事実を優先)
4. 判定できなかった記述(根拠資料が不足していて、事実とも要検証とも言い切れないもの。何の資料があれば判定できるかを添える)
## 注意事項
- 根拠資料に書かれていることだけを「事実」と判定する。資料に無い記述は、内容が正しそうに見えても「要検証」とする(「それらしさ」で事実判定しない)
- 事実(資料に裏付けがある)と、あなたの推測を必ず区別する。推測は判定欄で「推測」と明記し、断定に書き換えない
- 資料に出所のない数値・実績・導入社数・効果(「○%改善」「導入○社」等)を「正しい」と判定しない。必ず「要検証」に落とす
- 相手企業に関する記述(課題・体制・現状・決裁)で、根拠資料(議事録等)に相手の発言・記載が無いものは「要検証」とする。相手が言っていないことを「合意済み」として通さない
- 競合他社に関する記述は、根拠資料に事実の裏付けが無い限り「要検証」とする。自社の想定・見解を、相手企業に断定として提示させない
- 判定に迷う記述は「要検証・信頼度低」に倒す。迷いを事実側に丸めない
- 資料が足りず判定不能な記述は、無理に判定せず「4. 判定できなかった記述」に置き、必要な資料を書く
- 引用は提案書・資料の原文を短く抜き出す。要約で言い換えない
- このチェックはあくまで一次スクリーニング。「要検証」「人間確認: 要」と付いた記述は、必ず人(担当者・有識者)が最終確認してから社外に出すこと。AIの判定だけで社外提出しない
- 提案書・社内資料を外部AIに貼る際は、社外持ち出し・個人情報の扱いに注意するこのプロンプトを動かしてみる
プリセットされた依頼のまま「送信」を押すと、AIの応答がその場でストリーミング表示されます(架空データに対する収録済みの応答。生成AIは呼び出しません)。
AIに渡した入力データ(架空サンプル)
1. チェック結果一覧
提案書の記述(原文を短く引用) | 判定 | 根拠 | 信頼度 | 人間確認 |
|---|---|---|---|---|
「月末の締めに田中様おひとりで3日かかっている」 | 要検証(矛盾) | 議事録「私ともう1人で3日はかかっています」=2名で3日 | 高 | 要(田中様に人数・工数を確認) |
「締め工数は平均70%削減されます」 | 要検証 | 該当なし(資料に「70%」の裏付けなし) | 高 | 要(実測・出所を営業企画で確認) |
「導入実績は全国1,200社」 | 要検証 | 該当なし(資料に導入社数の記載なし) | 高 | 要(社数の一次データを確認) |
「御社が利用中の給与ソフトともAPI連携済みです」 | 要検証 | 資料に「既存の給与ソフトとのAPI連携が広い」はあるが相手のソフト名は議事録に未出現。特定ソフトとの連携可否は裏付けなし | 高 | 要(ソフト名を確認→連携可否を技術側で確認) |
「1人あたり月400円〜、初期費用20万円〜」 | 事実 | 製品概要に一致 | 高 | 不要 |
「田中様も『これなら回る』と評価されています」 | 要検証(矛盾) | 議事録では佐藤様が「田中が言ってくれないと上げにくい」と発言。田中様の評価発言は未出現 | 高 | 要(田中様の評価を実際に確認) |
「四半期の投資枠内で決裁いただけます」 | 推測 | 「四半期ごとの投資枠」「取締役会」は事実だが「決裁いただける」は相手が明言していない | 中 | 要(断定を弱める) |
「他社の労務SaaSは中堅企業には機能過多で、貴社には不向きです」 | 要検証 | 該当なし(競合の弱点・相手への不向きは事実の裏付けなし) | 高 | 要(断定を削り比較は事実ベースに) |
2. 特に危ういトップ3
- 「締め工数は平均70%削減されます」:出所のない効果数値。根拠を問われて説明できないと提示側の責任問題になり得る。
- 「田中様も『これなら回る』と評価されています」:相手が言っていないことを合意済みとして記載。面談で否定され信頼を損なう。
- 「給与ソフトとAPI連携済み」:相手のソフト名すら未確認。非対応だった場合、契約後のトラブルに直結する。
3. 送信前の必須確認リスト
- 締め工数「おひとりで3日」→ 議事録は「2名で3日」。修正
- 「70%削減」→ 出所を確認。無ければ削除または「試算」と明記
- 「1,200社」→ 一次データで裏取り。取れなければ削除
- 相手の給与ソフト名を確認→連携可否を技術側で確認してから記載
- 「田中様も評価」→ 実際の評価を確認できるまで削除
- 「決裁いただけます」→ 「ご検討いただける想定」等に修正
- 競合への「不向き」断定→削除し比較は自社の事実に限定
4. 判定できなかった記述
- 「導入は最短2週間で完了します」:資料に導入期間の記載なし。判定には標準導入スケジュールの社内資料が必要。
(注記: 「要検証」「人間確認: 要」の記述は一次スクリーニング結果です。社外提出前に必ず人が裏を取ってください)
カスタマイズのヒント
- RFP・仕様回答に使う:「提案書ドラフト」をRFP回答ドラフトに、「根拠資料」を検証済みの製品仕様・回答ライブラリに差し替える。相手要件を満たすと書いた項目が本当に対応済みか、機能単位で「要検証」を拾える
- セキュリティチェックシートに使う:回答ドラフトを、社内のセキュリティポリシー・認証取得状況の資料に照らす。取得していない認証を「取得済み」と書いていないかの検出に効く
- 数値の厳しさを上げる:注意事項に「出所が数値そのものを名指ししていない場合はすべて要検証にする」を足すと、丸めた数値・約数の混入も拾いやすくなる
- 相手企業の事実に絞る:レビュー時間が短いときは、出力フォーマットを「相手企業に関する記述だけ」に限定すると、否定されて信頼を損なう箇所を優先的に潰せる
よくある質問
ファクトチェックはAIだけで完結できますか。
できません。このプロンプトの出力は「人が確認すべき箇所のリスト」で、確認そのものは人が行う前提です。AIの誤った出力について提示企業が責任を問われた事例(Moffatt v. Air Canada、判例)があるとおり、社外に出す提案は「要検証」フラグの付いた記述を人が裏取りしてから確定します。AIは見落としを減らす一次スクリーニングとして使ってください。
根拠資料が少ないと精度は落ちますか。
落ちます。判定は「渡した根拠資料に書かれているか」で決まるため、資料が薄いと多くの記述が「要検証」や「判定できなかった記述」に落ちます。裏取りしたい範囲(製品仕様・料金・実績・相手企業の議事録)をできるだけ揃えるほど、事実と要検証の切り分けが明確になります。
相手企業の課題や決裁の記述もチェックできますか。
商談議事録を根拠資料に含めれば可能です。相手が実際にその発言をしたかを照合し、議事録に無い断定は「要検証」として拾います。相手が言っていないことを「合意済み」のトーンで書いてしまう事故の検出に効きます。
