RAG（Retrieval-Augmented Generation：検索拡張生成）とは、生成AIが回答を作る前に外部のデータベースから関連情報を検索し、その内容を根拠として回答を生成する技術です。ChatGPTのようなLLM単体では答えられない社内規程や製品仕様に、学習し直すことなく答えられるため、社内ナレッジの検索やFAQ応答を目的に導入する企業が増えました。本記事ではRAGの仕組みを検索と生成の2段構成で整理し、社内文書を検索できる形に整える工程を動くコードで示したうえで、ファインチューニングとの違い、自前構築とマネージドの選び分け、企業での導入例、精度の限界と採用しない判断条件までを解説します。
まとめ：RAGの仕組みとファインチューニングとの使い分けの要点
RAGの本質は「LLMに社内の知識を検索させてから答えさせる」ことにあります。モデル自体には手を加えず、質問のたびに関連文書を検索してプロンプトに添える構成のため、情報の更新はデータベースの差し替えだけで済む仕組みです。根拠となる文書を提示できることから、事実に基づかない回答（ハルシネーション）の抑制にも働きます。外部ツール接続の標準規格であるMCPとの役割の違い・併用構成はMCPとRAGの違いの解説で扱っています。
ファインチューニングとの使い分けは明快です。頻繁に更新される社内文書・製品情報・規程に答えさせたいならRAG。文体や応答の型、専門分野の推論傾向そのものをモデルに覚え込ませたいならファインチューニングです。多くの企業ユースは前者に該当するため、まずRAGから検討するのが定石で、両者の併用も可能です。
作る側の要点は3つです。文書を1,000字前後のチャンクに分けて埋め込みベクトルに変換し索引に載せること。キーワード検索とベクトル検索を併用して取りこぼしを減らすこと。回答に参照文書を必ず添えること。品質は検索精度と元データの整備状態に強く依存するため、限界を理解した上で導入範囲を決めるのが、期待外れを防ぐ入口になります。
RAGの定義と検索・生成の2段構成で動く仕組みのわかりやすい整理
まず言葉の意味と内部の動きを押さえます。仕組みといっても構成はシンプルで、2つの段階に分けると理解しやすくなります。
検索拡張生成という名前が示すRAGの意味と登場した技術的背景
RAGはRetrieval-Augmented Generationの略で、日本語では「検索拡張生成」と訳されます。検索（Retrieval）で回答を拡張（Augmented）してから生成（Generation）する、という処理順そのままの名前です。出発点は、2020年5月22日に投稿された論文Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasksです。
この論文は、事前学習済みのseq2seqモデルを「パラメトリック記憶」、Wikipediaの密ベクトルインデックスを「ノンパラメトリック記憶」と位置付け、両者を組み合わせました。検索器にはDPR（Dense Passage Retrieval）を使い、生成の全体で同じ検索結果を参照するRAG-Sequenceと、トークンごとに異なる文書を参照できるRAG-Tokenの2方式が示されています。今の企業向けRAGは前者に近い単純な構成が主流です。
背景にあるのはLLMの構造的な弱点です。大規模言語モデル（LLM）は学習時点までの公開データしか知らず、自社の社内規程や最新の製品情報には答えられません。知らない質問にもそれらしい文章を作ってしまうハルシネーションの問題も抱えています。この2つを、モデルの再学習なしで補う手法として広まったのがRAGです。
質問から検索・プロンプト合成・回答生成へ流れる2段階の処理手順
処理の流れは次の通りです。ユーザーが質問を入力すると、システムはまず外部のデータベースから関連性の高い文書を検索します。次に、検索で得た文書を質問と一緒にプロンプトへ組み込み、LLMに渡します。LLMは渡された文書を根拠として回答を生成するため、学習データに含まれない情報にも答えられる、という構造です。
検索対象には、文書を意味の近さで探せるベクトルデータベースを使う構成が一般的です。社内のPDFやWord文書を小さな単位に分割し、ベクトル化して格納しておくことで、キーワードの一致ではなく意味の近さで該当箇所を引き当てられます。3タイプの製品特性と選び方はベクトルデータベースのおすすめ比較で整理しました。
ここで押さえておきたい制約が、LLMに渡せる入力量の上限です。Azure AI SearchのRAG概要（2026年8月4日更新）はこれを「トークン制約」と呼び、文書を丸ごと投げるのではなく関連性の高い簡潔な結果を返す必要がある、と明記しています。渡す文書を絞る仕組みが、そのまま回答品質を決めるという関係です。
社内文書をチャンク分割し埋め込みで検索できる形に整える作業手順
概念だけでは構成が組めないため、検索対象を作る工程を実物のコードで確認します。RAGの品質はほぼこの前処理で決まり、企画側も工程名と判断点を押さえておく価値があります。
読み込みから分割・埋め込み・格納まで4工程を動くコードで確認
LangChain公式のRAGガイドは、インデックス作成をLoad（データソースをDocumentへ変換）、Split（テキストスプリッターでチャンク化）、Embed（埋め込みモデルでベクトル化）、Store（ベクトルストアへ索引化）の4工程に分けています。同ガイドの例ではRecursiveCharacterTextSplitterにchunk_size=1000とchunk_overlap=200を与え、14ページの文書が782チャンクに分かれています。1,000字ごとに切り、前後200字を重ねる設定です。
この4工程と検索・生成までを最小構成で書くと次のようになります。社内規程のテキスト1本を対象に、質問に近い4件を根拠として渡す形。
# 1. 依存パッケージの導入
pip install langchain langchain-openai langchain-text-splitters langchain-community
# 2. Load ・ Split ・ Embed ・ Store（検索できる形に整える）
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_core.vectorstores import InMemoryVectorStore
docs = TextLoader("shanai_kitei.txt", encoding="utf-8").load()
chunks = RecursiveCharacterTextSplitter(
chunk_size=1000, chunk_overlap=200
).split_documents(docs)
store = InMemoryVectorStore(OpenAIEmbeddings(model="text-embedding-3-small"))
store.add_documents(chunks)
# 3. Retrieve ・ Generate（根拠を添えて答えさせる）
question = "有給休暇の申請は何日前までに出す決まりですか"
hits = store.similarity_search(question, k=4)
context = "\n\n".join(d.page_content for d in hits)
prompt = (
"次の社内文書だけを根拠に答え、根拠が無ければ不明と答えてください。\n\n"
+ context + "\n\n質問: " + question
)
llm = ChatOpenAI(model=CHAT_MODEL) # 契約しているチャットモデル名を入れる
print(llm.invoke(prompt).content)
検証段階ではInMemoryVectorStoreで十分ですが、プロセスを落とすと索引も消えるため本番では永続化が必要です。分割幅も固定値でよいとは限りません。規程のように条文単位で意味が切れる文書は、意味の切れ目で分けるセマンティックチャンキングのほうが引き当て精度が上がります。日本語の精度を左右する埋め込みモデルの判断軸は埋め込みモデルの選び方にまとめました。
PostgreSQLのpgvectorでベクトル列とHNSW索引を作るSQLの実例
既にPostgreSQLを運用しているなら、拡張機能のpgvectorを入れるだけでベクトル検索が使えます。0.8系（2026年9月時点）はHNSWとIVFFlatの索引に対応し、距離演算子はL2距離・内積・コサイン距離・L1距離などが用意されています。vector型は最大16,000次元まで保持でき、索引を張る場合は2,000次元が上限です。
CREATE EXTENSION vector;
CREATE TABLE chunks (
id bigserial PRIMARY KEY,
doc_name text,
body text,
embedding vector(1536)
);
-- コサイン距離のHNSW索引を張る
CREATE INDEX ON chunks
USING hnsw (embedding vector_cosine_ops);
-- 質問ベクトルに近い上位4件を根拠として取り出す
SELECT doc_name, body
FROM chunks
ORDER BY embedding <=> :query_embedding
LIMIT 4;
次元数の1536は埋め込みモデル側の出力に合わせる値で、モデルを変えたら列定義も張り直しになります。索引は、数万件までならHNSWで検索速度が安定し、投入時のコストを抑えたいならIVFFlatという分け方が実務的です。専用のベクトルDBを新規契約せずに検証を始められるのが、この構成の実利です。
検索の取りこぼしを減らすハイブリッド検索とリランクの組み合わせ
ベクトル検索だけでは、型番や社内独自の略語のような「文字列そのもの」を探す質問に弱くなります。Azure AI Searchの前掲ドキュメントも、キーワード検索とベクトル検索を並列に走らせて統合するハイブリッドクエリを再現率の最大化手段に挙げ、セマンティックランク付けが上位50件を意味ベースで再スコア付けすると説明しています。検索は1段ではなく2段で組む設計です。
実装の型はBM25とベクトル検索をRRFで統合する構成で、手順とコードはハイブリッド検索の実装解説にあります。統合後の並べ替えを担うのがリランクモデルで、種類と選び方はリランクモデルの比較で扱いました。まずハイブリッド化で取りこぼしを潰し、それでも上位に無関係な文書が混じる場合にリランクを足す順序で足ります。
LLM単体との関係とファインチューニングとの違いの比較観点整理
RAGを検討する場面では「LLMだけではだめなのか」「ファインチューニングとどちらを選ぶのか」という2つの比較が必ず出てきます。順に整理します。
LLM単体でできることとRAGで補う領域の関係のわかりやすい整理
LLMとRAGは対立する技術ではなく、LLMの弱点をRAGが外付けで補う関係です。LLM単体は、一般的な知識に基づく文章生成・要約・翻訳を得意とします。弱いのは、学習データにない情報です。社内マニュアル、直近の価格改定、部署固有の手順書には答えられず、無理に答えさせると誤りを含みます。
RAGはこの「知識の外付け」を担います。LLM本体は汎用の言語能力に専念させ、自社固有の知識は検索で都度渡す分担です。したがって「LLMかRAGか」という二者択一は成立しません。RAGはLLMを前提とした構成であり、検討すべきは「LLMに自社の何を参照させたいか」という中身の設計になります。
モデルを更新するファインチューニングと外部参照のRAGの比較表
ファインチューニングは、既存のLLMに追加データを学習させ、モデル内部のパラメータそのものを更新する手法です。RAGとの違いを整理します。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| モデルへの変更 | なし（外部参照） | あり（重みを更新） |
| 知識の更新 | DB差し替えで即時 | 再学習が必要 |
| 得意分野 | 事実・文書の参照 | 文体・応答の型の獲得 |
| 初期コスト | 比較的小さい | 学習の時間と費用が大きい |
| 根拠の提示 | 参照文書を示せる | 示しにくい |
使い分けの軸は「覚えさせたいものが知識か、振る舞いか」です。更新頻度の高い知識はRAG、専門分野特有の推論傾向や一貫した文体はファインチューニングが向きます。実務では、まずRAGで知識参照の課題を解き、それでも応答の質が足りない場合にファインチューニングを重ねる順序が、コスト面で合理的な進め方になります。
社内FAQ・文書検索で成果を出すRAGの企業利用例と適する業務
概念を押さえたところで、企業で実際に成果が出ている利用例と、向く業務・向かない業務の線引きを示します。
社内問い合わせ対応とナレッジ検索で導入が進む代表的な利用場面
導入が先行しているのは社内ナレッジ系の用途です。代表例は3つあります。総務・情シスへの社内問い合わせにRAGを組み込んだチャットで一次回答させる構成、散在する規程・議事録・技術文書を意味検索できるようにする社内ドキュメント検索、そして顧客サポートでオペレーターに回答候補と根拠文書を提示する支援構成です。
共通するのは「答えは社内文書のどこかに書いてあるが、探すのに時間がかかる」業務である点。この条件に当てはまる業務ほど、RAGの効果が数字に出やすくなります。逆に、答えが文書化されていない業務や担当者の経験則で回っている業務には、参照すべきデータが存在しません。「答えの書かれた文書があるか」の確認が、適用可否の最初の判定です。
社内利用で先に決めるべきものが権限の扱いです。人事評価や役員資料まで同じ索引に入れると、検索側で絞らない限り誰にでも返ります。文書単位でアクセス権を引き継ぐ設計はナレッジベースとRAGの違いと権限制御で扱いました。
AIエージェントの知識基盤としてRAGが担う役割と組み合わせ方
2026年時点のもう1つの潮流は、RAGを単体のQ&Aで使うのではなく、自律的にタスクを進めるAIエージェントの知識基盤として組み込む構成です。エージェントが業務を判断・実行する際に、社内の規程や過去事例をRAGで参照させることで、判断の根拠を自社の文脈に接地させられます。
この構成では、RAGは「エージェントが使う道具の1つ」になります。検索の失敗をエージェント側が検知して検索し直す発展形も登場し、RAGの設計はエージェント全体の設計と切り離せない段階です。図表・画像まで検索対象を広げるマルチモーダルRAGの仕組みと実装方式も、この流れに連なる変種です。社内ナレッジのRAG化は、将来のエージェント導入の土台づくりでもあると捉えると、投資判断がしやすくなります。
自前構築とマネージドサービスを工数と制御範囲で比較した選定基準
構成が見えると、次の分岐は「どこまで自分で作るか」です。工程を代行するマネージドサービスが揃い、判断は数年前より単純になりました。
Azure AI SearchとBedrockが代行する工程と自前実装が残る範囲
Amazon Bedrock Knowledge Basesのマネージド版は、データ取り込み・索引化・格納・検索の基盤をサービス側が持ち、埋め込みや再ランクも既定モデルで実行する仕組みです。S3・SharePoint・Confluence・Google Drive・OneDriveなどのコネクタ、取得時の文書単位のアクセス制御リストによる絞り込み、回答へ引用を付けて出典を確認できる機能も公式に列挙されています。自前でベクトルストアを持つならカスタマー管理型を選び、OpenSearch ServerlessやAuroraを自分で運用する構成です。
| 工程 | 自前構築 | マネージド |
|---|---|---|
| チャンク分割 | 幅と単位を自分で設計 | 自動生成に任せられる |
| 埋め込み | モデルを選んで実装 | 既定モデルで実行 |
| 索引と格納 | pgvector等を運用 | サービス側が保持 |
| 引用の付与 | 自分で実装 | 応答に同梱 |
| 制御の自由度 | 広い | 設定できる範囲に限る |
| 費用の出方 | 基盤費と開発工数 | 従量課金 |
目安はこうです。対象文書が数千件までで、分割や検索ロジックに特殊な要件が無いなら、マネージドから始めたほうが立ち上げが早い。独自の分割ルールが要る文書（図表と本文が入り組んだ設計図書など）、既存DBに相乗りしたい場合、検索ロジックを自社の業務語彙に合わせて作り込む必要がある場合は、自前構築の余地が残ります。両方を同時に検証すると工数が二重になるため、先にマネージドで精度の下限を測り、足りない部分だけ自前に寄せる順番が無駄になりません。
2026年時点で主流になりつつあるエージェント型検索の採否の線引き
前掲のAzure AI Searchのドキュメントは、従来の1クエリ完結型に加えて「エージェント検索」を用意し、新規のRAG実装はこちらから始めるよう案内しています。LLMが質問を複数のサブクエリに分解して並列実行し、引用と実行メタデータを含む構造化応答を返す仕組みです。一方、GA機能だけを使いたい場合、速度と単純さを関連性より優先する場合、既存のオーケストレーションコードを保持したい場合は、従来型のハイブリッド検索＋セマンティックランク付けが向くとも明記されています。
ここは言い切ります。社内FAQのように質問文が短く単発で終わる用途なら、エージェント型は過剰です。1クエリで引ける質問に質問分解を挟むと、応答が遅くなり呼び出し回数も増えるだけで、精度の上積みが体感に出ません。採用条件は、質問が会話的で前提を含む場合、複数の情報源をまたぐ場合、回答に引用と検索過程の記録が業務要件として求められる場合。どれにも当たらないなら従来型で組むほうが早く成果が出ます。
RAGの精度が落ちる原因と導入前に押さえる限界・対策の全体像
RAGは万能ではありません。導入後に「思ったより答えられない」となる原因はある程度パターン化されているため、先に把握しておきます。
検索の外れと元データの不備がもたらす誤答の2大原因の切り分け
精度問題の原因は大きく2系統です。1つは検索の外れ。質問に対して関連の薄い文書が引き当てられると、LLMは的外れな根拠から回答を組み立てます。文書の分割単位が不適切な場合や、社内特有の略語が検索にかからない場合に起こる現象です。もう1つは元データの不備で、古い版と新しい版の規程が混在していれば、正しく検索できても答えは割れます。
切り分けの方法は単純です。誤答時に「どの文書が検索されたか」を確認します。検索結果自体が外れていれば検索側の改善、検索は正しいのに答えが誤っていればデータ整備の問題と判定できます。企業導入でつまずく原因の多くは後者です。ハイブリッド化やチャンク幅の見直しに手を付ける前に、対象文書の版が揃っているかを見てください。
導入範囲の絞り込みと段階的な検証で期待値を管理する進め方の設計
対策の方向性は、技術的なチューニングの前に運用設計にあります。最初から全社の文書を対象にせず、整備状態のよい1領域（例：情シスのFAQ）に絞り、回答に根拠文書を添えて利用者が検証できる形が基本です。精度の実測値を見ながら対象文書を広げる進め方が、期待値の崩壊を防ぎます。その実測をどの指標で行うかはRAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込みで解説しています。
検索改善やデータ整備を含む具体的な構築・チューニングの手順はRAG構築の手順で別途整理していますが、企業側の意思決定として押さえるべきは「RAGの品質は導入後のデータ運用で決まる」という一点です。文書の更新・棚卸しの担当を決めない導入は、時間の経過とともに精度が劣化します。一創ではRAG構成の設計から構築・運用改善までをAI受託開発として支援しており、対象業務の選定や文書の棚卸しからRAG構築支援で相談できます。
RAGを採用せず全文検索や文書整備で足りると判断できる条件の整理
採用しない判断も先に置きます。対象文書が数十ファイル程度で更新も年に数回なら、全文検索とタグ整理で足ります。RAGは過剰で、埋め込みの費用と索引の運用が追加コストになるだけ。次に、答えが文書化されていない業務は対象外です。担当者の判断で回っている領域にRAGを載せても、参照先が無く誤答が増えて終わります。
3つ目は、誤りの許容度がゼロに近い領域です。投薬の判断や法的な確定回答のように損害が回復不能な用途では、RAGを入れても人の確認工程を外さないでください。検索が外れれば誤答は残る性質は、構成をどれだけ作り込んでも消えません。この3つに当たらない社内文書の検索・要約・一次回答が、RAGの本命です。
RAGとは何かに関するよくある質問と導入検討前の疑問への回答
RAGについて検索されることが多い質問に簡潔に答えます。
RAGとは何ですか？わかりやすく言うとどのような技術ですか？
生成AIが答える前に、関連する文書を外部のデータベースから検索し、その内容を根拠にして回答を作る技術です。「調べてから答えるAI」と言い換えるとわかりやすい表現になります。AIモデル自体は変更しないため、参照させる文書を差し替えるだけで回答の中身を更新できる点が特長です。用語の出発点は2020年5月の論文で、パラメトリック記憶とノンパラメトリック記憶を組み合わせる構成として提案されました。
LLMとRAGの関係はどう理解すればよいですか？
LLMは文章を理解・生成する頭脳、RAGはその頭脳に社内資料を渡す仕組みです。RAGはLLMの存在を前提にした構成であり、どちらかを選ぶ関係ではありません。LLM単体では学習データにない社内情報に答えられないため、その弱点を検索で補う拡張がRAGだと理解すると、両者の関係が整理できます。
RAGとファインチューニングはどちらを選ぶべきですか？
更新される知識に答えさせたいならRAG、応答の型や専門分野の推論傾向をモデルに覚えさせたいならファインチューニングです。社内文書への質問応答という企業の代表的ユースはRAGが適します。初期コストもRAGのほうが小さいため、まずRAGで検証し、必要に応じてファインチューニングを重ねる順序を推奨します。
RAGの構成はどのような要素で作りますか？費用はどこにかかりますか？
文書を分割するチャンク処理、ベクトル化する埋め込みモデル、格納と検索を担うベクトル索引、回答を作るLLMの4要素が最小構成です。費用の内訳は、埋め込みの初回変換と質問ごとのLLM呼び出し、索引を置く基盤費の3種類です。既にPostgreSQLがあればpgvectorで索引を相乗りさせられ、検証段階の基盤費を抑えられます。文書量が数千件規模なら、マネージドの従量課金で始めるほうが総額を読みやすくなります。
RAGを導入するとハルシネーションはなくなりますか？
抑制はできますが、ゼロにはなりません。根拠文書を渡すことで事実に基づかない回答は減るものの、検索が外れた場合や元データに誤りがある場合には誤答が残ります。対策としては、回答に参照文書を必ず表示して利用者が確認できる形にすること、参照データの整備と更新を運用に組み込むこと、そしてプロンプトで「根拠が無ければ不明と答える」よう指示することが実効的です。
関連記事
- RAG構築の手順とは？データ整備から精度向上・本番運用までの進め方：概念を押さえた後の具体的な構築工程と精度改善を解説しています。
- AIエージェントとは？生成AIとの違い・仕組みと業務に組み込む判断基準を解説：RAGを知識基盤として組み込むエージェントの全体像を整理しています。
- ハルシネーション（AI）とは？意味・原因・種類・対策を実例で解説：RAGで抑える対象そのものを原因から分解した記事です。
- LangChain.jsとは？その概要と特徴を詳しく解説：RAG構成の実装で使われる代表的フレームワークの解説です。
- DXとは？定義とデジタル化との違い・進め方を受託開発の実務目線で解説：社内ナレッジのRAG化をDX施策の中に位置付ける際の基礎になります。
