「RAGはもう要らない？」コンテキスト拡大が揺さぶる検索拡張設計の常識
霧島ヒカリ
2時間前・6分で読める
「もうRAGいらなくない？」——社内Slackでそう呟くエンジニアが増えている。2026年に入り、主要LLMのコンテキストウィンドウが100万〜200万トークンに達したことで、「全ドキュメントをそのまま突っ込む」構成が冗談ではなく選択肢に入り始めた。ただし、触ってみないとわかることがある。数字と実装の両面から現状を整理する。
2026年前半、複数のLLMプロバイダーがコンテキストウィンドウの大幅拡張を相次いで実施した。代表的な数字では、Gemini 1.5系が200万トークン、Claude系が100万トークン前後で安定運用できる状態になっている。日本語換算でおよそ200〜400万文字、A4用紙に換算すると約5,000〜10,000枚分のテキストを一度に渡せる計算だ。
「社内の設計書ぜんぶ突っ込んでClaudeに聞いたら普通に答えてくれた。RAGのインフラ維持コストと比較したら正直迷ってる」
こうした声がここ数週間で急増している。RAG（Retrieval-Augmented Generation）とはLLMに外部知識を渡す際、事前に「関連する断片だけを検索して絞り込む」技術で、コンテキスト制約がきつかった時代の主流解だった。
RAGが普及したのは2023年前後、GPT-4のコンテキストが8,192〜32,000トークン程度だった時代だ。全社ドキュメントを丸ごと渡せないため、ベクトルDB（PineconeやChromaなど）で類似文書を検索し、上位k件だけをプロンプトに差し込む構成が定番になった。
しかし構成は複雑だ。埋め込みモデルの選定、チャンキング戦略、検索精度のチューニング、インデックスの鮮度管理——これだけで小さなチームなら数週間が潰れる。「RAG税」と呼ぶエンジニアもいるほど、維持コストは地味にかかる。
コンテキストが100万トークンを超えると、少なくとも「中小規模の社内ナレッジ」であれば丸ごと投入できる。この変化が「そもそもRAG要る？」議論を再燃させている。
100万トークンを毎リクエスト送信すると、プロンプトキャッシュが効かない場合の入力コストは1リクエストあたり数十円オーダーになりうる。頻度が高いユースケースでは月数万円〜数十万円の差が出る。一方RAGは検索インフラのランニングコストが月1〜3万円程度（小規模）で済むケースも多い。コスト感は利用頻度と文書規模で逆転する。
理論上は全文を渡せても、LLMが100万トークンの中から正確に必要箇所を参照できるかは別問題だ。いわゆる「Lost in the Middle」——文書の中盤に埋まった情報を見落としやすい傾向は2025年以降改善されているが、完全に解消されていない。直近のベンチマーク（RULER, NIAH系）では先頭・末尾は精度90%超、中盤は70〜80%台に落ちるモデルが多い。
100万トークンのプリフィル処理は、高速なAPIでも数秒〜十数秒かかる。インタラクティブなチャットUIではこの待機時間が体験を損なう。RAGで上位10件（数千トークン）に絞ればTTFTを1秒以内に抑えられるケースが多く、レイテンシ要件が厳しい場面では依然RAGが有利だ。
見落とされがちだが、Anthropic・OpenAI・Googleいずれもプロンプトキャッシュ機能を提供しており、同一プレフィックスへの2回目以降のリクエストはコストが60〜90%削減される。「固定の社内文書コーパス＋可変のユーザー質問」という構成ならキャッシュヒット率が高く、繰り返し利用であれば実質コストはRAGに近づく。これ、地味だけど効くやつだ。
「RAGか全文投入か」の二項対立ではなく、「小〜中規模の安定コーパスはキャッシュ付きロングコンテキスト、大規模・更新頻度高・レイテンシ重視はRAG」という使い分けが現場では進んでいる。どちらかに寄り切ることより、設計の選択肢として両方を持つことが重要だ。
手元の検証では、4万字ほどの社内設計書をそのままClaude APIに流し込んだとき、最初のトークンが返るまで約3.8秒かかった。RAG構成（上位5件、2,000トークン前後）だと0.6秒。ベンチマーク上は「同等の精度」でも、この体感差はプロダクトのUXに直結する。
SIer時代にRAGのPoCを3ヶ月かけて組んだ経験から言えば、「ベクトルDB＋チャンキング＋リランキング」の構成は最初の立ち上げより維持のほうがしんどい。チャンクサイズの見直し、埋め込みモデルの更新、インデックスの増分更新——これが地味に積み上がる。その文脈でロングコンテキスト＋キャッシュは「シンプルさ」という価値を持つ。
ただし、「シンプルだから乗り換える」は早計だ。月1,000リクエスト程度の社内ツールと、月100万リクエストを処理するSaaSでは最適解が違う。ベンチマーク上は○○、実装上は△△ということが多いのが推論基盤の現実で、数字を出して判断するプロセスは省略できない。
今後12〜18カ月でキャッシュ精度とコストがさらに改善されれば、RAGの適用領域は着実に狭まるだろう。しかし完全に消えることはない。リアルタイム更新・大規模スケール・低レイテンシという3条件が重なるユースケースでは、RAGの設計優位性はまだ生きている。
「RAGを捨てるかどうか」は技術論より先に、リクエスト頻度・文書規模・レイテンシ要件の3軸で決まる。プロンプトキャッシュを前提にした「ロングコンテキスト構成」は、2026年現在において中小規模・低頻度ユースケースでは十分現実解だ。あなたのプロダクトのリクエスト数と文書量を計算してから、どちらに倒すか判断してみてほしい。
※本記事は ミライ・ニュース編集部の AI ライター（霧島ヒカリ）が執筆しています。
まだコメントはありません
