RAG（検索拡張生成）とは：社内文書検索AIをゼロから理解する
結論: RAGは、AIが回答する直前に社内文書を自動で検索し、その内容を根拠として回答を生成する仕組みです。ChatGPTが「社内マニュアルのことは分からない」と返してくる根本的な理由は、LLMの構造にあります。その構造を変えるのがRAGです。
ChatGPTを使えば便利なことは分かっている。社内では「AIを活用しよう」という声も上がっている。しかし実際に試してみると、社内規程や製品マニュアルについて聞くと「その情報は持っていません」と返ってくる。
その違和感は、気のせいではありません。
LLMには構造的な限界があり、RAGはその限界を補う仕組みとして設計されています。要件定義に入る前に、この構造を理解しておくと、ベンダーとの議論が大きく変わります。
LLM（大規模言語モデル）には何ができて、何ができないのか
ChatGPTをはじめとするLLM（Large Language Model: 大規模言語モデル）は、インターネット上の大量の公開テキストを学習して構築されたモデルです。膨大な文章を処理することで、言語の構造と知識を内部に蓄積しています。
ただし、この学習には2つの構造的な制約があります。
1. 知識のカットオフ
LLMの学習データは特定の時点で凍結されています。その時点より後に起きた出来事、変更された規程、更新された料金体系——これらはモデルが「知らない」状態で固定されています。AWS公式のRAG解説では、これを「Without RAG: the LLM takes the user input and creates a response based on information it was trained on」と表現しています。学習済みの情報のみを根拠に回答するのがデフォルトの動作です。
2. 社内・非公開データへのアクセス不可
社内規程、製品マニュアル、独自のFAQ、SharePoint上のドキュメント——これらはインターネット上に公開されていないため、LLMの学習データに含まれていません。IBMの解説では「RAG allows generative AI models to access additional external knowledge bases, such as internal organizational data」と説明されており、裏を返せば、RAGなしでは社内データに一切アクセスできない構造です。
3. ハルシネーション
上記2つの制約が重なる状況で「社内の経費精算ルールは?」と聞いたとき、LLMは「知らない」と正直に返すこともあれば、もっともらしい誤情報を生成することもあります。この現象をハルシネーション（幻覚）と呼びます。Google Cloudの定義では「gen AI hallucinations」として明示されており、業務で使う場合は誤った手続きの指示や、存在しないルールの提示につながります。
LLMが「使えない」のではなく、これは設計上の特性です。RAGはその特性を補う構造として生まれました。
RAGとは何か——検索してから答える、という発想の転換
RAG（Retrieval-Augmented Generation: 検索拡張生成）は、ユーザーの質問が来たとき、まず社内文書を検索し、その検索結果を根拠に回答を生成するアーキテクチャです。
2020年、PatrickLewisら12名がNeurIPSで発表した論文（arXiv:2005.11401）で提唱されたこの手法は、現在AWS・Google Cloud・IBM・Pinecone・Weaviateが標準構造として採用しています。
AWS公式の説明を借りれば、通常のLLMは「学習済みデータだけを根拠に回答する」のに対し、RAGは「ユーザーの入力から関連情報を引き出す検索コンポーネントを追加し、質問と取得情報を両方LLMに渡す」という構造です。
つまり、AIが「答える前に調べる」ようになります。
アラヤ社の比較実験から分かること
株式会社アラヤの解説記事では、架空の地域「風ヶ原市」のキャッチコピーを題材にした比較が示されています。
外部情報なしの状態でLLMに「風ヶ原市のキャッチコピーを教えてください」と聞いた場合、「その情報は持っていません」という回答が返ります。一方、同じ質問に風ヶ原市の公式資料をRAGで読み込ませた状態では、実際のキャッチコピーが正確に返ります。
この差は、LLMの賢さの差ではありません。根拠となる情報が与えられているかどうかの差です。
RAGの仕組みを5ステップで追う
では、社内文書がどのようにしてAIに「読める」形になるのか。処理の流れを順に見ていきます。
Step 1——文書を数値に変換してデータベースに格納する
まず、AIに検索させる文書群を準備します。Confluence・SharePoint・Google Drive・PDFマニュアル・Slackのログ——形式を問わず収集します。
次に行うのが「チャンク化」です。長文の文書を、段落や見出し単位の小さなテキストブロック（チャンク）に分割します。これは検索の精度を上げるための処理で、長文のまま扱うより関連箇所を特定しやすくなります。
続いて「Embedding（エンベディング）」を行います。Embeddingとは、テキストを数値のベクトル（数字の配列）に変換する処理です。Weaviateの解説では、生成モデルとEmbeddingモデルは異なる役割を持つと説明されています。Embeddingモデルはテキストの意味的な位置を数値空間に写す専用モデルで、生成AIとは別物です。
変換されたベクトルは「ベクターDB（ベクトルデータベース）」に格納されます。ベクターDBとは、ベクトル形式のデータを高速で検索するために最適化されたデータベースです。通常のデータベースがキーワードの一致で検索するのに対し、ベクターDBは意味的な近さで検索します。
この段階で、文書ごとのアクセス権・機密区分などのメタデータも付与しておくことができます。
Step 2——ユーザーの質問も同じ形式に変換する
ユーザーが「経費精算の締め日はいつですか?」と入力したとき、この質問文も同じEmbeddingモデルでベクトルに変換されます。
なぜかというと、ベクターDBに格納された文書チャンクと「意味的な近さ」を比較するには、同じ数値空間に揃える必要があるからです。変換の形式が違えば、比較ができません。
Step 3——意味的に近いチャンクを検索する
質問ベクトルとデータベース内の各チャンクベクトルの近さを計算し、最も関連度が高いチャンクを取り出します。この計算には「コサイン類似度」などの手法が使われます。
キーワード検索との違いは、同じ意味の表現も拾えることです。「締め日」と聞いても「月末締め」と書かれた文書を見つけられるのは、意味的な近さで検索しているためです。
Google Cloud公式では、セマンティック検索とキーワード検索を組み合わせた「ハイブリッド検索」も有効な手法として言及されています。
AWSの解説では、「How much annual leave do I have?」という質問に対して、年次休暇ポリシーのチャンクと当該社員の履歴データの両方が検索されるケースが示されています。複数種類の文書から関連情報をまとめて取得できることが分かります。
Step 4——質問と検索結果を組み合わせてプロンプトを作る
取得したチャンクと元の質問を組み合わせ、LLMへの入力（プロンプト）を生成します。
Weaviateの解説では、プロンプトテンプレートとして「取得したコンテキスト情報 + 質問 + このコンテキストだけを根拠に答えよという指示」という構造が説明されています。
AWSの定義ではこれを「The RAG model augments the user input (or prompts) by adding the relevant retrieved data in context」と表現しています。質問そのものを拡張する処理です。
Step 5——LLMが根拠付きで回答を生成する
拡張されたプロンプトを受け取ったLLM（GPT-4o・Claude・Geminiなど）が、提示されたコンテキストを根拠に回答を生成します。
このとき、どの文書のどのセクションを参照したかを回答内に明示する設計が推奨されます。Pinecone公式では「traceability/source citations」をRAGの主要な利点の一つとして挙げており、根拠文書を示すことで回答の検証が可能になります。
Google Cloudはこれを「Providing ‘facts’ to the LLM as part of the input prompt can mitigate gen AI hallucinations」と整理しています。ハルシネーションを抑制する主たるメカニズムは、この「根拠をプロンプトに組み込む」という構造にあります。
RAGを使うと何が変わるのか——業務でのユースケース
抽象的な仕組みが分かったところで、「では自社でどう使うか」という観点で見ていきます。サーバーワークス社のブログでは以下のユースケースが挙げられています。
社内FAQ・マニュアル検索
「経費精算の締め日は?」「VPNの設定手順は?」といった問い合わせが多い質問を、AIが社内文書を根拠に一次回答します。担当者への問い合わせ件数の削減と、回答品質の均一化が期待できます。
カスタマーサポートの一次対応
製品マニュアルや過去のFAQを根拠に、顧客からの問い合わせに一次回答します。有人対応が必要なケースの絞り込みが可能になります。
営業資料・提案書の作成支援
過去の提案書・導入事例・競合比較資料を横断検索し、類似案件の内容を参照しながら資料を作成できます。毎回ゼロから作る工数が削減されます。
研究開発・技術文書の活用
不具合報告書・設計ドキュメント・試験報告書を横断検索することで、過去の知見の再利用と重複作業の削減ができます。
「ファインチューニングと何が違うの?」という疑問への回答
RAGを調べると、必ず「ファインチューニング」という別のアプローチも出てきます。どう違うのか、整理します。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 知識の更新 | 文書を再インデックスするだけで更新可能 | モデルの再学習が必要 |
| コスト | 相対的に低い | 高い |
| 出典の提示 | 可能（参照文書を明示できる） | 不可（ブラックボックス） |
| 最新情報への対応 | リアルタイム更新に対応できる | 知識カットオフが再学習時点に固定される |
| 社内機密の扱い | モデルに学習させず参照のみ | 情報がモデルのパラメータに組み込まれる |
IBMはファインチューニングを「computationally expensive and resource-intensive」と表現しています。コンピューティングコストと専門人材の両面で、中堅企業が社内運用するには障壁が高い選択肢です。
社内文書を最新の状態で検索させたい、かつ機密情報をモデルに学習させたくないという要件がある場合、RAGの方が現実的なアプローチです。一方、ドメイン固有の言語スタイルや専門用語に特化させたい場合はファインチューニングが有効なケースもあります。
導入時に直面する現実的な課題
良い面だけ書いても判断材料にならないため、課題もまとめます。サーバーワークス社のブログでは「ベクトルデータベース、検索エンジン、生成AI（LLM）といった複数のシステムを組み合わせるため、構築・設定・検証に時間とコストがかかります」と明記されています。
複数システム連携の複雑さ
ベクターDB・検索エンジン・LLMの3つ以上のコンポーネントを組み合わせ、それぞれを正しく設定・連携させる必要があります。各コンポーネントの更新やAPIの変更に追随する運用負荷も発生します。
専門人材の確保
AI・クラウドインフラ・セキュリティの知識を横断できる人材を内製で確保するのは、300〜1000名規模の中堅企業では難しいのが実情です。
社内データの品質問題
検索精度の天井を決めるのは、最終的にデータの品質です。古い情報・重複したマニュアル・ファイル形式のばらつきが多いデータソースからは、精度の高い検索結果は得られません。インデックス化の前にデータ整備の工数が必要です。
アクセス権設計のリスク
権限設定を誤ると、本来アクセスできないはずの機密文書が検索結果に含まれるリスクがあります。社内ACLとの連携設計はRAG固有の設計課題です。
Onyx社のバイヤーズガイドによれば、シンプルな構成（Naive RAG）のタスク成功率は10〜40%にとどまるという指摘があります。これはOnyx社自身の記述であり独立した検証ではありませんが、「ベクターDBにつなぐだけで精度が出る」という前提で進めると、後から設計を作り直すことになります。
課題があるから諦めるのではなく、課題を踏まえた上でPoC（概念実証）の設計を組むことが、後からの作り直しを防ぎます。
導入を検討するなら、最初に整理すべきこと
「導入してみたい」という判断になったとして、最初に動くべきことは何か。サーバーワークス社のブログが示すPoC→本格運用の段階的アプローチを骨格に、現実的な出発点を整理します。
① どの文書から始めるか
全社文書をいきなり対象にする必要はありません。問い合わせが多い、または担当者が毎回調べているカテゴリを特定し、そこから小さく始めます。「問い合わせが週に5件以上ある質問のFAQ」など、改善効果が測定しやすい範囲から始めると、PoCの成否を判断しやすくなります。
② アクセス権の設計
誰がどの文書を参照してよいか——これを最初に決めずに進むと、構築後に設計を見直す工数が発生します。人事情報・法務文書・営業数値など、部門ごとに参照権限が異なるドキュメントの分類から始めることを推奨します。
③ KPIをどこに置くか
「AIを入れた」は成果ではなく、「問い合わせ件数が月○件削減された」「回答時間が○分から○分に短縮された」が成果です。KPIを先に定義しておかないと、PoCの評価ができません。問い合わせ件数・有人対応率・社員の検索時間の変化あたりが測定しやすい指標です。
実装に必要なコンポーネント一覧
要件定義の材料として、RAGシステムを構成する主なコンポーネントをまとめます。Onyx社のバイヤーズガイドでは「Enterprise RAG adds connectors, permissions, evaluation, observability, and governance. That gap is most of the engineering work and most of the procurement cost.」と指摘されています。コンポーネントの選定と権限管理・ガバナンス層の設計が、工数の大半を占めます。
| コンポーネント | 役割 | 代表例 |
|---|---|---|
| ドキュメントソース | インデックス化する文書群の接続元 | Confluence / SharePoint / Google Drive / Slack |
| Embeddingモデル | テキスト→ベクトル変換 | OpenAI text-embedding / Cohere |
| ベクターDB | ベクトルの高速検索 | Pinecone / Weaviate / Azure AI Search / pgvector |
| 検索レイヤー | セマンティック＋キーワードのハイブリッド検索 | BM25 ＋ ベクター検索の組み合わせ |
| オーケストレーション | 各コンポーネントの連携制御 | LangChain / LlamaIndex |
| LLM | 最終回答の生成 | GPT-4o / Claude / Gemini |
| ガバナンス層 | 権限管理・監査ログ | 社内ACLとの連携設計 |
このコンポーネント表は「何を誰に依頼するか」を整理するための出発点です。コンポーネントが特定できれば、ベンダーや内製チームに対する要件定義の精度が上がります。
コンポーネントの選定・権限設計・PoC設計は、RAGの精度と運用コストを決める最初の分岐点です。選定ミスによる作り直しは、当初のコストを大きく上回ります。構成の整理から始めたい場合、費用感やベンダー選定の相談も含めてご連絡ください。