あなたのRAGはどこで精度を落としているか — 症状から原因を引く診断ガイド

「デモは動いたのに、本番でうまくいかない」。RAG（Retrieval-Augmented Generation＝検索拡張生成）の相談で、私たちが最も多く聞く言葉です。

社内文書をつないで最初の質問に答えが返った瞬間は、誰もが「いける」と思う。ところが実データを当てて現場が普段どおりの質問を投げ始めると、正答率は40〜60%台で頭打ちになり、「自分で探したほうが早い」と言われて、半年後には誰も開かなくなる。

この記事は、その状態を症状から診断するためのガイドです。私たちは商社の週次レポート検索、エネルギーインフラの法令ナレッジ、広告営業の見積など、複数のRAG/AI案件を本番まで持っていきました。そこで繰り返し確かめたのは、本番で精度が落ちる原因は、たいていモデルではなく、その手前の設計のどこかにあるということです。だから「もっと賢いモデルを待つ」より、症状を手がかりに穴の空いている層を特定するほうが、ずっと速く効きます。

なお、この記事はRAGの精度に絞ります。RAGに限らず「PoCは動いたのに本番に進まない」ときの原因と進め方は、AIのPoC止まりはなぜ起きるのかにまとめました。

先に地図を渡します。RAGの精度は4つの層——データ・検索・評価・運用——のどこでも漏れます。まず、あなたのRAGがいま出している症状から、疑うべき層を引いてください。

症状から、疑うべき層を引く

この表は「当たりをつける」ためのものです。ひとつの症状に原因が複数またがることもありますが、まずは一番上に来る層から手を入れると、たいてい一番大きく動きます。以下、層ごとに「なぜ漏れるか」と「どこで直すか」を順に見ていきます。

4層のどこで精度は漏れるか

第1層 データ設計 — 前処理を雑にやると、上の層で取り返せない。 精度の土台はデータです。地味で誰も評価してくれない作業ですが、ここが雑だと上のどの層で頑張っても取り返せません。文書を機械的に文字数で区切ると、答えの半分だけが入ったチャンクや文脈を失った断片が生まれ、検索でそれを拾ってもLLMは答えようがない。だから文書の種類ごとに切り方を変え、表を崩さず、メタデータを付け、古い版や廃止規程を整理する。精度はモデルより前処理で決まる——これはこのクラスタ全体で私たちが最も強く言いたいことで、詳しくは文書構造に沿ったチャンク設計にまとめました。

第2層 検索設計 — ベクトル検索だけでは固有名詞を取りこぼす。 本番で最も大きく精度を落とし、かつ改善インパクトが一番大きい層です。ベクトル検索は意味の近さに強い一方、固有名詞・型番・条文番号のように一文字違えば別物になる情報を平気で取りこぼす。「A社」と「B社」は意味的に近いので、A社を聞いたのにB社の資料が上位に来る。ここで効くのが、意味の曖昧さはLLM側（ベクトル）に、厳密な一致はルール側（キーワード＝BM25）に役割を分け、リランキングで束ねるハイブリッド検索です。ベクトル1本の限界は現場の経験則にとどまらず、埋め込みの次元が「上位に返せる文書の組み合わせ」を理論上縛ることも示されています（Weller et al., 2025）。設計の詳細はハイブリッド検索の設計に書きました。

第3層 評価設計 — 「なんとなく良くなった」を捨てる。 どこを直せば効くのかを、感覚で当てにいってはいけません。PoCが止まる現場には、ほぼ例外なく評価セットがない。何問中何問が正解で、どの種類の質問で外しているかを誰も数字で言えない。だからコードより先に、評価セットという物差しを作る。商社案件では49問、法令案件では4軸20点満点の評価を先に用意しました。作り方は評価セットの作り方にまとめています。

第4層 運用設計 — 納品した日が、精度のピークでは困る。 文書は更新され、規程は廃止され、組織が変われば呼び名も変わる。何もしなければAIは更新前の世界を見続け、廃止されたルールを根拠に堂々と誤答する。更新フロー・品質監視・評価セットによる定点観測を納品物に含める。第3層で作った計器盤が、ここで生き続けます。見落とされやすいのが部品の入れ替えです。埋め込みモデルや文書の切り方を替えると類似度スコアの出方が変わるので、「このスコアより低ければ答えない」という足切りの値も、評価セットで引き直します。旧モデルの値のまま据え置くと、関係のない質問にまで答えや案内が出るようになります。

4層をひとつの現場で積み上げた具体は、商社の文書検索で正答率を38.8%→93.6%にした4層設計に、数字とともに書いています。

「系統」で、次の一手を決める

層で原因の見当がついたら、次はいまのRAGがどの系統（世代）にいるかで打ち手を選びます。RAGの検索は、素朴なものから段階的に育ちます（この整理はNaive→Advanced→Modularというサーベイの体系におおむね対応します——Gao et al. 2023）。

大事なのは、上の系統ほど偉い、ではないことです。ただし、業務文書の出発点はハイブリッド検索です。固有名詞・型番・条文番号の多い文書でベクトル1本から始める理由は薄いので、キーワード検索とベクトル検索を並走させ、リランキングで並べ直す形を最初に組みます。

その先のGraphとAgenticは、症状が出てから足します。Graphが効くのは、複数の文書の関係をたどって初めて答えが揃う問いです。公開の比較評価でも、多段の推論や文書群全体の要約ではGraph RAGが勝つ一方、単純な事実を引く問いでは通常のRAGが同等以上でした（Xiang et al., ICLR 2026）。参照構造の無い文書にGraphを足しても、複雑さが増えるだけです。法令や規程のように条文が準用でつながる文書は、Graphが効く典型です（法令RAGをGraph拡張で解いた事例）。

Agentic RAG（検索をやり直したり、問いを分けて引き直したりする作り）は、商談の前・最中・後のように手順が分岐する業務で効きます（「使われる」営業AIの設計）。ただし、どこで止めるかを決めておかないと、いつまでも探し続けます。Anthropicは、調べものをするエージェントの評価（BrowseComp）で、性能差の8割が使ったトークンの量で説明できたと報告しています（Anthropic, 2025）。どれだけ探させるかが、そのまま品質と費用を決めるということです。呼び出し回数の上限・予算・「根拠が足りたか」の判定の3つで止まる作りにして、どれで止まったかを記録に残します。

系統を上げても解けない問い

件数・合計・一覧を聞く問いは、系統を上げても解けません。検索は上位の数件を返す仕組みなので、「先月の案件は全部で何件か」には形が合わず、もっともらしい数字で外します。こうした問いは文書検索に入れず、セマンティックレイヤー（指標と集計の定義を持ち、指標と条件を受け取って集計を返す層）に回し、LLMには「どの指標を・どの条件で」を選ばせるだけにします。dbt Labsが2026年4月に公表した比較（1社の実測・11問×20回）では、同じモデル（Claude Sonnet 4.6）で、LLMにSQLを書かせた場合の正答率が90.0%、セマンティックレイヤーを通した場合は98.2%でした（dbt Labs, 2026）。

逆に、数十〜数百件で変わらない手続きの一覧やFAQは、検索せずに全件をプロンプトに載せるほうが取り違えが起きません。ただ、文脈は長いほど読み落としが増えることも確かめられているので（Chroma, 2025）、全件を載せるのは短く固定の知識に限ります。

過剰でも過少でもない系統を選び、系統に乗らない問いは別の経路へ回す。これが「次の一手」の決め方です。

迷ったら、LLMを増やす前に「ルールで解けないか」を考える

改善の相談でいちばん多い誤解が、「精度が出ないのは、もっと強いLLMを使えば解決する」というものです。すでに書いたとおり主因はモデルの手前にあり、そのうえで私たちが繰り返し確かめてきたのは——決定的に解ける処理は、LLMよりルールベースのほうが良い、ということです。

固有名詞の一致、記号や略称の正規化、値付けの条件——こうした「答えが一意に決まる」処理をLLMに投げると、出力がぶれ、コストがかかり、なぜその結果になったのかを追いにくくなる。同じことをルールで書けば、測定しやすく、ブレず、安く、保守しやすい。実際、広告営業の見積エージェントでは、ベテランの頭の中にあった値付けの勘所をルールとして明文化し、LLMは自由文の依頼を型に落とす所に絞りました。LLMの出番は、意味の曖昧さを吸収する所や、自由文を構造化する所に限る。決定的に解ける所はルールに寄せ、LLMは曖昧さの担当に回す——この非対称が、本番で安定するRAGの地味な核心です（線引きの詳細はハイブリッド検索の設計）。

LLMに任せる所でも、書かせるより選ばせます。手続き・FAQ・規程の該当箇所のように答えの候補を一覧にできる業務では、私たちは3段で組みます。検索で根拠の候補を集め、LLMには「どの候補が答えか」を番号で選ばせ、回答文は選ばれた原文からプログラムで組み立てる。LLMは選ぶだけで、作らない。選択肢の外を返せないように、出力の形を候補の一覧で縛っておきます。

この考え方は、2025〜2026年に公開された実測とも向きがそろっています。前節のセマンティックレイヤーでは、LLMは指標と条件を選ぶだけで、定義に無い問いには誤った数字でなくエラーが返ります（dbt Labs, 2026）。LLMのAPIには、出力をJSONスキーマどおりの形に縛る構造化出力の機能が揃いました（Claudeは2026年1月に正式提供。Anthropic）。根拠が足りない文脈を渡すとモデルは断らずに誤答しやすくなり、「この根拠で答えられるか」を先に判定してから答えると精度が上がることも報告されています（Joren et al., ICLR 2025）。経費監査で、条件を書き切れる判断はルールで確定し、LLMには文脈が要る候補の仕分けだけを任せた例は経理AIの事例に書きました。

精度は「保つ」まで設計する — 人間監査から、やがて自動のループへ

最後に、多くのプロジェクトが設計しないまま終わる部分です。精度は上げて終わりではなく、保つところまでが設計です。ここで私たちが描く道筋は、3段階あります。

道筋は3段階です。まず人がAIの回答をチェックする人間監査（human-in-the-loop）を挟み、次に評価セットの数字で「監査が求める品質を安定して満たす」ことを実証し、そのうえで監査を外して評価とフィードバックのループを自動で回す——つまり監査を「卒業」していきます。

いきなり全自動を目指せば、品質を担保できているか誰も言えないまま暴走します。逆に人手監査を続ければ、そのコストが運用の重石になる。評価という物差しを先に持ち、人間監査で品質を実証してから卒業する——この順番だけが「作って終わり」を避けます。自動のループで採点にLLMを使うなら、その採点役も人の判定と突き合わせて癖を測ってから任せます。段階の踏み方と「卒業」の判断基準は評価セットの作り方に詳しく書きました。

RAG精度 診断チェックリスト（保存版）

いま手元のRAGが本番で精度を落としているなら、上から順に点検してください。

• データ設計 — 文字数で機械的に切っていないか。表・見出し・メタデータを保てているか。（→チャンク設計）
• 検索設計 — ベクトル検索だけになっていないか。固有名詞をキーワード（BM25）で押さえているか。（→ハイブリッド検索）
• 評価設計 — 評価セットはあるか。どの種類の質問で外しているかを「数値で」言えるか。（→評価セットの作り方）
• 運用設計 — 更新時にインデックスを入れ替えるフローと、精度の定点観測があるか。
• 足切りの値 — 埋め込みモデルや切り方を替えたとき、足切りの値を評価セットで引き直しているか。（→ハイブリッド検索）
• 系統の選択 — 症状と文書の性質に合った系統（素／ハイブリッド／Graph／Agentic）を、過剰でも過少でもなく選べているか。
• 問いの形 — 件数・合計・一覧を聞く問いを、文書検索に入れていないか。
• ルール優先 — 一意に決まる処理をLLMに任せていないか。ルールで固められる所を固めているか。
• 精度の維持 — 人間監査を挟み、卒業の判断を評価の数字で下せる設計になっているか。

症状を聞かせてください

もし、いま手元のRAGが本番で精度を落としていて原因が掴めないなら、症状を聞かせてください。「社名で聞いたのに別の取引先が出る」「準用先が抜ける」「数ヶ月で劣化した」——症状が分かれば、4層のどこに穴が空いていそうか、当たりはつけられます。RAG精度設計のサービスの形はAI/RAG精度設計サービスのページにまとめています。

参考文献

• Lewis et al. (2020) Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS — arXiv:2005.11401
• Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997
• Cormack, Clarke & Büttcher (2009) Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods, SIGIR — PDF
• Es et al. (2023) RAGAS: Automated Evaluation of Retrieval Augmented Generation — arXiv:2309.15217
• Zheng et al. (2023) Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — arXiv:2306.05685
• Weller et al. (2025) On the Theoretical Limitations of Embedding-Based Retrieval, ICLR 2026 — arXiv:2508.21038
• Xiang et al. (2025) When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation, ICLR 2026 — arXiv:2506.05690
• Joren et al. (2024) Sufficient Context: A New Lens on Retrieval Augmented Generation Systems, ICLR 2025 — arXiv:2411.06037
• Anthropic (2025) How we built our multi-agent research system — anthropic.com
• dbt Labs (2026) Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update — docs.getdbt.com
• Chroma (2025) Context Rot: How Increasing Input Tokens Impacts LLM Performance — trychroma.com