「PoCでRAG（検索拡張生成）を導入してみたけれど、思ったような回答が得られない」「もっと賢いLLMモデルに変えるべきだろうか？」
実務の現場では、企業のDX担当者やプロジェクトマネージャーがこのような課題に直面するケースが急増しています。社内ドキュメントを検索して回答するチャットボットを作ったものの、ユーザーからは「求めている情報が出てこない」「嘘をつく」といった厳しいフィードバックを受け、プロジェクトが停滞してしまうケースです。
実は、RAGの精度が出ない原因の8割は、生成AI（LLM）の頭の良さではなく、「検索（Retrieval）」の精度にあります。LLMにいかに優れた頭脳があっても、判断材料となる「社内ドキュメントの該当箇所」を正しく見つけ出せなければ、正しい回答は生成できません。
では、どうすれば検索精度を上げられるのでしょうか？ 多くの技術記事では「ベクトル検索（セマンティック検索）への全面移行」が推奨されていますが、実務を預かるPMの視点からすると、いきなりシステムを刷新するのはリスクが高すぎます。特に、社内特有の専門用語や型番検索においては、従来のキーワード検索の方が優れている場合も多いからです。
そこで今回は、既存のシステムを壊さずに、セマンティック検索を段階的に組み込んで精度を高めていくための確実なロードマップを解説します。技術的な深掘りよりも、プロジェクトをどう進めれば失敗しないかという、プロセスと品質管理の観点から体系的に整理します。
なぜRAGの回答精度は「検索」で決まるのか
なぜRAG（Retrieval-Augmented Generation）において、これほどまでに「検索」が重要とされるのでしょうか。その構造的な理由を整理します。ここを理解していないと、いかに高価で高性能なLLMを導入しても、コストばかりかかって成果が出ないという落とし穴にハマってしまいます。
OpenAIの公式情報（2026年1月時点）によると、GPT-4oなどの旧モデルが2026年2月に廃止され、より長い文脈理解や高度な推論能力を備えたGPT-5.2（InstantおよびThinking）への移行が進んでいます。このようにLLMの汎用知能や文章作成能力は日々進化していますが、システムに組み込む際、根本的な「検索」の精度が低ければ、最新モデルの真価を発揮することはできません。
LLMが賢くても「コンテキスト」が間違っていれば無意味
RAGの仕組みを料理に例えて説明します。
- LLM（生成AI）：超一流のシェフ
- 検索システム（Retriever）：食材を調達するバイヤー
- 社内データベース：市場（食材の倉庫）
- ユーザーの質問：オーダー（注文）
もし、お客様が「最高級のステーキ」を注文したのに、バイヤーが「腐った魚」や「ただの石ころ」をシェフに渡したらどうなるでしょうか。いくらシェフが一流でも、美味しいステーキを作ることは不可能です。せいぜい「これは魚ですが、ステーキのように調理してみました」と誤魔化すか、「食材がないので作れません」と断るしかありません。
これがRAGにおける「Garbage In, Garbage Out（ゴミを入れたらゴミが出る）」の原則です。LLMは渡された情報（コンテキスト）に基づいて回答を生成します。検索システムがユーザーの質問に関連性の低いドキュメントを抽出してしまった場合、LLMはそれを使って回答を作ろうとするため、結果として「もっともらしい嘘（ハルシネーション）」や「的外れな回答」が生成されてしまいます。どれほど最新のAIモデルを採用していても、入力されるデータが不適切であれば、出力の品質は担保できません。
キーワード一致の限界：表記揺れと文脈の無視
多くのシステム開発において最初に導入されるRAGは、既存の全文検索エンジンを利用した「キーワード検索」ベースのものです。これは、「質問文に含まれる単語」と「ドキュメントに含まれる単語」が一致するかどうかを判定基準としています。
しかし、自然言語による質問には「表記揺れ」や「同義語」がつきものです。
- ユーザーの質問：「PCの調子が悪い時の申請フローは？」
- ドキュメントの記述：「端末故障時の交換手続きについて」
人間であればこれらが同じ意味だと直感的に理解できます。しかし、単純なキーワード検索では「PC」と「端末」、「調子が悪い」と「故障」、「申請」と「手続き」の文字列が一致しないため、この重要なドキュメントが検索結果から漏れてしまう可能性が高いのです。
その結果、LLMには「関連情報なし」と判断され、「分かりません」と回答されるか、あるいは単語だけが一致した全く関係のない「PC購入申請」のマニュアルが参照されてしまいます。ユーザーが求める回答を得られない原因は、LLMの理解力ではなく、検索手法の限界にあります。
セマンティック検索がもたらす「意味」の理解とは
この課題を解決するアプローチが「セマンティック検索（ベクトル検索）」です。これは、文章を「意味を持つ数値の羅列（ベクトル）」に変換し、意味の近さを計算して検索する技術です。
先ほどの例で言えば、「PCの調子が悪い」という概念と「端末故障」という概念は、ベクトル空間上で非常に近い位置に配置されます。そのため、単語が全く一致していなくても、意味的に近いドキュメントを的確に見つけ出すことができます。
「それなら、すぐにすべてのシステムをベクトル検索に置き換えればいいのではないか」と思われるかもしれません。しかし、システム設計において注意すべき重要なポイントがあります。ベクトル検索は「意味」の理解には強い一方で、「完全一致」や「型番」「固有名詞」の検索には弱いという特性を持っています。例えば、「A-100」という製品と「A-200」という製品の違いを、文脈の類似性だけで区別するのは困難なケースが珍しくありません。
だからこそ、プロジェクトマネジメントの観点からは、ベクトル検索の強みとキーワード検索の強みを組み合わせた「ハイブリッド検索」への段階的な移行が推奨されます。それぞれの特性を補完し合うことで、より高精度で安定したRAGシステムを構築することが可能になります。
導入ロードマップ全体像：リスクを抑えた段階的アプローチ
RAGの精度向上プロジェクトは、一足飛びに完了するものではありません。システムへの影響、コスト、そしてユーザーの期待値管理を含めた、着実なステップが必要です。
いきなり全面移行しないためのフェーズ分け
実務の現場においてAI駆動型のプロジェクトを推進する際は、以下のような4段階のロードマップで進めることが効果的です。
- フェーズ1：データ構造の理解とベクトル化の準備
- 現状のデータの整理と、AIが読みやすい形への加工方針を決定します。
- フェーズ2：小規模PoCによるハイブリッド検索の検証
- 特定部署や特定業務に範囲を絞り、キーワード検索とベクトル検索を組み合わせた効果を測定します。
- フェーズ3：リランキング導入とコンテキスト注入の最適化
- 検索結果の順位をAIで再評価（リランク）し、LLMに渡す情報の質を極限まで高めます。
- フェーズ4：継続的な評価とフィードバックループの構築
- 運用開始後の精度劣化を防ぎ、日々改善していくための仕組みを作ります。
各フェーズにおけるゴールと判定基準
プロジェクト管理において重要なのは、「何をもって次のフェーズに進むか」という判定基準（Exit Criteria）です。
- フェーズ1完了基準：対象ドキュメントの80%以上が適切にチャンク化（分割）され、ベクトルデータベースに格納できる状態になっていること。
- フェーズ2完了基準：選定したテスト質問セット（ゴールデンデータセット）において、ハイブリッド検索がキーワード検索単体よりも高い正答率（Recall）を出すこと。
- フェーズ3完了基準：LLMへの入力トークン数を削減しつつ、回答精度（Precision）が向上し、応答速度が許容範囲内に収まっていること。
必要なリソースと体制の確認
このプロジェクトには、エンジニアだけでなく、「業務知識を持ったドメインエキスパート」の協力が不可欠です。検索結果が「正しいかどうか」を判断できるのは、AIではなく現場の担当者だからです。PMとしては、開発チームと現場担当者を橋渡しし、評価に協力してもらう体制を作ることが最初の仕事になります。
フェーズ1：データ構造の理解とベクトル化の準備
セマンティック検索の精度を左右するのは、事前のデータ準備工程です。まずは「食材の下ごしらえ」とも言えるデータの構造化とベクトル化の準備について解説します。ここでの設計が不十分だと、どれほど高性能なベクトル検索エンジンを導入しても期待する精度は得られません。
社内ドキュメントの「チャンク化」戦略
RAGにおいて地味ながら極めて重要なのが「チャンキング（Chunking）」です。LLMには一度に処理できる入力文字数（トークン数）の上限が存在します。そのため、長大なマニュアルや規定集を適切なサイズの「塊（チャンク）」に分割してベクトルデータベースに保存しなければなりません。
よく見られる失敗は、「一律500文字で機械的に区切る」といったアプローチです。この方法では、文章の途中で文脈が分断されるリスクが高まります。
- 悪い例：...申請を行う場合は、（ここで切れる）
（次のチャンク）上長の承認が必要です。
これでは、後半のチャンクだけが検索にヒットしても、「何に対する上長承認が必要なのか」をAIが判断できません。
プロジェクトマネジメントのポイント：
技術チームに対し、「意味のまとまり（セマンティック・チャンキング）」を意識した分割戦略を設計するよう指示してください。具体的には、見出し（H2, H3タグ）単位や段落単位での分割を基本とし、さらに前後の文脈を適度に重複させる（オーバーラップ）手法が効果的です。
非構造化データ（PDF、画像）の取り扱い方針
社内に蓄積されたデータの多くは、PDFやPowerPoint、あるいは画像化されたスキャンデータとして存在しています。これらを単純にテキスト抽出しようとすると、レイアウトが崩壊して意味不明な文字列の羅列になるケースが後を絶ちません。
特に表組（テーブル）は非常に厄介です。レイアウトが崩れてテキスト化されると、「価格」と「商品名」などの対応関係が完全に失われてしまいます。
この課題に対し、AI-OCR技術は大きく進化しています。例えば、Biz-AI×OCRのように複雑なレイアウトや印字ズレに対応したツールや、AIReadのようにETL機能（データの抽出・加工・ロード）を強化してCSV出力などの構造化を支援するツールが登場しており、以前と比べてデータ化のハードルは着実に下がっています。
しかし、プロジェクトマネージャーとしては「精度の出にくいデータは、一旦対象外にする」という決断も重要です。最新ツールであっても、最適な設定やチューニングには相応の工数が発生します。「まずはテキストベースのQ&A集とマニュアルのみを対象にする」と初期スコープを絞り込み、段階的にAI-OCRの適用範囲を広げていくアプローチが、プロジェクトの確実な進行に繋がります。
エンベディングモデル選定の基礎知識
テキストをベクトルに変換する「エンベディングモデル」の選定も、検索精度を決定づける重要な要素です。OpenAI APIなどで提供されるエンベディングモデルは手軽で高性能ですが、社内規定によって外部APIへの機密データ送信が制限されているケースは珍しくありません。
その場合、Hugging Faceなどで公開されているオープンソースモデルを自社サーバー環境で稼働させるアプローチが有力な選択肢となります。このローカル環境でのAI運用基盤は現在大きな転換期を迎えており、基幹ライブラリであるTransformersの最新メジャーアップデート（v5）により、自社運用に向けた技術要件が変化しています。
- フレームワークの移行要件：PyTorchを主要フレームワークとする方針にシフトし、TensorFlowやFlaxのサポートは終了しました。もし既存の社内システムがTensorFlowベースで構築されている場合は、PyTorchベースへの移行計画を技術チームと策定する必要があります。
- 推論環境の構築容易化：新たに「transformers serve」というOpenAI互換APIが導入され、オープンソースモデルを自社サーバーでAPIとして提供する開発ハードルが大幅に下がりました。
- ローカル推論の強化：ggml.aiの合流により、GGUFフォーマットが標準化され、限られたハードウェアリソースでも効率的にモデルを稼働させる基盤が整いつつあります。
モデルを選定する際は、これらの最新アーキテクチャに対応しているかを確認するとともに、「日本語対応能力」を厳しく評価してください。英語圏で高性能なモデルであっても、日本語特有のニュアンスを正確に捉えられない場合があります。必ず日本語での評価スコア（JMTEBなど）が高いモデルや、日本語データで十分な追加学習が行われたモデルを候補に挙げるよう、技術担当者と目線を合わせておくことが重要です。
フェーズ2：小規模PoCによるハイブリッド検索の検証
データの準備ができたら、いきなり本番環境を変えるのではなく、小規模なPoC（概念実証）で効果を検証します。ここで狙うのは、キーワード検索とベクトル検索の「いいとこ取り」です。
キーワード検索 × ベクトル検索の組み合わせ効果
推奨されるハイブリッド検索とは、同じ質問に対して「キーワード検索」と「ベクトル検索」の両方を実行し、その結果を統合する手法です。
- キーワード検索：製品型番「X-2000」、エラーコード「E04」、固有名詞「鈴木部長」などに強い。
- ベクトル検索：「PCが動かない」「画面が真っ暗」といった抽象的な表現や概念に強い。
これらを組み合わせることで、ユーザーがどんな聞き方をしても、網羅的にドキュメントを拾い上げることができます。技術的にはReciprocal Rank Fusion (RRF) というアルゴリズムを使って、双方の検索順位を公平に評価し、統合ランキングを作成します。
PMとしては、「キーワード検索だけでは拾えなかったドキュメントが、ベクトル検索によって拾えるようになったか？」を確認することが重要です。
特定の業務ドメインに絞ったテスト実施
全社のドキュメントを対象にすると評価が難しくなります。まずは「経費精算」や「セキュリティ規定」など、正解が明確で、かつ利用頻度の高いドメインに絞ってテストを行いましょう。
この際、現場の担当者に「よくある質問トップ50」を作ってもらい、それをテストケース（評価用データセット）として利用します。実際のユーザーが使う言葉（「交通費」なのか「旅費」なのか、「精算」なのか「請求」なのか）を含んだ質問を用意することがポイントです。
「正解」が見つかるかどうかの定性評価
このフェーズでの評価指標は、Recall（再現率）です。「検索結果の上位10件の中に、正解となるドキュメントが含まれているか？」をチェックします。
もし含まれていなければ、チャンクサイズを見直すか、エンベディングモデルを変更する必要があります。逆に、正解が含まれているのにLLMが間違った回答をする場合は、次のフェーズで行う「リランキング」やプロンプト調整の出番となります。
「まずは正解のドキュメントを拾ってくること」。これがフェーズ2の絶対的なゴールです。
フェーズ3：リランキング導入とコンテキスト注入の最適化
検索で「正解候補」を広く集めたら、次はそれをLLMに渡すために「厳選」する工程です。ここで回答の精度（Precision）を一気に高めます。
検索結果をLLMに渡す前の「再順位付け（Rerank）」
ハイブリッド検索で集めた上位20〜50件のドキュメントを、そのまま全てLLMに渡すとどうなるでしょうか？ 情報量が多すぎてLLMが混乱したり（Lost in the Middle現象）、API利用料が跳ね上がったりします。
そこで導入するのが「リランカー（Re-ranker）」です。これは、質問とドキュメントのペアを見て、「本当にこのドキュメントは質問の答えになっているか？」を厳密に採点するAIモデル（Cross-Encoderなど）です。
リランカーは処理が重いため全件検索には使えませんが、検索で見つけた数十件を並び替えるだけなら高速に動作します。この「検索（広範囲）→ リランク（精査）」の2段構え構成（Two-Stage Retrieval）にすることで、検索精度は劇的に向上します。
プロンプトに含めるコンテキスト長の調整
リランクによって上位に浮上した「本当に信頼できるドキュメント」の上位3〜5件だけを、LLMへのプロンプト（命令文）に含めます。
ここでPMが意識すべきは「情報の鮮度とノイズ」です。古い規定や、関係のない補足情報が含まれていると、LLMはそれを真実として扱ってしまいます。メタデータ（作成日、更新日）を活用し、古い情報を自動的に除外するフィルター機能を実装要件に盛り込むことをお勧めします。
ノイズ情報の除去と回答精度の相関
「情報は多い方がいいだろう」と思いがちですが、RAGにおいては「無関係な情報は毒」になります。関連性の低いドキュメントをコンテキストに含めると、LLMが無理やり関連付けようとしてハルシネーションを起こす確率が上がることが研究で分かっています。
リランカーのスコアがある閾値（例えば0.7）以下のドキュメントは、たとえ検索結果に出てきてもLLMには渡さない、という「足切りライン」を設定することが、回答の品質安定化につながります。
フェーズ4：継続的な評価とフィードバックループの構築
システムが稼働しても、プロジェクトは終わりではありません。むしろ、ここからが本番です。ドキュメントは日々更新され、新しい用語も生まれてくるからです。
ユーザーからのフィードバック収集メカニズム
回答の下に「👍（役に立った）」「👎（役に立たなかった）」ボタンを設置するのは必須要件です。しかし、それだけでは不十分です。「なぜ役に立たなかったのか？」の理由（情報が古い、答えになっていない、リンク切れなど）を選択式でフィードバックできるようにしましょう。
PMとしては、このフィードバック率をKPIの一つに設定し、ユーザーがフィードバックしやすいUI/UXを設計することが求められます。
回答精度が落ちた際の原因切り分けフロー
「回答がおかしい」という報告が上がった際、どこに原因があるかを即座に特定できるフローを準備しておきます。
- 検索の問題か？：正解ドキュメントが検索結果（リランク前）に含まれていたか？
- リランクの問題か？：正解ドキュメントがリランク後に上位に来ていたか？
- 生成の問題か？：正しいドキュメントを渡したのに、LLMが読み間違えたか？
- 元のドキュメントの問題か？：そもそもドキュメントに書いてあることが間違っていたか？
この切り分けをスムーズに行うために、RagasやLangSmithといったLLMアプリケーション評価・監視ツールの導入も検討に値します。これらは検索精度（Retrieval）と生成精度（Generation）を個別にスコアリングしてくれるため、改善ポイントが明確になります。
定期的なインデックス更新とメンテナンス
社内ドキュメントが更新されたら、ベクトルデータベースのインデックスも更新しなければなりません。ここが手動運用だと必ず破綻します。
ドキュメント管理システムへのアップロードをトリガーにして、自動的にチャンク化・ベクトル化・インデックス登録が行われるデータパイプライン（ETL処理）の構築を、初期段階から計画に組み込んでおきましょう。「死後硬直」した（情報の古い）RAGシステムほど、ユーザーの信頼を損なうものはありません。
結論：技術よりも「プロセス」がRAGの成功を決める
RAGの精度向上に、魔法の杖はありません。しかし、正しい手順を踏めば、確実に精度は上がります。
重要なのは、「キーワード検索」という既存の資産を活かしつつ、「ベクトル検索」という新しい武器を適材適所で組み込む（ハイブリッドにする）こと。そして、検索結果を「リランク」で磨き上げ、LLMに渡す情報の純度を高めることです。
プロジェクトマネージャーの役割は、最新のAIモデルを追いかけることではなく、この「データが回答になるまでのバケツリレー」のどこに穴が開いているかを見極め、一つずつ塞いでいくプロセスを管理することです。
まずは、特定の部署や業務に絞ったスモールスタートから始めることが推奨されます。現場の「検索できない痛み」を解決できたとき、RAGは単なる技術トレンドを超えて、真にビジネスに貢献するインフラとなるはずです。
自社と似た業界での導入事例や、具体的なハイブリッド検索の設計パターンを学ぶことは非常に有益です。他社の試行錯誤の歴史を参考にすることは、プロジェクトのリスクを減らし、ROIを最大化するための強力な武器になります。
コメント