RFP（提案依頼書⁠）とは｜書き方と項目例

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

RFPに書くべき項目

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

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

生成AIで下書きする手順

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

1. 現状業務を箇条書きで渡す — 誰が・何を・どのくらいの頻度で行っているか⁠。ここだけは人間にしか書けません
2. 課題と目的を対話で言語化する — 「この業務の何が困っているか⁠」をAIに質問させると抜けが減ります
3. 章立てを作らせてから⁠、章ごとに書かせる — 上の項目リストを渡して構成を固定します
4. 要件一覧は表形式で出させる — 機能名・概要・必須/希望の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ドラフトのレビュー・仕上げを発注者側の立場でお手伝いしています⁠。