RAG疲れとは何か：RAGの限界・失敗パターン・運用コストを整理する

特集「RAG疲れからの脱出：Corpus2Skillが示す検索しないAI知識基盤」第1回 公開予定：2026年5月14日 ／ 著者：野口真一

はじめに：「RAGがあれば社内検索は解決する」と言われていた頃の話

2023年から2024年にかけて、ChatGPTと社内文書を結びつけたいという相談は、私の現場にも数えきれないほど舞い込みました。回答はだいたい同じで、「まずは RAG（Retrieval-Augmented Generation）で組みましょう」。文書をベクトル化し、近いものを引いてきて、LLMにまとめさせる。シンプルで、安く、しかも見栄えがする。社内デモではあっという間に拍手が起き、決裁がおります。

ところが2025年後半、現場の雰囲気が少し変わってきました。「PoCは動いた、けれど本番で何かが足りない」という声が、業種を問わず重なってきます。チャンクを刻み直し、埋め込みモデルを差し替え、ベクトルDBを乗り換え、リランカーを足し、プロンプトを書き直す。それでも、ユーザーが期待した「ちゃんと正しい答え」には届かない。ある情シス担当の方は、ため息をついてこう言いました。「もう、RAGに疲れました」。

本稿はその一言を起点に、運用現場で起きている「RAG疲れ」という現象を、技術論ではなく組織と人とコストの視点から整理する記事です。続く第2回でCorpus2Skillという別解を、第3回で他のRAG代替技術との比較と導入戦略を扱います。まずは、この第1回で「自分たちが感じている重さの正体は何なのか」をはっきりさせるところから始めます。

RAGは一度、AI導入の救世主だった

少し公平を期しておきたいのですが、私はRAGそのものを否定する立場ではありません。むしろ2023〜2024年の社内AI導入では、RAGはほぼ唯一の現実解でした。

• ファインチューニング不要で、既存文書をそのまま活かせる
• 出典付きで回答できるので、ハルシネーション対策の建前が立つ
• ベクトルDBやLangChainなど、エコシステムが急速に整った
• LLMのコンテキスト長が短い時代、文書を「丸ごと食わせる」選択肢は事実上なかった

これらの利点は、稟議書を通す上でも、現場説明の上でも非常に強力でした。「うちの規程をAIに読ませて、社員からの問い合わせを減らしたい」という素朴な要望に対して、最初の答えとしては今でも合理的です。

問題はその先にあります。検索の精度がある程度上がってきて、ユーザーが本格的に頼り始めた瞬間に、「頭打ち」と「運用負荷」という別の壁が立ち上がる。ここからが、本稿で扱いたい「RAG疲れ」の領域です。

現場で起きている「RAG疲れ」の正体

RAG疲れは、技術用語ではありません。私が日々現場で耳にする愚痴と相談を束ねた、運用上の症候群のようなものです。共通しているのは、「もう打ち手が思いつかない」「次に何を触ればよいか分からない」という、改善ループの枯渇感です。

以下、典型的な5つの「疲れ」に分けて整理してみます。技術論として面白くないかもしれませんが、運用に入っている方ほど、どれかひとつは思い当たるはずです。

chunking疲れ：刻み方の正解がいつまでも見つからない

最初の壁は、ほぼ必ずチャンキングで来ます。512トークンか、1024か、1500か。オーバーラップは128か、256か。意味の区切りでスライスすべきか、固定長で機械的に刻むべきか。文書が増えれば増えるほど、「全文書に最適な刻み方」など存在しないことがはっきりしてきます。

ある現場では、規程・FAQ・議事録・契約書・操作マニュアルを同一インデックスに入れていたために、規程に最適化したチャンク設定が議事録の検索精度を落とし、議事録に合わせるとマニュアルの手順が断片化する、というジレンマに半年苦しみました。一見シンプルな「刻み方」というパラメータが、文書群が異種混合になった瞬間に、解のない最適化問題に変わるのです。

embedding疲れ：差し替えるたびに評価をやり直す消耗

埋め込みモデルの選定もまた、底のない井戸です。OpenAI、Cohere、Voyage、Qwen、E5、BGE、日本語特化モデル。新しい埋め込みが出るたびに、「もしかしてこれで精度が上がるのでは」と試してしまいます。

問題は、埋め込みモデルを差し替えるたびに、全ベクトルの再生成と再評価が必要になることです。文書が数十万件あれば、再ベクトル化だけで数時間〜数日。費用は数万円〜数十万円。さらに、評価データセットを使って実際に良くなったかを確認しなければなりません。「やってみないとわからない」が積み重なって、いつの間にか担当者の半分の時間が埋め込み比較に溶けている、という光景は珍しくありません。

vector DB疲れ：インデックスとインフラの面倒を見続ける

Pinecone、Weaviate、Qdrant、Milvus、pgvector、Elasticsearch。本番運用が始まると、ベクトルDBは単なるライブラリではなく、メンテすべきインフラとして牙を剥きます。

• ベクトル次元数を変えるとインデックス再構築が必要
• ハイブリッド検索のためにBM25インデックスも別途維持
• メタデータフィルタの設計を後から変えると、再投入が発生
• 文書の更新／削除を正確に追従させる仕組みが、想像以上に重い

しかも、これらは「AIプロジェクト」の名のもとに、本来はインフラチームの守備範囲だった重さが、AI担当者の机に積み上がっていきます。社内では「AIをやっている人」と一括りにされ、評価制度の上では誰もこのインフラ運用を労務として認識してくれない、というのもしばしば耳にする話です。

reranking疲れ：何を上に上げるべきかの最終解が出ない

リランカーは、RAG精度を一段上げる定番の打ち手です。Cohere Rerank、Cross-encoder、LLMによる自前リランキング。たしかに効きます。ただし、これも「最後の一段を上げているはずなのに、最後の一段が永遠に続く」性質を持っています。

リランカーを足すと、今度はリランカーのモデル選定、リランクするトップNの数、リランクスコアのしきい値、上位文書の足切り条件、というハイパーパラメータが芋づる式に増えます。チューニングは確かに進みますが、得られる精度向上が逓減していく一方で、システム複雑度は単調増加していく。担当者の脳内コストはじわじわと上がり、引き継ぎが効かない属人化を生みます。

評価疲れ：本当に良くなったかどうかが分からない

そして最後に、もっとも重い疲れが「評価疲れ」です。チューニングをひとつ行うたびに、「これで本当に良くなったのか」を客観的に確かめる必要があります。ところが社内文書ベースの評価データセットを作るには、業務担当者にQAペアを作ってもらわなければならない。彼らも本業がある。

結果として、評価データセットが古いまま、あるいは小さいまま、改善のたびに同じ50問を回し続ける運用に陥ります。50問のうち何問正解したかでパラメータを決め、現場に出してみると、「いや、社員が本当に聞いてくる質問はこれじゃないんだよね」と返ってくる。ベンチマークと本番ユーザーの乖離が、PoCの自信を本番運用で打ち砕いていきます。

RAGの失敗は、生成AIの失敗ではなく検索設計の失敗である

ここで強調しておきたいのは、いま挙げた5つの疲れはすべて、生成AIの問題ではなく、検索パイプラインの設計問題であるという点です。LLMの性能は2024年から2026年にかけて飛躍的に向上しました。Claude、GPT、Geminiのいずれも、与えられた文脈の中で要約や根拠提示を行う能力はもはや人間に近い水準にあります。

それでもRAGの精度が頭打ちになるのは、「LLMに何を渡すか」が間違っているからです。検索が外したチャンクをいくら高性能なLLMが受け取っても、出てくる答えはずれます。RAGの失敗事例を見ていくと、ほぼすべてが「retrievalの段階で本来取るべきものを取れていない」か「取ったものを構造として渡せていない」かのどちらかです。

これは、長年データ基盤を見てきた身からすると、ETLが壊れているのに分析の精度を上げようとしている状態に似ています。下流のモデルを賢くしても、上流が腐っていれば、出口は変わりません。RAG疲れの本質は「LLMが疲れている」のではなく、「検索の前提そのものが頭打ちになっている」のです。

RAG疲れを定義する

ここで、本稿のキーワードである「RAG疲れ」を、私の現場感覚として定義しておきます。技術用語というより、運用症候群としての定義です。

RAG疲れ（RAG Fatigue）：RAGを本番運用している組織で発生する、改善ループの枯渇感と運用負荷の蓄積による疲弊状態。次のいずれか／複数が当てはまる場合を指す。

1. 打ち手の手詰まり感：チャンク、埋め込み、ハイブリッド検索、リランカーを一通り試したが、精度が一定ラインから動かない
2. 評価の空転：何を変えても、評価データセットでの数字とユーザー体験の体感が一致しない
3. 属人化の悪化：パイプラインの複雑度が上がり、特定の担当者にしか触れない構造になっている
4. コストの不可視化：埋め込み再生成、ベクトルDB、リランカー、LLM呼び出しのコストが、誰も正確に把握できなくなっている
5. 組織内の信頼低下：現場ユーザーが「AIに聞いても結局自分で探したほうが早い」と離脱し始めている

5項目のうち2項目以上が当てはまる組織は、もう「RAGのパラメータをいじって解決する」フェーズではないと考えたほうがよいと思います。チューニングではなく、設計思想を変える局面に来ています。

RAGの失敗事例に共通する3つのパターン

私が直接見てきた、あるいは相談を受けた失敗事例を、3つのパターンに整理します。固有名は伏せます。

パターンA：似た言い回しが多い文書群で、意図と逆の結論を返す

カスタマーサポート用に組まれたRAGが、「年額プランの解約方法」を聞かれて、「年額プランへのアップグレード方法」を上位に出す。ユーザーが手順通りに進めると、料金が上がる。「ドメインの設定」と「ドメインの解約」を取り違えるのと同じ構造です。表面の語彙が近いほどベクトル空間で寄ってしまう、類似度検索の原理的な弱点が露出しています。

パターンB：上流の前提条件を取り損ねて、適用範囲を取り違える

「2025年4月以降の契約に限り適用」と書かれた上流条項を取り損ね、下流の手順だけを回答に出してしまう。法務やコンプライアンス系のRAGでは致命的で、社内監査で「根拠条文の前提部分が抜けている」と指摘されて運用停止になった事例もあります。チャンク単体の意味は正しいのに、それを含む文書全体の射程を見失っている、というRAGの典型的な事故です。

パターンC：手順の順序が崩れ、片側の条件分岐だけが回答に残る

操作マニュアル系のRAGで、「ステップ1→2→3」と並ぶ手順のうち、ステップ2だけがトップヒットし、結果として手順1と3が抜け落ちる。ユーザーは中間操作だけを実行し、入口と出口が成立しない状態になります。ヘルプデスクへのクレームが減るどころか、「AIに従ったら壊れた」というクレームが増える逆効果の運用です。

3パターンに共通しているのは、いずれも「LLMの賢さ」では解決できないという点です。渡される素材がそもそもズレているか、構造を失っているか。だから、生成側を強くしても改善は止まります。

RAG疲れの本当のコスト：技術費用より、組織と心理のコストが重い

RAG運用コストの議論は、しばしばトークン単価とインフラ料金の話に矮小化されます。月いくら、年いくら。もちろん大事です。ただ、RAG疲れの本質的なコストはそこにありません。

• 担当者の認知負荷：パイプラインが複雑化するほど、一人の頭の中で全体を保持しにくくなる。引き継ぎ困難、休めない、属人化が進む
• 評価のリードタイム：1回のチューニングサイクルに数日〜1週間。施策の数だけ時間が溶ける
• 現場との信頼関係：「AIに任せたら間違える」が一度刷り込まれると、再評価のチャンスを得るまでに数ヶ月かかる
• 意思決定の遅延：「もう一段チューニングしてからだ」と先送りされた予算配分が、別のAI施策の機会を奪っている

これらは経費精算には載らないコストです。ただ、現場の生産性と組織のAIへの期待値を確実に削っていきます。私が経営層や情シス責任者と話すとき、「RAGのトークン費用を半分にする」より「RAG疲れの担当者を救う」ほうが、はるかに大きなROIにつながることが多い、と感じています。

次の選択肢：検索しないAI知識基盤という発想

ここまでRAG疲れを定義してきましたが、「ではどうするか」が問題です。私の答えは、チューニングを続けるのではなく、そもそも「検索する」という前提を疑うことです。

2026年に入って、いくつかの方向の研究と実装が出てきています。

• GraphRAG：文書をエンティティと関係のグラフに変換し、グラフを辿って検索する
• RAPTOR：階層的に要約を積み上げ、抽象度の高い問いには要約層、具体度の高い問いには末端の本文を返す
• Agentic RAG：LLMエージェントが検索ツールを反復的に呼び出し、必要な情報を集める
• Corpus2Skill：コーパスをオフラインで階層的なスキルツリーに蒸留し、エージェントが目次を読みながらナビゲートする

このうち、本特集が注目するのは最後のCorpus2Skillです。理由はシンプルで、これだけが「検索しない」という前提を明示的に置いているからです。Don't Retrieve, Navigate。検索しないAI知識基盤、あるいはナビゲーション型RAGと呼んでもよいでしょう。

LLMに渡すのは断片ではなく、文書群を読み解くための地図です。エージェントは目次を眺め、自分で章を選び、必要なら章をまたいで戻ってくる。人間が分厚いマニュアルを読むときの動きを、そのままエージェントに置き換える発想です。

これがRAG疲れに対して何を解くのか、何を解かないのか、そして向く現場と向かない現場はどう見分けるのか。続く第2回で、Corpus2Skillの思想を編集者の視点で読み解いていきます。

まとめ：RAG疲れは「うまく動かない」ではなく「改善が続かない」病

第1回をまとめます。

• RAG疲れとは、改善ループの枯渇感と運用負荷の蓄積による組織的疲弊である
• chunking、embedding、vector DB、reranking、評価という5つの面で、それぞれ別種の疲れが発生する
• RAGの失敗は、生成AIの失敗ではなく、検索設計の失敗として理解すべきである
• 本当のコストは、トークン費用ではなく、担当者の認知負荷と組織のAIへの期待値の毀損である
• 解決策はチューニングの延長線ではなく、「検索する」という前提を変える設計転換にある

「うちもRAG疲れかもしれない」と感じた方は、次回のCorpus2Skill編をどうぞ。技術解説というより、RAG後の知識基盤をどう設計し直すかという編集的な視点でお届けします。

想定SEOキーワード

• 主要：RAG疲れ／RAG 限界／RAG 運用／RAG 運用 コスト／RAG 失敗／RAG 失敗 事例
• 副次：RAG 代替／検索しないAI知識基盤／ナビゲーション型RAG／RAG チューニング 頭打ち
• ロングテール：RAG チャンク 疲れた／RAG 評価データセット 作れない／社内文書 検索 AI 精度

内部リンク候補

• /blog/2026-04-29-corpus2skill-zenpen.html（前編：構造的限界の技術的解説）
• /blog/2026-04-29-corpus2skill-kouhen.html（後編：実装手順）
• /blog/2026-03-27-rag-cost-reduction.html（RAGコスト削減）
• /blog/2025-07-01-vector-database-rag.html（ベクトルDBとRAG入門）
• 特集第2回：/blog/feature/rag-fatigue/02.html（仮）
• 特集第3回：/blog/feature/rag-fatigue/03.html（仮）
• /services.html#ai（AI導入コンサルティング）
• /contact.html（無料相談）

既存記事との差別化メモ

• 既存前編はRAGの「技術的な4つの限界」を扱っているが、本稿は運用症候群としてのRAG疲れを定義することで切り口を分けた
• chunking/embedding/vector DB/reranking/評価という5つの疲れの整理は既存記事には存在しない独自フレーム
• 既存記事は事例を仮想（佐藤さん）として描写、本稿は3つの失敗パターン（A/B/C）として匿名化した実例ベースで体系化
• 「RAG疲れ」という造語の明示的な定義（5項目チェック）は特集第1回の固有資産として、第2回・第3回からも引用できるアンカーにする
• 既存記事は最後にCorpus2Skillの概念解説まで踏み込むが、本稿は「次の選択肢の存在を示すのみ」で第2回に送り出す構成として役割を分担