RAG(検索拡張生成)

よみ: ラグ

基本的な意味と仕組み(オープンブックテストの例え)

Retrieval-Augmented Generation(検索拡張生成)。LLM(大規模言語モデル)が回答を生成する前に、外部の知識ソース(自社ドキュメントやデータベース等)を検索して関連情報を取得し、それを元に回答を生成する仕組み。初心者にはテストで例えると分かりやすい。

通常の LLM：「記憶」だけを頼りにテストを解く(知らないことは適当に答えてしまう)。
RAG：「自社の教科書やマニュアル」の持ち込みが許可されたオープンブックテスト。

これにより、学習データに含まれない最新情報や社内の極秘情報にも答えられるようになる。

現場における核心：ハルシネーションの抑止と「構造化」の壁

企業が RAG を導入する最大の理由は、AI がもっともらしい嘘をつく「ハルシネーション」を抑止し、回答の根拠(参照元ファイル)を提示させるため。しかし、絶対に押さえておきたいのは、RAG は「参照する情報源の構造化」が大前提(Garbage in, Garbage out)だという点。社内の PDF や Word が散らかっていると、AI の出力品質も致命的に低くなる。精度は「検索ソースの質」、長文を AI が理解しやすいサイズに切り分ける「チャンク分割の設計」、そして「プロンプトの工夫」で決まるため、泥臭い情報の整理こそが成功の鍵を握る。

実務における導入ステップ

社内 AI チャットボット・FAQ 自動応答・ナレッジ検索などで使われる。プロジェクトは必ず、「情報源の棚卸し(不要なファイルの削除) → チャンク化設計 → プロンプト設計」という順で段階的に進めるのが鉄則。

Web 担当者が陥りやすい落とし穴とリアルな対策(運用の闇)

「AI は魔法」という幻想による準備不足：RAG というシステムだけ導入すれば勝手に賢くなると思い込み、事前の参照ドキュメントの整備(棚卸しと構造化)を怠ってプロジェクトが座礁する。
【最重要】運用フェーズでの情報の腐敗：無事に導入できた後、社内ルールや商品価格が変わったのに、RAG が読み込んでいる元のドキュメントを更新するフローが決まっていない罠。結果として「AI が古い情報や不正確な情報をドヤ顔で返し続ける」ようになり、現場の誰も使わなくなる。導入前に「誰が・いつ・どうやって参照元ファイルを最新に保つか」という運用体制まで設計しておく必要がある。

言葉をよく利用する人

Web 担当者(発注側)
AI 活用担当 / プロンプトエンジニア
情シス
バックエンドエンジニア

会話上での使用例

社内向けのAIチャットボット導入を情シスと相談する場面

情シス
社内のFAQ問い合わせをAIで自動化したいと考えているんですが、実現できそうですか。
Web担当者
RAGという、社内ドキュメントを検索しながら回答を組み立てる構成が一般的です。ただ前提として参照元の整理が必要なので、ドキュメントの棚卸し、チャンク分割の設計、プロンプト設計という順番で進めるのがよいと思います。
情シス
なるほど、まず資料を整えるところからですね。

チャットボットが古い情報を返すと指摘され、原因を切り分ける場面

プロデューサー
AIチャットボットが古い料金を案内してしまったと現場から報告が来ました。
Web担当者
RAGが参照しているソースを一度確認させてください。古いPDFが混ざっているか、最新版のドキュメントの構造化が追いついていない可能性が高いです。
プロデューサー
では参照元の中身から見直しましょう。