RFP（提案依頼書）の書き方｜テンプレート付き実践ガイド
システム開発のRFP（提案依頼書）の書き方を、テンプレート付きで解説。ITに詳しくない方でも使える実践的な構成と、よくある失敗パターンの回避策を紹介します。初めてのRFP作成でも安心のガイド。
「要件定義をAIに渡したら、数分でそれらしい一覧が返ってきた。ところが、よく読んだら、社内にすでにあるページや仕組みの存在をまるごと無視した内容だった。」これが、実際にやってみて最初にぶつかった出来事でした。
システム開発やアプリ開発で必ず出てくるのが要件定義です。「何を作るか」を言葉にする工程で、ここがあいまいだと後工程がすべてぶれます。そして、こう考えたことはないでしょうか。「要件定義って、AIにやらせれば早いんじゃないの？」と。たしかに、生成AIは文章を整えるのが得意です。論点を並べたり、抜けを指摘したりも上手い。要件定義は文章仕事の側面が大きいので、AIと相性がよさそうに見えます。
そこで実際に試してみました。私たちが普段使っているAI開発ツール（Claude Code）に、自社サイトの新しいページの要件定義をやらせてみたのです。題材は「料金・プランページ」です。来てくれた見込みのお客様に料金感を伝えて、相談につなげるための集客ページです。
結論を先に言うと、たたき台づくりは想像以上に速い。ただ、そのまま使えるものではありませんでした。そして「使えなかった理由」こそが、要件定義という仕事の本質を映していました。この記事では、実際の出力を見せながら、AIに任せられる部分と、人が埋めるしかない部分の境界線を整理します。
まず驚いたのは、その手軽さです。専門のツールやコードの知識がなくても、やることはシンプルでした。
おおまかな流れはこうです。
最初に書いたのは、たった数行の説明です。
自社サービス（ソフトウェア受託開発・MVP開発）の料金・プランページを作りたい。サイトに来た見込み客に料金感を伝えて、問い合わせにつなげるための集客ページ。プランの比較や「結局いくらかかるのか」の不安を解消したい。
そもそも要件をどんな書類に落とすのか、何を書けばよいのかは、こちらの記事でも整理しています。
この説明を渡しただけで、ツールは要件の一覧をきれいな形式で返してきました。出てきたのは、次の6つの項目です。
料金ページに必要な論点が、ひととおり並んでいます。中身もそれらしく具体的でした。実際に返ってきた内容を、一部そのまま引用します。
要件1：プラン情報の表示 見込み客として、提供されているプランとその内容を一覧で把握したい。そうすれば自分に合った選択肢を素早く理解できる。
- 利用者が料金ページにアクセスしたら、全プランをカード形式で一覧表示する
- 各プランに、プラン名・対象となる利用者像・含まれる主な内容・想定価格帯を表示する
- 「おすすめ」のプランは視覚的に強調表示する
要件3：料金に対する不安の解消 「結局いくらかかるのか」の疑問を解消したい。そうすれば安心して問い合わせに進める。
- 価格を構成する要素（規模・期間・関与範囲）の説明を提示する
- よくある質問として、料金・追加費用・契約形態の質問と回答を表示する
- 価格が「個別見積もり」の場合は、目安となる価格帯や事例ベースの参考額を提示する
ちなみに、実際の出力はもう少し独特の言い回しでした。たとえば要件1の一行目は、こう書かれています。
WHEN 利用者が料金ページにアクセスする THEN システムは SHALL 全プランをカード形式で一覧表示する
「〜したら、システムは必ず〜する」という、抜け漏れを防ぐための決まった書式です。一見読みづらいですが、条件と動作を一対一で対応させる、要件定義では理にかなった形です。
正直に言って、ここまでは見事です。要件定義のたたき台として、論点の抜け漏れを防ぐチェックリストとしては十分に機能します。「何から考えればいいか分からない」という最初のハードルを、AIはあっさり越えさせてくれます。コードを一行も書かずに、です。この手軽さは本物なので、興味があればぜひ一度試してみてほしいと思います。
問題は、出てきた要件をよく読んだときに起きました。
たとえば、さきほどの要件3にこんな一文がありました。「価格が個別見積もりの場合は、事例ベースの参考額を提示する。」料金の不安をやわらげるのに、過去の事例を見せるのは良い考えです。
ところが私たちのサイトには、すでに開発実績を紹介するページが用意してあります。本来なら「あの実績ページの事例とつなげて見せる」と書かれるべきところを、AIは、そんなページが存在することを知らないまま、ただ抽象的に「事例を提示する」とだけ書いていました。
似たことは要件4でも起きていました。「問い合わせへの導線」「MVP診断への導線」と、ちゃんと書かれてはいます。一見、よく分かっているように見えます。しかしこれは、私が最初の説明文に「/contact」「/mvp」という行き先を書いておいたので、それをなぞっただけでした。サイトにすでにある具体的な作り、たとえば記事の末尾から相談へ誘導する仕組みや、訪問者の悩みを診断するページには、まったく触れていません。
これは、AIがサボったわけではありません。多くのAIツールの要件定義の工程は、あえて既存の作りを細かく見ずに、依頼内容だけから要件を組み立てる設計 になっています。要件を素早く広く洗い出すには、それが合理的だからです。
しかし発注者の現場では、これが落とし穴になります。会社には、過去に作ったページや、すでに動いている仕組みといった資産が必ずあります。要件定義でいちばん効くのは、しばしば「ゼロから作る」ではなく「すでにあるものをどう活かすか」の判断です。ところがAIの要件は、その存在を知らないまま、まっさらな新規ページとして組み上がっていました。気づかずに進めていたら、すでにあるものを二重に作るところでした。
これは集客ページに限った話ではありません。社内の業務システムでも同じです。すでにある業務フロー、現場でしか起きない例外処理、過去に作って動いている仕組み。こうした事情は、依頼文に書かれていなければAIには知りようがありません。だからこそ、現場に何があるのかを引き出して要件に落とす工程が要ります。
何があるかを把握して、それを前提に要件へ織り込む。 ここは、AIが自動ではやってくれない領域でした。
もうひとつ、もっと根の深い問題がありました。
AIが出した要件には、利用者が「見込み客」としか書かれていなかったのです。すべての項目で、対象は一律「見込み客」でした。一見、当たり前に見えます。料金ページを見るのは見込み客なのだから、と。
とはいえ、料金ページに来る人は、決して一枚岩ではありません。開発の相談で繰り返し向き合ってきた見込みのお客様だけでも、まったく違うタイプがいます。
「結局いくらかかるのか」という同じ不安でも、その中身は人によって違います。事業オーナーは見積もりが膨らむことを恐れ、技術責任者は安さの裏に隠れた品質リスクを疑う。料金ページが応えるべき不安は、相手によって別物なのです。
AIの要件には、この区別がありませんでした。「対象となる利用者像を表示する」という項目こそありましたが、その中身は空っぽで、誰がどんな不安で来るのかという肝心の部分は埋まっていませんでした。
そして皮肉なことに、これは集客ページの要件定義だからこそ、致命的でした。集客ページの良し悪しは、ほぼ「誰のどんな不安に応えるか」で決まります。その顧客理解の部分が、すっぽり空いたままだったのです。要件定義をAIにやらせてみたら、要件定義でいちばん大事なものが抜けていた。この出来事そのものが、答えを示しているように感じました。
もちろん、AIに要件定義を任せて、うまくいく場面もあります。作るものが定型的で、社内に前例があり、誰が使うかがはっきりしているなら、AIのたたき台はそのまま実用に足ります。難しくなるのは、前例のない新しいものや、相手によって正解が変わるものを作るときです。AIが万能でも無力でもなく、得意と不得意がはっきり分かれるツールです。
なお、ここで何度も出てくる「結局いくらかかるのか」という料金そのものの相場観については、別の記事で詳しく整理しています。
ここまで読んで、こう思った方は鋭いです。「既存のページのことも、読者のタイプも、AIに最初から教えておけばいいのでは？」と。
そのとおりです。使い回せる部品の一覧や、想定する読者像を、AIが読み込む設定（Claude Codeにも、そうした前提を覚えさせておく仕組みがあります）に書いておけば、AIはそれを踏まえた要件を出してきます。さきほどの「知らない」は、正確には「教えていなかった」だけ。前提を渡しておけば、抜けの多くは防げます。
ただ、それで問題が消えるわけではありません。一段ずれるだけです。
「AIに何を教えるべきか」を決めるのは、結局のところ人だからです。どの既存資産を使い回すべきか。読者を何タイプに分け、それぞれが何を不安に思うのか。その「教える中身」を用意することこそ、いちばん頭を使う作業です。
しかも厄介なことに、その中身、つまり「誰が使うのか」「何があるのか」を書き出した文書は、それ自体がもう要件定義です。AIに正しく仕事をさせる準備を整えていたら、いつのまにか要件定義の本体を書いていた、という話なのです。
AIは、正しい前提さえあれば速い。問題は、その正しい前提を誰がどう用意するのか、に移っただけでした。
ここまでをまとめると、こうなります。
ツールとしての要件定義は、誰でも数分で試せるものになりました。コードが書けなくても、専門知識がなくても、それらしい要件の一覧は出せます。試すこと自体は、もう難しくありません。
けれど、本当に難しいのはそこではありませんでした。難しいのは、出てきたたたき台に対して「これは違う」「ここが抜けている」と判断できること です。既存の資産を知っていて、顧客を理解していて、過去の経緯を踏まえているからこそ、その判断ができます。
要件定義の価値は、文章を書く作業そのものにあるのではありません。何を要件にすべきかを決める、その判断にあります。AIは文章を速くまとめてくれますが、何を書くべきかは教えてくれませんでした。
AIを使ってみて、むしろはっきりしたことがあります。要件定義をプロに頼む意味は、「文章を作ってもらうこと」ではないということです。それはAIでもできます。
本当の価値は、「御社にすでに何があるか」を把握した上で要件を起こせること、「このページや機能を使うのはどのタイプの相手か」を一緒に考えられること にあります。今回の例で言えば、すでにある実績ページや問い合わせの仕組みをどう活かすか、料金に不安を抱く相手は事業オーナーなのか技術責任者なのかで見せ方をどう変えるか。この判断を引き受けるのが、要件定義から伴走するプロの仕事です。
私たちは、AIを否定しているわけではありません。むしろ、たたき台づくりや論点出しにはAIを積極的に使います。その上で、AIに渡す前提そのもの（誰のために作るのか、すでに何があるのか）を、御社と一緒に整理していきます。これはAIに教えるための準備であると同時に、要件定義の本体です。AIを使いこなした上で、人にしかできない判断に集中する。これが、いま現実的なやり方だと考えています。
要件が固まった後、どう小さく作り始めるかについては、こちらの記事も参考になります。
「自社の場合、どこまでAIで進められて、どこからプロに頼むべきか」を一度整理してみたい方へ。AIで作ったたたき台をお持ちいただければ、その要件のどこに穴があるかを、要件定義の段階から一緒に洗い出します（初回30分〜1時間ほど、無料）。「まだアイデア段階」「要件定義だけ頼みたい」「途中まで自分で進めた」など、どの状態からでも構いません。
アプリ・業務システムの試作（MVP）開発では、今回見てきた「何があるか」「誰のためか」の整理、つまり要件定義の段階から現役エンジニアが伴走します。固定50万円・最短2週間でブラウザで触れる試作まで形にし、その過程でまとめた要件定義書は御社の資産としてお渡しします。そのまま他社への発注にも使え、私たちに縛られることはありません。こちらから本格開発を押し売りすることもありません。
「こんなことできる？」「費用感を知りたい」「まだ漠然としているけど相談したい」
どんな段階でもお気軽にご相談ください。
クレインテックが一緒に考えます。
初回のご相談・お見積もりは無料です。
「こんなシステムは作れる？」「費用感を知りたい」「まだ漠然としている」など、どんな段階でもお気軽にどうぞ。
無料で相談する
