「RAGは終わった」は本当か――ロングコンテキストが変えたこと、変えられないこと：LLM外部データ活用の最適解は
大規模言語モデル（LLM）の進化とロングコンテキストの登場により、「RAGは不要になるのではないか」という議論が浮上している。RAGとロングコンテキストはどう違うのか。
大規模言語モデル（LLM）には、ある根本的な真実がある。それは「時間が止まった存在」であるということだ。LLMはナレッジカットオフ（情報の最終更新日）までの世界の情報を学習しているが、たった5分前に何が起きたかは把握していない。そこで、最新情報や社内データを扱うには、LLMに外部データを与える仕組みが不可欠だ。この課題に対する代表的な解が、RAG（検索拡張生成）だ。
一方、LLMのコンテキストウィンドウに文書全体をそのまま投入する「ロングコンテキスト」が新たな選択肢として登場した。RAGとロングコンテキストはどのように違い、どちらを使えばいいのか。IBMのマーティン・キーン氏（マネージャー兼IBMテクニカルトレーニングコンテンツクリエイター）の講演から、RAGの仕組みや課題、ロングコンテキストの強みを整理する。
RAGの仕組みと限界
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は、むしろ精度を担保する役割を果たす。
3．無限データセット問題
企業が扱うデータ量も課題だ。企業のIT環境に存在するデータは、テラバイトやペタバイト規模に及ぶことも珍しくない。こうした膨大な情報をすべてコンテキストに収めることは現実的ではなく、検索レイヤーによるフィルタリングが不可欠になる。
このように、ロングコンテキストも魅力的な選択肢である一方、RAGが担ってきた役割を完全に代替するものではない。両者は対立する技術ではなく、用途に応じて補完し合う関係にある。
契約書の分析やレポート要約など、「閉じたデータを深い推論で」といった場合はロングコンテキストを使う。社内ナレッジの検索やFAQなど「広範なデータを検索する」といった場合はRAGを使うといったように、両者を組み合わせたハイブリッド構成で運用できるとよい。
本稿は、2026年3月9日に公開された「Is RAG Still Needed? Choosing the Best Approach for LLMs」を記事化したものです。
Copyright © ITmedia, Inc. All Rights Reserved.