社内文書をAIに渡しても精度が出ない理由：RAG設計の落とし穴と成功の原則
「社内マニュアルや仕様書をAIに渡せば、何でも答えてくれる」。そう期待してRAGを導入した企業が、半年後に直面する現実は違う。回答が的外れ、古い情報を引用する、本来参照すべき文書を無視して엉뚱な答えを返す——。MLOps Communityが143社の企業RAGシステムを調査した結果、初年度に重大な障害を経験した割合は73%に達した（2026年調査）。
問題の根本は技術の難しさにない。「大量の文書を入れれば精度が上がる」という誤解が、設計判断を最初から狂わせている。この記事では、RAGが機能しない構造的理由と、成功する企業に共通する設計原則を具体例とともに解説する。
RAGとは何か、そして最大の誤解
RAG（Retrieval-Augmented Generation）は、生成AIが回答を生成する前に外部の文書を検索し、その内容を踏まえて回答を生成する手法だ。3つのステップで構成される。
まずRetrieval（検索）——質問をベクトル（数値の配列）に変換し、事前にインデックス化した文書群の中から意味的に近いテキストを取得する。次にAugmentation（拡張）——取得した文書を「コンテキスト」としてLLMのプロンプトに付加する。最後にGeneration（生成）——コンテキストを踏まえてLLMが回答を生成する。
理論上シンプルだが、この仕組みには根本的な前提がある。「検索が正しく機能していること」だ。ベクトルデータベースは辞書ではなく、検索エンジンに近い。適切に設計されていなければ、無関係な文書を拾い、本当に必要な情報を見落とす。Gartnerは「RAG導入企業の約40%が期待した精度が出ないと報告している」と指摘する（2026年調査）。
なぜ73%が初年度に失敗するのか
失敗パターンには構造的な共通点がある。技術スタックの問題ではなく、設計時の判断ミスだ。日本企業でも頻発している3つを解説する。
落とし穴1：チャンキングを「とりあえず1000トークン」で機械的に切る
RAGの精度の多くはチャンキング（文書を小さな塊に分割する処理）で決まる。ところが多くの企業は、文書を「とりあえず1000トークン」で機械的に切断する。重要な文脈が分断される。
海外での実例がある。米国の大手ヘルスケア企業では、医薬品の投与量に関する注意書きがチャンク境界でちょうど分割された。LLMが取得したのは注意書きの前半だけで、後半の「ただし腎機能障害患者には禁忌」という記述を見落とし、不適切な回答を生成した。直接的なコスト損失は470万ドルに達した（出典: ragaboutit.com, 2026年）。
問題の本質は「どこで切るか」にある。段落の途中で切れば意味が崩れる。仕様書の「条件」と「例外」が別チャンクに入れば、LLMは条件だけを読んで回答する。チャンキングは文書の意味構造を尊重して設計しなければならない。MLOps Communityの調査では「チャンキングは品質が決まるステップであるにもかかわらず、チームが最も時間をかけないステップでもある」と指摘されている（2026年）。
落とし穴2：ベクトル検索だけに頼る
ベクトル検索は意味的な類似性を捉えるのが得意だが、固有名詞・型番・法律条文の正確な文言には弱い。「ABC-1234」という製品番号で検索しても、意味的に近い別の製品情報を拾ってしまうことがある。
2026年のエンタープライズRAGガイドは「ハイブリッド検索（ベクトル検索＋キーワード検索）が一貫してベクトル単独より高精度を示す」と結論づけている（出典: synvestable.com, 2026年）。ベクトルが「意味的に近いもの」を拾い、キーワード検索が「正確に一致するもの」を拾う。この二層構造が精度を安定させる。
落とし穴3：ドキュメントを入れたまま更新しない
RAGシステムは一度インデックス化した後、文書が更新されても自動的には追従しない。社内規定が改定されても古い版がベクトルDBに残り続ける。ある保険会社では、共有フォルダのPDFが更新されたにもかかわらずインデックスが古いままで、期限切れの保険条件を回答し続けた（出典: ragaboutit.com, 2026年）。
更新頻度の高い文書ほど「鮮度管理」の仕組みが必要だ。変更検知と再インデックスを運用の一部として設計しなければならない。
成功する企業の設計3原則
73%が失敗する一方、残り27%には何が共通しているのか。
原則1：意味の単位でチャンクを設計する
成功している企業は、チャンクを「文書の構造」に合わせて切る。マニュアルであれば見出し単位、法律文書であれば条項単位、Q&Aであれば質問と回答の対単位だ。サイズは固定せず、意味が完結する範囲を優先する。さらに、前後のチャンクに内容を少し重複させる「オーバーラップ」も有効だが、10〜15%程度を目安に使う。過剰なオーバーラップはノイズを増やす。
原則2：ハイブリッド検索を採用する
ベクトル検索とキーワード検索を組み合わせ、スコアを統合する（Reciprocal Rank Fusionなど）。pgvectorをすでに使っているPostgreSQLユーザーなら、全文検索機能を組み合わせるだけで実現できる。小規模な利用であれば月額数千〜5万円程度の追加コストで導入できる（出典: uravation.com, 2026年）。
原則3：評価ファーストで設計する
「動いている＝正しい」は最も危険な思い込みだ。RAGは自信満々に間違った回答を返す。成功している企業は、プロンプトを書く前に評価基準を設計し、「どの質問に何%の精度で答えられれば成功か」を定義してから構築を始める。この「Eval-first」アプローチが、設計の手戻りを最小化する（出典: agileinfoways.com, 2026年）。
日本企業の事例：RAGが機能した現場
LINEヤフーは社内問い合わせ対応にRAGを活用し、年間70〜80万時間の業務削減を目標として設定している。トヨタ自動車では技術情報の検索精度が向上し、QA対応時間を30〜40%短縮した実績がある（出典: 国内AI活用動向調査, 2026年）。
共通しているのは「大企業だから成功した」のではない点だ。いずれも最初から全社展開せず、特定の部門・特定の文書カテゴリに絞ってPoCを行い、精度を確認してから展開範囲を広げている。香川県では行政の内部業務向けにRAGを導入し、職員が参照していた条例・規則の検索業務を自動化した。大規模なシステム投資ではなく、既存の行政文書を活用した小さな実証から始めた点が特徴だ。
中小企業はどこから始めるべきか
いきなりベクトルDBを構築する必要はない。試せる順番がある。
Step 1（今週から）: NotebookLMで実体験する
GoogleのNotebookLMは、PDF・Googleドキュメント・テキストをアップロードするだけで社内文書への質問応答が試せる。まず自社で最も問い合わせが多い文書（社内規定・製品マニュアル・FAQ）を10〜20件アップロードし、実際の問い合わせ内容で試してみる。これがRAGの基本挙動を体感する最速の手段だ。
Step 2（1〜2ヶ月後）: DifyまたはClaude Projectsで精度を検証する
DifyはオープンソースのノーコードRAGプラットフォームで、チャンキング設定やハイブリッド検索の切り替えを画面から操作できる。「どのチャンキング設定が自社の文書に合っているか」をここで検証する。Claude Projectsはシステムプロンプトとファイルを組み合わせてRAG的な挙動を手軽に実現できる。
Step 3（効果が確認できたら）: 本格構築へ
pgvector＋PostgreSQLなど、自社インフラに合った構成で本格実装に入る。Step 1〜2を経ていれば「何の文書を、どう分割して、どう検索すべきか」の要件が明確になっており、IT外注の費用対効果が格段に上がる。
RAGの次の波：2028年に向けた技術シフト
現在のRAGは「1回だけ検索して回答する」シングルホップ型が主流だが、2026〜2028年にかけて設計パラダイムが変わりつつある。
Agentic RAGは、エージェントがループ内で「何を検索すべきか」「追加情報が必要か」を自律的に判断し、複数回の検索を組み合わせて回答を構成する。スタンフォード大学の研究では、3ステップ以上の多段階クエリで標準RAGの精度が38%なのに対し、GraphRAGでは67%まで向上する（出典: Stanford IR Lab, 2026年）。
MicrosoftがMITライセンスで公開したGraphRAGは、文書内のエンティティと関係をグラフ化し、複雑な質問に対して関連文書を関係性でたどりながら取得する。「A社とB社の契約条件を比較して」のような、複数文書にまたがるクエリに強い。この方向性が2028年には業界標準になっていると、VentureBeatを含む複数の調査機関が予測している（出典: venturebeat.com, 2026年）。
Lat91では、10体のAIエージェントチームを運用する中で、エージェント間の知識共有にRAG的な仕組みを採用している。各エージェントが蓄積した調査結果や判断ログを共通の知識ベースに書き出し、別のエージェントが参照する設計だ。最も苦労したのは「どの粒度でログを書き出すか」のチャンキング設計で、細かすぎれば意味が失われ、大きすぎれば検索ノイズが増える。この試行錯誤が、本記事の設計原則の背景にある。
よくある疑問に答える
「RAGよりファインチューニング（LLMへの追加学習）の方が良いのでは？」
この問いは正当だ。ファインチューニングは特定の文体や回答スタイルを学習させるのに向いている。一方で、社内データが更新されるたびに再学習が必要になり、コストと時間がかかる。RAGは「データを更新するだけで最新情報を反映できる」点で、変化の速い業務知識の管理に適している。使い分けの原則は「スタイルを変えたい→ファインチューニング、知識を与えたい→RAG」だ。
「社内データをクラウドに出したくない」
正当な懸念だ。対策は2つある。オンプレミスのオープンソースLLM（Llamaなど）とpgvectorを組み合わせたローカル構成か、Azure OpenAI ServiceやGCP Vertex AIのような「データが同一クラウドリージョンに閉じる」エンタープライズプランを使う選択肢だ。API型より初期コストは上がるが、機密性の要件が高い業種では現実的な選択肢になる。
まとめ
- RAGの失敗の本質は技術の難しさではなく、「文書を渡せば賢くなる」という設計前の誤解
- 初年度失敗の主因は3つ：機械的チャンキング・ベクトル検索のみへの依存・ドキュメント鮮度管理の欠如
- 成功する企業の共通点：意味単位のチャンキング・ハイブリッド検索・評価ファーストの設計
- 中小企業はNotebookLMやDifyで小さく始め、精度を確認してから本格構築へ
- 2028年に向けてAgentic RAGとGraphRAGが普及し、単純な文書検索から知識グラフ活用へと移行する
RAGは「導入して終わり」のシステムではない。文書の粒度設計、検索戦略の選択、鮮度管理の運用、そして評価の継続——この4つを設計に組み込んで初めて機能する。逆に言えば、この4つを押さえれば、大企業でなくても社内ナレッジをAIに活かせる仕組みは作れる。
Lat91では、AIエージェントの設計・導入から社内ナレッジ活用の仕組みづくりまで、一気通貫でサポートしています。
「RAGを試したいが何から手をつければいいかわからない」という方は、まずは無料相談からお気軽にどうぞ。