「RAGを外注で進める」という方針は固まった。経営層の承認も取れた。あとは発注するだけ——。そう思って数社に問い合わせてみたものの、返ってきた見積もりの金額にばらつきがあり、「この金額が本当に妥当なのか」「そもそも自社は何を用意しておけばいいのか」が分からず、発注ボタンを押せずにいる。RAGシステムの発注方法を調べているあなたは、いまそんな状態にいるのではないでしょうか。
本格的なシステム発注の経験が浅いと、相場感も、自社で準備すべきことも手探りになります。RAG（検索拡張生成）は社内文書をAIに活用させる仕組みですが、通常のシステム開発と違って「読み込ませる自社データの質」が成否を大きく左右します。だからこそ、ベンダーに丸投げできない発注側の準備が存在し、そこが分からないまま発注して要件ズレや精度不足、想定外の追加費用で失敗するのが怖い——その不安はごく自然なものです。
しかし、発注の進め方を「費用の見極め → データ準備 → ベンダー選定」という3つのステップに分解すると、何から手をつければいいかが一気に見えてきます。やみくもに見積もりを比べるのではなく、各ステップで発注側が判断・準備することを順番に押さえれば、迷わず前に進めます。
本記事では、RAGシステムの発注方法を、発注側が実際に取るべきアクション単位で解説します。見積もりのどこを見るべきか、発注前に自社でやっておくべきデータ準備は何か、ベンダーをどう比較すればいいか。受託開発の現場で発注側が陥りやすい失敗を見てきた視点から、外注を成功させる実務手順を整理します。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
RAGシステムの発注方法を3ステップで整理する
RAGシステムの発注は、漠然と「いい会社に頼む」と考えるとうまくいきません。発注を成功させるには、発注側が押さえるべきポイントを順番に整理することが近道です。まずは全体像から把握しましょう。
なぜRAGの発注は「普通のシステム発注」と違うのか
一般的なシステム開発の発注では、要件を固めてベンダーに渡せば、あとは仕様どおりに作ってもらえます。しかしRAGは少し事情が異なります。RAGは「自社のドキュメントをAIが検索して、その内容をもとに回答する」仕組みのため、回答の精度は読み込ませる自社データの質に強く依存します。
実際、RAGの検索精度が低いと取得される情報が不安定になり、回答内容にブレが生じます。その結果、プロンプトの修正やモデルの再チューニング、想定外の追加開発が必要になり、運用側の負担が膨らみます（AI Market「RAGのデータ前処理はなぜ重要？」）。つまり、どれだけ優秀なベンダーに頼んでも、渡すデータが整っていなければ期待した精度は出ません。
ここがRAG発注の最大の特徴です。「発注したら終わり」ではなく、発注側にも品質を左右する準備の役割があります。準備不足のまま発注すると、ベンダーは見積もり段階で正確な工数を読めず、開発が進んでから「想定よりデータが汚れていた」と判明し、要件ズレや追加費用につながります。この構造を最初に理解しておくことが、失敗を避ける第一歩です。
発注成功までの3ステップ全体像
RAG発注で発注側が取るべきアクションは、次の3つのステップに整理できます。
- ステップ1：費用を見極める — 見積もりの内訳を理解し、金額の妥当性をチェックする観点を持つ
- ステップ2：データ準備をする — 発注側にしかできない自社データの棚卸し・整理・権限整理・正解データの用意を進める
- ステップ3：ベンダーを選定する — RAG固有の評価項目でベンダーを比較し、自信を持って発注する
この順番には意味があります。費用の見方を理解しておくと、見積もりを冷静に読み解けます。データ準備を発注前に進めると、ベンダーが正確な見積もりを出せるようになり、後からの追加費用を防げます。そしてデータと費用の感覚を持った状態でベンダーを比較すれば、価格だけでなく「自社のデータを任せられるか」という本質的な軸で選べます。本記事では、このあと各ステップを順番に掘り下げていきます。
なお、本記事は「外注すると決めた人」に向けて発注の実務手順を解説するもので、「内製すべきか外注すべきか」という判断そのものは扱いません。まだ内製か外注かで迷っている段階の方は、RAG開発・構築ガイド（内製vs外注の判断基準）で判断基準を整理してから本記事に戻ってくると、より理解が進みます。
ステップ1 RAG発注の費用を見極める（見積もりの読み解き方）
最初のステップは費用の見極めです。見積もりの金額そのものに振り回されず、「何にいくらかかっているのか」を内訳レベルで理解することが、妥当性を判断する土台になります。
RAG開発費用の内訳（何にお金がかかるのか）
RAG開発の見積もりは、主に次の要素で構成されます。発注者として、それぞれが何のための費用かを押さえておきましょう。
- データ整備・前処理：自社文書をAIが扱える形に整える工程。フォーマット変換、不要情報の除去、検索しやすい単位への分割（チャンキング）などを含みます。RAGの費用は、実はこの人的工数が大きな割合を占めることが多い領域です。
- ベクトルDB・インフラ：文書を検索可能な形で格納するデータベースや、システムを動かすクラウド基盤の費用。
- LLM API（従量課金）：回答生成に使う大規模言語モデルの利用料。利用量に応じて継続的に発生します。
- 検索・回答ロジックの実装：質問に対して適切な文書を探し出し、回答を組み立てる中核部分の開発費。
- UI（ユーザーインターフェース）：社内ユーザーが使うチャット画面や検索画面の開発費。
- 運用・保守：稼働後の精度改善、データ追加、障害対応などの継続費用。
特に注意したいのは、費用の大半がLLM APIそのものではなく、データ整備とUI開発の人的工数に集中しやすい点です（GXO「RAG導入の費用相場と内訳【2026年版】」）。「AIだからモデルの利用料が高いのだろう」と思い込むと、見積もりの本質を読み違えます。
費用相場の目安（段階別・初期費用と月額の分離）
RAGの費用相場は、どこまで作り込むかによって大きく変わります。同じ「PoC」「本格構築」でも、出典によって示されるレンジには幅があります。代表的な2つの出典が公開している目安を並べると、おおむね次のようになります。
段階 | GXOの目安 | MoMoの目安 |
|---|---|---|
PoC・スモールスタート | 100万〜300万円程度 | 50万〜500万円程度 |
本格構築（部門・社内向け） | 300万〜1,000万円程度 | 500万〜1,200万円程度 |
（出典: GXO「RAG導入の費用相場と内訳【2026年版】」、株式会社MoMo「RAG導入費用を徹底解説」、2026年）
出典によって金額レンジが異なるのは、含まれるスコープ（データ整備の範囲・UIの作り込み・対象データ量）が各社で違うためです。つまり、相場の数字はあくまで目安であり、「この段階ならいくら」と一律に当てはめるのではなく、自社の見積もりがどのスコープを前提にした金額かを確認することが大切です。全社展開・大規模データを扱うエンタープライズ構築になると、上記レンジをさらに超える規模になることもあります。
ここで発注者が必ず分けて捉えたいのが、初期費用と月額ランニングコストです。初期費用は構築にかかる一回限りの費用ですが、RAGは稼働後もLLM APIの従量課金やインフラ費用、保守費用が継続的に発生します。初期費用だけで予算を組んでしまうと、稼働後のランニングコストで予算超過に陥りがちです。見積もりを受け取ったら、初期と月額を必ず別々に確認してください。
発注者目線の見積もり妥当性チェック観点
金額の大小だけで見積もりを比較しても、妥当性は判断できません。発注者として、次の観点で各社の見積もりをチェックしましょう。
- スコープが明記されているか：どこまでが今回の費用に含まれ、どこからが追加費用になるのか。データ整備はどちらが・どこまで担うのか。曖昧な見積もりは後のトラブルの種です。
- 精度が出なかった場合の対応が書かれているか：RAGは一度作って終わりではなく、精度のチューニングが前提です。期待精度に届かない場合の改善対応が費用に含まれるか、別途追加になるかを確認します。
- 運用・改善費の内訳が示されているか：稼働後の保守・精度改善が見積もりに含まれているか、含まれないなら月額いくらかを把握します。
- 3〜5年のトータルコストで比較できるか：初期費用が安くても月額が高ければ、数年で逆転します。導入から数年スパンの総額で各社を並べると、本当の安さが見えてきます。
これらの観点を持っていれば、「安いから」「高いから」ではなく「自社にとって妥当か」で見積もりを読み解けるようになります。
ステップ2 発注側がやるべきデータ準備（RAG発注成功の最大の鍵）
ここからが、RAG発注で最も重要でありながら、多くの解説で見落とされがちなステップです。先ほど触れたとおり、RAGの精度は読み込ませる自社データの質で決まります。つまりデータ準備は、ベンダーに丸投げできない発注側の仕事です。ここを発注前にどれだけ進められるかが、見積もり精度・最終的な回答精度・追加費用の有無を大きく左右します。
実際、RAGの品質はindexにデータを登録する前段階の前処理で大きく左右され、文書の構造や品質をあらかじめ整えておくことで検索と生成の精度が安定し、意図しない誤答を抑制できるとされています（AI Market「RAGのデータ前処理はなぜ重要？」）。発注側がこの準備を主体的に進めることが、成功の最大の鍵です。
なお、RAGで「どの業務の・どんな質問に答えさせるか」というユースケースのイメージがまだ固まっていない場合は、生成AIで社内ナレッジを活用する方法で具体的な活用パターンを掴んでおくと、ここから先のデータ準備の範囲を決めやすくなります。
対象データの棚卸し（範囲を決める）
最初にやるべきは、AIに読み込ませたいデータの棚卸しです。「社内文書全部」と漠然と考えるのではなく、次を具体的に洗い出します。
- どの業務の・どんな質問に答えさせたいのか（用途を絞る）
- その回答に必要な文書は何か（マニュアル、規程、議事録、FAQ、過去の問い合わせ履歴など）
- それらの文書がどこに、どんな形式で保管されているか（共有フォルダ、社内Wiki、メール、紙のスキャンなど）
範囲を絞らずに「とにかく全部」と渡すと、検索のノイズが増えて精度が下がり、整備コストも膨らみます。最初は用途を限定し、必要な文書だけを対象にするのが、精度と費用の両面で得策です。この棚卸し結果が、ベンダーに渡す要件の出発点になります。
データの整理・前処理で発注前に決めておくこと
棚卸しで対象が決まったら、データの状態を確認し、整理の方針を決めます。発注前にここを詰めておくと、ベンダーが正確に見積もれます。
- フォーマットの混在：Word、PDF、Excel、画像、表組みなどが混在していないか。特にスキャンしたPDFや画像内の文字、複雑な表は、AIが正しく読み取れないことが多く、追加の処理工数がかかります。どの形式がどれだけあるかを把握しておきましょう。
- 版管理（最新版と旧版）：同じテーマの文書に新旧バージョンが混在していると、AIが古い情報を回答してしまいます。どれが最新の正とするかを整理しておく必要があります。
- 重複と表記ゆれ：同じ内容の文書が複数あったり、同じものを違う言葉で書いていたりすると、検索精度に影響します。
これらは「発注前に完璧に整える」必要はありませんが、どこにどんな課題があるかを把握し、誰がいつ整理するかを決めておくことが重要です。データの状態が見えないままだと、ベンダーは見積もりにバッファを積むか、開発途中で「想定よりデータが汚れていた」と追加費用を請求することになります。
アクセス権限と機密情報の切り分け（ベンダーに渡す前の線引き）
社内文書には、社外秘・個人情報・部門限定の機密が含まれます。これらをベンダーに渡す前に、必ず線引きを決めておきましょう。
- どの文書を学習・検索対象に含めてよいか、含めてはいけないか
- 個人情報や機密情報をマスキング（伏せる処理）する必要があるか
- 完成したRAGで、誰がどの情報にアクセスできるべきか（部門ごとの閲覧権限の設計）
この切り分けを発注後に後回しにすると、いざ稼働してから「経営層しか見てはいけない情報が一般社員に表示された」といったセキュリティ事故につながりかねません。権限と機密の扱いは技術ではなく業務ルールの問題であり、発注側が主体的に決めるべき領域です。ベンダーに渡す前に社内で合意しておきましょう。
精度検証用の「正解データ」を用意する（評価の物差し）
意外と見落とされがちですが、極めて重要なのが、精度を測るための「正解データ」を用意することです。これは「この質問には、こう答えてほしい」という想定質問と期待回答のペアのことです。
- 実際の業務で社員が聞きそうな質問を、20〜50問ほど集める
- 各質問に対する模範回答（正解）を社内の有識者が用意する
この正解データがあると、完成したRAGに同じ質問を投げて、期待どおりの回答が返るかを客観的に評価できます。物差しがなければ「なんとなく精度が低い気がする」という主観でしか判断できず、ベンダーとの間で「精度が出ている・いない」の認識がずれて揉める原因になります。精度の合格ラインをベンダーと合意するうえでも、正解データは交渉と検収の土台になります。発注前、遅くとも開発初期には用意しておきましょう。
ステップ3 RAGベンダーの選定（評価項目と比較のしかた）
費用の見方を理解し、データ準備を進めたら、最後にベンダーを選定します。集めた見積もりと提案を、価格だけでなくRAG固有の観点で比較することが、失敗しない選定の鍵です。
RAGベンダー選定で見るべき5つの評価項目
複数社を比較する際は、次の5つの評価項目で各社を見ていきましょう。
- RAG・生成AI開発の実績：PoC（試作）で終わらず、本番運用まで導いた実績があるか。デモは作れても本番の精度・運用まで責任を持てる会社かを見極めます。
- 精度が出なかった場合の対応フローと責任分界：RAGはチューニングが前提の技術です。期待精度に届かなかったときに、どこまで改善対応してくれるのか、その責任範囲が提案に明記されているかを確認します。
- データの取り扱い・セキュリティ：渡したデータをAIの学習に使わないか、どこに保管されるか、NDA（秘密保持契約）を結べるか。自社の機密文書を扱う以上、ここは妥協できません。
- 運用・改善まで伴走するか：作って納品して終わりではなく、稼働後の精度改善やデータ追加に伴走してくれるか。RAGは運用しながら育てるシステムです。
- 技術スタックの妥当性と将来の保守性：特定のベンダーにしか保守できない作りになっていないか（ロックインの度合い）。将来、内製化や別ベンダーへの移行が必要になったときに困らない構成かを確認します。
問い合わせ・提案依頼時に必ず確認したい質問例
提案を受ける際、次のような質問を各社に同じく投げると、比較がフェアになります。
- 「過去に本番運用まで到達したRAGの事例を、データ規模や用途も含めて教えてください」
- 「想定した精度が出なかった場合、どこまでが見積もりに含まれ、どこからが追加費用ですか」
- 「当社が渡すデータはどこに保管され、モデルの学習に使われることはありますか」
- 「データ整備は御社・当社のどちらが、どこまで担当する前提の見積もりですか」
- 「納品後の運用・精度改善は、どのような体制・費用で支援いただけますか」
特に4つ目のデータ整備の分担は、データ準備で進めた内容とも直結します。各社が「データ整備は発注側でやる前提」なのか「自社で巻き取る前提」なのかで、見積もり額の意味が変わってくるからです。
複数社を公平に比較するための考え方
各社の回答を集めたら、上記5つの評価項目を縦軸、各ベンダーを横軸にした比較表を作ると、強み・弱みが一目で見えます。価格だけで一列に並べるのではなく、評価項目ごとに見比べることがポイントです。
そして、いきなり大きな契約を結ぶのではなく、まずPoCやスモールスタートで実際の実力を見極めるのが安全です。提案や実績だけでは分からない「自社のデータでどこまで精度が出るか」「コミュニケーションは取りやすいか」は、小さく一緒に進めてみて初めて見えてきます。小さく始めて手応えを確かめてから本格構築に進む——この段階的なアプローチが、ベンダー選定のリスクを最も確実に下げます。
発注後に失敗しないための進め方（PoC・スコープ・運用の引き継ぎ）
発注先が決まっても、そこで気を抜くと失敗します。RAGは「発注したら自動で成果が出る」システムではありません。発注後から稼働までで失敗を避けるための実務を押さえておきましょう。
PoC・スモールスタートで始める（一気に全社展開しない）
最初から全社・全業務にRAGを広げようとすると、データ量も関係者も多くなり、精度のコントロールも費用管理も難しくなります。まずは一部門・一用途に絞ったPoCやスモールスタートで始め、効果と精度を確かめてから範囲を広げるのが鉄則です。小さく始めれば、失敗してもダメージが小さく、学びを次に活かせます。費用面でも、PoCは数百万円規模から始められるため、いきなり大規模投資をするより堅実です。
スコープと精度の合格ラインを契約前に合意する
「どこまで作るか（スコープ）」と「どの程度の精度を合格とするか（合格ライン）」を、契約前にベンダーと文書で合意しておきましょう。ここが曖昧なまま進むと、「これで完成のはず」「いや精度が足りない」という認識のズレが必ず起きます。データ準備で用意した正解データを使い、「想定質問のうち何割に正しく回答できれば合格とするか」を具体的な数値で握っておくと、検収時のトラブルを防げます。
運用・データ整備の内製引き継ぎを前提に置く
RAGは作って終わりではなく、運用しながらデータを追加し、精度を育てていくシステムです。データの追加や日々の運用までずっと外注に頼り続けると、ランニングコストがかさみ、社内にノウハウも残りません。発注の段階から、運用やデータ整備の一部を段階的に内製へ引き継ぐ前提を持っておくと、長期的なコストとノウハウの両面で有利になります。ベンダーには「将来内製化したい」という意向を最初に伝え、引き継ぎやすい構成にしてもらうとよいでしょう。
発注はゴールではなく、RAGを育てていくスタートです。発注側の窓口と意思決定者を明確にし、ベンダーと二人三脚で進める体制を整えておくことが、要件ズレを防ぎ成果につなげる最後のポイントです。
まとめ｜RAG発注を成功させる3ステップの再確認
RAGシステムの発注方法を、発注側が取るべきアクション単位で整理してきました。最後に、3つのステップを振り返ります。
- ステップ1：費用を見極める — 見積もりの内訳（特にデータ整備・運用保守の比重）を理解し、初期費用と月額を分けて捉え、スコープ・精度対応・トータルコストの観点で妥当性をチェックする。
- ステップ2：データ準備をする — 対象データの棚卸し、フォーマット・版・表記ゆれの整理方針、アクセス権限と機密の切り分け、精度検証用の正解データの用意を発注側が主体的に進める。
- ステップ3：ベンダーを選定する — 実績・精度対応・セキュリティ・運用伴走・保守性の5項目で比較し、PoC・スモールスタートで実力を見極めてから本格構築に進む。
そして、RAG発注で最も成否を分けるのは、ベンダー選びそのものよりも発注側のデータ準備です。どれだけ優れたベンダーに頼んでも、渡すデータが整っていなければ期待した精度は出ません。逆に言えば、データ準備を主体的に進められれば、見積もりの精度が上がり、要件ズレや追加費用のリスクは大きく減り、自信を持って発注を進められます。
まず今日できる一歩は、自社データの棚卸しです。「どの業務の・どんな質問に・どの文書で答えさせたいか」を書き出すことから始めてみてください。それが、迷わずRAG発注を進めるための確かな出発点になります。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- データ準備はいつから始めればよいですか？発注後でも間に合いますか？
発注前に着手するのが理想です。データ整備の状態が不明なままだとベンダーは見積もりにバッファを積むか、開発途中で追加費用を請求することになります。棚卸しだけでも発注前に済ませておくと、見積もり精度と後のトラブル防止に大きく効きます。
- ベンダーが「データ整備も込みで対応します」と言っている場合、発注側は何も準備しなくて大丈夫ですか？
「どの業務の・どんな質問に答えさせるか」という用途の絞り込みと、機密情報・アクセス権限の線引きだけは発注側でしか決められません。この2点を整理せずにベンダーに丸投げすると、セキュリティ事故や意図とのズレが起きやすくなります。
- PoCはどのくらいの費用で依頼できますか？
本文が引用する2社の目安を並べると、PoCの費用レンジはおおよそ50万〜500万円程度（出典によって異なる）です。対象データの範囲や想定質問数によって大きく変わるため、まず用途と対象データを絞り込んでから各社に見積もりを依頼するのが確実です。
- 複数社の見積もりを比べても金額差の理由が分からない場合、どう判断すればよいですか？
「データ整備を発注側・ベンダー側のどちらが担う前提か」を各社に確認するのが最初の一手です。この分担の違いが見積もり額の大部分を左右するため、同じ前提に揃えて比較すると差の理由が見えてきます。
- IT専任がいない場合、稼働後の運用・データ追加はどう引き継げばよいですか？
発注時点でベンダーに「将来的に内製運用したい」と伝え、操作マニュアルの整備・引き継ぎ期間の設定を契約に盛り込むのが現実的です。運用担当が1名いれば回せる設計にしてもらうよう最初に依頼しておくと、長期コストを抑えられます。
