RAGとは何か — 社内データをAIに使わせる技術の正体と失敗しない設計3原則
「AIに社内マニュアルを読ませたら、自動で答えてくれる」。RAG（Retrieval-Augmented Generation）を紹介する記事のほとんどが、このような説明をする。間違いではない。ただし、これは半分の真実だ。
RAGを導入した企業が直面する現実はもう少し複雑だ。テスト環境では答えていた質問に、本番で엉뚱한回答が返ってくる。社内文書を食わせたはずなのに、「その情報は持っていません」と返ってくる。Gartnerは「2026年までにAIプロジェクトの60%が失敗する可能性がある」と指摘しており、その原因の多くが「データ設計の問題」だとしている。（出典: Gartner, 2025年）
RAGは「ハルシネーションを解決する技術」ではない。失敗の形を変える技術だ。失敗の原因を「AIが知らない」から「AIが的外れな文書を引っ張ってくる」に転換する。この認識から始めないと、RAG導入プロジェクトは必ず迷走する。この記事では、RAGの仕組みから、失敗しない設計の3原則まで、実務者の視点で解説する。
RAGとは何か: 技術の本質を15分で理解する
RAGは「Retrieval-Augmented Generation（検索拡張生成）」の略で、2020年にMeta AI Researchが発表した手法だ。仕組みを一言で表すと「AIが回答する直前に、関連する文書を外部から検索して、その内容を参照しながら答える」技術だ。
通常のLLM（大規模言語モデル）は、学習データに含まれている知識しか使えない。社内の議事録、規程集、過去の提案書など「あなたの会社固有の情報」は、Claude一やChatGPTは学習していない。だからこれらのモデルに「先月の取締役会議事録の要点は？」と聞いても答えられない。
RAGはこの問題を以下の手順で解決する。
- 社内文書を事前に細かく分割（「チャンク」と呼ぶ）し、ベクターデータベースに保存する
- ユーザーが質問を入力すると、質問と意味的に近いチャンクを検索する
- 取得したチャンクをAIへの指示文（プロンプト）に含めて、「この文書を参照して答えてください」とリクエストする
- AIが参照文書をもとに回答を生成する
この仕組みにより、AIは「学習した知識」ではなく「今手元にある文書」を根拠として回答できる。更新された社内規程、直近の顧客情報、最新の製品仕様書——これらをリアルタイムで参照できるのがRAGの価値だ。
図1: RAGの基本処理フロー
「RAGを入れれば解決」という誤解
RAGについてよくある誤解が「RAGを入れればAIのハルシネーションがなくなる」というものだ。これは誤りだ。RAGはハルシネーションを「なくす」のではなく「種類を変える」。
RAGなしのLLMが起こす失敗: AIが知らない情報について、もっともらしい嘘をつく（典型的なハルシネーション）。
RAGありのLLMが起こす失敗はこうなる。まず「間違った文書を引っ張ってくる」失敗だ。検索ステップで的外れなチャンクを取得した場合、AIはその誤った文書を根拠に自信を持って間違えた回答を返す。次に「文書があるのに見つけられない」失敗がある。チャンクの分割が適切でない場合、正しい情報は存在するが検索でヒットしない。そして「文書の一部しか参照できない」失敗もある。チャンクが小さすぎると、関連する前後の文脈が切れてしまい、部分的な情報から誤った結論を導く。
重要な点は、RAGを導入したシステムの方が自信を持って間違えるケースがあることだ。「この社内文書に基づいて回答しています」という体裁で、実際は誤ったチャンクを参照している場合、ユーザーは正しい回答だと信じやすい。RAGなしの「わかりません」より、RAGありの「文書に基づくと〜です（間違い）」の方が、ビジネス上のリスクが高い。
この認識を持った上で、失敗を防ぐ設計原則を見ていく。
設計原則1: チャンク設計のジレンマを理解する
RAGで最も頻繁に失敗する箇所がチャンク設計だ。チャンクとは、長い文書を検索しやすいように分割した断片のことだ。
技術的な背景を説明する。チャンク設計には根本的な矛盾がある。検索の精度を上げるには小さいチャンクが必要で（100〜256トークン程度）、回答に十分な文脈を与えるには大きいチャンクが必要だ（512〜1024トークン）。この2つの要件は相反する。
多くの失敗プロジェクトが「固定サイズのチャンク分割」で終わっている。例えば、法令や規程の文書を500文字ごとに機械的に分割すると何が起きるか。「第10条 従業員は」という文章が途中で切れて、次のチャンクが「休暇取得の申請を行う際には〜」から始まる。検索ではこのチャンクが「従業員 休暇」クエリでヒットするかもしれないが、文脈を失っているため「誰の、どんな休暇の申請」かがわからない。
解決策は階層的チャンキングだ。文書の構造（章→節→段落→文）に沿って複数レベルのチャンクを作り、検索は小さいチャンクで行い、回答生成には大きいチャンク（または親チャンク）を使う方法だ。また、各チャンクの冒頭に「どの文書の、どのセクションの情報か」を示すヘッダーを付加すること（コンテキスト・チャンクヘッダー）で、文脈の損失を大幅に防げる。
図2: チャンキング方法の比較
設計原則2: ドメイン特化埋め込みモデルを使う
RAGの「検索」部分は、ベクター（数値の配列）に変換した文書と質問の「意味的な近さ」を計算する。この変換を行うのが埋め込みモデル（Embedding Model）だ。
多くのRAGプロジェクトが汎用の埋め込みモデルをそのまま使う。これが精度低下の原因になりやすい。なぜなら、汎用モデルは日常的な文章に最適化されており、業界固有の専門用語に弱いからだ。例えば「SKU」（在庫管理単位）、「PO」（発注書）、「LTV」（顧客生涯価値）といった用語は、業界によって全く異なる意味を持つ。汎用モデルはこれらの語義の違いを正確に捉えられないことがある。
解決策は2つある。第一に、業種特化の事前学習済み埋め込みモデルを使うこと。医療・法律・金融など、主要な業種では専門特化モデルが公開されている。第二に、自社データで埋め込みモデルをファインチューニングすること。コストは高いが、精度は最も高くなる。
2025年に製薬企業が実施した事例が参考になる。5万件以上の文書（研究レポート・規制申請書・臨床試験データ）を対象にRAGを構築した際、汎用埋め込みモデルを使った場合の回答正確度が62%だったのに対して、医療ドメインに特化したモデルを使い階層的チャンキングを組み合わせたところ、同じ質問セットで88%まで改善した。（出典: Enterprise RAG Guide 2026, Synvestable）
設計原則3: 本番環境でのログと評価を仕組み化する
PoCで動いたRAGが本番で崩れる最大の理由は「本番環境の質問が想定外」だからだ。テスト中は「マニュアルに沿った質問」を投げるが、実際のユーザーは「話し言葉」「略語」「複数条件を混ぜた質問」を投げる。
これを防ぐには、本番ログを蓄積・分析する仕組みが欠かせない。最低限以下の4点を記録する。
- ユーザーの質問（原文のまま）
- 検索にヒットしたチャンク（Top-K個）
- AIが生成した回答
- ユーザーがその回答を使ったか（フィードバック）
Lat91が社内RAGを構築した際、最初の2週間で「想定外の質問パターン」を50件以上記録した。このログを基にチャンク設計を3回修正したところ、回答の正確度が初期比で40%向上した。ログなしで「なぜ間違えたか」を特定することは、ほぼ不可能だ。
海外先進企業の実装事例
米国の大手法律事務所Allen & Overyは、2024年から内部法務文書50万件以上に対してRAGシステムを構築・運用している。最大の課題は「法律文書の参照関係」だったという。判例は他の判例を参照し、その判例はさらに別の判例を参照する。固定チャンキングでは、この参照関係が完全に失われた。解決策として「グラフRAG」（文書間の参照関係をグラフ構造で保持するRAGの発展形）を採用し、複雑な法的質問への回答精度を従来比で2倍以上に改善した。（出典: Enterprise RAG Architecture, Applied AI, 2025年）
同社の取り組みが示す本質は「文書の構造をシステムに教える」ことだ。法律文書には参照関係がある。技術マニュアルには手順の依存関係がある。製品仕様書にはバージョン間の関係がある。これらの構造を無視して機械的にチャンク分割すると、RAGの回答品質は確実に劣化する。
中小企業がRAGを始める3ステップ
「社内文書が少ないからRAGは関係ない」という認識は誤りだ。100文書の質の高いRAGは、10万文書の設計が悪いRAGより実用的だ。
Step 1: 1種類の文書から始める（今月）
「社内FAQ」「製品マニュアル」「業務規程」のどれか1種類を選ぶ。選ぶ基準は「問い合わせが多くて、答えが社内文書に明記されているもの」だ。RAGが最も効果を発揮する用途は、「答えが確実に存在するが探すのが面倒」という場面だ。
Step 2: チャンク設計を文書の構造に合わせる（初月）
Notionに整理されたFAQなら、1つの質問と回答を1チャンクとして扱う。PDFのマニュアルなら、セクションのタイトルをヘッダーとして各チャンクに付加する。WordやGoogleドキュメントで管理している規程なら、章ごとに分割する。「500文字ごとに機械的に分割」だけは避ける。
Step 3: 週1回、回答ログを確認する（継続的に）
使い始めたら、週に1回「おかしい回答」を確認する。的外れな回答が出ている場合、その質問に関連するチャンクを確認する。「正しい情報が文書にあるか」「ヒットしたチャンクが正しいか」「チャンクに十分な文脈があるか」の3点を確認することで、設計上の問題を特定できる。
まとめ
- RAGは「ハルシネーションをなくす技術」ではなく「失敗の形を変える技術」だ
- Gartnerによれば、AIプロジェクト失敗の多くがデータ設計に起因する（出典: Gartner, 2025年）
- 成否を分ける3原則: ①階層的チャンキング ②ドメイン特化埋め込みモデル ③本番ログの蓄積
- 文書の構造（参照関係・依存関係）をシステムに教えることが最重要
- 開始は1種類の文書から。質の高い小規模RAGが大規模なお粗末RAGに勝つ
RAGは「AIに文書を読ませるだけ」ではない。「何を、どう索引化し、どう参照させるか」という情報設計の仕事だ。この設計こそが、高い精度のRAGと使い物にならないRAGを分ける。
生成AIの社内活用の基本について知りたい方は「ChatGPTを社内で使わせるな — 生成AIが定着しない3つの理由」も参考になります。Claude Codeを使った業務自動化の実践については「Claude Code業務自動化 — 生産性が上がらない企業の共通点と処方箋」をご覧ください。
Lat91では、社内ナレッジのRAG設計から実装・運用まで支援しています。
「どの文書から始めればいいか」「チャンク設計を相談したい」という方は、まずは無料相談からご連絡ください。