RAG構築とは？仕組み・手順・費用相場から精度を上げるポイントまで解説

自社のマニュアルをChatGPTに読ませてみたら、それらしい嘘を返してきた。生成AIを社内で使い始めた企業から、この相談が急増しています。

原因は単純で、そのモデルが自社の情報を学習していないためです。これを解決する手段として広く採用されているのがRAG（検索拡張生成）で、社内文書を検索し、その中身を根拠に回答させる仕組みを指します。

ただし「RAGを入れれば賢くなる」という理解のまま進めると、ほぼ確実にPoCで止まります。検索の精度が低ければ、AIは間違った根拠をもとに堂々と誤答するためです。

本記事では、RAG構築の仕組みと5つの工程、内製と外注の判断、技術選定、費用相場、そして精度が上がらないときの改善策までを、実務で判断できる形に整理します。

確認したいポイント	結論	詳細
RAG構築とは何ですか？	社内文書を根拠に回答させる仕組み作り	LLMが学習していない自社の情報を検索し、その内容をもとに回答を生成させる構成です。
どんな手順で作りますか？	データ準備から生成までの5工程	前処理、分割、ベクトル化、格納、検索と生成の順。前処理の質が最終的な精度を左右します。
費用はどのくらいですか？	PoCで50〜200万円、本番は数百万円〜	外注した場合の目安です。加えてAPI利用料やインフラ費が毎月かかり続けます。
精度が出ないときは？	生成より検索側に原因があることが多い	まず評価指標を決めて測ることが先決です。次に分割設計と検索方式を見直します。

この記事でわかること

・RAGの仕組みと、ファインチューニングとの使い分け

・データ準備から回答生成までの5つの工程と、それぞれの勘所

・内製・外注・SaaSという3つの選択肢の判断基準

・PoCから本番運用までの費用相場と、継続的にかかるコストの内訳

・精度が出ないときに、どこから手をつければよいのか

RAG構築を検討しているが、どこから着手するか決めきれない方へ 対象業務の切り出しから技術選定、費用の見立てまで、現状をうかがったうえで進め方を一緒に整理します。 構想段階でのご相談も歓迎です。 相談予約はこちら

RAG構築とは——仕組みと必要になる場面

まずはRAGがどのような仕組みで、どんな場面で必要になるのかを押さえます。基本の流れ、ファインチューニングとの違い、そして向き不向きという3点で整理します。

RAGの基本的な仕組み

RAGはRetrieval-Augmented Generationの略で、日本語では検索拡張生成と訳されます。LLMが回答を作る前に、外部の情報源を検索し、その結果を根拠として使うという構成です。

具体的な流れを見てみます。利用者が「就業規則の在宅勤務のルールを教えて」と質問したとき、システムはいきなり回答を作りません。まず社内文書やFAQの中から関連する箇所を検索します。

検索で見つかった内容をLLMに渡し、それを踏まえた回答を生成させる。モデルの記憶ではなく、検索してきた文書を根拠に答えるという点が本質です。

この仕組みによって、社内独自のルールや最新の情報にも対応できるようになります。就業規則が改定されても、検索対象の文書を差し替えるだけで回答が更新される点は運用上の大きな利点です。

ファインチューニングとの違い

自社の情報をAIに扱わせる手段として、ファインチューニング（追加学習）と比較されることがよくあります。両者は目的が異なるため、どちらが優れているという話ではありません。

RAGが得意なのは、知識を後から足すことと、更新に追随することです。文書を差し替えれば回答も変わるため、頻繁に更新される情報を扱う場面に向いています。

ファインチューニングが得意なのは、振る舞いや文体を学習させることです。特定の書式で回答させたい、業界特有の言い回しに合わせたいといった場面で効果を発揮します。

社内の問い合わせ対応やナレッジ検索といった用途であれば、まずRAGを検討するのが基本です。更新コストが低く、回答の根拠を示せるという点でも実務に向いています。

RAGが向く用途・向かない用途

向いているのは、答えが文書の中に書かれている質問です。社内ヘルプデスク、カスタマーサポート、規程やマニュアルの検索、営業資料からの情報抽出といった用途が該当します。

一方で向いていないのは、文書に書かれていない判断を求められる場面や、複数の情報を横断して集計・計算する必要がある場面です。検索して見つかるものがなければ、RAGは答えを作れません。

また、そもそも参照すべき文書が整備されていない場合、RAGを入れても解決しません。元になる情報が散在している、あるいは古いまま放置されているなら、まずそこを直すのが先です。

関連記事：仕事でのAI活用事例｜1日の流れで見る使いどころと時間の作り方【2026年】

RAG構築の全体像——5つの工程

RAGの構築は、データの準備から回答の生成まで5つの工程に分かれます。各工程の品質がそのまま最終的な回答精度に直結するため、順に押さえていきます。

工程1：データの準備と前処理

最初の工程であり、最も精度を左右するのがここです。AIが参照するデータの質を徹底的に高める作業になります。

古い情報、内容の重複、文字化け、表記のゆれ。こうしたものが混ざったまま読み込ませると、AIは誤った根拠に基づいて回答を作ります。質の低いデータからは質の低い回答しか出てこないという原則がそのまま当てはまります。

実際の作業としては、最新のマニュアルや議事録、FAQを選定し、不要な改行や表記ゆれを取り除きます。PDFやスキャン画像が混在している場合は、テキストとして抽出できる状態に揃える工程も必要です。

この工程に十分な時間を確保できるかが、プロジェクトの成否を分けます。ここを軽視して先に進んだ結果、後の工程でいくらチューニングしても精度が上がらない、というのが典型的な失敗パターンです。

工程2：チャンク分割

準備した文書を、意味のあるかたまり（チャンク）に分割する工程です。地味な作業ですが、社内導入で詰まるのはこの部分だと言われるほど重要です。

分割が細かすぎると、文脈が失われて意味の通らない断片になります。逆に大きすぎると、関係のない情報まで一緒に検索結果へ含まれ、回答がぼやけます。

扱う文書の性質によって適切な分割の仕方は変わります。見出しごとに区切るのが自然な規程類と、Q&A単位で区切るべきFAQでは、設計が違って当然です。

前後のチャンクを少し重ねて保持する方法もよく使われます。文の途中で切れてしまう問題を緩和するための工夫です。

工程3：ベクトル化と格納

分割したチャンクを、埋め込みモデルによって数値の並び（ベクトル）に変換します。意味の近い文章どうしが、数値の空間上でも近い位置に配置されるようにするための処理です。

変換したベクトルは、ベクトルデータベースに格納します。ここに蓄えられたデータが、後の検索の対象になります。

この工程で決めるのが、どの埋め込みモデルを使うかです。日本語の文書を扱うなら、日本語での性能が確認されているモデルを選ぶ必要があります。後から変更するには全データの再変換が必要になるため、最初の選定は慎重に行ってください。

工程4：検索と回答生成

利用者が質問を入力すると、その質問も同じ方法でベクトルに変換され、格納済みのデータの中から意味的に近いチャンクが取り出されます。

取り出したチャンクを、質問とあわせてLLMに渡します。「以下の資料をもとに質問に答えてください」という形で指示を組み立てる部分です。

ここで根拠となった文書を回答に添えて表示する設計にしておくと、利用者が内容を確認できるようになります。社内で信頼して使ってもらうためには、この透明性が欠かせません。

また、検索で適切な情報が見つからなかった場合の挙動も設計が必要です。無理に答えさせず「該当する資料が見つかりません」と返すほうが、誤答よりはるかに実用的です。

RAGの技術選定と体制づくりを、専門家と一緒に進めたい方へ 構築方法の比較や、導入時に確認すべき項目をまとめた資料をご用意しています。 稟議や社内検討の材料としてお使いください。 資料請求はこちら

関連記事：AIエージェントの活用事例｜業務別の使い方と権限設計の注意点【2026年最新】

RAG構築の3つの選択肢——内製・外注・SaaS

どう作るかによって、必要な体制もコストも変わります。内製、外注、既存サービスの利用という3つの選択肢を、それぞれの条件とあわせて整理します。

内製で作る場合

内製の利点は、外注費がかからないことと、自社の要件に細かく合わせられることです。改善のサイクルも自分たちで回せるため、長期的には有利になります。

ただし前提条件があります。埋め込みモデルやベクトルデータベースを理解しているエンジニアを確保できることです。ここが揃わないまま着手すると、動くものはできても精度が上がらず、改善の手立ても打てない状態になります。

現実的な進め方としては、まず小規模なプロトタイプを内製して仕組みを理解し、本番構築の判断はその後に行うという順序です。学習の投資として内製に取り組むという位置づけであれば、価値のある選択肢になります。

外注する場合

社内にリソースがない、あるいは早く形にしたい場合は外注が現実的です。要件定義から設計、実装、既存システムとの連携までを任せられる点が利点になります。

委託先を選ぶ際は、自社と近い業種・用途での実績があるかを確認してください。社内ヘルプデスク、カスタマーサポート、規程検索など、用途によって設計の勘所が異なるためです。

もうひとつ確認すべきなのが、精度をどう測り、どう改善するかの方法論を持っているかです。作って納品して終わりではなく、評価と改善の枠組みまで提示できる相手かどうかが、後の運用を左右します。

AI開発の外注を検討する際の観点は、ネクストスケールのAI活用コラムでも取り上げています。

SaaS・ノーコードを使う場合

近年は、管理画面からファイルをアップロードするだけでRAGが使えるサービスも増えています。エンジニアリソースが限られる場合の有力な選択肢です。

最大の利点は、小さく試せることです。委託先を決める前の効果検証や、そもそもRAGが自社の課題に効くのかを確かめる段階では、この手軽さが役に立ちます。

一方で制約もあります。細かなチューニングができない、既存システムとの連携に限界がある、データの保管場所が自社の規程に合わないといった点です。

まずSaaSで効果を確かめ、必要性が明確になってから本格的な構築に進むという段階的な進め方は、投資の判断としても合理的です。

関連記事：医療現場のAI活用例｜業務別の使いどころと規制で外せない確認点【2026年】

RAG構築における技術選定のポイント

内製や外注で作る場合、いくつかの技術的な選択が必要になります。フレームワーク、ベクトルデータベース、モデルという順に、選定の考え方を整理します。

フレームワークの選び方

すべてを自前で書くより、既存のフレームワークを使うのが近道です。代表的な選択肢には次のようなものがあります。

・LangChain：LLMと各種ツールを連結し、複雑な処理やエージェントを組むのに強い汎用的なフレームワーク

・LlamaIndex：データの接続とインデックス構築に特化。多様な情報源から素早く取り込めるためプロトタイプ向き

・Haystack：本番運用や評価の機能が充実しており、大規模で長期運用するシステムに向く

選定の目安は、小規模でスピード優先ならLlamaIndex、複雑な機能や拡張性を求めるならLangChain、大規模で長期運用ならHaystackという整理になります。

ただし最も重要なのは、自社のエンジニアが使い慣れているかどうかです。理論上の適合度より、実際に手を動かす人の習熟度が開発速度を決めます。

ベクトルデータベースの選び方

ベクトルデータベースは、専用のサービスを使う方法と、既存のデータベースの拡張機能を使う方法に大別されます。

既にPostgreSQLを運用しているなら、その拡張機能を使うことで初期費用を抑えられます。データ量が中規模までであれば、この構成で十分に実用的です。

一方、大量のデータを扱う場合や、検索速度が重要な場合は専用のサービスが選択肢になります。マネージドで提供されるものを使えば運用の負担は減りますが、その分の費用が継続的に発生します。

判断の軸は、データ量、必要な検索速度、そして自社の運用体制です。最初から大規模を想定するのではなく、実際のデータ量に見合った構成を選んでください。

LLMと埋め込みモデルの選び方

回答を生成するLLMは、扱う情報の機密性によって選択肢が変わります。外部のAPIを使うのか、自社環境で動かすモデルを使うのかという判断です。

社内文書に個人情報や機密情報が含まれる場合、APIに送信してよいかを情報取り扱い規程と照らして確認する必要があります。この確認を後回しにすると、構築後に運用できないという事態になります。

AIを事業で利用する際の基本的な考え方は、経済産業省「AIガバナンス」のページで公開されている各種ガイドラインが参考になります。開発・提供・利用それぞれの立場で求められる取り組みが整理されています。

埋め込みモデルについては、日本語の文書を扱うなら日本語での性能を確認したうえで選ぶことが重要です。英語で評価の高いモデルが日本語でも同じ性能を発揮するとは限りません。

自社データでRAGが機能するか、まず検証したい方へ 対象文書の選定から評価の設計まで、小さく始めて効果を見極める進め方をご提案します。現状をお聞かせください。 相談予約はこちら

RAG構築の費用相場

稟議を通すうえで必要になるのが費用の見立てです。初期費用、運用でかかり続ける費用、そして抑えるための工夫という順に整理します。なお金額はあくまで一般的な目安であり、要件によって大きく変動します。

初期費用の目安

外注する場合の目安として、PoC（概念実証）で50万〜200万円程度、本番構築で数百万円から1,000万円超という水準が示されています。要件の複雑さと連携するシステムの数によって幅が出ます。

PoCの費用が極端に安い場合は注意が必要です。実データを使わないデモレベルの検証では、本番での精度が見えず、結局やり直しになります。

逆にPoCの見積もりが高すぎる場合は、検証範囲が広すぎる可能性があります。対象部門と対象文書を1つに絞り、数週間で検証する構成が、費用対効果の面では最も無駄がありません。

内製の場合は外注費こそかかりませんが、担当エンジニアの工数が実質的なコストになります。人月換算で比較すると、外注と大差ない、あるいは上回るケースもあります。

運用でかかり続ける費用

見落とされやすいのが、構築後に継続的に発生する費用です。主な内訳は3つあります。

・LLMのAPI利用料：質問と回答のたびに発生する従量課金。利用者数と文章量に比例して増える

・インフラ費用：ベクトルデータベースやサーバーの維持費。マネージドか自社運用かで変動する

・保守・改善費：データの更新や精度のチューニングにかかる人件費

年間の運用・保守費用は、初期開発費の20〜30%程度が相場とされています。500万円で構築したなら、年間100万〜150万円を見込んでおく計算です。

特に注意したいのがAPI利用料です。利用者が増えるほど費用が膨らむ構造であるため、全社展開を想定するなら事前の試算が欠かせません。

費用を抑える工夫

現実的な手立てはいくつかあります。

ひとつめが、対象データを絞って段階的に展開することです。全社の全文書を対象にすると、データ整備だけで費用が膨らみます。1部門・1業務のFAQに絞って始めるほうが確実です。

ふたつめが、質問の難易度に応じてモデルを切り替える設計です。単純な質問には軽いモデル、複雑な質問には高性能なモデルを充てることで、API費用を大きく削減できます。

みっつめが、既存のデータベースを活用して初期費用を抑える方法です。専用のサービスを新規に契約する前に、今あるものを流用できないかを検討してください。

精度が上がらないときの改善策

RAG構築で最も多い相談が「思ったほど精度が出ない」というものです。原因の切り分け方と、検索側・生成側それぞれの改善策を整理します。

まず精度を測る

改善の前に必要なのが、現状を数値で把握することです。感覚的に「なんとなく精度が低い」という状態では、何を直せばよいか判断できません。

評価の観点は大きく2つに分かれます。検索が正しい文書を取ってこられているかと、取ってきた文書をもとに正しく回答できているかです。この2つを分けて測ることが、原因の切り分けにつながります。

実務での進め方としては、想定される質問と正しい回答の組み合わせを数十件用意し、それに対する結果を確認します。この評価用のデータセットを作る作業が、改善サイクルの土台になります。

なお、社内検索の用途であれば80〜90%程度の精度で十分に実用的です。95%を超える精度を目指すとチューニングの工数が急増するため、目標水準の設定も重要な判断になります。

検索側の改善

精度が出ない場合、多くは生成ではなく検索側に原因があります。正しい根拠が渡っていなければ、どれだけ優れたLLMでも正しく答えようがありません。

最初に見直すべきはチャンクの分割設計です。文書の性質に合っていない分割は、検索結果の質を根本から下げます。細かすぎないか、逆に大きすぎないかを、実際の検索結果を見ながら調整します。

次に有効なのが、意味による検索とキーワードによる検索を組み合わせる方法です。製品名や型番のような固有の表現は、意味の近さだけでは拾いきれないためです。

さらに、検索してきた候補を並べ替えて絞り込む処理を挟む方法もあります。多めに取得したうえで本当に関連の高いものだけをLLMに渡すことで、回答の質が上がります。

生成側の改善

検索が正しく機能しているのに回答がずれる場合は、生成側に手を入れます。

見直すべきは、LLMに渡す指示文の構成です。「渡した資料の範囲だけで答えること」「資料に書かれていない場合はその旨を答えること」といった制約を明示するだけで、誤答は大きく減ります。

回答の形式を指定することも有効です。結論、根拠、参照した文書名という構成で出力させると、利用者が内容を検証しやすくなります。

それでも改善しない場合は、使用するLLM自体の見直しが選択肢になります。ただしモデルを変えれば解決するケースは思うほど多くありません。まずは検索側と指示文を疑うのが順序として正しい進め方です。

PoCで止まっているRAGを、実用レベルまで引き上げたい方へ 精度が出ない原因の切り分けから改善の設計まで、既存の仕組みを踏まえてご提案します。現状をお聞かせください。 相談予約はこちら

RAG構築を成功させるための進め方

最後に、プロジェクトとしてどう進めるかを整理します。範囲の絞り込み、運用体制、そして本番移行の判断という3点です。

対象範囲を絞る

最も多い失敗が、最初から全社の全文書を対象にしようとすることです。データ整備だけで費用と期間が膨らみ、成果が見えないまま頓挫します。

推奨されるのは、1つの部門、1つの業務、数百件程度の文書に絞って始める進め方です。範囲が狭ければ、データの質も担保しやすく、効果の測定も容易になります。

選ぶ対象としては、問い合わせが多く、答えが文書に明記されている業務が適しています。人事・総務への定型的な質問や、製品の仕様に関する問い合わせなどが典型例です。

体制と運用の設計

構築段階で見落とされがちなのが、運用に入った後の体制です。RAGは作って終わりではなく、参照する文書を最新に保ち続けて初めて価値が出ます。

決めておくべきなのは、文書を更新する担当者、更新の頻度、そして更新した内容をシステムに反映する手順です。この運用が回らないと、時間の経過とともに回答が古くなり、使われなくなります。

あわせて、利用者からのフィードバックを集める仕組みも用意してください。回答が間違っていた事例こそが、改善の最も有用な材料になります。

PoCから本番への移行判断

PoCの目的は、動くものを作ることではなく、本番に進めるかどうかを判断する材料を得ることです。

判断の基準は、精度が業務で許容できる水準に達しているか、利用者が実際に使い続けたいと感じているか、そして費用に見合う効果が見込めるかの3点です。

この3つのいずれかが満たされないなら、範囲や方式を見直してから進むほうが結果的に早くなります。要件のずれを抱えたまま本番構築に入ると、手戻りの規模が桁違いになるためです。

効果測定の指標としては、問い合わせ対応にかかっていた時間、担当者が回答を探す時間、そして回答までの待ち時間などを、導入前後で比較するのが分かりやすい入り口になります。

まとめ

RAG構築とは、社内文書を検索してその内容を根拠に回答させる仕組みを作ることです。データ準備、分割、ベクトル化、格納、検索と生成という5つの工程で構成され、なかでも最初のデータ準備が精度を大きく左右します。

構築方法は内製・外注・SaaSの3つがあり、社内のエンジニアリソースと求める要件によって選択が変わります。費用はPoCで50万〜200万円、本番構築で数百万円以上が目安で、加えてAPI利用料などが継続的に発生します。

進め方としては、1部門・1業務に絞ってPoCを行い、精度と効果を確認したうえで本番に進む。この順序であれば、投資判断を段階的に行いながら、確実に成果へつなげられます。

AI活用を社内に定着させる進め方については、ネクストスケールのブログ記事一覧もあわせてご覧ください。

RAG構築を、自社の状況に合わせて具体化したい方へ 対象業務と扱うデータをうかがったうえで、内製と外注の切り分けを含めて率直にお伝えします。 検討段階でのご相談も歓迎です。 相談予約はこちら

参考・出典

・経済産業省「AIガバナンス」：https://www.meti.go.jp/policy/it_policy/ai-governance/index.html

・総務省「AI事業者ガイドライン」：https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html