受発注システムのRFPの作り方｜6部構成と記載項目

◆監修・編集責任者　小園 将隆　2026年8月17日

B2B EC-COLUMN

RFPは要件定義の成果物を提案比較できる形に変換した文書

受発注システムのRFPは、目的と背景・現状・要求要件・提案依頼事項・選定の進め方と評価基準・契約と前提条件という6部で構成します。要件定義で固めた内容を、提案を比較できる書式に変換して書くのが基本です。

受発注システムのRFPとは、要件定義で固めた要求を、複数ベンダーの提案を横並びで比較できる書式に落とし込んだ文書を指します。RFPはRequest for Proposal（提案依頼書）の略で、発注側が要求内容を提示し、ベンダーに実現方法と条件を提案してもらうために使います^*1。

RFP（提案依頼書）の定義と役割

RFPの役割は、要件定義の成果物をそのまま渡すことではありません。要件を「機能要件」「非機能要件」「制度・法令要件」に整理し直し、ベンダーが同じ土俵で提案できる粒度に調整する点にあります。

IPA（独立行政法人情報処理推進機構）は、要件定義の段階から業務部門のユーザーが主体的に関与するスタイルへの変革が必要だと整理しています^*3。RFPはその要件定義の結果を受け取り、ベンダーへの依頼文書として再構成する工程にあたります。

RFP・RFI・要件定義書・仕様書の違いを表で比較

この4つの文書は目的も書き手も異なります。混同すると、ベンダーへ渡す情報の粒度がずれてしまうでしょう。

文書	目的	主な書き手	出す時期
要件定義書	自社が何を実現したいかを言語化する	発注側（業務部門＋情報システム部門）	RFP作成の前段階
RFI（情報提供依頼書）	ベンダーの実績・技術情報を集める	発注側	RFPに先立ち候補を絞る段階（任意）
RFP（提案依頼書）	要求要件を示し、比較可能な提案を依頼する	発注側	ベンダー範囲が固まった段階
仕様書	実現方法・機能を確定させ開発の指示とする	選定後にベンダーと発注側が共同で作成	契約後の設計工程

要件定義書の作り方そのものは、本記事では扱いません。要件を決める工程の詳しい進め方は、別記事で解説しています。本記事は「決めた要件を、比較できる提案依頼へどう変換するか」に絞って解説します。

取引先が使うシステムという受発注システム特有の前提

受発注システムのRFPが社内システムのRFPと異なる点は、実際にシステムを操作するのが自社の社員ではなく、取引先の担当者である点です。取引先ごとに担当者の人数や承認フローが異なり、既存のFAX・電話・EDIといった複数の受発注手段が並存しているのが実情です。

そのため、RFPの要求要件には「自社が使いたい機能」だけでなく、「取引先が無理なく使える条件」を明記する必要があります。この観点は「受発注システム特有の商習慣要求」の章で具体的な記載項目として整理します。

BtoB-EC化率43.1%と中小企業の電子受発注対応48.5%

経済産業省の令和6年度電子商取引に関する市場調査によると、2024年の国内BtoB-EC市場規模は514.4兆円でした^*6。前年の465.2兆円から10.6%増加し、EC化率は43.1%でした^*6。EC化率は全ての商取引金額に対する電子商取引市場規模の割合を指し、BtoB-ECでは業種分類上「その他」以外の業種が算出対象です^*6。

一方で、中小企業庁が公表した令和3年度取引条件改善状況調査によると、2021年時点で電子受発注システムを導入していた受注側企業は48.5%でした^*7。同調査は製造業・サービス業・建設業・卸売業／小売業・金融業の5分野を対象とし、受注側約8万600社に調査したものです^*7。EC化率は取引金額に対する比率、48.5%は企業数に対する比率で、調査主体も対象年も異なるため直接の比較はできません。それでも、金額ベースで電子化が進む一方、企業数ベースでは受注側の約半数が未対応であるという二つの側面が読み取れます。これから受発注システムを調達する企業にとって、取引先の対応状況を前提条件として確認しておく意味は大きいでしょう。市場規模の詳細な内訳は、別記事で解説しています。

RFPに書く6部構成、そのまま使える目次

RFPの記載項目は、公的な枠組みと自社の整理を明確に区別して示します。以下の6部構成は、IPAの要件定義ガイドやモデル取引・契約書の考え方を土台に、受発注システムの調達に合わせて編集部が整理したものです^*3*2。

6部構成の全体像を章・内容・出どころ・不足しがちな点で整理

第1部 目的と背景を業務の言葉で書く

第1部には、なぜシステムを入れ替えるのかを、システム用語ではなく業務の言葉で書きます。「FAXでの受注が多く確認作業に時間がかかる」のように、現場の状況から入れば、ベンダーは自社の業務を具体的にイメージできます。

第2部 現状を受発注手段別の件数で示す

第2部の現状把握は、提案の前提を揃える上で欠かせない部分です。電話・FAX・メール・EDI・Webといった手段別に、月間の受発注件数や取引先数を示すと、ベンダーは規模に見合った提案を組み立てられます。

件数を示さないままだと、ベンダーごとに想定する規模がばらつき、提案内容も価格帯も比較しづらくなります。社内に正確な件数データがない場合は、概算であることを明記した上で提示するとよいでしょう。

第3部 要求要件を機能・非機能・制度要件の3欄に分ける

第3部は、機能要件・非機能要件・制度要件の3つに分けて書きます。機能要件は受発注・在庫・請求といった業務機能、非機能要件は性能や可用性、制度要件は後述する2026年施行の制度対応を指します。

非機能要件について、IPAは「非機能要求グレード」という枠組みを公開しています。まず重要な項目から段階的に受発注者間で要求レベルを確認する使い方で、樹系図で全体を俯瞰したうえでグレード表によりレベル値を決める手順です^*1。効果として、発注側では業務への影響把握と費用説明の明確化、開発ベンダ側では手戻りコストの圧縮と運用トラブルの減少が挙げられています^*1。非機能要求グレードの使い方は、「提案を比較できる書き方」の章で改めて扱う予定です。

第4部 提案依頼事項で提案してほしい内容と書式を指定

第4部では、何を、どの書式で提案してほしいかを具体的に指定します。章立てや様式を指定しないと、ベンダーごとに構成がばらばらの提案書が届き、比較の手間が増えてしまいます。書式指定の具体策は「提案を比較できる書き方」の章で扱います。

第5部 選定の進め方と評価基準、配点開示の判断

第5部には、評価項目とスケジュール、質疑応答の窓口を明記します。評価の配点をベンダーに開示するかどうかは、公平性を重視するか、提案の独自性を引き出すことを重視するかで判断が分かれる論点です。この点はFAQでも扱います。

第6部 契約・前提条件で契約形態と体制を示す

第6部では、契約形態（一括請負か準委任か）、工程分割の考え方、社内体制、秘密保持の扱いを前提条件として先に示します。IPAが公開する「情報システム・モデル取引・契約書（第二版）」は、ユーザ企業とITベンダのいずれにもメリットが偏らないことを目指した契約書のひな型です^*2。契約条件を1行で済ませず、こうした中立的なモデル契約書の存在を踏まえて前提を示すと、ベンダー側も見積もりの前提を揃えやすくなるはずです。

RFPは6段で作る、社内合意から提案受領・評価まで

受発注システムのRFP作成は、社内の合意形成からベンダーの提案評価まで6つの段階を踏みます。この6段は、公的資料の枠組みを土台に編集部が受発注システムの調達向けに整理したものです。

4つの局面をさらに具体的な6段に分解すると、次の通りです。

1. 第1段：目的・予算枠・稼働時期・体制について社内の合意を先に取ります。社内向けの説明資料や稟議の書き方は別記事で扱います。
2. 第2段：要件定義の結果を棚卸しし、必須・推奨・任意の3段階に仕分けます。要件定義そのものの進め方は別記事で解説しています。
3. 第3段：声をかけるベンダーの範囲を決めます。候補が絞り切れていない場合は、RFPの前にRFI（情報提供依頼書）を挟むかを判断します。
4. 第4段：6部構成に沿ってRFP本文を執筆します。第3部の要求要件と第4部の提案依頼事項に、最も時間をかけます。
5. 第5段：RFPを発行し、質疑を受け付けます。質疑の受付期間と、回答を候補ベンダー全社へ共有するルールを事前に決めておきます。
6. 第6段：提案を受領し、評価基準に沿って比較・内示します。受領した提案の比較方法は別記事で詳しく解説しています。

作成にかかる期間やページ数は、対象業務の数・連携先の数・取引先の数・社内承認の段数によって変わります。一次情報で裏づけられる標準的な期間は確認できていないため、具体的な日数の目安は示さず、決まり方の要因を上記の通り示すにとどめます。

受発注システム特有の商習慣要求、汎用テンプレートにない項目

受発注システムのRFPで書き落としやすいのが、BtoBの商習慣に関する要求です。一般的なRFPテンプレートには、次のような項目が含まれていません。

価格 取引先別単価と数量帯別価格

取引先ごとに単価が異なる、数量帯によって価格が変わるといった価格体系は、機能要件の中でも特に見落とされやすい部分です。都度見積もりが必要なケースをどこまでシステム内で扱うかも、あわせて要求として書きます。金額の相場そのものは別記事で扱っています。

取引 掛売・与信限度・締め支払い・ロットと入数

掛売（かけうり）とは、代金を後払いにする取引形態を指します。与信限度、締め支払いのサイクル、ロット・入数の管理、分割納品への対応は、受発注システムに固有の要求です。これらを機能要件の欄に具体的に書かないと、汎用的な在庫・受注機能しか提案されません。

組織 取引先側の複数担当と代理店階層

取引先側に複数の担当者と承認者がいる場合や、代理店・特約店の階層がある場合は、それぞれの権限とシステム上の見え方を要求要件に書きます。自社側の受注センターの運用体制も、あわせて明記しておくとよいでしょう。

連携 基幹システムと既存EDIとの接続方式

基幹システムや在庫システム、既存EDIとの連携は、接続方式（API・ファイル連携など）と、どちらが仕様を提示するのかをRFPの段階で明示します。連携要求の具体的な書き方は別記事で扱っています。

移行 既存データと取引先の移行

既存データの移行に加え、電話・FAXでの受発注に慣れた取引先をどう新システムへ移行させるかも、RFPの要求要件に含めます。移行の実務的な手順は別記事に譲ります。

汎用RFPテンプレートとの記載項目差を表で確認

これらの要求を要件定義の段階で言語化できていないと、RFPを書く段になって初めて不足に気づくことになります。RFP作成に着手する前に、この5項目が要件定義書に含まれているかを確認してください。

自社の業務を熟知した担当者が個別に確認するには、取引先の担当者数や代理店階層の把握、既存EDIの仕様確認など、複数部門にまたがる調整が必要です。この整理を自社の商習慣に即して行うには、受発注システムの提案実績を持つ相手と一度要件を突き合わせる方法もあります。無料相談で要件を整理するのも一つの手段です。

提案を比較できる書き方、回答書式と評価軸の指定

提案が比較できなくなる主な原因は、回答の書式を指定していないことにあります。ここでは、比較可能な提案を引き出すための4つの指定事項を扱います。

回答書式を指定する

提案書の章立て・様式・分量をRFP側で指定します。章立てをRFPの6部構成に合わせておくと、提出された提案書とRFPの要求を突き合わせやすくなるはずです。

見積の内訳区分を指定する

見積もりは、初期費用・月額費用・個別対応費用・保守費用・基盤費用といった区分ごとに提示するよう求めます。金額そのものの相場は本記事では扱いません。区分を揃えることで、総額だけでなく費用構造の違いを比較できるようになります。

前提条件の明示を求める

「提案の前提としている条件を書いてください」という一文を加えると、ベンダーが想定した取引先数やデータ量などの前提が可視化されます。前提が異なる提案を金額だけで比べると、条件のずれに気づかないまま選定してしまうおそれがあります。

非機能要求を別紙にする

非機能要件は、IPAの非機能要求グレードを認識合わせの共通様式として使う方法があります。樹系図で全体を俯瞰し、グレード表でレベル値を決めるという使い方をRFPの別紙として示すと、ベンダーとの間で要求レベルの解釈がずれにくくなります^*1。

書きすぎと書かなすぎの線引き

実現方法まで細かく指定すると、どの提案も同じ内容になり、ベンダーの工夫が提案に表れなくなります。反対に要求が曖昧すぎると、提案内容がばらついて比較できません。「何を実現したいか」は具体的に、「どう実現するか」はベンダーに委ねるという線引きが、比較可能性と提案の質を両立させます。

この線引きを自社だけで判断するには、機能要件と実現方法の切り分けに関する知識と、複数ベンダーの提案傾向を見た経験が必要です。判断に迷う場合は、受発注システムの提案を扱う相手に相談することもできます。

2026年施行の制度・法令要件をRFPに書く

2026年は、受発注システムのRFPに制度・法令要件を明記する必要性が高まる年です。

中小受託取引適正化法、2026年1月1日施行

2026年1月1日、下請法が中小受託取引適正化法（取適法）に改正・施行されます^*5。改正により、発注内容の明示について、中小受託事業者の承諾がなくても電子メールなどの電磁的方法で行えるようになりました^*5。あわせて、取引記録の作成・保存が委託事業者の義務とされ、違反した場合は勧告・指導のほか50万円以下の罰金が科される場合があります^*5。

受発注システムのRFPでは、この制度変更を踏まえ、発注内容を電子的に明示できる機能と、取引記録を保存・検索できる機能を要求要件に含めるかどうかを検討します。ただし、本記事は法令の解釈や適用可否を助言するものではありません。個別の適用判断は、所管官庁の公表資料を確認してください。

電子取引データの保存という論点

国税庁は、請求書・領収書・契約書・見積書などを電子データで送付・受領した場合、一定の要件を満たした形で保存することが必要になる制度を案内しています^*9。受発注システムでこれらの帳票を電子的にやり取りする場合、保存機能の要否をRFPの要求要件に含めるかを検討する論点になります。保存要件の具体的な内容や義務化の時期については、国税庁の公表資料を直接確認してください。

制度要件は発注側が要求として明記する

制度対応をベンダー任せにすると、提案ごとに対応レベルが異なったまま選定してしまう可能性があります。第3部の要求要件に「制度・法令要件」の欄を独立して設け、発注側が要求として明記する形にすると、提案の比較がしやすくなります。

公共調達の枠組みを参考にする

デジタル庁は、政府情報システムの整備・管理に関する共通ルールとして「デジタル社会推進標準ガイドライン群」を公開しています。その中のDS-100（デジタル・ガバメント推進標準ガイドライン）は、2026年6月12日に最終改定され、Normative（規範）と位置づけられています^*4。民間の受発注システム調達がこの枠組みに従う義務はありませんが、要求事項を体系的に整理する参考にはなるでしょう。

RFPでつまずく5つの箇所とどの段で潰すか

受発注システムのRFP作成でつまずきやすい箇所と、どの段階で対処すべきかを整理します。

• 要件定義をせずにRFPを書き始めてしまう。第2段の要件棚卸しに戻り、要件定義を先に済ませます。
• 現状の件数を出さず、提案の前提がベンダーごとにばらつく。第2部で受発注手段別の件数を示します。
• 回答書式を指定せず、提案を並べて比較できない。「回答書式を指定する」で示した内容を第4部に反映します。
• 実現方法まで書き込みすぎて、どの提案も同じ内容になる。「書きすぎと書かなすぎの線引き」を見直します。
• 取引先が使えるかを提案段階で確かめず、導入後に混乱する。商習慣要求の章で挙げた項目を提案依頼事項に含めます。

実現方法まで指定してしまう失敗は、要件定義の段階での知識不足がそのままRFPに持ち込まれるケースで多く見られます。機能要件と実現方法の切り分けを自社の担当者だけで判断するのが難しい場合、複数ベンダーの提案を見た経験を持つ相手に事前に相談すれば、線引きの精度は上がるでしょう。

そのまま使えるRFPチェックリスト

RFP作成の各段階で確認する項目を、章別と発行前の2つに分けて整理します。

章別のチェックリストは、次の通りです。

1. 第1部：目的と背景を業務の言葉で書いたか。
2. 第2部：受発注手段別の件数を示したか。
3. 第3部：機能・非機能・制度要件の3欄に分けたか。
4. 第4部：回答書式・見積区分・前提条件の明示要求を含めたか。
5. 第5部：評価基準とスケジュールを明記したか。
6. 第6部：契約形態と体制、秘密保持を前提条件として示したか。

作成に必要な工数は、要件定義の完成度や関係部署の数によって変わります。第3部・第4部を自社の担当者だけで仕上げるには、機能要件と非機能要件を切り分ける知識、複数ベンダーの提案傾向を踏まえた書式設計の経験が必要になります。この工程を専門パートナーに相談した場合、要件の整理から回答書式の設計まで一緒に詰められる点が、内製だけで進める場合との違いです。

まとめ｜商習慣と比較可能な書式がRFPの完成度を決める

本稿では、受発注システムのRFPの作り方を、6部構成・6段の作成手順・受発注システム固有の商習慣要求という3つの軸で整理しました。要点を3つに集約すると次の通りです。第一に、RFPは要件定義の成果物を提案比較できる形に変換する文書であり、要件定義の内容をそのまま転記するものではありません。第二に、掛売・与信・取引先別単価といった商習慣要求は、汎用テンプレートには載っておらず、自社で明記する必要があります。第三に、2026年施行の中小受託取引適正化法をはじめとする制度・法令要件を、ベンダー任せにせず要求要件へ明記することが、比較可能な提案を引き出す前提になります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

RFPと要件定義書は何が違いますか。

要件定義書は自社が何を実現したいかを言語化する文書、RFPはその要件をベンダーが比較可能な形で提案できるように再構成した依頼文書です。要件定義書は発注側の内部検討資料に近く、RFPは社外のベンダーへ渡す依頼文書という点で役割が異なります^*3。

RFPは何社に送るのがよいですか。

一次情報で裏づけられる標準的な社数は確認できていないため、具体的な数を断定することはできません。声をかける範囲は、要件を満たせそうな候補の有無、RFIを挟むかどうかの判断、比較検討にかけられる社内の工数によって決まります。

RFIは出す必要がありますか。

RFIは必須ではありません。候補ベンダーの技術力や実績がすでに把握できている場合は、RFIを省いてRFPから始めることができます。候補が絞れていない、あるいは新しい技術領域で情報が不足している場合に、RFPの前段階として活用するとよいでしょう。

予算をRFPに書くべきですか。

金額そのものの記載よりも、予算枠を示すか示さないかという判断軸で考えます。枠を示すと現実的な提案が集まりやすくなる一方、示さなければベンダーの提案の幅を狭めずに済むという違いがあります。金額の相場は別記事で解説しています。

評価基準の配点はベンダーに開示すべきですか。

開示すると、ベンダーは重視される項目に沿って提案を組み立てやすくなり、公平性を示しやすくなります。非開示にすると、配点に引っ張られない提案の工夫を引き出せる可能性もあるでしょう。どちらを選ぶかは、選定プロセスで何を重視するかによって決めます。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「システム構築の上流工程強化（非機能要求グレード）」（非機能要求グレード2018 利用ガイド[活用編] 2019年3月28日改訂）　https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
2. *2　出典：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（2020年12月22日）　https://www.ipa.go.jp/digital/model/model20201222.html
3. *3　出典：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版 ― 要件定義を成功に導く128の勘どころ」（2019年9月12日公開）　https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/youkenteigi20190912.html
4. *4　出典：デジタル庁「デジタル社会推進標準ガイドライン」（DS-100 デジタル・ガバメント推進標準ガイドライン、最終改定2026年6月12日）　https://www.digital.go.jp/resources/standard_guidelines
5. *5　出典：内閣府政府広報室（政府広報オンライン）「2026年1月から下請法が『取適法』に！委託取引のルールが大きく変わります」（2025年11月）　https://www.gov-online.go.jp/article/202511/entry-9983.html
6. *6　出典：経済産業省 商務情報政策局 情報経済課「令和6年度電子商取引に関する市場調査の結果を取りまとめました」（2025年8月26日）　https://www.meti.go.jp/press/2025/08/20250826005/20250826005.html
7. *7　出典：中小企業庁「中小企業の受発注デジタル化（中小企業共通EDI）」（出典調査：令和3年度取引条件改善状況調査、中小企業庁2021）　https://www.chusho.meti.go.jp/keiei/gijut/digitalization/index.html
8. *9　出典：国税庁「電子帳簿保存法関係／電子取引関係」　https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/tokusetsu/01.htm