RFIとは RFP・RFQとの違いと記載項目・作成手順とベンダー選定の進め方

「システムを入れたいが、何ができるのかも相場も分からない」「RFPを書けと言われても、要件が固まっていない」。システム導入を検討し始めた段階で、多くの企業がぶつかる状況です。

RFIは、発注側がベンダーに対して会社情報や製品情報、導入実績などの提供を依頼する文書です。情報提供依頼書と訳されます。Request For Informationの略で、そのまま「アールエフアイ」と読みます。

位置づけとしては、RFPを作成する前の段階にあたります。市場に何があるのかを広く知り、自社の構想が実現可能かを確かめ、そのうえでRFPを書くための材料を得るための手続きです。

この記事では、RFPやRFQとの違いを整理したうえで、省略してよい場合の判断、記載すべき項目、作成と発行の手順、そして回答をRFPへつなぐ方法までを順に扱います。

確認したいポイント	結論	詳細
RFIとは？	情報提供依頼書のこと	発注側がベンダーに会社情報や製品情報、導入実績の提供を依頼する文書です。
RFPとの違いは？	情報収集が目的か、提案依頼か	RFIは広く浅く情報を集める一次選考、RFPは具体的な提案を求める二次選考です。
いつ出す？	RFPを作る前の段階	RFI→RFP→RFQという順序が基本です。要件が固まっていない段階で使います。
省略できる？	社内に知見があれば省略可	対象領域に詳しければ不要です。知見が乏しい場合は省略すると要件が的外れになります。

この記事でわかること

• RFIの定義と、RFP・RFQとの順序および役割の違い
• RFIを省略してよい場合と、省略すべきでない場合の判断
• 記載すべき6つの項目と、それぞれに何を書くのか
• 依頼先の選定から回答の比較までを通した5ステップ
• 集めた回答をRFPへつなぐ方法と、よくある失敗への対策

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発の依頼範囲や体制の決め方、費用と期間の目安を1冊にまとめました。 稟議の検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

RFIとは

RFIは、企業や官公庁が業務の発注や委託を計画する際、発注先候補の業者に情報提供を依頼する文書です。ITの分野では、システムの開発や購入、IT関連業務の委託を行う前に発行されます。

求める情報は、会社の概要、財務状況、開発実績、扱っている製品やサービスの情報、技術的な特徴、おおまかな費用感などです。公開されているWebサイトや会社案内では得られない情報を集めることが目的になります。

いつ発行するのか

要件が固まっていない段階で発行します。「何を作るべきか」がまだ決まっておらず、市場に何があるのかも分からないという状態が典型です。

システム化の構想が社内で決まったら、めぼしいベンダーへRFIを送って情報提供を求めます。その回答をもとにRFPを作成し、改めて提案を依頼するという流れになります。

RFIは一次選考、RFPは二次選考という使い分けをする企業も多くあります。RFIで幅広く情報を集めて候補を絞り、絞った相手にRFPを出すという進め方です。

発注側にとっての価値

RFIを出す意味は、単に情報を集めることだけではありません。4つの価値があります。

• 市場の把握：どういう製品やサービスが存在し、どのくらいの費用感なのかが分かる
• 実現性の確認：自社の構想が技術的に可能か、どの程度の期間がかかるかの見当がつく
• 候補の絞り込み：多数のベンダーから、自社に合いそうな数社を選び出せる
• RFPの品質向上：市場の実情に沿った要件を書けるようになる

4つ目が最も重要です。市場の実情から乖離したRFPを出すと、ベンダーは的確な提案ができません。結果として質の低い提案しか集まらず、選定そのものが失敗します。

情報処理技術者試験にも出題される

RFIは、情報処理技術者試験の出題範囲にも含まれる基本的な用語です。過去の試験では、新しいITソリューションの活用の是非を判断するために、提供者へ活用事例や技術情報の提供を依頼する文書として問われています。

また、既存システムの再構築に関して複数のベンダーへ新システムの実現イメージの提出を求めるRFIについて、同時に求めるべき情報を選ぶという形でも出題されています。

IT調達の基礎として位置づけられている用語であり、担当者が知っておくべき概念として扱われています。

RFP・RFQとの違い

混同されやすい3つの文書があります。順序と役割で整理します。

3つの文書の順序と役割

基本的には、RFI、RFP、RFQという順序で発行されます。段階が進むにつれて、求める内容が具体的になっていきます。

【調達の流れ】

①RFI（情報提供依頼書）

　　目的：広く浅く情報を集める

　　前提：要件は固まっていない

　　　↓

②RFP（提案依頼書）

　　目的：具体的な提案を求める

　　前提：要件と課題が整理されている

　　　↓

③RFQ（見積依頼書）

　　目的：費用の見積りとその内訳を求める

　　前提：仕様が確定している

RFIとRFPの違い

最もよく問われる違いです。RFIは情報を集めるため、RFPは提案を求めるためという目的の差があります。

RFIでは「貴社ではどういうことができますか」と尋ねます。RFPでは「弊社のこの課題に対して、どう解決しますか」と尋ねます。前者は相手のことを知るため、後者は自社の課題を解いてもらうためです。

この違いから、ベンダー側の準備の負担も大きく変わります。RFIの回答は既存の資料の組み合わせで作れますが、RFPへの回答は個別の検討が必要になります。回答期間も後者のほうが長くなります。

RFQの位置づけ

RFQはRequest For Quotationの略で、見積依頼書を指します。費用の見積り額とその内訳の提示を依頼する文書です。

システムに求める要件が明確にならないと見積り額も算出できないため、通常はRFPの後に発行されます。あるいは、RFPの中に見積りの提出を含めてしまう運用も一般的です。

中小企業の案件では、RFPとRFQをまとめることが多くあります。提案書と見積書を同時に提出してもらう形にすれば、手続きが1回で済みます。

一覧で整理する

3つの文書の違いを、観点ごとに並べます。自社がいまどの段階にいるかを確認する材料になります。

　　　　　　　RFI　　　　　RFP　　　　　　RFQ

目的　　　　　情報収集　　　提案の依頼　　　見積りの依頼

要件の状態　　未整理　　　　整理済み　　　　確定

対象社数　　　多い　　　　　絞り込み後　　　絞り込み後

回答期間　　　1〜2週間　　　3〜4週間　　　　1〜2週間

回答の性質　　既存資料中心　個別の検討　　　金額の算定

回答期間は目安です。案件の規模と要件の複雑さによって変わります。ベンダー側の負担を考えて設定することが、良い回答を得る条件になります。

RFIは省略できるのか

必ず出さなければならない文書ではありません。判断の基準を整理します。

省略してよい場合

導入したいシステムについて、社内に十分な知見がある場合は省略できます。何を作るべきかが分かっており、市場の製品も把握しているなら、情報収集の必要はありません。

既存システムの単純な更新、過去に同種の導入経験がある、業界で使われる製品が事実上限られている。こうした条件ならRFPから始めて構いません。

信頼できるベンダーとの継続的な取引がある場合も同様です。すでに相手の実力と実績を知っているなら、改めて情報提供を求める意味は薄くなります。

省略すべきでない場合

逆に、社内に知見がない領域では省略すべきではありません。要件が市場の実情から乖離したまま進むことになります。

初めて導入する種類のシステム、新しい技術の活用を検討している、取引経験のないベンダーを候補にしたい。こうした場合はRFIの価値が高くなります。

予算の規模が大きい案件も、省略しないほうが安全です。投資額が大きければ、事前の情報収集にかける時間は十分に回収できます。

省略したときに起きること

実際に起こる問題を挙げます。いずれも後の工程で手戻りになります。

既製品で実現できることをスクラッチ開発の要件として書いてしまう。市場に存在しない機能を前提にしてしまう。予算の想定が実勢価格と数倍ずれている。あるいは、候補ベンダーが自社の領域を扱っていなかった。

RFPを出し直すことになると、数週間から数か月の遅れが生じます。ベンダー側の信用にも影響します。「この会社は準備ができていない」という印象は、以降の提案の質を下げます。

RFIに記載すべき項目

決まった様式はありませんが、押さえるべき項目は共通しています。次の6つを埋めれば実用に足ります。

1. 依頼の目的と背景

冒頭で、何のために情報提供を求めているのかを明示します。ここが曖昧だと、集まる情報も的外れになります。

「既存システムの老朽化に伴う入れ替えの検討」「業務効率化のための新技術の導入検討」といった形で、達成したいことを具体的に示します。プロジェクトの規模や業界の特性も添えると、ベンダーが適切な情報を選べます。

現時点でRFPを作成する前段階であることも明記します。これがないと、ベンダーは本格的な提案書を作り込んでしまい、双方の負担が無駄になります。

2. 現状と課題の概要

いま何に困っているのかを伝えます。詳細でなくて構いませんが、ベンダーが状況を想像できる程度の情報は必要です。

利用者数、扱うデータの規模、現在使っているシステムの構成、業務の流れの概略。数値を含めると、ベンダーは規模感を把握できます。

機密情報に触れる部分は伏せて構いません。ただし、伏せすぎると回答の精度が落ちます。必要に応じて秘密保持契約を締結するという選択肢もあります。

3. 検討している構想

現時点で考えている方向性を示します。確定している必要はなく、むしろ「こう考えているが妥当か」という問いかけの形で構いません。

「クラウド型のサービスを想定しているが、自社構築との比較も知りたい」といった書き方をすると、比較の材料が返ってきます。

実現イメージの提出を求めるという形も一般的です。この場合、ベンダーは概略の構成図や類似事例を添えて回答します。

4. ベンダーに求める情報

最も重要な項目です。何を教えてほしいのかを箇条書きで明示します。

• 会社概要：事業内容、従業員数、財務状況、拠点
• 実績：類似案件の件数、業種、規模、期間
• 製品・サービスの情報：標準機能、カスタマイズの可否、技術的な特徴
• 概算の費用感：初期費用と運用費用のおおまかな幅
• 想定される期間：導入までにかかる期間の目安
• 体制：対応可能な要員数、保守サポートの範囲と時間帯

非機能面も確認しておくと後が楽になります。IPAが公開する非機能要求グレードでは、可用性、性能・拡張性、運用・保守性など6つの大項目について要求レベルを段階的に整理する枠組みが提供されています。この分類に沿って質問すると、抜けなく確認できます。

5. 回答期限と提出方法

期限、提出先、提出形式を明記します。ベンダーが社内で承認を得る時間も必要なため、余裕を持って設定します。

RFIであれば1週間から2週間が目安です。短すぎるとベンダーが辞退し、長すぎると自社のスケジュールが押します。

質疑の受付期間も設けておくと、認識のずれを防げます。あわせて問い合わせ先の担当者と連絡方法を記載します。

6. 秘密保持と留意事項

双方の情報の扱いを定めます。発注側が開示する情報、ベンダーが開示する情報のいずれも、他社に知られたくない内容を含む可能性があります。

必要に応じて秘密保持契約を締結します。RFIの段階から締結しておくと、より踏み込んだ情報を得られることがあります。

あわせて、RFIへの回答が発注を約束するものではないこと、費用は各社の負担であることを明記します。後の認識の違いを防ぐための記載です。

何を聞くべきかの整理からご相談いただけます 書き方は分かっても、自社が何を確認すべきかの判断は別の問題です。 構想の整理からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

作成と発行の手順｜5ステップ

準備に時間をかけすぎないことも大切です。RFIは調査の手続きであり、それ自体が目的ではありません。

ステップ1｜目的と知りたいことを決める

「何を判断するために、何を知りたいのか」を先に決めます。ここが曖昧なまま項目を並べると、集まった情報を使えません。

たとえば「既製品で足りるかスクラッチが必要かを判断したい」という目的なら、各製品の標準機能とカスタマイズの範囲を重点的に聞くことになります。

目的から質問項目を導くという順序を守ります。逆に質問項目から考え始めると、聞きたいことが際限なく増えます。

ステップ2｜依頼先を選ぶ

5社から10社程度が現実的な範囲です。少なすぎると比較になりませんが、多すぎると回答の整理に時間がかかります。

選び方は、業界での実績、同業他社の導入事例、規模の近さ、所在地です。大手と中堅を混ぜると、費用感の幅が見えてきます。

既存の取引先も含めます。付き合いのある会社を外すと、関係に影響することがあります。あわせて、取引経験のない会社を1社は入れると、新しい選択肢が見つかります。

ステップ3｜文書を作成する

前章の6項目を埋めていきます。分量はA4で3枚から5枚程度で十分です。詳細な仕様を書き込む必要はありません。

回答してもらう形式は、可能であれば表形式のシートを用意します。各社が自由形式で回答すると、比較する段階で苦労します。

自由記述の欄も設けます。こちらが想定していない情報が、そこから得られることがあります。「その他、ご提案いただける点があればご記載ください」という一文で足ります。

ステップ4｜発行して質疑に対応する

各社へ同時に送付します。内容に差をつけないことが公平性の前提です。

質疑には誠実に対応します。質問の内容そのものが、ベンダーの理解度を示す情報にもなります。的確な質問をしてくる会社は、読み込んでいる会社です。

質問と回答は、可能であれば全社に共有します。公平性が保たれ、こちらの説明不足も一度に解消できます。

ステップ5｜回答を整理して比較する

集まった回答を1枚の比較表にまとめます。項目を縦、ベンダーを横に並べる形が読みやすくなります。

この段階では優劣をつけません。まず事実を並べ、傾向を把握します。「費用感は300万円から1,200万円の幅がある」「クラウド型を提案する会社が多数」といった全体像が見えてきます。

回答がなかった会社、辞退した会社も記録します。辞退の理由が、自社の条件に無理がある兆候を示していることもあります。

回答の扱いとRFPへのつなぎ方

RFIの真価は、集めた情報をどう使うかで決まります。

要件の整理に反映する

最も重要な使い方です。回答から得た市場の実情を、自社の要件に反映させます。

「この機能は標準で持っている製品が多いので、あえて要件に書く必要はない」「この連携は追加開発が必要で費用が上がるので、優先度を下げる」といった判断ができるようになります。

構想そのものの修正も必要になります。「想定していた予算では実現できない」と分かったなら、範囲を絞るか予算を積み増すかを決めます。要件の書き方は要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

候補を絞る基準

RFPを送る相手を3社から5社に絞ります。それ以上になると、提案の評価に時間がかかりすぎます。

絞る基準は、自社の要求領域との適合、類似案件の実績、費用感の折り合い、対応体制、そして回答そのものの丁寧さです。

回答の丁寧さは軽視できない指標です。RFIの段階で雑な回答を返す会社が、RFPで丁寧な提案をすることは期待しにくくなります。

社内での説明材料にする

見落とされやすい使い方です。RFIの回答は、予算確保のための客観的な材料になります。

「複数社に確認した結果、この規模の投資が必要と判明した」という説明は、担当者の推測より説得力があります。期間の見通しについても同様です。

非現実的な計画を修正する根拠にもなります。経営層が想定していた予算や期間が実勢と合わない場合、外部の情報として提示することで議論が進みます。

辞退したベンダーへの対応

回答してくれた各社へ、結果を連絡します。RFPへ進まない会社にも一報を入れます。

無償で情報提供を受けている以上、最低限の礼儀にあたります。また、別の案件で候補になる可能性も残ります。

理由を簡潔に伝えられれば理想的です。「今回は対象領域が合わなかった」という一言でも、次の機会につながります。

よくある失敗

手続きを踏んでも情報が得られないというケースには、共通の原因があります。

目的が曖昧で情報が集まらない

最も多い失敗です。「何かいい提案はありませんか」という趣旨のRFIには、カタログを送り返されるだけです。

ベンダーは、何を知りたいのか分からなければ的を絞れません。結果として一般的な会社案内と製品パンフレットが届き、比較の材料になりません。

対策は、判断したいことを明示することです。「既製品で足りるかを判断したい」と書けば、それに沿った情報が返ってきます。

質問が多すぎて回答負担が重い

逆方向の失敗です。100項目を超える質問票を送ると、辞退されます。

RFIは無償の情報提供です。ベンダーにとって、受注の確度が見えない段階で大きな工数を割く合理性はありません。負担が重すぎれば、有力な会社から順に辞退します。

目安として30項目程度に収めます。詳細はRFPの段階で聞けば済みます。この段階では、候補を絞るために必要な情報だけを求めます。

特定ベンダーに偏る

既存の取引先だけにRFIを送るケースです。比較にならないため、RFIを出す意味がありません。

また、質問項目が特定製品の仕様に沿って作られていると、他社が回答しにくくなります。結果として、実質的に1社しか選べない状態になります。

製品に依存しない表現で質問することが対策です。「この製品のこの機能はありますか」ではなく「この業務をどう実現できますか」と聞きます。

回答を提案と誤解する

RFIの回答に書かれた費用や期間を、確定したものとして扱ってしまうという誤りです。

RFIの段階では要件が固まっていません。そこで示される金額は、あくまで概算の幅です。要件が固まれば数倍に変わることもあります。

社内で共有する際は、概算であることを明記します。この数値が予算として固定されると、後のRFPの段階で無理が生じます。

中小企業での現実的な運用

大企業と同じ手続きを踏む必要はありません。規模に見合った形で十分な効果が得られます。

簡易な形式で構わない

A4で2枚程度の文書でも成立します。目的、現状、聞きたいこと、期限。この4点があれば足ります。

形式にこだわって作成に時間をかけるより、早く出して情報を得るほうが価値があります。メールの本文に書いて送るという方法でも構いません。

IPAが公開する情報システム・モデル取引・契約書（第二版）は、ユーザ企業とITベンダのいずれにもメリットが偏らない中立的な契約書を目指して作成されたものです。調達の段取りや役割分担を整理する際の参考になります。

3社から5社に絞る

小規模な案件であれば、依頼先は3社から5社で十分です。10社に送っても、整理の負担が増えるだけで判断は良くなりません。

選び方は、同業他社が使っている製品の提供元、地域で実績のある会社、既存の取引先という組み合わせが現実的です。

回答が3社揃えば、費用感の幅は見えてきます。相場を知るという目的であれば、この規模で達成できます。

期待値を伝えておく

「現時点では情報収集の段階である」と明記します。これがないと、ベンダーが提案書を作り込んでしまいます。

あわせて、この後の流れも伝えます。「回答をもとに候補を絞り、来月にRFPを発行する予定」という一文があれば、ベンダーは適切な粒度で回答できます。

誠実に段取りを伝える会社は、ベンダーからも協力を得やすくなります。発注側の進め方についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも整理しています。

まとめ

RFIは、発注側がベンダーに会社情報や製品情報、実績の提供を依頼する文書です。RFPを作成する前の段階で発行し、市場の把握と候補の絞り込みを行います。

RFP・RFQとの違いは目的と前提です。RFIは要件が未整理の段階で情報を集め、RFPは整理された要件に対する提案を求め、RFQは確定した仕様に対する見積りを求めます。

記載すべきは、目的と背景、現状と課題、検討している構想、求める情報、回答期限と提出方法、秘密保持と留意事項の6項目です。A4で3枚から5枚程度で足ります。

最も多い失敗は、目的が曖昧で一般的なカタログしか集まらないことです。「何を判断するために何を知りたいのか」を明示することが、有用な回答を得る条件になります。

まずは「既製品で足りるのか、開発が必要なのか」という1点に絞って、3社に聞いてみてください。この問いへの回答だけでも、計画の現実味は大きく変わります。

システム導入の進め方から、無料で相談できます 何から検討すべきか分からない、社内にシステム調達の知見がなく不安があるといった段階のご相談も承っています。 営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎