RAG構築の手順とは？構成要素・精度評価・失敗回避を実務で解説

RAG構築とは何か、なぜ生成AIの社内活用に必要？

RAGは検索と生成を分けて、社内文書を根拠に回答させる設計です。ハルシネーションの抑制と情報の鮮度の確保に効果があります。

RAG構築とは、社内に散らばる文書を検索し、その結果を生成AIに渡して根拠付きで回答させる仕組みを設計・運用することです。AX（AI Transformation）の実装フェーズでは、RAGは「汎用の生成AI」を「自社の業務知識で答えるAI」に変える中核の部品にあたります。

RAGは「検索」と「生成」を分離する設計思想

RAGの本質は、知識をモデルの内部に持たせず外部の検索層に置き、生成時にプロンプトへ注入する点にあります。

RAG（Retrieval-Augmented Generation）は、Meta AI（当時のFacebook AI Research）のPatrick Lewisらが2020年のNeurIPSで発表した論文で提示された手法です。当時は研究上の枠組みでしたが、現在では企業の生成AI活用で事実上の標準構成になっています。

処理は大きく2段階に分かれます。

• 第1段階（検索）：ユーザーの質問に関連する社内文書の断片（チャンク）を検索して取り出す
• 第2段階（生成）：取り出した断片をプロンプトに埋め込み、LLM（大規模言語モデル）に「この情報だけを根拠に答えよ」と指示する

このように分けることで、モデルを再学習させずに知識を差し替えられる構造になります。

ファインチューニングではなくRAGを選ぶ判断基準は？

知識の追加・更新が目的ならRAG、出力形式や文体の矯正が目的ならファインチューニングが向いています。両者は役割が違います。

両者は競合する手法ではありません。実務では次の判断軸で使い分けるのが現実的です。

社内規程やFAQ、製品仕様のように「更新され続ける知識」を扱う場合、知識を学習済みの重みに埋め込む方法では運用が破綻しやすくなります。この点で、RAGはAX推進の初期投資として回収しやすい選択肢です。

AX推進でRAGが最初の一手になる理由

RAGは既存の文書資産をそのまま使え、整備した検索基盤をAIエージェントに再利用できるため、AXの最初の一手に適しています。

現場でヒアリングすると、「AIエージェントを導入したい」という要望の裏にある本当の課題が、「社内のどこに正しい情報があるか分からない」という探索コストであることは少なくありません。RAGはこの探索コストに直接効きます。

また、RAGで整備した検索基盤は、その後のAIエージェント構築で「ツール」としてそのまま再利用できます。段階的に投資しても無駄になりにくいのが特徴です。

RAGの全体像と構成要素は？

RAGはインジェスト・リトリーバル・ジェネレーションの3層で構成され、回答精度の大半はリトリーバル層で決まります。

インジェスト層：文書を検索可能な形に整える

インジェスト層は、PDFやスライドをテキスト化し、意味のまとまりで分割して埋め込みベクトルに変換する工程です。

ここでの設計判断が、後の工程の精度の上限を決めます。主な論点は次の3つです。

1. パース（構造抽出）：PDFの表やスライドのレイアウトを崩さずにテキスト化できるか。日本企業では仕様書や稟議資料が表形式のPDFやExcelで蓄積されていることが多く、この工程で情報が抜け落ちると後から取り戻せません。
2. チャンク分割：一般的には数百トークン程度の粒度が目安です。ただし、条文単位の契約書と時系列の議事録では最適な切り方が異なります。見出しの階層に沿って分ける構造的チャンキングは、多くの場合、固定長の分割より安定します。
3. メタデータ付与：文書種別、部門、作成日、公開範囲をチャンクに付けておくと、後述する権限フィルタや、新しい情報を優先する絞り込みができるようになります。

実務では、メタデータを後から付けると想像以上にコストがかかります。インジェストの設計時点で、少なくとも「誰が見てよい情報か」と「いつの情報か」の2軸は必ず持たせておくことをおすすめします。

リトリーバル層：検索精度を決める中核

リトリーバル層は、ベクトル検索とキーワード検索のハイブリッド検索に、リランクを重ねる二段構えが実務の標準解です。

ハイブリッド検索では、両方のスコアをそのまま足すのではなく、順位をもとに統合するRRF（Reciprocal Rank Fusion）を使う実装が広く採用されています。スコアの尺度が違う検索手法でも安全に統合できるためです。

統合した上位20〜50件程度を、クロスエンコーダ型のリランカー（Cohere Rerankや、MicrosoftのAzure AI Searchが提供するセマンティックランカーなど）で並べ替え、最終的に上位5件前後をLLMに渡します。この構成は、コストと精度のバランスを取りやすい形です。

ジェネレーション層：根拠に基づく回答を強制する

ジェネレーション層では、「渡した文脈だけを根拠にし、分からなければ分からないと答える」という制約をプロンプトで明示します。

生成モデルには、OpenAIやAnthropicなどが提供するLLMを使います。どのモデルを使う場合も、出典を文ごとに付けさせる設計にしておくと、利用者が自分で確かめられるため、AIへの信頼が早く育ちます。反対に、出典のない回答は、内容が正しくても業務で使うハードルが上がります。

なお、Stanford大学のNelson Liuらが2023年に報告した「Lost in the Middle」現象のように、長い文脈の中ほどにある情報はモデルに参照されにくい傾向が知られています。文脈をむやみに長くするより、リランクで絞り込んだ少数の質の高い断片を渡すほうが精度が出やすい、というのが多くの現場の実感とも一致します。

RAG構築はどんな手順で進める？

ユースケースの定義と評価データの整備を先に行い、最小構成のPoCで現状値を測ってから本番化する3フェーズが基本です。

フェーズ1：ユースケースと評価データを先に決める

「誰のどの業務を、どの文書で助けるか」を絞り込み、評価用の質問と正解の組を、構築を始める前に用意します。

この手順を飛ばすと、後の工程での改善判断がすべて主観になってしまいます。着手時に用意するものは次のとおりです。

1. 対象業務の特定：問い合わせ対応、社内規程の照会、提案書の作成支援など、頻度も工数も大きい業務を1つ選ぶ
2. 対象文書の範囲確定：初回は数百〜数千文書程度に絞る。最初から全社の文書を対象にしない
3. 評価セット（ゴールデンセット）の作成：現場から実際に集めた質問30〜100問について、それぞれ「根拠となる文書と箇所」を人の手で紐付ける
4. 合格基準の合意：たとえば「業務担当者が有用と判定した割合が8割以上なら合格」のように、関係者が事前に納得できる基準を決める

評価セットづくりは地味な作業ですが、その後の改善サイクル全体のスピードを左右します。現場の質問ログがあれば、そこから抜き出すのが一番の近道です。

フェーズ2：最小構成でPoCを組む

ベクトル検索だけの最小構成でベースラインを測り、キーワード検索やリランクを1つずつ足して差分を確かめます。

最初から検索の高度化やAIエージェント化まで盛り込むと、精度が出なかったときに原因を切り分けられません。ベクトル検索だけの素朴な構成でベースラインを取り、キーワード検索、リランク、クエリ書き換えを1つずつ加えて差分を測るほうが、結果的に早く進みます。

フェーズ3：本番化と運用設計

権限制御、インデックス更新、ログ収集、改善担当者の配置を決めて初めて、RAGの本番運用が成り立ちます。

特にアクセス権制御は、人事情報や未公開の経営情報を扱う場合、後から組み込むのが非常に難しくなります。設計段階から情報システム部門とセキュリティ部門を巻き込んでおくことが、手戻りを防ぐ一番のポイントです。

RAGの検索精度はどう評価・改善する？

検索と生成は別々に測るのが原則です。まず検索のRecall@kを確認し、その後に生成の忠実性と適合性を評価します。

検索（リトリーバル）を測る指標

検索層では、正解文書が上位k件に含まれる割合を示すRecall@kを最初に確認し、ここから優先して引き上げます。

実務では、まずRecall@10やRecall@20を確認します。ここが低ければ、プロンプトをどれだけ工夫しても回答の質は上がりません。「LLMの回答がおかしい」という報告の多くは、実際には検索の段階で正解文書を拾えていないことが原因です。

生成（ジェネレーション）を測る指標

生成層は、渡した文脈に忠実か（Faithfulness）と、質問に答えているか（Relevancy）の2軸で評価します。

Ragasは、Pythonで使えるオープンソースのRAG評価フレームワークです。主に次の指標を提供しています。

• Faithfulness：回答が文脈に根拠づけられているか
• Answer Relevancy：回答が質問に合っているか
• Context Precision／Context Recall：渡した文脈がどれだけ質問に合い、どれだけ必要な情報を網羅しているか

RagasはLLMを評価者として使う「LLM-as-a-judge」方式です。そのため、評価する側のブレを抑える運用が必要になります。具体的には、プロンプトを固定する、サンプリング温度を下げる、人による評価と定期的に照らし合わせる、といった対応です。

自動評価は改善サイクルを回すための道具であり、合否を最終判断するものではありません。月に数十件を人の目で読み合わせ、自動評価が妥当かを確かめる体制を並行して持つのが現実的です。

改善の優先順位をどう決めるか

原因を「拾えていない」「並べられていない」「使えていない」の3つに切り分け、この順番で対処すると効率的です。

この順番を守ると、投資対効果の高い施策から手を付けられます。反対に、モデルの入れ替えから始めると、コストばかり増えて改善幅が読めない状態になりがちです。

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

三大要因は、評価基準がないこと、権限設計の後付け、文書品質の放置です。いずれも技術ではなく設計と運用の問題です。

失敗1：評価セットがないまま改善を試みる

評価セットがないまま改善を試みると、主観でしか判断できず、改善も投資判断も積み上がりません。

回避策はシンプルで、PoCに着手する前に、30問程度でもよいので評価セットを作ることです。完璧である必要はありません。現場の担当者が「これに答えられれば実用になる」と言える質問を集めれば、十分に機能します。この作業を「本番の前にやればいい」と後回しにしたプロジェクトほど、PoCから先に進めない傾向があります。

失敗2：アクセス権とガバナンスの後付け

閲覧権限のない文書が回答に混入した瞬間、RAGは社内の信頼を失い、プロジェクトは停止に追い込まれます。

対策は、インジェストの時点で元のシステム（SharePoint、Google Drive、社内Wikiなど）の権限情報をメタデータとして取り込み、検索のたびに必ずフィルタを適用する設計にすることです。あわせて、ログをどこまで保存するか、個人情報をどう扱うか、外部APIにデータを送ってよいかについて、法務・セキュリティ部門と事前に合意しておく必要があります。

失敗3：文書品質の問題をシステムで解決しようとする

古い版と新しい版が混在したままでは、検索精度をどれだけ上げても回答は矛盾します。これはシステムでは解決できません。

RAG構築を進めると、社内のナレッジ管理の実態が見えてくることがよくあります。「同じ規程のバージョンが3種類ある」「決裁済みの最新版がローカルPCにしかない」といった状況が見つかるのは珍しくありません。これは失敗ではなく、AXの過程で解くべき課題が見つかった状態と捉えるべきです。技術で覆い隠さず、文書のマスター管理と改廃ルールの整備をセットで進めることが、結局は一番の近道になります。

失敗4：ユースケースを広げすぎる

対象の文書と質問の範囲を絞らないと精度が平均化し、どの用途にも中途半端なRAGになってしまいます。

RAGは万能の社内検索ではなく、特定の業務に合わせて調整できる仕組みです。まず1業務・1部門で明確な成果を出し、その構成をテンプレート化して横に展開していきます。

RAG構築を成功させるために何から始める？

成否を分けるのは、モデルやベクトルデータベースの選択ではありません。評価の仕組みと運用体制をつくれるかどうかです。

検索と生成を分けて測るループを回す

検索と生成を分けて測り、原因を切り分け、優先順位をつけて改善するループを続けられる体制を、最初に整えます。

この地道なループを回せる体制があるかどうかで、生成AIが一時的なPoCで終わるか、業務変革の基盤に育つかが決まります。フェーズ1で作った評価セットと、フェーズ3で整えるログ・月次レビューが、このループの土台になります。

1業務の成功をテンプレート化して横展開する

まず1業務・1部門で成果を出し、その構成をテンプレート化して横に展開する順番が、現実的な拡大戦略です。

最初の1業務で整えたインジェストの設計、権限フィルタ、評価セットの作り方は、次の業務でもそのまま使い回せます。対象を広げるたびに一から作り直すのではなく、テンプレートを育てながら展開することが、AX推進のスピードを上げる近道です。

姉妹メディアの関連記事