RAGとは：社内データをAIに使わせる技術の本質と3つの落とし穴
「ChatGPTに自社の製品マニュアルを学習させたい」——AI活用の相談を受けるたびに、この要望が出てくる。
結論から言うと、ChatGPT単体では社内データを「学習させる」ことはできない。ただし、RAG（Retrieval-Augmented Generation）という技術を使えば、社内データをAIに活用させることは今すぐにでも可能だ。
問題は、「RAGを導入したのに回答精度が低い」という声もまた、同じくらい多いという事実だ。RAGは万能ではない。正確には、RAGは「検索の品質がそのままAI回答の品質に直結する設計パターン」であり、設計なしには高コストなシステムになるだけだ。
この記事では、Lat91が10体のAIエージェントを構築・運用する過程で直面したRAGの本質と、現場で必ずつまずく3つの構造的ポイントを解説する。
1. 「AIに学習させる」という言葉の罠
「AIに社内データを学習させる」という表現が広がっているが、一般的なLLM（大規模言語モデル）は一度学習が完了するとその重みは固定される。ChatGPTやClaudeに新しい社内資料を渡しても、それがモデル自体に「記憶」されるわけではない。会話が終われば、その情報はリセットされる。
この誤解を解消しないまま進めると、Fine-tuning（ファインチューニング）という大がかりなモデル再学習に向かいがちだ。Fine-tuningは「社内特有の用語や文体をモデルに覚えさせる」には有効だが、「最新の規程や製品情報をリアルタイムに参照させる」には向いていない。改訂のたびに再学習が必要になり、コストと時間が積み上がる。
RAGは、異なるアプローチを取る。AIに情報を「記憶させる」のではなく、「必要なときに正しい情報を検索して渡す」という設計だ。AIはあくまで「渡された情報に基づいて回答する」のみで、内部に記憶するわけではない。この違いが、運用コストと更新の柔軟性に決定的な差をもたらす。
2. RAGの仕組みを3ステップで理解する
RAGのプロセスは大きく3つのフェーズに分かれる。
図1: RAGの3ステップ——「検索→渡す→生成」のシンプルなフロー
Step 1: Indexing（インデクシング）
最初のフェーズは、社内文書をAIが検索できる形に変換する準備作業だ。文書をある程度の長さに分割（チャンキング）し、各チャンクをEmbedding（埋め込みベクトル）に変換してベクトルデータベースに格納する。
Embeddingとは、テキストの意味を数値の配列で表現する技術だ。「AIとは何か」という質問と「人工知能の定義と概要」という文書は表現が違うが、意味的に近い。Embeddingを使えば、この「意味の近さ」をコンピュータが数値計算できるようになる。
Step 2: Retrieval（リトリーバル）
ユーザーから質問が来ると、その質問もEmbeddingに変換される。データベース内の全チャンクと「意味的な近さ」を計算し、スコアが高い上位k件を取得する。
この段階が、RAGの品質を決定的に左右する。いかに優れたLLMを使っても、検索で的外れな文書が引かれれば、回答の精度は上がらない。LLMは渡された情報を元に回答するだけなので、インプット次第で出力品質は上下する。
Step 3: Generation（ジェネレーション）
検索で取得した文書チャンクと、ユーザーの質問を合わせてLLMに渡す。LLMは「渡された文書を参照して回答を生成する」という指示のもと、最終的な回答を返す。回答には「どの文書から引用したか」という情報も含められるため、ハルシネーション（誤情報の生成）の検証が可能だ。
3. RAGが真価を発揮する条件：海外先進企業の事例
RAGの可能性と限界を理解するには、実際の大規模導入事例を見るのが早い。
Morgan Stanley：金融顧問の知識基盤を変えた
RAGの実用化で最も注目を集めた事例の一つが、Morgan StanleyとOpenAIが共同で導入したシステムだ（2023年3月発表、OpenAI公式ブログ掲載）。同社は10万件以上の社内リサーチレポートや金融文書をベクトルデータベースに格納し、ファイナンシャルアドバイザーがリアルタイムで関連情報を参照できる仕組みを構築した。
担当者が「欧州の中型株に対するリスク評価は？」と質問するだけで、関連するリサーチレポートのサマリーが即座に返ってくる。従来、専門の調査担当者への問い合わせと24〜48時間の待機が必要だった作業が、数秒に短縮された。
注目すべきは、Morgan Stanleyが「AIを再学習させた」のではなく、「既存のリサーチレポートをAIが検索できる形に整理した」という点だ。AIの高性能化よりも、データの構造化と検索設計が成功の鍵だった。
Notion AI：日常業務の文書がそのまま知識基盤になる
Notionは2023年にNotionAIを導入し、ユーザーが自分のワークスペース内文書を対象にRAGベースの質問応答を利用できるようにした。「先月の議事録から、○○プロジェクトの決定事項を教えて」という質問に、関連する議事録から情報を集約して回答する。
このケースが興味深いのは、技術の高度さではなく「すでにそこにある文書を活用する」というコンセプトの受け入れられ方だ。特別なデータ収集プロジェクトは不要で、日常業務で自然に蓄積された議事録・マニュアル・仕様書がそのままRAGの素材になる。中小企業にも直接適用できる発想だ。
4. 現場で必ずつまずく3つの構造的ポイント
Lat91では、10体のAIエージェントの一部にRAGアーキテクチャを採用している。情報収集エージェント（Intel Scout）は収集したリサーチ結果をベクトルデータベースに蓄積し、他エージェントが参照できる仕組みだ。このインフラ構築と運用の過程で、ほぼ確実にぶつかる3つの壁がある。
つまずき①: ゴミ入れ、ゴミ出し——データ品質の問題
最も頻繁に起きるのが、社内文書の品質問題だ。
典型的な失敗パターンがある。全社文書をRAGに投入したところ、「3年前の古い規程」「更新漏れのマニュアル」「途中で中断した草稿」が混入し、AIが古い情報をもっともらしく回答するようになった——という事態だ。LLMは渡された文書の鮮度を判断できないため、古い情報も新しい情報と同等に扱う。
Lat91でも同様の経験がある。知識ベースに蓄積するリサーチ文書の品質管理を怠ったとき、古い情報とリアルタイム情報が混在し、エージェントの回答品質が著しく低下した。対策として、文書にメタデータ（作成日・更新日・有効期限）を必ず付与し、期限切れの文書は自動的に検索対象から除外する仕組みを導入した。
RAGで最初に投資すべきは、LLMの高性能化よりも文書管理の仕組みだ。
つまずき②: チャンキングの罠——分割設計の問題
チャンキングの設計が不適切だと、正しい情報がデータベースにあるのに検索でヒットしない、という逆説的な事態が発生する。
最も多い失敗パターンは「固定長分割」だ。「500文字ずつ分割」という設定では、一つの重要な概念が2つのチャンクに分断され、どちらのチャンクも文脈が不完全になる。検索でどちらかが引かれても、回答に必要な情報の半分しかない。
英国の製造業向けSaaSスタートアップがこの問題で痛い目を見た事例がある。製品仕様書を500文字固定で分割したところ、「仕様の本体」と「使用上の注意（後半部分）」が別チャンクに分かれてしまった。AIが仕様のみを参照して重要な注意事項を見落とし、顧客対応で誤った情報を提供し続けた。
解決策は「意味的なまとまりで分割する」こと。セクション単位・段落単位での分割が基本だ。また、チャンク同士に意図的な「オーバーラップ（重複）」を持たせることで、分断リスクを低減できる。LlamaIndexやLangChainには、この重複チャンク設定のオプションが標準搭載されている。
つまずき③: ベクトル検索の死角——固有名詞と数字が苦手
「意味検索（ベクトル検索）があれば、キーワードが違っても検索できる」という期待は半分正しく、半分は誤りだ。
ベクトル検索には固有の弱点がある。具体的な数字・固有名詞・製品コードの検索が苦手だ。「売上高5億円以上の案件」という条件でチャンクを検索するとき、ベクトル検索は意味的な近さで判断するため、「高い収益」「大型案件」という文書も同等のスコアになることがある。
図2: ハイブリッド検索——2つの検索手法を組み合わせて精度を高める
現実的な解決策は「ハイブリッド検索」だ。ベクトル検索（意味的な近さ）と、従来型のキーワード検索（BM25）を組み合わせ、両スコアを統合して最終的な検索結果を返す方法だ。LlamaIndexはRecursiveRetriever、LangChainはEnsembleRetrieverという形でハイブリッド検索をサポートしており、数十行の設定変更で有効化できる。
5. よくある反論に正直に向き合う
「Fine-tuningすれば済むのでは？」
この反論には一理ある。Fine-tuningはLLM自体を社内データで追加学習させる手法で、「特定のドメイン用語の理解」「文体のカスタマイズ」「文書なしでの特定知識回答」において、RAGより高精度な結果が出ることがある。特に、一般的なLLMが知らない専門用語や業界特有の表現を扱う場合には有効だ。
ただし、Fine-tuningの致命的な弱点は「更新コスト」だ。社内規程が改訂されるたびに再学習が必要になり、GPT-4クラスのモデルでは1回のFine-tuningに数十万円かかることもある。また、Fine-tuningでは「この情報はどこから来たか」を追跡しにくく、ハルシネーションの検証が難しい。
現実解は組み合わせだ。Fine-tuningで社内の用語・文体をモデルに覚えさせ、RAGで最新情報を動的に参照させる。Morgan Stanleyも、OpenAIのモデルそのものは変更せずRAGを組み合わせるアーキテクチャを採用している。
「社内データをクラウドに上げるのは危険では？」
セキュリティへの懸念は正当だ。選択肢は3つある。
一つ目は「オンプレミス展開」だ。LLMをオンプレミスで動かし、データが社外に出ない構成にする。Ollamaやllama.cppを使えばローカルでLLMを動かせる（ただし、能力はクラウドLLMより劣る）。
二つ目は「データの分離設計」だ。機密度の高い文書はRAGの対象外にし、一般的な業務文書のみを対象にする。全情報をRAGに投入する必要はない。
三つ目は「企業向けサービスの利用」だ。Microsoft Azure OpenAI ServiceやAnthropic Claude for Enterpriseは、データがモデルのトレーニングに使用されないという契約保証がある。コンプライアンス要件が厳しい金融・医療業界でも採用実績がある。
6. 今後の展望：RAGが向かう先
2026年時点のRAGは「第二世代」に入っている。初期のRAGが「文書を検索してLLMに渡す」という単純なパイプラインだったのに対し、現在は複数のRAGパイプラインを組み合わせた「マルチホップRAG」や、LLMが自ら検索クエリを修正しながら精度を高める「Agentic RAG」が実用化されつつある。
Gartnerは2026年に企業向けAIアプリケーションの80%以上がRAGを何らかの形で採用すると予測している（Gartner「Top Strategic Technology Trends 2026」）。この普及が進む中で、競争優位の源泉は「RAGを使っているか否か」から「RAGの設計品質」に移行する。
2028年に向けた予測として、RAGはデータ管理システムと不可分になっていく。社内文書の品質・鮮度・アクセス制御が自動的に管理され、RAGパイプラインに常に最新の情報が供給される仕組みが標準化されるだろう。つまり、今から文書管理の仕組みを整備している企業は、RAGの恩恵を最大限に享受できる準備が整っていることになる。
7. 月曜から始める最初の3ステップ
RAGの実装は大がかりなプロジェクトである必要はない。今週中にできる具体的なステップを示す。
月曜日：対象文書を10件選ぶ
全文書の整備を待たずに始める。最も質問が多い領域の文書を10件選ぶ。製品FAQ、よくある問い合わせへの回答例、社内規程の主要10項目など。「全文書を投入しなければ始められない」は誤りで、10件から始めても十分な検証価値がある。
火〜水曜日：Dify.aiで試作する
Dify.ai（無料プランあり）は、コーディングなしでRAGパイプラインを構築できるノーコードツールだ。文書をアップロードするだけで自動的にインデクシングが実行され、チャットインターフェースで動作確認できる。品質への期待値は低く設定し、まず「どんな質問に答えられて、どんな質問に答えられないか」を把握することが目的だ。
木〜金曜日：失敗パターンを記録する
誤答・的外れな回答を収集し、原因を分類する。チャンキングの問題か、データ品質の問題か、検索の問題か、それとも回答生成の問題か——失敗パターンを分類することで、次の改善の優先順位が明確になる。
まとめ
- RAGは「AIに社内データを記憶させる」技術ではなく「検索とAIを橋渡しする設計パターン」
- 検索精度（Step 2）がそのままAI回答品質に直結するため、LLMより検索設計が重要
- 固定長チャンキングは意味の分断を生む——意味的まとまりで分割し、オーバーラップを持たせる
- ベクトル検索は固有名詞・数字が苦手——ハイブリッド検索（BM25併用）で補完する
- Fine-tuningとRAGは競合ではなく補完——用語定着はFine-tuning、最新情報はRAGで
- 10件の文書から今週始められる。全文書の整備を待つ必要はない
社内データをAIに活用させることは、技術的には今すぐでも実現可能だ。ただし「投入すれば動く」という前提は捨てる必要がある。RAGは設計の質を問うシステムだ。データ品質・チャンキング・検索精度——この3点への投資が、長期的な回答品質の差をつける。
Lat91では、RAGを含むAIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
「自社でもRAGを活用したいが、何から設計すればいいかわからない」という方は、まずは無料相談からお気軽にどうぞ。