この記事は、RAG（Retrieval-Augmented Generation）の基本構成と設計上の確認点を整理した技術解説です。特定クラウドや製品の性能、回答の正確さを保証するものではありません。

「RAGとは何か」を短く言えば、質問に関連する情報を先に検索し、その情報を生成AIへ文脈として渡して回答を組み立てる仕組みである。モデルが学習した知識だけに頼らず、社内文書、データベース、更新された資料などを参照できるようにする。

NISTの用語整理でも、RAGは生成AIモデルと別の情報検索システムや知識ベースを組み合わせ、質問に応じて関連情報を取り出し、生成の文脈として使うシステムと説明されている。大切なのは、RAGを「正解を入れた箱」と考えず、検索と生成の間に新しい確認点を増やす設計として見ることだ。

質問から関連資料が検索され、文脈として生成モデルへ渡り、出典へ戻る抽象ビジュアル。

01 RAGは「検索」と「生成」をつなぐ

通常の検索は、質問に近い文書やページを見つけ、利用者が内容を読む。生成AIは、入力された文脈をもとに文章や別の形式の候補をつくる。RAGはこの二つを組み合わせ、検索された情報を生成モデルへ渡す。

基本の流れは次のように分けられる。

  1. 文書やデータを、検索できる単位へ整える
  2. 利用者の質問を受け取る
  3. 質問に関連する情報を検索し、候補を順位づけする
  4. 取得した情報を質問とともに生成モデルへ渡す
  5. 回答を生成し、必要なら出典や根拠へ戻れるようにする

AWSの公式資料も、文書の分割や埋め込み、ベクトルデータベース、検索、文脈付与、生成という構成要素を説明している。実際の構成はサービスによって異なるが、RAGは一つのモデル名ではなく、検索と生成を組み合わせる設計パターンとして捉える方が分かりやすい。

02 RAGで変わるのは、モデルの記憶だけではない

RAGの特徴は、モデルを再学習させなくても、外部の知識ベースを回答の文脈へ加えられることにある。[MCP（Model Context Protocol）](/articles/what-is-model-context-protocol-mcp/)のような接続規格とは役割が異なり、RAGの中心は取得した情報を生成へどう組み込むかにある。社内の規程、製品マニュアル、研究資料など、対象を限定した情報を使いたいときに、参照先を管理しやすくなる場合がある。

ただし、RAGを導入すれば自動的に最新・正確・公平になるわけではない。取得する資料が古い、質問と関係が薄い、重要な箇所が切れている、アクセス権のない資料が混ざる。そうした問題は、生成前にすでに始まっている。

RAGが助けられる課題RAGだけでは決まらないこと
特定の知識ベースを回答へ渡すその知識ベースが正しいか、最新か
資料の所在を限定する検索結果に必要な箇所が含まれるか
回答から原文へ戻る道をつくる生成された文が原文を言い過ぎていないか
再学習なしで参照情報を更新する何を更新し、いつ反映するか

RAGの価値は、モデルの能力を魔法のように増やすことではない。回答に使う情報の経路を、ある程度観測・更新・制御できるようにすることにある。

03 検索結果が違えば、生成結果も変わる

RAGでは、生成モデルへ渡る文脈が回答の材料になる。だから、検索の評価と生成の評価を分ける必要がある。検索が必要な情報を取りこぼせば、生成モデルがどれだけ流暢でも答えられない。逆に、関係のない資料を渡すと、その情報を根拠らしく使ってしまう可能性がある。

確認するときは、少なくとも次を分けて見る。

  • 検索：質問に必要な資料を拾えているか
  • 順位：より重要な資料が上位へ来ているか
  • 文脈：文書の切り出しが意味を失っていないか
  • 生成：取得した資料だけで主張を支えられているか
  • 表示：利用者が出典、更新日、対象範囲へ戻れるか

Microsoftの公式資料も、RAGを情報検索とテキスト生成の組み合わせとして説明し、組織固有の知識を使う際の制約やガバナンスの確認を挙げている。検索の精度を、最終回答の読みやすさだけで評価しないことが重要だ。

検索で取り込んだ文書が回答の根拠候補になることと、その文書がエージェントへ行動を指示する権限を持つことは別である。外部情報の参照からツール実行まで連なるときは、データと命令の境界、実行権限、人が確認する地点を別々に設計したい。[AIエージェントが読む情報と行動権限の境界を整理した記事](/articles/ai-agent-definition-and-boundaries/)では、間接プロンプトインジェクションを含む委任上のリスクを扱う。

04 RAGの出典は、正しさの証明ではない

RAGの回答に資料名やリンクが表示されると、根拠があるように見える。これは原文へ戻るための大切な手がかりだが、引用が存在することと、回答の全体がその資料に支えられていることは別である。

生成AIは、取得した複数の断片をつなぎ、資料にない関係や断定を作ることがある。検索された文書が正しくても、質問の条件を外したり、更新日を無視したり、異なる対象を混同したりする可能性は残る。

出典を確認するときは、次の順で見る。

  1. その資料は、対象とする範囲・時点に合っているか
  2. 回答の各主張を、原文が本当に支えているか
  3. 引用された部分の前後に、条件や例外がないか
  4. 取得できなかった資料や、未確認の主張が残っていないか

RAGはハルシネーションを減らす設計の一つになり得るが、なくす仕組みではない。出典へ戻る体験と、人が検証できる記録を、最初から構成へ含める必要がある。

05 RAG・検索・ファインチューニングは同じではない

似た言葉が並ぶと、目的と手段を取り違えやすい。大まかには、次のように分けられる。

方法主に変えるもの向いている問い
検索利用者が読む情報の入口どの資料を探せばよいか
RAG検索した情報を生成回答へ渡す流れ資料を文脈にした回答をつくれるか
ファインチューニングモデルの振る舞い・出力傾向形式や応答の癖を調整できるか

この表は導入判断を確定するものではない。実際には複数の方法を組み合わせることもある。頻繁に更新される事実を参照したいのか、特定の形式で出力したいのか、利用者へ資料を見せたいのかで、必要な仕組みは変わる。

追加学習とRAG、プロンプトの違いを導入判断の軸で比べる場合は、[ファインチューニング・RAG・プロンプトの比較ガイド](/articles/fine-tuning-and-rag/)も参照できる。

06 RAGを設計する前の確認点

RAGの導入は、ベクトルデータベースを置くことから始めない。まず、回答へ使ってよい資料と、使ってはいけない資料の境界を決める。

  • 目的：どの質問に、どの判断を助けるために使うか
  • 情報源：誰が管理し、いつ更新し、どの版が正しいか
  • 権限：利用者ごとに、検索・表示してよい範囲が違うか
  • 検索品質：取りこぼし、誤取得、古い資料をどう測るか
  • 不回答：資料が足りないとき、推測せず保留できるか
  • 出典：どの資料のどの箇所を、利用者へ示せるか
  • 人の確認：公開、契約、個人に影響する判断を誰が承認するか

情報源の中身だけでなく、アクセス権と更新の流れもRAGの一部である。機密文書を検索できることは、誰にでも表示してよいことを意味しない。RAGは検索と生成の接続点であると同時に、データ管理と責任の接続点でもある。

RAGとは、AIが自分で正しい情報を覚える仕組みではない。必要な資料を探し、文脈として渡し、回答を生成し、原文と人の判断へ戻れるようにする設計である。検索の質、権限、出典、見直しを一つの流れとして扱うと、RAGは答えを隠す箱ではなく、情報体験を開く経路になる。