システム開発を外部に発注するとき、最初の成果物がRFP（Request for Proposal：提案依頼書）です。RFPの出来は、集まる提案の質・見積もりの精度・プロジェクトの成否をほぼ決めます。本記事では、RFPに書くべき項目、生成AIで効率よく下書きする手順、そして「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ドラフトのレビュー・仕上げを発注者側の立場でお手伝いしています。