RAGとは？企業の知識資産をAIに使わせる技術の本質と設計の落とし穴
「社内のドキュメントをAIが参照できるようにしたい」という要望が経営層から増えている。RAGはその実現手段として2024年から急速に普及しているが、実装後に「期待したほど動かない」という声が絶えない。問題はベクトル検索の精度ではなく、意外なところにある。
結論から言うと、RAGが機能しない理由のほとんどは、企業のドキュメントが「検索されること」を前提に書かれていないことにある。これはシステムの問題ではなく、知識の構造問題だ。
RAGの仕組みを3分で理解する
RAGは「Retrieval Augmented Generation（検索拡張生成）」の略語で、通常のLLM（大規模言語モデル）が持つ根本的な制約を補う技術だ。
通常のLLMは、学習時点までのデータしか知らない。ChatGPTやClaudeに「自社の製品仕様は？」と聞いても、当然ながら答えられない。学習データに入っていないからだ。これを「知識のカットオフ問題」と呼ぶ。
RAGはこの問題を以下のプロセスで解決する。
- 社内ドキュメントを「ベクトル（数値の配列）」に変換して専用データベースに保存する
- ユーザーの質問を同様にベクトル化する
- 質問ベクトルに類似した文書ベクトルを検索し、関連文書を取得する
- 取得した文書をLLMに渡し「この文書を参考に答えよ」と指示する
図1: RAGの処理フロー。ベクトルDBから関連文書を取得し、LLMが参照して回答する
Googleの検索とは根本的に違う。Googleはページのリンク構造や人気度などを組み合わせて順位付けするが、RAGは「意味の近さ」で文書を取得する。「コスト」と入力しても「費用」「予算」「価格」に関する文書が取れるのはこのためだ。
ベクトルDBとして使われる主なツールはPinecone、Qdrant、Weaviateなど。LLMと組み合わせるフレームワークはLangChainとLlamaIndexが主流で、2025年時点で企業向けRAG実装の70%以上がこのどちらかを使っているとされる（出典: AI Infrastructure Alliance, 2025年レポート）。
仕組みとしては理解しやすい。問題は、実装してみると「動いているのに使えない」状態に陥ることだ。
なぜRAGは「動いているのに使えない」状態になるか
「検索精度が低い」「엉뚱な文書が取れる」という声はよく聞く。だが、その原因のほとんどはベクトル検索のアルゴリズムではない。
私たちが社内FAQをRAGに入れたとき、質問の仕方によって全く異なる答えが返ってきた経験がある。「料金はいくらですか」と聞くと正確に返ってくるが、「費用を教えてください」と聞くと関係のない文書が引っかかった。最初はベクトルDBの設定の問題だと疑い、パラメータを調整した。しかし原因は別のところにあった。チャンク（文書の切り方）の問題だ。
FAQの回答文が前後の文脈と一緒に固定長で切られていたため、「料金」という単語が含まれる文書と含まれない文書が別々のチャンクに分かれていたのだ。
この経験から気づいたことがある。企業のドキュメントは、そもそも「検索されること」を前提に書かれていない。
- 議事録は「決まったこと」と「議論の経緯」が混在している。検索したいのは結論だが、それが文書の中に埋まっている
- マニュアルは前のページを読んでいる前提で書かれている。「手順3はこちらを参照」という参照リンクが断片だと意味をなさない
- メールの返信チェーンは文脈なしでは意味不明になる。「承知しました」という一文だけ取れても答えにならない
ここに構造的な問題がある。RAGは「適切に書かれた文書」を検索するシステムであり、「適切に書かれていない文書」を自動で整理するシステムではない。
多くの企業がRAGに期待していることは後者だ。「雑多に積み上がった社内文書に、AIが魔法をかけてくれる」という期待。それは技術的に不可能ではないが、2026年時点の実用RAGで実現できる姿ではない。
「知識の質」がRAGの成否を決める理由
RAGのパフォーマンスを左右する要素を整理すると、以下の3層に分けられる。
| 層 | 要素 | 影響度 |
|---|---|---|
| ドキュメント品質 | 文書の構造・明確さ・重複の有無 | 最大 |
| チャンキング設計 | どの単位で文書を分割するか | 大 |
| ベクトルDB設定 | 類似度の閾値・取得件数 | 中 |
多くの人がいじるのは一番下の「ベクトルDB設定」だ。しかし影響度は一番低い。成否を決めるのは一番上の「ドキュメント品質」と、その次の「チャンキング設計」にある。
チャンキングの落とし穴
チャンキングとは、大きなドキュメントをRAGが処理できる小さな単位に分割する作業だ。
最も単純な方法は「固定長チャンキング」で、例えば512トークン（日本語で約700〜800字）ごとに切る。実装が簡単なため多く使われているが、文脈を無視して切るため「意味の切断」が起きやすい。
一文が途中で切れることもある。「この製品の保証期間は3年です。ただし、消耗品につい」というところで切れると、次のチャンクに「ては1年となります。」という断片が残る。どちらも意味をなさない。
対策は「意味単位チャンキング」だ。段落・セクション・Q&Aのペアなど、文書の論理構造に沿って分割する。実装コストは上がるが、精度への影響は大きい。
チャンクサイズの目安は512〜1024トークン（文書の性質による）。法律文書や技術仕様書のように情報密度が高いものは小さく、FAQ形式のものは1問1答で切るのが有効だ。
PDFからの抽出で起きる問題
企業の文書はPDFで保存されていることが多いが、PDFからのテキスト抽出は想像以上に難しい。
レイアウトが複雑なPDFでは、テキストの読み取り順序が崩れる。2段組みのレポートで、左カラムの全文を読んだ後に右カラムの全文を読む、という形になることがある。表の中のデータが行・列バラバラに抽出されることもある。
図や画像の中にテキストが含まれている場合、通常のPDF抽出ツールでは読み取れない。OCR（光学文字認識）を組み合わせる必要があるが、精度は100%ではない。
スライドからの抽出も同様だ。PowerPointの箇条書きは「断片の集合」であり、単体では文脈を持たない。「→課題：コスト増」という一行だけ取得しても、何のコストが増えているのか判断できない。
事例1: 英国の法律事務所のケース
英国の大手法律事務所（弁護士230名規模）が、判例検索システムにRAGを導入した事例がある。
構築から3ヶ月後の精度は50%以下。実際の判例と関係のない文書が半数以上を占めていた。原因を分析すると、判例文書の構造問題だった。英国の判例は「事実関係」「争点」「判決理由」「結論」が長文で連続しており、固定長チャンキングでは文書の性質が失われていた。
その後、6ヶ月をかけてドキュメントの再構造化を行った。各判例を「争点ごと」に分割し、結論を先頭に置く形式に書き直した。結果、精度は85%に改善した。
注目すべきは時間の配分だ。システム構築に3ヶ月、ドキュメント整備に6ヶ月。知識整備の方が2倍の時間がかかった。
事例2: 米国コールセンター企業のケース
米国の家電メーカー系コールセンター（オペレーター数420名）が、問い合わせ対応支援にRAGを活用しようとした。
製品マニュアル（総ページ数4,700ページ）をそのままRAGに投入した第1フェーズでは、正答率32%にとどまった。マニュアルの文体が「手順を追った説明文」であり、「〇〇の場合はどうすればよいか」という問い合わせ形式とミスマッチが生じていた。
第2フェーズで、よくある問い合わせ上位200件を元にマニュアルをQ&A形式に書き直した。4,700ページのマニュアルを2,100件のQ&Aに再編成するために社内の専門チームが3ヶ月を要したが、正答率は68%に改善した。ベクトルDBもLLMも変えていない。変えたのは文書の形式だけだ。
この事例が示す本質は明確だ。RAGの精度を2倍にしたのは、AIの改善ではなく人間による知識の整備だった。
図2: RAGの成否を決める3層構造。技術的な設定変更よりも、知識の品質が最も影響する
RAGを成功させる3つの設計原則
失敗事例に共通するパターンから、実用レベルのRAGを構築するための設計原則を3つ導いた。
原則1: ドキュメントファーストで考える
RAGの導入を「システム構築」として捉えると失敗する。「知識資産の整備プロジェクト」として捉えるべきだ。
導入前に行うべき棚卸しは以下の4点だ。
- 何の質問に答えさせたいか（用途を明確にする）
- その質問に答えるために必要な文書は何か（スコープを絞る）
- その文書の品質は検索に耐えられるか（構造の評価）
- 文書が不十分なら、整備するか別の手段を取るか（判断）
全社のドキュメントを一度にRAGに入れようとするプロジェクトは、ほぼ確実に失敗する。範囲を絞り、品質を確保することの方が重要だ。
原則2: チャンク設計に工数を使う
チャンキングは「最初に決めてあとは自動」ではなく、継続的に改善が必要な設計上の判断だ。
文書タイプ別の推奨アプローチは以下の通り。
| 文書タイプ | 推奨チャンク単位 | チャンクサイズ目安 |
|---|---|---|
| FAQ | 1問1答のペア | 128〜256トークン |
| マニュアル・手順書 | 1手順ステップ | 256〜512トークン |
| 仕様書・規程 | 1条文・1項目 | 512〜768トークン |
| 議事録 | 1決定事項（要約後） | 256〜512トークン |
| レポート・提案書 | 1セクション | 512〜1024トークン |
また、チャンクに「前後の文脈情報」を付与するオーバーラップ設計も有効だ。前のチャンクの末尾100トークン程度を次のチャンクの先頭に重複させることで、文脈の断絶を軽減できる。
原則3: 評価ループを組み込む
RAGのパフォーマンスを測る指標は2つに分けて管理すべきだ。
一つは「検索の精度」、もう一つは「回答の正確さ」だ。この2つを分けて測定しないと、改善が必要な箇所を特定できない。
例えば、正答率が低い場合に「ベクトルDBを変えてみる」という判断をするケースがある。しかし原因が検索段階にあるのか、LLMの回答生成段階にあるのかを切り分けないと、的外れな改善になる。
評価の仕組みとして実践的なのは「テストクエリセット」を用意することだ。実際のユーザーが問い合わせてきた質問の上位50〜100件を用意し、正解の回答とともに記録する。システムに変更を加えるたびにこのセットで計測し、改善か悪化かを数字で確認する。
主要なフレームワークを使う場合、LlamaIndexにはBuilt-in Evaluation、LangChainにはLangSmithという評価ツールが存在する。これらを活用することで評価の自動化が図れる。
よくある誤解と、その実態
RAGを検討している企業から頻繁に出る誤解を整理しておく。
「GPT-4は長文を読めるから、RAGなしで社内文書を全部渡せばよい」
確かにGPT-4oやClaudeは100万トークン以上のコンテキストを扱える。技術的には全文書を渡すことも不可能ではない。ただし問題が2つある。
一つはコストだ。毎回の問い合わせで数百万字の文書を送信すると、API料金が跳ね上がる。例えば100万トークンの文書を毎日100回参照した場合、Claude Sonnet 3.7の料金換算でおよそ月30〜40万円の推定コストになる。RAGを使えば1回あたりの参照トークン数を数千トークン程度に絞れる。
もう一つは「迷子問題」だ。文書が長くなるほど、LLMは文書の途中にある情報を見落としやすくなる（Lost in the Middleと呼ばれる現象で、複数の研究で確認されている）。関連する情報を的確に取り出すRAGの方が、精度面でも有利なケースが多い。
「ベクトルDBを導入すれば完成する」
ベクトルDBはあくまでインフラだ。図書館の棚に本を並べる設備はあっても、本の中身の品質は別の問題、というのと同じ構造だ。
Pineconeを入れようが、Qdrantを入れようが、投入する文書の品質が低ければ結果は変わらない。ベクトルDBの選定に時間をかけるよりも、文書整備に時間をかける方が投資対効果は高い。
「RAGを入れれば幻覚（ハルシネーション）がなくなる」
これは部分的に正しいが、根本的には誤解だ。
RAGは「参照すべき文書」を提供するが、その文書の内容が誤っていれば、LLMは誤った情報を正確に回答する。文書が古い、記述が曖昧、矛盾する情報が複数の文書に存在する — こうした状況ではRAGが誤りを「保証」してしまう。
また、検索で関連文書が取れなかった場合、LLMが「文書がないなら自分の知識で答えよう」と判断してしまうケースもある（これは実装設計の問題でもある）。RAGはハルシネーションを減らす手段だが、ゼロにするものではない。文書の品質管理とセットで初めて機能する。
まとめ
- RAGは「検索拡張生成」の略で、LLMがリアルタイムで社内文書を参照して回答するための技術だ。仕組みは明快だが、実装後に期待通り動かない事例が多い
- 失敗の根本原因は、企業のドキュメントが「検索されること」を前提に書かれていないことにある。議事録・マニュアル・メールは人間が文脈を持って読む前提で作られており、RAGとは設計思想が異なる
- RAGの成否を決めるのはベクトルDBの設定ではなく、ドキュメント品質とチャンキング設計だ。英国の法律事務所は6ヶ月の文書再構造化で精度を85%に改善し、米国のコールセンターはQ&A形式への書き直しで正答率を2倍にした
- 実装前に「用途の特定→スコープの絞り込み→ドキュメント品質の評価」の順で進めることが重要だ。全社文書を一度に入れるアプローチは失敗する
- 評価ループを最初から設計に含める。「検索の精度」と「回答の正確さ」を分けて測定しないと、改善の方向性を見誤る
RAGは正しく設計すれば、企業の知識資産を実際に使えるインフラに変える力を持つ。ただし「AIに文書を渡せば賢くなる」という期待ではなく、「人間が知識を整備し、AIがそれを活用する」という設計思想で臨むことが前提になる。
知識整備はコストに見える。しかし、整備された知識資産はRAGに限らず、新人教育・品質管理・意思決定支援など、あらゆる業務の基盤になる。RAG導入は、そのきっかけとして活用できる。
RAG設計の相談はLat91へ
Lat91では、RAGを含む企業向けAI活用の設計支援を行っています。「どの文書から始めるべきか」「チャンキング設計はどうすべきか」「評価の仕組みをどう作るか」といった具体的な設計段階から支援します。
まずは無料相談から。こちらのフォームよりお問い合わせください。