「RAGは終わった」は本当か――ロングコンテキストが変えたこと、変えられないこと

大規模言語モデル（LLM）の進化とロングコンテキストの登場により、「RAGは不要になるのではないか」という議論が浮上している。RAGとロングコンテキストはどう違うのか。

公開 2026年04月16日 05時03分

[TechTargetジャパン]

印刷する

　大規模言語モデル（LLM）には、ある根本的な真実がある。それは「時間が止まった存在」であるということだ。LLMはナレッジカットオフ（情報の最終更新日）までの世界の情報を学習しているが、たった5分前に何が起きたかは把握していない。そこで、最新情報や社内データを扱うには、LLMに外部データを与える仕組みが不可欠だ。この課題に対する代表的な解が、RAG（検索拡張生成）だ。

　一方、LLMのコンテキストウィンドウに文書全体をそのまま投入する「ロングコンテキスト」が新たな選択肢として登場した。RAGとロングコンテキストはどのように違い、どちらを使えばいいのか。IBMのマーティン・キーン氏（マネージャー兼IBMテクニカルトレーニングコンテンツクリエイター）の講演から、RAGの仕組みや課題、ロングコンテキストの強みを整理する。

RAGの仕組みと限界

併せて読みたいお薦め記事

AIの暴走を防ぐには

　RAGが動く過程は以下の通りだ。

事前準備
- マニュアル、議事録、規定、製品資料、PDF、コード、メール等の文書やデータを収集する。
- 情報をベクトル（数値のリストや配列）化して、AIモデルが意味を理解できるようにする（エンベディング）。エンベディングでは、文書やそのチャンク（小さい区切り）を、AIモデルが処理しやすいベクトルに変換する。ベクトルはベクトルデータベースに保存され、検索や生成処理の際に活用される。
クエリの処理
- ユーザーの質問を同数のエンベッドモデルでベクトル化する。
- ベクトルデータベースでクエリのベクトルと全チャンクベクトルの類似度を計算し、データを取得し、コンテキストに注入する。

　RAGは一見合理的だが、実務では3つの課題がある。

1．インフラが複雑化する

　まず問題となるのがインフラの複雑さだ。チャンキングの設計や埋め込みモデルの選定、ベクトルデータベースの運用に加え、検索結果を最適化するリランカーや元データとの同期管理など、多くの要素が組み合わさる。結果として構成が肥大化し、障害が発生した際に原因を特定しにくい「ブラックボックス化」が起きやすい。

2．検索くじが発生する

　検索そのものが確率的な仕組みに依存している点も見逃せない。いわゆる「Retrieval Lottery」（検索くじ）の問題だ。ベクトル類似度に基づく検索は常に最適な結果を返すとは限らず、必要な情報が存在していてもヒットしないケースがある。この場合、LLMは本来参照すべきデータにアクセスできず、結果として誤った回答や不完全な回答を生成してしまう。しかも、この不具合は表面化しにくく、「サイレント障害」として見過ごされやすい。

3．Whole Book Problem

　RAGはあくまで関連性の高い「断片」を取り出す設計であるため、文書全体を俯瞰した分析が求められる場面には適していない。例えば、複数の文書を比較して差分や欠落を検出するようなケースでは、部分的な情報だけでは全体像を把握できず、重要な見落としが発生する可能性がある。こうした「Whole Book Problem」は、RAGの構造的な限界を示している。

ロングコンテキストはこれが強い

　ロングコンテキストは、文書全体をそのままLLMに投入するアプローチだ。近年では100万トークン規模の処理が可能となり、書籍や大規模文書であっても一括で扱えるようになった。この進化により、従来のRAGとは異なる利点が生まれている。

1．インフラの簡素化（No Stack Stack）が可能になる

　ロングコンテキストでは、検索やベクトルデータベース、埋め込みモデルといった要素が不要となる。データをそのまま投入すればよいため、システム構成を簡素化でき、従来のRAG（検索拡張生成）に必要な複雑なインフラを排除した、極めてシンプルな構成「No Stack Stack」と呼べる状態に近づくことができる。

2．検索の失敗を排除できる

　検索プロセスを介さないため、必要な情報が見つからないといった失敗も起きにくい。全てのデータを直接参照できることで、「検索ミス」という概念そのものが薄れる点も特徴だ。

3．全体推論を強化できる

　文書全体を前提とした処理が可能になることで、複数文書の比較や抜け漏れの検知といった「全体推論」がしやすくなる。これは、断片的な情報に依存するRAGには難しかった領域だ。

それでもRAGが消えない理由

　一方で、ロングコンテキストがRAGを完全に置き換えるわけではない。

1．再読コスト問題

　まず問題となるのが計算コストだ。長大な文書を毎回コンテキストに投入して処理する必要があるため、リクエストごとに大きな負荷が発生する。これに対してRAGは、あらかじめデータをインデックス化しておくことで、クエリ時の処理負荷を抑えられるという利点がある。

2．Needle in a Haystack問題

　コンテキストが巨大になることで、重要な情報が埋もれてしまうリスクも無視できない。いわゆる「Needle in a Haystack」（干し草の中の針）問題だ。情報量が増えるほどLLMの注意が分散し、必要な箇所を正確に捉えられなくなる可能性がある。この点で、必要な情報だけを抽出して提示するRAGは、むしろ精度を担保する役割を果たす。