※本記事は2026年6月時点の技術一次情報（Anthropic「Introducing Contextual Retrieval」等の公式ドキュメント・公開資料）と、当社の社内文書RAG（検索拡張生成）の構築・チューニング実務にもとづく内容です。守秘案件は業界・規模・概要のみに匿名化し、実名・実数は出していません。数値は実装・データにより幅があり、断定ではなく目安です。

「RAGを社内文書で組んでみたが、的外れな回答が返ってくる」「それっぽい答えは出るが、肝心の規程や数値を間違える」——社内向けに生成AI（RAG）を導入した情報システム・DX推進の現場から、いま最も多く寄せられる相談です。

先に結論をお伝えします。RAGの精度が上がらない原因の多くは「生成（LLM）」ではなく「検索（Retrieval）」にあります。 答えの素材を間違って渡していれば、どれだけ賢いモデルを使っても正しく答えられません。つまりRAGの精度向上とは、「AIを賢くする」ことではなく「AIに渡す情報を賢く選ぶ」ことです。そして、その打ち手には効く順番があります。

本記事では、検索精度と回答品質を改善する打ち手を、当社が社内文書RAGの実装で実際に踏んでいる順番（チャンク設計→メタデータ→ハイブリッド検索→再ランク→評価）で解説します。机上の手法カタログではなく、社内文書ならではのハマりどころと、当社の匿名チューニング事例まで公開します。

この記事の結論（30秒サマリ）
– RAGの精度トラブルの7〜8割は「検索」で起きる。投資は検索フェーズに集中させる。
– 打ち手には順番がある：①チャンク設計 → ②メタデータ → ③ハイブリッド検索 → ④再ランク。上流から直す。
– 何より「評価」を最初に作る（評価データセット＋Recall@K＋LLM採点）。測れない改善は回らない。
– 社内文書の三大ハマりどころは固有名詞・表/PDF・版数。手法より先にここを疑う。

この記事の監修：大槻 伸夫（キュリオシティ株式会社 代表取締役CEO）。”現場主義 × AI”を掲げ、製造・商社・決済など複数業界で、社内文書を根拠に答える生成AI（RAG）の構築から精度チューニング・本番化までを一貫して伴走支援。現場の文書・業務を起点に、評価で回し続ける改善設計を統括。

結論｜RAGの精度は「検索の質」で8割決まる

RAGは大きく「検索（質問に関係する文書を探す）」と「生成（探した文書を根拠にLLMが答える）」の2段で動きます。精度トラブルのほとんどは前段の検索で起きています。

なぜなら、検索が答えの根拠となる文章を取ってこられなければ、後段のLLMは「手元にない情報」を埋めようとして、もっともらしい誤り（ハルシネーション）を返すからです。逆に、根拠が正しく渡っていれば、現在のLLMは高い確率で正答します。だからこそ、精度改善の投資は検索フェーズに集中させるのが鉄則です。

その検索を直す打ち手は、おおむね次の順番で効きます。土台となる4つ——①チャンク設計 → ②メタデータ → ③ハイブリッド検索 → ④再ランク——を上流から積み上げ、それらを「評価」で回し続けるのが基本形です（必要に応じて⑤コンテキスト付与・⑥クエリ整備・⑦生成側の打ち手を重ねます。詳細は後述）。上流（チャンク）を放置したまま下流（再ランク）だけ足しても効果は限定的です。土台から順に直すのが最短ルートです。

なお、RAGそのものの構築手順や社内データの準備はRAG構築の進め方で、社内データ活用の全体像は社内向け生成AIの構築方法で整理しています。本記事は「組んだ後に精度をどう上げるか」に絞ります。

なぜRAGの精度は上がらないのか｜原因を「検索」と「生成」に切り分ける

改善の前に、まずどこで失敗しているかを切り分けます。これをやらずに闇雲にプロンプトをいじっても、迷路に入るだけです。切り分けは単純で、誤答した質問について次を確認します。

• 検索の失敗：正解の根拠が、検索で取ってきた文書（コンテキスト）の中にそもそも入っていない。→ 検索フェーズの問題。
• 生成の失敗：根拠は渡っているのに、LLMが読み違える・無視する・盛る。→ プロンプトやモデルの問題。

当社の実装経験では、初期段階の誤答は7〜8割が検索の失敗に分類されます。そして検索失敗の典型は、次の3つに集約されます。

1. チャンクの切り方が悪く、答えが分断されている（定義と条件が別々のチャンクに割れる等）。
2. 固有名詞・型番・社内用語をベクトル検索が拾えない（意味の近さでは一致しない）。
3. 似た文書が大量にあり、正解が上位に浮かんでこない（版違い・部署違いの規程など）。

以下の打ち手は、この3つの失敗を上流から順につぶしていく構成になっています。

RAGの精度を向上させる7つの打ち手【打つ順番つき】

① チャンク設計を見直す（最優先・最も効く）

チャンクとは、文書を検索可能な単位に分割した断片です。ここが崩れていると、後段の埋め込みや高価な再ランクをいくら足しても精度は頭打ちになります。大きすぎるチャンクは複数トピックが混ざって「話題のごった煮」になり、小さすぎると定義や前提が欠落して断片だけでは意味が通らなくなります。

実務の指針はシンプルです。

• 意味のまとまり（見出し・段落・条項）で区切る。文字数で機械的に切らない。Anthropicの公式解説でも、チャンクは「数百トークン以下」を目安に、文脈を保つ前処理が推奨されています。
• 親子チャンク（小さく検索し、大きく渡す）：検索は小さい単位で精度を上げ、LLMに渡すときは前後を含む親チャンクを渡す。「ヒットはするが文脈が足りず誤答」を防ぐ定番。
• 表・PDF・図は素直に分割しない。表をテキストに流すと行と列の対応が壊れ、誤った数値を返す原因になります（後述の匿名事例B）。

② メタデータを付けて「絞ってから探す」

文書に部署・文書種別・有効日・版数・機密区分などのメタデータを付け、検索時に絞り込みます。これは精度とガバナンスの両方に効きます。

• 「2024年版を引いてほしいのに2019年版が出る」→ 有効日・版数でフィルタ。
• 「経理向けの規程に営業の規程が混ざる」→ 部署・文書種別でフィルタ。
• 閲覧権限を超えた文書を答えさせないアクセス制御にも直結します（権限分離の考え方は閉域網で生成AIを使う方法も参考に）。

メタデータは地味ですが、検索空間そのものを正解の周辺に狭めるため、費用対効果が非常に高い打ち手です。

③ ハイブリッド検索（ベクトル＋キーワード）にする

ベクトル検索（意味の近さ）だけだと、型番・品番・社内固有名詞・略語のような「表記が一致しないと意味がない語」を取りこぼします。そこで、キーワード検索（BM25）と組み合わせるハイブリッド検索が、いまや実務の標準です。

両者はスコアの尺度が違うため、順位を合成するRRF（Reciprocal Rank Fusion）で頑健に融合するのが定石です。「意味」はベクトルが、「正確な語の一致」はBM25が担当し、互いの弱点を補い合います。固有名詞が多い社内文書では、ここが最大の効きどころになることが少なくありません。

④ 再ランク（リランカー）で上位を入れ替える

ハイブリッド検索で候補を広めに（例：上位50〜150件）取り、それをクロスエンコーダ型のリランカーで質問との関連性を精査し、本当に効く上位（例：5〜20件）だけをLLMに渡します。初期検索は「漏れなく拾う（再現率）」担当、再ランクは「絞り込む（適合率）」担当、と役割を分けるのがコツです。

効果は数値でも裏づけられています。Anthropicが公開した技術解説「Introducing Contextual Retrieval」（2024年9月公開）では、後述のコンテキスト付与（⑤）とキーワード検索を組み合わせた構成にさらに再ランクを重ねると、ベースライン比で上位20チャンクの検索失敗率が67%低下（5.7%→1.9%）したと報告されています（＝再ランク単独ではなく、複数の打ち手を積み上げた合算効果です）。順番として、③ハイブリッド化で土台を作り、④再ランクで仕上げる流れが効率的です。

⑤ コンテキスト付与でチャンクの「文脈欠落」を補う

チャンクを細かくすると、「その断片が文書全体の中で何の話か」という文脈が失われがちです。これを補うのが、各チャンクの先頭にそのチャンクの位置づけ（どの文書・どの章・何についてか）を短く付与してから埋め込む手法です（Anthropic「Contextual Retrieval」）。

同検証で報告された、打ち手を積み上げたときの上位20チャンクの検索失敗率は次のとおりです。打ち手は単独で効くより、上流から重ねるほど効くことが読み取れます。

出典：Anthropic「Introducing Contextual Retrieval」（2024年9月公開。上位20チャンク取得時の失敗率。数値は同社の検証条件下のもので、再現性はデータ・実装に依存します。自社では必ず評価セットで実測してください）。①〜④を入れてもまだ取りこぼす場合の、強力な上積み策です。

⑥ クエリ（質問）を整える

ユーザーの質問は、検索に最適な形になっていないことが多いものです。質問の言い換え（クエリ変換）、複数の言い換えで検索するマルチクエリ、想定回答文を生成して検索に使うHyDEなどで、検索ヒット率を底上げします。社内文書では特に、社内用語⇔一般用語の同義語辞書を持つだけでも効果が大きいです（後述の匿名事例A）。

⑦ 生成プロンプトと「出典提示」を固める

最後に生成側です。「渡した文書だけを根拠に答える」「根拠がなければ”分かりません”と答える」「回答に出典（どの文書か）を併記する」をプロンプトと設計で徹底します。出典併記は、ユーザーが正誤を確認できるHuman-in-the-loop（HITL）の最小実装でもあり、誤答を業務事故にしないための安全弁になります。

一番大事なのは「評価」｜測れない改善は回らない

ここまでの打ち手以上に重要なのが、精度を“測る”仕組みです。評価がないと「変えた→たぶん良くなった」の感覚論になり、改善が一度きりで止まります。実際、当社が最初に手を入れる多くの現場で、評価データセットが用意されていないのが最大のボトルネックでした。

最低限、次を用意します。

• 評価データセット：実際に来そうな質問と「正解（根拠となる文書・理想の回答）」を、まず30〜100問でいいので作る。現場のFAQや問い合わせ履歴が宝の山です。
• 検索の指標：正解の根拠が上位に入ったかを測るRecall@K（再現率）・MRR・NDCG。検索フェーズの良し悪しはここで分かります。
• 回答の指標：回答が根拠に忠実か（Faithfulness）・質問に答えているか。人手評価に加え、LLM-as-a-Judge（別のLLMに採点させる）が自動評価の主流です。
• 回帰チェック：チューニングのたびに同じデータセットで測り、「Aを直したらBが悪化した」を検知する。RAGの改善は副作用が出やすいので、これが効きます。

評価を後回しにして打ち手を足し続けるのは、目隠しでダーツを投げるのと同じです。「測る→直す→また測る」のループを最初に作ること。これが、地味ですが精度向上の最短経路です。

現場のハマりどころ｜社内文書RAG特有の落とし穴（匿名事例）

公開情報の手法を実装に落とすと、社内文書ならではの壁にぶつかります。当社が実際に踏んだ落とし穴を匿名で共有します（業界・規模・概要のみ。実名・実数は出していません）。

• 匿名事例A：固有名詞を“意味”で探そうとして外す（製造・商社／社内規程・技術文書RAG）。 当初ベクトル検索のみで構築したところ、型番・品番・社内略語の問い合わせで的外れな文書ばかり返りました。原因は「表記の一致」が必要な語を意味検索で拾おうとしていたこと。BM25とのハイブリッド＋RRFに変え、さらに社内用語の同義語辞書を足したところ、固有名詞を含む質問で正解の根拠が上位5件に入る割合（Recall@5）は、おおよそ6割台から9割前後まで改善しました（自社の評価セットでの概数。守秘のため概算値）。打ち手の順番として、ここが最初に効きました。
• 匿名事例B：表・PDFを素直に切って数値を誤答。 仕様表や料金表をテキストに流し込んでチャンク化したら、行と列の対応が崩れ、別の行の数値を根拠に回答する事故が発生。表は表として保持し（セル構造を残す）、親子チャンクで前後文脈を渡す設計に変えて解消しました。
• 匿名事例C：評価を作らず2週間溶かす。 評価データセットを用意しないまま「プロンプト改善で良くなったはず」と進め、後から30問規模の評価セットで測ると、狙った質問は良くなった一方、別の質問群でRecall@5が数ポイント悪化していました（典型的な“もぐら叩き”）。先に評価セットを作っていれば防げた手戻りです。評価は最初に作る——これが最大の教訓でした。
• 匿名事例D：版違いの規程を引く。 改訂前の旧版を根拠に回答してしまう問題は、有効日・版数のメタデータ＋フィルタでほぼ解消しました。検索ロジックを高度化する前に、メタデータ整備が効いた典型例です。

いずれも、特別なモデルではなく「上流から順に、測りながら直す」という型で解けています。

内製と外注、費用の考え方

これらの打ち手の多くは内製でも着手できますが、評価設計・ハイブリッド検索／再ランクの実装・社内文書の前処理（表・PDF・権限）は、つまずきやすく時間を溶かしやすい領域です。「自社で1〜2か月試して頭打ちなら、検索フェーズだけ外部の知見を借りる」という切り分けが現実的です。

費用感は、まず小さくPoC（概念実証）で精度の見極めから入り、本番化はその後に投資する順番が総額を最も抑えます。PoCから本番の生成AI開発までの伴走の進め方は生成AI開発・PoC支援に、フェーズ別の内訳と見積もりの読み解き方は生成AI導入の費用相場で、進め方の全体像は生成AI導入支援とはで詳しく整理しています。

まとめ｜RAGの精度は「検索を上流から、測りながら」直す

RAGの精度向上の要点を、最後に1枚で整理します。

• 精度トラブルの多くは生成ではなく検索で起きる。投資は検索フェーズに集中。
• 打ち手には順番がある：①チャンク設計 → ②メタデータ → ③ハイブリッド検索 → ④再ランク → ⑤コンテキスト付与 → ⑥クエリ整備 → ⑦生成・出典提示。上流から直す。
• 何より評価（評価データセット＋Recall@K等＋LLM-as-a-Judge）を最初に作る。測れない改善は回らない。
• 社内文書では固有名詞（ハイブリッド検索）・表/PDF（チャンク設計）・版数（メタデータ）が三大ハマりどころ。

検索を上流から順に、評価で回しながら直す——この型を踏めば、RAGの精度は着実に上がります。

RAGの精度を「測りながら」上げたい方へ

当社では、社内文書RAGの精度チューニングを小さなPoCから評価設計込みで伴走しています。「どこから手を付ければいいか」を整理する第一歩として、生成AI PoCの企画テンプレートを無料配布しています。検証スコープ・KPI・撤退基準まで埋められる実務テンプレです。

▶ 生成AI PoC企画テンプレート（無料ダウンロード）（メールアドレスのご登録でダウンロードいただけます）

自社のRAGの精度や、評価のつくり方を個別に相談したい場合は、無料相談はこちらからお気軽にどうぞ。”現場主義 × AI”で、検索を上流から、評価で回しながら、精度を着実に引き上げます。