データ基盤構築のRFP（提案依頼書）の書き方と項目サンプル

データ基盤構築のRFP（提案依頼書）の書き方を、発注現場の実例で解説します。A社は「まずデータレイクから」、B社は「BIツールだけ入れましょう」、C社は「500万円で」「1,800万円で」。3社にお願いしたら、返ってきた提案の中身も金額もバラバラ。RFPの相談は、こういう状況でご連絡をいただきます。

正直に言うと、これは各社が悪いというより、そもそも渡した条件がそろっていないことに原因があります。同じ土俵に提案を並べるために使う道具、それがRFP（提案依頼書：Request for Proposal）です。

2026年に入ってから、生成AIやRAG（社内文書検索）を前提にしたデータ基盤の相談が増えています。従来のシステム開発RFPのテンプレをそのまま使うと、非構造化データの扱い、ベクトルDBの要否、LLMにデータを渡すときの権限制御といった項目が抜け落ちます。データ基盤特有の項目に加えて、AI活用を見据えた記述例も本記事に盛り込んでいます。

生成AIやRAGを見据えた要件整理は生成AIに使えるデータを整える：AI-Readyデータの考え方が、費用の相場観がまだない方はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説が参考になります。発注タイプで迷っている方はデータ基盤構築の会社の選び方・比較｜失敗しない発注先、内製と外注の分岐はデータ基盤の内製と外注はどっち？判断基準と現実解もあわせてどうぞ。

丸投げRFPはなぜ失敗するのか

「口頭で要望を伝えれば、ベンダーが見積もってくれるのでは」と思うかもしれません。実際、それでも見積もりは出てきます。問題は、その見積もりを横並びで比較できないことです。

A社には「広告データを見たい」、B社には「売上も見たい」と、伝えた内容が少しずつ違えば、各社は別々の前提で提案します。スコープが違う見積もりを金額だけで比べても、安いほうが本当に得かは分かりません。データ基盤の提案依頼書サンプルを1枚そろえて全社に同じものを渡すと、次の効果があります（後述の目次サンプルをそのまま流用できます）。

• 提案を同じ前提で比較できる：スコープと要件がそろうので、価格と内容を公平に評価できる
• 認識のズレを早い段階で潰せる：発注側の意図が文書で伝わり、「思っていたものと違う」を防げる
• 社内の合意形成に使える：目的と予算が明文化され、稟議や上申が通しやすくなる

逆に、RFPを作らずベンダー任せにすると、発注側が受け身になり、後から要件の認識違いでトラブルになりがちです。

1社に絞って発注する場合でも、RFPを作る価値はあります。要件を書き出す過程で、自社の目的とデータの現状が整理されるからです。

RFP・RFI・要件定義書の違い

RFPの話をすると、RFIや要件定義書との違いが分かりにくい、とよく聞かれます。図のように、これらは使うタイミングが違います。

• RFI（情報提供依頼書）：ベンダーを絞り込む前に、各社の実績やサービス概要を集める文書。候補を広く洗い出す段階で使います
• RFP（提案依頼書）：絞り込んだ候補に要件を示し、具体的な提案と見積もりを求める文書。本記事の主役です
• RFQ（見積依頼書）：提案を踏まえ、金額面を詰める文書。RFPと一体で運用することも多いです

一般的には、RFI → RFP → RFQ の順に進みます。候補が最初から数社に絞れているなら、RFIを省いてRFPから始めても構いません。

要件定義書とも混同されがちですが、こちらは発注先が決まった後に、システムの仕様を詳細に固める成果物です。RFPが「何を実現したいか」を扱うのに対し、要件定義書は「どう作るか」を扱います。順番としては、RFPのほうが先です。

RFIサンプル質問リスト（10問）

候補ベンダーがまだ絞れていない段階なら、いきなりRFPを出す前にRFIで実績とサービス概要を集めます。データ基盤に特化したRFIで聞いておくと差がつく質問を、そのまま貼れる形で挙げます。

【会社・実績】
1. 過去3年間で構築したデータ基盤の事例を3件（業界・データ量・使用ツール）教えてください
2. 弊社と同業種・同規模の構築実績はありますか
3. データ基盤の運用保守を継続提供しているクライアント数を教えてください

【技術・ツール】
4. 得意なDWH（BigQuery / Snowflake / Redshift / Databricks）はどれですか
5. ELT/ETLはどのツールを標準にしていますか（TROCCO / Fivetran / Airbyte / 自社開発 等）
6. BIツールの導入・運用支援実績（Looker / Tableau / Power BI / Metabase）を教えてください
7. 生成AI・RAG・データカタログ・MCPの案件経験はありますか

【体制・進め方】
8. 想定するプロジェクト体制（PM/エンジニア/データアナリストの人数と稼働率）を教えてください
9. PoC・スモールスタートに対応可能ですか。標準的な期間と金額感を教えてください
10. 稼働後の運用保守メニューと月額レンジを教えてください

10問前後に絞ると回答率が上がります。RFIの回答をもとに3〜5社に絞ったうえで、本命の候補にRFPを配るのが現実的な流れです。

RFPに書くべき項目の全体像

RFPに決まった様式はありませんが、データ基盤構築では図のように3つのブロックで組み立てると、漏れなく整理できます。

ブロック1：プロジェクト概要（なぜやるか）

ベンダーが提案の方向性を決めるための、土台になる情報です。

• 背景・現状の課題：いま何に困っているか（例：部署ごとに数字がバラバラで集計に毎月40時間かかっている）
• 目的・達成したい状態：データ基盤で実現したいこと（例：経営会議の数字を翌営業日に見られる状態にしたい）
• 対象業務・利用部門：誰がどう使うのか
• 予算とスケジュール：おおよその予算レンジと、いつまでに動かしたいか（規模別・工程別の期間の目安を踏まえて現実的な希望時期を示すと、提案がぶれません）

ブロック2：提案依頼内容（何を作るか）

提案と見積もりの精度を左右する、RFPの中心です。データ基盤特有の項目が多いため、次のセクションで詳しく扱います。

ブロック3：選定の進め方（どう選ぶか）

意外と抜けやすいのが、このブロックです。評価基準と配点を先に明記すると、提案を公平に比較でき、社内での選定理由も説明しやすくなります。提案の提出方法・様式、選定スケジュール、想定する契約形態（請負か準委任か）もここに書きます。

データ基盤のRFPで特に重要な項目

一般的なシステム開発のRFPと、データ基盤構築のRFPの一番の違いは、「データそのもの」の情報をどれだけ具体的に書けるかです。ここが薄いと、提案も見積もりも精度が出ません。最低限おさえたい項目を挙げます。

対象データソースの一覧

どのシステムのデータを扱うのかを、表で具体的に示します。これがRFPの肝です。

Evastの現場でも、RFP段階でデータ量と更新頻度が書かれていない案件では、見積もりが提案社ごとに2〜3倍ぶれました。ソースの実態（APIがあるか、権限を取れるか）が分かってはじめて、ベンダーは現実的な工数を出せます。

記入例：5システムをそのまま埋めた表

雛形だけだと手が止まるので、実案件でよくある構成を仮の数字で埋めたサンプルを載せます。RFPにはこの粒度まで埋めて渡すと、提案が具体的になります。

このサンプルを自社のシステムに置き換えるだけで、提案精度が上がります。特に「権限・注意点」列は見落とされがちですが、ベンダーの工数見積もりに直結します。

非機能要件

機能要件（何ができるか）だけでなく、性能や運用などの非機能要件も書きます。何を書けばいいか迷ったら、IPA（情報処理推進機構）が公開している非機能要求グレードの6分類が参考になります。

• 可用性：止まると困る時間帯、許容できる停止時間
• 性能・拡張性：ダッシュボードの表示速度、将来のデータ量増加
• 運用・保守性：監視や障害対応を誰がやるか
• 移行性：既存のデータやレポートをどう引き継ぐか
• セキュリティ：個人情報の扱い、アクセス権限、監査ログ
• システム環境：オンプレかクラウドか、利用ブラウザなど

ツールの希望・既存資産

すでに使っているDWHやBIツール、クラウド環境があれば明記します。「BigQueryを使っている」「Tableauの資産を活かしたい」といった制約は、提案の前提を大きく変えます。ツール選定をゼロから相談したい場合は、その旨を書けば各社が選定理由ごと提案してくれます。ツール選びの観点はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較で扱っています。

PoC・スモールスタートの可否

いきなり全社展開ではなく、まず一部で試したいなら、PoC（試験導入）やスモールスタートを許容する旨を書いておきます。段階的な進め方を前提にすると、初期費用を抑えた現実的な提案が集まりやすくなります。PoCの進め方や成功基準の決め方はデータ基盤のPoCの進め方｜5ステップと成功基準・費用の目安で扱っています。

AI活用時代のRFPに追記すべき項目（2026年版）

「作ったデータ基盤を、社内の生成AIやRAG（社内文書検索）に繋げたい」という要件が、2026年に入ってから急激に増えています。従来のシステム開発RFPテンプレのままだと、以下の項目がまるごと抜け落ちるので、データ基盤RFPの3-3〜3-5あたりに追記しておきます。

非構造化データの取り扱い

生成AIやRAGで検索対象にする非構造化データ（議事録、契約書PDF、Slackログ、Notion、Confluence）を、どこまでデータ基盤の対象にするかを明記します。書く例。

• 対象：Google Drive上のPDF約1.2万件、Slack過去2年分のログ、Notion社内Wiki全ページ
• 除外：役員メールボックス、人事DBの個人情報カラム
• 前処理：PDFのOCR要否、機密ラベル自動付与の要否

対象範囲を切らないと、ベンダー側は「全部やる前提」で見積もり、金額が跳ね上がります。詳しくは別記事のAI-Readyデータの考え方で扱っています。

ベクトルDBとRAG基盤の要否

RAGを組む場合、ベクトルDB（Pinecone、Weaviate、pgvector、AlloyDB等）を新設するか、既存のDWHで完結させるかで構成が大きく変わります。RFPには次の観点を書いておきます。

• ベクトルDBは新規導入 or 既存資産活用（BigQuery Vector Search等でもOKか）
• 想定チャンク数・埋め込みモデル（OpenAI text-embedding-3 系／Cohere／自社ホスト）
• 検索精度の合格基準（Recall@10 = 80%以上、等）

エンタープライズRAGの設計論はRAGのエンタープライズ活用：社内データ検索の設計と落とし穴で扱っています。

データカタログ・メタデータ管理

生成AIに「どのテーブルの何のカラムを見ればいいか」を教えるためのメタデータ管理は、2026年のデータ基盤RFPの必須項目になりつつあります。

• カタログツール（DataHub / OpenMetadata / Dataplex / Alation 等）の指定または選定依頼
• カラム単位の説明・オーナー・PII フラグの記述ルール
• 生成AIエージェントからカタログをどう参照させるか

カタログの選び方の基礎は別記事のデータカタログとは？導入メリットと主要ツール比較で解説しています。

MCP / 生成AIワークフロー連携

Model Context Protocol（MCP）などを使って、社内の生成AIエージェントからデータ基盤に直接アクセスさせる構成が広がっています。RFPには「MCPサーバー構築の要否」「LLMからのクエリ権限制御」「監査ログ要件」を書いておきます。MCPとデータ基盤の関係は別記事のMCPで社内データ基盤に生成AIから安全に繋ぐで扱っています。

LLMアクセス時の権限制御・監査ログ

これが一番抜けやすい項目です。LLMが社内データをまたいで検索するとき、利用者ごとに閲覧できるレコード範囲を絞る必要があります。

• 行レベルセキュリティ（Row-Level Security）の実装要否
• 個人情報カラムのマスキング・匿名化ルール
• LLMが実行したクエリ・返答の監査ログ保持期間（90日／1年／3年）

LLMだからOKではありません。通常のBIツールと同等以上の権限管理が必要です。

そのまま使えるRFPの目次サンプル

ここまでの項目を、章立てに落とすと次のようになります。Wordやスプレッドシートにこの見出しをそのまま並べ、各章を埋めていけば、データ基盤構築のRFPの骨格ができます。

1. はじめに
   1-1. 提案依頼の背景・現状の課題
   1-2. プロジェクトの目的・達成したい状態
   1-3. 対象業務・利用部門

2. プロジェクト概要
   2-1. スコープ（対象範囲・対象外）
   2-2. 想定予算レンジ
   2-3. スケジュール（提案・選定・構築・稼働）

3. 提案依頼内容
   3-1. 対象データソース一覧（システム名・データ量・更新頻度・連携方法）
   3-2. 機能要件
   3-3. 非機能要件（可用性・性能・運用保守・移行・セキュリティ）
   3-4. 既存資産・利用中のツール／制約
   3-5. PoC・スモールスタートの可否
   3-6. 生成AI/RAG連携要件（非構造化データ・ベクトルDB・データカタログ・MCP・権限制御）
   3-7. 成果物・体制・運用保守の範囲

4. 選定について
   4-1. 評価基準と配点
   4-2. TCO（3〜5年）評価の内訳と配点
   4-3. 契約形態（請負／準委任）の想定・フェーズ別の契約分割
   4-4. 質疑応答の窓口・締切

5. 提出要領
   5-1. 提出期限・様式・宛先
   5-2. 提案プレゼンの有無

すべての項目を完璧に埋める必要はありません。特に 3-1の対象データソース一覧と 4-1の評価基準の2つが埋まっていれば、提案の質は大きく変わります。逆にこの2つが空欄だと、どれだけ他を作り込んでも提案の前提がぶれます。

このテンプレートを Word / Google スプレッドシート版でお渡しできます。対象データソース棚卸し表とTCO評価配点表がプリセットされているので、そのまま社内展開に使えます。

→ RFPテンプレートを受け取る（無料相談）

ベンダー選定の評価基準をRFPに書く

提案を集めてから「さて、どう選ぼう」では遅すぎます。評価基準は、RFPを出す前に決めておくのが鉄則です。基準を先に決めておくと、各社に同じ観点を伝えられ、選定後に社内へ理由を説明するときにも役立ちます。

データ基盤構築でよく使う評価軸は次のとおりです。

• 実績：同業種・同規模のデータ基盤構築の経験があるか
• 技術・提案内容：要件に対する構成が妥当か、過剰でも不足でもないか
• 運用・保守体制：作った後の伴走体制があるか
• コスト・TCO：初期費だけでなく、3〜5年の総額で見て妥当か
• コミュニケーション：非エンジニアにも分かる言葉で説明してくれるか

それぞれに配点をつけ、価格点と技術点のバランスを決めておきます。配点の例を挙げます。

配点に正解はありませんが、価格だけで決めると安かろう悪かろうの提案を選びがちなので、技術点の比重を価格点と同等以上に置いておくのが定石です。見積もりの読み解き方はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説でも詳しく解説しています。

契約形態（請負と準委任）の違い

評価基準とあわせて決めておきたいのが、契約形態です。データ基盤構築では主に2つあります。

• 請負契約：成果物の完成に責任を負う契約。要件がきっちり固まった構築フェーズに向きます
• 準委任契約：作業や稼働に対して支払う契約。要件が動きやすいPoCや、運用しながら改善する伴走フェーズに向きます

データ基盤は、作りながら要件が見えてくる場面が多いため、PoCや初期は準委任、要件が固まった本構築は請負、とフェーズで使い分けるのが現実的です。どちらを想定しているかをRFPに書いておくと、提案の前提がそろいます。

フェーズ別の契約分割サンプル（PoC=準委任／本構築=請負）

フェーズごとに契約を分けるとしても、金額の切り分けが曖昧だと社内稟議が通りません。中規模（対象データソース5〜8、初年度予算1,500万〜2,500万）を想定した、契約分割のイメージを載せます。

このようにフェーズごとに契約を切ると、Phase 1のPoCで見えた実データを踏まえて Phase 2 の請負金額を再見積もりでき、双方のリスクが下がります。RFPには「PoC後に本構築の再見積もりを実施する前提で提案してほしい」と明記しておきましょう。

TCO評価の内訳サンプル（3〜5年）

「初期費だけ安いけど、月額運用が高くて5年で見たら一番高い」というのが、データ基盤で一番ありがちな失敗です。RFPでTCO（Total Cost of Ownership、3〜5年の総所有コスト）を評価軸に組み込むなら、内訳ごとに配点しないと各社の見積もり形式がバラバラで比較になりません。

配点ワークシートの例を挙げます（TCO評価軸に25点を割り振る場合）。

3年総額と5年総額の両方を出させると、初期に安く見せて後で回収するタイプの見積もりを見抜けます。TCOを下げる勘所はデータ基盤の運用コスト削減：5つの見直しポイント、初期費の妥当性判断はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説、ELTツールの料金比較はデータ連携ツールの料金プランを比較を参照してください。

【業界別】データ基盤RFPサンプルの差分（自治体・EC・製造・SaaS）

業界によって、RFPで強調すべき項目が変わります。ここが薄いと、他業界のテンプレを流用しただけの提案が集まってしまいます。

自治体や公立病院のRFPは公開されているケースが多く、非機能要件・監査要件・提出書式のフォーマットは民間案件でも十分に参考になります。「◯◯市 データ連携基盤 RFP」で検索すると実物のPDFが出てきます。

やりがちな失敗：丸投げRFPを避ける

RFPでつまずく原因は、両極端のどちらかに寄ることです。図のように、目的が曖昧な「丸投げRFP」と、手段まで縛りすぎたRFPは、どちらも良い提案を遠ざけます。

ありがちな失敗を、具体的に挙げます。

• 目的が「いい感じのデータ基盤」レベルで曖昧：ベンダーが何を提案すればいいか判断できず、各社の方向性が散ってしまう
• 対象データやデータ量を書かない：見積もりの前提が立たず、提案が当てずっぽうになる
• 評価基準がない：提案が集まってから迷走し、結局「なんとなく安いところ」を選んでしまう
• 手段まで固めすぎる：使うツールや設計方法まで指定し、より良いモダンな構成の提案を自ら閉ざす

避け方はシンプルです。What（何を実現したいか）と制約（既存資産・予算・セキュリティ）は具体的に、How（どう作るか）はベンダーに委ねる。この線引きができると、各社の知恵を引き出しつつ、同じ土俵で比較できるRFPになります。RFPの作り込み以外にも発注前に確認すべき落とし穴は別記事のデータ基盤構築でよくある失敗と発注前チェックリストで扱っています。

RFP作成の進め方

失敗パターンを踏まえて、RFPを作る現実的なステップを順に挙げます。規模にもよりますが、棚卸しから完成まで2〜4週間ほどを見ておくと無理がありません。

1. 目的を1〜2行で言語化する：「何の業務の、どの判断を、データで速くしたいか」を先に決めます
2. 対象データを棚卸しする：どこに・どんなデータが・どれだけあるかを洗い出します。ここが一番時間のかかる工程です
3. 要件を What と制約に整理する：手段は決めず、実現したい状態と外せない条件を書きます
4. 評価基準と配点を決める：選定の観点を先に固めます
5. 候補ベンダーに配布し、質疑の窓口を用意する：配布先は3〜5社が現実的です。多すぎると評価の工数が膨らみ、各社の提案も雑になりがちです

質疑応答は、運用ルールを決めておくと公平に進められます。おすすめは次の運用です。

• 質問はメール個別ではなく、共通フォーム（Googleフォーム／専用メールボックス）で一元受付
• 回答はスプレッドシート1枚にまとめ、全社にPDFで週次配信（例：毎週金曜17時締切、翌月曜正午配信）
• 特定1社の固有事情は個別回答、要件解釈に関わる質問は必ず全社共有
• 口頭説明会を開くなら録画し、参加できなかった社にも配布

一部の社だけが有利な情報を持つと提案の前提が食い違い、後で「聞いてない」の押し問答になります。

要件の棚卸しや評価基準づくりは、社内だけだと手が止まりがちな工程です。私たちEvastも、ツール選定やデータ基盤の提案依頼書サンプル作成の前段となる現状整理から相談を受けることが少なくありません。データ活用の戦略立案から伴走するデータ戦略策定サービスのような形で、第三者の視点を入れる選択肢もあります。

まとめ：RFPは「提案をそろえる物差し」

データ基盤構築のRFPについて、要点を整理します。

• RFPの役割は、複数社の提案を同じ前提でそろえ、比較できるようにする物差し
• 構成は「プロジェクト概要・提案依頼内容・選定の進め方」の3ブロック
• データ基盤特有の肝は、対象データソースの一覧（量・更新頻度・連携方法）と非機能要件
• 評価基準は、RFPを出す前に決めておく
• What と制約は具体的に、How はベンダーに委ねる

RFPは、立派な分厚い文書を作ることが目的ではありません。自社が何を実現したいかを言葉にし、それを各社に同じ形で伝えられれば、役割は果たせます。まずは目的の1行と、データの棚卸しから手をつけてみてください。

データ基盤RFPテンプレート（Word/スプレッドシート）を無料でダウンロード

株式会社Evastでは、本記事の目次サンプルをベースにしたデータ基盤構築RFPテンプレート（Word / Google スプレッドシート版）を、無料相談の面談時にお渡ししています。

同梱内容：

• 章立て済みのRFP本文テンプレ（Word）
• 対象データソース棚卸し表（本記事の記入例5行を含むスプレッドシート）
• TCO 3〜5年評価配点ワークシート（記入例あり）
• RFIサンプル質問リスト10問
• 生成AI/RAG連携要件の追記テンプレ（2026年版）

「RFPを作りたいが、何を書けばいいか分からない」「集まった提案が妥当か、第三者の視点で見てほしい」「要件整理の段階から相談に乗ってほしい」といったフェーズから、お気軽にご相談ください。

→ データ活用の無料診断を受ける（3分） → データ基盤 提案依頼書 サンプルを無料でもらう（無料相談） → データ基盤構築サービスを見る → データ戦略策定サービスを見る