執筆:Swooo編集部/監修:諸藤 哲耀(株式会社アイビス Swooo)|編集方針・監修体制
RAG(検索拡張生成)の開発を外部に依頼するとき、判断材料が集まりにくいのが費用です。RAG開発を扱う情報は増えましたが、金額の目安まで示されているものは限られます。
そこでこの記事は、市場で語られている費用相場を先に示し、そのうえで選定基準、依頼先の選択肢、構築の進め方、精度とセキュリティの考え方までを1本にまとめました。社内文書を対象にしたRAGの導入を検討している情報システム部門・DX推進部門の方が、社内説明に使える形で読めるように整理しています。
結論を先に示します。
- 社内データを使うRAG・業務組み込みの開発費は、市場の一般相場で100万〜1,000万円。LLM APIを使った小規模構成なら50万〜300万円
- 金額差の主因はAIモデルの選定ではなく、対象データの整備量・検索の設計・既存システム連携・権限制御の4つ
- 会社選びで特に重要なのは「データ整備の工程が見積もりに入っているか」「精度の合格ラインを契約前に決められるか」「本番運用の体制まで示せるか」の3点(本文ではさらに権限・ログ設計、外部API障害時の設計を加えた5つの基準で解説します)
- 検証で止まったまま本番に進めない状態を避けるには、評価方法と運用担当を検証の開始前に決めておく
RAGとは:社内データを検索してから答えさせる仕組み
RAG(Retrieval-Augmented Generation/検索拡張生成)は、質問を受けたときにまず社内の文書やデータベースから関連情報を検索し、その検索結果を材料として渡したうえでLLMに回答を書かせる構成です。LLMが学習済みの知識だけで答えるのではなく、手元の一次情報を根拠にして答えるため、社内規程・製品仕様・過去案件のように「その会社にしかない情報」を扱えます。
実装上は3つの工程に分かれます。
| 工程 | やること | ここで決まること |
|---|---|---|
| ①データ整備 | 対象文書の収集、テキスト抽出、分割(チャンク化)、メタデータ付与 | そもそも探せる状態になっているか |
| ②検索 | ベクトル検索・キーワード検索の組み合わせ、並べ替え、閲覧権限による絞り込み | 正しい根拠を引っ張れているか |
| ③生成 | 検索結果をプロンプトに載せてLLMに回答生成、出典の提示 | 読める答えになっているか |
回答がずれる原因は、③よりも①と②に多く潜みます。PDFの表が崩れて抽出されている、同じ規程の新旧版が両方入っている、部署限定の資料に誰でも到達できてしまう——こうした状態のままLLMを差し替えても改善しません。RAG開発の実務は、データと検索の設計が主戦場です。
ファインチューニングとの使い分け
自社の情報をAIに扱わせる方法として、ファインチューニング(モデル自体を追加学習させる)と比較されることがあります。判断の目安は、情報の更新頻度と出典提示の必要性です。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 向く情報 | 頻繁に更新される規程・仕様・案件情報 | あまり変わらない書き方・専門用語・出力形式 |
| 更新の手間 | 元データを入れ替えれば反映 | 再学習が必要 |
| 出典の提示 | 検索した文書を根拠として示せる | 出典を示しにくい |
| 権限制御 | 検索段階で利用者ごとに絞り込める | 学習済み知識の切り分けが難しい |
社内ナレッジ検索・問い合わせ対応・申請書や報告書のドラフト作成といった用途では、更新頻度と出典提示の両方が求められるため、RAGが選ばれやすくなります。両方を組み合わせる構成もありますが、最初の一歩としてはRAG単体から始めるほうが検証しやすいです。
RAG開発会社に依頼できる範囲
「RAG開発」と一口に言っても、依頼できる範囲は会社によって差があります。見積もりを比べる前に、どこまでを外部に任せるかを決めておくと比較が成立します。
- 構想・要件定義:対象業務の選定、投資判断に使う効果の見立て、対象データの棚卸し
- データ整備:文書の収集・変換・分割ルールの設計、更新の仕組み化
- 検索・生成の実装:検索方式の設計、プロンプト設計、出典表示、評価データの作成
- アプリ側の実装:利用画面、既存の社内システムやチャットツールとの連携、認証・権限
- 運用:精度の継続測定、データ更新、利用ログの分析、モデル更新への追随
RAG開発会社の選定基準5つ

提案書の見た目では差がつきにくい領域です。次の5点について質問すれば、回答の具体度から経験値を判別できます。
①データ整備の工程が見積もりに入っているか
RAGの工数は、対象データの状態に大きく左右されます。テキスト化されたWiki中心なのか、スキャンPDFや図表入りの設計書が混ざるのか、部署ごとにフォルダ運用が違うのか。ここを見ずに一律の金額を提示された場合、後から追加費用が発生する余地が残ります。
確認する質問は具体的にできます。「どの形式のファイルを、どのツールで、どのルールで分割するか」「新旧版が併存する文書はどう扱うか」「データ更新は誰がどの頻度で回すか」。この3つに設計方針として答えられるかどうかが、経験の分かれ目になります。
②精度の合格ラインを契約前に定義できるか
AIの出力には誤りが一定割合で含まれます。そのため「どの水準なら合格とするか」を契約前にすり合わせておかないと、検収の段階で認識の食い違いが起きます。具体的には、評価用の質問セット(何問用意するか、誰が作るか)、判定者、合格基準、測る指標を決めます。
この論点を先回りして提示してくる会社は、RAG案件の経験があると判断できます。回答が定性的なものにとどまる場合は、測定方法と合格基準を発注側から提示して契約前に合意しておくと、検収の食い違いを避けられます。
③検証のあと本番運用まで担当できるか
RAGは作った時点が完成ではなく、社内文書が更新されるたびに状態が変わります。検証だけを請け負う体制と、運用保守まで含めて引き受ける体制では、提案の中身が変わります。運用フェーズの体制図・作業項目・月額を、検証の提案時点で出せるかを確認してください。
あわせて、社内側の受け皿も決めておきます。データ更新の担当、精度が落ちたときの一次対応、利用者からの問い合わせ窓口。ここが空白のまま検証を始めると、結果が良くても展開に進めません。
④権限制御とログの設計
社内文書を横断検索させる仕組みは、権限設計を誤ると「見えてはいけない資料の内容が回答文として出てくる」状態を作ります。人事情報、未公開の経営資料、取引先ごとの契約条件などが典型です。
設計の考え方としては、既定を「見せない」に置き、閲覧を許可する条件を明示的に足していく方式が安全側に働きます。加えて、誰がいつ何を質問し、どの文書が根拠として使われたかのログを残せるかも確認します。入力データが外部の学習に使われない契約形態になっているかも、社内説明では必ず問われる点です。
⑤既存システム連携と外部API障害時の設計
RAGは単体で完結せず、SharePoint・Box・Salesforce・基幹システム・チャットツールなどとつなぎ込む前提になります。ここは通常のシステム開発の実装力がそのまま出る部分です。実際にご相談いただく中には、外部API連携の実装が進まないまま検討が止まっているケースもあります。
特に見落とされやすいのが、外部APIが落ちたとき・遅延したときの挙動です。
タイムアウトの検知、管理者への通知、失敗した処理の再実行をどう設計するか。ここを標準工程として持っている会社かどうかで、本番稼働後の運用負荷が変わります。
5つをチェックリストにまとめます。
- 対象データの形式・量・更新頻度を確認したうえで見積もりが作られているか
- 評価用の質問セット・判定者・合格基準・指標が契約前に決まるか
- 運用フェーズの体制・作業項目・月額が提案書に含まれているか
- 閲覧権限による絞り込みと、質問・根拠文書のログ設計が示されているか
- 既存システム連携と、外部API障害時の通知・再実行の設計方針があるか
RAG開発の費用相場

ここからが本題です。以下は市場の一般的な相場として整理した目安で、特定の会社の見積もりを示すものではありません。案件ごとの前提で上下します。
| 構成 | 初期開発費の目安 | 典型的な内容 |
|---|---|---|
| LLM API活用(小規模) | 50万〜300万円 | 限られた文書セットを対象に、既存のチャットUIやSaaSに載せる構成。対象業務1つに絞った検証向き |
| RAG・業務組み込み | 100万〜1,000万円 | 社内文書を横断的に扱い、権限制御・既存システム連携・専用画面を伴う構成。全社利用を前提にする場合はこの帯 |
幅が広く見えますが、これは「RAG」という言葉が指す範囲が広いことの反映です。1部署の200ファイルを対象にした検証と、全社数万ファイル・権限階層あり・基幹システム連携ありの本番構成では、必要な工数が一桁以上変わることもあります。
金額を左右する4つの要素
| 要素 | 安く収まる条件 | 費用が上がる条件 |
|---|---|---|
| 対象データ | テキスト化済み・単一の保管場所・版管理あり | スキャンPDFや図表中心・複数システムに分散・新旧版が併存 |
| 検索の設計 | 用途が1つで、想定質問のパターンが限られる | 部署ごとに質問の型が違う・表や数値の照合が必要 |
| 連携 | 単独のWeb画面で完結 | 基幹システム・SaaS・チャットツールへの組み込み |
| 権限・監査 | 全社員が同じ範囲を見る | 部署・役職単位の絞り込み、監査ログ、保持期間の要件 |
逆に言えば、費用を抑える打ち手はモデルの選定ではなく、最初の対象範囲を絞ることです。「よく聞かれる質問が集中している1業務」から始めれば、上表の左側の条件に寄せられます。
要件定義と運用保守の費用
初期開発費のうち、要件定義は全体の10〜15%が目安です。RAGの場合はここに「対象データの棚卸し」と「評価用の質問セット作成」が入るため、削ると後工程で跳ね返ります。
運用保守は、スクラッチで作り込んだ構成の場合月10万〜100万円が目安です。作業内容は、データ更新の反映、精度の定期測定と改善、利用ログの分析、LLM側のモデル更新への追随などです。RAGは対象文書が動き続ける仕組みなので、初期費用だけで比較すると総額を見誤ります。
これらに加えて、LLMのAPI利用料・ベクトルデータベースなどの基盤利用料・クラウド費用がランニングで発生します。利用人数と質問件数で変動するため、想定利用量を置いた試算を提案時点で出してもらうと、年間の総額が把握できます。
小さく検証してから本格化する場合の考え方
段階を分ける進め方は、上記レンジの内数で組み立てます。対象業務を1つに絞った検証は「LLM API活用(小規模)」の帯、そこで評価が通ってから全社展開に広げる段階が「RAG・業務組み込み」の帯にあたります。検証フェーズのために別枠の費用体系があるわけではありません。
このとき重要なのは、検証を「動くかどうかの確認」で終わらせないことです。検証の成果物として、①評価結果の数値、②本番化に必要な追加工数の見積もり、③運用体制の案が揃っていれば、次の投資判断の材料になります。
逆にデモだけが残った場合、社内での次の一歩が踏み出しにくくなります。
AI開発の費用構造そのものについては、方式別の内訳を「AIアプリ開発の費用相場はいくら?方式別の料金と内訳」で詳しく整理しています。
自社のデータ状況で費用感を確認したい場合は、お問い合わせから対象業務とデータの状態をお知らせいただければ、範囲の切り方を含めてご相談を承ります。
RAG開発を依頼できる会社の選択肢
掲載基準:公式サイトで事業内容とRAG関連の提供範囲が確認できる会社を挙げています。掲載順は推奨順ではありません。記載内容は2026年7月時点の各社公式サイトに基づきます。
Swooo(株式会社アイビス)※当社
| 所在地 | 東京都中央区八丁堀一丁目5番1号 |
| 上場 | 東証グロース上場(証券コード9343) |
| 得意領域 | RAG・業務組み込みのAI開発、新規事業の立ち上げ支援 |
本記事の運営元です。Swoooは、ibisPaint(世界累計5億ダウンロード超)を運営する東証グロース上場の株式会社アイビスが提供する開発サービスで、累計50件以上の開発支援を行ってきました。RAGのような業務組み込み型のAI開発と、新規事業の立ち上げ支援を扱います。
実装面では、外部APIのエラーハンドリングを標準工程として整備しています。管理者への通知、タイムアウトの検知、失敗時の再実行設計を最初から設計に含める形です。RAGは外部のLLM APIと社内システムの両方に依存する構成になるため、この部分が稼働後の運用負荷に直結します。
あわせてリリース前チェックリスト37項目を運用し、権限設定の漏れや検証用設定の戻し忘れといった事故を出す前に潰します。
株式会社ヘッドウォータース
| 上場 | 東証上場 |
| 得意領域 | RAG導入アセスメント、RAGの精度改善 |
RAGシステムの開発と、すでに動いているRAGの精度改善コンサルティングを提供しています。導入アセスメントから精度改善までを一連のサービスとして公開しており、RAGの正答精度90%以上の実績を自社サイトで公表しています。
大和証券・JR西日本・伊藤忠商事など、実名の導入事例を掲載している点も判断材料になります。「作ってはみたが精度が上がらない」段階からの相談先としての選択肢です。
パーソルワークスイッチコンサルティング株式会社
| グループ | パーソルグループ |
| 得意領域 | ヒアリングから定着までの一貫支援 |
ヒアリング、環境構築、実証、ガバナンス整備、社内定着までを一貫して支援する体制を公表しています。RAGの構築そのものよりも、導入後に社内で使われ続ける状態まで含めて外部の手を借りたい場合に検討対象になります。ガバナンス整備と社内定着を支援工程として明示している点が特徴です。
大手AI企業・大手SIer系という選択肢
全社規模での標準化や、既存の大規模システムとの連携が主要論点になる場合は、上場・大手のAI企業や大手SIer系も候補に入ります。具体的には、PKSHA Technology、ABEJA、Preferred Networksといった上場・大手のAI企業、大手SIer系ではNTTデータ先端技術などが挙げられます。
会社規模による向き不向きは、案件の性質で決まります。判断の目安を整理します。
| 案件の性質 | 相性のよい依頼先 |
|---|---|
| 1業務から始めて、評価を見ながら範囲を広げる | 段階的な範囲拡大を前提に契約できる開発会社 |
| 最初から全社標準として設計し、既存の大規模システムと統合する | 大手SIer系・大手AI企業 |
| すでに動いているRAGの精度が上がらない | 精度改善を単独サービスとして持つ会社 |
| 社内での定着・ガバナンス整備までを含めたい | コンサルティング型の一貫支援 |
AI開発の受託会社をより広い範囲で比較したい場合は、「AI受託開発会社おすすめ11選」もあわせてご覧ください。
RAG構築の進め方(5ステップ)
| ステップ | やること | 次に進む条件 |
|---|---|---|
| ①対象業務の選定 | 問い合わせが集中している業務、参照する文書が特定できる業務を1つ選ぶ | 対象文書のリストと、想定質問が20〜50件書き出せている |
| ②データの棚卸しと整備方針 | 形式・量・保管場所・版管理の状態を確認し、分割ルールと更新の仕組みを決める | 「探せる状態」にするための作業量が見積もれている |
| ③評価設計 | 評価用の質問セット、正解の定義、判定者、合格基準を先に決める | 合格ラインが数値で書かれている |
| ④検証と改善 | 検索・生成を実装し、評価を回して分割方法や検索方式を調整する | 合格基準を満たす/満たさない理由が説明できる |
| ⑤本番化と運用 | 権限制御・ログ・既存システム連携を作り込み、運用担当と更新フローを確定 | 運用の担当者・頻度・費用が決まっている |
順番として重要なのは、③の評価設計を④より先に置くことです。実装してから評価方法を考えると、「なんとなく良さそう」以上の判断ができず、次の段階に進む根拠が作れません。
期間は対象範囲で大きく変わります。1業務に絞った検証であれば短期間で回せますが、全社展開はデータ整備と権限設計の作業量に比例して伸びます。開発の進め方自体をAI前提で組み立てる方法については「AI駆動開発とは」で解説しています。
精度をどう考えるか:検証で止まらないために
RAG導入で最初に不安が集中するのは精度です。この不安は根拠のあるもので、帝国データバンク「生成AIに関する企業の動向調査」(2026年3月調査・有効回答10,312社)では、生成AI活用の懸念・課題として「情報の正確性」が50.4%と最上位に挙がっています。
一方で、検証の段階で止まってしまう現象も広く報告されています。MIT NANDAの調査レポート「The GenAI Divide: State of AI in Business 2025」(MIT Project NANDA・2025年7月公開。公開されたAI導入事例300件超の分析等にもとづく)は、企業の生成AIパイロットのうち95%が測定可能な収益貢献に至っていないと報告し、その原因をモデルの品質ではなく「進め方」にあると分析しています。
精度への不安そのものは妥当です。そのうえで2つの調査が示しているのは、対処すべき論点が精度の数値の高低ではなく、精度を測る仕組みと運用の受け皿を先に作れているかどうかにあるということです。ここが、検証で終わるか本番に進めるかを分けます。
検索と回答を分けて測る
精度を1つの数字で見ると、改善の手が打てません。少なくとも2段階に分けて測ります。
- 検索の精度:質問に対して、根拠となる正しい文書を候補に取れているか。ここが低い場合の原因はデータ整備と検索設計にあり、プロンプトを直しても改善しません
- 回答の精度:取れた根拠を使って、正しく読める答えになっているか。ここが低い場合はプロンプト設計や出力形式の調整が効きます
あわせて「答えられない質問に、答えられないと返せるか」も評価項目に入れます。根拠が見つからないときに推測で書いてしまう挙動は、社内利用では正答率の低さより問題になります。
公表されている精度の数字の読み方
開発会社が公表している精度の数字は、実績の裏付けとして参考になります。ただし数字だけを比較しても意味は薄く、確認したいのは前提条件です。どんな質問セットで、どの業務ドメインで、誰が正解を判定したのか。前提が違えば、同じ数字でも難易度がまったく違います。
実務上は、他社の公表値を目標にするのではなく、自社の対象業務で作った質問セットに対する到達水準を基準にします。用途によって必要な水準も変わります。参考情報として使う社内検索なら誤りを人が確認できますが、顧客への回答文をそのまま出す用途なら求められる水準は上がります。
セキュリティと権限設計の考え方
RAGは社内データを扱うため、社内の情報セキュリティ部門との調整が必要になります。論点は概ね次の4つに整理できます。
| 論点 | 確認する内容 |
|---|---|
| データの流れ | 社内文書がどこに保存され、どの経路でLLMに渡るか。入力が外部の学習に使われない契約形態か |
| 閲覧権限 | 既定を「見せない」に置き、許可条件を明示的に足す設計になっているか。既存の権限情報と連動できるか |
| ログと監査 | 質問・回答・根拠文書・利用者を記録し、保持期間を定めているか |
| 出力の扱い | 回答を社外に出す用途がある場合、確認者と手順が決まっているか |
権限設計は後付けが難しい部分です。検証段階では「全社員が同じ範囲を見る」前提で作り、本番化のタイミングで部署別の絞り込みを入れようとすると、データの持ち方から見直しが必要になることがあります。権限の階層を最終的にどこまで作るかは、検証の設計時点で共有しておくと手戻りを減らせます。
RAGの次に来る検討事項
社内文書を検索して答える仕組みが動き出すと、次に出てくる要望は「調べるだけでなく、その先の作業まで任せたい」という方向に向かいます。見積書の作成、システムへの登録、担当者への割り振りといった処理です。ここはRAGの延長ではなく、AIエージェントの設計領域になります。
この段階では、扱う費用帯も、必要な権限設計も一段上がります。検討の順序としては、RAGで「社内データを正しく引ける状態」を作ってからのほうが進めやすいです。業務自動化まで含めた設計と費用感は「AIエージェント開発の費用相場と進め方」で扱っています。
よくある質問
RAG開発の費用はいくらかかりますか
市場の一般相場では、社内データを使うRAG・業務組み込みの構成で100万〜1,000万円、LLM APIを使った小規模構成なら50万〜300万円が目安です。加えて、要件定義が全体の10〜15%、運用保守はスクラッチで作り込んだ構成の場合に月10万〜100万円がかかります。金額差は対象データの整備量・検索設計・既存システム連携・権限制御の4要素で決まります。
まず検証から始めるべきですか
対象業務を1つに絞って検証する進め方は有効です。ただし条件があります。評価用の質問セットと合格基準、そして本番化したときの運用担当を、検証を始める前に決めておくことです。ここが決まっていない検証は、動くデモは残っても次の投資判断の材料になりません。
精度は何%を目標にすればよいですか
用途によって変わるため、一律の目標値はありません。人が確認してから使う社内検索と、回答をそのまま外部に出す用途では、必要な水準が違います。決め方としては、自社の対象業務で作った質問セットに対して「この水準なら現在の業務より良い」というラインを、業務側の担当者と合意して設定します。他社の公表値を目標に置くと、質問の難易度が違うため判断を誤ります。
社内文書がPDFやExcelでばらばらでも導入できますか
導入できますが、その整備作業が費用と期間の主要な部分を占めます。特にスキャンされたPDF、図表中心の資料、同じ規程の新旧版が併存している状態は工数が増えます。見積もり時点で対象ファイルのサンプルを渡し、抽出と分割の方針まで含めた見積もりを出してもらうと、後からの追加費用を避けやすくなります。
RAGとファインチューニングはどちらを選ぶべきですか
情報が頻繁に更新される、出典を示す必要がある、利用者ごとに見せる範囲を変える——このいずれかに当てはまるならRAGが向きます。一方、出力の文体や形式を自社仕様に寄せたい場合はファインチューニングが選択肢になります。社内ナレッジ検索や問い合わせ対応では前者の条件が揃うため、RAGから検討するのが一般的です。
情報漏えいのリスクはどう抑えますか
3点を設計で押さえます。①検索段階で利用者の閲覧権限による絞り込みをかける(既定は「見せない」に置く)、②質問・回答・根拠文書・利用者のログを残し保持期間を定める、③入力データが外部の学習に使われない契約形態を選ぶ。特に①は後付けが難しいため、検証の設計時点で最終的な権限階層を共有しておきます。
既存の社内システムと連携できますか
文書管理システム、SaaS、基幹システム、チャットツールとの連携は一般的な要件です。確認したいのは、連携先のAPI仕様に加えて、そのAPIが落ちたとき・遅延したときの設計です。タイムアウト検知、管理者通知、失敗した処理の再実行をどう扱うかを提案時点で確認しておくと、稼働後の運用負荷を見積もれます。
まとめ
RAG開発会社を選ぶときの判断材料を整理します。
- 費用の目安は、RAG・業務組み込みで100万〜1,000万円、小規模構成で50万〜300万円(市場の一般相場)。要件定義が全体の10〜15%、運用保守は月10万〜100万円
- 金額はモデル選定ではなく、データ整備量・検索設計・連携・権限制御で決まる
- 選定時の確認事項は、データ整備工程の有無、精度の合格ライン定義、運用体制の提示、権限とログの設計、外部API障害時の設計
- 評価設計は実装より先に置く。検証の成果物に評価結果・追加見積もり・運用体制案が揃えば、次の段階に進める
Swoooは、東証グロース上場の株式会社アイビスが提供する開発サービスとして、RAGを含む業務組み込み型のAI開発を扱っています。外部APIのエラーハンドリングを標準工程として整備し、リリース前チェックリスト37項目で稼働前の確認を行います。対象業務の切り出しから評価設計、運用体制の組み立てまでのご相談をお問い合わせで承っています。
関連ガイド:AIエージェント開発会社の選び方と比較/LLM開発会社の選び方と比較
じっくり比較したい方へ:会社紹介資料(体制・実績・進め方)を見る