IT企業の提案書をAIで作る方法｜要件定義から見積根拠まで

提案書を1本仕上げるのに、毎回3日かかっています。要件をヒアリングして、過去案件を引っ張り出して、機能一覧を組んで、見積根拠まで通したら、もうレビューする時間がない——ある受託開発会社の営業マネージャーが、相談の冒頭でぽつりとそう話されました。IT・Web業界の提案書は、要件定義書・機能一覧・WBS・見積根拠書がワンセットで動くため、1本の重みが他業界より明確に重い構造になっています。

本記事では、生成AIをIT企業の提案書作成に組み込む具体的な手順を、要件定義のヒアリング整理から、WBS生成、見積根拠の組み立て、提案書ドラフト化までの4工程に分解して解説します。

なぜIT企業の提案書はAIと相性が良いのか

本記事のテーマに関連するサービスとして、BoostXではIT/Web企業の支援を提供しています。

IT・Web業界の提案書には、他業界には少ない3つの構造的特徴があります。第一に、要件定義書・機能一覧・WBS・見積根拠書という4ドキュメントが連動して動くこと。第二に、過去案件の機能の組み合わせが新案件の見積精度に直結すること。第三に、見積根拠が「人月×単価」という共通の言語で説明できること。この3つは、いずれも生成AIが得意とする「構造化された文書間の整合」と「過去データからの類推」の領域に重なります。

逆に、IT提案書がAIで失敗する場面も明確です。ヒアリング情報が断片的なまま要件定義書を書かせる、過去案件を読ませずに見積根拠を作らせる、機能一覧の単価を市況に合わせず生成AIの推定に任せる——この3つは、生成AIに「一次情報なしで推測させている」状態であり、ハルシネーション（事実と異なる出力）が混入する典型的なパターンです。AIに任せる工程と、人が一次情報で固める工程を切り分けることが、提案書作成における最初の設計判断になります。

提案書1本あたり40時間の内訳を分解する

弊社で支援している受託開発系のクライアント企業では、提案書1本あたりの実工数を計測したところ、要件整理に8時間、過去案件の検索に6時間、機能一覧とWBSに10時間、見積根拠の組み立てに8時間、ドラフト執筆に10時間、レビュー反映に4時間、合計で46時間ほどかかっていました。AI導入後は要件整理2.5時間、過去案件検索1時間、WBS作成3時間、見積根拠2時間、ドラフト3時間、レビュー反映1.5時間で13時間まで圧縮されています。削減の中心は「過去案件検索」と「ドラフト執筆」で、ここだけで合計15時間以上が短縮されました。

要件ヒアリングをAIで構造化する手順

提案書作成の起点は、要件ヒアリング会議の議事録です。多くのIT企業では、ヒアリング音声を持ち帰った後、営業担当が記憶を頼りに要件を箇条書きしてから提案書執筆に入ります。この工程に最初の8時間が消えていきます。生成AIを使う場合は、議事録作成の時点で「機能要件・非機能要件・制約条件・前提条件」の4分類で出力させると、後工程の機能一覧・WBS生成にそのまま接続できます。

この領域でつまずきやすいのは、ツール選定よりも「業務の中のどこに組み込むか」の設計です。BoostXの生成AI伴走顧問は、業務ヒアリングから設計・定着支援までをサービス対応範囲としてカバーできる領域です。

ヒアリング音声からの要件抽出プロンプト

録音した会議音声をWhisperやCLOVA Noteなどの文字起こしツールに通した後、生成AIに「機能要件・非機能要件・制約条件・前提条件・未確認事項」の5分類で抽出させます。プロンプトには「未確認事項を必ず別欄に出すこと」「要件と要望を区別すること」「定量目標は数値のまま抽出すること」の3つを必ず指示として入れます。これを入れないと、AIは未確認事項を勝手に断定したり、要望と要件を混ぜたりします。

分類後の情報は、機能要件のうち「画面が必要なもの」「バッチが必要なもの」「外部API連携が必要なもの」の3軸で再整理します。この再整理は、後工程のWBS生成で「画面開発」「バッチ開発」「外部連携開発」の3カテゴリにそのままマッピングできるため、機能一覧表を別途作る手間を省けます。

未確認事項リストを必ず分離する

要件定義の現場で最も多いトラブルは「ヒアリング時に決まったと思っていた仕様が、実は未確認だった」というケースです。生成AIは、聞き取れなかった部分や曖昧な発言も、文脈から推測して断定的に出力する傾向があります。そのため、プロンプトに「不明な点は『未確認』タグをつけて別リストに出力」と明示しておきます。出力された未確認事項リストは、提案書とは別に「未確認事項一覧」として顧客に提示し、提案フェーズで合意形成に使います。これは提案後の認識齟齬を防ぐ実務的な防衛策にもなります。

過去案件をRAGで再利用するNotebookLM活用

IT提案書の見積精度は、過去類似案件をどれだけ早く正確に引き出せるかで決まります。受託開発会社の多くは、過去の見積書・WBS・契約書をフォルダに格納していますが、案件名で検索しても「機能の組み合わせが似ている案件」までは辿り着けません。ここで活用するのがGoogle NotebookLMやRAG（Retrieval-Augmented Generation）構成です。

投入する一次情報の種類と粒度

NotebookLMには、過去3年分の見積書・WBS・契約書・キックオフ議事録・要件定義書を投入します。粒度は1案件1セットを推奨します。複数案件をまとめたフォルダごと投入すると、AIは案件をまたいで情報を混ぜてしまい、ハルシネーションの温床になります。投入時は、案件名・契約金額・期間・体制・主要機能を冒頭にメタ情報として手書きで添えると、検索精度が上がります。

類似案件抽出のクエリ設計

新規案件の機能一覧（仮）を作った段階で、NotebookLMに「これに最も類似する過去案件を3件、それぞれの差分とともに提示してください」と問い合わせます。ポイントは「差分とともに」です。差分が出ないと、過去案件をそのまま流用してしまうリスクがあります。差分が明示されると、過去案件の見積を新規案件用に補正する根拠が見えてきます。

この方法を導入したクライアントでは、過去案件検索に6時間かけていた工程が1時間まで短縮され、見積精度（実工数とのズレ幅）も2割以内に収まるようになりました。AIに過去案件を「探させる」のではなく、過去案件を「整理して読ませる」設計が、見積の信頼性を支えます。

機能一覧・WBS・見積根拠をAIで生成する

要件と過去案件が揃ったら、機能一覧・WBS・見積根拠の3点をAIに下書きさせます。ここでの設計判断は「人月×単価」を直接AIに計算させないことです。人月を出すための要素分解（タスク分解、難易度評価、リスク係数）まではAIで進め、単価との掛け算は人が単価表と突き合わせて確定させます。AIに金額を出させると、過去の市場相場や訓練データの単価が混ざり、自社の単価表と乖離する恐れがあるためです。

WBSは「タスク・前提・成果物・想定工数レンジ」の4列で生成

WBSを生成する際は、AIに「タスク名」「前提条件」「成果物」「想定工数（最小〜最大のレンジ）」の4列で出力させます。工数を1値ではなくレンジで出させる理由は、後工程の見積根拠で「最頻値・最大値・最小値」のシナリオを組み立てやすくするためです。プロジェクトマネジメントの世界で使われる三点見積法（最頻値・楽観値・悲観値の加重平均）と相性が良く、見積の説明力が一段上がります。

見積根拠は「工数×単価×リスク係数」で構造化する

見積根拠書は「工数（人月）」「単価（円/人月）」「リスク係数（1.0〜1.3）」の3列構造でAIに下書きさせます。リスク係数は、要件の確定度・技術的不確実性・体制の安定度の3軸で1.0〜1.3の範囲で設定します。AIには「この案件の不確実性要因を5つ挙げ、それぞれを難易度1〜5で評価してください」と問いかけ、その結果を基に人がリスク係数を決定します。AIに係数そのものを決めさせず、評価材料を出させて人が判定する設計が肝になります。

この構造化により、見積根拠の組み立てに8時間かけていた工程が2時間まで圧縮されました。同時に、顧客から「なぜこの金額なのか」と問われた際に、工数・単価・リスク係数の3要素で説明できるため、価格交渉での後退も減ります。AIは見積を「作る」のではなく、見積を「説明可能な形で整える」役割を担います。

提案書ドラフト化と運用上の注意点

機能一覧・WBS・見積根拠が揃った段階で、提案書のドラフトをAIに作らせます。提案書のテンプレートは、自社の過去提案書から「採用された案件」「失注した案件」を5本ずつNotebookLMに読み込ませ、トーンと構成を学習させます。新規案件の要件と見積を渡すと、過去の採用案件のトーンに沿ったドラフトが上がってきます。

ドラフトを「叩き台」として使い切る

AIが上げてくるドラフトは、構成と論理は整っていますが、固有の現場感や顧客のキーパーソンの言い回しは反映されません。ここを人が補強します。具体的には、要件定義の章で顧客社内の組織構造を書き加える、見積の章で顧客の予算感に合わせて表現を調整する、リスクの章で過去案件の具体的なヒヤリハットを差し込む、の3点です。AIドラフトを「土台の8割」と捉え、残り2割を人が現場情報で塗り替える運用が、提案書の刺さり方を決めます。

セキュリティと情報管理の3原則

IT企業の提案書作成にAIを使う際、最大の論点は顧客情報・契約金額・社内見積データの取り扱いです。3つの原則を運用ルールに明文化することを推奨します。第一に、顧客名・契約金額・個人名は仮名化または伏字でAIに入力する。第二に、Web版ではなくAPI経由かエンタープライズプラン（学習に使われない契約形態）を使う。第三に、過去案件データを投入するNotebookLMやRAG基盤は社内アカウントで隔離する。「API版にすれば安心は思考停止」という言葉のとおり、APIキーが漏れたときのダメージはWeb版の学習利用より大きい場合があります。アクセス制御とログ監査の運用設計が、AIツールの選定そのものより重要です。

ハルシネーション対策の3層チェック

提案書はそのまま顧客に提出される文書のため、ハルシネーションが残ったままだと商談そのものが崩れます。3層のチェック構造を入れます。第一層は機械的チェックで、機能一覧の数値・金額・期間が要件定義書と一致しているか自動比較します。第二層はAIによるセルフレビューで、別のプロンプトで「この提案書の論理矛盾と未確認事項を5つ挙げてください」と問います。第三層は人による事実確認で、顧客名・契約条件・固有の数値を一次情報と照合します。この3層を通すと、提案書のレビュー指摘件数が半減し、レビュー反映の工数も4時間から1.5時間まで削減できます。

よくある質問