データ分析システムをベンダーに外注する際、最終的な成否を分けるのは要件定義とRFP（提案依頼書）の精度です。要件が曖昧なまま発注すると、想定外の追加費用や運用フェーズでの破綻を招き、当初の投資判断そのものが揺らいでしまいます。とくに生成AIやRAGを組み込んだ近年のデータ分析システムでは、ベクトルDBのスケーリングやAPI従量課金といった「見えにくいコスト」が後から重くのしかかります。本記事では、ベンダー外注を前提に、RFPと要件定義書に書くべき項目・評価観点・隠れコストの把握方法を実務目線で整理します。
本記事はRFP・要件定義書・提案依頼書の「作り方」に特化した内容です。データ分析システムそのものの全体像や、システム選定の前提知識をまだ押さえていない場合は、先に データ分析システムの完全ガイド を読んでおくと、本記事で扱う要件定義の各項目がより立体的に理解できます。ここから先は、要件定義担当者・PM・情報システム部門の方が、ベンダーへ渡すドキュメントを実際に作成する場面を想定して解説します。
▼全体ガイドの記事
・データ分析システムの完全ガイド
データ分析システムのRFPに必ず含めるべき項目
RFP（提案依頼書）は、ベンダーに「何を作ってほしいのか」を伝え、複数社から比較可能な提案を引き出すための土台となる文書です。ここが曖昧だと、各社の提案が見積前提から食い違い、横並びの比較ができなくなります。データ分析システムのRFPに最低限含めるべき項目は、目的・対象データ・機能要件・非機能要件・運用保守・費用内訳・スケジュール・評価基準の8つです。以下では、それぞれを「ベンダーに何を書かせるか」という観点で整理します。
目的・対象データ・スコープを明文化する
RFPの冒頭では、システム導入の目的を「誰の・どの業務の・どの指標を改善するのか」というレベルまで具体化します。たとえば「営業部門の受注分析の工数を月40時間削減する」のように、定量的なゴールを示すことが重要です。目的が抽象的だと、ベンダーは過剰なスコープを提案しがちで、結果として見積が膨らみます。
次に、分析対象となるデータを明記します。データの種類（売上・顧客・ログなど）、保管場所、おおよそのレコード件数、更新頻度を示すと、ベンダーは現実的なアーキテクチャを設計できます。とくに生成AIやRAGを使う場合、対象となる社内文書の量と形式（PDF・Excel・Webなど）はコスト見積に直結します。
あわせて、対象スコープと「対象外」を明確に切り分けます。どこまでを今回の構築範囲とし、どこからを将来フェーズとするのかを書いておくと、ベンダー間の提案範囲がそろい、比較しやすくなります。スコープの境界を曖昧にしたまま発注すると、後工程で「それは別費用です」という認識のズレが生じやすくなります。
スケジュールと評価基準を提示する
RFPには、希望する全体スケジュールとマイルストーンを記載します。PoC（概念実証）から本番構築へ進める段階的な進め方を想定する場合は、その意図も明記しておきます。スケジュールを示すことで、ベンダーは体制やコストの前提を合わせやすくなり、現実離れした短納期提案を抑制できます。
評価基準は、提案を受け取る前にRFPへ明記しておくべき重要項目です。価格・技術力・実績・体制・サポートなどの観点と、それぞれの重み付けをあらかじめ示すことで、社内の選定プロセスが公平かつ説明可能になります。評価基準を後出しにすると、選定が属人的になり、後から「なぜこのベンダーなのか」を説明できなくなります。
提案フォーマットを指定することも有効です。費用内訳の粒度や、回答してほしい項目をテンプレート化して渡すと、各社の提案を同じ軸で並べられます。比較可能性を確保することが、RFPを発行する最大の目的のひとつです。
要件定義書に書く機能要件と非機能要件
要件定義書は、RFPで示した方向性をベンダーと合意したうえで、具体的な仕様へ落とし込むための文書です。ここでは機能要件と非機能要件を明確に分けて記述します。機能要件は「システムが何をするか」、非機能要件は「どの品質水準で動くか」を定めるもので、とくに非機能要件の精度がデータ分析システムの安定運用を左右します。両者を分けて整理することで、開発範囲の抜け漏れと、後工程での要件追加トラブルを防げます。
機能要件はデータ準備の役割分担まで踏み込む
機能要件では、データの取り込み・加工・分析・可視化・出力という一連の流れを、どの範囲までシステム化するかを定義します。データ連携先のシステムや、必要なダッシュボードの種類、ユーザーが行う操作を具体的に書き出すことが基本です。ここを曖昧にすると、開発後に「想定していた分析ができない」というギャップが生まれます。
とくに見落とされやすいのが、データ準備（クレンジング・整形・名寄せ）の役割分担です。RAG導入の成功フレームワークでは、データ準備に全工数の40〜60%を割くべきだとされており、これはPM（プロジェクトマネージャー）の鉄則とも言える経験則です。データ品質が低ければ、どれほど高度な分析エンジンを載せても期待した精度は得られません。
そのため要件定義の段階で、データ準備を「自社が担うのか、ベンダーが担うのか」を明確に切り分ける必要があります。前処理の範囲が曖昧なまま発注すると、ベンダーは最小限の前提で見積を出し、後から大規模なデータ整備が追加費用として発生します。データ準備の範囲と責任分界点を要件定義書に書き込むことが、コスト超過を防ぐ最大の防御策です。
RAG導入を5ステップで進める場合、データ準備・チャンク設計・ベクトル化・検索精度の評価・運用への移行という流れになります。要件定義書では、このうち自社とベンダーがどのステップを担当するのかを段階ごとに合意しておくと、進行中の認識ズレを最小化できます。
非機能要件は精度・セキュリティ・可用性を数値で示す
非機能要件では、精度・セキュリティ・可用性・性能を可能な限り数値で定義します。たとえば分析結果の精度に関する許容水準、応答時間、同時利用者数、稼働率（SLA）などです。生成AIを使う場合は、回答の正確性をどう評価するかという評価指標もここで合意しておく必要があります。
セキュリティ要件は、データ分析システムでとくに重要です。アクセス権限の管理、データの暗号化、ログの保全、外部APIへ送信するデータの取り扱いなどを明記します。社内の機密情報を外部の生成AIへ渡す構成になる場合、どのデータを送信し、どのデータを送信しないのかを要件として固める必要があります。
可用性については、障害時の復旧目標時間（RTO）や、データ消失の許容範囲（RPO）を示します。データ分析が日常業務に組み込まれるほど、停止時の影響は大きくなります。非機能要件を数値で固めておくことで、ベンダーの提案を品質面から客観的に比較でき、運用開始後の「期待外れ」を防げます。
費用内訳と隠れコストをRFPで可視化する
RFPで最も差がつくのが費用内訳の指定です。初期開発費だけを比較すると、運用フェーズで発生する費用が見えず、総額で割高なベンダーを選んでしまうことがあります。データ分析システムの予算を正しく組むには、まず費用相場の感覚を持ち、そのうえで隠れコストをベンダーに明示させる必要があります。
費用相場を予算欄の根拠にする
RFPに予算規模やレンジを示すかどうかは判断が分かれますが、少なくとも自社内で相場感を持っておくことは必須です。データ分析システムの構築費用は規模によって大きく異なります。小規模なPoC（概念実証）であれば50万〜200万円、期間は1〜2ヶ月が目安です。
中規模の本番構築になると、1,500万〜4,000万円、期間は3〜6ヶ月が一般的なレンジです。さらに全社展開や大規模なデータ基盤を伴う場合は、5,000万円以上に達することもあります。これらの相場を押さえておくと、提案された見積が妥当なのか、過剰または過少なのかを判断する基準になります。
まずは小規模なPoCで効果と技術的な実現性を検証し、その結果をもとに本番構築の予算を組むという段階的アプローチが、過剰投資を避けるうえで有効です。要件定義の段階で「どのフェーズに、どの程度の予算をかけるのか」を整理しておくことで、RFPの予算欄やスケジュールに一貫性を持たせられます。
運用保守費と従量課金を明記させる
初期開発費の比較だけでは見えないのが、運用フェーズの隠れコストです。代表的なものとして、ベクトルDBのスケーリング費用、外部AIサービスのAPI従量課金、そして運用保守費の3つが挙げられます。これらをRFPで明示的に回答させないと、提案時点では安く見えても、運用開始後に総コストが膨らみます。
運用保守費の目安は、初期開発費の15〜25%程度（構成によっては20〜30%）が一般的です。たとえば初期開発費が3,000万円であれば、年間で450万〜750万円程度の保守費が継続的に発生する計算になります。この継続費用を見落とすと、初年度以降の予算が破綻しかねません。
API従量課金は、利用量に比例して増えるため、想定利用量に対する月額の試算をベンダーへ求めることが重要です。ベクトルDBもデータ量や検索回数が増えるとスケーリング費用が上がります。RFPでは「想定利用規模における月次のランニングコスト試算」を必須回答項目として指定すると、各社の総額比較が可能になります。
費用内訳は、初期費用・ライセンス費・インフラ費・運用保守費・従量課金を分けて記載させるのが基本です。これにより、どの費目が総コストを押し上げているのかが一目でわかります。隠れコストを表に出させることこそ、RFPによる費用可視化の本質です。
調達ガイドラインを活用した評価観点の作り方
ベンダーの提案を評価する観点を自前でゼロから作るのは負担が大きく、抜け漏れも生じやすいものです。そこで有効なのが、官公庁の調達ガイドラインを民間のRFPへ転用するアプローチです。デジタル庁が公開する調達関連のチェックシートには、AIを扱うシステムの評価観点が体系的に整理されており、これを自社の評価基準のたたき台として活用できます。
デジタル庁の調達チェックシートを転用する
デジタル庁は、政府情報システムの調達にあたって参照すべきチェックシートやガイドラインを整備しています。これらは公共調達向けですが、AIガバナンスやセキュリティの評価観点は、民間のデータ分析システム調達にも十分応用できます（出典：デジタル庁）。公的に整理された観点を取り入れることで、自社のRFP評価基準の網羅性を一段引き上げられます。
具体的な評価観点としては、AIガバナンスの構築状況、セキュリティインシデント発生時の対応体制、そして生成AIにおけるプロンプトの隠蔽回避（プロンプトインジェクション等への対策）が挙げられます。これらをRFPの評価項目に組み込むことで、ベンダーがどこまでリスクに備えているかを比較できます。
あわせて重視したいのが透明性要件です。AIがどのようなデータをもとに、どのようなロジックで結果を出しているのかを説明できるかどうかは、社内での意思決定にAIの出力を用いる際の信頼性に直結します。調達ガイドラインを起点に評価観点を組むことで、技術力や価格だけに偏らない、バランスの取れた選定が可能になります。
セキュリティ要件を評価基準に落とし込む
セキュリティ要件は、要件定義書に記述するだけでなく、RFPの評価基準としても明確に位置づけます。データの取り扱い範囲、アクセス制御の仕組み、外部サービスへ送信する情報の管理方針などを評価項目として設定し、各ベンダーの回答を点数化します。これにより、セキュリティを軽視した提案を選定段階で見抜けます。
とくに生成AIを組み込む構成では、社内データが外部のAIサービスに渡る経路が生じます。どのデータをどこへ送るのか、送信されたデータが学習に使われないかといった点を、契約・要件の両面で確認する必要があります。これらを評価基準に組み込むことで、後から発覚するセキュリティ上の問題を未然に防げます。
インシデント対応体制も評価対象に含めます。障害や情報漏えいが発生した際の連絡フロー、対応時間、責任範囲を提案段階で確認しておくと、運用フェーズでの安心感が大きく変わります。要件定義とRFPの評価基準を連動させることが、セキュリティ要件を「絵に描いた餅」にしないための鍵です。
まとめ
本記事では、データ分析システムをベンダーへ外注する際のRFP・要件定義書・提案依頼書の作り方を解説しました。RFPには目的・対象データ・機能要件・非機能要件・運用保守・費用内訳・スケジュール・評価基準の8項目を含め、各社が比較可能な提案を出せる土台を整えることが重要です。要件定義書では機能要件と非機能要件を分け、とくにデータ準備の役割分担と、精度・セキュリティ・可用性の数値化に踏み込む必要があります。費用面では、小規模PoCの50万〜200万円から大規模展開の5,000万円以上までの相場を踏まえ、運用保守費（初期開発費の15〜25%）やAPI従量課金といった隠れコストをRFPで可視化させることが、総コストでの正しい比較につながります。
そして評価観点は、デジタル庁の調達チェックシートに代表される公的な調達ガイドラインを起点にすると、AIガバナンス・セキュリティインシデント対応・透明性要件まで網羅した網羅性の高い基準を効率的に組めます。RFPと要件定義書、そして評価基準を一貫した思想でつなぐことが、見落としがちな隠れコストとセキュリティリスクの両方を抑え、データ分析システム導入を成功へ導く最短ルートです。発注前のドキュメント整備に時間をかけることが、結果として開発・運用フェーズの手戻りと追加費用を最小化します。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。