RAG（Retrieval-Augmented Generation）とは、外部ドキュメントをリアルタイムで検索し、その内容をLLMの回答生成に組み込む技術アーキテクチャです。

社内ナレッジ検索や顧客対応チャットボットへの応用が急速に広がる一方、「プロトタイプは動いたのに本番に出せない」という声は現場で繰り返されています。LangChainやLlamaIndexといったフレームワークの成熟で実装の敷居は下がりましたが、設計・実装・運用の各フェーズで踏んでしまう落とし穴の数も比例して増えています。

この記事が対象とするのは、以下のような読者です。

• RAGのPoC（概念実証）は完了したが、本番化で壁にぶつかっているエンジニア
• 検索精度やハルシネーションの問題を抱え、改善の糸口を探っているMLエンジニア・開発リード
• これからRAGを設計・導入しようとしており、事前に失敗パターンを把握しておきたいアーキテクト

記事を読み終えると、現場で繰り返される10の失敗パターンとその具体的な回避策が体系的に把握でき、設計レビューや実装チェックリストとして即日活用できる知識が得られます。

RAGは「LLMに最新・専門知識を持たせる」有力な手段として、本番導入を進める企業が急増しています。しかし、PoC段階では動いたシステムが本番環境で想定外の回答精度低下を起こすケースは後を絶ちません。

その背景には、RAG固有の複雑な処理パイプラインがあります。ドキュメント前処理・チャンク分割・埋め込み生成・ベクトル検索・プロンプト組み立て・LLM推論と、失敗が潜む箇所は多岐にわたります。

以降のH3では、失敗が起きやすい構造的な要因と、設計・実装・運用の各フェーズにおける落とし穴を順に掘り下げます。

RAG（Retrieval-Augmented Generation）は、LLMの「知識の鮮度問題」と「ハルシネーション問題」を同時に緩和するアーキテクチャとして広く採用されています。GPTやClaudeといったモデルは学習データのカットオフ以降の情報を持たないため、社内ドキュメントや最新の製品仕様を参照させたい場面では単体では機能しにくい状況があります。RAGはその欠点を補う有力な手段です。

しかし、構造的な難しさも伴います。RAGのパイプラインは主に次の要素で構成されます。

• ドキュメントの前処理：PDF・HTML・Markdownなど多様なフォーマットの正規化
• チャンク分割：テキストを検索可能な単位に分割するサイズ・境界の設計
• 埋め込み（Embedding）：テキストをベクトルに変換するモデルの選定
• ベクトルストア：インデックス構築と近似最近傍探索の設定
• 検索（Retrieval）：クエリに対して関連チャンクを取得するロジック
• 生成（Generation）：取得結果をプロンプトに組み込んでLLMが回答を生成

これらの要素は一つでも設計を誤ると、最終的な回答品質が連鎖的に低下するという脆弱性を持ちます。たとえばチャンク境界が文脈の途中で切れていると、埋め込みベクトルが意味を正しく表現できず、関連度の高いドキュメントが検索上位に来ないケースが報告されています。

さらに、Agentic RAGやマルチモーダル対応RAGなど応用形態が増えるにつれ、パイプラインの複雑度は高まる傾向があります。「動いているように見えて精度が低い」状態が長期間放置されやすい点が、RAG構築の本質的な難しさといえます。

RAGの失敗は「どこか一箇所が悪い」のではなく、設計・実装・運用の三つのフェーズにまたがって発生する点が厄介です。フェーズごとに問題の性質が異なるため、原因の特定が遅れるケースが少なくありません。

設計フェーズでは、要件定義の甘さが後工程に連鎖します。

• ユーザーのクエリ傾向を調査せずにチャンク戦略を決める
• 対象ドキュメントの言語・形式（PDF・HTML・社内Wikiなど）を整理しないまま着手する
• 評価指標を「後で考える」と先送りにする

これらは「最初は動くが精度が出ない」という典型的な症状につながります。RAGASやTruLensといった評価フレームワークの普及により、設計段階での指標設定が業界標準になりつつある点も見逃せません。

実装フェーズでは、技術選定のミスマッチが頻発します。

• 埋め込みモデルとLLMの言語対応が揃っていない（英語モデルで日本語ドキュメントを処理するなど）
• ベクトル検索のみに依存し、キーワードマッチが必要なクエリを取りこぼす
• 再ランキング処理を省略し、関連度の低いチャンクがそのままLLMに渡る

実装ミスは「動いているように見えて精度が低い」状態を生むため、発見が遅れやすい傾向があります。

運用フェーズでは、ドキュメントの鮮度管理が最大の盲点です。

• ソースドキュメントが更新されてもインデックスが再構築されない
• 本番クエリのログを収集・分析する仕組みがなく、精度劣化に気づけない
• 「とりあえず全部渡す」設計が横行し、コストと精度の両面で問題が顕在化するケースが報告されている

三つのフェーズを横断的にレビューする習慣が、RAG構築の失敗を未然に防ぐ第一歩となります。

RAGの失敗は「なんとなく動く」段階から「本番品質」へ引き上げる過程で集中して発生します。設計・実装・運用の3フェーズで起きやすい問題を10パターンに整理したので、まず全体像を把握し、自プロジェクトの現状と照らし合わせてみてください。詳細な原因分析と回避策は、次のセクション以降で順を追って解説します。

設計フェーズ（パターン1〜3）

• パターン1：チャンクサイズの設計ミス
• パターン2：メタデータ設計の欠落
• パターン3：ユースケースに合わない埋め込みモデルの選定

実装フェーズ（パターン4〜7）

• パターン4：埋め込みモデルとLLMの言語ミスマッチ
• パターン5：PDFなど非構造化ドキュメントの前処理不足
• パターン6：プロンプトへのコンテキスト詰め込みすぎ
• パターン7：再ランキング（リランカー）なしで上位k件を直接渡す

運用フェーズ（パターン8〜10）

• パターン8：インデックス再構築タイミングの管理不足
• パターン9：評価指標を設定しないまま本番化
• パターン10：多言語ドキュメント混在による検索精度劣化

設計フェーズでの判断ミスは、後工程のすべてに悪影響を波及させます。実装を始めてから気づいても手戻りコストが大きいため、以下の3パターンは着手前に確認しておくことが重要です。

パターン1：チャンクサイズの設計が不適切

チャンクが大きすぎると、検索時に無関係な情報が混入してLLMの回答精度が下がります。逆に小さすぎると文脈が途切れ、単体では意味をなさないチャンクが上位にヒットしやすくなります。

• 一般的なユースケースでは256〜512トークン前後が検討の出発点とされる傾向がある
• 法令文書や技術仕様書など構造が複雑な場合は、セクション単位の可変長チャンキングが有効なケースが報告されている
• LlamaIndexやLangChainはセマンティックチャンキング機能を標準搭載しており、文の意味的まとまりを考慮した分割が選択肢として利用できる

パターン2：ユーザークエリの多様性を想定しない

設計段階でクエリのバリエーションを洗い出さないと、本番で想定外の質問に対して的外れな検索結果が返り続けます。

• 専門用語で問い合わせる社内ユーザーと、平易な言葉で聞く一般ユーザーが混在する場合、単一の埋め込みモデルでは対応しきれないことがある
• クエリ拡張（Query Expansion）やHyDE（Hypothetical Document Embeddings）などの前処理手法を設計段階で検討しておくことが望ましい

パターン3：データソースの品質評価を省略する

ドキュメントの品質が低いままベクトル化しても、検索精度は向上しません。「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」の原則はRAGでも例外ではありません。

• 重複ドキュメント・古い情報・フォーマットの不統一はインデックス汚染の主な原因となる傾向がある
• 設計フェーズでデータクレンジングのパイプラインを定義しておかないと、運用フェーズで品質問題が顕在化しやすい
• PDFや社内Wikiなど複数ソースを混在させる場合は、メタデータ設計（作成日・ソース種別・信頼度スコアなど）を同時に決めておくことが重要

設計が固まった後の実装段階でも、見落としやすい落とし穴が連続して現れます。パターン4〜7は「動いているように見えるが精度が出ない」状態を生み出す典型例です。

パターン4：埋め込みモデルとLLMの言語ミスマッチ

日本語ドキュメントを英語特化の埋め込みモデルでベクトル化すると、語彙の意味空間がずれ、類似度スコアが信頼できなくなる傾向があります。multilingual-e5-largeやtext-embedding-3系など多言語対応モデルの選択肢は広がっているため、使用するLLMと埋め込みモデルの対応言語を事前に照合することが重要です。

パターン5：チャンクのオーバーラップ設定ミス

オーバーラップをゼロにすると文脈が途切れ、大きくしすぎると重複情報がノイズになります。ドキュメントの構造によって最適値は異なるため、複数パターンで実測評価して調整することが求められます。

パターン6：メタデータを活用しないフラット検索

ベクトル類似度だけに頼ると、古いバージョンのマニュアルが新しいものより上位にヒットするリスクがあります。作成日・カテゴリ・バージョン番号などをフィルタ条件として組み合わせることで、検索精度を改善できます。

パターン7：再ランキングなしで上位k件をそのまま渡す

ベクトル検索の上位結果は「意味的に近い」ものの、必ずしも「回答に最も有用」とは限りません。Cross-Encoderベースの再ランキングモデルを挟むことで、LLMに渡すコンテキストの質が向上する事例が報告されています。

実装チェックリストとして以下を確認してください。

• 埋め込みモデルの対応言語をドキュメント言語と照合したか
• オーバーラップ率を複数パターンで評価したか
• メタデータフィルタリングの設計が完了しているか
• 再ランキングステップの有無を意思決定したか

これらを見落としたまま本番化すると、運用フェーズでの修正コストが大きく膨らむ傾向があります。

本番稼働後に発覚する問題は、修正コストが設計フェーズの数倍に膨らむ傾向がある。「動いているから大丈夫」という慢心が、運用フェーズ特有の失敗を招きやすい。

パターン8：ドキュメント更新時のインデックス再構築を怠る

社内規程や製品仕様書は頻繁に改訂される。古いベクトルインデックスが残ったまま運用を続けると、廃止済みのルールや旧バージョンの仕様を根拠にした回答が生成されるリスクがある。差分更新パイプラインを自動化し、更新トリガーを明示的に設計することが重要だ。

パターン9：評価・モニタリングの仕組みを持たない

• Faithfulness・Answer Relevancyなどの定量指標を設定しないまま運用するケースが多い
• フィードバックループがないため、精度劣化への気づきが遅れる
• RAGASやTruLensといった評価フレームワークを本番前に組み込むことが、標準的なプラクティスになりつつある

RAGASのスコアを定期バッチで計測し、閾値を下回った際にアラートを出す仕組みが有効だ。

パターン10：LLMのモデルバージョン更新による挙動変化を考慮しない

APIプロバイダーがモデルをアップデートすると、同じプロンプトでも出力の傾向が変わることがある。プロンプトテンプレートや後処理ロジックが旧バージョンに依存している場合、突然の品質低下につながる。

• モデルバージョンを明示的に固定し、更新時は回帰テストを実施する
• プロンプトをコードと同様にGitで管理する
• 本番環境と検証環境を分離し、段階的なロールアウトを行う

継続的な計測と更新管理を設計段階から組み込むことが、長期的な品質維持の鍵となる。

チェックリストで全体像を把握したら、次のステップは「なぜその失敗が起きるのか」「どう回避するか」を構造的に理解することです。

各パターンには、設計・実装・運用それぞれのフェーズに固有の原因があります。表面的な症状だけを修正しても、根本原因が残れば同じ問題が繰り返される傾向があります。自分のシステムのどのフェーズに当てはまるかを照らし合わせながら読み進めてください。

チャンクサイズの設定ミスは、RAG構築で最も頻繁に報告される失敗の一つです。「大きめに切れば情報が欠けない」という判断が、かえって検索精度を大きく損なうケースが多く見られます。

なぜ大きすぎるチャンクが問題になるのか

ベクトル検索では、チャンク全体の意味をひとつの埋め込みベクトルに圧縮します。チャンクが大きいほど、そのベクトルは「複数トピックを平均した曖昧な表現」になりやすく、クエリとの類似度計算が不正確になります。結果として、本来マッチすべき箇所が上位に来ない「検索ミス」が増加します。

起きやすい症状

• クエリの意図と無関係な段落が混入しやすくなる
• LLMに渡すコンテキストに「関連情報」と「無関係な情報」が混在し、回答精度が下がる
• 上位k件を取得しても、実質的な情報密度が低くなる

推奨アプローチ：Small-to-Big検索（親子チャンク戦略）

現在主流なのは、検索時は小さなチャンク（128〜256トークン程度）で精度の高いマッチングを行い、LLMへの入力時には親チャンク（512〜1,024トークン）を渡す方法です。文脈の欠落を防ぎながら検索精度を保てます。LlamaIndexやLangChainでは、この戦略を実装する機能が標準的に提供されています。

実装時の目安（参考値）

• 検索用チャンク：128〜256トークン（精度優先）
• LLM入力用チャンク：512〜1,024トークン（文脈保持）
• チャンク間オーバーラップ：20〜50トークン程度（文脈の断絶を防ぐ）

チャンクサイズは「一度決めたら終わり」ではありません。RAGASなどの評価フレームワークで定期的に検索精度を測定しながら調整する運用が、本番品質の維持に重要です。最適値はドキュメントの性質やユースケースによって異なるため、上記数値はあくまで参考として自社環境での検証を行うことを推奨します。

埋め込みモデルとLLMの言語が噛み合っていない状態は、RAG全体の精度を静かに蝕む。検索結果は返ってくるのに回答がなぜかズレている——そう感じたときに疑うべき原因のひとつがこのミスマッチだ。

問題の構造

埋め込みモデルは「クエリと文書の意味的距離」を計算し、LLMは「取得されたコンテキストを読んで回答を生成する」という役割分担がある。この2つが異なる言語空間で動いていると、検索では関連チャンクが上位に来ても、LLMがそのチャンクを適切に解釈できないケースが生じる。

典型的なミスマッチのパターンは以下のとおりだ。

• 英語特化の埋め込みモデル × 日本語ドキュメント：英語コーパスで主に学習されたモデルは、日本語文書の意味表現が粗くなる傾向がある
• 多言語埋め込みモデル × 英語専用LLM：埋め込みが多言語対応でも、LLMが日本語コンテキストを正確に処理できなければ回答品質が落ちる
• ドメイン特化語彙の不一致：法律・医療・金融など専門用語が多い領域では、汎用埋め込みモデルが用語の意味を正確にベクトル化できないケースが報告されている

回避策

1. 埋め込みモデルとLLMを同一プロバイダーで揃えることで言語空間のズレを最小化する
2. 多言語対応モデルを候補に加えて比較検証する（公式スコアのみを参考とし、自社環境での実測を推奨）
3. RAGASなどの評価フレームワークで「Context Relevance」スコアを測定し、検索精度とLLM解釈精度を分離して評価する

モデル選定は一度決めると変更コストが高い。初期段階で複数モデルをA/Bテストする習慣が、後工程の手戻りを防ぐ鍵となる。

ベクトル検索で取得した上位k件のチャンクを、そのままLLMへ渡していませんか？実装が手軽な反面、回答品質を大きく損なう代表的な落とし穴です。

ベクトル検索はコサイン類似度などで意味的な近さを測りますが、クエリへの関連度と回答に必要な情報量は必ずしも一致しません。類似度スコアが高くても、実際の質問に正確に答えられるチャンクが上位に来るとは限らない傾向があります。

なぜ上位k件をそのまま渡すと問題になるのか

• 「関連しているが答えではない」チャンクが混入しやすい
• コンテキストウィンドウを無駄に消費し、本当に必要な情報が薄まる
• ノイズが多いほどLLMが誤った情報を拾い、ハルシネーションのリスクが高まる

回避策：再ランキング（Re-ranking）の導入

取得フェーズと生成フェーズの間に、クロスエンコーダーモデルを用いた再ランキングステップを挟むことが有効です。クロスエンコーダーはクエリとチャンクを同時に入力して関連度を精密に評価するため、バイエンコーダー方式のベクトル検索より高精度な順位付けが期待できます。

CohereのRerankエンドポイントやBAAI/bge-rerankerシリーズ、FlashRankのような軽量ローカルモデルが広く活用されています。これらを組み合わせることで、LLMに渡すチャンクを絞り込み、コンテキストの質を高められます。

実装上のポイント

• 初回検索では広めに（top-20〜50件）取得し、再ランキング後にtop-3〜5件に絞る
• 再ランキングモデルは日本語対応の有無を必ず公式ドキュメントで確認する
• レイテンシへの影響を計測し、非同期処理やキャッシュで補う

RAGシステムは「一度構築したら終わり」ではない。ドキュメントが更新されたにもかかわらず、ベクトルインデックスをそのまま放置するケースは、本番運用で頻繁に報告される失敗パターンの一つだ。

なぜ問題になるのか

ベクトルストアに格納されているのは、インデックス作成時点のスナップショットに過ぎない。社内規程・製品仕様書・APIドキュメントなど更新頻度の高いドキュメントを扱う場合、インデックスが古いままだと以下の問題が生じる。

• 廃止されたルールや旧バージョンの仕様を根拠に回答を生成してしまう
• 最新情報が検索対象から除外され、ユーザーに誤った情報が提供されるリスクが高まる
• 削除済みのチャンクが検索にヒットし、存在しないコンテンツへの参照が発生する

見落とされがちな「差分更新」の設計不足

多くのチームがインデックスの「全件再構築」は意識しても、「差分更新」の仕組みを設計しないまま本番化する傾向がある。全件再構築はドキュメント数が増えるほどコストと時間がかかるため、更新頻度が高い環境では現実的でないケースも多い。

LlamaIndexやLangChainのドキュメントローダーには差分検知機能が整備されつつある。ドキュメントのハッシュ値やタイムスタンプを管理し、変更があったチャンクのみを再埋め込みする設計が推奨されている（各フレームワークの公式ドキュメントで最新仕様を確認すること）。

回避策のポイント

• ドキュメントごとにメタデータ（最終更新日時・バージョン番号）をベクトルストアに付与する
• CI/CDパイプラインにインデックス更新ジョブを組み込み、ドキュメント変更をトリガーに自動実行する
• 定期的なインデックス整合性チェックを設け、参照先ドキュメントが存在するかを確認する
• 削除されたドキュメントに対応する「論理削除フラグ」をメタデータで管理する

インデックスの鮮度はRAGの回答品質に直結する。運用フェーズに入った後こそ、更新フローの自動化と監視体制の整備を優先すべきだ。

「動くものを作った」段階で満足してしまうと、本番環境で思わぬ問題が噴出するケースが報告されている。RAG実装では、一見すると正しそうな手順が検索精度やコスト効率を大きく損なっていることがある。ここでは現場で特に遭遇しやすい2つのNG実装パターンを取り上げ、何が問題なのかを解説する。

PDFをそのままベクトル化する実装は、RAG構築における代表的なNG例のひとつです。手軽に見えますが、検索精度を著しく低下させる原因になりやすい点に注意が必要です。

なぜNGなのか：PDFが抱える構造的な問題

PDFは印刷レイアウトを優先したフォーマットであり、テキスト抽出の段階でさまざまなノイズが混入します。代表的な問題は以下のとおりです。

• ヘッダー・フッターの混入：ページ番号や会社名が本文と結合し、意味のないチャンクが生成される
• 段組レイアウトの誤読：2カラム構成のPDFでは、左右の列が混ざった順序で抽出されるケースがある
• 表・図のテキスト化失敗：セル内データが結合・欠落し、数値情報が正確に取得できない
• 文字化け・記号の混入：フォント埋め込みの問題で、特殊文字や日本語が崩れる場合がある

これらのノイズがそのままベクトル化されると、埋め込みベクトルの品質が低下し、関連性の高いチャンクが検索でヒットしにくくなります。

回避策：前処理パイプラインを設ける

PyMuPDF・pdfplumber・Unstructuredといったライブラリを活用した前処理が広く採用されています。基本ステップは以下のとおりです。

1. ヘッダー・フッターを正規表現またはレイアウト解析でトリミング
2. 表はMarkdown形式やCSVに変換してからチャンク化
3. 抽出後のテキストを目視サンプリングしてノイズの有無を確認
4. スキャンPDFにはTesseractやAzure Document Intelligenceを検討

PDFの前処理はRAG全体の品質を左右する土台です。ベクトル化の前段階に十分な工数を確保することが、本番品質を確保するうえで欠かせません。

検索でヒットしたチャンクを「とにかく全部渡せば安全」と考え、プロンプトのコンテキスト欄に大量のテキストを詰め込む実装は、現場で頻繁に見られるNG例のひとつです。

情報量が多いほど回答精度が上がりそうに思えますが、実際には逆効果になりやすい傾向があります。コンテキストが長くなるほどLLMは「どの情報が重要か」を判断しにくくなり、回答の質が低下するケースが報告されています。この現象は「Lost in the Middle」問題として知られており、プロンプトの中央付近に配置された情報がモデルに参照されにくくなることが研究で示されています。

典型的な失敗の流れ

• 上位20件のチャンクをそのままシステムプロンプトに連結する
• 合計トークン数が1万〜2万を超える
• モデルが中盤・末尾の情報を見落とし、冒頭付近の内容だけで回答を生成する
• 結果として「的外れ」または「不完全な回答」が頻発する

問題をさらに悪化させる要因

• チャンク間に重複した内容が含まれており、モデルが混乱しやすくなる
• 関連度の低いチャンクが上位に混入し、ノイズとして機能する
• コンテキストが長いほどAPIの推論コストと応答レイテンシが増大する

回避策のポイント

• 再ランキング（Cross-Encoderなど）を挟み、上位k件を3〜5件程度に絞り込む
• チャンクの関連スコアに閾値を設け、一定以下は除外する
• 渡すコンテキストの合計トークン数に上限を設定し、超過分は切り捨てるロジックを実装する

GPTやClaudeのコンテキストウィンドウが大幅に拡張されている現在でも、「長く渡せる＝長く渡すべき」ではありません。精度・コスト・レイテンシのバランスを保つため、コンテキストの量は常に必要最小限に絞る設計を基本とすることが重要です。

チャンク設計や検索アルゴリズムの選定に力を注ぐ一方で、見落とされやすい落とし穴も存在します。評価指標を設けないままリリースするケースや、多言語ドキュメントが混在する環境での精度劣化は、現場で繰り返し報告されている課題です。次のH3では、これら二つの落とし穴を掘り下げ、具体的な対処の方向性を示します。

RAGシステムが「動いている」状態と「正確に答えられている」状態は、まったく別物だ。評価指標を持たないまま本番リリースすると、品質劣化に気づくのが遅れ、ユーザーからのクレームが唯一のフィードバック手段になりかねない。

評価なし本番化が引き起こす主なリスク

• 検索ヒット率（Recall）の低下を数値で把握できず、改善の優先順位が立てられない
• ハルシネーションの発生頻度が不明なまま、誤情報が蓄積・拡散するリスクがある
• チャンク設計やプロンプト変更の効果を定量比較できず、改善が属人的な判断に依存する
• リグレッション（改修による品質後退）を検知できないため、更新のたびに品質リスクを抱える

RAG評価のフレームワークとして広く参照されているのがRAGASだ。主に以下の指標でシステム品質を多角的に測定できる。

• Faithfulness（忠実性）：生成回答が検索コンテキストに基づいているか
• Answer Relevancy（回答関連性）：質問に対して回答が適切に応答しているか
• Context Precision / Recall：検索チャンクが精度・網羅性の両面で適切か

本番化前に最低限実施すべき評価の流れは次のとおりだ。

1. 代表的なクエリ50〜100件のテストセットを用意する
2. RAGASなどで各指標のベースラインを計測する
3. 閾値（例：Faithfulness 0.8以上）を定め、下回った場合はリリースを保留するルールを設ける
4. 本番後も定期的に同じテストセットで再評価し、スコアの推移を監視する

「感覚的に精度が良さそう」という主観評価だけで本番化するのは、品質保証の観点から見ると構造的な欠陥と言える。評価基盤の整備こそ、RAGシステムの信頼性を担保する最初の一歩だ。

日本語と英語が混在するナレッジベースは、RAGにおいて見落とされがちな検索精度劣化の温床となる。多言語対応の埋め込みモデルは進化を続けているものの、実運用では言語混在に起因する問題が依然として多く報告されている。

なぜ精度が落ちるのか

埋め込みモデルは言語ごとにベクトル空間の分布が異なる傾向がある。日本語クエリに対して英語ドキュメントが意味的に近くても、ベクトル距離が開いてしまい検索結果から漏れるケースが生じやすい。

主な劣化要因は以下の通りだ。

• モデルの多言語対応範囲の差異：多言語対応を謳うモデルでも、東アジア言語の精度は英語より低い傾向が報告されている
• トークナイザーの影響：日本語は形態素単位で分割されるためトークン数が膨らみ、チャンク境界でのコンテキスト切断が起きやすい
• スコアリングの非対称性：同一の意味内容でも言語が異なると類似度スコアが一致せず、上位k件に偏りが生じる

具体的なシナリオ

製品マニュアルが日本語、技術仕様書が英語で管理されているシステムを想定する。「冷却ファンの回転数制御」という日本語クエリに対し、英語仕様書内の"cooling fan RPM control"が意味的に最適な回答源であっても、検索上位に浮上しないケースが起こりやすい。

回避策

• クエリを複数言語に自動翻訳してから検索する「クエリ拡張」アプローチを採用する
• 言語ごとにインデックスを分割し、マージ時にスコアを正規化するアーキテクチャを検討する
• 多言語特化モデルとBM25を組み合わせて検索精度を補完する
• 定期的に言語別の検索精度を評価指標で計測し、モデルの再選定サイクルを設ける

言語混在の問題は「使えばわかる」段階になって発覚しやすい。設計段階でドキュメントの言語構成を棚卸しし、対応策を組み込んでおくことが本番化への近道となる。

これまで紹介してきた失敗パターンを踏まえると、RAG設計には「最初から完璧を目指す」よりも「壊れにくい構造を選ぶ」という発想が重要になる。検索戦略・チャンク設計・評価指標のいずれかが欠けると、どこかのフェーズで必ず問題が表面化する。ここでは、特に効果が高いとされるハイブリッド検索の設計思想と、複雑なクエリへ柔軟に対応するAgentic RAGのパターンを掘り下げる。

ベクトル検索単体では拾いきれないクエリが、実運用では頻繁に発生する。ハイブリッド検索はその弱点を補う、現時点で最も実績のあるアプローチの一つだ。

ベクトル検索とBM25それぞれの弱点

• ベクトル検索の弱点：固有名詞・型番・コマンド名など、表記が一致しないと類似度スコアが下がりやすい。「AWS Lambda」「CVE-2024-XXXX」のような識別子は意味的な近傍に埋め込まれにくい傾向がある
• BM25の弱点：単語の表層一致に依存するため、言い換えや同義語には対応しにくい。「コスト削減」と「費用圧縮」は別クエリとして扱われてしまう

両者を組み合わせることで、意味的な近似と字句的な一致の双方をカバーできる。

スコアの統合方法：RRFが主流

スコア統合には Reciprocal Rank Fusion（RRF） が広く採用されている。各検索結果の順位を逆数で重み付けして合算するシンプルな手法で、スコアのスケールが異なる二つのシステムを正規化なしに結合できる点が利点だ。Elasticsearch・OpenSearch・Weaviateなど主要な検索基盤はRRFベースのハイブリッド検索のネイティブサポートを進めており、実装コストは以前より下がっている。

効果が出やすいケース

• 製品マニュアルや技術仕様書など、型番・コマンドが頻出するドキュメント
• 社内規程や法令文書など、条文番号や固有用語が検索キーになる場合
• ユーザーが口語表現と専門用語を混在させるチャットボット用途

固有名詞を含むクエリの検索精度が改善される傾向が複数の事例で報告されている。まずBM25の重みを低めに設定してベクトル検索主導で動かし、精度ログを見ながら比率を調整するアプローチが運用しやすい。次セクションのAgentic RAGと組み合わせる際も、ハイブリッド検索を検索レイヤーの基盤として据えておくと、複雑なクエリへの対応力が一段高まる。

通常のRAGは「1クエリ→1検索→1回答」という単純なパイプラインを前提とする。しかし現場では、複数ステップの推論や複数ソースの統合が必要なクエリが頻繁に発生する。こうした複雑なクエリに対応するのがAgentic RAGの設計パターンだ。

Agentic RAGとは、LLMをエージェントとして機能させ、検索・判断・再検索のループを自律的に繰り返すアーキテクチャを指す。主な設計パターンは以下の3つに整理できる。

• Plan-and-Execute型：クエリを受け取ったエージェントがまず「サブタスク一覧」を生成し、各タスクに対して個別に検索・回答を実行。最後に統合回答を生成する
• ReAct（Reasoning + Acting）型：思考→行動→観察のサイクルを繰り返し、検索結果が不十分であれば自動的にクエリを言い換えて再検索する
• Self-RAG型：生成した回答に対してモデル自身が「この回答はドキュメントに裏付けられているか」を評価し、不確かな場合は検索をやり直す

たとえば「A製品とB製品の価格差が生じる技術的な理由を比較して」というクエリは、単一検索では対応が難しい。Plan-and-Execute型であれば、A製品の仕様検索・B製品の仕様検索・比較推論という3ステップに分解して処理できる。

導入時には以下の点に注意したい。

• ループ回数の上限（max_iterations）を設定し、無限ループを防ぐ
• 各ステップのログを記録し、どの検索が失敗したかをトレース可能にする
• ツール呼び出しが累積するため、レイテンシとトークン消費の監視が不可欠

Agentic RAGは強力だが、複雑さが増す分だけ障害ポイントも増える。シンプルなクエリには通常のRAGを使い、複雑なクエリにのみエージェントを起動するハイブリッド構成が、運用安定性の観点から有効な傾向がある。

RAG構築・運用に取り組む開発者やエンジニアから寄せられる疑問を、厳選して2つ取り上げます。「小規模なドキュメントでもRAGは意味があるのか」「どのLLMを選ぶべきか」は、現場でも依然として多く聞かれる問いです。設計判断に直結するため、それぞれ具体的な観点を交えて解説します。

結論から言えば、ドキュメント数が少なくてもRAGは有効に機能するケースは多い。ただし、規模が小さいからこそ設計上の注意点が変わってくる。

小規模環境（数十〜数百件程度）では、ベクトル検索のインデックスサイズが小さいため、検索レイテンシは低く抑えられる傾向がある。一方で、候補チャンクの絶対数が少ないぶん、チャンク設計の粗さが回答品質に直結しやすい点には注意が必要だ。

効果が出やすいユースケースの例：

• 社内規程・マニュアルなど更新頻度が低く権威性の高いドキュメント群
• 製品仕様書やFAQなど、構造化されたテキストが中心の場合
• 特定ドメインに限定した専門用語の多い社内ナレッジベース

逆に注意が必要なのは、ドキュメントが少ないと「検索がヒットしない」ケースが増えることだ。クエリに対応するチャンクが存在しない場合、LLMは手持ちの情報で補完しようとしてハルシネーションが起きやすくなる。「ドキュメントに記載がない場合は回答しない」という明示的な指示をプロンプトに組み込むことが、特に重要になる。

要点まとめ：

• 小規模でもRAGは有効だが、チャンク設計とプロンプト設計の精度がより重要になる
• ヒット率を上げるため、クエリ拡張（Query Expansion）の導入を検討する
• ドキュメントが少ない分、全件評価によるRAGAS等の品質測定が比較的容易に実施できる

RAG構築において、LLMの選択は「どれが最強か」ではなく「自分のユースケースに何が合うか」で判断するのが基本的な考え方です。GPT・Claude・Geminiはいずれも高い性能を持ち、一概な優劣はつけにくい状況です。

各モデルの特徴と向いているユースケース：

• GPT（OpenAI）: ツール連携・関数呼び出しの実績が豊富で、LangChainやLlamaIndexとの統合事例が多い。RAGパイプライン構築のノウハウが蓄積されており、エコシステムの成熟度が高い
• Claude（Anthropic）: コンテキストウィンドウが非常に大きく、長文ドキュメントを一括で扱うシナリオに強みがある傾向がある。指示への忠実さや安全性を重視する設計が報告されている
• Gemini（Google）: Google Workspaceや検索インフラとの親和性が高く、マルチモーダル対応が充実している。日本語処理の品質も向上傾向にある

選定時に確認すべきポイント：

• 対象ドキュメントが長文か短文か（長文ならコンテキスト長が大きいモデルが有利）
• 既存インフラ・フレームワークとの統合コスト
• 日本語ドキュメントの割合（日本語対応品質はモデルごとに差がある）
• コスト構造（各社公式料金ページを執筆時点の参考値として確認すること）

実務では、単一モデルに依存せず複数モデルを評価した上で選定するアプローチが有効です。RAGASなどの評価フレームワークで自社のドキュメントとクエリセットを使い、実際にスコアを測定してから本番モデルを決定することが推奨されます。「有名だから」という理由だけで選ぶと、精度・コスト・レイテンシのいずれかで想定外の課題が生じるケースがあります。

ここまで解説してきた10の失敗パターンは、設計・実装・運用の各フェーズに分散して潜んでいる。一度に全てを解決しようとするより、フェーズごとにチェックリストを活用して段階的に潰していくアプローチが現実的だ。

RAGASやTruLensといった評価フレームワークを活用し、Retrieval精度・Answer Relevancy・Faithfulnessの複数指標を組み合わせた定量評価が標準的になりつつある。本番化前にベースラインを計測しておくと、改善サイクルを回しやすくなる。

チェックリストを運用する際の要点は以下の通りだ。

• 設計フェーズ: チャンクサイズ・オーバーラップ幅・埋め込みモデルの言語適合性を確認する
• 実装フェーズ: ハイブリッド検索の導入可否・再ランキングの有無・プロンプト長の上限を検証する
• 運用フェーズ: インデックス更新頻度・評価指標のモニタリング体制・多言語ドキュメントの混在状況を定期的に見直す

特に見落とされやすいのが「運用フェーズの継続的なモニタリング」だ。ドキュメントが更新されるたびにインデックスが陳腐化し、回答品質がサイレントに劣化する傾向がある。品質チェックを仕組みとして組み込んでおくことが、長期的な安定稼働につながる。

RAGは一度構築して終わりではなく、データとユーザーの問いに合わせて継続的に育てるシステムだ。チェックリストを「設計時の儀式」ではなく「運用の習慣」として定着させることが、本番化を成功に導く近道といえるだろう。