LASSIC Media らしくメディア
提案依頼書の書き方とテンプレート｜16項目の記入例とよくある抜け
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 提案依頼書は、背景と要件から評価の基準まで、提案に要る情報を1冊にまとめて書く文書です。
- 各項目は記入例のように「誰が・何を・いつまでに」まで具体的な言葉で埋めます。
- 関連する発注との境目、データの移行、稼働後の運用、変更の手順は抜けやすいので配る前に確かめます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
提案依頼書を書こうとして社内の過去の資料を探したが、見つからない。ひな形を埋めて配ってはみたものの、届いた見積もりの前提が会社ごとにばらばらだった——。初めてシステム開発を外部に頼む会社では、こうした食い違いが起こりがちです。提案依頼書（RFP）は、発注する側が依頼の中身と提案の条件をまとめ、複数の会社に同じ条件で提案を求めるための文書です。
項目のひな形があれば、書き始めるのは難しくありません。ただし万能ではなく、項目の名前だけを埋めると、肝心の中身が抜けたまま配ることになります。本記事では、提案依頼書を初めて書く情報システムの担当者に向けて、16項目の書き方を記入例つきのひな形で示し、抜けやすい項目と防ぎ方、そして外部に頼むときに確認したい点を整理します。
提案依頼書とは
国の情報システムの調達では、デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（2026年6月12日決定）が、提案依頼書に書く事項を定めています。提案依頼書は「事業者が適切に提案するために必要となる情報が網羅される」ように書く、というのがその考え方です。*1 同じガイドラインは、依頼の中身を書く調達仕様書と、提案の出し方を書く提案依頼書を分けて扱っています。
- 調達仕様書に書くこと：案件の概要、要件、作業の内容、体制、守ること、成果物の扱い、再委託など11の事項*1
- 提案依頼書に書くこと：提案の内容と記載要領、提案の手続、評価の基準、審査の方法の4つ*1
- 要件定義書：求める機能と非機能をまとめた文書。調達仕様書に添付し、満たすべきことを書く*1
民間企業の発注では、これらを1冊にまとめて提案依頼書としてもかまいません。本記事のひな形も、ガイドラインの事項を1冊にまとめ、民間の発注で使いやすい言葉に置き換えたものです。ひな形は前半の7項目と後半の9項目、あわせて16項目です。表の記入例は、社名や数値を「〇〇」で伏せた例です。書き方に迷ったら、記入例の「〇〇」を自社の言葉に置き換えるところから始めると進めやすくなります。
案件の概要と要件のひな形
ひな形の前半は、何を頼みたいのかを伝える部分です。提案する会社はここを読んで、体制と費用の見当をつけます。ガイドラインは、調達の背景、目的、期待する効果、業務と情報システムの概要、契約期間、作業のスケジュールを最初に書く事項に挙げています。*1
| 項目 | 書く中身 | 記入の例 | よくある抜け |
|---|---|---|---|
| 背景・目的 | なぜ今発注するのか。いま困っている業務の場面 | 〇〇業務の受付を紙と電話で行っており、入力が月末に〇日遅れる。受付から入力までを〇〇システムの1つの画面で終えたい | 困りごとは書いたが、何を変えたいのかが書かれていない |
| 期待する効果 | 導入した後に、何がどこまで変わればよいか | 受付から入力の完了までを〇日以内にする | 効果を数で書かず、検収のときに達成したかどうかを判断できない |
| 業務・システムの概要 | 対象の業務の流れ、今のシステムの構成、利用者の数、つながるほかのシステム | 利用者は〇部門の約〇名。会計の〇〇システムと毎日データを受け渡す | ほかのシステムとのつながりが抜け、連携の作業が見積もりに入らない |
| 契約期間・スケジュール | 契約の始まりと終わり、稼働の時期、途中の節目 | 〇年〇月に契約し、〇か月で設計と開発を終え、〇年〇月に稼働する | 稼働日だけを書き、社内での確認やテストに使う期間が入っていない |
| 関連する発注 | 同じ時期に別の契約で頼む作業（機器、回線、運用など）と、この依頼との境目 | サーバーの購入は別の契約で行う。本件はアプリケーションの設計・開発とデータの移行まで | 境目を書かず、どちらの見積もりにも入らない作業が出る |
| 求める要件 | 機能と非機能（性能や障害への備えなど、機能以外の水準）。要件定義書を添付して満たすことを求める | 別紙の要件定義書を満たすこと | 機能の一覧だけで、非機能の水準が書かれていない |
| 作業の内容・成果物・納品期日 | 頼む作業の範囲、納めてもらう物、その期日 | 設計書・テスト結果の報告書・操作説明書を〇年〇月〇日までに納める | 操作説明や引き継ぎの資料が成果物に入っていない |
前半で特に気をつけたいのは「関連する発注」の行です。サーバーや回線を別の契約で買う場合、境目を書かないと、機器の設定がどちらの見積もりにも入っていなかった、ということが起こります。要件そのものを詰める作業は要件定義を外注する費用と進め方で扱っています。
体制・契約・提案条件のひな形
後半は、どう進めてもらうか、どの条件で提案してもらうかを決める部分です。ガイドラインは成果物の扱いとして、知的財産権の帰属、契約不適合責任、検収を挙げています。*1 契約の条項に関わる行は、契約書と食い違わないよう、法務の担当や専門家に確かめてから配ります。
| 項目 | 書く中身 | 記入の例 | よくある抜け |
|---|---|---|---|
| 実施体制・作業場所 | 体制、担当者に求める経験や資格、作業する場所、進み具合の管理の方法 | 週1回の定例で進み具合を報告する。本番環境での作業は当社の拠点で行う | 進み具合の報告の仕方が無く、遅れに気づくのが遅れる |
| 守ること | 機密の保持、貸し出す資料の扱い、守る法令 | 貸し出した資料は契約の終了後に返却または消去し、その旨を文書で報告する | 資料の返し方と消し方が決まっていない |
| 成果物の扱い | 知的財産権の帰属、契約不適合責任、検収 | 検収は納品から〇週間以内。契約不適合責任の期間は検収から〇か月 | 後の改修を別の会社に頼むときに、成果物をどこまで使えるかを決めていない |
| 再委託 | 再委託を認めるか。認めるなら条件と承認の手続 | 再委託するときは、相手先と作業の範囲を示して事前に文書で承認を得る | 再委託の有無が分からず、誰が作業しているかを把握できない |
| 前提条件・変更の手順 | 前提とする条件、動かせない制約、要件が変わったときの進め方 | 要件の変更は双方で合意して記録し、費用と期間への影響を見積もってから進める | 変更の手順が無く、追加の費用でもめる |
| 添付する資料 | 要件定義書、閲覧できる資料の一覧、閲覧の方法 | 今のシステムの設計書は当社内で閲覧できる。閲覧は〇日前までに予約する | 今の資料を見られず、各社の見積もりの前提がばらばらになる |
| 提案書の記載要領 | 提案書に書いてほしい事項と順番、様式、分量 | 体制、実施計画、管理の方法、費用の内訳の順に〇ページ以内で書く | 様式が自由で、各社の提案を並べて比べられない |
| 提案の手続 | 提出の期限・場所・方法、質問の受付と回答の仕方 | 質問は〇月〇日までにメールで受け付け、回答は提案するすべての会社に送る | 質問の窓口と、回答をほかの会社にも伝えるかが決まっていない |
| 評価の基準と審査 | 配点、評価する事項、プレゼンテーションの有無 | 技術〇点・価格〇点。最低限の要求を満たさない提案は採点しない | 合否を分ける最低限の要求と、加点する事項を分けていない |
提案書の記載要領と評価の基準は、届いた提案を並べて比べるための行です。様式を決めずに配ると、会社ごとに書き方がばらばらになり、比べる作業に時間がかかります。届いた見積もりの比べ方はシステム開発の相見積もりの取り方にまとめています。
抜けやすい項目と防ぎ方
ひな形を埋めても、書き手の頭の中にある前提は文書から抜けやすいものです。特に非機能は、機能の一覧に比べて書き忘れやすい項目です。IPA（情報処理推進機構）は非機能の要求を、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つに分けて整理しています。*2 非機能の行を書くときは、この6つを順に見ていくと抜けに気づけます。
- データの移行：今のデータを誰が、いつ、どこまで移すか。移行性は、IPAの整理でも今のシステムの資産を移すことに関する要求とされています*2
- 稼働した後の運用と保守：問い合わせへの対応や改修を、この契約に含めるか別にするか
- 変更の手順：要件が変わったときに、費用と期間をどう決め直すか
- 閲覧できる資料：今のシステムの設計書や画面の資料を、提案の前に見られるか
- 質問への回答：ある会社からの質問への回答を、ほかの会社にも伝えるか
防ぐには、配る前に2つの手順を挟みます。1つは、利用する部門、情報システムの担当、経理や法務の担当に下書きを読んでもらうこと。もう1つは、配る前に候補の会社から意見を聞くことです。ガイドラインも、事業者との質疑応答を通じて「提供すべき情報が明確で、かつ、漏れがないこと」を確かめるよう求めています。*1
ひな形を埋めるために外部に頼める範囲
ひな形の行の中には、社内だけでは埋めにくいものがあります。今のシステムの構成や非機能の水準は、技術の知識がないと書きにくい行です。外部に手伝いを頼むときは、どの行を手伝ってもらうかを決めてから相談すると、話が早く進みます。
- 業務・システムの概要：今のシステムの構成と、ほかのシステムとのつながりの整理
- 求める要件：要件定義書の作成と、非機能の水準の決め方
- 作業の内容と成果物：設計書や操作説明書など、何を納めてもらうかの洗い出し
- 提案書の記載要領と評価の基準：各社の提案を同じ物差しで比べるための様式づくり
- 配った後：質問への回答の文面の確認と、届いた提案の読み比べ
手伝いを頼むときは、作成に関わった会社がその後の提案に加われるかどうかも先に決めておきます。国のガイドラインは、調達仕様書の作成に直接関与した事業者を、原則としてその入札に参加させないとしています。*1 作成の支援を頼む費用と進め方はRFP作成の支援と外注の進め方で扱っています。
まとめ：提案依頼書で確かめておきたい3つの点
提案依頼書を書くうえで、確かめておきたい点は3つに整理できます。第一に、ひな形の行を項目の名前で埋めるのではなく、記入例のように「誰が・何を・いつまでに」まで書くこと。第二に、関連する発注との境目、データの移行、稼働した後の運用、変更の手順のように抜けやすい行を、配る前に確かめること。第三に、社内での読み合わせと候補の会社からの意見聞きを経てから配り、質問への回答はすべての会社に伝えることです。この3点を踏まえておけば、「届いた見積もりの前提が会社ごとに違い、比べられなかった」という事態を避けやすくなります。ひな形の埋め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
提案依頼書と要件定義書は何が違いますか
要件定義書は、システムに求める機能と非機能をまとめた文書です。提案依頼書は、その要件をもとに、作業の範囲や提案の条件まで含めて提案を求める文書です。国のガイドラインでは、要件定義書を調達仕様書に添付し、満たすべきことを書く形をとっています。*1
ある会社からの質問への回答は、ほかの会社にも伝えるべきですか
提案に大きく影響する回答は、すべての会社に伝えるのが公平です。国のガイドラインも、提案に重要な影響がある応答の内容は、関係するすべての事業者に通知するとしています。*1 質問の締め切りと回答の送り方は、提案の手続の行に書いておくと迷いません。
小さな案件でもひな形の項目は全部必要ですか
全部を同じ厚さで書く必要はなく、小さな案件なら行をまとめてもかまいません。ただし、作業の内容と成果物、成果物の扱い、評価の基準の3つは省かないでおくと、後のもめごとを防ぎやすくなります。
提案依頼書づくりのご相談
提案依頼書の項目の洗い出しから、要件定義書の作成、届いた提案の読み比べまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン（DS-100）」2026年6月12日 デジタル社会推進会議幹事会決定（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：第3編第6章「調達」の調達仕様書の記載内容（アからサまでの11の事項、成果物の取扱い、入札制限）、意見招請、提案依頼書の作成（アからエまでの4つの事項）、公告後の応答内容の通知の記述を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「非機能要求グレード」紹介ページ・小冊子「経営に活かすIT投資の最適化」（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）。出典：非機能要求の6つのカテゴリ（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）と移行性の説明を参照（2026年10月確認）
