RAG（検索拡張生成）とは？仕組みと作り方、精度を上げる方法

RAG（Retrieval-Augmented Generation、検索拡張生成）とは、質問に関係する文書を先に検索し、見つけた内容を指示に添えて生成AIに回答させる仕組みです。生成AIのモデルは、学習していない社内の規程や手順書、最近更新された情報を知りません。RAGを使うと、モデルを学習し直さなくても、社内の文書をもとにした回答と、その根拠となる出典を示せます。この記事では、RAGの意味と企業が使う理由、文書の準備から回答までの仕組み、ファインチューニングや長いコンテキストとの違い、作り方、精度が出ないときの原因と対策、権限の扱い、始め方を説明します。

RAG（検索拡張生成）とは

言葉の由来は2020年の論文

RAGという名前は、2020年5月にarXivで公開された論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（Patrick Lewisほか、NeurIPS 2020採録）で提案されました。この論文は、モデルの重みに蓄えられた知識だけでは、知識を正確に扱うことや、回答の根拠を示すこと、知識を更新することに課題があると指摘しています。そのうえで、学習済みの生成モデルに、Wikipediaの文章をベクトルにした索引と検索器を組み合わせる方法を「RAG」と名付けました。

現在は、論文の手法そのものより、広く「検索した内容を使って生成する」構成を指す言葉として使われています。OpenAIのドキュメントも、RAGを「回答を生成する前に、内容を検索してLLMへの指示を補う処理」と説明しています。

企業がRAGを使う理由

OpenAIのドキュメントは、学習データに含まれていない知識、古くなった知識、社内の独自の情報が必要な場合は、モデルに渡す情報（コンテキスト）を工夫するべきだと整理しています。RAGは、その情報を質問のたびに検索して渡す方法です。

企業でよく検討される用途は、次の2つです。

• 社内検索：就業規則、経費精算の手順、製品の仕様書などを、言葉で質問して探す
• 問い合わせ対応：社内のヘルプデスクや顧客からの質問に、マニュアルや過去の回答をもとに回答案を作る

どちらも、答えの根拠が社内の文書にあり、文書は更新されていきます。RAGでは文書を差し替えれば検索の対象も変わるため、モデルの学習をやり直さずに新しい内容を反映できます。回答に出典を付ければ、利用者が元の文書を開いて確かめることもできます。

RAGの仕組み：文書の準備から回答の生成まで

RAGの処理は、あらかじめ文書を検索できる形にしておく「準備」と、質問が来たときの「検索と生成」に分かれます。全体の流れを図にまとめました。

図の要点をテキストで読む

RAG（検索拡張生成）の処理の流れを4段階で示した図。1は文書の準備で、社内文書をチャンクに分割し、更新日や閲覧権限などの情報を付ける。2は索引の作成で、チャンクを埋め込みモデルでベクトルに変換し、キーワード検索用の索引も作る。文書の準備と索引の作成は質問の前に行い、文書が更新されたら作り直す。3は検索で、質問のたびに、利用者が閲覧できる文書に絞って質問に近いチャンクを探す。4は回答の生成で、検索結果を質問に添えて生成AIに渡し、出典を付けて回答する。根拠が見つからなければ答えない。精度は、検索の結果と生成した回答を分けて評価する。

文書を集めてチャンクに分割する

まず、対象の文書を集めてテキストを取り出し、検索しやすい大きさの断片（チャンク）に分割します。チャンクの大きさは、検索の精度に影響する設定の1つです。たとえば、OpenAIのファイル検索は、既定で800トークンずつに分け、前後のチャンクを400トークン重ねます。Amazon Bedrock Knowledge Basesの既定の分割は約300トークンで、文の途中では切らないようになっています。どちらのサービスでも、大きさや重なりは変更できます。

埋め込みに変換して索引を作る

次に、各チャンクを埋め込みモデルで数値の並び（ベクトル）に変換し、ベクトルを検索できるデータベースに保存します。意味が近い文章ほどベクトルも近くなるため、質問と言葉が一致しなくても、内容の近いチャンクを探せます。これを意味検索（セマンティック検索）と呼びます。保存先には専用のベクトルデータベースのほか、PostgreSQLの拡張機能であるpgvectorのように、既存のデータベースにベクトル検索を加える方法もあります。

チャンクには、文書名、更新日、部署、閲覧できる人などの情報（メタデータ）も一緒に保存しておきます。後で検索の対象を絞り込んだり、出典として文書名を示したりするときに使います。

質問に近いチャンクを検索する

利用者が質問すると、質問文も同じ埋め込みモデルでベクトルに変換し、近いチャンクを検索します。このとき、メタデータを使って「利用者が閲覧できる文書だけ」「最新版の規程だけ」のように検索の対象を絞ります。検索結果の上位を、別のモデルで質問との関連度を採点し直して並べ替える処理（リランキング）を加えることもあります。

検索結果を添えて回答を生成する

最後に、検索で見つかったチャンクを質問と一緒に生成AIに渡し、その内容をもとに回答させます。検索で根拠が見つからないときは、推測で答えずに「該当する文書が見つからない」と返すよう指示しておきます。OpenAIのファイル検索、Gemini APIのFile Search、Amazon Bedrock Knowledge Basesは、どのファイルを使って回答したかを示す出典の情報を回答と一緒に返せます。社内で使う場合も、回答に出典を付けて、利用者が元の文書を確かめられるようにしておくと安心です。

RAGとファインチューニング、長いコンテキストの違い

社内の知識をAIに使わせる方法は、RAGのほかに、モデルを追加で学習させるファインチューニングと、文書を丸ごと指示に入れる長いコンテキストの利用があります。

ファインチューニングは振る舞いをそろえる方法

OpenAIのドキュメントは、改善の方向を2つに分けています。モデルに知識が足りないときは、渡す情報を工夫して回答の正確さを上げます。一方で、出力の形式がそろわない、口調が合わない、決めた手順どおりに考えないといった場合は、モデルそのものを調整して振る舞いをそろえます。RAGは前者の方法で、ファインチューニングは主に後者に使います。両方を組み合わせることもでき、RAGの検索結果を含む例でファインチューニングする方法も紹介されています。

社内の知識を答えさせることが目的なら、まずRAGから検討します。ファインチューニングで知識を覚えさせると、文書が更新されるたびに学習し直す必要があり、どの文書を根拠にしたかも示しにくくなります。選び方は、Q&A「RAGとファインチューニング、どちらを選ぶべきですか？」でも整理しています。

文書が少なければ長いコンテキストで足りる場合もある

最近のモデルは、一度に大量の文章を読み込めます。GoogleのGemini APIのドキュメントには、多くのGeminiモデルが100万トークン以上のコンテキストを扱えると書かれています。Anthropicは2024年9月の記事で、知識として使う文書が20万トークン（約500ページ）より少なければ、RAGを使わずに文書全体を指示に入れる方法でよいと説明しています。

ただし、Googleのドキュメントは、長いコンテキストで複数の情報を同時に探すと精度が下がる場合があること、質問のたびに入力した分の費用がかかることを、注意点として挙げています。同じ文書を繰り返し使う場合は、キャッシュ機能で費用を抑える方法も紹介されています。文書の量が多い、頻繁に更新される、利用者ごとに見せてよい文書が違う、といった条件があるなら、RAGで必要な部分だけを渡す方が向いています。

RAGの作り方：マネージドサービスと自社での構築

RAGを作る方法は、大きく分けて、クラウド事業者が提供する検索の機能を使う方法と、部品を組み合わせて自社で構築する方法があります。

クラウドのサービスを使う

主なAIの提供元とクラウド事業者は、RAG向けの機能を用意しています。

• OpenAIのファイル検索：ファイルをベクトルストアに追加すると、分割、埋め込み、索引の作成が自動で行われます。意味検索とキーワード検索の両方で探し、ファイルの属性で検索対象を絞れます。
• Gemini APIのFile Search：ファイルを取り込むと、分割、埋め込み、索引の作成が行われ、回答に出典の情報を付けられます。アップロードした元のファイルは48時間後に削除されますが、取り込んだデータは利用者が削除するまで残ります。
• Azure AI Search：キーワード検索とベクトル検索を組み合わせるハイブリッド検索と、意味に基づく並べ替えを使えます。複雑な質問を分解して検索する「エージェント型の検索」も提供されています（質問の分解は2026年10月6日時点でプレビュー）。
• Amazon Bedrock Knowledge Bases：管理をAWSに任せる型と、ベクトルストアなどを自社で管理する型があります。管理を任せる型では、SharePointやConfluenceなどからの取り込みと、文書ごとの閲覧権限での絞り込みに対応しています。

これらを使うと、分割や索引の仕組みを一から作らずに試作を始められます。どこにデータが保存されるか、文書を削除したときにいつ検索から外れるかは、サービスごとに確認します。たとえばOpenAIのドキュメントは、ベクトルストアからファイルを削除しても、しばらくは検索結果に残る場合があると書いています。

AIエージェントが、必要なときに社内の検索を道具として呼び出す構成もあります。Amazon Bedrock Knowledge Basesの管理を任せる型は、MCPに対応したエージェントからツールとして呼び出せます。MCPの仕組みはMCPとは？MCPサーバーの仕組みと社内システム連携の権限設計で解説しています。

部品を組み合わせて自社で構築する

自社で構築する場合は、文書を取り出す処理、埋め込みモデル、ベクトルデータベース、検索結果を生成AIに渡す処理を組み合わせます。分割の方法や検索の条件を細かく決められる一方で、取り込みの更新や障害時の対応も自社で受け持ちます。なお、Anthropicは独自の埋め込みモデルを提供しておらず、Claudeのドキュメントでは埋め込みの提供元の1つとしてVoyage AIを紹介しています。生成と埋め込みで、別の提供元のモデルを組み合わせることもできます。

社外のサービスに文書を送れない場合は、モデルを自社の環境で動かす方法もあります。考え方はローカルLLMとは？OllamaとLM Studioでの始め方、企業での使い分けで解説しています。

RAGの精度が出ない原因と対策

RAGの回答が期待どおりにならないとき、原因は大きく2つに分かれます。OpenAIのドキュメントは、検索の段階で正しい情報を渡せていない場合と、正しい情報を渡しているのにモデルがうまく使えていない場合を分けて考えるよう勧めています。関係のない情報を多く渡しすぎると、必要な情報が埋もれて誤った回答につながることも指摘しています。よくある原因と対策を表にまとめました。

図の要点をテキストで読む

RAGの回答の精度が出ないときの、よくある原因と起きること、対策をまとめた表。文書の旧版や重複が残っていると、古い内容で回答するため、版を管理して最新版に絞る。チャンクが文脈を失っていると、何の話かわからず検索で見つからないため、見出しに沿って分けるか、チャンクに説明を付ける。型番や略語などの完全一致が必要な語は意味検索で取りこぼすため、キーワード検索と組み合わせる。関係のない文書が多く混ざると、必要な情報が埋もれて誤答するため、件数を調整し、リランキングで並べ替える。正しい文書を渡しているのに誤答する場合は、根拠だけで答えるよう指示を直し、評価用の質問で確かめる。

データを整える

精度の問題は、検索の仕組みより前に、元の文書にあることもあります。同じ規程の旧版と新版が両方入っていると、古い内容で回答することがあります。スキャンしたPDFや表の多い資料は、テキストを正しく取り出せているかを確認します。版の管理と更新日のメタデータを整え、検索の対象を最新版に限る設定にします。

チャンク分割の設計を見直す

チャンクが小さすぎると、その部分だけでは何の話かがわからなくなります。Anthropicは、「前の四半期より売上が3%増えた」という一文だけのチャンクでは、どの会社のいつの話かがわからず、検索で見つけにくくなる例を挙げています。そのうえで、文書全体から見た説明を各チャンクの先頭に付けてから索引を作る方法を紹介しています。Amazon Bedrock Knowledge Basesには、小さなチャンクで検索して、より大きな親のチャンクを生成AIに渡す階層型の分割もあります。見出しや条文の区切りに沿って分ける方法も含め、自社の文書で比べて決めます。チャンク設計の考え方は、Q&A「RAG向けのドキュメントチャンク（分割）は、どう設計すればよいですか？」でも整理しています。

キーワード検索と組み合わせる

意味検索は言い換えに強い一方で、型番、エラーコード、社内の略語のような完全一致が必要な語を取りこぼすことがあります。Anthropicは、「TS-999」のようなエラーコードで検索する例を挙げ、BM25というキーワード検索の手法を組み合わせる方法を説明しています。Azure AI Searchのハイブリッド検索は、キーワード検索とベクトル検索を同時に実行し、2つの結果をRRF（Reciprocal Rank Fusion）という方法でまとめます。OpenAIのファイル検索でも、意味検索とキーワード検索の比重を調整できます。

評価用の質問セットでRAGを評価する

改善の効果は、同じ質問で比べて確かめます。実際に寄せられる質問と、正しい答え、根拠となる文書を組にした評価用のセットを用意し、設定を変えるたびに同じセットで測ります。Microsoft Foundryには、検索の質を測る評価と、回答が検索した内容に基づいているか（groundedness）、質問に答えているか、必要な情報が欠けていないかを測る評価が用意されています。Amazon Bedrockの評価機能も、検索だけを評価する方法と、検索と生成をまとめて評価する方法を分けています。検索と生成を分けて測ると、どちらを直すべきかがわかります。測る指標は、Q&A「ナレッジ検索の品質は、どんな指標で測ればよいですか？」も参考にしてください。

RAGのアクセス制御とセキュリティ

社内文書をRAGで検索できるようにすると、本来は見られない人に文書の内容が回答として届くおそれがあります。Microsoftのドキュメントは、経理のデータは役員が質問した場合でも経理の担当者にだけ見せるべき、という例でこの課題を説明しています。

対策の基本は、検索の段階で、質問した人が閲覧できる文書だけに絞ることです。Azure AI Searchは、文書ごとに閲覧できるグループのIDを持たせ、質問した人が属するグループで検索結果を絞り込む方法を説明しています。Azure Storageから取り込んだ文書では、Microsoft Entra IDの権限情報を引き継ぐ機能もあります。Amazon Bedrock Knowledge Basesの管理を任せる型は、取り込み元のアクセス制御リストに基づいて、検索の時点で文書を絞り込めます。権限のない文書は、生成AIへの指示で「答えないで」と頼むだけでは防げないため、検索結果に入らないようにします。

あわせて、次の点も決めておきます。

• 退職や異動で権限が変わったときに、検索の絞り込みへ反映されるまでの時間
• 文書を削除したときに、検索の対象からいつ外れるか
• 質問と回答、参照した文書の記録をどこに、どのくらいの期間残すか
• 個人情報を含む文書を検索の対象に入れるかどうか

ロールや属性に応じた絞り込みの実装は、Q&A「ロール別のアクセス制御（RBAC/ABAC）は、ナレッジ検索でどう実装しますか？」でも解説しています。

RAGの始め方：小さな文書の範囲で試してから広げる

RAGは、最初から全社の文書を対象にすると、精度の問題がどこから来ているのかを切り分けにくくなります。対象の業務と文書を絞って試し、評価してから広げます。

1. 対象を決める：質問が多く、答えが文書に書かれている業務を1つ選び、文書の範囲を決めます。
2. 評価用の質問を集める：実際の問い合わせから質問を集め、正しい答えと根拠の文書を担当者と一緒に決めます。
3. 試作する：クラウドのサービスなどで、分割、索引、検索、生成の流れを動かします。
4. 評価して直す：検索と回答を分けて評価し、データ、チャンク、検索の方法を直します。
5. 本番の準備をする：権限の連携、文書の更新の手順、記録の残し方、回答できないときの案内を決めます。

試作の結果を本番運用に移すときに確かめる項目は、AIのPoCを本番運用に移すには？止まる理由と移行前の確認項目で解説しています。

RAGの導入を相談する場合

RAGは、仕組みとしては単純でも、文書の整理、チャンクと検索の設計、評価、権限の連携で精度と安全性が決まります。inovieでは、対象業務と文書の整理から、社内検索や問い合わせ対応のRAGの試作と評価、既存システムとの連携、運用の設計までを支援しています。支援の範囲はAI導入・システム開発の支援をご覧ください。社内の文書をAIの回答に使いたいという段階でも、お問い合わせからご相談いただけます。

出典確認日：2026-10-06