レッスン1：RAG とは何か——「社内知識を LLM が使う」ためのアーキテクチャ入門

このレッスンで学ぶこと

本コースの守備範囲（社内 RAG の企画・設計・構築・評価・展開）と、扱わない範囲を区別できる
RAG の 3 世代の系譜（原論文 2020 → 実装ラッシュ 2022-2023 → マネージド RAG 2024-2026）を把握する
RAG の 4 段階アーキテクチャ（データ→索引→検索→生成）で全体像を捉えられる
対象読者の 3 軸（情シス／DX 推進／エンジニア）と、同じコースで扱う狙いを理解する
発展形（Agentic RAG・Corrective RAG・Self-RAG）の位置づけと、本コースの守備範囲外を押さえる

社内向けの RAG（検索拡張生成）は、便利な生成 AI に社内文書を読ませる、という単純な話ではありません。誰の文書を、どの単位で切り、どう索引し、どこまで見せるか——RAG の設計は、実は「社内の情報構造を設計し直す仕事」でもあります。本コースの背骨となるのは、「RAG の 8 割は LLM の外側で決まる——文書と検索が勝敗を分ける」という中核メッセージです。モデルの名前を追いかけるのではなく、次の 3 年間、どのモデル・どのフレームワークが来ても「判断できる自分」を育てることを目指します。

本コースの位置づけ——「社内 RAG」の企画・設計・構築・評価・展開

本コースは「社内向けに RAG（検索拡張生成）システムを企画・設計・構築・評価・展開する」ための入門です。生成 AI そのものの基礎、プロンプト設計の基礎、AI エージェント一般論、LLM 内部の仕組み、Model Context Protocol のプロトコル仕様は、別の入門コースで扱います。本コースはそれらを前提として、「社内文書と RAG をどう組み合わせて、社内で使えるシステムに仕立てるか」の判断軸を、情シス・DX 推進部門・社内開発エンジニアの 3 軸で扱います。

💡 ポイント 本コースは「使い方」ではなく「社内 RAG のシステム設計」に軸足を置きます。個別ベンダーの料金や SKU、機能一覧は変動が激しく数か月で陳腐化するため、機能概念のレベルに留めます。ツール名を覚えるのではなく「どう分類し、どう選び、どう組織に定着させるか」の判断軸を持ち帰ってください。

想定読者の 3 軸

本コースは 3 種類の読者を主軸に据えます。1 つ目は、社内の情シス部門で情報基盤・ドキュメント管理・アクセス制御を預かる方です。誰の文書を何に載せているか、権限がどこにあるか、監査ログをどう残すか、を実務で扱ってきた方です。2 つ目は、DX 推進部門・企画部門・プロダクトマネージャーです。RAG の効果を KPI として捉え、投資判断や部門間の合意形成を進める方です。3 つ目は、社内開発エンジニアや SIer プロジェクトの PM です。実装の選定・構築・評価に直接手を動かす方です。

この 3 軸を、本コースでは意識的に交錯させています。情シスは KPI とロードマップの視点を、企画は文書とアクセス制御の実務感覚を、エンジニアは組織の力学と定着の現実を、それぞれ持ち帰れる構成にしました。片方の視点だけでは、社内 RAG の導入は成功しにくいからです。

RAG の系譜——2020 年 → 2023 年 → 2026 年

RAG（Retrieval-Augmented Generation、検索拡張生成）という用語は、Facebook AI Research（当時）の Patrick Lewis と Ethan Perez らが 2020 年に NeurIPS で発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」に由来します。「事前学習済みの生成モデルに、外部の非パラメトリックな知識源から検索してきた文書を組み合わせる」という設計思想が、この論文で明確に提示されました。

flowchart LR
  G1[第 1 世代<br/>原論文<br/>2020] --> G2[第 2 世代<br/>実装ラッシュ<br/>2022-2023]
  G2 --> G3[第 3 世代<br/>マネージド RAG<br/>2024-2026]
  G1 -.-> C1[Lewis 論文<br/>RAG 概念定式化]
  G2 -.-> C2[LangChain<br/>LlamaIndex<br/>pgvector]
  G3 -.-> C3[Contextual Retrieval<br/>Agentic RAG<br/>マネージド化]

第 1 世代：原論文（2020 年）

2020 年発表の Lewis 論文は、Wikipedia を外部知識源として用い、質問応答タスクで有効性を示しました。当時はまだ、GPT-3 の公開直後で、LLM に「知識を外部から与える」という発想自体が新しく、後に「RAG」の名で普及することになる基本形が示された段階です。

第 2 世代：実装ラッシュ（2022〜2023 年）

2022 年 11 月の ChatGPT 公開を境に、生成 AI の実務利用が爆発的に広がりました。「LLM は最新情報や社内情報を知らない」というカットオフ問題が広く認識され、その解決策として RAG が実装ラッシュを迎えます。2022 年 10 月に Harrison Chase が公開した LangChain、同年に Jerry Liu が公開した LlamaIndex（旧 GPT Index）、PostgreSQL の拡張として広がった pgvector、Weaviate や Pinecone などのベクトル DB、といったツールがこの時期に整いました。

第 3 世代：マネージド RAG と発展形（2024〜2026 年）

2024 年から現在にかけて、RAG は「作る」から「使う」段階に入りつつあります。Amazon Bedrock Knowledge Bases、Azure AI Search の統合、Google Vertex AI Search、Cohere の RAG 特化サービス、Anthropic の Contextual Retrieval（2024 年 9 月公開）など、フルマネージドの RAG が主要クラウドから提供されるようになりました。同時に、RAG 自身も進化しています。Agentic RAG（エージェントが検索クエリを反復設計する）、Corrective RAG（検索結果を検証して補正する）、Self-RAG（生成過程で検索の必要性を判定する）、GraphRAG（知識グラフを組み合わせる）といった発展形が研究・実装の両面で広がっています。

📝 補足 世代は完全に上書きされるものではなく、共存します。2026 年 7 月時点でも、社内 RAG の多くは第 2 世代のスタック（LangChain／LlamaIndex ＋ pgvector／Weaviate）で組まれ、フルマネージド（第 3 世代）と発展形（Agentic RAG 等）は選択肢の 1 つとして共存しています。「世代」は歴史の整理であって、「使うのを止めるべき手法」の選別ではありません。

RAG の 4 段階アーキテクチャ——本コースの背骨

本コースを通じて何度も戻ってくる「背骨」が、RAG の 4 段階アーキテクチャです。データ・索引・検索・生成の 4 段階で、社内 RAG を捉え直します。

flowchart LR
  A[1. データ<br/>文書の収集と前処理] --> B[2. 索引<br/>チャンキングと埋め込み]
  B --> C[3. 検索<br/>ベクトル検索と<br/>ハイブリッド検索・リランク]
  C --> D[4. 生成<br/>プロンプト設計と<br/>引用付き応答]
  D -.フィードバック.-> A

1. データ——社内文書の収集・抽出・クリーニング・メタデータ設計

社内文書は、Wiki・ファイルサーバー・メール・チャット・データベース・画像など、さまざまな場所と形式に散らばっています。RAG のデータ段階では、これらから文書を集め、PDF や Office からテキストを抽出し、日本語を適切にトークナイズし、レイアウトを解析し、メタデータを付与します。RAG の 8 割は、この段階の品質で決まるというのが本コースの中核メッセージです。文書が古い・重複している・タイトルが不正確・改訂履歴が管理されていない、といった状態のままでは、その後どんな高度な手法を積み上げても、質の高い応答は返ってきません。

2. 索引——チャンキングと埋め込みモデル選定

集めた文書を、そのまま LLM に渡すことはできません。文書を意味のある単位に「切り分け」、それぞれをベクトル空間の点に「埋め込み」、ベクトル DB に「索引化」します。この段階の設計が、後段の検索精度の天井を決めます。チャンクが大きすぎれば無関係な情報が混ざり、小さすぎれば文脈を失います。埋め込みモデルの選定は、多言語対応・次元数・コスト・日本語特化の 4 象限で行います。詳細はレッスン 3 で扱います。

3. 検索——ベクトル検索・ハイブリッド検索・リランク

質問（クエリ）を埋め込みに変換し、ベクトル DB から近い文書を取り出します。ここに、キーワード検索の代表格である BM25 を組み合わせる「ハイブリッド検索」、上位候補を再ランク付けする「リランキング」、メタデータフィルタでの絞り込み、といった技法を重ねます。検索の品質が生成の品質の天井を決めるというのが、この段階のキーメッセージです。詳細はレッスン 4 で扱います。

4. 生成——プロンプト設計と引用付き応答

検索で取り出した文書と、ユーザーの質問を、生成 LLM に渡します。この段階のプロンプト設計は、「参照情報のみに基づいて回答する」「出典を明示する」「該当情報がなければ答えない」といった RAG 特化のパターンが中心になります。詳細はレッスン 5 で扱います。

フィードバックループ——4 段階は 1 回で終わらない

4 段階は一方通行ではありません。ユーザーの質問傾向・失敗ログ・評価データセットからのフィードバックが、データ段階（メタデータ改善）・索引段階（チャンキング調整）・検索段階（重み調整）・生成段階（プロンプト調整）へ戻ります。継続的にこのループを回すことが、社内 RAG を「動くもの」から「使えるもの」に育てる道筋です。

🔰 初学者の方へ RAG の 4 段階は、社内 RAG のあらゆる設計・障害切り分けの共通言語になります。「これはデータ段階の問題か、索引段階の問題か、検索段階の問題か、生成段階の問題か」と切り分けるだけで、議論の見通しが劇的に良くなります。図と一緒にこの 4 段階を覚えてしまってください。

発展形の位置づけ——Agentic RAG・Corrective RAG・Self-RAG

「RAG の発展形」は 2024 年以降、名前が増え続けている領域です。本コースでは、代表的な 3 つを位置づけだけ紹介し、深追いはしません（発展形の実装は、本コース修了後に取り組むテーマです）。

Agentic RAG：RAG をエージェントの内部に組み込み、エージェント自身が検索クエリを設計・反復・複数ソースを使い分ける形。「1 回検索して 1 回生成」ではなく、「検索と推論を繰り返して答えに近づく」形になる
Corrective RAG（CRAG）：検索結果の関連度を評価し、関連度が低ければ Web 検索など別ソースにフォールバックする、または結果を書き直す形。検索の失敗に強い
Self-RAG：生成過程で「そもそも検索が必要か」「取ってきた文書は役に立ったか」を LLM 自身がタグ付きで判定する形。Akari Asai らの 2023 年論文で提唱された

これらはいずれも、本コースで扱う「基本 4 段階」の応用形です。基本を押さえないままエージェンティックな複雑さに手を出しても、多くの場合は失敗します。まず 4 段階の骨格を固めることから始めます。

本コースが扱わない範囲——境界の明示

本コースの守備範囲を、明確に境界化しておきます。以下は、社内 RAG の隣接領域として重要ですが、本コースでは深追いしません。

LLM 内部の仕組み（Transformer・Self-Attention・トークナイザー・埋め込み空間の学習など）：モデル内部の話は扱わず、本コースでは「文書に対する埋め込みモデルの選定」だけを扱います
プロンプト設計の一般論（5 要素・Zero/Few-shot・Chain-of-Thought・JSON Schema など）：一般論は前提として扱い、本コースでは「RAG の生成段階に特化したプロンプトパターン」だけを扱います
AI エージェントの一般論（観察・思考・行動の 5 要素・ReAct・Plan-and-Execute など）：Agentic RAG の位置づけと学習方向のみ触れ、エージェント設計そのものには踏み込みません
Model Context Protocol のプロトコル仕様：MCP のスキーマ設計や実装詳細は扱わず、社内 RAG から MCP 経由で外部システムを「呼び出す」場合の考え方だけを扱います
モデルのベンチマーク点数比較：モデル性能は数か月で塗り替わるため、点数比較は扱いません
個別ベンダーの料金・SKU・機能一覧：数か月で陳腐化するため、機能概念のレベルに留めます

⚠️ 注意 「本コースで扱わない範囲」を扱わないのは、それらが重要でないからではなく、それぞれが別の入門コース 1 本分の重さを持つからです。社内 RAG を実装・運用する立場では、隣接領域の入門コースを並行して学ぶことで理解が深まります。

中核メッセージ 6 個——このコースの背骨

最後に、本コースを通じて何度も戻ってくる「6 個の背骨」を紹介します。これらは筆者が社内 RAG 10 社以上の伴走で得た実感を、原則の形に整えたものです。

RAG の 8 割は「LLM の外側」で決まる——文書と検索が勝敗を分ける。モデル選びで解決しようとしても頭打ちが早い
検索の品質が生成の品質の天井を決める（Garbage In, Garbage Out）。誤った文脈を渡された LLM は、必ず誤った回答を出す
権限伝播とガバナンスは後から足せない——最初のスキーマ設計で決まる。「動いてから権限をつけよう」は、ほぼ確実に破綻する
評価データセットのない RAG は「動いているように見える」だけ——数値で追えなければ、改善はできない
モデルは 3 か月・フレームワークは 1 年・社内文書は 10 年で動く——文書側から設計する
PoC は 8 割成功する、定着で 8 割詰まる——KPI と業務プロセス設計の連続性が定着を決める

これらは各レッスンの冒頭・末尾で、繰り返し立ち返ります。単なる語呂ではなく、社内 RAG の意思決定で迷ったときの「羅針盤」として使ってください。

まとめ

RAG は 2020 年の Lewis 論文で概念が定式化され、2022〜2023 年に実装ラッシュを迎え、2024〜2026 年でマネージド化と発展形（Agentic RAG・Corrective RAG・Self-RAG）が広がった
本コースは RAG を「データ→索引→検索→生成」の 4 段階アーキテクチャで捉え、情シス・DX 推進・社内開発エンジニアの 3 軸で意思決定できることを目指す
モデル内部・プロンプト一般論・エージェント一般論・MCP プロトコル仕様・モデルベンチマーク・個別ベンダー料金は本コースの守備範囲外
6 個の中核メッセージ（RAG の 8 割は外側／検索が生成の天井／権限伝播は後付け不可／評価データセット必須／文書は 10 年もつ／定着で 8 割詰まる）が本コースの背骨

次のレッスンでは、RAG の「1. データ段階」に焦点を当て、社内文書の類型・前処理パイプライン・メタデータ設計・更新戦略を扱います。RAG のスタック設計はここから始まります。

確認クイズ

このレッスンの内容の理解度をチェックしましょう。