RAGとは何か：社内ドキュメントをAIの記憶に変える技術と、9割の企業がつまずく実装の壁
「社内ドキュメントをAIに読ませれば、AIが賢くなる」。この認識が、RAG導入プロジェクトの失敗を引き起こしている。RAGの本質は、AIにデータを与えることではない。AIが間違えない状況を意図的に設計することだ。Gartnerの調査では、AIプロジェクトの60%が2026年までにデータ不足で失敗すると予測されており、国内企業の約50%がRAGに取り組むなか、本番環境で成功しているのはわずか30%にとどまる。この記事では、RAGの仕組みから実装の落とし穴、具体的な始め方まで、Lat91の実体験を交えながら解説する。
RAGとは何か — 検索拡張生成の基本的な仕組み
RAG（Retrieval-Augmented Generation）は、日本語で「検索拡張生成」と訳される技術だ。LLM（大規模言語モデル）の回答生成プロセスに、外部データベースへの検索ステップを組み合わせる手法を指す。
通常のLLMは、学習済みの知識だけで回答を生成する。社内規程の最新版も、昨日の会議議事録も、LLMは知る由がない。RAGはこの問題を、「回答を生成する前に関連情報を検索して文脈として渡す」という構造で解決する。
処理の流れは4段階だ。
- Query（クエリ受付）: ユーザーが質問を入力する
- Retrieve（検索）: 質問に関連するドキュメントをベクトルデータベースから検索する
- Augment（拡張）: 検索結果を「文脈」としてプロンプトに付加する
- Generate（生成）: 文脈を参照しながらLLMが回答を生成する
重要なのは、RAGは「AIを賢くする技術」ではないという点だ。LLM自体の能力は変わらない。RAGが行うのは、「LLMが正しく答えられる状況を事前に整える」ことだ。この認識の違いが、実装の設計思想を根本から変える。
なぜRAGが必要なのか：LLMが「知らないこと」の構造的問題
LLMが持つ知識には、構造的な制約が3つある。
1. 知識のカットオフ（学習データの締め切り）
LLMは特定時点までのデータで学習されている。ChatGPTやClaudeがどれほど賢くても、今朝の会議で決まった方針や、先週更新された社内規程は知らない。
2. 私的情報へのアクセス不能
学習データはインターネット上の公開情報が中心だ。自社の契約書、顧客データ、独自のナレッジベースは学習されていない。これは当然のことだが、企業でAIを活用する際の最大の障壁になる。
3. ハルシネーション（幻覚）
LLMは「知らない」と言うことが苦手だ。問われれば、それらしい回答を生成しようとする。このハルシネーションが企業利用で最も危険な性質であり、RAGが「根拠のある文書から引用して回答する」という設計でこれを抑制する。
東京ガスが社内の人事規定に関するRAGシステムのPoCを実施したところ、回答精度が全く出なかったという事例がある。これはLLMの問題ではなく、「ドキュメントの前処理が不十分で、検索段階で正しい情報が取得できていなかった」ことが原因だった。RAGはLLMに社内データを読ませる技術ではなく、正しく検索できる状態を設計する技術だ。
RAGの実装プロセス：設計から本番稼働まで
RAGの実装は、5つのフェーズで構成される。
フェーズ1: ドキュメント収集と前処理
対象ドキュメントを収集し、テキストを抽出する。PDFや Word、Confluence、Notion、社内Wikiなど、形式が多様なほど前処理の難易度が上がる。重複文書の排除、機密レベルの分類、更新日時の管理がこの段階での要点だ。
フェーズ2: チャンキング（文書の分割）
大きなドキュメントを検索可能な単位に分割する。この「チャンキング」が、RAG精度を左右する最重要ステップだ。単純に1000文字ごとに機械的に切ると、文脈が壊れて検索精度が大幅に低下する。論理的なまとまり（段落、章、Q&Aのペア）を意識した分割が必要になる。
フェーズ3: ベクトル化とインデックス構築
各チャンクをEmbeddingモデルで数値ベクトルに変換し、ベクトルデータベースに格納する。OpenAIのtext-embedding-3-small、CohereのEmbed v3、Google のtext-embedding-004 などが主要な選択肢だ。
フェーズ4: 検索と回答生成
ユーザーの質問をベクトル化し、類似度検索で関連チャンクを取得。取得した文脈をプロンプトに含めてLLMに渡し、回答を生成させる。
フェーズ5: 評価と改善
回答品質を継続的に測定する。RAGの評価指標としては、Precision（取得した文書の関連度）、Recall（関連文書の取得漏れ）、Answer Faithfulness（回答が取得文書に忠実か）の3つが基本となる。
9割の企業がつまずく3つの実装の壁
国内企業でRAGを本番稼働まで持っていけるのは、取り組んだ企業の30%にとどまる。失敗の80%以上は技術的な問題ではなく、設計段階の戦略的ミスだ。
壁1: チャンキング問題 — 文脈の境界を見誤る
最も多い失敗がこれだ。文字数ベースの単純なチャンキングは実装が簡単なため多用されるが、「1つの意味のまとまりが複数チャンクに分断される」という問題を引き起こす。たとえば、「Aという条件を満たす場合、Bという対応をする」という一文が二つのチャンクに分かれると、どちらのチャンクも単独では意味をなさなくなる。
Lat91では、社内のナレッジを10体のAIエージェントが参照できるように、RAGを活用した知識基盤を構築している。最初はシンプルなチャンク分割+ベクトル検索から始めたが、実際に動かすとすぐに壁にぶつかった。特に苦労したのは、文書の「境界問題」だ。議事録や提案書は論理的なまとまりで区切られているため、文字数だけで機械的にチャンク分割すると文脈が壊れ、検索精度が大幅に低下した。
解決策は、セマンティックチャンキングと呼ばれる手法だ。文章の意味的なまとまりを検出してから分割する。あるいは、チャンク間にオーバーラップ（重複部分）を設けることで文脈の連続性を保つ方法も有効だ。
壁2: 検索精度問題 — 「関連する」と「正しい」の混同
ベクトル検索は意味的な類似度で文書を取得するが、「意味が近い文書」が「質問の答えを持つ文書」とは限らない。検索精度が30%低下するケースも報告されており、ノイズの多い社内データでは特にこの問題が顕在化する。
対策として有効なのはハイブリッド検索だ。ベクトル検索（意味的類似度）とキーワード検索（BM25等）を組み合わせることで、単独では取りこぼす情報を補完し合う。Weaviateはこのハイブリッド検索を標準で提供しており、特にガバナンス要件が厳しい企業での採用が多い。
壁3: ドキュメント管理問題 — RAGは「設置したら終わり」ではない
RAGシステムの精度は、ドキュメントの質と鮮度に直結する。古い規程、矛盾した情報、重複した文書が混在したままベクトルDBに投入すると、正確性が担保できなくなる。本番稼働後に最も見落とされるのが、この継続的なドキュメント管理だ。
更新があるたびにベクトルDBを再構築する仕組み、ドキュメントの有効期限管理、バージョン管理の仕組みを実装段階から設計に含める必要がある。後付けで対応しようとすると、システム全体の再設計が必要になる。
RAGとファインチューニング：どちらを選ぶか
「RAGかファインチューニングか」という議論は、しばしば二項対立として扱われるが、それは誤りだ。用途によって最適解が異なる。
判断の基準はシンプルだ。「事実に基づいた正確な回答が必要で、情報が頻繁に更新される」なら RAG。「特定の文体・形式・振る舞いを習得させたい」ならファインチューニング。「社内ドキュメントをAIが参照できるようにしたい」という要件は、ほぼRAGで解決する。
注意すべきは、「ファインチューニングすれば社内知識を覚えさせられる」という誤解だ。ファインチューニングは知識の詰め込みには向かない。特定の詳細情報についてファインチューニングされたモデルも、ハルシネーションを起こす。ファインチューニングが有効なのは、「どのように答えるか（形式・トーン・推論スタイル）」を習得させる場面だ。
海外企業の実践事例（具体的な数字・成果）
RAGの実用化において、海外のテクノロジー企業は日本より2〜3年先行している。
Instacart: 社内知識検索の精度向上
食料品デリバリーサービスのInstacartは、pgvector を活用したRAGシステムを本番運用している。社内の膨大な商品データと業務マニュアルを対象に、サポートチームが自然言語で検索できる環境を構築。従来のキーワード検索と比較して、関連情報への到達速度を大幅に改善した。
法律事務所でのRAG活用: 契約書レビューの効率化
米国の大手法律事務所では、数万件の過去判例と契約書をベクトルDBに格納し、RAGで参照するシステムを導入した。弁護士が新規案件の関連判例を探す時間が従来の数時間から数十分に短縮されたという事例が報告されている。この領域でPineconeが採用されているケースが多く、レイテンシーが重要なインタラクティブ検索では、マネージドサービスとしての安定性が評価されている。
Supabase: 開発者ドキュメントのRAG実装
オープンソースのデータベースプラットフォームSupabaseは、pgvectorを使ったRAGをドキュメントサイトに実装している。ユーザーが技術的な質問をすると、公式ドキュメントから関連箇所を検索して回答する。ハルシネーションを抑えつつ、最新のAPIリファレンスに基づいた回答が可能になっている。
カスタマーサポートへの適用: 応答時間50%削減
SaaS企業を中心に、カスタマーサポートチャットボットへのRAG適用が拡大している。製品マニュアル、FAQ、過去のサポートチケットをナレッジベースとして構築し、一次対応の自動化率と精度の両立を実現。手動でFAQを更新する工数が不要になる点が、運用コスト削減に直結している。
具体的な始め方：月曜日から試せる3ステップ
「何から始めればいいかわからない」という状況を解消するために、最小限の工数でパイロットを開始できる手順を示す。
Step 1: ドキュメント整理（1〜2日）
対象ドキュメントを選定する。最初は10〜50件程度の小規模なコレクションから始めること。選定の基準は「よく参照されるが見つけるのが面倒な文書」だ。社内規程、FAQ、製品マニュアル、議事録のうちの1種類に絞る。
重要なのは品質チェックだ。古い文書、矛盾した記述、重複しているファイルを先に除去する。ゴミを入れればゴミが出てくる（Garbage In, Garbage Out）の法則はRAGでも例外なく成立する。
Step 2: ツール選択とパイロット環境構築（2〜3日）
最初の選択肢として推奨するのは以下の組み合わせだ。
- オーケストレーション: LangChain または LlamaIndex（Pythonのエコシステムが充実。日本語ドキュメントも豊富）
- ベクトルDB（プロト）: ChromaDB（ローカルで動作、設定ゼロ、プロトタイプに最適）
- ベクトルDB（本番）: Weaviate（ハイブリッド検索、データガバナンス対応、セルフホストまたはクラウド）
- Embeddingモデル: OpenAI text-embedding-3-small（コスト効率が高く、日本語精度も安定）
- LLM: Claude Sonnet（ロングコンテキスト対応、日本語品質が高い）
ChromaDB + LangChain + OpenAI のスタックであれば、Pythonのコードを100行以内で動作するプロトタイプを作れる。まず動かすことが最優先だ。
Step 3: パイロット実装と評価（1〜2週間）
選定したドキュメントをChromaDBに投入し、5〜10問のテスト質問を作成する。テスト質問は「正解が明確に存在する質問」に限定すること。曖昧な質問でのパイロットは評価ができない。
評価は3つの視点で行う。
- 取得精度: 正しいチャンクが上位に来ているか。ログを確認して取得されたチャンクの内容を目視する
- 回答の忠実性: 回答が取得チャンクの内容に基づいているか。「でたらめな情報をもっともらしく言っていないか」を確認する
- 回答の有用性: 実際にその回答が業務で使えるか。使えない回答の原因がチャンキングなのか、検索なのか、プロンプトなのかを切り分ける
パイロットの目的は「完璧なシステムを作ること」ではなく、「自社のデータとユースケースで何が起きるかを理解すること」だ。失敗から学ぶこと前提で、まず動かす。
よくある誤解と反論（正直な回答）
Q: 「全社のドキュメントを全部入れれば精度が上がるのでは？」
A: 逆だ。ドキュメントが増えれば増えるほど、ノイズが増え、検索精度は下がる。重要なのは「何を入れるか」ではなく「何を入れないか」の選択だ。最初は対象範囲を絞り、精度が確認できてから拡張する。
Q: 「RAGを入れれば社内のAIアシスタントができあがるのでは？」
A: RAGは検索と回答生成の仕組みだ。UI、認証、権限管理、ログ管理、監査証跡、継続的なドキュメント更新の仕組みが別途必要になる。RAGはあくまでコアコンポーネントのひとつにすぎない。
Q: 「クラウドサービス（ChatGPT Enterprise等）を使えばRAGは不要では？」
A: ChatGPT EnterpriseにもRAG的な機能（ファイルのアップロードと参照）は存在する。しかし、自社のシステムとの統合、アクセス権限の細かい制御、コストの最適化、データの保持場所の選択が必要な場合は、自前のRAG実装が適している。
Q: 「PoC（概念実証）では動いたが、本番では精度が落ちる。なぜ？」
A: これは最も頻繁に報告される問題だ。PoCでは整形されたデータを使うことが多いが、本番では非構造化データ、古い文書、表記ゆれが混在する。本番品質のデータで早い段階からテストすることが根本的な解決策だ。
まとめ
RAGは「社内データをAIに読ませる技術」ではなく、「AIが間違えない状況を設計する技術」だ。この認識の違いが、実装の成否を分ける。
チャンキングの設計、検索精度の確保、ドキュメント管理の継続——この3つが9割の企業がつまずく壁であり、裏を返せば、この3つを丁寧に設計すれば、他社の失敗を回避できる。
RAGの導入は難しくない。難しいのは、動き続けるRAGシステムを維持することだ。小さく始め、品質を測定し、段階的に拡張する。「月曜日に10件のドキュメントでパイロットを始める」ことが、最速の学習ループだ。
Lat91では、社内データを活用したAIエージェントの構築を支援しています。
「社内のナレッジをAIに活かしたいが、何から始めればいいかわからない」という方は、まずは無料相談からお気軽にどうぞ。