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