RAGとは？社内資料をAIに読ませる前に知るべき限界と設計

RAGとは、社内資料を細かく分割して検索し、質問に近い断片だけをAIに渡して答えさせる仕組みです。断片化によって文脈が失われ、検索が的外れになりやすいのが主な限界です。整理された資料ほど検索精度は上がり、資料が少なければRAGを組まずに全文を渡す方が確実な場合もあります。

要点(TL;DR)

• RAGとは、資料を検索してAIに渡す仕組みのこと。ナレッジDBそのものではなく、それを検索する仕組み
• 資料を分割する過程で文脈が失われると、検索は的外れな断片を拾う(Anthropicの実測では検索失敗率5.7%)
• 断片に説明的な文脈を付けるだけで、その失敗率は最大67%下がる(同実測)
• 精度は検索の仕組みだけでなく、資料の整理(ファイル名・グルーピング)にも左右される
• 資料が少ない(目安: 約20万トークン、およそ500ページ以下)なら、RAGを組まずに全文を渡す方が確実な場合もある

RAGとは何か — 検索してAIに渡す仕組み

RAG(Retrieval-Augmented Generation、検索拡張生成)とは、大量の資料をあらかじめ細かい断片に分割して索引を作り、AIが質問に答える際に関連度の高い断片だけを検索して呼び出し、その断片を根拠として回答を生成する仕組みです。資料そのものではなく、資料の中から必要な部分を探し出して渡す「検索の仕組み」がRAGの中身です。

ここはナレッジDBと混同しやすい点です。ナレッジDBは判断・手順・過去のやり取りを編纂した知識そのものであり、RAGはその知識をAIに検索させて渡す手段です。ナレッジDBの土台が薄ければ、どれだけ検索の仕組みを工夫してもAIに渡す中身が乏しく、答えの質は上がりません。RAGを組む前提として、まず何を溜めるかを決める話はなぜAIエージェントはナレッジDBから作るべきなのかで扱っています。

なぜ資料をそのまま渡さず、検索するのか

資料を検索してから渡す理由は、AIが一度に読める量(コンテキストウィンドウ)に上限があり、資料が増えるほど全部をその場で読ませるのが難しくなるからです。数百ページの社内資料を毎回まるごと読ませるのは、遅く、費用もかさみます。そこで資料を断片に分けて索引化し、質問に関係する部分だけを引いてくるのがRAGの発想です。

一方でAnthropicは、資料全体がおよそ20万トークン(紙で500ページ程度)に収まるなら、検索の仕組みを組まずにそのまま全文を渡す方が確実な場合があるとも述べています。近年はキャッシュの仕組みで、全文を渡すコストと速度も改善しています。つまりRAGは「資料が増えて全部は渡せなくなったときの解決策」であり、資料が少ないうちから急いで導入する仕組みではありません。この見極めが、RAGを検討する最初の分岐点になります。

断片化で文脈が壊れる、という限界

RAGの一つ目の限界は、資料を機械的に分割する過程で、断片が元の文脈を失うことです。Anthropicはこの問題を、資料を分割・検索する標準的な手法が「文脈をしばしば壊してしまう」と説明しています。

たとえば「売上が前年から20%増えた」という一文だけを含む断片があったとします。この断片には、どの会社の、どの期間の売上かという情報が含まれていません。人が読めば前後の文脈から分かることも、断片だけを取り出すと分からなくなります。検索の仕組みは、この文脈の抜けた断片を「関係ない」と判断して取りこぼしたり、逆に見当違いの断片を「関係ある」と誤認したりします。Anthropicの実測では、こうした標準的な分割方法での検索失敗率は5.7%でした。

対策として同社が示したのが、断片ごとに「この断片が何についてのものか」を説明する短い文脈を先頭に付けてから索引を作る手法です。この工夫を加えるだけで失敗率は35%下がり、キーワード検索と併用すると49%、さらに検索結果を並べ直す仕組み(リランク)を足すと67%下がりました。同じ資料・同じ質問でも、断片に文脈を残すという一手間だけで、検索の当たり方が大きく変わります。

検索が外れれば、AIはそれっぽい答えを返す

RAGの二つ目の限界は、検索が外れても、AIは「分かりません」ではなく、それっぽい答えを返してしまう傾向があることです。RAGは根拠となる断片をAIに渡す仕組みですが、渡された断片が的外れであれば、AIはその的外れな断片をもとに、自信ありげな誤った回答を組み立てます。

これは前の限界と地続きの問題です。断片化で文脈が壊れているほど、検索は正しい断片を引き当てにくくなり、間違った断片が渡る確率が上がります。厄介なのは、答えの見た目からは検索が外れたのか、AIが誤って解釈したのかが分かりにくいことです。社内資料をAIに読ませる設計では、検索結果に根拠の出典(どの資料のどの部分から答えたか)を必ず表示させ、人が確認できる状態にしておくことが、この限界への現実的な備えになります。

精度は、資料の整理次第で変わる

RAGの三つ目の限界は、検索の精度が、渡す資料の整理状態に強く依存することです。「RAGを導入すれば資料が雑でも検索してくれる」というのは誤解です。

この点は、AIベンダーであるAnthropic自身のヘルプ記事でも認められています。同社のClaude Projects機能は、資料の量が一定の閾値を超えると自動でRAGに切り替わりますが、検索の的を絞るための工夫として、資料には分かりやすいファイル名を付け、関連する資料はまとめ、質問時には資料名を具体的に挙げることを推奨しています。検索の仕組みを作った側が、資料の整理を精度の前提条件として挙げているという事実は重い意味を持ちます。断片に文脈を付ける技術的な工夫(前述)と、資料そのものの整理という運用上の工夫は、両方が揃って初めて機能します。

資料が少なければ、RAGを組まない方が確実な場合もある

RAGの四つ目の限界は、資料が少ない場面ではRAG自体が過剰投資になりやすいことです。検索の仕組みは、断片への分割・索引の構築・検索精度の検証という工程を必要とします。資料がそもそも少なければ、この工程そのものが不要な手間になります。

目安になるのが、前述の約20万トークン(およそ500ページ)という基準です。これに収まる資料量であれば、検索という中間工程を挟まず、質問のたびに関連資料を丸ごと渡す方が、取りこぼしの心配がなく確実です。1人社長やマイクロチームが最初に持つ資料量は、多くの場合この基準よりずっと小さい。だとすれば、最初にやるべきはRAGの仕組みを組むことではなく、判断基準や過去の事例を資料として書き出し、整理することです。RAGは、その資料が育って全文を渡せなくなったときに、初めて検討すればよい話になります。

RAGを組む前に、何を判断すべきか

RAGを組む前に判断すべきことは、資料の量と、資料がどれだけ整理されているかの2点です。この2つの組み合わせで、取るべき手段が変わります。

資料が少なく整理されているなら、検索の仕組みを組まずに全文を渡すだけで足ります。資料が少ないのに整理されていないなら、先にやるべきは検索の導入ではなく整理です。資料が多く整理されているなら、断片に文脈を付けたRAGが効果を発揮します。もっとも避けたいのは、資料が多いまま整理を後回しにして検索の仕組みだけを入れることです。この状態では、検索は動いていても的外れな断片を拾い続け、「AIに社内資料を読ませたのに、的外れな答えしか返らない」という結果になります。

日本の1人社長・マイクロチームでは、何が違うのか

大企業とマイクロチームでは、RAGを検討する前提が違います。大企業は資料の量が最初から多く、部署ごとに整理の状態もばらつきます。RAGの導入自体は早期に必要になりやすい一方、資料の整理を全社で揃えるのに時間がかかります。

1人社長やマイクロチームは逆の事情を持っています。資料の絶対量が少なく、前述の基準に収まることが多いため、多くの場合はRAGを急いで組む必要がありません。一方で、資料が経営者一人の頭の中とチャットのやり取りに散らばっている点は、大企業以上に深刻です。整理されていない資料は、量が少なくてもAIに渡した瞬間に文脈が伝わりません。だからこの規模の会社がまず投資すべきは、検索の仕組みではなく、判断基準・過去の事例・顧客ごとの事情を文章として書き出す作業です。判断を書き出す具体的な進め方はセカンドブレインで扱っています。資料が育ち、量が基準を超えてから、断片に文脈を付けたRAGを検討すれば十分です。順序を間違えなければ、この規模の会社ほど、遠回りをせずに済みます。

よくある質問(FAQ)

Q. RAGとは何ですか? A. 資料を細かく分割して検索の索引を作り、質問に近い断片だけをAIに渡して答えさせる仕組みです。資料そのもの(ナレッジDB)ではなく、それを検索して渡す手段です。

Q. RAGを使えば、検索は必ず正確になりますか? A. なりません。断片化で文脈が失われたり、資料が整理されていなかったりすると、検索は的外れな断片を拾います。Anthropicの実測でも、標準的な分割方法での検索失敗率は5.7%でした。

Q. 小さな会社でもRAGは必要ですか? A. 必ずしも必要ではありません。資料の全体量がおよそ20万トークン(500ページ程度)以内なら、検索の仕組みを組まず全文を渡す方が確実な場合があります。

Q. RAGの検索精度を上げるには何をすればいいですか? A. 断片に「何についての断片か」を示す文脈を付けることと、資料に分かりやすい名前を付けて整理することの両方が効きます。技術的な工夫と運用上の整理は、どちらか一方では機能しません。

---

出典・参考

• Anthropic「Introducing Contextual Retrieval」: 標準的なチャンク分割は文脈を壊しやすく検索失敗率5.7%。断片に説明的な文脈を付けると単体35%・キーワード検索併用49%・リランク併用67%、失敗率が下がる。約20万トークン(約500ページ)以下は全文投入で足りるという指針 — https://www.anthropic.com/news/contextual-retrieval
• Anthropic「Retrieval augmented generation (RAG) for projects」(Claudeヘルプ記事): 資料量が閾値を超えると自動でRAGに切り替わる仕組み、精度を保つための分かりやすいファイル名・資料のグルーピング・資料名を指定した質問という推奨 — https://support.claude.com/en/articles/11473015-retrieval-augmented-generation-rag-for-projects

監修: Kazuya Hibara(Automate & Augment(株式会社設立準備中) 代表) — 業務フロー再設計とAIエージェント常駐運用を専門とし、自社のナレッジDBも実際に運用している。