こんにちは！株式会社雲海設計の技術部です。2026年7月現在、弊社のIT経営相談で急増しているのが「RFPとRFIの違いがよく分からず、いきなりRFPを出して見積が揃わなかった」「情シスがRFIだけで発注を決めてしまい、要件が曖昧なまま契約してトラブルになった」「そもそもどのタイミングでどちらを使うべきか社内基準がない」という中堅中小企業の情シス・経営企画層からのご相談です。JUAS（日本情報システム・ユーザー協会）が2026年5月に公表した『企業IT動向調査2026』では、ベンダー選定で「期待外れだった」と回答した企業の63%が「RFI/RFPプロセスを省略もしくは混同していた」と回答しています。
本記事では、RFP RFI 違いというキーワードで検索する発注企業の意思決定者向けに、両者の違いを目的・タイミング・記載項目・回答活用の4軸で整理し、実務で使える使い分け判断フローとテンプレート項目を解説します。用語辞典的な解説ではなく、雲海設計が支援現場で使っている「案件規模と成熟度に応じたプロセス設計」の実装知の共有がゴールです。
- RFI（情報提供依頼書）は「市場と選択肢を知る」ためのもの、RFP（提案依頼書）は「具体的な提案と見積を取る」ためのもの
- 両者は目的・タイミング・記載項目・回答活用の4軸で明確に異なる
- RFIを飛ばしてRFPに進むと「提案の粒度がバラバラで比較不能」という失敗が起きやすい
- 案件規模5,000万円以上・技術選定が未確定・複数部門横断のケースはRFI→RFP の2段階必須
- 2026年の新論点は「生成AI・SaaS前提のRFP設計」と「AIベンダー特有の評価軸追加」
RFPとRFIはそもそも何が違うのか？
結論から言うと、RFI は「知るための文書」、RFP は「選ぶための文書」です。両者を混同すると、ベンダーからの回答粒度が揃わず、比較検討ができなくなります。
RFI（Request for Information）とは
RFIは情報提供依頼書と訳され、市場にどんなソリューション・ベンダー・実現方式があるかを広く把握するための文書です。発注側の要件がまだ固まっていない段階で、複数ベンダーに会社概要・実績・技術的アプローチ・概算費用感を求めます。回答は数ページ〜十数ページ程度で、拘束力はありません。
RFP（Request for Proposal）とは
RFPは提案依頼書と訳され、具体的な要件・課題を提示した上で、ベンダー各社に具体的な提案・見積・スケジュール・体制を求める文書です。回答は数十ページに及ぶことが多く、これをもとに最終的な発注先を決定します。RFPへの回答は実質的に契約の基礎資料となるため、記載内容には拘束力があります。
4軸で比較する RFI と RFP
| 比較軸 | RFI（情報提供依頼書） | RFP（提案依頼書） |
|---|---|---|
| 目的 | 市場・選択肢・実現可能性の把握 | ベンダー選定と発注意思決定 |
| タイミング | 企画・構想フェーズ | 要件定義完了後・調達フェーズ |
| 記載項目 | 背景・課題感・欲しい情報の粒度 | 要件・制約・評価基準・契約条件 |
| 回答活用 | 要件整理・RFP作成の材料 | 提案評価・ベンダー選定・契約交渉 |
| 回答期間 | 2〜3週間 | 4〜8週間 |
| ベンダー数 | 5〜10社に広く依頼 | 3〜5社に絞って依頼 |
| 拘束力 | なし（参考情報） | あり（提案書は契約前提資料） |
この4軸の違いを理解せずに「とりあえずRFPを出せば見積が来る」と考えると、要件が曖昧なまま各社バラバラの前提で提案してきて、金額も内容も比較不能になります。これがベンダー選定失敗の典型パターンです。
なぜRFIを飛ばしてRFPに進んではいけないのか？
結論から言うと、要件が固まっていない状態でRFPを出すと、ベンダーが独自解釈で提案し、比較軸が揃わないからです。特に情シスや経営企画がベンダー選定に慣れていない企業ほど、RFIを省略しがちです。
RFI省略で起きる3つの失敗
- 提案の粒度がバラバラ：A社はスクラッチ開発前提、B社はSaaS導入前提、C社はローコード前提と、実現方式が異なる提案が並び比較できない
- 金額のレンジが極端に開く：500万円〜5,000万円のような10倍レンジの見積が返ってきて意思決定不能に
- 要件の抜け漏れ：市場動向を知らないまま要件を書くため、後から「そんな機能があるならそっちが良かった」となる
RFIが特に必要になる3つのケース
雲海設計の支援現場では、以下のケースは必ずRFIから始めるようクライアントに提案しています。
- 案件規模5,000万円以上：失敗コストが大きく、選定プロセスの精度が投資対効果を左右する
- 技術選定が未確定：スクラッチ/SaaS/ローコードなど実現方式が複数考えられる
- 複数部門横断：業務要件が部門ごとに異なり、ベンダーの業種知見によって解が変わる
逆に、SaaS製品名がほぼ決まっている・案件規模1,000万円以下・既存ベンダーへの追加発注のようなケースは、RFIを省略して直接RFPに進んでも大きな問題は起きにくいです。
RFI・RFPの記載項目は何を書けばよいか？
結論から言うと、RFIは「聞きたいこと」を書き、RFPは「実現したいこと」を書くのが原則です。両者で書く内容の質が根本的に異なります。
RFIの標準記載項目
- 発注元の背景：業種・規模・現状システム・課題感の概要
- 検討中のテーマ：例）基幹システム刷新、AIエージェント導入、SaaS移行
- 知りたい情報：ベンダー実績・類似事例・技術アプローチ・概算費用レンジ・想定期間
- 回答フォーマット：自由記述 or 指定テンプレート
- 回答期限：2〜3週間
- 秘密保持の扱い：NDAの要否
RFPの標準記載項目
- プロジェクト概要と目的：ビジネスゴール・KGI/KPI
- 現状分析と課題：現行システム構成・業務フロー・データ構造
- 機能要件：必須機能・推奨機能・オプション機能を優先度付きで
- 非機能要件：性能・可用性・セキュリティ・拡張性
- 制約条件：予算上限・スケジュール・使用可能技術・既存資産
- 提案してほしい項目：システム構成・工程・体制・見積内訳・リスク
- 評価基準と配点：技術評価・価格評価・体制評価の比率を明示
- 契約条件：契約形態（請負/準委任）・検収条件・瑕疵対応
- スケジュール：質問受付期間・提案書提出期限・プレゼン日程・選定日
特に重要なのは「評価基準と配点の明示」です。技術60点・価格30点・体制10点のように配点を先に開示すると、ベンダー側も提案の力配分を最適化でき、結果として質の高い提案が集まります。
2026年に追加すべきAI関連項目
2025年までは考慮しなくてよかった項目が、2026年に必須化しています。生成AIやMCPサーバー連携が絡む案件では、MCPサーバーの導入判断を含めた以下の項目をRFPに明記することを推奨します。
- 使用するLLMとそのデータ保持ポリシー
- ハルシネーション対策と評価ハーネスの設計方針
- プロンプトインジェクション等のAIセキュリティ対策
- 従量課金（トークンコスト）のモデルと上限設定
AIコストの見積精度が低いまま契約すると、運用開始後に想定外の請求が発生するケースが増えています。AIコストの原価分解を踏まえた予算枠の設計が必須です。
RFI→RFPの使い分け判断フローはどう組むか？
結論から言うと、「案件規模・技術選定の成熟度・部門横断性」の3変数で判断するのが実務的です。雲海設計では以下のフローをクライアントに提示しています。
graph TD
A[プロジェクト起票] --> B{案件規模5000万円以上?}
B -->|Yes| C[RFI必須]
B -->|No| D{技術選定確定?}
D -->|No| C
D -->|Yes| E{複数部門横断?}
E -->|Yes| C
E -->|No| F[RFP直行可]
C --> G[RFI発行・2-3週間]
G --> H[回答分析・要件精緻化]
H --> I[RFP発行・4-8週間]
F --> I
I --> J[提案評価・選定]フェーズごとの所要期間の目安
| フェーズ | 期間 | 主なアウトプット |
|---|---|---|
| 企画・構想 | 1〜2ヶ月 | プロジェクト起票書・投資稟議骨子 |
| RFI | 2〜3週間 | 市場マップ・要件仮説・費用レンジ |
| 要件精緻化 | 1ヶ月 | 機能要件書・非機能要件書 |
| RFP | 4〜8週間 | ベンダー提案書・評価表 |
| 選定・契約 | 2〜4週間 | 選定結果・契約書 |
合計で4〜6ヶ月のリードタイムを見込むのが現実解です。「今期中に発注したい」と3ヶ月前から動き出すと、必ずRFIを飛ばすことになり失敗リスクが高まります。
RFI・RFPで発注側が陥りやすい落とし穴は？
「RFPを出せばベンダーが答えを持ってきてくれる」という発想が、ベンダー選定失敗の最大の原因である。──JUAS企業IT動向調査2026
この引用が示す通り、RFPは「発注側が意思決定に必要な情報を得るための道具」であって、要件を丸投げして解を待つものではありません。以下は雲海設計が現場で頻繁に見る5つの落とし穴です。
- 要件の抽象度が高すぎる：「業務を効率化したい」だけでは提案できない。せめて対象業務・現状KPI・目標KPIまで書く
- 評価基準の非公開：ベンダーが何に力を入れて提案すべきか分からず、玉石混交の提案が並ぶ
- 質問受付期間の設定なし：ベンダーは前提を推測で埋めるしかなく、提案の齟齬が生まれる
- プレゼン機会の非設定：書類だけでは体制の実態や技術力は見抜けない
- 既存ベンダーへの情報優位：新規ベンダーが同じ情報にアクセスできず、公正な競争にならない
特に契約形態（請負か準委任か）の判断は、後のトラブルに直結します。受託開発とSESの違いを踏まえて、案件特性に合った契約形態をRFPで指定することが重要です。また、コンサルとシステム開発を分ける従来型ではなく、一気通貫の支援体制を条件にすることで責任分界の曖昧さを回避できます。
2026年のRFP設計で追加すべき新論点は？
結論から言うと、「生成AI活用の明示」と「SaaS前提の再設計」の2点が2026年のRFPで必須になっています。
生成AI活用に関する記載
ベンダー側の開発プロセスに生成AIをどう組み込むかを明示させることで、生産性と品質のバランスが可視化されます。具体的には以下の項目をRFPで問います。
- コード生成・レビューにおけるAI利用の範囲と統制
- AI生成コードの検証プロセスと責任分界
- 成果物の著作権・秘密保持の扱い
- AIエージェント統合を含むアーキテクチャの提案
SaaS前提の設計思想
2026年時点で、スクラッチ開発を第一選択にする案件は例外的です。SaaS/PaaS/ローコードの組合せで7〜8割を賄い、差別化領域だけをスクラッチするのが主流のアーキテクチャです。RFPでも「スクラッチ前提の提案」ではなく「実現方式の選択根拠を含めた提案」を求めるべきです。
雲海設計のDXソリューションおよびITコンサルティングでは、RFI/RFP策定の伴走支援を提供しており、テンプレート提供から評価表の設計、ベンダー面談の同席まで一貫してサポートしています。
よくある質問
Q. 小規模案件でもRFI・RFPは必要ですか？
A. 500万円以下・既存ベンダー継続・SaaS製品名がほぼ確定しているケースなら、簡易な仕様書＋見積依頼で十分です。ただし1,000万円を超える場合は、簡易版でもRFPを整備することで契約トラブルの予防効果が大きくなります。
Q. RFIとRFPを1つの文書にまとめてもよいですか？
A. 推奨しません。目的とタイミングが異なるため、混在させるとベンダー側の回答粒度がぶれます。ただし要件成熟度が高い案件では「詳細RFI＋簡易RFP」のような統合型を採用することもあります。
Q. RFIに回答したベンダーは必ずRFPにも招待すべきですか？
A. 義務ではありません。RFIの回答内容と技術適合性を評価し、3〜5社に絞ってRFPを送るのが一般的です。ただしRFI段階で選外にする場合は、その理由を社内で言語化しておくとガバナンス上の説明責任を果たせます。
Q. RFPへの回答は無償が原則ですか？
A. 提案書作成費用は原則ベンダー負担ですが、案件規模が大きくPoC相当の作業を求める場合は「提案フィー（数十万円〜）」を支払うケースが増えています。優秀なベンダーほど無償提案の依頼を断る傾向があり、良い提案を得るための投資と捉える発注企業が増えています。
Q. AIベンダーへのRFPで特に注意すべき点は？
A. モデルのバージョンアップ耐性・トークンコストの上限・ハルシネーション対策・評価ハーネスの設計方針の4点は必ず問うべきです。従来のSIerと同じRFPテンプレートを使い回すと、AIプロジェクト特有のリスクが見落とされます。
まとめ｜RFI・RFPを使い分けて選定精度を上げる
RFPとRFIの違いは、目的・タイミング・記載項目・回答活用の4軸で明確に整理できます。「知るためのRFI」「選ぶためのRFP」という原則を守り、案件規模と成熟度に応じて2段階で運用することで、ベンダー選定の失敗確率は大きく下がります。2026年の新論点である生成AI・SaaS前提を織り込んだRFP設計は、これからの標準装備です。
雲海設計では、RFI/RFPの策定支援・ベンダー選定同席・契約レビューまで、発注企業側の立場に立った伴走支援を提供しています。「自社のRFPが妥当か第三者レビューしてほしい」「そもそも案件をRFI/RFPどちらから始めるべきか判断がつかない」といったご相談は、ぜひお問い合わせください。