RAGとは
最終更新: 2026年8月12日
質問に関係しそうな文書を探してきて、それをAIに読ませてから答えさせる。 これだけです。Retrieval（検索）してAugment（足して）Generate（答える）の頭文字です。
ポイントはAIが覚えているわけではないところ。 毎回その場で資料を渡しているので、 資料を直せば答えも変わりますし、 どの文書を根拠にしたかを示せます。
似た目的の4つを並べる
「社内の情報をAIに答えさせたい」という要望に対して、選択肢は4つあります。 混同されやすいので並べます。
| やり方 | 何をするか | 向いている | 向かない | かかるもの |
|---|---|---|---|---|
| RAG（検索して渡す） | 質問に関係しそうな文書を探してきて、AIに読ませる | 資料が多い・よく更新される・出典を示したい | 文書を横断して数える、集計するような問い | 検索の仕組みを作る手間。渡す量ぶんのトークン |
| ファインチューニング（学習させる） | モデル自体に、その分野の話し方や形式を覚えさせる | 決まった形式で出したい・独特の文体や専門用語に合わせたい | 内容が頻繁に変わる。覚えた知識は更新しにくい | 学習データの用意と学習の費用。作り直しも高い |
| MCP（道具をつなぐ） | AIが自分でシステムを呼び出して、読む・書く・実行する | リアルタイムの情報・操作させたい | 静的な文書を大量に読ませるだけの用途 | 権限とセキュリティの設計 |
| 全部渡す（長いコンテキスト） | 資料をまるごとプロンプトに入れる | 資料が少ない・その場かぎり | 資料が多い。毎回送るので費用が積み上がる | 毎回のトークン。いちばん高くつきやすい |
いちばん多い誤解が「RAGかファインチューニングか」という二択です。 この2つは目的が違います。 知識を持たせたいならRAG、話し方や形式を合わせたいならファインチューニング。 内容が変わるものを学習させると、更新のたびに作り直すことになります。
MCPとの違いもよく聞かれます。 RAGは読む方向だけ、MCPは操作もできるのが違いです。 詳しくはMCPとはに書きました。
「長いコンテキストがあればRAGは要らない」か
モデルが一度に読める量が増えたので、 資料を全部渡してしまえばいいという話が出ます。 資料が数ページなら、それが正解です。作る手間がかかりません。
問題は量が増えたときです。
- 毎回その量ぶんの費用がかかる。 1回だけなら気になりませんが、1日に何百回も動かすなら効いてきます。
- 関係ない情報が混ざると精度が落ちる。 渡す量を増やすほど良くなるわけではありません。
- 会話履歴と合わさって積み上がる。 資料と履歴の両方が毎回送られると、伸び方が急になります （コンテキストエンジニアリングで計算しています）。
つまり「渡す量を減らすための仕組み」としてRAGを見ると、位置づけがはっきりします。 全部渡せるかどうかではなく、全部渡す必要があるかどうかの問題です。
うまくいかないとき、疑うのはたいてい検索のほう
RAGの相談で多いのが「AIが正しく答えてくれない」というものですが、 原因の多くはAIではなく検索側にあります。 渡っていない資料について、AIは答えようがありません。
| 症状 | たいていの原因 | 見るところ |
|---|---|---|
| 資料にあるはずのことを「わかりません」と言う | 検索が拾えていない | 検索側の問題です。文書の切り方（チャンク）が細かすぎる／粗すぎる、質問の言い回しと文書の言い回しが違う、といった原因を疑います。 |
| 関係ない資料の内容を混ぜて答える | 拾いすぎている | 渡す件数を減らします。10件渡すより3件のほうが精度が上がることはよくあります。 |
| 古い情報で答える | 索引が更新されていない | 文書を更新したら索引も作り直す必要があります。ここが自動化されていないと、じわじわ古くなります。 |
| 出典が間違っている | どの文書から答えたかを持ち回っていない | 検索結果に文書のIDや見出しを含め、それを引用させます。あとから確かめられる形にします。 |
| 費用が思ったより高い | 毎回たくさん渡している | 渡す件数と1件あたりの長さを見直します。会話履歴と合わさると積み上がります。 |
切り分けの方法は単純です。 検索で拾ってきた文書を、そのまま目で見る。 そこに答えが載っていなければ検索の問題、 載っているのに間違えているならプロンプトかモデルの問題です。 ここを見ずにプロンプトを直し続けるのが、いちばんよくある回り道です。
作る前に決めておくこと
- 文書をどう切るか。 長すぎると関係ない部分が混ざり、短すぎると文脈が失われます。 見出し単位で切るのが扱いやすい出発点です。
- 何件渡すか。 多ければいいわけではありません。3〜5件から始めて、 足りなければ増やすほうが調整しやすくなります。
- 出典をどう持ち回るか。 後から「どこに書いてあったのか」を確かめられないと、 間違いに気づけません。
- 索引をいつ更新するか。 文書を直したら索引も作り直す必要があります。 自動化しておかないと、必ず古くなります。
- 合っているかをどう測るか。 「よく分からないけど良さそう」で運用すると、 直したつもりで悪化しても気づけません （Evals（評価））。
層のなかでの位置づけ
RAGはコンテキストエンジニアリングの一手法です。 「何を渡すか」を決める話なので、5つの層でいえば内側から2番目にあたります。 規格でも設計パターンでもなく、渡す情報を選ぶやり方のひとつです。
- AIエージェント設計の5階層マップ — 用語の位置づけを1枚で
- コンテキストエンジニアリング — 渡す量と費用の関係
- MCPとは — 読むだけでなく操作もさせる場合
- Evals（評価） — 精度が上がったかを確かめる
渡している文書が何トークンあるかはトークン数の計算で数えられます。
本記事は2026年8月時点で一般に共有されている考え方を整理したものです。実装の方法や適した構成は用途・データ量・要件によって大きく変わります。特定のフレームワークやサービスを推奨するものではありません。