RAGのアーキテクチャとデータ登録・ユースケース
RAGのアーキテクチャとデータ登録・ユースケース
RAG（Retrieval-Augmented Generation）は、LLMに外部ナレッジを注入する技術として注目されている。しかし、実際のところ「いつRAGが必要で、いつ不要なのか」は意外と語られていない。
この記事では、RAGの基本的なアーキテクチャを説明しつつ、コーディングエージェントの検索機能との比較、データ登録の実際の手間、そしてRAGの限界まで踏み込んで解説する。
関連する概念ノート
- RAG
- セマンティック検索
- ベクトルデータベース
- 埋め込み
- チャンキング
- ファインチューニング
- リランキング
- ハイブリッド検索
- PageIndex - ベクトルレスRAGの新しいアプローチ - 階層的推論による検索の発展形
LLMの限界とRAGの登場
LLMは強力だが、以下の制約がある：
- 学習データの時点性：モデルの学習時点までの情報しか持たない
- 独自データへのアクセス不可：企業の内部文書、個人のメモは知らない
- コンテキストウィンドウの制約：一度に処理できる情報量に上限がある（Claude 3.5 Sonnetで約200kトークン）
RAGは、これらの制約を「外部データベースから情報を検索して、LLMに渡す」ことで解決しようとする技術だ。
ファインチューニングとの違い
RAGとよく比較されるのがファインチューニング（Fine-tuning）だ。
| 手法 | 仕組み | 適したケース | 更新コスト |
|---|---|---|---|
| ファインチューニング | モデル自体を再学習 | 文体、出力形式の調整 | 高（再学習が必要） |
| RAG | 検索結果をプロンプトに追加 | 知識の追加・更新 | 低（データ追加のみ） |
ファインチューニングは「モデルの振る舞い」を変えるのに適しており、RAGは「知識の追加」に適している。両者は排他的ではなく、併用も可能だ。
RAGが本当に必要なのはどんな時か？
ここが最も重要なポイントだ。実は、RAGを使わなくても解決できるケースは多い。
パターンA：コーディングエージェントで十分なケース
Claude CodeやCursorのようなコーディングエージェントは、以下のような検索を行う：
ユーザー：「認証機能のコードを教えて」
↓
1. Grepで "auth" "login" などをキーワード検索
2. 関連ファイル10個を発見
3. その10個を全文読み込み（数千〜数万トークン）
4. LLMが全体を見て回答を構築
この方式の利点：
- 情報の取りこぼしがない：関連ファイルを全て読むので、重要な情報を見逃さない
- セットアップ不要：ファイルシステムがあればすぐ使える
- コンテキストが豊富：前後の文脈を含めて理解できる
限界：
- キーワードベース：Grepは文字列一致しか見ない
- 規模の限界：関連ファイルが100個あると、全部読むのは無理
発展形：階層的推論アプローチ（PageIndex等）
このエージェント方式の発展として、階層的インデックス + 推論ベース検索という新しいアプローチが登場している（例：PageIndex）：
1. 事前に文書から階層的な「目次」構造を生成
2. LLMが階層を段階的に評価
3. 関連する部分だけを深く掘り下げる
4. 必要なセクションのみを読み込み
この方式は：
- エージェント方式の「全文読み込み」を階層化して効率化
- AlphaGo式の「賢い枝刈り」で無駄な読み込みを削減
- 初期コストは高いが、検索を繰り返すほど効率的
詳細はPageIndex - ベクトルレスRAGの新しいアプローチを参照。
パターンB：RAGが必要なケース
RAGが真価を発揮するのは以下の条件を満たす時：
1. セマンティック検索が必要
キーワードが分からない状態で探す場合：
例：
- 「エラーが起きたときの対処法を教えて」
- Grep：
errorしか探せない - RAG：「例外処理」「リトライロジック」「フォールバック」など、意味が近い文書も拾える
- Grep：
2. エンドユーザーが直接使う
コーディングエージェントのような段階的検索ができないケース：
- カスタマーサポートボット：ユーザーは検索スキルを持たない
- 社内検索システム：非エンジニアが「なんとなく」質問する
3. 大規模データで全文読み込みが不可能
データ量がコンテキストウィンドウを超える場合：
- 数万件の問い合わせチケット
- 複数のGitHubリポジトリ（数十万行）
- 数千ページの社内ドキュメント
この場合、Grepで全部読むことは物理的に不可能なので、RAGが唯一の選択肢になる。
使い分けの基準
| 条件 | 推奨手法 |
|---|---|
| ファイル数〜300、エンジニアが使う | Grep + 全文読み込み |
| ファイル数300〜、または非エンジニアが使う | RAGを検討 |
| ファイル数1000以上、または複数データソース横断 | RAG必須 |
重要なのは、「とりあえずRAG」ではなく、まずシンプルな検索から始めることだ。
シンプルRAGのアーキテクチャ
RAGの最もシンプルな構成は、以下の4ステップで構成される。
1. データ準備とチャンキング
元データ（ドキュメント、コード、FAQ）を小さな単位（チャンク）に分割する。
チャンクサイズの例：
- 文章：200〜500トークン（約150〜400語）
- コード：関数単位、またはクラス単位
- 会話履歴：1メッセージ単位
チャンクが小さすぎると文脈が失われ、大きすぎると検索精度が下がる。
2. 埋め込み（Embedding）生成
各チャンクを埋め込みモデルに通して、ベクトル（数値の配列）に変換する。
埋め込みモデルの例：
- OpenAI
text-embedding-3-small（クラウド、従量課金） all-MiniLM-L6-v2（ローカル、無料）
埋め込みは「意味の近さ」を数値で表現する。例えば：
- 「ログイン機能」と「認証システム」は近いベクトルになる
- 「ログイン機能」と「データベース設計」は遠いベクトルになる
3. ベクトルデータベースへの保存
生成した埋め込みをベクトルデータベースに保存する。
ベクトルDBの例：
- クラウド：Pinecone、Weaviate、Qdrant
- ローカル：Chroma、FAISS
ベクトルデータベースは「類似ベクトル検索」に特化したデータベースで、通常のSQLデータベースとは異なる。
4. 検索と生成
ユーザーのクエリ（質問）が来たら：
- クエリを埋め込みモデルに通してベクトル化
- ベクトルデータベースで類似度が高いTop-K（例：5チャンク）を取得
- 取得したチャンクをプロンプトに埋め込んでLLMに渡す
- LLMが回答を生成
プロンプト例：
以下の情報を参考に、ユーザーの質問に答えてください。
## 参考情報
[チャンク1の内容]
[チャンク2の内容]
[チャンク3の内容]
...
## ユーザーの質問
認証機能の仕組みを教えて
データ登録と日々の運用
ここでは、管理者視点での「実際の手間」を見ていく。
初期構築（1回のみ）
- データソースの選定：Notion、Slack、GitHubなど
- データの取り込み：APIまたはエクスポート機能で取得
- クリーニング：不要な情報（ヘッダー、フッター、広告）を削除
- チャンキング設定：サイズと重複を決定
- 埋め込み生成：全データに対して実行（数時間〜数日）
- ベクトルDBセットアップ：インデックス作成
工数目安：1週間〜2週間（規模による）
日々の運用（継続的）
運用パターンは大きく3つに分かれる：
パターンA：バッチ更新型（自動化）
例：社内Wiki、GitHubリポジトリ
- 新規ファイルを自動検知 → 埋め込み生成 → DBに追加
- 更新頻度：毎晩、または毎時
- 管理者の手間：ほぼゼロ（エラー監視のみ）
パターンB：半自動型（手動トリガー）
例：Notionデータベース、Google Drive
- 管理者が「更新ボタン」を押す → システムが自動処理
- 更新頻度：週1回、月1回
- 管理者の手間：週5〜10分
パターンC：手動登録型（品質重視）
例：法務文書、重要な社内規定
- 管理者が1件ずつレビュー → 承認 → 登録
- 更新頻度：随時
- 管理者の手間：文書1件あたり5〜10分
運用上の注意点
1. データの鮮度管理
- リアルタイム性が必要：Slack最新会話、ニュースフィード → 高頻度更新
- 多少古くてもOK：技術文書、過去のFAQ → 低頻度更新
2. データ品質の維持
RAGの精度は元データの品質に大きく依存する：
- ノイズの多いデータ（雑談、重複文書）→ 事前フィルタリング必須
- 構造化された高品質データ → そのまま取り込める
3. 削除データの扱い
- ファイルが削除されたとき、ベクトルDBからも削除する必要がある
- 削除漏れがあると、存在しない情報を参照してしまう
4. 権限管理
- 誰が何を見られるか？
- ベクトルDB側で権限フィルタリングが必要になるケースもある（例：部署ごとに情報を分ける）
具体的なユースケース
ここでは4つのユースケースを、RAGが必要かどうかの判断も含めて詳しく見ていく。
1. 社内ナレッジベース検索
シナリオ
- Notion、Confluence、社内Wikiに蓄積された情報を検索
- 「新入社員向けのオンボーディング手順は？」「経費精算のルールは？」
データソース
- Notion全ページ（500〜数千ページ）
- Confluence スペース
- 社内規定PDF
- 過去の議事録
RAGの必要性
| 条件 | 推奨手法 |
|---|---|
| エンジニアチームのみ（〜300ページ） | Grep + 全文読み込みで十分 |
| 全社利用（500ページ以上） | RAG推奨 |
| 非エンジニアが検索 | RAG推奨（セマンティック検索が必要） |
運用の手間
- 初期構築：Notion APIで全ページ取得 → 埋め込み生成（1日）
- 日々の運用：新規ページを自動で取り込み（Webhook or 日次バッチ）
- 管理者の手間：週1回、5分程度の監視（エラーチェック）
落とし穴
- 権限管理が複雑：部署ごとに見られる情報が異なる場合、ベクトルDB側でフィルタリングが必要
- 削除ページの同期漏れ：Notionで削除されたページがRAGに残り続けるリスク
- 検索精度の問題：社内用語（略語、固有名詞）が多いと、埋め込みモデルが対応できない場合がある
2. カスタマーサポートボット
シナリオ
- ユーザーからの問い合わせに自動回答
- 「パスワードを忘れました」「返品手続きを教えて」
データソース
- FAQ（100〜500件）
- 製品マニュアル
- 過去の問い合わせチケット（数千〜数万件）
- 解決済みの事例データベース
RAGの必要性
| 条件 | 推奨手法 |
|---|---|
| FAQ 50件以下 | プロンプトに直接書き込み |
| FAQ 100〜500件 | RAG推奨 |
| 過去チケット1000件以上 | RAG必須 |
運用の手間
- 初期構築：過去1年分のチケット（数千件）を取り込み
- 日々の運用：
- 新しい解決事例を手動で追加（週5〜10件）
- 「これは良い回答だった」とマークしたものをRAGに追加
- 管理者の手間：週2〜3時間（品質チェックが重要）
落とし穴
- 正確性が命：間違った情報を返すと信頼を失う
- 手動レビュー必須：全自動化は危険（特に返品、返金など重要な情報）
- 回答の一貫性：同じ質問に対して、毎回違う答えを返すとユーザーが混乱する
- 「答えられない」を判定する：該当情報がない場合、適切にエスカレーションする仕組みが必要
3. コード検索・補完
シナリオ
- 自社のコードベースから関連コードを検索
- 「ユーザー認証の実装を見たい」「このAPIの使い方は？」
データソース
- GitHubリポジトリ（複数）
- APIドキュメント、README
- 過去のPull Request、Issue
RAGの必要性
| 条件 | 推奨手法 |
|---|---|
| 1リポジトリ、1万行以下 | Grep + 全文読み込みで十分（Claude Codeなど） |
| 複数リポジトリ、または3万行以上 | RAG推奨 |
| IDE統合（Copilot的な使い方） | RAG有効 |
運用の手間
- 初期構築：リポジトリをクローン → ファイルごとに埋め込み生成
- 日々の運用：Pushごとに自動更新（GitHub Webhook + CI/CD）
- 管理者の手間：ほぼゼロ（自動化可能）
落とし穴
- チャンキングの難しさ：関数単位？ファイル単位？クラス単位？
- 関数単位：文脈が失われやすい
- ファイル単位：大きすぎて検索精度が下がる
- コードの更新頻度：頻繁に更新されるコードベースでは、埋め込みの再生成コストが高い
- 依存関係の表現：関数Aが関数Bを呼ぶ、という関係をベクトルだけで表現するのは難しい
4. 個人のセカンドブレイン
シナリオ
- 自分のメモ、読書記録、アイデアを検索
- 「以前読んだデザイン思考の本に何が書いてあったっけ？」
データソース
- Obsidian vault、Notionの個人ノート
- 読書メモ、ブログの下書き
- 日記、アイデアメモ
RAGの必要性
| 条件 | 推奨手法 |
|---|---|
| 100ノート以下 | Obsidian + Claude Codeで十分 |
| 300ノート以上 | RAG検討 |
| スマホから検索したい | RAG推奨（WebアプリやSlack botで統合） |
運用の手間
- 初期構築：既存ノート全て（数百〜数千）を取り込み
- 日々の運用：新しいノートを書くたびに自動で埋め込み生成
- 管理者（=自分）の手間：意識しないレベル（Obsidianプラグインで自動化）
落とし穴
- コスト：OpenAI Embeddingsは従量課金（月数百円〜数千円）
- 対策：ローカル埋め込みモデル（無料）を使う
- プライバシー：個人的なメモをクラウドに送るのは抵抗がある人も
- 対策：ローカルで完結するセットアップ（Chroma + ローカルLLM）
- 検索精度：個人的な略語、造語が多いとベクトル検索が効きにくい
RAGの限界と課題
ここが最も重要なセクションだ。RAGは万能ではなく、いくつかの本質的な限界を抱えている。
1. ベクトル検索の取りこぼし問題
RAGの最大の問題は、Top-Kで切り捨てられた情報は見えないことだ。
Grep + 全文読み込みとの比較
Grep方式：
「認証機能を教えて」
→ Grepで "auth" "login" 関連ファイル10個を発見
→ その10個を全部読み込む（数万トークン）
→ LLMが全体を見て回答
利点：情報の取りこぼしがない
全てのファイルを読むので、重要な情報を見逃すことがない。
RAG方式：
「認証機能を教えて」
→ ベクトル検索でTop-5チャンクを取得
→ その5チャンクだけをLLMに渡す
→ 残りの情報は見ない
問題：重要な情報が漏れる可能性
もし重要な情報がTop-5に入らなければ、LLMはそれを知らないまま回答する。
なぜこの問題が起きるのか？
RAGはコンテキストウィンドウの節約のために設計されている。
- 大規模データ（数万件）の場合、全部読むのは物理的に不可能
- だからTop-Kだけを取り出す
- しかし、その代償として情報の取りこぼしが発生する
対策：Advanced RAGのテクニック
しかし、これらの手法も完璧ではない。「Grep + 全文読み込み」の方が正確なケースは多い。
2. チャンキングの難しさ
チャンクの切り方次第で、検索精度が大きく変わる。
悪いチャンキングの例
## ユーザー認証
当社のシステムは、JWTベースの認証を採用しています。
---（ここでチャンク分割）---
ユーザーがログインすると、サーバーはトークンを発行し...
この場合、「JWT」という重要なキーワードと、その説明が別のチャンクに分かれてしまう。
結果：
- 「JWT認証について教えて」→ 前半のチャンクだけが取得される → 説明が不完全
- 「トークンの発行方法は？」→ 後半のチャンクだけが取得される → JWTという文脈が失われる
解決策：重複を持たせる
チャンク1：「当社のシステムは、JWTベースの認証を採用しています。ユーザーがログインすると...」
チャンク2：「JWTベースの認証を採用しています。ユーザーがログインすると、サーバーはトークンを発行し...」
このように、チャンク間で一部を重複させることで、文脈の断絶を防ぐ。
しかし、重複が多すぎると：
- データ量が増える → コスト増
- 同じ情報が複数回ヒットする → ノイズになる
3. 埋め込みモデルの限界
埋め込みモデルは「意味の近さ」を数値化するが、完璧ではない。
問題例
- 専門用語：社内用語、業界特有の略語は、汎用モデルでは対応できない
- 文脈依存：「Apple」が「リンゴ」なのか「企業名」なのか判断できない
- 否定の扱い：「認証は不要」と「認証は必要」が近いベクトルになる場合がある
対策
- ドメイン特化の埋め込みモデルを使う（医療、法律など）
- ファインチューニングで自社データに適応させる
- ハイブリッド検索（キーワード検索を併用）
4. コストとレイテンシ
RAGは「検索」→「生成」の2ステップなので：
- レイテンシが増える：検索に数百ms、生成に数秒
- コストが増える：埋め込み生成、ベクトルDB、LLM呼び出しの3つ
小規模データなら、RAG不要でLLMだけの方が速くて安い。
まとめ：RAGを使うべきか？
RAGは強力な技術だが、万能ではない。以下のチェックリストで判断すると良い。
RAGが必要なケース
RAG不要なケース
推奨アプローチ：3つの選択肢
| アプローチ | 適した用途 | 初期コスト | 検索コスト | 精度 |
|---|---|---|---|---|
| Grep + 全文読み込み （エージェント方式） |
〜300ファイル、エンジニア向け | なし | 高い | 高い（取りこぼしなし） |
| 階層的推論 （PageIndex等） |
長文専門文書、構造化文書 | 非常に高い | 中程度 | 非常に高い |
| ベクトルRAG | 大規模データ、非エンジニア向け | 低い | 低い | 中程度（取りこぼしあり） |
判断フロー：
- まずシンプルな方法から試す：Grep + 全文読み込み、プロンプトに直接書き込み
- 規模の限界を感じたら：
- 構造化された長文文書（金融、法律） → 階層的推論（PageIndex等）
- 大量の非構造化データ → ベクトルRAG
- 小さく始める：最初はシンプルRAG、必要に応じてAdvanced RAGに進化
重要な洞察：
RAGは「データが大きくなったら自動的に必要」ではなく、「どう使うか」で判断する技術だ。
- エージェント方式（全文読み込み）で解決できるなら、それが最もシンプル
- 階層的推論は、専門文書での精度とコストのバランスが良い
- ベクトルRAGは、汎用性が高いが「類似度≠関連性」の限界を理解する
自分のユースケースに本当にRAGが必要か、この記事の基準で見極めてほしい。