RAG構築の手順 — 「1日でできる最小構成」と本番品質の間を、4層で埋める

RAG（Retrieval-Augmented Generation＝検索拡張生成）を「とりあえず動く」ところまで作るのは、もう難しいことではありません。フレームワークのチュートリアルに沿えば、手元の文書に答えるチャットは1日で立ち上がります。私たちも最初の一歩はそこからでした。

問題は、そこから業務で「使える」までの距離です。デモを見た現場が期待して使い始め、普段どおりの質問を投げた途端に外し始める——この間には、チュートリアルが扱わない工程がいくつも挟まっています。この記事では、私たちが実案件で繰り返してきたRAG構築の手順を、「何から作り、どの順で測るか」という実務の順番で書きます。個別の工程の深掘りは各記事に譲り、ここでは全体の設計図を示します。

構築の全体像 — モデル選定から始めない

RAG構築というとモデルやフレームワークの選定から入りたくなりますが、精度を決めるのはそこではありません。私たちの経験では、本番の精度はデータの質、検索の設計、評価の仕組み、運用の体制の順に効きます。モデルの差が効いてくるのは、この4層が整ってからです。

手順に入る前に、「そもそも何を揃えれば動くのか」という環境構築の部品を先に並べておきます。

RAG構築に必要なもの — 環境構築の部品表

RAGの環境構築で揃える部品は、突き詰めると6つです。

環境構築そのものは、ここに挙げた部品を繋ぐだけなら難所ではありません。検索基盤も、専用のベクトルDBを新規に立てるより、既に社内にあるPostgreSQLやElasticsearchを土台にできないかを先に考えます（運用に慣れた基盤のほうが本番で壊れにくいからです）。

注意してほしいのは、6つのうち評価ハーネスだけは既製品で済まないことが多い、という点です。質問セットは自社の業務からしか作れず、ここが後述するすべての手順の物差しになります。部品選びに時間を使うより、この物差し作り——ここから先の手順0〜5——に時間を使うほうが、本番の精度には効きます。

順に見ていきます。

手順0: 「何に答えられれば合格か」を先に決める

最初に作るのはコードではなく、合格の定義です。対象の文書群を絞り、「この質問に答えられれば業務で使える」という質問を現場から集める。私たちは商社の文書検索案件で、業務シナリオに沿った49問の評価セットを起点にしました。この最初の質問集めが、後のすべての工程の物差しになります。

ここを飛ばすと、改善が「なんとなく良くなった気がする」の繰り返しになります。逆に言えば、質問セットさえあれば、構築は「外している質問を減らす作業」という測れる仕事に変わります。

手順1: データ整備 — 精度の土台で、一番地味な工程

固定長で機械的に切らず、文書の構造（条文・見出し・表）に沿って分割する。どの版が最新かをメタデータで持つ。廃止された規程や古い版を検索対象から外す。——派手さのない工程ですが、私たちの経験では精度への効きが最も大きい層です。ここで手を抜くと、後段の検索や生成をどれだけ工夫しても、壊れた素材から正しい答えは出ません。詳細はチャンク設計とデータ整備に書きました。

手順2: 検索設計 — キーワードとベクトルを最初から並走させる

業務文書を相手にするなら、検索はキーワード検索（BM25）とベクトル検索を最初から並走させ、統合した候補をリランキングで並べ直す形から始めます。固有名詞や型番の取りこぼしはベクトル検索の性質上どうしても起き、その限界は理論でも示されています（Weller et al., ICLR 2026）。一方でBM25は言い換えに弱いので、どちらか一方では足りません。記号の正規化や略称の展開のような一意に決まる処理は、LLMではなく辞書とルールで先に解く。決まりきった処理をルール側へ寄せておくほど、検索の土台はぐらつきません。設計の詳細と、足切りの値の決め方はハイブリッド検索の設計へ。

その前に、問いと知識の形を見て、そもそも文書を検索する作りでよいかを決めます。

件数や合計を文書検索で答えようとすると、もっともらしい数字で外します。LLMにSQLを書かせるより、セマンティックレイヤーを通してLLMには選ばせるだけにしたほうが正答率が上がったという比較もあります（dbt Labs, 2026）。Graph RAGは、多段の推論や全体の要約を問う質問では通常のRAGに勝つ一方、単純な事実を引く質問では通常のRAGが同等以上だったと報告されています（Xiang et al., ICLR 2026）。検索結果を見て問い直しが要る業務ならAgentic化——ここから先は、文書と症状に応じた系統選びになります。どこまで必要かの見立ては診断ガイドの系統選びにまとめています。

手順3: 生成 — 出典を示し、「無い」と言える設計に

生成側で最初に固めるのは、答えの正しさより答え方です。回答には必ず出典（どの文書のどの箇所か）を付ける。検索結果に根拠が無ければ、それらしく埋めずに「見つからなかった」と返す。この2つが守られているだけで、現場からの信頼は大きく変わります。うまく答えた1問より、堂々と間違えた1問のほうが強く記憶されるからです。

この2つを、LLMへのお願いではなく仕組みで守ります。私たちの原則は「LLMは選ぶだけ・作らない」です。答えの候補を一覧にできる業務なら、LLMには候補の中から答えを番号で選ばせ、選択肢の外を返せないよう出力の形を縛り、回答文は選ばれた原文からプログラムで組み立てます。主要なLLMのAPIには、出力をJSONスキーマどおりの形に縛る構造化出力の機能が揃いました（Claudeは2026年1月に正式提供）。ただし保証されるのは形で、中身の正しさではないので、選ばれた番号が実在するかといった確認は残します。

文書のチャンクを根拠に文章で答える作りでは、次の3つを入れます。

• 答える前に、根拠が足りるかを判定する。 根拠が足りない文脈を渡すと、モデルは断らずに誤答しやすくなります。公開モデルのGemmaでは、文脈なしで10.2%だった誤答が、不十分な文脈を渡すと66.1%に増えました（Joren et al., ICLR 2025）。足りなければ、検索し直すか、聞き返すか、断ります。断りの判定には、類似度ではなくリランキングのスコアを使います。
• 出典はAPIの引用機能で返す。 回答の根拠となった原文を文書から抜き出して返す機能を使うと、引用が文書の実在する箇所を指すことが保証されます（Anthropic Citations）。回答文の中の番号を後から拾う作りより壊れません。
• 根拠の無い文を後から落とす。 回答のうち根拠に支えられていない箇所を印す小型の検出器があり（Kovács & Recski, 2025）、数値が根拠の原文に含まれているかの機械的な確認と組み合わせて使えます。

手順4: 評価 — 「測れる状態」を作ってから改善を回す

手順0で集めた質問セットを、自動で回せる評価にします。要点は検索と生成を分けて測ること。正解文書が上位に入っているか（検索）と、入っていたときに正しく答えられたか（生成）は別の故障なので、混ぜて測ると打ち手を誤ります。検索は、正解の文書が上位k件に入った割合（recall@k）をルールで自動採点し、キーワード検索だけ・ベクトル検索だけ・リランキング後と経路別に出します。決定的に採点できる項目はルールで、文章の質のような曖昧な項目だけLLM-as-a-Judgeと人手で。LLMの採点役は並び順や言い回しで判定が揺れるので、人の判定と突き合わせて較正してから使います。作り方は評価セットの設計に書きました。

改善を回すときは、上流から見て、一度に1か所だけ変えます。読み取り→検索→生成の順に、最初に外れた層を原因として数え、変えたら質問の種類ごとの前後差を全部見る。ある種類が上がって別の種類が下がる、という動きを見逃さないためです。商社の案件で正答率を38.8%から93.6%まで運べたのは、この物差しがあって、外した質問を層ごとに潰していけたからです。先に作り込んで後から測る逆順だと、どの改善が効いたのか分からなくなります。

手順5: 運用 — 人間監査から始めて、卒業する

本番投入の初期は、AIの回答を人が確認してから使う（human-in-the-loop）体制で始めます。これは暫定の妥協ではなく、設計の一部です。監査の記録が貯まり、評価セット上で品質が基準を満たし続けたら、監査を段階的に外し、利用ログからのフィードバックが自動で回る状態へ移行する。この「監査の卒業」までを最初から設計しておくと、運用コストが線形に増え続けるのを防げます。新しい文書が出たら誰がいつ取り込むかという更新フローも、この段階で決めます。

部品を入れ替えるときの手順も、この段階で決めておきます。埋め込みモデルや切り方を替えたら、足切りの値を評価セットで引き直し、質問の種類ごとの前後差を確かめてから本番に出す。アプリと推論サーバーが同じモデル名・版を指しているかは、起動時に照合します。旧モデルの足切りの値を据え置くと、関係のない質問にまで答えや案内が出るようになります。

安全の前提も1つ置きます。取り込む文書は、社外の人が書けるものとして扱うことです。2025年には、細工したメール1通を取り込ませるだけで、利用者が何も操作しなくても社内データを外へ送れる経路が業務用のAIアシスタントに見つかりました（EchoLeak。提供元がサービス側で修正済みで、悪用の報告はありません。NVD）。回答を返すだけのRAGには、外部へデータを送る経路（画像URLの自動読み込み・リンクの展開・書き込みのできるツール）を持たせず、閲覧権限は検索の段で絞ります。

どこまで作り込むか — 過剰設計の回避

構築ガイドの締めとして逆向きのことを言いますが、全部を作り込む必要はありません。参照関係のない文書にGraphを重ねても、効果のないまま構成だけが複雑になります。判断の順番は「症状が出てから、その症状に効く系統を足す」。検索をやり直すAgentic化を足すときは、呼び出し回数の上限・予算・「根拠が足りたか」の判定という止まる条件を一緒に決めます。過剰設計は精度ではなく、保守コストに跳ね返ります。

よくある質問

RAGの構築期間はどれくらいかかりますか。

「とりあえず動く」までなら1日、デモとして見せられる形でも数日です。時間がかかるのはそこからで、業務で使える精度までの距離は、対象文書の状態（構造の有無・版の整理）と合格ラインの高さで大きく変わります。だからこそ、期間を見積もる前に手順0の「何に答えられれば合格か」を決めることをすすめています——ここが決まると、残りの距離が測れるようになります。

LangChainやLlamaIndexのようなフレームワークは使うべきですか。

立ち上げには有効です。ただ、本番で精度を詰める段階になると、チャンク分割・検索・評価は結局自分たちで設計を握ることになります。フレームワークの既定値のまま精度が出ないと悩んでいる相談は多く、既定の文字数ベースの機械的な分割——文書構造を見ない分割——が原因だったというのが典型です。薄く使い、要所は自前で持つ、が私たちの使い方です。ノーコードのDifyで作った場合も考え方は同じで、どこまでDifyの設定で直り、どこから外に出すかはDifyでRAGの精度が出ないときに書きました。

ベクトルDBは何を選べばよいですか。

まず、すでに社内で運用しているものに乗れないかを考えます。PostgreSQLがあればpgvector＋全文検索、Elasticsearch / OpenSearchがあればそのまま両用できます。PostgreSQLの場合は2点を確かめます。1つは、日本語の全文検索の拡張には採点がBM25でないものがあることです（PGroongaのスコアは語の出現回数だけ）。もう1点はpgvectorの版です。0.8.3と0.8.4（2026年6月）で、HNSWインデックスのVACUUMまわりの不具合（インデックスが壊れうる問題を含む）が直されました。0.8.4より前の版でHNSWと定期的なVACUUMを使っているなら、更新を優先してください（pgvector CHANGELOG）。専用のベクトルDBを検討するのは、規模や性能要件でそれらが苦しくなってからで遅くありません。基盤選びより、ハイブリッド構成と評価の設計のほうが精度への効きは大きいです。

埋め込みモデルは何を選べばよいですか。

候補は3種類から1〜2本ずつ取ります。日本語に特化した小型のもの（ruri-v3など）、多言語の小型のもの（EmbeddingGemma、graniteの多言語版など）、LLMを土台にした大きめのもの（Qwen3-Embeddingなど）です。そのうえで、自社の評価セットで正解の文書を拾えた割合を比べて決めます。公開ベンチマークの数字は、表が違えば同じモデルでも値が変わり、ベンチマークを替えると順位も入れ替わるので、別々の表の数字を並べて比べません。ライセンスも選ぶ軸です。日本語の評価でスコアの高いモデルにも、商用利用できないライセンス（非商用限定）のものがあります。

長い文章を読めるLLMなら、全部読ませればRAGは要らないのではありませんか。

100万トークン級の文脈を扱えるモデルが主要な各社から出ましたが、読める長さと、読み落とさない長さは別です。文脈が長くなるほど精度が不安定になることが、多くのモデルで確かめられています（Chroma, 2025）。RAGと長文脈のどちらが勝つかは文書の種類や長さ・モデルで変わり、決まった答えはありません（Li et al., 2025）。少量で固定の知識は全部を載せ、それ以外は必要な箇所を検索して渡す、を基本に、両方を同じ評価セットで測って決めます。

社内にAI人材がいなくても構築できますか。

モデルの知識より、対象文書と業務を知っていることのほうが重要です。手順0の質問集めと手順1のデータ整備は、業務を知る人にしかできません。逆に、そこさえ社内で持てれば、検索や評価の設計は外部の実装者と組む形で補えます。全部を外に投げると、物差し（評価セット）が業務とずれたまま進むリスクが残ります。

構築チェックリスト

• 「この質問に答えられれば合格」という質問セットを、コードより先に作ったか。
• 問いと知識の形を見て、検索・全件をプロンプトに載せる・セマンティックレイヤーのどれで答えるかを決めたか。
• 文書の構造に沿った分割・メタデータ・版の整理ができているか。
• 固有名詞・型番の一致をキーワード検索（BM25）で押さえ、リランキングで並べ直しているか。一意な処理をルールで先に解いているか。
• 回答に出典が付き、根拠が足りないときは「無い」と言えるか。LLMに書かせる範囲を、選ばせる範囲まで狭められないか。
• 検索と生成を分けて測る評価が、自動で回るか。一度に1か所だけ変えているか。
• 部品を替えたときに足切りの値を引き直す手順と、文書更新のフローを決めたか。
• 人間監査から始めて「卒業」するまでの道筋を決めたか。

最小構成と本番品質の間を、一緒に埋めませんか

チュートリアルと本番の間にある4層は、どれも特別な発明ではなく、順番どおりに積めば届く工程です。いまどの手順で止まっているかを聞かせていただければ、次に積むべき層をお伝えします。この手順で実際に数字が動いた記録は商社の文書検索事例にあります。

参考文献

• Lewis et al. (2020) Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS — arXiv:2005.11401
• Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997
• Weller et al. (2025) On the Theoretical Limitations of Embedding-Based Retrieval, ICLR 2026 — arXiv:2508.21038
• Xiang et al. (2025) When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation, ICLR 2026 — arXiv:2506.05690
• dbt Labs (2026) Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update — docs.getdbt.com
• Joren et al. (2024) Sufficient Context: A New Lens on Retrieval Augmented Generation Systems, ICLR 2025 — arXiv:2411.06037
• Kovács & Recski (2025) LettuceDetect: A Hallucination Detection Framework for RAG Applications — arXiv:2502.17125
• Anthropic, Citations（Claude Docs） — platform.claude.com
• Anthropic, Claude Platform Release notes（構造化出力の正式提供） — platform.claude.com
• NVD, CVE-2025-32711（EchoLeak） — nvd.nist.gov
• Chroma (2025) Context Rot: How Increasing Input Tokens Impacts LLM Performance — trychroma.com
• Li et al. (2025) LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs — No Silver Bullet for LC or RAG Routing — arXiv:2502.09977
• pgvector CHANGELOG — github.com

この記事は、AIツールを活用して作成し、Cognisant 工藤大地がファクトチェック・編集・監修を行っています。事例の数値はすべて公開済みの実案件既出値です。