RFP（提案依頼書）の作り方｜AI で下書きするときの注意点

システム開発を外部に発注するとき、最初の成果物がRFP（Request for Proposal：提案依頼書）です。RFPの出来は、集まる提案の質・見積もりの精度・プロジェクトの成否をほぼ決めます。AIは例外処理を知りません。書かれなかった要件は、契約後に追加費用として返ってきます。

RFPに書くべき項目

形式は自由ですが、ベンダーが見積もりを出すために最低限必要な情報は決まっています。

背景と目的 — なぜこのシステムが必要か。現状の業務と課題
スコープ — 対象業務・対象ユーザー・作ってほしい機能の範囲（やらないことも書く）
必須要件と希望要件の区別 — すべて「必須」と書くと見積もりが跳ね上がります
非機能要件 — 利用人数・データ量・セキュリティ・稼働時間帯など
既存環境 — 連携が必要な既存システム・データ移行の有無
予算感とスケジュール — 書きたくない場合も「上限レンジ」は示すのが結局は得です
提案してほしいこと・評価の観点 — 何を基準に選ぶかを先に示す
契約条件 — 検収基準・瑕疵担保・知的財産権の帰属

生成AIで下書きする手順

ゼロから書くより、生成AIに下書きさせるほうが圧倒的に速いのは事実です。コツは「一気に全部書かせない」ことです。

現状業務を箇条書きで渡す — 誰が・何を・どのくらいの頻度で行っているか。ここだけは人間にしか書けません
課題と目的を対話で言語化する — 「この業務の何が困っているか」をAIに質問させると抜けが減ります
章立てを作らせてから、章ごとに書かせる — 上の項目リストを渡して構成を固定します
要件一覧は表形式で出させる — 機能名・概要・必須/希望の3列。後の比較評価にそのまま使えます

AIの下書きをそのまま出してはいけない理由

ここが本記事の主題です。生成AIのRFPドラフトには、受け取る側から見ると典型的な問題があります。

1. もっともらしいが検証されていない要件が混ざる

AIは「一般的なシステムにありそうな要件」を補完します。実際には不要な機能（使わない承認ワークフロー、過剰な権限管理など）が紛れ込み、見積もりを数百万円単位で押し上げることがあります。

2. 自社の業務の特殊性が反映されない

見積もりが割れる原因の多くは「例外処理」です。月末だけ発生する処理、特定の取引先だけ違うルール。AIは知らないので書けません。そして書かれていない要件は、契約後に追加費用として跳ね返ります。

3. 実現性・費用感の相場観がない

「リアルタイムで」「AIで自動的に」といった表現は、書くのは一瞬ですが実装コストは桁で変わります。相場観のないまま要求水準が固定されると、提案辞退や過大見積もりを招きます。

4. 矛盾に気づけない

予算300万円と書きながら要件一覧は3,000万円規模、スケジュール3ヶ月なのにデータ移行とパラレル稼働を要求。ベンダーはこうした矛盾を見た瞬間に警戒し、保険をかけた金額を出します。

出す前の最終チェックリスト

要件一覧の1行ごとに「これは本当にうちの業務で使うか」を業務担当者が確認したか
必須要件は全体の5割以下に絞れているか
例外処理・締め処理・他システム連携を業務担当者にヒアリングして反映したか
予算レンジ・スケジュールと要件のボリュームが釣り合っているか
提案の評価軸（価格・体制・実績・保守）を先に決めてRFPに書いたか

まとめ｜AIで書き、プロの目で仕上げる

生成AIはRFP作成の強力な道具ですが、「正しさの保証」は構造的にできません。AIで下書きを高速に作り、開発の相場観を持つ人間が要件の妥当性・実現性・矛盾をレビューする。この分業が、現時点でもっとも合理的なRFPの作り方です。シャノンでは、AIで作ったRFPドラフトのレビュー・仕上げを発注者側の立場でお手伝いしています。