RAG構築の発注では、目的と対象データを決め、費用・精度・安全性をRFP（提案依頼書）に示します。PoCで検証してから本番へ進むと、提案の比較と予算管理につながります。
契約後は、想定精度に届かない、運用費が当初の想定を大きく超えるといったトラブルも頻発します。全体像はRAG構築の完全ガイドもご覧ください。
▼全体ガイドの記事
・RAG構築の完全ガイド
AIシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
RAG構築の費用相場と見落としがちな隠れコストの把握
RFPを作る前に費用相場を把握しておくと、ベンダーの見積もりが妥当かを判断できます。
RAGの構築費は、規模やアプローチによって大きく変わります。だからこそ、まず相場感を持つことが大切です。
相場を知らないまま発注すると、過剰な金額を支払う場合や、安さだけで品質の低いベンダーを選ぶ場合があります。
要件定義の前提として、費用相場と見落とされがちな隠れコストを押さえておく必要があります。
フェーズ別の費用相場の目安
RAG構築の開発費は、目指すフェーズによって異なります。RFPには、目指す段階と到達目標を明記してください。
- 小規模なPoC：50万〜200万円程度が目安です。
- 中規模の本番構築：1,500万〜4,000万円程度が一般的な水準です。
- 大規模な全社展開：5,000万円以上に達することもあります。
まずPoCで効果を検証するのか、最初から本番運用を見据えるのかによって、必要な予算とスコープは変わります。フェーズが曖昧なままだと、各社の想定する範囲がずれ、見積もりを比べられなくなります。
たとえば、ある社はPoCを、別の社は本番構築を前提にすることがあります。同じ依頼書でも、前提が違えば金額が何倍も開く場合があります。
目指すフェーズと到達目標を示すと、各社から比較できる見積もりを得やすくなります。
実務では、まずPoCで小さく検証してから本番へ進む、段階的な進め方が勧められます。具体的には、PoCで業務に耐える精度かを確かめ、効果を数字で確認してから本格投資に移れば、大きな失敗を避けられます。
RFPには、PoCの結果を踏まえて本番への移行可否を判断すると書き込みます。また、各フェーズの費用を分けて見積もってもらうと、リスクや予算の上振れを抑えられます。
RFPで開示を求めるべき隠れコストの内訳
RAGの予算では、初期開発費のほかに発生する費用も見込んでおく必要があります。運用保守費は、初期開発費の15〜25%程度が年間で継続する目安です。試算の前提によっては、20〜30%とされる場合もあります。
保守費を要件定義の段階で見込んでおかないと、運用開始後に予算超過となることがあります。そのため、RFPでは初期費用と分けて年間額を示してもらいます。
利用量に応じて変わる費用は、次のようなものです。
- 生成AIのAPI従量課金：質問数やトークン量に応じて増えていく費用。
- ベクトルデータベース費用：データの増加に伴い、スケーリングに要する額。
- インフラ増強費：文書量や利用者の増加に対応して生じる出費。
利用が増えるほど費用も膨らみます。そこで、RFPでは想定する利用量のもとでの月額ランニングコストと、その内訳を求めます。
初期費用だけで比べると、運用段階で総額が逆転するケースもあります。たとえば、ベクトルデータベースの費用は文書量が増えるほど段階的に上がり、見積もりの時点では小さく見えても、運用が進むと負担が増します。
RFPには「文書量が当初の2倍、5倍になった場合」の試算条件を記してもらい、将来の総保有コスト（TCO）を確認します。隠れコストの内訳を発注条件に含めれば、見えない出費への対策になります。
要件定義書とRFPに盛り込むべき項目
要件定義書とRFPに盛り込む基本項目は、目的と対象データ、精度指標などです。そのほかに、セキュリティ、運用保守とSLA、隠れコストの内訳も含めます。
必要項目がそろうと、ベンダーは工数を見積もれるようになり、発注者は各社を同じ条件で比べられます。
なかでも見落とされやすいのは、対象データの範囲と精度評価の指標です。
目的と対象データ範囲の明確化
要件定義では、システムの目的と、AIに読み込ませるデータの範囲を固めておきます。
- 文書と質問：参照する文書の種類と量、対応する質問の範囲。
- 業務連携：有人対応への引き継ぎや、外部システムとの連携が必要かどうか。
- 文書形式：PDF、Excel、社内Wikiなど、対象文書の形式。
対象文書の一覧と形式を要件定義書に書いておくと、作業の量を見積もる前提がそろいます。手書きのスキャンや複雑な表が混在する場合は、事前にベンダーへ伝えておきます。後から工数が膨らむのを防ぐためです。
RAG導入を5段階で整理する考え方では、データ準備に始まり、チャンキング設計や検索方式の選定、生成の制御を経て、評価に至ります。各段階で何をどこまで作るかを明記すれば、スコープの抜け漏れを防げます。
データ準備は、プロジェクト全体の工数の40〜60%を占めるとも言われます。そのため、どこまでをベンダーに任せ、どこから社内で対応するかを分けておくと、費用と日程を予測しやすくなります。
特に、文書の整形やノイズ除去、適切なチャンク（分割単位）の設計は、最終的な回答精度を左右します。この工程を軽視すると、精度不足につながります。だからこそ、RFPには十分な工数を見込むよう記載します。
データ準備を省略しようとするベンダーは、選定の段階で見極めます。一方で、丁寧な準備はRAG構築のPM鉄則です。
精度・評価指標の合意と検収基準
回答精度は関係者の間で合意がずれやすいため、「精度が高いこと」ではなく、測定可能な指標を決めておきます。
- Context Precision：検索した文書の的確さを示す検索精度。
- Faithfulness：回答が参照文書に忠実かを示す指標。
Ragasなどの評価フレームワークには、上記のような指標が用意されています。RFPでその活用を求めれば、精度を数値で検証できます。
検収（受け入れ判定）の基準も、発注時に合意しておきます。完成の水準を定めないと、納品時の評価が主観的になり、トラブルの原因になります。
たとえば、代表的な質問100件への正答率が一定以上であることや、Faithfulnessが定めた閾値を上回ることを条件にできます。測定方法と判定基準をセットで定めておくと、ベンダーとの認識のずれを防ぎ、円滑な検収につながります。
運用保守の範囲とSLA（サービス品質保証）も明記しておきます。具体的には、応答速度の目標値や稼働率、障害時の対応時間を定めます。
文書を更新したときの再学習についても、頻度と範囲を決めておきます。そうすれば、運用段階でどこまでを誰が受け持つかが明確になります。
精度指標、検収基準、SLAを具体的に決めておくと、「作ったが使えない」という結末を避けられます。逆に、合意が曖昧なままだと、契約上の根拠をもって改善を求めにくくなります。
セキュリティ・ガバナンス要件の盛り込み方
RAGは社内の機密情報を参照するため、セキュリティとガバナンスの要件を定義しておく必要があります。
参考になるのが、デジタル庁が公開している調達向けのチェックシートです。官公庁向けの評価項目も、民間企業のRFPに応用できます。
これらの項目を使えば、見落としがちなリスクを幅広く確認できます。
公的な枠組みを基にすれば、社内に専門知識が乏しい場合でも、要件の抜け漏れを減らせます。
デジタル庁の調達観点の民間RFPへの転用
デジタル庁の調達チェックシートは、次の観点を示しています（出典：デジタル庁）。
- AIガバナンス：構築と運用の体制。
- インシデント対応：セキュリティ事故が起きた際の対応体制。
- システムの透明性：AIの挙動を把握できる状態。
行政向けの項目ではありますが、安全かつ責任をもってAIを運用できるかを問う点は、民間にも当てはまります。RFPに転用すれば、安全性を軽視するベンダーを、選定の段階で見極められます。
RAGでは、回答を生成する指示がブラックボックス化しがちです。そのため、プロンプトを隠さず、透明性を確保することも求められます。
プロンプトが開示されず内部の挙動を把握できないと、回答に問題が起きた際に原因を特定できません。そこでRFPには、システムプロンプトや検索ロジックの開示と、回答根拠を追跡できる仕組みを求めます。
上の観点を民間の発注に当てはめると、要件定義書に明記しておきたい項目は4つあります。
- 二次利用：社内データをAIの学習に使わない契約と設定。
- 事故対応：インシデント時の対応体制と連絡の流れ。
- 監査：AIの回答を事後に確認でき、ログを残しておく仕組み。
- ガバナンス支援：利用ルールや責任体制の構築を助ける取り組み。
これらを要件定義書に明記すれば、安全性を軽視するベンダーを、発注の前にふるい分けられます。生成AIの論点は日々更新されます。そのため、公的機関の調達観点を基にすることは、発注者が品質を確保する近道になります。
参照データの保護とアクセス制御の要件
RAGでは、参照する社内データの取り扱いとアクセス制御を定めます。権限の異なる文書を横断検索するため、本来はアクセス権のない利用者が機密情報を引き出すおそれがあります。
権限制御を後から実装しようとすると、設計の見直しが必要になり、コストと工数が大きく膨らみます。
参照データの改ざんや不正な混入も、要件として定めます。データが汚染されると、誤回答や情報漏洩につながります。
RFPには、次の対策を明記します。
- 権限に応じた検索制御：文書単位・部門単位での参照範囲の制御。
- 不正入力対策：不正な入力の検知と遮断。
- 改ざん対策：参照データへのアクセス制御と、改ざんの検知。
発注時に示しておけば、ベンダーは設計の段階からセキュリティを考慮できます。
セキュリティ要件は、機能要件や費用とトレードオフになることがあります。厳格な制御や監査機能を求めるほど、開発の工数も費用も増えていきます。
必要なセキュリティ水準は、扱うデータの機密度に応じて判断します。すべてに最高水準を求めず、機密度の高い情報を中心に対策を施せば、費用と安全性を両立しやすくなります。
外注先を見極める評価チェックリスト
RFPと要件定義書が整ったら、提案を受けたベンダーを評価する段階に進みます。
価格だけで選ぶと、後になって悔やむことがあります。RAGでは精度と運用の質が問われるため、技術力と運用体制を確認します。
評価チェックリストを用意しておくと、納得できるベンダー選定につながります。
提案評価で確認すべき観点
提案は次の5つの観点でチェックリスト化して採点すると、複数社を客観的に比べられます。
- データ準備：全体工数のうち40〜60%を目安に割いているか。
- 精度評価：Ragas等を用いた客観的な評価の体制の有無。
- 受け入れ条件：検収基準とSLAが具体的に示されているか。
- 費用開示：保守費や従量課金などの内訳が示されているか。
- 安全性：セキュリティとアクセス制御が要件を満たしているか。
項目ごとにスコアをつけると、価格に左右されず、総合的な実力で比較できます。精度を数値で説明できるかも見ておきます。「高精度」とうたいながら、測定方法や保証方法を説明できないベンダーには注意が必要です。
評価指標と検収条件を具体的に示すベンダーは、RAGの難しさを理解していると考えられます。提案書の精度評価がどこまで具体的かも、技術力を測る手がかりになります。
PoCから本番への移行を見据えた提案かも確認します。最初から大規模な構築を勧めず、段階的な計画を示すかどうかが、見極めの材料になります。PoCで効果を確かめ、その結果から本番投資の可否を判断する計画は、発注者のリスクに配慮したものです。
内訳の開示、精度の客観評価、段階的な計画を備えた提案が、外注先を選ぶ判断基準になります。
まとめ
ここまで、RAG構築の費用相場、要件定義、セキュリティ要件、外注先の評価を見てきました。RAG構築を外注するときは、目的と対象データを明確にし、費用・精度・安全性をRFPに記載します。
PoCは50万〜200万円、中規模構築は1,500万〜4,000万円が目安です。保守費やデータベース費用、API課金も見積もりに含めます。
運用保守費は初期費用の15〜25%が目安ですが、前提により20〜30%の場合もあります。隠れコストの内訳開示も求めます。
対象データと準備範囲を定め、準備の工数を全体の40〜60%と想定します。Ragas等の指標、検収条件、SLAについても、発注時に合意しておきます。
デジタル庁の調達観点を参考に、セキュリティとプロンプトの透明性を要件として定めます。評価表で各社を採点すれば、発注後のトラブルを減らせます。
RFPは、自社の要求水準を文書にして示し、各社を同じ条件で比べるためのものです。作成に時間をかけることが、RAG構築全体の成否を左右します。
▼RFP作成前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。