RAG（検索拡張生成）構築ガイド｜設計・データ準備・精度改善の実装ステップと外注判断【2026年版】

社内文書やマニュアルを生成AIに正しく答えさせたい。その定番手法が RAG（検索拡張生成）です。しかし「rag 構築」で調べても、断片的なサンプルコードか、抽象的な紹介記事が多く、「結局どういう順番で、何を選び、どう精度を測ればいいのか」までを一気通貫で示した情報は多くありません。この記事は、自社でRAGを作りたい実装者と、外注すべきか迷っている発注担当の双方が、手を動かす／依頼先を評価する両方に使えるよう、データ準備から評価・精度改善・費用と外注判断までを、公式ドキュメントと原論文に基づいて整理します。

RAG（検索拡張生成）構築とは？まず押さえる全体像

RAG構築とは、生成AIに社内文書などの外部知識を検索させ、その結果を根拠に回答を生成する仕組みを作ることです。学習済みモデルの記憶だけに頼らず、検索した文書を回答の根拠に使う点が核心です。

RAGは Retrieval-Augmented Generation（検索拡張生成）の略で、大きく「検索（retrieval）」と「生成（generation）」の2段構えでできています。ユーザーの質問が来たら、まず社内文書などの知識ベースから関連する文章を検索し、その文章を質問と一緒にLLM（大規模言語モデル）へ渡して、検索結果を根拠にした回答を生成させます。これにより、モデルが学習していない自社固有の情報や、学習後に更新された最新情報にも、根拠を示しながら答えられるようになります。

この考え方の出発点は、RAGの原著論文（Lewis et al., 2020）です。この論文は、事前学習済みの生成モデル（パラメトリック記憶）に、Wikipediaの密ベクトルインデックスという外部知識（ノンパラメトリック記憶）を検索して組み合わせる構成を提案し、知識集約型タスクで当時の最高水準を達成しました。論文は、外部知識を参照する構成が「より具体的で多様、かつ事実に即した（more specific, diverse and factual）言語を生成する」と報告しています。ここで注意したいのは、これは2020年当時のモデル・データセットに基づく結果であり、「ハルシネーションを何％削減する」といった一般化した数値ではない点です。RAGの価値は「外部知識を根拠に回答できるようになる」ことであって、精度が自動で保証されるわけではありません。だからこそ、後述する評価と精度改善の工程が構築の成否を分けます。

なぜ今RAGが選ばれるのか。ファインチューニング（モデル自体を追加学習させる方法）と比べると、RAGは知識の更新が容易です。文書を差し替えれば回答に反映され、モデルの再学習は不要です。また、どの文書を根拠に答えたかを提示しやすく、業務での説明責任にも向きます。一方で、検索が的外れなら生成も的外れになるという弱点があり、「検索の質」を作り込むことが構築の中心作業になります。この記事では、その検索と生成をどう組み立て、どう測り、どう改善するかを順に見ていきます。

「rag 構築」を検討している人の関心は、実際には3つに分かれます。1つ目は「RAGとは何か」を確認したい層、2つ目は「どう作るか」を手順で知りたい層、3つ目は「何を選び、自社で作るか外注するか」を判断したい層です。本記事はこの3つすべてに答えられるよう構成しています。まず本節と次節で仕組みを押さえ、続く7ステップで作り方を具体化し、そのうえでベクトルDB・埋め込みモデルの選び方、精度改善、日本語での注意点、費用と外注判断へと進みます。読む順番は上から順で構いませんが、急ぐ場合は最後の状況別早見表から自分の位置を確認し、必要な節へ飛ぶ使い方もできます。

RAGの仕組みと構成要素（検索と生成をどう組み合わせるか）

RAGは、前処理・埋め込み・ベクトルDB・検索・生成・評価という6つの要素からできており、文書を検索可能な形に変換しておき、質問時に関連文書を引いて生成に渡す流れで動きます。

RAGを支える6つの要素を、役割で整理しておきます。前処理は情報源をクリーンなテキストに整える工程、チャンク分割はそれを検索単位に切り分ける工程、埋め込みは各チャンクを意味を表すベクトルに変換する工程、ベクトルDBはそのベクトルを保存して高速に類似検索できるようにする工程です。ここまでが「事前準備」にあたります。実行時に働くのが検索と生成で、検索は質問に関連するチャンクを取り出し、生成はそれらを根拠にLLMが回答を作ります。そして評価が、生成した回答の質を測って各要素へ改善をフィードバックします。この6要素の役割分担を頭に入れておくと、後で「どこを直せば精度が上がるか」を切り分けやすくなります。

処理の流れは大きく「事前準備」と「実行時」に分かれます。事前準備では、社内文書などを検索単位に分割（チャンク分割）し、各チャンクを埋め込みモデルでベクトル（数値の列）に変換して、ベクトルDBに格納しておきます。実行時には、ユーザーの質問を同じ埋め込みモデルでベクトル化し、ベクトルDBから類似度の高いチャンクを検索して取り出し、それらを質問と一緒にLLMへ渡して回答を生成します。図の右側にある「評価による改善ループ」が示すとおり、生成した回答の質を指標で測り、検索や分割の設計に戻して改善する循環が、実運用では欠かせません。

ここで、RAGと対比される別のやり方にも触れておきます。近年はLLMが扱える入力（コンテキスト）の長さが伸び、「検索せず、関連しそうな文書を丸ごとプロンプトに貼る（long-context）」という選択肢も現実味を帯びています。ただ一般的な傾向としては、必要な箇所だけを検索して渡すRAGのほうが、コスト・精度・更新性の面で有利になりやすいと言えます。コスト面では、毎回の質問で大量の全文を渡すとLLMへ送るトークン量が膨らみ、その分の課金がかさみます。精度面でも、無関係な文章を大量に混ぜると、モデルが要点を見失って回答がぼやける傾向が指摘されます。更新性の面では、文書が変わっても検索対象を差し替えるだけで済むRAGに対し、都度どの全文を貼るかを組み替える運用は煩雑になりがちです。もちろん扱う文書がごく少量なら全文投入で十分なこともあり、両者は排他ではありません。まずは「必要箇所だけを根拠に渡す」というRAGの発想を軸に据えると、規模が増えても破綻しにくい設計になります。

検索（retrieval）と生成（generation）の2段構え

RAGの品質は、この2段のどちらが原因で崩れているかを分けて考えられるかにかかっています。検索段の役割は「質問に本当に必要な文書を、漏れなく・的確に取ってくる」ことです。ここで必要な文書を取りこぼすと、生成段がどれだけ優秀でも正しい回答は作れません。生成段の役割は「取ってきた文書だけを根拠に、質問へ的確に答える」ことです。検索が正しくても、生成が文書を無視して自分の記憶で答えたり、質問とずれた回答をすれば品質は落ちます。後半で紹介する評価指標も、この「検索側の問題」と「生成側の問題」を切り分けられるように設計されているため、まずこの2段構えを頭に入れておくと、精度改善の道筋が立てやすくなります。

埋め込みとベクトル検索の役割

検索段の中核が「埋め込み（embedding）」です。OpenAIの埋め込みガイドによれば、埋め込みはテキスト文字列間の関連度（relatedness）を測るためのもので、検索・クラスタリング・レコメンドなどに使われます。テキストをベクトルに変換すると、意味が近い文章はベクトル空間上でも近くに配置されるため、キーワードが一字一句一致しなくても「意味的に近い」文書を見つけられます。同ガイドは、ベクトル間の類似度計算にコサイン類似度を推奨し、大量のベクトルを高速に検索するにはベクトルデータベースの利用を推奨しています。埋め込みの次元数はモデルにより異なり、text-embedding-3-small は既定1536次元、text-embedding-3-large は既定3072次元とされています（2026年7月時点・最新は公式で要確認）。この次元数は、後述するベクトルDBの選定に直結する重要な数字です。

ここで押さえておきたいのは、これら6要素はそれぞれ独立に設計・改善できるということです。チャンク分割だけを見直したり、埋め込みモデルだけを差し替えたり、検索段だけにハイブリッド検索を足したりできます。この「部品ごとに切り分けられる」性質は、後述の「精度が出ないときの改善策」での原因切り分けでも、外注を段階的に発注する判断（「費用の考え方と内製・外注の判断」）でも効いてきます。なお、LLMのAPIを実際に呼び出す部分の基礎はAnthropic APIの始め方ガイドも参考になります。

RAG構築の実装ステップ（データ準備から評価まで7ステップ）

RAG構築は、データの収集・前処理からチャンク分割、埋め込み、ベクトルDBへの格納、検索実装、生成、評価という7ステップで進めると、動くだけでなく「精度を測って改善できる」RAGになります。各ステップを、入力・作業・成果物・つまずき（よくある失敗と回避）の4点で具体的に見ていきます。小規模データでまず一周し、評価指標を回してから本番規模へ広げる進め方はAIのPoCから本番運用への進め方ガイドも参考になります。

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

入力：RAGに答えさせたい情報源です。社内マニュアル、製品ドキュメント、FAQ、議事録、PDF、Webページ、スプレッドシートなど、対象範囲を最初に定義します。

作業：まず「どの質問に答えられれば成功か」を決め、その回答に必要な文書だけを集めます。次に、PDFやHTMLからテキストを抽出し、ヘッダー・フッター・ページ番号・ナビゲーションといったノイズを除去します。表や箇条書きは構造が崩れやすいため、抽出後にレイアウトが保たれているか目視で確認します。文書に更新日・部署・機密区分などのメタデータを付けておくと、後の検索でフィルタリングに使えます。個人情報や公開してはいけない機密が含まれていないかも、この段階で棚卸しします。

成果物：ノイズを除去し、メタデータを付与した、クリーンなテキスト群。これが次のチャンク分割の入力になります。

つまずき（よくある失敗と回避）：最も多い失敗は、PDFからのテキスト抽出が汚いまま先に進むことです。段組みや表がぐちゃぐちゃに抽出されていると、どれだけ後段を作り込んでも検索・生成の品質は上がりません。スキャンPDFはOCRが必要で、抽出品質が低い場合はここに工数をかける価値があります。回避策は、代表的な文書を数件抜き出して抽出結果を必ず目視すること。「入り口のデータが汚いと出口も汚い」がRAGの鉄則です。加えて、重複した文書（同じマニュアルの新旧版が混在するなど）を放置すると、検索で古い情報が上位に来てしまうことがあります。バージョンや更新日をメタデータに持たせ、必要なら最新版だけを対象にする設計を、この段階で決めておくと後段が安定します。

完了条件：対象文書がクリーンなテキストとして抽出され、メタデータが付与されている。

ステップ2 チャンク分割の設計

入力：ステップ1のクリーンなテキスト群。

作業：文書を検索単位（チャンク）に分割します。ここが構築で最も工数と精度への影響が大きい工程です。LangChainのText splittersドキュメントは、推奨の出発点として RecursiveCharacterTextSplitter を挙げています。これは段落→文→単語の順に、できるだけ大きな意味のまとまりを保とうとする分割器で、既定の区切り文字は改行や空白の階層になっています。設計上の意思決定ポイントは主に2つです。1つ目はチャンクサイズで、大きすぎると1チャンクに複数の話題が混ざって検索がぼやけ、小さすぎると文脈が断ち切られます。2つ目はオーバーラップ（隣接チャンクの重なり）で、これを設けると、文の途中で切れて文脈が失われるのを防げます。HTML・Markdown・JSONのように構造を持つ文書は、見出しやセクション単位で切る構造ベースの分割が有効とされています。

成果物：検索単位に分割され、必要に応じてオーバーラップを持つチャンク群。各チャンクは元文書やメタデータへの参照を保持します。

チャンクサイズとオーバーラップの決め方には、実務的な当たりのつけ方があります。まずは「1チャンク＝1つの完結した意味のまとまり」を目安にし、見出しやセクションなど文書構造の切れ目を優先して分割します。オーバーラップは、直前の数文を次のチャンクの先頭に重ねる程度から始め、文脈が切れて回答がおかしくなるケースが出たら増やす、というように評価結果を見て調整します。最初から最適値を狙う必要はなく、いくつかの候補を用意して比較できる状態にしておくことが重要です。

つまずき（よくある失敗と回避）：万能なチャンクサイズは存在しません。公式ドキュメントも固定値を示していないとおり、最適値は文書特性と、次のステップで使う埋め込みモデルの最大トークン長に依存します。よくある破綻が、埋め込みモデルの最大トークン（例えば後述のmultilingual-e5は512トークン上限）を超えるチャンクを作り、超過分が切り捨てられて情報が欠落するケースです。もう1つの失敗は、表や箇条書きを1文字ずつ機械的に切ってしまい、行と見出しの対応関係が壊れることです。回避策は、チャンクサイズを埋め込みモデルの上限内に収めること、オーバーラップを過少にしすぎないこと、構造を持つ文書は構造ベースで分割すること、そして数パターンのサイズを試して評価（ステップ7）で比較することです。

完了条件：チャンクが埋め込みモデルのトークン上限内に収まり、文脈が不自然に断ち切られていない。

ステップ3 埋め込みモデルでベクトル化

入力：ステップ2のチャンク群。

作業：各チャンクを埋め込みモデルに通してベクトルに変換します。ここでの意思決定は「どのモデルを使い、何次元にするか」です。前述のとおり、OpenAIの text-embedding-3-small は1536次元、-large は3072次元が既定です（2026年7月時点・公式で要確認）。次元数が大きいほど表現力は上がりますが、ストレージと計算コストが増え、後述するベクトルDBの制約にも関わります。重要な注意として、質問側と文書側は必ず同じ埋め込みモデルでベクトル化しなければ、意味的な比較が成立しません。日本語主体なら、多言語対応や日本語適性を選定基準に加えます（詳しくは後述の選び方と日本語の注意点の章で）。

成果物：全チャンクに対応するベクトル群と、各ベクトルに紐づく元チャンク・メタデータ。

次元数の選び方も判断が要ります。次元数が大きいほど微妙な意味の違いを捉えやすくなる一方、ストレージ量と検索時の計算量が増え、コストとレイテンシに影響します。まずは小さめの次元（例：text-embedding-3-small の1536次元）で一周し、精度が足りなければ大きい次元へ上げる、という進め方だと無駄が少なくなります。ここで決めた次元数が、後のベクトルDBのインデックス制約に収まるかを必ず確認してください。

つまずき（よくある失敗と回避）：モデルを途中で変えると、既存のベクトルとの整合が崩れ、全チャンクの再ベクトル化が必要になります。回避策は、PoC段階で候補モデルを評価で比較し、本番前に確定させること。もう1つの落とし穴が、選んだ次元数を格納先のベクトルDBが扱えるか未確認のまま進めることで、これはステップ4に直結します。API課金型の埋め込みを使う場合、初回の全文書ベクトル化でまとまった量のリクエストが発生するため、対象文書量からおおよそのコストを事前に見積もっておくと予算のずれを防げます。

完了条件：全チャンクが単一の埋め込みモデルでベクトル化され、次元数が格納先DBの制約に適合している。

ステップ4 ベクトルDBへの格納

入力：ステップ3のベクトル群とメタデータ。

作業：ベクトルとメタデータをベクトルDBに格納し、類似検索用のインデックスを構築します。ここで「どのベクトルDBを使うか」を確定します。既存にPostgreSQLがあるなら拡張の pgvector、運用を任せたいならフルマネージドの Pinecone、キーワード検索とベクトル検索を組み合わせたいなら Weaviate、といった具合に、既存資産・運用体制・要件で選びます（後述の「ベクトルDBと埋め込みモデルの選び方」で詳しく比較します）。インデックス方式（HNSWなど）とそのパラメータ、メタデータフィルタの設計もこの段階で決めます。

ここで、ステップ1のメタデータ設計がどう効くかを具体的なシナリオで補足します。例えば社内規程200ファイルをRAG化する想定を考えます。就業規則・経費規程・情報セキュリティ規程などが部署別・改定履歴付きで存在し、旧版と新版が混在しているとします。前処理の段階で各チャンクに「規程名」「所管部署」「改定日」「有効／廃止」といったメタデータを付けておけば、格納時にそのままフィルタ用のフィールドとして活かせます。すると検索段で「情報セキュリティ規程の最新版だけ」「人事部が所管する規程だけ」と対象を絞り込め、廃止された旧版が根拠として混ざる事故を構造的に防げます。逆に、ここでメタデータを設計せずに全ファイルを一括で放り込むと、内容が似た新旧の規程がベクトル空間上で近接し、検索で古い条文が上位に来てしまう典型的な事故につながります。メタデータ設計はステップ1で決めておくほど、ステップ4以降の検索精度が安定します。

成果物：検索可能な状態でベクトルが格納されたベクトルDBと、そのインデックス。

つまずき（よくある失敗と回避）：見落とされやすいのが次元数の上限です。例えば pgvector の HNSW インデックスには2000次元の上限があるとされ（2026年7月時点・公式で要確認）、text-embedding-3-large の3072次元をそのまま HNSW で使えないという制約が生じます。この場合、次元数の小さいモデルを選ぶ、次元削減する、別のインデックス方式やDBを選ぶ、といった判断が必要です。回避策は、ステップ3のモデル選定とステップ4のDB選定を必ずセットで検討することです。

完了条件：ベクトルが格納され、テスト質問で類似チャンクが返る状態になっている。

ステップ5 検索（retrieval）の実装

入力：ステップ4のベクトルDBと、ユーザーの質問。

作業：質問を同じ埋め込みモデルでベクトル化し、ベクトルDBから類似度の高い上位k件のチャンクを取得します。取得件数kは、多すぎると生成段に無関係な文書が混ざり、少なすぎると必要な情報を取りこぼすため、評価で調整します。メタデータフィルタ（部署・更新日など）を併用すると、対象範囲を絞って精度を上げられます。この段階で、後の改善余地として「ベクトル検索だけでなくキーワード検索も併用するハイブリッド検索」を組み込めるよう、検索段を差し替え可能に作っておくと後が楽です。

成果物：質問に対して関連チャンク上位k件を返す検索機能。

取得件数kの決め方も、精度とコストのトレードオフです。kを大きくすれば必要な文書を取りこぼしにくくなりますが、生成段に渡す文書が増えてノイズが混じり、LLMへ渡すトークン量（＝コスト）も増えます。まずは小さめのk（数件程度）から始め、必要な情報が取れているか（Context Recall）を評価で確認しながら調整するのが実務的です。

つまずき（よくある失敗と回避）：略語・型番・固有名詞など「意味は似ていないが文字として一致すべき語」は、ベクトル検索だけだと取りこぼしがちです。回避策は、こうしたケースが多い場合にハイブリッド検索を検討すること（後述の「精度が出ないときの改善策」で詳述）。また、kを固定で決め打ちせず、評価で最適な件数を探ることも重要です。メタデータフィルタ（部署・製品・更新日など）を併用して検索範囲をあらかじめ絞ると、無関係な文書の混入を減らせます。

完了条件：代表的な質問に対し、根拠となるチャンクが上位に返ってくる。

ステップ6 LLMでの生成（プロンプト設計）

入力：質問と、ステップ5で取得した関連チャンク。

作業：質問と検索結果をLLMに渡し、回答を生成します。プロンプト設計の要点は、「渡した文書だけを根拠に答え、根拠がなければ『分からない』と答える」よう明示すること、回答に出典（どのチャンク・文書に基づくか）を付けさせること、そして回答のトーンや形式（箇条書き・要約など）を指定することです。検索されたチャンクをどの順で・どう区切ってプロンプトに入れるかも、回答品質に影響します。

成果物：検索結果を根拠にした回答を返す生成機能。出典表示付きが望ましい。

プロンプトに検索結果を差し込む際の具体的な工夫もあります。各チャンクに出典（文書名やセクション）を添えて渡すと、モデルが根拠を明示しやすくなります。関連度の高いチャンクを先頭に置く、チャンク同士を明確な区切りで区切る、といった配置も回答品質に効きます。回答フォーマット（結論を先に述べる、箇条書きにする、など）を指定しておくと、業務でそのまま使える出力になりやすくなります。

つまずき（よくある失敗と回避）：検索結果を渡しても、モデルが文書を無視して自分の記憶で答えてしまう（結果として誤情報を出す）ことがあります。回避策は、プロンプトで根拠限定を強く指示し、根拠がない場合の振る舞いを定義すること。逆に、検索が的外れなのに生成を疑ってしまう混同も起きやすいため、次のステップの評価で検索と生成を分けて測ることが不可欠です。「文書に書かれていなければ推測せず、分からないと答える」ルールを明示するだけでも、根拠のない断定はかなり減ります。

完了条件：検索結果に基づいた回答が生成され、根拠のない断定が抑えられている。

ステップ7 評価と精度測定

入力：質問と期待される回答（または根拠）のテストセット、そして実際の検索結果・生成結果。

作業：RAGを「作って終わり」にしないための最重要工程です。Ragasの評価指標ドキュメントは、主要指標として次の4つを定義しています。Faithfulness（回答が検索した文書に根拠づけられ、裏付けのない主張を含まないか）、Answer Relevancy（回答が質問に的確に答えているか）、Context Precision（検索したチャンクのうち関連するものの割合＝検索の的確さ）、Context Recall（回答に必要な情報が検索結果に含まれているか）です。前2つは「生成の品質」、後2つは「検索の品質」を測るため、どちらに問題があるかを切り分けられます。まずテスト質問セットを用意し、これらの指標を算出して、弱い指標を狙って改善します。

成果物：検索・生成それぞれの品質を数値化した評価結果と、改善の優先順位。

評価を機能させる前提が、良質なテスト質問セットです。実際に業務で聞かれる質問を、想定回答（または根拠となるべき文書）とセットで数十件用意すると、改善の効果を安定して測れます。網羅的である必要はなく、「よく聞かれる質問」「答えにくい質問」「答えるべきでない質問（社外秘など）」をバランスよく含めるのがコツです。このテストセットは一度作れば、チャンク設計・埋め込みモデル・検索方式を変えるたびに使い回せる資産になります。

つまずき（よくある失敗と回避）：最大の失敗は、評価工程そのものを飛ばして体感で「なんとなく良くなった」と判断することです。これでは改善が場当たり的になり、本番で精度が崩れます。もう1つの注意点として、RAGASの多くの指標は評価用LLMを使って算出されるため、評価LLMやプロンプト次第で結果が変動しうること、合格ラインの絶対スコアは公式が一律に定めていないことです（2026年7月時点）。回避策は、絶対値を過信せず、自社の同一質問セットで改善前後を相対比較する使い方に徹することです。

完了条件：テスト質問セットに対し4指標が算出でき、改善の当たりどころが見えている。

7ステップの完了条件チェックリスト

• 対象文書がクリーンなテキストとして抽出され、メタデータが付いている（ステップ1）
• チャンクが埋め込みモデルのトークン上限内で、文脈が断ち切られていない（ステップ2）
• 全チャンクを単一モデルでベクトル化し、次元数がDBの制約に適合している（ステップ3）
• ベクトルが格納され、テスト質問で類似チャンクが返る（ステップ4）
• 代表質問に対し、根拠チャンクが上位に返ってくる（ステップ5）
• 検索結果に基づく回答が生成され、根拠のない断定が抑えられている（ステップ6）
• 4指標が算出でき、改善の当たりどころが見えている（ステップ7）

要件定義の段階から検索対象や評価基準を整理しておきたい場合は、AIシステム開発の要件定義ガイドも、この7ステップを発注要件に落とすうえで役立ちます。

ベクトルDBと埋め込みモデルの選び方（実名比較）

ベクトルDBと埋め込みモデルは、「既存にPostgreSQLがあるか」「運用を任せたいか」「ハイブリッド検索や日本語適性が要るか」という実務軸で選ぶのが失敗しない考え方です。ここでは代表的な選択肢を、強み・限界・向く／向かないケース・料金の確認先まで並べて比較します。

社内データを外部 API に出さない構成を検討する場合は、ローカルLLMおすすめ比較で日本語性能と費用を比較しています。

ベクトルDB比較（Pinecone / pgvector / Weaviate / Elasticsearch）

選択肢	タイプ	強み	限界・注意	向くケース	料金の確認先
Pinecone	フルマネージド	スケーリング・最適化・保守を自動で行い、書き込みが即時検索可能。セマンティック検索やRAGが代表用途で、運用負荷を抑えやすい	外部SaaSに依存するため、データ所在やベンダーロックインの検討が必要	運用を任せたい／自前でDB運用の体制が薄いチーム	公式で要確認（2026年7月時点）
pgvector	PostgreSQL拡張	既存のPostgreSQL上でベクトル格納・類似検索が可能。HNSWインデックスを提供（既定 m=16, ef_construction=64）	HNSWは2000次元の上限があり、text-embedding-3-largeの3072次元をそのまま使えない点に注意（2026年7月時点・公式で要確認）	既にPostgreSQLを運用し、データを1つのDBに集約したいチーム	公式で要確認（2026年7月時点）
Weaviate	ハイブリッド検索対応	BM25キーワード検索とベクトル検索を組み合わせるhybrid searchを公式提供。取りこぼしと意味検索を両立しやすい	機能が豊富な分、設計・チューニングの学習コストがかかる	略語・型番など文字一致も重要で、ハイブリッド検索を使いたいチーム	公式で要確認（2026年7月時点）
Elasticsearch	既存全文検索資産と統合	すでに全文検索基盤として運用している場合、その資産の上でベクトル検索を足せる。既存の検索運用ノウハウを活かせる	ベクトル検索専用DBと比べ、用途や設定により最適化の作り込みが必要になる場合がある	既にElasticsearchの全文検索を運用しており、そこにRAGを載せたいチーム	公式で要確認（2026年7月時点）

選定の軸を言い換えると、「運用を任せたいなら Pinecone」「既存PostgreSQL資産を活かすなら pgvector」「キーワード一致も両立したいなら Weaviate」「既存の全文検索基盤があるなら Elasticsearch」が出発点です。実務では、データの所在制約（社外SaaSに文書を置けるか）、扱うデータ規模、チームがDB運用にどれだけ工数を割けるか、という3点を先に整理すると、候補が自然に絞れます。例えば、機密文書が多くデータを外に出しにくいなら自前運用できる pgvector や Weaviate が候補に上がり、運用人員を割けないなら Pinecone のようなフルマネージドが現実的です。PoC段階では手軽に始められる構成で検証し、本番でデータ量・運用要件に合わせて選び直す、という二段階の判断もよく取られます。特に見落とされやすいのが、埋め込みの次元数とベクトルDBのインデックス制約の食い合わせです。pgvector の HNSW 2000次元上限と text-embedding-3-large の3072次元は、そのまま組み合わせられないため、モデル選定とDB選定は必ずセットで検討してください。なお、各社の料金・無料枠・上限は変動が速いため、本記事では価格を断定せず、各行に公式確認を促しています。RAGは社内文書という機微な情報を扱うことが多いため、外部に出す文書の範囲や権限設計はAIのプロンプトインジェクション対策ガイドの観点もあわせて確認しておくと安全です。

埋め込みモデル比較（OpenAI text-embedding-3 / Cohere / multilingual-e5）

モデル	特徴	注意点	出典
OpenAI text-embedding-3	-small は既定1536次元、-large は既定3072次元。検索・クラスタリング等の汎用用途に広く使われ、ドキュメントも充実	次元数・仕様・料金は変動しうる。3072次元はDBのインデックス制約（例：pgvector HNSW 2000次元）に注意（2026年7月時点・公式で要確認）	OpenAI 埋め込みガイド
Cohere embed	多言語対応の埋め込みを提供し、複数言語が混在する文書での検索に選択肢となる	具体的な次元数・対応言語・料金は公式で要確認。日本語適性はユースケースで検証が必要（2026年7月時点）	各公式ドキュメントで要確認
multilingual-e5	オープンな多言語埋め込みモデルで、自前ホスティングやコスト制御がしやすい	最大入力512トークンという上限があり、日本語の長文チャンク設計時に留意が必要（2026年7月時点・モデル仕様は要確認）	NVIDIA 技術ブログ（日本語）

選定の実務軸

埋め込みモデルは「日本語の精度」「トークン上限」「ホスティング形態（API利用か自前運用か）」「コスト」で選びます。日本語主体なら多言語対応モデルや日本語適性の高いモデルを候補にし、必ず自社の質問セットで評価（ステップ7）して相対比較してください。ここでも、選んだモデルの次元数とトークン上限が、ベクトルDBの制約とチャンク設計に矛盾しないかを確認するのが実務のコツです。3つの選択肢はいずれも「これを選べば正解」というものではなく、既存環境と要件次第で最適解が変わります。

精度が出ないときの改善策（検索の取りこぼしか、順位付けか）

回答精度が低いときは、原因を「検索の取りこぼし（recall不足）」なのか「順位付けの問題」なのか、あるいは「生成が文書を活かせていない」のかに切り分けてから打ち手を選ぶのが、遠回りしないコツです。

切り分けの基準になるのが、ステップ7で紹介した評価指標です。Context Recall が低ければ「必要な文書をそもそも取ってこられていない（取りこぼし）」、Context Precision が低ければ「関連の薄い文書が混ざっている（順位付け・絞り込み）」、Faithfulness が低ければ「検索は合っているのに生成が文書を無視している（生成側）」と当たりをつけられます。症状と原因、打ち手を対応させると次のようになります。

症状	推定原因	打ち手	根拠となる指標
必要な文書が検索結果に入ってこない	検索の取りこぼし（recall不足）	ハイブリッド検索の導入、チャンク再設計、取得件数kの見直し	Context Recall の低下
略語・型番・固有名詞で正しく引けない	ベクトル検索だけでは文字一致に弱い	キーワード検索を併用するハイブリッド化（alpha調整）	Context Recall の低下
関連の薄い文書が上位に混ざる	順位付け・絞り込みの問題	re-ranking で上位を再順位付け、取得件数kを絞る	Context Precision の低下
検索は合っているのに回答がずれる／根拠のない断定が出る	生成側の問題（文書を活かせていない）	プロンプトで根拠限定を強化、出典明示を指示	Faithfulness / Answer Relevancy の低下

ハイブリッド検索（ベクトル＋キーワード）

取りこぼしへの主要な打ち手がハイブリッド検索です。Weaviateのハイブリッド検索ドキュメントによれば、ハイブリッド検索はベクトル検索とBM25キーワード検索を並列で実行し、スコアを融合する仕組みです。alpha パラメータ（既定0.5、1に近いほどベクトル重視、0に近いほどキーワード重視）で重み付けを調整できます（2026年7月時点・公式で要確認）。略語や型番のように「文字として一致すべき語」で取りこぼす場合、alpha を下げてキーワード寄りにすると改善することがあります。

re-ranking

順位付けの問題には re-ranking が有効です。一次検索で取得した候補集合を、より精密なモデルで並べ替え、本当に関連する文書を上位に持ち上げます。ここで極めて重要な注意があります。同ドキュメントが示すとおり、re-ranking は「初期検索で取得済みの集合の中で」再順位付けするため、リコール（取りこぼし）そのものは改善しません。つまり、必要な文書が一次検索の候補に入っていなければ、re-ranking をいくら強化しても取りこぼしは埋まりません。取りこぼしにはハイブリッド化やチャンク再設計といった検索段の見直しが必要で、re-ranking は「取れてはいるが順位が低い」場合の打ち手です。この誤解は現場で頻発するため、症状（recall か precision か）を指標で確かめてから打ち手を選んでください。

チャンク再設計

指標を見ても改善が頭打ちなときは、チャンク分割（ステップ2）に戻ります。1チャンクに複数の話題が混ざっていれば検索がぼやけ、細切れすぎれば文脈が失われます。オーバーラップを増やして文脈の連続性を補う、構造ベースの分割に切り替える、といった見直しが効くことがあります。

具体的な切り分けの進め方を、よくある2つの症状で示します。1つ目、「製品の型番で問い合わせても該当マニュアルが出てこない」ケース。これは Context Recall の低下、つまり検索の取りこぼしです。型番のような文字一致が重要な語はベクトル検索が苦手なため、ハイブリッド検索を入れて alpha をキーワード寄りに調整すると改善しやすい典型例です。ここで re-ranking を強化しても、そもそも候補に入っていない文書は上位化できないため効果は出ません。2つ目、「関連はしているが的外れな回答が返る」ケース。検索で必要な文書は取れている（Recall は高い）のに、関連の薄いチャンクが上位に混ざって Context Precision が低い状態です。この場合は re-ranking で上位を並べ替える、取得件数kを絞る、が有効です。このように、まず指標で Recall 側か Precision 側かを見極めてから打ち手を選べば、無駄な作り込みを避けられます。

もう1つ、検索でも生成でもない「データ側」に原因がある症状も知っておくと切り分けが速くなります。典型例が「文書を最新版に更新したのに、古い内容の回答が返ってくる」ケースです。指標を見ると検索も生成も一見正常なのに、返ってくる根拠が古い、という状態です。この原因の多くは、旧版の文書がベクトルDBに残ったまま、新版と一緒に検索候補に上がっていることにあります。内容が似た新旧の文書はベクトル空間上で近接するため、更新日を区別する仕組みがないと、古いチャンクがそのまま上位に混ざります。打ち手は、ステップ1で設計したメタデータが効く場面です。更新日フィルタで最新版だけを検索対象にする、旧版に「廃止」フラグを立てて検索から除外する、更新時に旧チャンクを確実に削除・再ベクトル化する、といったバージョン管理を徹底します。逆に、ステップ1でメタデータや更新日を持たせていないと、この症状はプロンプトや検索パラメータをいくらいじっても解消しません。「古い回答が返る」ときは、まずデータの版管理を疑うのが近道です。

チャンク設計・ハイブリッド化・re-ranking はいずれも独立に試せるため、評価指標を固定して1つずつ変え、効果を測って採否を決めるのが着実です。複数を同時に変えると、どれが効いたか分からなくなり、悪化したときの切り戻しも難しくなります。次に、日本語特有の落とし穴（「日本語RAGでつまずかないための注意点」）も確認してください。

日本語RAGでつまずかないための注意点

日本語RAGでは、日本語に強い埋め込みモデルとre-rankingモデルの選定、そしてトークン上限を踏まえたチャンク設計が精度を大きく左右し、英語向けの設定をそのまま流用すると精度が出にくくなります。

英語の事例をそのまま真似して精度が出ない典型的な原因が、埋め込みモデルの日本語適性です。多言語対応でも日本語での検索精度はモデルにより差があるため、必ず自社の日本語質問セットで評価（ステップ7）して相対比較してください。日本語での精度改善の具体的な手がかりとして、NVIDIAの日本語RAGに関する技術ブログが参考になります。同ブログは、日本語検索データセット JMTEB（nDCG@10）での評価で、二段階検索（まず高速な埋め込み検索で上位候補を取得し、次に精密な re-ranking で上位を絞り込む）を行い、埋め込みモデルに re-ranking モデルを組み合わせることで「さらに3.7ポイントの向上」が見られたと報告しています。ただし、この+3.7ポイントは NVIDIA 社の特定モデル（NV-EmbedQA / NV-RerankQA 系）・JMTEB という特定条件下の結果であり、他のモデルや他のデータでの再現を保証するものではありません。あくまで「日本語でも二段階検索＋re-ranking が精度改善の有力な打ち手になりうる」という方向性の根拠として捉えてください。

日本語で精度が伸び悩む原因は、埋め込みモデルの適性だけではありません。表記ゆれ（全角と半角、カタカナと英字、送り仮名の違い）や、社内固有の略語・製品名が絡むと、意味的には近くても検索で拾いにくくなります。こうした「文字として一致すべき語」が多い日本語のドキュメントでは、ベクトル検索だけに頼らず、キーワード検索を併用するハイブリッド検索が効きやすい傾向があります。用語の表記を前処理の段階で正規化しておく（例：全角英数字を半角に揃える）ことも、地味ですが効果的な打ち手です。

もう1つの日本語特有の注意が、トークン上限とチャンク設計の関係です。多言語埋め込みモデル multilingual-e5 は最大入力512トークンという制約があるとされます（2026年7月時点・モデル仕様は公式で要確認）。日本語は英語に比べて同じ文字数でもトークン数が多くなりやすいため、英語基準のチャンクサイズをそのまま使うと、上限を超えた分が切り捨てられて情報が欠落することがあります。回避策は、使う埋め込みモデルのトークン上限を先に確認し、その範囲に収まるようチャンクサイズを設計すること。つまり、日本語RAGでは「モデル選定（日本語適性・トークン上限）」と「チャンク設計」を切り離さず、セットで詰めることが、つまずかないための最大のポイントです。日本語re-rankingを二段目に足すかどうかも、評価指標を見ながら判断してください。

評価指標の設計（Recall@K・faithfulness・RAGAS）と合否閾値

RAGの評価は、検索精度（Recall@K・MRR）と回答精度・faithfulnessの二層で設計し、RAGASなどの0〜1スコアで合否閾値を決めるのが実務の標準です。この二層構造は、前述のRAG原論文（Lewis et al., 2020）がretrieverとgeneratorを別コンポーネントとして評価する必要性を示したことに由来します。検索段階で正解文書を取れていなければ、生成側をどれだけ改善しても正しい回答は出ません。逆に、検索は正しいのに回答が誤るなら、原因は生成側にあります。層を分けて測ることが、改善の打ち手を特定する唯一の方法です。

検索精度：Recall@K・Precision・MRR

検索層の評価では、「正解の根拠となる文書チャンクが、検索結果の上位K件に含まれているか」を測ります。代表的な指標は次の3つです。

• Recall@K（再現率）：正解チャンクが上位K件に含まれた割合。RAGでは検索結果をそのままLLMに渡すため、ここで取りこぼすと回答は原理的に不可能になります。最も優先すべき指標です。
• Precision（適合率）：検索結果のうち、実際に関連するチャンクの割合。無関係なチャンクが多いと、LLMがノイズに引きずられて回答品質が落ちます。
• MRR（Mean Reciprocal Rank）：正解チャンクが検索結果の何番目に出たかの逆数の平均。正解が1位に出るほど1に近づきます。上位に出るほどLLMが参照しやすいため、順位の質を測る指標として使います。

回答精度とfaithfulness（忠実性）：ハルシネーションの定量化

生成層の評価では、「質問に正しく答えたか（正答率・回答精度）」と「回答が検索した文書に忠実か（faithfulness）」を分けて測ります。この2つは似ているようで別物です。文書に書かれていないことをもっともらしく述べる、いわゆるハルシネーションは、faithfulnessの低下として現れます。回答が結果的に正しくても、根拠が検索文書になければ本番運用ではリスクです。

この評価を体系化したフレームワークがRAGASです。RAGASはLLMを使ってRAGパイプラインを自動評価するオープンソースのフレームワークで、公式ドキュメントでは主要指標として次の4つを定義しています。いずれも0〜1のスコアで表現されるため、PoCや本番前チェックの合否閾値の設定にそのまま使えます。

• Faithfulness（忠実性）：回答に含まれる各主張が、検索されたコンテキストに基づいているか。ハルシネーションの測定に直結します。
• Answer Relevancy（回答関連性）：回答が質問に対して的を射ているか。
• Context Precision（コンテキスト適合率）：検索されたチャンクのうち、関連するものが上位に来ているか。
• Context Recall（コンテキスト再現率）：正解に必要な情報が検索結果に網羅されているか。

前半2つが生成層、後半2つが検索層の指標で、原論文の二層構造ときれいに対応しています。ハルシネーション率は「faithfulnessが閾値未満の回答の割合」として運用上定義するのが実務的です。

各指標をPoCでどう使うか、目安とあわせて整理します。

指標	何を測るか	目安/閾値の考え方
Recall@K	正解チャンクが検索上位K件に入った割合	Recall@5で0.8以上を目安に。未達なら生成改善の前に検索改善を優先
MRR	正解チャンクの検索順位の質	0.7以上が目安。低い場合はリランキングの導入を検討
正答率（回答精度）	評価セットに対し業務上正しい回答を返した割合	人間の一次対応の品質を基準に設定（例：80%以上）
Faithfulness	回答が検索文書に忠実か（ハルシネーション測定）	0.85超を目安に。社外向け用途ならさらに高く設定
Answer Relevancy	回答が質問の意図に沿っているか	0.8前後を目安に
Context Precision / Recall	検索チャンクの関連度・必要情報の網羅	0.8前後を目安に。低い場合はチャンク設計を見直し
レイテンシ	質問から回答表示までの応答時間	用途で設定（対話用途なら3秒以内が一つの基準）

数字の動き方を具体例で見てみましょう。社内規程QAで評価セット50問を流したとします。正解文書が検索上位5件に入った質問が41問なら、検索のヒット率（Recall@5相当）は0.82。回答内容が業務上正しかったのが38問なら正答率76%。回答が参照文書と矛盾しなかった（faithfulnessが基準を満たした）のが46問なら92%です。この結果が意味するのは、「検索はほぼ合格水準、ハルシネーションも管理できているが、正解文書を渡しても回答を誤るケースが数問ある」という状態で、次の打ち手はプロンプト改善か生成モデルの変更だと絞り込めます。3つの数字を並べて初めて、どこに手を入れるべきかが読めるわけです。

閾値はあくまで出発点であり、用途のリスクに応じて調整します。業務クリティカル度で基準を変えるのが原則で、社内ヘルプデスクの一次回答なら正答率80%でも工数削減効果は出ますが、顧客向け回答や規程の解釈・金額に関わる用途なら、faithfulness 0.9以上・致命的誤回答ゼロといった厳しい基準に引き上げ、かつ人間の確認を挟む運用を前提にすべきです。また、指標の平均値だけを見るのは危険です。平均正答率85%の裏で、特定の文書群（例えば経理規程）に関する質問だけ正答率が4割、というケースは珍しくありません。評価結果は必ず質問カテゴリ別に分解して確認し、「どの領域なら本番投入できるか」を面で判断してください。

RAGASのようなLLMを評価者として使う自動評価には、実務上の注意点もあります。評価用LLMの判定は人間の判断と概ね相関しますが、完全ではありません。運用の定石は、自動評価でスクリーニングしつつ、スコアが閾値付近の回答と重要カテゴリの回答は人間がサンプリングレビューする二段構えです。自動評価だけで合否を確定させず、最終判断には必ず業務担当者の目を通す。この一手間が、数字上は合格なのに現場で使われないシステムを防ぎます。

もう一つ、評価設計に含めておきたいのが出典トレーサビリティです。Google CloudのVertex AI RAG Engineのドキュメントでは、回答生成時に参照した文書チャンクやページを構造化して返すgrounding（グラウンディング）の仕組みが解説されています。回答の各文がどの文書に基づくかを機械的に検証できる設計にしておくと、faithfulness評価の自動化が容易になるだけでなく、本番運用で「なぜその回答になったのか」を説明する監査要件にも応えられます。

評価セット（ゴールデンデータ100〜200件）の作り方

指標を計算するには、正解付きの評価セットが必要です。作り方の要点は4つあります。

第一に、質問は実際の業務から採ること。問い合わせログ、メール、チャット履歴から実際の言い回しのまま収集します。担当者が頭で考えた「きれいな質問」だけで作ると、本番投入後に精度が急落します。

第二に、難易度を混ぜること。単一文書で答えられる質問6割、複数文書をまたぐ質問2〜3割、対象文書に答えが存在しない質問1〜2割、が一つの目安です。「答えがない質問に『わからない』と言えるか」は、ハルシネーション耐性を測る上で欠かせません。

第三に、正解には根拠文書の箇所まで記録すること。回答テキストだけでなく「どの文書のどの節が根拠か」を残すことで、検索層の指標（Recall@K）が計算可能になります。

第四に、規模は100〜200件を目標にすること。MicrosoftのRAG設計・評価ガイドでも、この規模の質問-回答ペアによるオフライン評価が推奨されています。50件未満だと設定変更の効果が誤差に埋もれ、チューニングの判断がつきません。

作成した評価セットは、PoC限りの使い捨てにしないでください。本番化後の回帰テスト（モデルや文書を更新した際の品質劣化チェック）にそのまま流用でき、運用フェーズの品質基盤になります。だからこそ、外注時には評価セットを成果物として納品対象に含める契約にしておくことが重要です。評価セットが外注先の手元にしか残らないと、ベンダーを変えるたびに評価基準がリセットされ、過去との品質比較ができなくなります。

評価は一度きりではなく、本番運用後も継続的に回す仕組みに育てていくものです。運用後のモニタリング設計まで視野に入れるならLLMOpsの実践ガイド、検索精度を上げる具体的な技法（ハイブリッド検索・リランキング等）はRAGの精度改善テクニック集が次の一歩として役立ちます。

本番化のゴー/ノーゴー判断（PoCから先へ進めてよいか）

本番化の判断は、faithfulnessやレイテンシ等の閾値クリアに加え、運用コスト試算・出典トレーサビリティ・セキュリティ審査の充足で決めます。「精度が良さそうだから本番へ」という感覚的な判断が、PoC止まりと本番後の炎上の両方を生みます。判断は二段階で設計します。

第一段階：PoCの合否判定（技術検証のクリア）

ステップ7で作った評価セットに対する実測値を、事前に合意した閾値と突き合わせます。判定例は次のような形です。

• Recall@5 ≧ 0.8（検索が正解文書を拾えている）
• faithfulness 0.85超（回答が文書に忠実で、ハルシネーションが管理可能な水準）
• 正答率 ≧ 80%（業務上使える回答品質）
• レイテンシ 3秒未満（利用者が待てる応答速度）

すべて満たせば合格、一部未達なら「どの層の問題か」を特定した上で改善ループに戻ります。判定は白黒の二択にせず、「条件付きゴー」を用意しておくと実務では機能しやすくなります。たとえば「全体では基準未達だが、申請手順カテゴリに限れば正答率9割を超える」なら、対象範囲を絞って本番化し、残りは文書整備後に拡張する、という段階的な進め方が取れます。全カテゴリ一括の合否にこだわると、部分的には十分実用的な成果まで捨てることになります。

ここでもう一つ重要なのは改善ループの回数上限を決めておくことです。「あと2週間の追加チューニングで未達なら中止」といった撤退条件を先に決めておかないと、PoCは際限なく延びます。中止の判断は失敗ではありません。数百万円のPoCで「この用途には現時点で投資すべきでない」と分かることは、数千万円の本開発で同じ結論に至るより遥かに安上がりです。

第二段階：本番化のゴー/ノーゴー判定（運用条件のクリア）

技術検証をクリアしても、本番化にはPoCでは問われなかった条件が加わります。チェックすべきは次の5点です。

1. 検索アーキテクチャの本番耐性。PoCで単純なベクトル検索のみを使った場合、本番の多様なクエリで品質が落ちることがあります。MicrosoftのAzure AI SearchのRAG解説では、エンタープライズRAGの構成としてキーワード検索とベクトル検索を統合するハイブリッド検索や、検索結果を再順位付けするセマンティックランキングの役割が示されています。PoC構成と本番構成の差分を明文化し、追加開発の規模を見積もります。

2. インデックス更新の設計。PoCは静的な文書スナップショットで動きますが、本番では文書が日々更新されます。夜間バッチでの再インデックスで足りるのか、即時反映が必要なのか。更新頻度の要件は運用コストに直結します。

3. 出典トレーサビリティ。回答の根拠文書を利用者に提示できるか。前述のVertex AI RAG Engineのgroundingのような出典付与の仕組みは、利用者の信頼獲得と誤回答時の検証可能性の両方に効きます。社外向けや判断支援の用途では実質必須と考えるべきです。

4. セキュリティ・権限の審査。文書のアクセス権限を回答に反映できるか、データの保管場所と外部送信は社内規程を満たすか、情報セキュリティ部門の審査を通過できるか。ここは技術より調整に時間がかかるため、ゴー判定の前に審査プロセスを開始しておくのが賢明です。

5. 運用コストとROIの試算。本番の想定利用量でのAPI利用料・インフラ費・運用工数（精度モニタリング・文書メンテナンス）を月額換算し、後述の費用の章で整理する業務コスト削減額と比較します。精度が合格でも、運用コストが削減効果を上回るならノーゴーです。

判定会議でそのまま使えるよう、ゴー/ノーゴーの確認項目をチェックリストにまとめます。

• 事前合意した評価指標（検索・回答・忠実性・応答速度）がすべて閾値を満たしている
• 致命的な誤回答（存在しない条文の引用・旧版文書での回答など）がゼロ件である
• 本番想定の利用量でのランニングコスト試算が、削減効果と見合っている
• インデックス更新（文書の追加・改定への追従）の運用体制と担当が決まっている
• アクセス権限・機密区分の制御方針が情報セキュリティ部門と合意できている
• 回答の根拠文書を利用者に提示できる（出典トレーサビリティがある）
• PoC構成と本番構成の差分と、その追加開発費の概算が文書化されている
• 精度が劣化したときの検知方法と対応フロー（誰が・何を見て・どう直すか）がある

一部の指標だけ未達のグレーゾーンでは、「中止か全面ゴーか」の二択にしないことが重要です。取れる選択肢は3つあります。第一に限定リリース：合格水準に達したカテゴリ・部署だけで本番運用を始め、実利用ログで残りを改善する。第二に対象文書の絞り込み：精度を崩している文書群（旧版混在のフォルダ等）を検索対象から外し、範囲を狭めて基準クリアを狙う。第三に再PoC：チャンク設計や埋め込みモデルなど根本の構成を変えて短期の再検証を回す。ただし再PoCは撤退条件（回数・期限）とセットでなければ、ずるずると延命するだけになります。

判定の場の運営にも一工夫が要ります。合否判定会議には、技術メンバーだけでなく、業務側の責任者・情報セキュリティ担当・予算権限者を最初から同席させてください。技術チームだけで「合格」と結論づけた後に各部門を個別説得して回る進め方は、それぞれの部門が新しい懸念を持ち出すたびに議論が振り出しに戻ります。判定材料（実測値・コスト試算・差分リスト・リスクと対策）を1つの資料にまとめ、一度の場で意思決定する。この段取りが本番化までの期間を数ヶ月単位で縮めます。

この二段階をクリアして初めて本番開発の投資判断ができます。移行計画の立て方はPoCから本番化への移行ガイド、全社展開のステップ設計はAI導入の進め方ガイドで詳しく解説しています。

RAG構築の費用の考え方と、内製すべきか外注すべきか

RAG構築には公式が定めた標準価格は存在せず、費用はデータ量・要件・運用監視の作り込みで大きく変わる案件依存です。だからこそ「いくら」を先に問うのではなく、評価指標を握って段階的に発注・検収する進め方が、コスト超過と精度未達を避ける近道になります。

費用を決める要素

費用に効く主な要素は、対象データの量と種類（PDF・スキャン文書が多いほど前処理が重い）、要求精度（どこまで評価指標を追い込むか）、ハイブリッド検索やre-rankingなど検索段の作り込み、日本語対応の作り込み、そして本番の運用・監視・更新の仕組みです。同じ「RAGを作る」でも、社内の小さなFAQ検索と、全社の機密文書を扱う本番システムでは、必要な工数もセキュリティ要件も桁が違います。加えて見落とされやすいのが、構築後の継続コストです。埋め込みやLLMのAPI利用料、ベクトルDBのホスティング費用、文書が更新されるたびの再ベクトル化、精度を維持するための評価・監視の手間は、作った後もかかり続けます。初期構築費だけでなく、この運用フェーズのコストまで含めて見積もることが、後からの予算超過を防ぐ鍵になります。市場相場を一律に語ることには無理があるため、本記事では具体的な金額・人月・期間を断定しません。相場観の整理にはAI受託開発の料金ガイドを、内製と外注を3年程度のTCO（総保有コスト）で比べたい場合はAI内製化とAI外注の比較を参照してください。

内製が向くケース

内製と外注は、次の観点で判断します。

観点	内製が向くケース	外注が向くケース
スピード	社内にLLM・検索の実装経験があり、すぐ着手できる	実装リソースが不足し、着手が遅れる／期限が厳しい
社内知見	継続的にRAGを改善・横展開する予定で、知見を内部に貯めたい	単発・短期で仕上げたい、または専門知見を早く取り込みたい
コスト構造	継続運用が前提で、長期の人件費として抱える方が合理的	初期構築を切り出し、変動費として発注したい
運用・監視	監視・再学習・文書更新を自社で回せる体制がある	運用設計や監視の型を外部から取り入れたい
精度の握り方	評価指標を自社で回し、改善を主導できる	評価指標を発注側が握り、成果物を指標で検収したい

社内に実装経験があり、RAGを継続的に改善・横展開していきたいなら、知見を内部に蓄積できる内製が向きます。評価指標（RAGAS）を自社で回せることは、内製・外注いずれでも強力な武器になります。逆に、まだ社内に検索・LLMの実装経験がなく、最初の一件を確実に立ち上げたい段階では、外部の知見を借りつつ、その過程で評価や運用の型を自社に取り込むという折衷も現実的です。内製か外注かは白黒で決めきる必要はなく、「PoCは外部と一緒に、運用は内製で」といった役割分担も選択肢になります。

外注（受託開発）が向くケースと発注の勘所

一方、実装リソースが足りない、期限が厳しい、専門知見を早く取り込みたい、といった場合は外注（受託開発）が向きます。外注で失敗しないための勘所は「一括で丸投げしない」ことです。RAGは前処理・チャンク分割・埋め込み・検索・生成・評価と部品ごとに切り分けられるため、まず小規模データでPoCを回し、評価指標で検索・生成の弱点を特定してから本番規模へ拡張する、という段階発注が有効です。このとき、評価指標（RAGASの4指標など）を発注側が握り、「Context Recall と Faithfulness がこの水準を満たすこと」といった検収基準を発注側で定義しておくと、成果物を感覚でなく数値で評価でき、精度未達の押し付け合いを避けられます。あわせて、発注時には「動くシステム」だけでなく、後から自社で改善・保守できる資産を成果物として明記して残しておくことが重要です。具体的には、検収の基準にもなるテスト質問セット、その質問セットに対する評価スコア（RAGASの4指標など）、そしてチャンク分割や検索の設計判断を記録した設計ドキュメントの3点は、発注側の資産として引き渡しを求めておくべきです。これらが手元に残っていれば、運用を内製へ切り替えるときも、別のベンダーへ乗り換えるときも、なぜその設計にしたのかを引き継げ、改善の再現性が保てます。逆にこれらを握らずにシステムだけ納品させると、精度が落ちたときに原因を追えず、結局同じベンダーに依存し続けることになりがちです。受託開発の進め方や依頼先の見極め方はAI受託開発の進め方・依頼先の選び方に詳しくまとめています。

「ベクトルDB選定やチャンク設計まで要件には落ちているが実装リソースが足りない」「PoCの精度が出ず、検索と生成のどちらが原因かを一緒に切り分けてほしい」といった状況なら、要件を持ち込んでの相談が有効です。具体的な構築や外注の相談はお問い合わせ窓口（/contact）から進められます。

まだ相談しなくてよい人もいます。この記事の7ステップをまだ試しておらず、小規模PoCで自分の手を動かせる段階の人は、まず自前で一周してみるほうが、要件も費用感も具体化します。逆に、PoCで精度の壁に当たっている・本番規模のセキュリティや運用まで見据える必要がある・社内に実装リソースがない、という人は、早めに相談したほうが遠回りを避けられます。次は、自分の状況に合わせた優先順位を早見表で確認してください。

あなたの状況別・次にやること早見表

「結局いまの自分は何を優先し、次にどこを読めばいいのか」を、状況別に一枚に整理しました。自分に近い行を起点に、次のアクションへ進んでください。

あなたの状況	まず優先すること	根拠（本記事の該当箇所）	次のアクション	参考リンク／相談
まず概念を掴みたい	RAGの定義と検索・生成の2段構えを理解する	「全体像」と「仕組み」の章	仕組みを押さえたら実装7ステップへ	本記事の該当セクション
小規模で試したい（PoC）	7ステップを小規模データで一周し評価まで回す	「実装7ステップ」（特にステップ7の評価）	評価指標を回してから本番規模を検討	PoCから本番運用への進め方
精度が出ない	取りこぼしか順位付けかを指標で切り分ける	「精度が出ないときの改善策」の切り分け表	Context Recall/Precisionを見て打ち手を選ぶ	本記事の該当セクション／AIエージェントの作り方
日本語で精度が出ない	日本語適性のモデル選定とトークン上限に合わせたチャンク設計	「日本語RAGでつまずかないための注意点」	二段階検索＋re-rankingを評価で試す	本記事の該当セクション
費用・体制を決めたい	内製か外注かを判断軸表で整理し、評価指標を握る	「費用の考え方と内製・外注の判断」	段階発注・検収の作法を決める	AI受託開発の進め方・依頼先の選び方
外注先を選びたい	評価指標で検収できる依頼先か見極める	「外注が向くケースと発注の勘所」	候補を比較して相談する	AI開発会社の比較（2026年版）／お問い合わせ

RAG構築に関するよくある質問（FAQ）

関連記事と読み分け

この記事は、自社でRAGを作りたい実装者と、外注すべきか判断したい発注担当に向いています。データ準備から評価・精度改善・費用と外注判断までを一気通貫で確認したい人には、そのまま使える内容です。一方で、隣接するテーマは別の記事のほうが詳しく読み分けられます。

RAGを含むAIエージェント全体の作り方を知りたいならAIエージェントの作り方が向いています。社内のQ&Aをチャットボットとして提供したい場合はAIチャットボット完全ガイドを、コーディング作業そのものをAIエージェントに委ねたい場合はAIエージェントにコーディングを任せる方法をあわせて読むのがおすすめです。逆に、これらのテーマが主目的なら、本記事のRAG構築部分だけを部品として参照し、全体像は各記事で押さえると効率的です。外注先の比較検討まで進みたい人はAI開発会社の比較（2026年版）へ進んでください。

読者への補足: 本記事は2026年7月13日に更新し、同時点までに確認できた情報に基づいています。RAGの原理は原著論文（Lewis et al., 2020）、埋め込み・チャンク・評価・ベクトルDB・日本語検索の各記述はOpenAI・LangChain・Ragas・Pinecone・pgvector・Weaviate・NVIDIAの公式ドキュメントや技術ブログといった一次情報に基づいており、記載の数値・仕様・料金（次元数・トークン上限・pgvectorの2000次元上限やパラメータ、alpha値、NVIDIAの+3.7ポイントなど）は執筆時点のもので、いずれも公式での最終確認を推奨します。内容はファクトチェックと編集レビューを経ています。具体的な構築や外注のご相談は問い合わせ窓口（/contact）からお寄せください。