RAG構築とは？仕組み・5ステップの進め方・費用相場と精度を上げる設計

社内に生成AIを入れたが、自社の規程やマニュアルについて聞くと的外れな答えが返ってくる。だからRAGを構築したい。ここまでは多くの企業が同じ結論に至ります。

ただ、RAG構築でつまずくのはモデル選定ではありません。社内文書が整理されていない、検索の設計が甘い、評価の基準がない。この3つで止まります。RAGの品質は、LLMの賢さより「適切な情報をLLMに渡せているか」に依存します。

本記事では、RAGの仕組みとファインチューニングとの違いから、構築の5ステップ、技術スタックの選択肢、費用相場、精度を上げる設計、そして社内データを扱う際の法務上の注意点までを順に整理します。着手前に決めるべきことが分かる状態を目指しています。

確認したいポイント	結論	詳細
RAGとは何をする仕組み？	社内文書を検索し、AIに渡して答えさせる仕組み	モデル自体は変えず、質問のたびに関連文書を検索して参照させます。最新情報や社内固有の知識にも答えられるようになります。
RAG構築の手順は？	分割・ベクトル化・格納・検索・生成の5段階	各段階の品質がそのまま回答精度に直結します。特に最初のデータ前処理に時間を確保することが、成否を大きく分けます。
RAG構築の費用相場は？	小規模なPoCで200万〜500万円程度	中規模で500万〜1,200万円、大規模で1,500万円以上。運用費は初期開発費の20〜30%程度が年間で継続します。
精度が出ないときどこを見る？	LLMではなくチャンク設計と検索の作り込み	適切な情報をLLMに渡せているかが本質です。ハイブリッド検索、リランキング、メタデータでの絞り込みが定石になります。

この記事でわかること

• RAGの仕組みと、ファインチューニングとの使い分けの基準
• データ分割から回答生成までのRAG構築5ステップと、各段階の勘所
• SaaS・マネージドサービス・フレームワークという構築方法の選択肢
• PoCから大規模までの費用相場と、運用コストを抑える具体策
• チャンク設計・ハイブリッド検索・評価指標など精度を上げる設計と法務上の注意

自社の文書でRAGが成立するのか、どこから着手すべきか。事業相談の初回は無料で対応しています。

RAG構築とは。仕組みとファインチューニングとの違い

手順の話に入る前に、RAGが何を解決する仕組みなのかを確定させます。ここを曖昧にしたまま着手すると、そもそもRAGで解くべきでない課題に投資することになります。

RAGの定義と処理の流れ

RAG（Retrieval-Augmented Generation／検索拡張生成）とは、質問を受けたときに関連する社内文書を検索し、その内容をLLMに渡したうえで回答を生成させる仕組みです。日本語では検索拡張生成と訳されます。

処理は2段階です。まず質問文をもとに知識ベースから関連文書を取り出す検索フェーズ、次にその文書を根拠としてLLMが回答文を組み立てる生成フェーズ。モデル自体には手を加えず、渡す情報を差し替えるという発想が中核にあります。

この構造により、学習時点以降の最新情報や、社外に存在しない社内固有の知識にも答えられるようになります。出典を提示できるため、回答の根拠を確認できる点も業務利用では重要な利点です。

社内規程への質問で見るRAGの具体例

たとえば、社員が社内チャットで「出張で新幹線のグリーン車は利用できますか？」と質問したとします。

RAGは質問文だけをLLMに渡すのではなく、まず社内文書の中から関連する規程を検索します。たとえば、以下のような文書です。

検索対象	参照する内容
出張旅費規程	交通手段、座席区分、役職別の利用条件
経費精算マニュアル	申請方法、必要な領収書、精算期限
出張申請FAQ	例外的にグリーン車を利用できるケース

検索の結果、「出張旅費規程 第8条」に「原則として普通車指定席を利用する。ただし、役員または会社が事前承認した場合はグリーン車を利用できる」と記載されていた場合、RAGはその箇所を根拠として回答を生成します。

回答例は次のようになります。

「原則として、新幹線は普通車指定席を利用します。グリーン車を利用できるのは、役員または会社から事前承認を受けた場合です。利用する場合は、出張申請時に承認を取得してください。

出典：出張旅費規程 第8条、経費精算マニュアル『出張費の申請』」

重要なのは、AIが一般的な知識から回答するのではなく、自社の現行規程を検索し、その内容だけを根拠として回答する点です。該当する規程が見つからない場合は、「確認できる規程がありません。総務部へお問い合わせください」と返すように設計します。

このように、どの文書を検索対象にするか、どの文書を優先するか、回答時にどこまで出典を示すかまで設計して初めて、社内問い合わせで使えるRAGになります。

ファインチューニングとの使い分け

ファインチューニングは、モデル自体を追加学習させて振る舞いを変える手法です。文体や出力形式を安定させたい、特定領域の言い回しに寄せたいといった目的に向きます。

一方、参照すべき知識が頻繁に更新される、出典を示す必要がある、対象文書の量が多いといった条件ならRAGが適しています。社内規程や製品マニュアルの問い合わせ対応は、まさにこの条件に当てはまります。

実務では二択ではなく、RAGで知識を供給し、必要に応じて出力形式だけをプロンプトや軽い調整で整える構成が主流です。まずRAGから検討するのが、費用面でも運用面でも合理的になります。

RAG構築は「データ・検索・AI」の3要素を設計する仕事

RAG構築というと、どのLLMを使うかという話になりがちです。しかし実際に精度を左右するのは、社内データがどう整備されているか、検索がどう設計されているかの部分です。

RAGシステムの品質は、LLMの賢さ以上に、いかに適切な情報をLLMに渡せるかに依存します。したがって、RAG構築は業務課題を起点に、データ・検索・AIの3要素をまとめて設計する仕事だと捉えてください。

関連記事：中小企業が月120時間を削った、生成AI活用30の現場

RAG構築の進め方。5ステップで押さえる

RAG構築は、データ分割からベクトル化、格納、検索、回答生成までの5段階で進みます。各ステップの品質がそのまま最終的な回答精度に直結するため、順に見ていきます。

ステップ1：データの収集と前処理

LLMが参照する社内文書を集めます。規程、マニュアル、議事録、FAQ、過去の問い合わせ履歴などです。PDF、Word、スプレッドシート、社内Wikiと形式が散らばっているのが通常です。

ここで行うのは、テキストの抽出、不要なヘッダーやフッターの除去、表の扱いの決定、重複文書の整理です。RAG構築で最も時間を確保すべきなのがこの工程で、ここを飛ばすと後のチューニングでいくら粘っても精度は上がりません。

同時に、古い版と現行版が混在していないかを確認します。廃止済みの規程が検索に引っかかると、AIは自信を持って誤った回答を返します。

ステップ2：チャンク分割

文書を意味のある塊（チャンク）に分割します。分割の単位が大きすぎると関係のない情報が混ざり、小さすぎると文脈が失われます。検索精度は、チャンクサイズと、文脈を保つための重複幅に強く依存します。

見出し構造を持つ文書なら、見出し単位で区切るのが基本です。表や箇条書きは機械的に切ると意味が壊れるため、扱いを個別に決めます。この設計が後工程すべての土台になります。

ステップ3：ベクトル化とインデックスへの格納

各チャンクを埋め込みモデルで数値ベクトルに変換し、ベクトルデータベースに格納します。埋め込みモデルは検索機能の中核を担うため、日本語での性能と、扱う分野との相性で選びます。

この段階で、あわせてメタデータを付与しておきます。作成年度、部門、公開範囲、文書種別といった属性を持たせておくと、後から検索の絞り込みに使えます。後付けは手間がかかるため、最初に設計してください。

ステップ4：検索（Retrieval）

質問文をベクトル化し、近いチャンクを取り出します。ここが精度の分かれ目で、単純なベクトル検索だけでは実務の要求に応えきれないことが多くあります。詳しい設計は後半の章で扱います。

取り出す件数の設計も重要です。多すぎればノイズが増え、少なすぎれば必要な根拠が欠けます。業務ごとに適正な件数を実測で決める必要があります。

ステップ5：回答生成（Generation）

検索した文書をプロンプトに埋め込み、LLMに回答させます。ここでの設計事項は、根拠にない内容を答えさせない指示、出典の提示形式、そして分からない場合に「分からない」と返す振る舞いです。

業務で使うRAGでは、答えられないことを正直に返せるかどうかが信頼性を決めます。もっともらしい誤答を返す状態のまま展開すると、現場は一度で使わなくなります。

自社の文書でRAGが成立するのか、どこから着手すべきか。データの状態を見ながら判断材料を整理します。事業相談の初回は無料です。

▶ 無料相談を申し込む

RAG構築の選択肢と技術スタック

すべてを自前で書く必要はありません。既存のフレームワークやサービスを活用するのが近道です。作り込みの深さで4つの層に分かれます。

選択肢1：既製のRAG搭載SaaSを使う

社内文書をアップロードするだけで検索と回答ができる製品を使う方法です。開発費がかからず、数週間で立ち上がります。一般的な社内問い合わせ対応であれば、これで足りるケースは少なくありません。

制約は、検索ロジックの調整幅と、既存システムとの連携範囲です。まずSaaSで試し、要件が固まってから開発に移るのが、費用面でも安全な順序になります。

関連記事：カスタマーサポートAIで応答80%自動化｜中小企業実装術

選択肢2：クラウドのマネージドサービスを組み合わせる

各クラウドが提供する検索サービスとLLMサービスを組み合わせる構成です。認証や権限管理を既存のクラウド基盤に寄せられるため、社内展開時の統制が取りやすくなります。

自社でインフラを維持する負担が小さく、セキュリティ要件が厳しい組織でも通しやすいのが利点です。一方で、検索ロジックの細かな制御には制約が出ることがあります。

選択肢3：フレームワークで構築する

LangChain、LlamaIndex、Haystackといったフレームワークを使う方法です。LangChainはLLMと各種ツールを連結し、複雑なワークフローやエージェントを組むのに強い汎用型です。

LlamaIndexはデータ接続とインデックス構築に特化しており、多様なソースから素早く取り込めるためプロトタイプ向きです。Haystackは本番運用と評価機能が充実し、大規模で長期運用するシステムに向きます。

選定の目安は、小規模でスピード優先ならLlamaIndex、複雑な機能と拡張性が要るならLangChain、大規模・長期運用ならHaystackです。ただし最も重要なのは、チームのエンジニアが使い慣れているかという点です。

選択肢4：ベクトルデータベースの選び方

専用のベクトルDBを使うか、既存のリレーショナルDBの拡張機能を使うかの分岐があります。既存のPostgreSQLにpgvectorを入れる構成なら、新しいミドルウェアを増やさずに始められます。

専用DBを選ぶ判断軸は、扱うチャンク数、必要な検索速度、そしてメタデータでの絞り込み機能です。主要なベクトルDBは高度なメタデータフィルタリングに対応しているため、この機能の有無は必ず確認してください。

RAG構築の費用相場と運用コスト

費用は、対象データの量と、どこまで作り込むかで大きく変わります。初期費用と運用費を分けて見積もることが、判断を誤らないための前提です。

初期構築費用の目安

小規模なPoCで200万〜500万円程度、中規模で500万〜1,200万円程度、大規模になると1,500万円以上というのが一つの相場感です。対象文書の種類が多いほど、前処理の工数が積み上がります。

SaaSを使う構成であれば、初期費用を大きく圧縮できます。開発が必要かどうかは、検索ロジックの調整と既存システム連携の要否で決まります。まずここを見極めてください。

運用・保守にかかる継続費用

RAGは構築して終わりではありません。年間の運用・保守費用は、初期開発費の20〜30%程度が相場です。500万円で構築したなら、年間100万〜150万円が目安になります。

内訳は3つです。質問と回答のたびに発生するLLMのAPI利用料、ベクトルDBやサーバーのインフラ費用、そしてデータ更新と精度チューニングにかかる保守費です。利用が増えるほどAPI費が膨らむため、事前の試算が欠かせません。

費用を抑える現実的な方法

最大のコスト要因はLLMの推論費用です。質問の難易度に応じてモデルを切り替えるモデルルーティングを導入すると、推論コストを大きく削減できることが知られています。簡単な質問に高価なモデルを使わない、という発想です。

そのほか、既存のDB機能を使って新規インフラを増やさない、対象データを1部門に絞って段階展開する、データの前処理を社内リソースで行う、といった打ち手があります。特に業界特有の専門知識が要る前処理は、外部委託より社内で行うほうが効率的です。

関連記事：そのAI、何ヶ月で元が取れますか。投資回収を3分で見える化する計算式

構築範囲の切り分け、SaaSと開発の比較、概算費用とランニングコストの試算まで対応します。初回の事業相談は無料です。

RAGの精度を上げるための設計

「回答がずれる」という相談の原因は、ほぼ検索側にあります。LLMを上位モデルに変えても、渡す情報が間違っていれば精度は上がりません。ここでは効果の大きい打ち手を順に挙げます。

チャンク設計を見直す

検索精度は、文書をどう分割するか（チャンクサイズ）と、文脈を維持するためにどれだけ重複させるか（オーバーラップ）に強く依存します。元のチャンクが意味的に断片化されすぎていれば、後段でどれだけ精査しても解決しません。

有効な手法の一つが、検索は的を絞りやすい小さめのチャンクで行い、LLMに渡す文脈としてはそれを含む大きめのチャンクを使う設計です。検索のヒット率を高めつつ、回答生成に十分な文脈を与えられます。

ハイブリッド検索を導入する

ベクトル検索は意味の近さを捉えるのが得意ですが、型番や固有名詞のような完全一致が必要な検索には弱さがあります。逆にキーワード検索は確実性が高い一方、言い換えに対応できません。

この2つを組み合わせるのがハイブリッド検索です。キーワード検索の確実性とベクトル検索の柔軟性を統合するもので、企業向けRAGでは推奨オプションではなく必須要件になりつつあります。スコアの統合にはRRFなどの手法が使われます。

リランキングとメタデータフィルタ

リランキングは、初期検索で取り出した候補を再評価し、関連性の高い順に並べ直す処理です。単純な検索スコアだけでなく、文脈や意味の類似度を考慮して優先順位を決めます。精度向上の切り札になります。

ただし、応答速度を低下させる要因にもなります。すべての検索でリランキングを行うのではなく、一次検索のスコアが低い場合に限定するなど、体験とのバランスを取った実装が必要です。

実務でより効くのが、メタデータによる絞り込みです。年度、部門、文書種別、公開範囲といった属性で候補を先に絞ってから検索すると、精度と速度のバランスが最も良くなることが多くあります。

評価指標を決めてから改善する

RAGの改善を「なんとなく良くなった気がする」で進めてはいけません。想定質問と正解のセットを用意し、検索された情報の正確性や、回答が根拠に忠実かといった観点を数値化します。

評価用のフレームワークを使えば、この計測は自動化できます。数値で比較できる状態を作ってからパラメータを調整する。この順序を守るだけで、チューニングの効率は大きく変わります。

関連記事：Claude Code MCP設定｜業務ツール連携の実装ガイド

社内データを扱うときのセキュリティと法務

RAGは社内の機密情報や顧客データを扱うことが多く、セキュリティやコンプライアンスの要件が厳しくなるほど構築コストは上がります。着手前に確認すべき点を整理します。

個人データをプロンプトに入れる場合の注意

個人情報保護委員会は、生成AIサービスの利用に関して注意喚起を公表しています。個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合、特定された利用目的を達成するために必要な範囲内であることを十分に確認する必要があるとされています。

また、本人の同意を得ずに個人データを含むプロンプトを入力し、それが応答結果の出力以外の目的で扱われる場合、個人情報保護法に違反する可能性が指摘されています。そのため、利用するサービスが当該データを機械学習に利用しないことを十分に確認することが求められます。

出典：個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」

権限に応じて検索範囲を制御する

RAGで見落とされやすいのが、閲覧権限の反映です。人事情報や役員資料が全社員の検索対象に入っていると、AIが権限のない情報を要約して返してしまいます。

回避策は、チャンクに公開範囲のメタデータを持たせ、利用者の権限で検索対象を先に絞り込む設計にすることです。生成側で止めようとせず、検索の入口で制御してください。

出典表示と引用の扱い

検索したチャンクをそのまま回答に含める設計では、引用の範囲を超える分量になっていないかという観点が出てきます。外部の資料やサードパーティのデータを含む場合は、より慎重な確認が必要です。

実務的な対応は、回答本文は要約で返し、原文へのリンクや文書名・該当箇所を出典として併記する形です。根拠を辿れる状態を保ちつつ、原文の大量転載を避けるのが基本形になります。

社内規程との突き合わせ、権限設計、扱えるデータ範囲の整理など、構築前段階のご相談も承っています。事業相談以外のご用件もこちらから。

RAG構築でよくある失敗と回避策

RAGは技術的に難度が高いというより、準備と運用の設計で結果が割れる仕組みです。実際に起きている5つを挙げます。

失敗1：社内文書が整理されないまま着手する

古い版と現行版が混在し、部門ごとにフォーマットがばらばら、そもそもどこに何があるか分からない。この状態で構築しても、精度は上がりません。

回避策は、対象を1部門・1業務に絞り、その範囲の文書だけを正しく整理してから始めることです。全社の文書を一気に取り込もうとした案件は、ほぼ例外なく止まっています。

失敗2：期待値の調整をしていない

AIに対する期待が先行し、実際には検索対象とデータ品質で結果が大きく左右されるという構造が共有されていない。導入後に「思ったほど賢くない」という評価になります。

回避策は、着手前に現状のデータで到達しうる水準を実測して共有することです。事業側と開発側の期待値調整は、RAG構築において特に重要な工程になります。

失敗3：評価をしないままチューニングを続ける

評価セットがないまま、感覚でパラメータをいじり続ける。何を変えたら良くなったのかが分からず、改善が積み上がりません。回避策は、想定質問と正解のセットを最初に作ることです。

失敗4：データ更新の仕組みがない

規程が改訂されてもインデックスが古いまま。半年後には誤った回答を返す装置になります。回避策は、文書の更新を検知して再インデックスする仕組みを、構築と同時に用意しておくことです。

誰がいつ更新するのかを運用ルールとして決めておくところまでが構築の範囲だと考えてください。ここを空欄にした案件は必ず放置されます。

失敗5：いきなり全社に展開する

利用部門が広がるほど、質問の傾向も必要な文書も分散します。精度が安定しないまま全社公開すると、最初の印象で使われなくなります。まず1部門で運用を安定させ、質問ログを蓄積してから広げてください。

関連記事：外注ゼロでAIを回す会社がやっている、内製化5段階のステップ

まとめ

RAG構築で最初に理解すべきなのは、品質を決めるのがLLMではなく、データと検索の設計だという点です。モデルを上位に変えても、渡す情報が的外れなら回答は良くなりません。

手順は、データ前処理、チャンク分割、ベクトル化と格納、検索、回答生成の5段階。費用は小規模PoCで200万〜500万円程度から、運用費は初期費用の20〜30%程度が年間で継続します。SaaSで試してから開発に移る順序が安全です。

精度を上げる打ち手は、チャンク設計の見直し、ハイブリッド検索、リランキング、メタデータでの絞り込み、そして評価指標の設定。評価できる状態を作ってから改善するという順序を守ってください。あわせて、個人データの取り扱いと権限に応じた検索制御は着手前に確認します。

LiftBaseは、現場に入り込んで業務フローそのものを設計し直し、PoCで止まらないAI導入を定着まで支援しています。自社の文書でRAGが成立するのかを判断したい、という段階からのご相談でも構いません。

対象業務の絞り込み、文書の棚卸し、SaaSと開発の切り分け、概算費用の試算まで。初回の事業相談は無料です。