Webサイト

RFI・RFP・RFQの違いとは?意味・使い分けと発行の流れを実務目線で整理

QAサイトシステム開発の重要性

RFI・RFP・RFQは、発注側がベンダーやサプライヤーに出す3種類の依頼文書です。名前が似ているため混同されがちですが、尋ねる対象が「情報か・提案か・価格か」で明確に分かれます。RFIで候補企業の情報を集め、RFPで解決策を比べ、RFQで価格と条件を確定する——この順番と役割を取り違えると、選定が長引いたり、安い見積もりに釣られて要件を満たせない相手を選んでしまったりします。システム開発の発注でも、製造業の部材調達でも骨格は同じです。この記事では3文書の意味と違いを整理し、RFI→RFP→RFQの発行の流れ、各文書で書くべき記載項目、IT・製造・購買での使い分け、そして実務で起きやすい失敗とその回避策までまとめます。

まとめ:RFI・RFP・RFQの違いと使い分けの結論

RFI・RFP・RFQの違いの本質は、発注側が尋ねる対象が情報(情報提供依頼書)・提案(提案依頼書)・価格(見積依頼書)のどれか、という一点にあります。発行順は原則 RFI→RFP→RFQで、情報収集で候補を広げ、提案比較で数社に絞り、価格比較で1社に決める、と判断の精度を段階的に上げていきます。ただし3つすべてを必ず出す必要はありません。仕様が確定した部材調達ならRFIやRFPを飛ばしてRFQから始めますし、要件が固まっているシステム案件ならRFPに見積項目を含めてRFQを兼ねることもあります。判断軸は「次の文書で新たに得たい情報があるか」。以下で各文書の中身、違い、流れ、記載項目、業界別の使い分け、よくある失敗を順に見ていきます。

RFI・RFP・RFQとは|3文書の意味と目的

まず3つの文書がそれぞれ何を尋ねるものかを押さえます。共通するのは「発注側が相手に出す依頼文書」であること。違いは、尋ねる対象が情報か、提案か、価格か、という点です。この違いが、出すタイミングと書くべき中身をそのまま決めます。

RFI(情報提供依頼書)とは|候補を知るための情報収集

RFIはRequest for Informationの略で、日本語では情報提供依頼書と呼びます。発注を本格検討する前段で、どんな企業が市場にいて、どんな製品・サービスや実績を持っているかを把握するために出す文書です。尋ねるのは会社概要・資本規模、同業種での導入実績、対応できる技術や業務範囲、サポート体制、そして概算の費用感まで。この段階では細かい提案や正式な見積もりは求めません。RFIの狙いは「候補をリストアップし、次に声をかける相手を絞る材料を得ること」にあります。市場や技術動向の理解がまだ浅いとき、社内に発注経験が少ないときほど効果が大きく、逆に候補も相場も把握済みなら省いてかまいません。RFIを丁寧に回すと、後段のRFPで的外れなベンダーに提案作成の手間をかけさせずに済みます。

RFP(提案依頼書)とは|解決策と体制の提案を求める

RFPはRequest for Proposalの略で、提案依頼書と訳します。自社の課題や実現したいことを示し、それをどう解決するかをベンダーに提案してもらう文書です。RFIで絞った候補に対して出すのが一般的で、ここで初めて発注側の要件を具体的に伝えます。書くのは、背景と目的、解決したい課題、必要な機能要件・非機能要件、予算の範囲、スケジュール、評価基準など。ベンダーはこれを受けて、解決方針・システム構成・体制・概算費用を盛り込んだ提案書を返します。RFPの質がそのまま提案の質を決めるため、要件をどこまで言語化できているかが勝負どころです。RFP単体の記載項目や、フル仕様で作り込むべき案件と簡易版で足りる案件の見極めはRFPとは何かを発注者視点で整理した解説で詳しく扱っています。RFPの前提となる要件整理については要件定義と設計の基本:成功するプロジェクトの基盤も参考になります。

RFQ(見積依頼書)とは|価格と条件を揃えた比較

RFQはRequest for Quotationの略で、見積依頼書を指します。発注する仕様や数量が固まっている段階で、その条件に対する価格・単価・納期・支払条件を出してもらう文書です。提案内容を比べるRFPと違い、RFQは条件を揃えたうえで「いくらでできるか」を比較するためのもの。だからこそ、仕様・数量・前提条件を発注側が明確に指定する必要があります。条件が曖昧なままRFQを出すと、各社が違う前提で見積もるため横並び比較が成立しません。製造業の部材調達や、保守・消耗品のような仕様が確定した反復購買では、RFIやRFPを挟まずRFQから始めることも珍しくありません。3文書のうち、価格比較の実務で最初に名前を確認されることが多いのがRFQです。

RFI・RFP・RFQの違い|目的・タイミング・記載内容の比較

3つの違いは、目的・発行タイミング・記載内容・回答形式の4つの軸で見ると整理できます。まず全体像を表で確認します。

観点 RFI RFP RFQ
正式名称 Request for Information Request for Proposal Request for Quotation
日本語 情報提供依頼書 提案依頼書 見積依頼書
尋ねる対象 情報 提案・解決策 価格・条件
主な目的 候補把握・絞り込み 解決策の提案比較 価格・条件の確定
発行タイミング 初期 中盤 終盤
送付先の目安 10社前後 3〜5社 2〜3社
主な回答 会社情報・実績 提案書・体制・概算費用 詳細見積・単価

目的と発行タイミングの違い

3文書は選定の進行に合わせて出すタイミングがずれます。RFIは「相手をまだ知らない」初期、RFPは「候補は絞れたが解決策を比べたい」中盤、RFQは「やることは決まったので価格を比べたい」終盤に対応します。焦点も段階的に狭まり、RFIは情報を広く集める、RFPは提案の優劣を見る、RFQは価格差を見る、と変わっていきます。送付先の数も、初期は10社前後と広く声をかけ、提案依頼で3〜5社、見積依頼で2〜3社へ絞るのが目安です(社数は案件規模で調整します)。この「広く集めて、絞って、確定する」という漏斗の形が、3文書を順に使う理由そのものです。

記載内容と回答形式の違い

記載内容は、後段ほど発注側が具体的に書く必要があります。RFIは質問項目が中心で、相手の自由記述に任せる部分が多い。RFPは課題・要件・評価基準まで踏み込むため、発注側の準備量が最も多くなります。RFQは仕様と数量を確定して渡すので、相手の回答は価格・納期といった数値に収れんします。回答形式で見ると、RFIは会社案内や資料、RFPは提案書(プレゼンを伴うことも多い)、RFQは見積書という違いです。つまり発注側の負担はRFPで最大になり、RFQは「どれだけ条件を固定して渡せるか」に成否がかかります。

RFPとRFQが混同されやすい理由と見分け方

RFPとRFQはどちらも「依頼して回答をもらう」点が同じで、提案書に概算費用が載るため境界が曖昧になりがちです。見分ける基準は、見たいものが「解決策か、価格か」の一点。解決方法そのものをベンダーに考えてほしいならRFP、やり方は決まっていて値段だけ比べたいならRFQです。ソフトウェア開発のように要件が固まりきらない案件はRFP寄り、仕様が確定した物品・保守の調達はRFQ寄り、と覚えると迷いません。実務では、RFPの中に見積項目を組み込み、提案と価格を一度に求めるケースもよくあります。逆にRFIとRFPの混同は少ないものの、「RFIで相場を聞いたつもりが正式見積のように扱われた」というズレは起きるため、RFIでは概算・参考であることを明記しておくと安全です。

RFI→RFP→RFQの流れ|ベンダー選定プロセスの全体像

RFI・RFP・RFQは単独で使うより、選定プロセスの流れの中で連携させると効果を発揮します。基本は前述の「広く集めて、絞って、確定する」の3段階です。

ステップ別の進め方と絞り込みの目安

標準的な進め方は次のとおりです。

  1. 現状の課題と発注の目的を整理し、候補となるベンダーをリストアップする
  2. RFIを10社前後に送り、会社情報・実績・対応範囲・概算費用を集める
  3. RFIの回答を見て目的に合わない先を外し、RFPの送付先を3〜5社に絞る
  4. RFPで解決策・体制・概算費用の提案を受け、評価基準で比較して2〜3社に絞る
  5. 選定先にRFQを出して価格・納期・条件を確定し、最終的に1社へ発注を決める

各段階で判断材料が「情報→提案→価格」と変わるため、前段の結果を踏まえて次に進むのが要点です。RFPの提示から各社の回答までは2〜3週間ほど見ておくと、提案の比較検討に十分な時間を確保できます。RFIとRFPは分けず、RFIの質問にRFPの前提を軽く含めて1回にまとめる運用もありますが、候補が多い初期ほど分けたほうが提案作成の負担を無駄にしません。

RFIやRFQを省略できるケースと判断基準

3文書をすべて出すのが常に正解ではありません。市場や候補企業をすでに把握していて、声をかける相手が決まっているならRFIは省けます。逆に、要件も発注先も固まっておらず社内に知見が薄い案件で、いきなりRFPを出すのは避けるべきです。提案がばらついて比較できず、選定をやり直すことになります。RFQについては、提案段階で概算費用が十分に詰まり、追加の価格交渉の余地が小さいなら、RFPに見積項目を含めて省略してかまいません。判断軸はシンプルで、「次の文書で新たに得たい情報があるか」。得たい情報がないなら、その文書は出さなくてよい、と考えると過剰なプロセスを避けられます。形式を全部こなすこと自体は目的ではありません。

RFI・RFP・RFQの記載項目|文書ごとに書くべき中身

どの文書も、発注側の意図が伝わらなければ回答の質が落ちます。共通して明記すべき項目と、文書ごとに固有の中身を分けて押さえます。

各文書に共通して明記すべき項目

RFI・RFP・RFQに共通して書いておきたいのは、発注の背景と目的、回答してほしい項目と様式、回答期限、提出先と問い合わせ窓口、そして秘密保持の扱いです。これらが抜けると回答の粒度がそろわず、比較に余計な手間がかかります。とくに「様式の指定」は横並び比較の前提で、自由記述に任せると各社バラバラの形で返ってきて集計できません。

文書ごとに固有の記載項目

共通項目に加えて、各文書で固有に指定すべき中身があります。

  • RFI:知りたい会社情報(資本・拠点・体制)、同業種での導入実績、対応可能な技術/業務領域、標準的な費用感、認証やセキュリティ体制
  • RFP:解決したい課題と機能要件・非機能要件、評価基準と配点、予算の範囲、スケジュール、希望する契約・体制
  • RFQ:対象品目・サービスの仕様と数量、希望納期と納品場所、保守・アフターの範囲、支払条件、見積有効期限、価格の前提条件(数量変動時の単価や為替・原材料価格の扱い)

とくにRFQは前提条件の指定が甘いと各社の見積もりが横並びにならず比較できません。単価×数量の内訳明細まで様式を指定し、仕様・数量・納期・保守範囲を発注側が固定して初めて、価格差だけを純粋に比べられます。RFPの土台となる要件定義の進め方は要件定義の全体像を理解し、効果的に進めるためのポイントで体系的に解説しています。要件が固まりきらない段階では、RFPで「実現したいこと」を伝えて解決策ごと提案してもらう進め方が現実的です。

IT・製造・購買での使い分け|業界と案件タイプ別の実務

RFI・RFP・RFQの型は共通でも、どの文書を主役にするかは業界と案件タイプで変わります。ここは検索結果でも手薄になりやすい論点なので、代表的な3パターンで整理します。

システム開発の発注|RFI→RFPが主役

要件が固まりきらないシステム開発では、RFI→RFPが中心になります。解決策そのものをベンダーに提案してもらう必要があるため、RFPの比重が最も高く、RFQは独立させずRFPの見積項目に含めることが多い。ここで効くのは、RFPを書く前の要件整理です。何を実現したいか(業務・機能要件)と、性能や運用などの非機能要件が言語化されていないと、ベンダーは前提を推測で埋めるしかなく、提案の精度が落ちます。要件整理を外部と進めたい場合は、業務システム開発のような開発・支援サービスに設計段階から相談する選択肢もあります。

製造業・自動車の部材調達|RFQが主役

図面や仕様が確定している部材・部品の調達では、RFQが主役になります。仕様が固まっているためRFIやRFPを挟まず、複数サプライヤーへ同一条件のRFQを出して単価を相見積もりで比較する、という進め方が中心です。自動車業界のように継続取引・量産が前提の調達では、単価だけでなく供給能力・品質保証・BCP(供給途絶時の代替)まで前提条件に含めて揃えるのが実務のポイント。価格だけで選ぶと、量産段階で供給が追いつかないリスクを抱えます。

間接材・定常購買|RFQのテンプレ化と効率化

消耗品や保守、定常的な間接材の購買では、同じRFQを繰り返し出すことになります。ここでは1回ごとの精度より、テンプレート化と回収・比較の効率が効いてきます。品目ごとに標準フォーマットを用意し、依頼から見積回収・横並び比較までを見積管理ツールやクラウドで一元化すると、担当者の集計負担が大きく減ります。逆に年数回の単発調達なら、表計算ソフトと定型フォーマットで十分回せます。発行頻度と社数で、ツール投資の要否を判断するのが現実的です。

RFI・RFP・RFQ運用でよくある失敗と回避策

文書の形式を整えても、運用を誤ると選定はうまくいきません。実務で繰り返し起きる失敗を、回避策とあわせて挙げます。

最も多いのが、要件が固まらないままRFPを出してしまう失敗です。提案の前提がベンダーごとにずれ、提案書を横に並べても比べられません。回避するには、RFPの前に最低限の要件定義を済ませ、評価基準を先に決めておくこと。基準を後出しにすると、印象や価格に引きずられた選定になりがちです。

次に多いのが、RFQを単なる価格表として使ってしまう失敗です。仕様や前提を曖昧にしたまま「見積もりください」と出すと、各社が異なる前提で計算し、安い見積もりが実は条件を満たしていない、という事態を招きます。相見積もりは条件が揃って初めて意味を持ちます。RFQは価格を比べる文書である前に、条件を揃える文書だと捉え、仕様・数量・納期・保守範囲を発注側が固定してから出すのが正解です。

3つ目は、プロセスを形式的に全部こなして時間を浪費する失敗です。要件も相手も決まっているのにRFIから始めれば、選定が数週間単位で遅れます。前段で述べたとおり、「次の文書で新たに得たい情報があるか」を基準に、不要な文書は省く判断をしてかまいません。形式を守ること自体は目的ではありません。

よくある質問

RFQとRFPはどちらを先に出すべきですか?

原則はRFPが先、RFQが後です。RFPで解決策と体制を提案してもらい、候補を絞ったうえで、選定先にRFQを出して価格を確定します。提案より価格の比較を優先したい、あるいは仕様が完全に固まっている調達では、RFPを省いてRFQから始めることもあります。判断軸は「解決策を比べたいか、価格を比べたいか」です。

RFCやRFIとの違いは何ですか?

RFC(Request for Comments、または Request for Change)は、技術仕様への意見募集や変更要求を指す言葉で、ベンダー選定で使うRFI・RFP・RFQとは目的が異なります。RFIが「候補企業の情報を集める」文書であるのに対し、RFCは仕様や提案に対するコメント・改善要求をやり取りするもの。調達・発注プロセスの文脈では、RFI・RFP・RFQの3つを押さえておけば実務上は十分です。

RFQクラウドや見積管理ツールは必要ですか?

送付先が多い、または見積取得が定常業務になっている場合は、見積依頼から回収・比較までを一元管理できるクラウドツールが効果的です。条件を揃えたテンプレートで依頼でき、回答の比較も自動化しやすくなります。一方、年に数回の単発調達であれば、表計算ソフトと定型フォーマットでも十分回せます。導入判断は発行頻度と社数で見るのが現実的です。

RFQ・RFI・RFPは英語で何と表記しますか?

RFQはRequest for Quotation、RFIはRequest for Information、RFPはRequest for Proposalの略です。海外ベンダーとのやり取りや、英語の見積仕様書を作成する際はこの正式名称が使われます。略語だけでなく正式名称を併記しておくと、相手に意図が正確に伝わります。

製造業や自動車業界でもRFI・RFP・RFQは使いますか?

使います。とくにRFQは、部品や部材の調達で仕様・数量が確定している取引が多い製造業・自動車業界で頻繁に用いられます。仕様が固まっているため、RFIやRFPを挟まずRFQから始めるケースが目立つのが特徴です。逆にシステム開発のように解決策から検討する案件では、RFI・RFPを経てから価格を詰める進め方が中心になります。

関連記事

資料請求

RELATED POSTS 関連記事