基礎知識 / FUNDAMENTALS

RAG（Retrieval-Augmented Generation）とは

外部知識を検索して LLM に渡す仕組み。何が嬉しくて、いつ使うべきで、CLIツールでどう活かすか。

公開 2026.05.17

RAG（Retrieval-Augmented Generation、検索拡張生成）は、LLM の応答を生成する前に「関連情報を検索して prompt に詰める」仕組みのこと。読み方は「ラグ」。

「学習データに入っていない情報を扱える AI」を作るための定番手法で、AI CLI ツール群でも内部的に使われている。

なぜ必要か

LLM の根本的な制約:

学習時点までの情報しか知らない（カットオフ）
個別企業の内部情報は知らない（社内仕様書、議事録、独自API等）
コンテキストウィンドウに収まらない量の情報は持てない（全社全ドキュメントを毎回 prompt に入れるのは無理）

RAG はこの3つを「必要なときに必要な部分だけ取ってくる」というアプローチで解決する。

仕組み（最小構成）

[1. 事前準備]
ドキュメント群 → チャンク分割 → embedding 化 → ベクトルDBに保存

[2. クエリ時]
ユーザー質問 → embedding 化 → ベクトルDBで類似検索
              ↓
        関連チャンク取得 → prompt に詰めて LLM に投げる → 応答

Embedding

テキストを「数百〜数千次元のベクトル」に変換する技術。意味が近い文章は近いベクトルになる。

"Pythonでファイル読み込み" → [0.23, -0.15, 0.81, ...]
"Pythonでファイル書き込み" → [0.21, -0.12, 0.79, ...]  ← 近い
"今日の天気"              → [-0.45, 0.32, 0.04, ...]  ← 遠い

ベクトルDB

embedding を高速に類似検索できる専用 DB。Pinecone、Weaviate、Chroma、pgvector（PostgreSQL 拡張）等が代表的。

検索 → 注入

ユーザー質問を embedding 化 → DB で類似度上位 5〜10件を取得 → prompt に「以下を参考に答えて」として詰める。

いつ使うべきか

向く場面

社内ドキュメントの Q&A — Notion、Confluence、Slack 等の社内情報を AI に答えさせたい
頻繁に更新される FAQ — モデルを再学習せず情報を入れ替えられる
大量のマニュアル・規程からの抽出 — 数百ページの PDF から該当箇所を探す
コードベース全体の意味検索 — 「認証関連のコード」「決済処理」のような曖昧クエリ

向かない場面

全体構造の把握が必要なタスク — 関連箇所だけ拾うと前後関係が失われる
計算・推論が必要な質問 — 検索じゃ解決しない
小規模なコンテキスト — そもそも全部 prompt に入るなら RAG 不要。直接渡したほうが質が高い
リアルタイム性が極めて重要 — embedding 計算・検索のレイテンシが入る

AI CLI ツールとの関係

実は AI CLI ツール（Claude Code、Cursor 等）は内部で RAG 的な仕組みを使っていることが多い。

コードベース検索

Cursor の @Codebase
Claude Code が「関連ファイルを自動で読む」挙動
Aider のリポマップ機能

これらは RAG の一形態。リポ全体を embedding 化しておいて、ユーザー質問に応じて関連ファイルを引っ張ってくる。

ユーザー視点だと「自動で関係ありそうなコードを参照してくれる」だけだが、裏では:

リポジトリ内コードを事前にチャンク分割 + embedding
ユーザー質問の意味検索
関連箇所を context に追加
LLM が応答生成

をやっている。

外部 RAG ツールとの組み合わせ

MCP（Model Context Protocol）経由で外部の RAG システムを CLI に接続することもできる:

社内 Notion を MCP サーバ化 → Claude Code から検索可能
自前のベクトルDB を MCP で公開 → エージェントが検索できる

詳細は MCP とはを参照。

RAG の落とし穴

導入前に知っておくべきこと。

1. チャンク分割の質が全て

ドキュメントをどの粒度で切るかが検索精度を大きく左右する。

細かすぎる → 文脈が切れて意味が失われる
大きすぎる → 1チャンクに無関係な情報が混ざる
章境界・段落境界で切るのが定石

2. embedding モデルの選択

OpenAI の text-embedding-3、Voyage の voyage-3、Cohere の embed-v3 など。日本語ドキュメントは日本語特化モデルの方が精度が出ることが多い。

3. 検索精度 ≠ 応答精度

検索結果に正しい情報が含まれていても、LLM がそれを正しく解釈・引用するかは別問題。「引用元を明示せよ」をシステムプロンプトに入れる、hallucination 検出を別途行う等の対策が必要。

4. 更新のオーバーヘッド

ドキュメントが更新されたら再 embedding が必要。バッチで定期再生成する仕組みが要る。

「fine-tuning じゃダメなの？」

よくある質問。RAG と fine-tuning は別物。

	RAG	Fine-tuning
何をする	検索結果を prompt に注入	モデル自体を追加学習
知識の更新	DB を更新するだけ	再学習が必要
出典の明示	できる	できない
コスト	低い（embedding は安い）	高い（GPU 必要）
既存事実の追加	得意	不得意（hallucination リスク）
スタイル・トーンの学習	不得意	得意

「ナレッジを増やしたい」なら RAG、「モデルの口調や応答パターンを変えたい」なら fine-tuning、というのが大まかな使い分け。

LLM とは — RAG が組み合わせる相手
MCP（Model Context Protocol）とは — 外部 RAG ツールを AI CLI に接続