AIで提案書のたたき台を作る方法｜要件整理から構成まで

AIで提案書のたたき台を作るときは、最初に「相手が決めたいこと」と「提案側が確認できている事実」を分けます。AIに完成版を一度で書かせるのではなく、要件票、構成、複数案、本文、レビューの順で進めると、もっともらしい数字や約束が混ざったときに修正箇所を特定できます。AIは情報整理と文章化の補助役です。提案の範囲、価格、納期、効果を決めるのは担当者です。

書き始める前に意思決定を一文にする

提案書の依頼を受けたら、まず相手に何を判断してもらう文書かを一文で置きます。「導入するか」「どの案を選ぶか」「調査を始めるか」では必要な資料が違います。次に、現在の状況、課題として聞いた内容、裏付け資料、まだ分からないこと、提案側の仮説を分けて記録します。「問い合わせが増えた」は集計で確認できる事実かもしれませんが、「新しい広告が原因」は追加調査前なら仮説です。相手の発言を要約するときは、発言日や出所も残し、提案側の解釈と混ぜないようにします。

要件票には次の列を作ると実務に使えます。

• 項目：相手の目的、現状、制約、期限、予算、関係者、承認者。

• 内容：依頼者が実際に伝えた情報。資料の箇所や会話日も添える。

• 区分：確認済み／相手に確認中／提案側の仮説／未定。

• 提案書での扱い：記載、条件付き記載、保留。

• 確認先：誰がいつまでに確定するか。

予算や期限が分からないのに「一般的にはこの程度」と補うと、読者はそれを確定条件と受け取ることがあります。未確認のままでも構成案は作れますが、価格・納期・成果を約束する箇所は空欄または要確認のまま残します。

課題と提案をつなぐ論理を点検する

構成は「相手の現状→解くべき課題→原因の仮説→提案内容→実施条件→次の判断」のように、読者が根拠をたどれる順で設計します。原因が確定していないなら「原因」と断定せず「確認したい仮説」として置きます。提案の各施策について、どの課題をどう変える想定なのか、必要な前提は何かを一行でつなぎます。課題に対応しない機能紹介や、目的に寄与しない会社紹介は削る候補です。

たとえば「問い合わせが多い」という課題にFAQ改善を提案するなら、最初に問い合わせ分類や重複率を調べる段階を置けます。分類データがない場合、FAQが原因と断定するのではなく、調査を第一段階にする。ここでは「問い合わせを何％減らせる」と数字を作らず、「分類結果を見て対象を決め、変更前後で同じ分類の件数を比較する」と検証方法を提案できます。数値目標を置くなら、現状値、計測期間、対象範囲、算出方法を相手と合意してからです。

選択肢は「差」と「選ぶ条件」で比べる

複数案を出すときは、豪華さの順に並べるのではなく、判断に関わる差を見せます。最小案、標準案、拡張案は名称だけでは比較になりません。各案に対象範囲、含む作業、相手側の作業、前提、費用の確定状態、期間の見積条件、残るリスクを付けます。

表は横にスクロールできます

比較項目	小さく始める案	標準案	拡張案
対象	一部署・一業務など	合意した複数業務	部門横断など
成果物	調査・試作	実装・運用手順	展開・教育を含む
相手側の作業	データ提供・確認	承認担当・運用準備	複数部署の調整
未確定事項	小規模検証後に判断	要件合意後に見積	依存関係を確認
選ぶ条件	不確実性が高い	要件と責任者が明確	展開範囲が確定

この表は例示の枠であり、実案件の金額・期間・効果を示すものではありません。提案書では各セルを事実に置き換え、確定した価格、概算、未見積を区別します。概算には算出の前提と有効期限を添え、確定見積のように見せないでください。案を一つしか出せない場合も、選択肢を水増しせず、実施する案と「見送る場合に残る課題」を比べれば意思決定の材料になります。

AIに任せる範囲を小さく区切る

AIへ渡す入力は、社外利用が認められた範囲に限定します。顧客名、未公開の売上、個人情報、契約書などを貼り付けてよいかは、利用環境の契約と社内ルールを確認します。匿名化しても案件が特定できる場合があるため、「名前を消したから大丈夫」とは判断しません。最初の依頼では、要件票を要約させるより、情報を「事実・仮説・未確認」に分類し、根拠の列がないものを明示させます。

たとえば次のように依頼できます。

あなたは提案内容を決定する担当者ではなく、入力情報を読みやすく整理する編集者です。

入力にない事実、価格、工数、納期、改善率、導入効果を追加しないでください。

各記述を「確認済み事実」「仮説」「未確認」に分類し、根拠が入力されていないものは「要確認」としてください。

次に、相手の意思決定、現状、課題、提案、前提、リスク、次の判断の順で構成案を作ってください。

構成案が承認されるまでは本文を作らないでください。

構成が合意された後に、節ごとに文章化します。出力が整っていても、前提と矛盾する文がないかを先に確認します。特に「短期間で改善」「大幅削減」などの文は、根拠がない場合は削除するか、検証後に判断する仮説として書き換えます。

効果の主張は測定計画に置き換える

提案書で最も誤解されやすいのは、期待効果を確定した実績のように書く箇所です。AIにROI計算を頼む場合、入力値、計算式、期間、含めた費用が分からなければ数字は検証できません。入力のない値を仮置きした結果は、予測の確定値ではなくシナリオ例です。仮定値を使うときは「例示」と明示し、実案件の見積りへ流用しません。

効果の代わりに、合意できる計測方法を提案できます。

1. 変更前に測る指標と対象範囲を決める。

2. 計測期間とデータ取得責任者を決める。

3. 施策後に同じ定義で測る。

4. 季節性や業務量など他要因も記録する。

5. 結果を見て継続・変更・中止を判断する。

AIは指標候補や集計表の草案を作れますが、どの指標が事業目標を表すかは相手と確認します。データがないなら「導入でX％改善」とは書かず、「効果を測定する設計を含める」と記述します。効果が十分に確かめられない場合も、成功条件と見直し時点を明示するのが誠実です。

本文を相手の判断順に整える

読者は提案側の会社紹介から読みたいとは限りません。冒頭に相手が決めること、提案の要点、前提条件を置き、続けて現状と根拠、案の違い、実施方法、費用・期間、リスク、次の判断を示します。読み手が役員なら判断事項と費用・リスクを早めに、現場担当なら運用変更や必要な作業を詳しくするといった調整をします。ただし、読み手に合わせて不利な条件を隠したり、未確定事項を小さく見せたりしません。

図表は装飾ではなく、文章だけでは比較しづらい項目を見せるために使います。提案内容と課題の対応表、案別の役割分担、作業の前後関係など、会議で質問されるものを選びます。1枚の資料に収めるために文字を小さくするより、補足資料へ分け、意思決定に必要な情報を先に見せる方が読みやすくなります。

提出前は「約束」「抜け」「読み手」をレビューする

提出前に、AIの文面と要件票を照合します。各提案を、課題、根拠、作業、成果物、費用、期間、担当、前提、受け入れ条件に対応付けます。対応先がない文は、削除候補か確認事項です。出力にない重要条件も検査します。費用に税・追加費用の扱いがあるか、データ提供や相手側作業が必要か、運用開始後の責任範囲が明記されているかを確認します。

レビューは次の順で行うと、手戻りを減らせます。

• 事実：会社名、部署名、数値、現状、引用元が正しいか。

• 論理：示した課題から提案へつながり、前提が明らかか。

• 契約：scope、納期、価格、成果保証の書き方を責任者が承認したか。

• 実行：担当、必要データ、相手側作業、受け入れ基準が決まっているか。

• 読みやすさ：専門用語を説明し、要点から読める構造か。

数字が未確認、承認者が未確定、必要データを受領できないなどの条件が残るなら、完成した提案として提出せず、相談用のたたき台と明記します。相手の承認前に予算や納期を「当然の前提」として置かないでください。

小さな例で提案の筋を点検する

次は説明用の架空ケースです。あるチームが「問い合わせ対応に時間がかかる」と相談し、FAQ整理を検討しているとします。相談者が示したのは月別の問い合わせ件数だけで、質問内容の分類や処理時間はありません。この時点で「FAQ導入で工数を30％削減」と書く根拠はありません。提案を調査・分類、FAQ試作、効果確認の段階に分け、まず必要なデータと確認方法を合意する案が現実的です。

表は横にスクロールできます

段階	分かっていること	提案書に置く判断	成果の確認
現状整理	月別件数のみ	内容と処理時間を調べる	分類表と対象期間
試作	頻出質問が未確定	一部質問で案を作る	担当者の正確性確認
継続判断	効果は未測定	測定結果で範囲を決める	同じ定義で前後を比較

このケースでは、数値目標を決める前に計測の設計が必要です。測定に必要なデータを取得できないなら、効果検証を約束した提案にせず、データ整備を別の作業として説明します。提案書の読み手が「今承認すること」「承認後に決まること」「相手が用意するもの」を区別できるかも確認します。

提出前の会議で確認する質問

提案書はPDFにした時点で完成するのではなく、相手が次の意思決定へ進めることが目的です。説明会の前に、次の質問へ答えられるかを見ます。

• 今日は何を決めてもらうのか。見積承認か、調査開始か、関係者への相談か。

• 相手側で追加の資料、担当者、アクセス権が必要か。

• 提案の前提が崩れた場合、どの範囲を再見積りするのか。

• 受け入れ条件は誰が、いつ、どの記録で確認するのか。

• 費用や納期に含まれない作業は何か。

回答できない場合は、曖昧な文章で隠さず「次回確認事項」として冒頭または末尾にまとめます。これにより、相手は提案を承認する前に不足情報を埋めるか、保留するか判断できます。

AIものさしの判断

AIで提案書を作るときは、「文章を作る前の要件整理」に使う価値が大きいです。

要件→構成→option→本文の順で進めると、もっともらしいが根拠のない提案を減らせます。

最終的なscope、price、commitmentは必ず担当者が確定します。