「社内の資料に詳しいAIがほしい」——企業のAI活用で最も多いこの要望に応える定番技術がRAG(検索拡張生成)です。親記事では基本の3ステップを紹介しましたが、この記事はシリーズの看板として、その内側で何が起きているのか、なぜうまくいく場合と失敗する場合があるのか、現場での利活用の姿までを、フロー図とともに徹底的に掘り下げます。
📖 ひと言でいうと
RAG (Retrieval-Augmented Generation、検索拡張生成) とは、AIが回答を作る前に、関連する資料を検索して読み込ませ、その内容に基づいて答えさせる仕組みです。
例えるなら、図書館のレファレンスサービス(調べもの相談)の司書さんです。優れた司書は、質問を受けても記憶だけで即答しません。まず書庫から関連する資料を探し出し、該当ページを開いて確認し、「この資料によると〜です」と出典つきで答えます。RAGは、この「調べてから答える」手順をAIに組み込んだものです。厳密には、司書(LLM)自身が賢くなるわけではなく、答える直前に正しい資料を手渡す仕組みである点がポイントです。
🖼 1枚でわかるRAG
🔍 しっかり理解する
全体像は「2つのフェーズ」——見えない準備が半分を占める
親記事では「検索→拡張→生成」の3ステップを学びました。実はその手前に、もう1つの重要なフェーズがあります。RAGは「事前準備フェーズ」と「回答フェーズ」の2階建てで動いているのです。
まず事前準備フェーズです。質問が来てから毎回、全文書を頭から読んでいたのでは間に合いません。そこで、あらかじめ文書を検索しやすい形に加工して蓄えておきます。
そして質問が来たら、回答フェーズが動きます。
「分割(チャンク化)」がなぜ必要かというと、LLMに一度に渡せる文章量(コンテキスト)には限りがあり、また資料全体より「該当する部分だけ」を渡すほうが回答の焦点が定まるからです。ただし切り方が悪いと、表とその説明文が泣き別れになるなど、検索しても意味の通らない断片しか取れなくなります。地味に見えて、RAGの品質を左右する重要な設計ポイントです。
「意味で探す」検索——キーワード一致を超える
RAGの検索でよく使われるのが、意味検索(ベクトル検索)です。ひと言でいうと「言葉の表面ではなく、意味の近さで資料を探す方法」です。文章を「意味の座標」を表す数値の列(埋め込み・ベクトル)に変換しておくと、似た意味の文章は近い座標に集まります。質問も同じように座標化し、近くにあるチャンクを取り出すのです。
これにより、質問が「有休って翌年に持ち越せる?」で、規定の表現が「年次有給休暇の翌年度への繰越」でも、言葉が一致しないのに正しい条文を見つけられます。従来のキーワード検索が「単語の一致」で探すのに対し、意味検索は「言いたいことの近さ」で探せるのが強みです。一方、型番や固有名詞のような「表記そのものの一致」が重要な検索はキーワード検索が得意なため、実務では両方を組み合わせる方式もよく使われます。
ファインチューニングとの違い、そして使い分け
「AIに社内知識を持たせる」もう1つの方法であるファインチューニング(1-3参照)と、RAGはよく比較されます。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 知識の置き場所 | モデルの外(文書データベース) | モデルの中(パラメーター) |
| 知識の更新 | 文書を差し替えるだけ | 再度の追加学習が必要 |
| 根拠の提示 | 出典を示しやすい | 出典は示せない |
| 向くケース | 事実・規定・最新情報の参照 | 文体・口調・専門的な応答の型の習得 |
覚え方は「事実はRAG、振る舞いはファインチューニング」です。日々更新される事実知識は、モデルの外に置いて検索で渡すほうが管理しやすく、根拠も示せます。一方、業界特有の言い回しや応答スタイルを身につけさせたいなら、追加学習が向きます。両者は対立ではなく併用できる関係です。
品質を決めるのは「資料の質×検索の質×指示の質」
RAGは強力ですが、「資料を放り込めば完成」ではありません。品質は3つの掛け算で決まります。第一に資料の質。古い規定や重複した文書が混ざっていれば、AIはそれを根拠に堂々と誤答します。第二に検索の質。チャンクの切り方や検索方式が悪ければ、的外れな資料が渡ります(的外れな資料しか持たない司書は正しく答えられません)。第三に指示の質。「渡した資料に基づいて答え、資料にないことは『資料に記載がありません』と答える」といった制約をプロンプトで与えることで、資料の外への飛躍(ハルシネーション)を抑えます。
また、RAGにも苦手はあります。「全文書を横断して件数を集計する」ような網羅的な処理は、関連チャンクだけを取り出す仕組みと相性が悪い代表例です。さらに実務では、閲覧権限のない文書が検索結果に混ざらないようにするアクセス権の管理も欠かせません。
💡 具体例で考える
ある機械メーカーのコールセンターでは、製品マニュアルが数百冊分あり、ベテランでも即答できない問い合わせが多くありました。RAGを導入し、オペレーターが顧客の質問をそのまま入力すると、該当機種のマニュアルの該当箇所を検索し、「型番○○の場合、この手順です(マニュアル△△ページ参照)」と出典つきの回答案が表示されるようにしました。オペレーターは原文を確認してから案内するため、誤案内が減り、新人でも安定した対応ができるようになりました。ポイントは、AIの回答をそのまま読み上げるのではなく、出典を人間が確認する運用にしたことです。
一方、ある会社の社内チャットボットは「規定と違う答えを返す」と不評でした。調べると、原因はAIではなく、改定前の古い規定ファイルがデータベースに残っていたことでした。文書の棚卸しと更新ルールを整えたところ、回答の正確さは大きく改善しました。「RAGの品質改善は、文書の整備から」を示す典型例です。
⚠️ よくある誤解・つまずきポイント
- 誤解: RAGを導入すればハルシネーションはなくなる → 正しくは: 資料に基づかせることで大幅に抑制が期待できますが、資料の誤読や資料外への飛躍は残りえます。出典確認の運用とセットで使います
- 誤解: RAGでモデルが社内知識を「学習」する → 正しくは: モデル自体は変わりません。回答のたびに資料をその場で読んでいるだけで、知識はモデルの外にあります
- 誤解: 文書を大量に入れるほど賢くなる → 正しくは: 古い文書や重複はむしろ品質を下げます。効くのは量より整備(最新化・重複排除・適切な分割)です
- 誤解: RAGとファインチューニングはどちらか一方を選ぶもの → 正しくは: 「事実はRAG、振る舞いはファインチューニング」で併用できます
📝 生成AIテストではこう出る
- RAGの流れ(検索→プロンプトへの拡張→生成)の順序や、各ステップの役割を問う問題。事前準備(分割・索引化)の存在も押さえておくと盤石です
- RAGの利点を問う問題。「学習していない情報への対応」「出典の提示」「文書差し替えによる容易な更新」「ハルシネーション抑制への寄与」が軸です
- ファインチューニングとの違いを問う問題。「知識がモデルの外か中か」「更新の手軽さ」「根拠提示の可否」で区別しましょう
- 「RAGを使えば誤りは起きない」「モデル自体が賢くなる」といった過大評価の選択肢は誤りと判断できるようにしましょう
📚 まとめ
- RAGは「調べてから答える」仕組みで、事前準備(集める→分割→索引化→保存)と回答(検索→拡張→生成→出典提示)の2フェーズで動きます
- 意味検索により、言葉が一致しなくても「言いたいことが近い」資料を見つけられるのが技術的な要です
- 「事実はRAG、振る舞いはファインチューニング」。知識を外に置くことで、更新の容易さと根拠の提示という実務上の大きな利点が生まれます
- 品質は資料×検索×指示の掛け算で決まり、ハルシネーションもゼロにはなりません。出典を人間が確認する運用までがRAGの利活用です
