RAGとは何か
📍 In One Sentence
RAG は知識ベースから関連ドキュメントを取得し、それらを質問と共にLLMに提供します。モデルは推測ではなく、あなたのデータから応答します。
💬 In Plain Terms
RAG なし = クローズドブック試験（モデルは記憶から答える、詳細を発明可能）。RAG あり = オープンブック（モデルは最初にノートを参照）。ノートを誤読しても、少なくとも事実を発明しない。
RAG は関連情報を見つけるレトリバーと、その情報を使って最終回答を執筆するジェネレータを組み合わせます。 レトリバーはユーザークエリに基づいて知識ベース（インデックス付き PDF、ウェブページ、内部ドキュメント）を検索します。ジェネレータはそれから取得された通路を読み、そのコンテンツを引用または反映した回答を生成します。
なぜRAGが重要か
**RAG は ハルシネーション を削減し、回答を最新に保つため重要です。** 純粋な言語モデルは専門的または最新の話題で自信満々に詳細を作り出すことができます。RAG を使えば、回答はあなたが管理するドキュメントに固定されます。
プライバシーとガバナンスにおいても重要です。機密データでモデルをトレーニングする代わりに、そのデータを自社ストアに保管し、クエリ時に関連スニペットのみをモデルに供給できます。モデルはあなたのコンテンツについて推論しますが、永続的に吸収することはありません。
取得したい文書がインフラ外に出せない場合、RAG パイプライン全体を自分のハードウェアで動かすことができます。GDPR 対応のアーキテクチャ、監査ログ、デプロイパターンについては、業務データのためのローカル RAGを参照してください。
RAGシステムの仕組み
典型的な RAG システムは 4 つの主段階を実行：取得、索引化、検索、生成。 各段階は独立して調整可能です。
このパイプラインを自分の PDF とローカルモデルで動かす手順については、自分の PDF でローカル RAG をステップバイステップで動かすを参照してください。
- 1取得：ドキュメント（PDF、知識ベース記事、チケット、コード）を読み込み、チャンク化。メタデータ（タイトル、日付、作成者、タグ）を附属させることができます。
- 2索引化：各チャンクを埋め込みモデルでベクトル表現に変換し、ベクトルデータベースまたは検索インデックスに保存。新しいクエリに対してセマンティックに類似したコンテンツを検索。
- 3検索：ユーザーが質問を入力すると、システムはクエリをベクトル化して最も関連のあるチャンクをインデックスから取得。フィルタ（日付範囲、ドキュメント種類、ユーザーパーミッション）をこの段階で適用可能。
- 4生成：システムはユーザーの質問と取得されたチャンクを含むプロンプトを構築して言語モデルに送信。モデルは提供されたコンテキストと一貫性のある回答を生成。
🔍 検索がボトルネック
RAG の品質は 80%が検索に依存。優れたレトリバーと弱いモデル = 弱いレトリバーと GPT-5.5 より良い結果。索引化とチャンク化のチューニングに時間をかけてください。
RAG vs ファインチューニング
**RAG と ファインチューニング は異なる問題を解決し、組み合わせが最適です。** 最初に RAG から始めます。プロンプトでは実現できない一貫した動作変更が必要な場合のみファインチューニングを追加してください。
| 要素 | RAG | ファインチューニング |
|---|---|---|
| クエリ時取得 | ドキュメントから | トレーニング時にパラメータに組み込み |
| データの鮮度 | リアルタイム | 静的 |
| 機密データ | インフラに留まる | モデル重みに吸収 |
| トレーサビリティ | ドキュメント追跡可 | 出処なし |
| 更新コスト | 低 | 高 |
| スタイル変更 | 不可 | 可能 |
| 最適用途 | 変動データ | 安定動作 |
| ユースケース | Q&A | 法律文書 |
🔍 RAG 優先、その後ファインチューニング
RAG は知識を追加（可逆：ベクトルストア更新）。ファインチューニングは動作を変更（永続：再訓練）。コンテンツには常に RAG を使用、スタイル/トーンにのみファインチューニング。
例：RAG なし vs RAG あり
RAG の利点は記憶だけの回答と取得ドキュメントベースの回答を比較すると明確になります。 以下は内部ポリシー質問の概念的な例です。
悪い例 — RAG なし
"当社の出張旅費償還ポリシーは？"
モデルは一般的パターンに基づいて推測し、組織によって誤りの可能性。
良い例 — RAG あり
"あなたは当社の内部ポリシー質問に答えるアシスタントです。以下が関連ポリシー抜粋です：
...取得されたポリシーテキストチャンク...
次の質問にこれらの抜粋に基づいてのみ回答してください：「当社の出張旅費償還ポリシーは？」抜粋にない場合は「指定されていません」と述べます。"
この場合、モデルは実際のポリシードキュメントに固定され、情報が欠けている時の対応が明確です。
ベクトルデータベース比較表
正しいベクトルデータベースを選ぶことは、インフラ、レイテンシ制約、コンプライアンス要件に依存します。 以下は 6 つの主要選択肢です。
| データベース | タイプ | 最適用途 | EU データ拠点 | セルフホスト | 概算コスト |
|---|---|---|---|---|---|
| Pinecone | マネージド ベクトル（クラウド） | 素早いプロトタイピング、MVP、運用負荷最小 | はい、eu-west-1 | いいえ | 月 100～1,000€（使用量別） |
| Weaviate | ベクトル オープンソース | エンタープライズデプロイメント、ハイブリッド検索 | はい、セルフホスト | はい（Kubernetes） | 無料 + インフラ（年 500～5,000€） |
| Chroma | ベクトル 軽量 | プロトタイプ、ローカルアプリケーション、デモ | はい、ローカル | はい（Python） | 無料 |
| Milvus | ベクトル 高性能 | 数百万ベクトル、<100ms 遅延 | はい、セルフホスト | はい（Kubernetes、Docker） | 無料（オープンソース）または月 500～2,000€（サポート） |
| Qdrant | ベクトル 最新 Rust | 高度なフィルタリング + ベクトル、高性能 | はい、セルフホスト | はい | 無料または月 500～2,000€（クラウド） |
| pgvector（PostgreSQL） | PostgreSQL 拡張 | ベクトル + SQL クエリ、インフラ簡素化 | 既存 PostgreSQL を使用 | はい | 無料（拡張）+ 既存 PostgreSQL |
マルチモデルワークフローでのRAG
RAG は複数モデルと構造化プロンプティングと組み合わせるとさらに強力になります。
- ドキュメント埋め込み・検索に 1 つのモデル、回答生成に別のモデル使用。
- chain-of-thought や TRACE のような推論重点プロンプトを取得コンテキストの上に適用。
- 複数モデルで同じ RAG プロンプトを実行して、各モデルがドキュメントをどう活用するかを比較。
🔍 同じドキュメント、異なる回答
同じ RAG プロンプトを GPT-5.5、Claude Opus 4.8、Gemini 2.0 Pro で同じベクトルストアに対して実行してみてください。長さ・スタイル・コンテキスト活用が異なります。PromptQuorum は同じクエリを複数モデルにルーティングして比較を可能にします。
このモジュラリティが RAG の最大利点：検索機、インデックス、生成機、プロンプトを個別にアップグレード可能でシステム全体の再構築不要。
規制環境におけるRAG
RAG は機密データが扱われる場面で推奨される。モデルパラメータに決して入らないため。
EU / GDPR : 個人データ処理する EU 企業向けの推奨アーキテクチャ。ドキュメントはインフラに留まり、クエリ時に関連スニペットのみ LLM に渡される。個人データ外部モデルプロバイダに未送信。GDPR 第 46 条自動満足。EU AI 法第 11 条は知識源の記録が要求—バージョン管理ドキュメント保存の RAG が直接満たす。ドイツ BSI ガイドラインは機密データ処理にローカルまたは自社ホストベクトルデータベース推奨。
日本（METI）： AI 統計判断に使用データソースを記録せよという要求。キュレート・バージョン管理ドキュメント持つ RAG が正確にこの監査証跡を生成—各回答がクエリ時取得特定ドキュメントに追跡可能。日本企業デプロイメントは通常 RAG をローカル推論（Ollama 経由 LLaMA）と合わせ、すべてデータが社内インフラに留まるよう確保。
中国（CAC）： CAC 生成 AI サービス規定（2023）はプロダクション AI システム使用前に検索データソース記録・審査を要求。承認された国内ソース持つ RAG アーキテクチャが標準準拠アーキテクチャ。ベクトルデータベースプロバイダが中国データセキュリティ法（数据安全法）のデータローカライゼーション要件を満たすことを確認。
よくある間違い
❌ モデルが既に知っている知識に RAG を使用
Why it hurts: モデルが正確に知っているコンテンツ（例：Python 標準ライブラリ）取得は、トークン消費と遅延が増すだけで価値がない
Fix: RAG をドメイン固有・独占的・最新データに制限してください。一般知識は LLM パラメータに十分。
❌ チャンク化が小さすぎる（<100 単語）
Why it hurts: 周囲コンテキスト喪失。ポリシー文は隣接段落なしでは曖昧、モデルが正確に理解できない
Fix: 200～500 単語をベースラインに。あなたのドメインの代表クエリで実際にテストしてください。
❌ 関連性しきい値がない
Why it hurts: すべての取得ドキュメントが LLM に渡されるので無関連コンテキストでモデルに作業させ、ノイズと誤り増加
Fix: 最小スコア設定：>0.7 コサイン類似度。閾値を超えないドキュメントは「知識ベースに見つかりません」を返す。
❌ 検索品質と生成品質を分離テストしない
Why it hurts: 回答が間違っていても原因（検索でドキュメント取得失敗 vs 生成でモデル推論失敗）が不明
Fix: フルパイプライン評価前に 20+ 代表クエリで検索機を独立テストしてください。
❌ メタデータ（日付、所有者、権限）フィルタを使用していない
Why it hurts: 大規模ストアでも日付/部門/権限フィルタなしでは陳腐化・機密・アクセス不可コンテンツを返す
Fix: 取得時にメタデータを附属、検索時にフィルタを適用。権限ベースアクセス制御（RBAC）を実装。
RAGの実装方法
- 1AI が応答する必要がある知識ソースを特定（ドキュメント、PDF、データベース、API）。 2026 年 4 月現在、最も一般的なソースは内部 PDF、知識ベース記事、製品ドキュメント。カスタマーサポート：FAQ、製品ドキュメント、過去チケット解決。研究：論文リポジトリ、外部データベース。
- 2静的ドキュメントをベクトルデータベース（Pinecone、Weaviate、Chroma、Milvus）で検索可能な埋め込みに変換。 プロセスはドキュメントを段落または文にチャンク化、各チャンクを意味の数値表現に変換、高速セマンティック検索に保存。
- 3クエリ時：(1) ユーザー質問をベクトル化、(2) 最も類似ドキュメント取得、(3) 取得ドキュメントと質問を LLM に渡す。 例：ユーザーが「パスワードをリセット？」→ システムが関連 FAQ/ドキュメント検出 → LLM が訓練データでなくドキュメント基盤の回答生成。
- 4大規模ドキュメント集合（100+ ページ）について、チャンク化戦略を実装：200～500 単語チャンク、オーバーラップ付き。 理解と検索精度のバランス。代表クエリで チャンクサイズをテスト。
- 5取得ドキュメントが実際に回答を含むことを生成前に検証。 取得が悪ければモデルも悪い。関連性しきい値を使用：関連度スコア超過時のみ取得ドキュメントを LLM に渡す（例：>0.7 コサイン類似度）。
🔍 ハイブリッド検索の利点
ベクトル検索（セマンティック）+ BM25（キーワード）を組み合わせてください。Weaviate と Qdrant はネイティブサポート。「顧客契約2024」というクエリ：セマンティックが段落を、BM25 が年号を捉える。合わせて = 優れたリコール。
関連資料
- プロンプトエンジニアリングとは？ — RAG 取得コンテキストで動くプロンプト設計基礎
- Chain-of-Thought プロンプティング — RAG で取得ドキュメント上で複雑なマルチステップ推論に Chain-of-Thought を組み合わせ
- プロンプトインジェクション＆セキュリティ — 取得ドキュメント経由の間接プロンプトインジェクションは RAG の最初のセキュリティリスク
- オープンソース vs 専有 LLM — RAG パイプラインの生成段階向けにクラウドとローカル LLM から選択
- AI の限界―LLM ができないこと — LLM 知識カットオフとハルシネーション限界を克服するのに RAG がなぜ必要かを理解
- 品質チェックを構築 — RAG 出力検証パターン：ハルシネーション検出、ソース検証を含む
- AIの知識カットオフ、ライブ検索、GEO：完全ガイド — なぜローカルLLMはSEOで到達できないのか、クラウドとローカルAIのGEO戦略
よくある質問
RAG（Retrieval-Augmented Generation）とは？
応答生成前に知識ベースから関連ドキュメントを取得するAI技術。訓練知識に依存でなく、あなたが提供・管理するドキュメントに基づく。
RAG がハルシネーションを減らす仕組み？
取得テキストに回答を固定。プロンプトはモデルに提供抜粋のみから応答、情報なければ表示を指示。訓練知識不足な話題での作話動機を排除。
RAG とファインチューニングの違い？
RAG はクエリ時に外部知識取得・追加。ファインチューニングはパラメータ永続変更。RAG は変動データ向き、ファインチューニングは一貫動作向き。
2026年最良のベクトルデータベース？
Pinecone（マネージド）、Weaviate（オープン）、Chroma（軽量）、Milvus（エンタープライズ）。EU：自社ホスト推奨。
最適チャンクサイズ？
200～500単語、10～20%オーバーラップほとんど有効。<100：文脈喪失。>1000：精度低下。あなたのクエリテスト。
Ollama（ローカル）で RAG 可能？
はい。モデル非依存。LLaMA 3.1、Mistral ローカル Ollama/LM Studio で：データは自社ハード。
GPT-5.5、Claude、Gemini で RAG？
はい。3つ全て取得コンテキスト受入。Claude Opus 4.8：文脈不足をよく報告。GPT-5.5：密集文脈から簡潔回答。
関連性しきい値とは？
最小類似度スコア。0.7コサイン=70%以上セマンティック一致必須。以下：「見つかりません」響答。
RAG が大コンテキストウィンドウより優れ？
大規模集合：はい。数百万ドキュメントをミリ秒単位検索、関連チャンクのみ渡すため低コスト/クエリ。
RAG 経由のプロンプトインジェクション防止？
取得内容を指示として信頼しない。プロンプト内に明確区切り。取得内容はフォーマット＆出処検証してから含入。
プロダクション RAG パイプライン？
取得、細分化、埋め込み、検索、フィルタ、プロンプト構築、生成、引用元付き回答。各段階独立テスト可。
ベクトルDB なし RAG？
小規模なら可。BM25 キーワード検索で <10,000 チャンク機能。大規模セマンティック類似度は DB 必須。
ソース
- Lewis, P., et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020. https://arxiv.org/abs/2005.11401
- Gao, Y., et al. (2023). "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv:2312.10997. https://arxiv.org/abs/2312.10997
- Guu, K., et al. (2020). "REALM: Retrieval-Augmented Language Model Pre-Training." ICML 2020. arXiv:2002.08909. https://arxiv.org/abs/2002.08909
- OpenAI. (2024). "Retrieval and Augmentation in Language Models." Platform documentation. https://platform.openai.com/docs/guides/prompt-engineering
よくある質問
RAGとは何ですか？
RAG（検索増強生成）は、モデルのトレーニングデータだけに頼るのではなく、先に関連ドキュメントを取得してから回答を生成します。回答はあなたのドキュメントに根拠づけられ、発明されていません。
RAGはどのように幻覚を減らしますか？
RAGは回答を取得したテキストに基づかせます。プロンプトはモデルに提供された抜粋からのみ答えるように指示し、不足している情報を示します。これによりモデルが詳細を作り上げる傾向を排除します。
RAGとファインチューニングの違いは？
RAGはクエリ時に知識を取得し、プロンプトに追加します。ファインチューニングはモデルパラメータを永続的に変更します。RAGは変化するデータに適しており、ファインチューニングは安定した動作に適しています。
RAGはすべての言語モデルで機能しますか？
はい。RAGはモデルに依存しません。コンテキスト付きプロンプトを受け入れるすべてのLLMが、取得されたドキュメントを使用できます。これはGPT-5.5、Claude Opus、Gemini、Llamaなどのオープンソースモデル、Ollama経由のローカルモデルを含みます。
RAGの最適なチャンクサイズは？
ほとんどの場合：1チャンク200～500単語、隣接するチャンク間に10～20%のオーバーラップ。小さいチャンク（50～100単語）は精度を改善し、大きいチャンク（500+単語）はコンテキストを提供しますが、無関係な段落を含むリスクがあります。
RAGの関連性閾値とは？
類似度スコアの最小値です。取得されたドキュメントの類似度が閾値（例：0.7コサイン類似度）未満の場合、LLMに渡されません。これにより、低品質なコンテキストがモデルを混乱させるのを防ぎます。
RAGは大きなコンテキストウィンドウより優れていますか？
大規模なドキュメント集合の場合はそうです。RAGはセマンティック類似度を使用して数百万のドキュメントをミリ秒で効率的に検索します。大きなコンテキストウィンドウはより費用がかかり、どのドキュメントを含めるかを事前に知る必要があります。
RAGとファインチューニングを組み合わせることはできますか？
はい。モデルをファインチューニングしてスタイル、トーン、またはドメイン動作を改善します。その後RAGを使用して、それを現在の事実に根拠づけます。これにより両方の長所が得られます：一貫した動作+事実の根拠。
RAGでプロンプト・インジェクション攻撃を防ぐにはどうしますか？
プロンプトに含める前に取得されたコンテンツを検証します。システム指示と取得されたテキスト間に明確な区切り文字を使用します。取得されたコンテンツを実行可能な命令として扱わないでください。不審なパターンを監視します。
RAGはベクトルデータベースが必要ですか？
小さな集合には必要ありません。BM25キーワード検索は10,000ドキュメント未満でベクトルなしで動作します。より大きな集合でのセマンティック類似度については、ベクトルデータベース（Weaviate、Pinecone、Chroma、Milvus）が重要です。