RAG構築のRFP/要件定義書/提案依頼書について

RAG（検索拡張生成）の構築をAIベンダーに外注する際、プロジェクトの成否を大きく左右するのが、RFP（提案依頼書）と要件定義書の精度です。「社内文書を読み込んで質問に答えるシステムが欲しい」といった漠然とした依頼のまま発注すると、各社の見積もりがばらつき、比較が成り立たなくなります。さらに、契約後に「想定していた精度が出ない」「運用費が当初想定の何倍にも膨らんだ」といったトラブルが頻発します。とくにRAGは、初期の開発費だけでなく、ベクトルデータベースのスケーリング費用や生成AIのAPI従量課金といった「隠れコスト」が見えにくく、要件定義の段階でこれらを織り込めるかどうかが、予算管理の成否を分けます。

本記事では、RAG構築のRFP・要件定義書・提案依頼書について、費用相場と隠れコストの把握から、精度評価指標の合意、セキュリティ要件の盛り込み方、そして外注先を見極める評価チェックリストまでを、発注実務で使える観点とともに解説します。要件定義の前提としてRAGの全体像を把握しておきたい方は、あわせてRAG構築の完全ガイドもご覧ください。本記事は、その完全ガイドの内容を発注実務に落とし込み、RFPに具体的に何をどう書くべきかを掘り下げる内容です。

▼全体ガイドの記事
・RAG構築の完全ガイド

RAG構築の費用相場と見落としがちな隠れコストの把握

RFPを作成する前に、まずRAG構築の費用相場の感覚を持っておくことが重要です。相場観がないままベンダーの見積もりを受け取っても、その金額が妥当かどうかを判断できません。RAGの構築費は、規模やアプローチによって大きく変動します。相場を知らずに発注すると、過剰な金額を支払ったり、逆に安さだけで品質の低いベンダーを選んでしまったりするリスクがあります。ここでは、要件定義の前提となる費用相場と、見落とされがちな隠れコストを整理します。

RAG構築の開発費は、目指すフェーズによって相場が大きく異なります。小規模なPoC（概念実証）であれば、50万〜200万円程度が目安です。中規模の本番構築になると、1,500万〜4,000万円程度が一般的とされています。大規模な全社展開では、5,000万円以上に達することもあります。RFPには、自社がどのフェーズを目指すのかを必ず明記してください。「まずPoCで効果を検証したい」のか「最初から本番運用を見据えた構築をしたい」のかで、必要な予算もスコープも大きく変わります。

フェーズを曖昧にしたまま発注すると、ベンダーごとに想定するスコープがずれ、見積もりの比較そのものが成立しなくなります。あるベンダーはPoC前提で安く見積もり、別のベンダーは本番構築前提で高く見積もるといった具合に、同じ依頼書でも前提が異なれば金額は何倍も開きます。目指すフェーズと到達目標をRFPで明確に示すことが、各社から適切で比較可能な見積もりを引き出す第一歩です。

実務上は、いきなり中規模の本番構築に踏み込むのではなく、まずPoCで小さく検証してから本番に進む段階的なアプローチが推奨されます。PoCの段階で精度が業務に耐えるかを見極め、効果を数字で確認してから本格投資に移れば、大きな失敗を避けられます。RFPには「PoCの結果を踏まえて本番フェーズへの移行可否を判断する」という段階的な進め方を盛り込み、各フェーズの費用を分けて見積もってもらうと、リスクを抑えた発注ができます。フェーズを分けることは、予算の上振れを防ぐ安全弁にもなります。

RAGの予算管理で最も注意すべきは、初期開発費以外に発生する隠れコストです。代表的なものが運用保守費で、これは初期開発費の15〜25%程度（試算の前提によっては20〜30%とされる場合もあります）が年間で継続的に発生するのが一般的な目安です。要件定義の段階でこの保守費を見込んでおかないと、運用開始後に予算超過に陥ります。RFPでは、初期費用とは別に、年間の運用保守費を明示してもらうことが欠かせません。

RAG特有の隠れコストとして、利用量に応じて変動する次のような費用があります。
・生成AIのAPI利用にかかる従量課金（質問数やトークン量が増えるほど膨らむ）
・ベクトルデータベースのデータ増加に伴うスケーリング費用
・文書量や利用者の増加に対応するためのインフラ増強費

これらは利用が拡大するほど膨らむため、RFPでは「想定利用量における月額ランニングコストの試算」と「その内訳の開示」をベンダーに求めることが重要です。初期費用だけで比較すると、運用フェーズで総額が逆転するケースもあります。

とくにベクトルデータベースのスケーリング費用は、文書量が増えるほど段階的に上がっていくため、見積もり時点では小さく見えても、運用が軌道に乗るほど重くのしかかります。RFPには「文書量が当初の2倍、5倍に増えた場合のコスト試算」といった条件を付して見積もりを依頼すると、将来の総保有コスト（TCO）を見通せます。隠れコストの内訳開示を発注条件に組み込むことが、見えない出費に足をすくわれないための実践的な対策です。

要件定義書とRFPに盛り込むべき項目

RAGの要件定義書とRFPには、最低限おさえておくべき定番の項目があります。具体的には、目的と対象データの範囲、精度・評価指標の合意、セキュリティ要件、運用保守の範囲とSLA、そして隠れコストの内訳開示要求です。これらを漏れなく盛り込むことで、ベンダーは工数を正確に見積もれ、発注者は各社を同じ土俵で比較できます。ここでは、とくに見落とされがちな「データ範囲の定義」と「精度評価指標の合意」を中心に整理します。

RAGの要件定義でまず固めるべきは、システムの目的と、AIに読み込ませる対象データの範囲です。参照する社内文書の種類と量、対応すべき質問の範囲、有人対応への引き継ぎの要否、連携が必要な外部システムなどを明確にします。とくに「どの文書を読み込ませるか」は精度に直結するため、対象文書の一覧と形式（PDF・Excel・社内Wikiなど）を要件定義書に明記しておくと、ベンダーが工数を正確に見積もれます。手書きのスキャンや複雑な表が混在している場合は、その旨を伝えておかないと、後から工数が膨らむ原因になります。

RAGの成功フレームワークとして、導入を5つのステップで整理する考え方があります。一般に、データ準備・チャンキング設計・検索方式の選定・生成の制御・評価という流れで構成され、それぞれに要件を定義していきます。要件定義書では、各ステップで何をどこまで作るのかを明文化しておくと、スコープの抜け漏れを防げます。とくにデータ準備の工程をどこまでベンダーに任せるのか、社内で対応するのかを切り分けておくことが、後の費用とスケジュールの予測精度を高めます。

このデータ準備の工程は、RAGプロジェクト全体の工数の40〜60%を占めるとも言われるほど重要です。文書の整形、ノイズの除去、適切なチャンク（分割単位）の設計といった地道な作業が、最終的な回答精度を大きく左右します。ここを軽視した要件定義は、精度不足という形で必ず跳ね返ってきます。RFPには「データ準備の工程に十分な工数を割く前提で見積もる」ことを明記し、安易にこの工程を省略しようとするベンダーを見極める材料としてください。データ準備に手を抜かないことは、RAG構築のPM鉄則です。

RAGの要件定義で最も合意がずれやすいのが、回答精度の評価基準です。「精度が高いこと」といった曖昧な表現ではなく、測定可能な指標を発注時に合意しておく必要があります。たとえばRagasのような評価フレームワークでは、検索した文書の的確さを示すContext Precision（検索精度）や、回答が文書に忠実かを示すFaithfulness（忠実性）といった指標が定義されています。RFPに「Ragas等の評価フレームワークを用いて精度を客観的に検証する」ことを盛り込めば、精度を数値で語る体制を発注時から組み込めます。

精度の評価基準とあわせて重要なのが、検収（受け入れ判定）の基準を発注時に合意しておくことです。「どの水準に達したら完成とみなすか」をRFPの段階で定めておかないと、納品時に評価が主観的になり、トラブルの火種となります。たとえば「代表的な質問100件に対して、正答率が一定以上であること」「Faithfulnessが定めた閾値を上回ること」といった具体的な検収条件を設けておけば、ベンダーと発注者の認識のずれを防げます。測定方法と判定基準をセットで定義することが、円滑な検収につながります。

あわせて、運用保守の範囲とSLA（サービス品質保証）も要件定義書に明記します。応答速度の目標値、システムの稼働率、障害発生時の対応時間、文書更新時の再学習の頻度と範囲などを定めておくと、運用フェーズの責任分界点が明確になります。精度・評価指標・検収基準・SLAの4点をRFPで具体的に定義することが、「作ってみたが使えない」という最悪の結末を避けるための要になります。曖昧な合意のまま進めると、契約上の根拠を持って改善を求めることができなくなります。

セキュリティ・ガバナンス要件の盛り込み方

RAGは社内の機密情報を参照するため、セキュリティとガバナンスの要件を要件定義書に明確に盛り込む必要があります。ここで参考になるのが、デジタル庁が公開している調達向けのチェックシートの観点です。官公庁向けに整備された評価項目は、民間企業のRFPにも応用でき、見落としがちなリスクを網羅的に押さえられます。社内に専門知識が乏しくても、公的な枠組みを下敷きにすることで、要件の抜け漏れを大幅に減らせます。

デジタル庁の調達チェックシートでは、AIガバナンスの構築、セキュリティインシデントへの対応体制、システムの透明性の確保といった観点が示されています（出典：デジタル庁）。これらは行政向けに作られたものですが、その本質は「AIを安全かつ責任を持って運用できるか」を問うものであり、民間企業の発注にもそのまま当てはまります。RAGのRFPにこれらの観点を転用することで、安全性を軽視するベンダーを選定段階で見極められます。

とくに重要なのが、プロンプトの隠蔽を避け、透明性を確保する観点です。RAGでは、AIにどのような指示（プロンプト）を与えて回答を生成しているかがブラックボックス化しがちです。ベンダーがプロンプトの内容を開示せず、内部の挙動が把握できない状態では、回答に問題が生じた際に原因を特定できません。RFPには「システムプロンプトや検索ロジックの内容を発注者に開示すること」「回答生成の根拠を追跡できる仕組みを備えること」を要件として盛り込み、透明性を担保してください。

具体的には、RFPに次のような要件を盛り込みます。
・社内データがAIの学習に二次利用されない契約・設定になっているか
・セキュリティインシデント発生時の対応体制と連絡フローが定義されているか
・AIの回答に対する監査やログ保全の仕組みがあるか
・AIガバナンス（利用ルールや責任体制）の構築を支援できるか

これらの観点を要件定義書に明記することで、安全性を軽視するベンダーを発注前にふるい分けられます。生成AIの分野は技術の進歩が速く、論点も日々更新されるため、公的機関が整理した調達観点を土台にすることが、発注者側でも一定の品質を担保する近道です。

RAG固有のセキュリティ要件として、参照する社内データの取り扱いとアクセス制御を定義しておくべきです。RAGは権限の異なる文書を横断的に参照するため、本来アクセス権のない利用者が、検索を通じて機密情報を引き出せてしまうリスクがあります。RFPには「利用者の権限に応じて参照できる文書を制御する仕組み」を要件として盛り込み、文書単位・部門単位でのアクセス制御を求めることが重要です。この権限制御を後付けで実装すると、設計の見直しを伴い、コストも工数も大きく膨らみます。

あわせて、参照データの改ざんや不正な混入への対策も要件化しておきます。RAGは検索対象のデータをそのまま回答の根拠とするため、データが汚染されると誤った回答や情報漏洩につながります。RFPには「参照データへのアクセス制御」「不正な入力を検知・遮断する仕組み」「データの改ざんを検知する仕組み」といった対策要件を盛り込むことが望まれます。これらを発注時に明示しておけば、ベンダーは設計段階からセキュリティを考慮した構築を行います。

セキュリティ要件は、機能要件や費用とトレードオフの関係になることがあります。厳格なアクセス制御や監査機能を求めれば、その分の開発工数と費用は増えます。だからこそ、扱うデータの機密度に応じて、どこまでのセキュリティ水準を求めるかを判断することが重要です。すべてに最高水準を求めるのではなく、機密度の高い情報を扱う部分に重点的に対策を講じるという、メリハリのある要件設計が、コストと安全性を両立させる現実的なアプローチとなります。

外注先を見極める評価チェックリスト

RFPと要件定義書が整ったら、次は提案を受けたベンダーを評価する段階です。複数社から提案を受け取った際、価格だけで選ぶと後悔することが少なくありません。RAGは精度と運用がものを言う領域であり、技術力と運用体制を見極める評価チェックリストを用意しておくことが、納得のいくベンダー選定につながります。ここでは、提案評価で確認すべき観点を整理します。

提案を評価する際は、次の観点をチェックリスト化して各社を採点すると、客観的な比較ができます。
・データ準備の工程に十分な工数を割いているか（全体の40〜60%が目安）
・Ragas等の指標で精度を客観的に評価する体制があるか
・検収基準とSLAが具体的に提示されているか
・運用保守費や従量課金など、隠れコストの内訳が開示されているか
・セキュリティとアクセス制御の設計が要件を満たしているか

これらをスコア化すれば、価格に引きずられず、総合的な実力で各社を比較できます。

とくに注視したいのが、精度を数値で語れるかという点です。「高精度なRAGを構築します」と謳いながら、その精度をどう測り、どう保証するのかを説明できないベンダーは要注意です。逆に、評価指標と検収条件を自ら具体的に提示してくるベンダーは、RAGの難しさを理解している証拠であり、信頼に値します。提案書の精度評価に関する記述の具体性は、技術力を見極める有力な手がかりとなります。

あわせて、PoCから本番への移行を見据えた提案になっているかも確認します。最初から大規模構築を勧めてくるのではなく、まずPoCで効果を検証し、結果を踏まえて本番投資の可否を判断する段階的なロードマップを示すベンダーは、発注者のリスクに配慮できる相手だと言えます。隠れコストの内訳開示、精度の客観評価、段階的なロードマップ。この3点を満たす提案を選ぶことが、RAG構築の外注を成功に導く現実的な判断基準となります。

まとめ

本記事では、RAG構築のRFP・要件定義書・提案依頼書について、費用相場と隠れコストの把握、要件定義書に盛り込むべき項目、セキュリティ・ガバナンス要件の盛り込み方、外注先を見極める評価チェックリストを解説しました。PoCは50万〜200万円、中規模構築は1,500万〜4,000万円という相場感を持ち、運用保守費（初期費用の15〜25%）やベクトルDBのスケーリング費用、API従量課金といった隠れコストを、要件定義の段階で内訳開示まで含めて織り込むことが、予算管理の要です。

要件定義書では、目的と対象データ範囲を明確にし、データ準備に工数の40〜60%を割く前提を共有したうえで、RagasなどによるFaithfulnessといった精度指標と検収基準、SLAを発注時に合意することが欠かせません。さらに、デジタル庁の調達観点を転用してセキュリティとプロンプトの透明性を要件化し、評価チェックリストで各社を客観的に採点すれば、発注後のトラブルを大幅に減らせます。RFPは、単に要望を伝える書類ではなく、自社の要求水準を可視化し、各社を同じ土俵で比較するための設計図です。ここに時間をかけることが、RAG構築というプロジェクト全体の成否を左右します。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。