RFI(アールエフアイ・情報提供依頼書)

システム開発や情報インフラの整備を検討する組織が最初に直面する問いは、「何をどのベンダーに頼めばいいのか」という問いである。ITシステムの調達や業務委託において、発注者側の担当者が技術仕様や市場動向を十分に把握しているケースは少ない。

一方でベンダー側も、発注者の要件・規模・予算感が見えない状態では的確な提案が難しい。このギャップを埋める情報交換の仕組みとして機能するのがRFI（Request For Information：情報提供依頼書）である。

RFIは調達プロセスの最上流に位置し、ベンダー選定の精度を高めると同時に、組織内の意思決定者に対して選定根拠を明示する文書としても活用される。

コンサルティングの文脈では、ITコンサルタントやPMO（Project Management Office：プロジェクト管理組織）がRFI策定を支援する場面が多く、調達管理の基礎知識として実務上の重要性は高い。

RFIとは

RFIはRequest For Informationの頭文字であり、日本語では「情報提供依頼書」と訳される。調達プロセスにおいて、発注者がベンダー候補企業に対し、自社製品・サービス・技術力・導入実績などに関する情報の提供を求める正式な文書である。

RFIの目的は大きく2つに整理できる。

第一に、発注者が市場に存在するソリューションや技術水準を把握し、要件定義の精度を高めることである。

第二に、ベンダー候補を絞り込み、次工程であるRFP（Request For Proposal：提案依頼書）の送付先を決定することである。

RFIはあくまでも「情報収集」の段階であり、この段階で発注者が要件の詳細を完全に固める必要はない。

ただし、RFIに盛り込む依頼事項の内容によって、回答の精度や有用性が大きく変わるため、問いの設計そのものに一定のスキルが求められる。

なお、小規模な案件や既存取引先との更新交渉では、RFIが省略されメールでの情報交換に代替されることもある。

大規模なシステム調達・業務委託プロジェクトほど、RFIを正式プロセスとして設定する傾向がある。

RFIの主要記載項目

具体例／ミニケース

製造業A社が基幹システム（ERP：Enterprise Resource Planning、企業の基幹業務を統合管理するシステム）の刷新を検討している場面を想定する。

A社の情報システム部門は、現行システムの保守期限切れに伴い、新ERPの選定を開始した。しかし担当者はSAP・Oracle・Microsoft Dynamicsなどの主要製品の違いや、クラウド型とオンプレミス型（自社設備上でシステムを運用する形態）の費用構造を十分に把握していなかった。

そこでA社は、候補ベンダー10社にRFIを発行した。依頼内容には「製造業向け導入実績（従業員500名以上の事例）」「クラウド移行時の概算コスト体系」「カスタマイズの自由度と標準機能のカバー範囲」「保守・サポート体制」を盛り込んだ。

回答を比較した結果、A社は製造業実績が豊富で費用体系が透明な3社に絞り込み、次工程のRFPを送付した。RFIがなければ、要件定義も不十分なままRFPを10社に送付し、提案内容の比較が困難になっていた可能性が高い。

RFI・RFP・RFQの違い

調達プロセスでは、RFIのほかにRFP（提案依頼書）とRFQ（Request For Quotation：見積依頼書）が登場する。それぞれの位置づけと目的の違いを正確に理解することが、調達支援業務の基礎となる。

RFIは「何が可能か・誰に頼めるか」を探索する文書であり、RFPは「この要件を満たす提案を出してほしい」と求める文書である。RFQはさらに進んで「この仕様でいくらか」を確認する文書であり、3者はプロセスの上流から下流に向かって順に発行されるのが一般的である。

実務上、小規模案件ではRFIを省略してRFPから始めるケースも多いが、大規模・複雑なシステム調達ではRFI→RFP→RFQの順を踏むことでリスクを抑制できる。

コンサルティング業務での位置づけ

論点設計（イシュー出し）

コンサルタントがクライアントのシステム調達プロジェクトに参画する際、最初の論点は「RFIを発行すべきかどうか」という判断そのものである。

要件定義の成熟度・市場知識のギャップ・候補ベンダーの特定状況などを評価し、RFIの必要性と設計方針をイシュー（Issue：解くべき問い）として整理する。

「発注者の要件が未確定な状態でRFPを発行した場合、ベンダー提案の質がばらつきすぎて比較不能になるリスクがあるか」という論点を立て、RFI先行の判断根拠を明文化することが、プロジェクト上流での価値発揮につながる。

現状分析（As-Is整理）

RFI回答の分析フェーズでは、各ベンダーの回答内容を構造化して比較可能な形に整理することが求められる。コンサルタントは評価軸（技術適合性・実績・費用体系・体制・リスク等）を設定し、ベンダーごとの強み・弱みをAs-Is（現状）として可視化する。

この作業には定性情報の定量化も含まれる。たとえば「実績件数」「類似案件のプロジェクト規模」「回答の具体性」を評価スコアに変換することで、クライアント内部の意思決定を円滑にする。

施策設計（To-Be）

RFI分析結果をもとに、次工程であるRFPの送付先リストとRFP設計方針を策定することが、施策設計（To-Be）フェーズにおけるコンサルタントの主要アウトプットとなる。

RFIで判明したベンダー間の技術格差や価格体系の違いを踏まえて、RFPに盛り込むべき要件の優先順位や評価基準を設計する。この段階での判断の質が、最終的なベンダー選定精度と調達コストに直結する。

資料作成（スライド構造）

クライアントの経営層や意思決定者に対してRFI結果を報告する際、コンサルタントはベンダー評価サマリー・比較マトリクス・推奨候補の根拠を1枚のエグゼクティブサマリーに集約することが多い。

スライド構造としては、「調査目的と実施概要→回答ベンダー一覧→評価軸別スコア比較→上位候補の特徴整理→次工程（RFP）への推奨事項」という流れが標準的である。

意思決定者が短時間で判断できる構造を意識した資料設計が、コンサルタントとしての付加価値を示す場面となる。

導入メリットと注意点

RFI活用のメリット

• 発注者側の市場知識・技術知識を補完し、要件定義の質を高められる
• ベンダー候補を早期に絞り込むことで、RFP以降のプロセスを効率化できる
• 複数ベンダーの比較によって、概算コストの相場観を把握できる
• 社内の意思決定者に対して、ベンダー選定の根拠と透明性を担保できる
• ベンダー側にとっては、初期段階で自社をアピールできる機会となる

注意点と適用限界

• 法的拘束力はない：RFIはあくまでも情報収集の文書であり、回答内容が契約条件を保証するものではない。回答精度や情報の鮮度はベンダー側の判断に委ねられるため、重要事項は後工程で改めて確認が必要である。
• ベンダー側の負担に配慮する：回答に要する工数はベンダー側が負担する。過度に詳細な情報を要求すると、中小ベンダーが参加を断念し、選定対象が大手に偏るリスクがある。
• 機密情報の管理：RFIには自社の構想や現状システムの情報が含まれることがあり、情報管理契約（NDA：Non-Disclosure Agreement）の締結を事前に検討することが望ましい。
• RFIで得た情報の陳腐化リスク：技術や市場環境の変化が速い領域では、RFI回答から時間が経過するにつれて情報の有効性が低下する。RFPまでのリードタイムが長くなる場合は注意が必要である。

コンサル採用面接との接点

コンサルティングファームの採用面接において、RFIという用語が直接問われることは多くない。しかしITコンサルタントや調達支援・PMOポジションを志望する場合、RFIを含む調達プロセス全体の流れを理解していることは、ケース解答や経験談の論理展開に厚みをもたらす。

たとえばケース面接で「クライアントが新システムを導入する際の進め方を提案してほしい」という問いに対し、「まず市場情報とベンダー能力を把握するためにRFIを実施し、候補を絞ったうえでRFPを発行する」という構造で回答できると、プロセス設計の解像度が高い候補者という印象を与えやすい。

また、過去の職務経験においてシステム調達・ベンダー選定・IT戦略策定に関わった経験を持つ候補者が、その文脈でRFIの役割を自然に語れる場合、実務感覚を持った候補者として説得力が増す。RFI・RFP・RFQの違いとプロセス上の位置づけの骨格をおさえておけば、十分な知識基盤となる。

FAQ

Q1. RFIとは何か、一言で説明するとどういう文書か

RFIとは、業務委託やシステム調達の検討初期段階において、発注者がベンダー候補企業の製品・技術・実績・価格体系などに関する情報提供を正式に依頼する文書である。

調達プロセスの最上流に位置し、発注者側の市場知識の不足を補いながら、ベンダー候補の絞り込みと要件定義の精緻化を同時に進めるための仕組みとして機能する。

法的拘束力は持たず、あくまでも情報収集を目的とした文書である点が、後工程のRFP（提案依頼書）やRFQ（見積依頼書）と大きく異なる。

特にIT・情報システム領域では、発注者の技術知識の不足が多いため、RFIの活用によって市場全体を俯瞰したうえでの合理的な意思決定が可能となる。

Q2. RFIとRFPの違いは何か

RFIとRFPの最大の違いは、「要件の確定度」と「求める回答の性質」にある。RFIは発注者の要件が未確定な段階で発行され、ベンダーの能力・製品・実績などに関する情報の提供を求める文書である。

一方RFPは、要件がある程度確定した段階で発行され、具体的な解決策・提案内容・費用・スケジュールの提示を求める文書である。プロセスの観点では、RFIで市場調査とベンダー候補の絞り込みを行い、その結果を踏まえてRFPを発行するというシーケンシャルな関係にある。

RFIへの回答内容は法的拘束力を持たないが、RFPへの回答（提案書）は契約交渉の起点となる点でも両者は異なる。小規模案件ではRFIを省略してRFPから始めることも多い。

Q3. RFIはどのような手順で作成・運用するのか

RFI作成・運用の標準的な手順は以下の流れで進む。まず発注者側が「何を知りたいか」「どのような情報があれば意思決定できるか」を整理し、依頼事項を設計する。

次にベンダー候補リストを作成し（通常5〜15社程度）、RFI文書を送付する。回答期限は一般に2〜4週間程度が多い。回答収集後は評価軸（技術・実績・費用・体制等）に沿って比較・分析を行い、次工程（RFP）の送付先を決定する。

注意点として、RFIの依頼事項が曖昧すぎると回答の質がばらつくため、「知りたい情報の粒度」をある程度明示することが重要である。機密情報を伴う場合はNDA（秘密保持契約）の事前締結も検討する。

Q4. コンサルティングの実務でRFIはどのように活用されるか

ITコンサルタントやPMOがRFIに関わる場面は主に3つある。

第一は「RFI設計支援」であり、クライアントが適切な依頼事項を設定できるよう、評価軸・質問項目・フォーマットを設計する。

第二は「回答分析・ベンダー評価」であり、複数ベンダーの回答を構造化して比較し、上位候補の推奨根拠をクライアントに提示する。

第三は「次工程設計」であり、RFI分析結果を踏まえてRFP要件の優先順位や評価基準を設計する。特にERPや基幹システムの刷新案件では、ベンダー市場の全体像把握とコスト相場の確認にRFIが有効であり、プロジェクトROI（Return On Investment：投資対効果）の根拠形成にも貢献する。

Q5. RFIに関してよくある誤解は何か

最も多い誤解は「RFIは契約に向けた正式な提案依頼と同じだ」という認識である。RFIはあくまでも情報収集を目的とした文書であり、回答内容が自動的に提案書や見積書の効力を持つわけではない。

別の誤解として「RFIを発行したら必ずRFPも発行しなければならない」という思い込みがあるが、RFI結果を踏まえて調達自体を見直したり、特定ベンダーとの随意契約に切り替えたりすることも実務では起こり得る。

また「RFIには決まった書式がある」と考えるケースも多いが、標準的な公式フォーマットは存在せず、プロジェクトの性質や組織のガバナンス方針によって記載内容は異なる。形式よりも「何を知りたいか」という設計思想の方が重要である。

Q6. RFIはどのような業種・規模の案件で使われるか

RFIは業種を問わず活用されるが、特に利用頻度が高いのはITシステム調達（ERP・CRM・クラウドインフラ等）、製造業の生産管理システム刷新、官公庁・自治体の情報システム整備、大手企業のアウトソーシング先選定などである。

規模感としては、数千万円以上の業務委託や複数年にわたるシステム保守契約では正式なRFIが機能しやすい。

一方、数百万円以下の小規模開発やリピート取引ではRFIを省略しメールでの情報交換に代替されることが多い。

官公庁調達では入札制度との整合から、RFIを「情報収集のための市場調査」として位置づけることが制度上も認められており、公共調達における透明性確保にも寄与している。

まとめ

RFIは、業務委託やシステム調達における「情報の非対称性」を解消するための文書として、調達プロセスの最上流に設置される仕組みである。

発注者の市場知識を補完し、要件定義の精度を高め、適切なベンダー候補の絞り込みを可能にするという点で、調達全体の品質を左右する重要なプロセスといえる。

コンサルティングの文脈では、RFI設計支援・回答分析・ベンダー評価・次工程設計といった形でITコンサルタントやPMOが関与することが多く、調達プロセス全体を俯瞰した知識はプロジェクト上流での価値発揮につながる。

RFI・RFP・RFQの違いとプロセス上の役割を整理しておくことは、IT戦略や調達支援の業務にとっての基礎的な知識基盤となる。

採用面接においても、RFI単体の知識として問われることは多くないが、システム調達や業務委託の文脈でプロセス設計を語る際の基礎として機能する。概要と考え方の骨格をおさえておけば、実務的な論理展開に十分な厚みが生まれる。

出典

• デジタル庁「デジタル社会推進標準ガイドライン」（政府情報システムの整備・管理・調達に関する共通ルール群）
  https://www.digital.go.jp/resources/standard_guidelines
• 経済産業省「情報システムの信頼性向上のための取引慣行・契約に関する研究会」（情報システム・モデル取引・契約書、RFP関連文書を含む）
  https://www.meti.go.jp/policy/it_policy/softseibi/
• デジタル庁「デジタル庁調達事務マニュアル」（市場調査〔RFI〕の手続きを明記、2024年8月版）
  https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/883b9dc1-3155-4a26-a0cc-c2b5fb0d41d1/393d57e3/20240814_procurement_manual_01.pdf