RAGって何？AIに「自分の資料」を読ませたいエンジニアのための入門ガイド
RAGって何？AIに「自分の資料」を読ませたいエンジニアのための入門ガイド
はじめに——「AIは賢いけど、うちのことは知らない」問題
最近、業務でChatGPTやClaudeを使う機会が増えた方も多いのではないでしょうか。私もここ数年、生成AIをプロダクトに組み込む仕事をしてきました。
そんな中でよく聞くのが、こんな声です。
「ChatGPTってすごく賢いけど、うちの社内マニュアルとか、製品仕様書とか、そういうのは全然答えられないんだよね」
これ、本当にその通りなんです。
ChatGPTのような大規模言語モデル（LLM）は、インターネット上の膨大なテキストを学習しています。だから一般的な知識についてはかなり詳しい。でも、あなたの会社の内部資料や、最新の製品情報、お客様との過去のやり取りなんかは、当然ながら知りません。
じゃあ、どうすればAIに「自分たちの情報」を理解させられるのか？
その解決策の一つとして注目されているのが、今回お話しする**RAG（ラグ）**という技術です。
RAGとは何か——まずはざっくりと
正式名称と基本的な考え方
RAGは「Retrieval-Augmented Generation」の略です。日本語にすると「検索で補強された生成」という感じでしょうか。
……と言われても、ちょっとピンと来ないですよね。
私なりに噛み砕くと、こういうことです。
「AIが回答を作る前に、関連する資料を検索して読ませる仕組み」
たとえば、こんなイメージです。
- ユーザーが「製品Aの保証期間は？」と質問する
- システムが社内の製品マニュアルから、製品Aに関する部分を検索して取り出す
- 取り出した情報をAIに渡して、「この資料を参考にして答えてね」とお願いする
- AIが資料を踏まえて回答を生成する
要するに、AIが「カンニング」できるようにしてあげるわけです。自分の知識だけで答えるんじゃなくて、手元に資料を置いて、それを見ながら答えてもらう。そんなイメージが近いと思います。
なぜRAGが必要なのか
ここで「じゃあ、AIにうちの資料を全部学習させればいいんじゃない？」と思う方もいるかもしれません。
実は、それにはいくつか難しい点があります。
1. 学習（ファインチューニング）にはコストがかかる
AIモデルに新しい知識を「覚えさせる」には、追加学習（ファインチューニング）という作業が必要です。これには専門的な知識、計算リソース、そして時間がかかります。資料が更新されるたびにやり直すのも大変です。
2. 情報の鮮度を保つのが難しい
学習させた時点の情報で固定されてしまうので、「先週更新されたマニュアル」の内容を反映させるには、また学習し直す必要があります。
3. 「どこから持ってきた情報か」がわからなくなる
学習してしまうと、AIの中に知識が溶け込んでしまいます。「この回答の根拠はどの資料？」と聞かれても、明確に答えられなくなるんです。
RAGなら、これらの問題をある程度クリアできます。
- 資料を「検索できる形」で置いておけばいいので、学習し直す必要がない
- 資料を更新すれば、すぐに最新情報を参照できる
- 「この資料のこの部分を参考にしました」と示せる
特に3つ目は、業務で使う上では結構重要です。お客様に「AIがこう言ってました」と説明するとき、根拠を示せるかどうかで信頼度が全然違いますから。
RAGの仕組みをもう少し詳しく——ベクトルデータがカギ
「検索」と言っても、キーワード検索じゃない
RAGの中核にあるのは「検索」の部分なのですが、ここがちょっと面白いんです。
普通、検索というと「キーワードが一致するものを探す」というイメージがありますよね。Googleで検索するときも、基本的には入力した言葉が含まれるページを探しています（実際にはもっと複雑ですが）。
でも、RAGで使われる検索は、ちょっと違います。**「意味が近いものを探す」**という検索です。
たとえば、「返品のやり方」と「商品を返却する方法」は、使っている言葉は違いますが、意味としてはほぼ同じですよね。キーワード検索だと、この2つが一致しないことがあります。でも「意味で探す」検索なら、ちゃんと見つけられる。
これを実現するのが、ベクトルデータという技術です。
ベクトルデータって何？
「ベクトル」という言葉、高校の数学で聞いた記憶がある方もいるかもしれません。矢印で表すやつですね。
機械学習の世界でのベクトルは、もう少し抽象的で、**「数字の並び」**と思っていただければ大丈夫です。
たとえば、[0.12, -0.34, 0.56, 0.78, ...] みたいな感じで、数百〜数千個の数字が並んだものです。
で、ここからが大事なところなのですが、文章をこの「数字の並び」に変換できるんです。
この変換を行うのが「埋め込みモデル（Embedding Model）」と呼ばれるAIです。
文章をベクトルに変換すると、意味が近い文章は、ベクトルも近くなるという性質があります。
数学的に言うと、ベクトル同士の「距離」や「角度」を計算して、近いかどうかを判定できる。だから、「返品のやり方」というベクトルと、「商品を返却する方法」というベクトルは、数値的に「近い」ことがわかるわけです。
ちょっと不思議な感じがしますよね。私も最初に知ったときは「文章が数字になるってどういうこと？」と思いました。
イメージとしては、文章の「意味」を、多次元の空間上の点として表現しているという感じでしょうか。似た意味の文章は、その空間上で近い場所に置かれる。だから距離を測れば、似ているかどうかがわかる。
この仕組みを使って、RAGは「質問に意味的に近い資料」を見つけ出しているんです。
RAGの全体の流れ
改めて、RAGがどう動くのか、全体像を整理してみます。
【事前準備】
- 社内資料やマニュアルなど、参照させたいドキュメントを用意する
- ドキュメントを適切なサイズに分割する（チャンキングと呼びます）
- 分割した各パーツを、埋め込みモデルでベクトルに変換する
- ベクトルを専用のデータベース（ベクトルデータベース）に保存する
【質問が来たとき】
- ユーザーの質問を受け取る
- 質問文をベクトルに変換する
- ベクトルデータベースで、質問ベクトルに近いドキュメントを検索する
- 見つかったドキュメント（複数の場合もある）を、質問と一緒にLLMに渡す
- LLMが、渡された情報を参考にして回答を生成する
- 回答をユーザーに返す
これがRAGの基本的な流れです。
実際に使ってみて感じたこと——良かった点
私がRAGをプロダクトに組み込んだ経験から、良かった点をいくつかお話しします。
1. 思ったより「それっぽい」回答ができる
正直なところ、最初は半信半疑でした。「本当にちゃんと資料を読んで答えてくれるの？」と。
でも、ちゃんと設定すれば、かなりの精度で資料の内容を反映した回答を返してくれます。
たとえば、100ページくらいある製品マニュアルを登録して、「このエラーコードが出たらどうすればいい？」と聞くと、該当する部分を見つけて、わかりやすく説明してくれる。
社内のサポートチームに聞くのと遜色ないレベルの回答が返ってくることも珍しくありません。これには素直に感心しました。
2. 更新が楽
資料が更新されたら、その部分だけ再度ベクトル化して登録し直せばOKです。
モデル全体を学習し直す必要がないので、運用の負担がずいぶん軽くなります。
私が関わったプロジェクトでは、毎週更新される情報をRAGに反映させていましたが、自動化の仕組みを作ってしまえば、ほぼ手間なく最新情報を反映できていました。
3. 「出典」を示せる
回答と一緒に「この情報は○○マニュアルの△△章から取得しました」と表示できます。
これ、地味に重要です。
AIの回答を鵜呑みにするのは怖いですが、「元の資料を確認できますよ」と言えれば、使う側も安心できます。実際、この機能があることで、社内での導入がスムーズに進んだケースがありました。
実際に使ってみて感じたこと——正直、苦労した点
一方で、うまくいかないこと、悩んだこともたくさんあります。ここは正直に書いておきます。
1. チャンキング（分割）の加減が難しい
資料をどのくらいの大きさに分割するか、これが意外と難しいんです。
細かく分割しすぎると、文脈が失われて、検索で見つかっても意味がわからない断片になってしまう。
大きく分割しすぎると、関係ない情報まで含まれてしまって、AIが混乱したり、回答が冗長になったりする。
さらに、資料の種類によって最適な分割サイズが違うこともあります。FAQみたいな短い文章と、長文の技術文書では、扱い方を変える必要がある。
私の経験では、最初から正解を見つけるのは難しくて、何度か試行錯誤しながら調整していく形になりました。「500文字くらいで区切る」とか「段落単位で分ける」とか、いくつかパターンを試して、実際に質問を投げてみて、回答の質を見ながら決めていく感じです。
2. 検索精度が期待どおりにいかないことがある
「意味が近いものを探す」と言っても、万能ではありません。
専門用語や固有名詞が多い領域だと、埋め込みモデルがうまく「意味」を捉えられないことがあります。たとえば、社内でしか使わない略語とか、製品のコードネームとか、そういうのは正しく扱えないことがある。
また、質問の仕方によっても結果が変わります。「製品Aの価格」と聞くのと「Aっていくら？」と聞くのとでは、検索結果が違ってくることがあるんです。
このあたりは、ベクトルデータによる検索だけでなく、従来のキーワード検索も併用する「ハイブリッド検索」というアプローチで改善できる場合があります。実際、両方を組み合わせているシステムも増えています。
3. LLMが「検索結果を無視する」ことがある
検索でちゃんと関連資料を取ってきているのに、LLMがそれを無視して、自分の「知識」で回答してしまうことがあります。
特に、LLMが学習時に知っている一般的な知識と、資料に書いてある情報が微妙に違う場合、LLM側の知識が優先されてしまうことがある。
「渡した資料に基づいて回答してね」というプロンプト（指示文）を工夫することで改善できることもありますが、完全にはコントロールしきれない部分があります。
これは正直、今でも試行錯誤中です。プロンプトの書き方を変えたり、「資料に書いていないことは『わかりません』と答えてね」と明示的に指示したり、いろいろな工夫をしています。
4. コストを意識しないといけない
RAGを動かすには、いくつかのコストがかかります。
- ベクトルデータベースの運用コスト
- 埋め込みモデルのAPI利用料（または自前で動かす場合のサーバー代）
- LLMのAPI利用料
特に、質問が来るたびにLLMを呼び出すので、利用量が増えるとAPI料金がそれなりにかかります。
このあたりは、事前にちゃんと試算しておかないと、「思ったより費用がかさんだ」ということになりかねません。私も一度、想定より利用が伸びてしまって、急いでコスト最適化を考えたことがあります。
RAGを始めるには——技術的なポイント
ここからは、もう少し技術的な話をしてみます。興味がある方向けです。
ベクトルデータベースの選択
ベクトルデータを保存・検索するための専用データベースがあります。代表的なものをいくつか挙げると：
- Pinecone: クラウドで提供されていて、セットアップが簡単
- Weaviate: オープンソースで、自分でホスティングもできる
- Qdrant: こちらもオープンソース、Rust製で高速
- Chroma: Python向けに作られていて、手軽に始められる
- pgvector: PostgreSQLの拡張機能として使える
小規模なプロトタイプなら、ChromaやpgvectorあたりでサクッとThe試すこともできます。本番運用を考えるなら、スケーラビリティや運用のしやすさも考慮してて選ぶことになると思います。
私が最初に試したのはChromaでした。Pythonで数行書くだけで動かせるので、「とりあえず動くものを作って感覚をつかむ」には良かったです。
埋め込みモデルの選択
文章をベクトルに変換するモデルもいくつか選択肢があります。
- OpenAI Embeddings: text-embedding-ada-002やtext-embedding-3-smallなど
- Cohere Embed: 多言語対応が比較的充実している
- オープンソースモデル: sentence-transformers系など、自前でホスティング可能
日本語を扱うなら、日本語に対応しているか、日本語での精度はどうか、というのも確認ポイントです。
OpenAIのモデルは手軽に使えて精度も安定している印象ですが、API呼び出しになるので、データを外部に送ることになります。セキュリティ要件が厳しい場合は、オープンソースモデルを自前で動かすことも検討することになります。
LLMの選択
回答を生成するLLMも選ぶ必要があります。
- OpenAI: GPT-4o、GPT-4o-miniなど
- Anthropic: Claude 3.5 Sonnet、Claude 3 Haikuなど
- Google: Geminiシリーズ
- オープンソース: Llama 3、Mistralなど
長いドキュメントを参照させたい場合は、コンテキストウィンドウ（一度に処理できるテキストの長さ）が大きいモデルを選ぶ必要があります。
コスト、精度、レスポンス速度、どこまでデータを外部に出せるかなど、いろいろな要素を考慮して選ぶことになります。
フレームワーク・ライブラリ
RAGを実装するためのフレームワークやライブラリも充実してきています。
- LangChain: RAGに限らず、LLMアプリケーション全般を構築するためのフレームワーク
- LlamaIndex: 特にデータのインデックス化やRAGに強みがある
- Haystack: 検索システム構築のためのフレームワーク
これらを使うと、ベクトルデータベースへの登録、検索、LLMへの受け渡しといった一連の処理を、比較的簡単に実装できます。
私はLlamaIndexを使うことが多いです。RAGに特化した設計になっていて、「こういうことをしたい」というのが直感的に書ける印象があります。ただ、開発が活発で頻繁にアップデートがあるので、ドキュメントを追いかけるのがちょっと大変なときもあります。
RAGをうまく使うためのコツ——実務から学んだこと
1. まずは小さく始める
いきなり大量の資料を登録しようとせず、まずは限られた範囲で試すのがおすすめです。
10ページくらいの資料を登録して、いくつか質問を投げてみて、どんな回答が返ってくるか見てみる。そこで感覚をつかんでから、徐々に範囲を広げていく。
私も、最初に「よし、全部入れよう」と意気込んで数百ファイルを一気に処理しようとしたことがありますが、問題が起きたときにどこを直せばいいかわからなくなって、結局やり直しになりました。
2. 評価の仕組みを作っておく
「ちゃんと動いているか」を確認する方法を、早めに用意しておくといいです。
たとえば、想定される質問と、期待する回答（または参照してほしい資料）のペアをいくつか用意しておいて、定期的にテストする。
これがないと、「なんとなく動いている気がする」という状態になりがちです。資料を更新したら精度が下がった、みたいなことにも気づきにくくなります。
3. プロンプトを丁寧に設計する
LLMに渡すプロンプト（指示文）は、回答の質に大きく影響します。
「以下の資料を参考にして、ユーザーの質問に答えてください」というシンプルな指示でも動きますが、もう少し詳しく指示すると精度が上がることがあります。
たとえば：
- 資料に書いていないことは「情報がありません」と答える
- 回答の根拠となる箇所を引用する
- 専門用語は平易な言葉で言い換える
こういった指示を追加することで、より使いやすい回答が得られることがあります。
4. ユーザーのフィードバックを集める
実際に使ってもらうと、想定していなかった質問の仕方をされることがあります。
「この回答は役に立ちましたか？」みたいなフィードバックを集める仕組みがあると、どこを改善すればいいかが見えてきます。
私が関わったプロジェクトでは、フィードバックをもとに「こういう質問にはこう答えてね」という例を追加していったところ、徐々に回答の質が上がっていきました。
よくある疑問にお答えして
Q. ファインチューニングとRAG、どっちがいいの？
これ、よく聞かれます。
私の理解では、用途によって使い分けるのがよいと思っています。
RAGが向いているケース：
- 情報が頻繁に更新される
- 「この情報はどこから来たか」を明示したい
- 特定のドキュメントに基づいた回答をさせたい
ファインチューニングが向いているケース：
- 特定のスタイルや口調で回答させたい
- 特定のタスクに特化した挙動をさせたい
- 回答速度を重視する（RAGは検索の分だけ時間がかかる）
両方を組み合わせることもあります。ファインチューニングしたモデルにRAGで情報を補強する、といったパターンです。
まずはRAGから試してみて、それで足りなければファインチューニングを検討する、という順番が現実的かなと思います。RAGのほうが手軽に始められますので。
Q. 機密情報を扱っても大丈夫？
これは慎重に考える必要があります。
クラウドのAPIを使う場合、データがそのサービス提供者に送信されることになります。OpenAI、Anthropicなど各社、データの取り扱いについてはポリシーを公開していますが、自社のセキュリティ要件と照らし合わせて確認する必要があります。
機密性が高い情報を扱う場合は：
- オンプレミスやプライベートクラウドで動かせるオープンソースモデルを使う
- データの匿名化・マスキングを行う
- アクセス制御をしっかり設計する
といった対策を検討することになります。
私が関わった案件でも、「データを外に出せない」という制約があったので、オープンソースモデルを自社環境で動かす構成にしたことがあります。構築の手間はかかりますが、セキュリティ要件を満たすためには必要な判断でした。
Q. どのくらいの精度が出る？
正直に言うと、「場合による」としか言えません。
資料の質、質問の仕方、チャンキングの設計、使用するモデルなど、多くの要素が絡み合います。
私の経験では、ある程度整理されたドキュメント（マニュアルやFAQなど）に対する質問であれば、体感で7〜8割くらいはまともな回答が返ってくる印象です。ただ、複数の資料を横断して考える必要がある複雑な質問や、資料に明確に書かれていないことを聞かれると、精度が落ちることがあります。
「完璧を目指す」よりも「ある程度の精度で、人間がチェックしやすい形で出力する」という設計のほうが、実用上は現実的かなと思っています。
RAGのこれから——個人的な所感
RAGという技術自体は、ここ1〜2年で急速に普及しました。私が最初に触ったころと比べると、ツールやサービスも充実して、ずいぶん始めやすくなったと感じます。
一方で、まだ発展途上の部分も多いです。
- より長いコンテキストを扱えるモデルが出てきて、「そもそも全部渡せばいいのでは」という議論もある
- 検索精度を上げるための手法（リランキング、ハイブリッド検索など）が日々進化している
- エージェント的なアプローチ（AIが自律的に検索を繰り返して情報を集める）との組み合わせも研究されている
数年後には、今の「RAG」という枠組み自体が古くなっている可能性もあります。技術の進化は速いので。
ただ、「外部の情報を参照してAIに回答させる」という基本的な考え方は、形を変えながらも残っていくんじゃないかと思っています。AIが「自分の知識だけで答える」のではなく、「必要な情報を探して、それを踏まえて答える」という発想は、人間の思考プロセスにも近いですしね。
おわりに——まずは触ってみてほしい
RAGについて、私なりに噛み砕いてお話ししてきました。
正直なところ、文章で読むだけだとピンと来ない部分もあると思います。私も、実際に手を動かして作ってみて初めて「ああ、こういうことか」と腹落ちした部分がたくさんあります。
今は、LlamaIndexやLangChainを使えば、数十行のコードでRAGの基本形は動かせます。チュートリアルも充実しています。まずは手元のPDFファイルを1つ読み込ませて、質問を投げてみる、くらいから始めてみてはいかがでしょうか。
完璧なシステムを作ろうとしなくていいと思います。「へー、こんな感じで動くんだ」という感覚をつかむことが、最初の一歩になります。
私自身、まだまだ試行錯誤の途中です。チャンキングの最適解も見つかっていませんし、プロンプトの書き方もプロジェクトごとに模索しています。
でも、その試行錯誤が、この技術の面白いところでもあると思っています。
もしRAGを試してみて、「こういう課題があった」「こうしたらうまくいった」ということがあれば、ぜひどこかで共有してください。私も、他の方の経験から学ぶことが多いですから。
長くなりましたが、この記事がRAGを理解する一助になれば幸いです。
