RAG vs ロングコンテキスト：全部渡す方式は本当に安いのか

コンテキストウィンドウが100万トークンに達したとき、「もう検索は要らない。全部プロンプトに入れればいい」という見方が広がりました。RAGは死んだ、という主張です。

2年経った現在、そうはなっていません。この記事では、なぜそうならなかったのかを実際の円建て単価で計算して確かめます。

コスト：1リクエストあたり200倍

まず前提を置きます。

• 全部渡す方式 — 毎リクエスト100万トークンの資料をプロンプトに入れる
• RAG方式 — 検索で絞り、5,000トークンだけ入れる（資料数件＋質問）

FastMetalの円建ての入力単価（2026年8月時点）で、1リクエストあたりの入力コストを計算するとこうなります。

倍率が一律200倍なのは当然で、1,000,000 ÷ 5,000 = 200 だからです。入力トークンは線形に課金されるので、渡す量の比がそのままコストの比になります。

重要なのは倍率より絶対額です。Claude Sonnet 5 で全部渡す方式を選ぶと、質問1回あたり357円かかります。1日100問で35,700円、月に100万円を超えます。同じことをRAGでやれば月5,400円です。

（最新の単価は料金ページで確認してください。上の計算はそこから引いた値です。）

プロンプトキャッシュを使えば？

「同じ資料を毎回渡すならキャッシュが効くはずだ」という反論は正当です。実際に効きます。

多くのモデルでキャッシュ読み出しは入力単価の1/10（一部は1/5）に設定されています。これを効かせた場合を加えます。

200倍が20倍まで縮みます。大きな改善ですが、まだ1桁以上の差があります。 そしてキャッシュには条件が付きます。

• 資料が固定されている必要があります。 1文字でも変えればキャッシュは無効になり、全額かかります
• 有効期限があります。 アクセスが途切れれば作り直しで、書き込みは読み出しより高くつきます
• 利用者ごとに資料が違う用途では効きません。 顧客Aの資料と顧客Bの資料は別のキャッシュです

「全社共通のマニュアル1冊にみんなが質問する」ならキャッシュは強力に効きます。「顧客ごとの契約書に答える」なら、ほぼ効きません。

精度：長くすれば良くなるわけではない

コスト以上に効くのが精度です。長いコンテキストの真ん中に置かれた情報は、モデルが見落としやすいという現象が知られています（lost in the middle）。先頭と末尾は拾われやすく、中間が弱くなります。

つまり100万トークンを渡すことは、「100万トークンぶんの理解」を意味しません。関係のない990,000トークンは、正解を薄めるノイズとして働きます。

RAGが精度で有利になるのはここです。検索で絞るという工程は、コスト削減の手段であると同時に、モデルに雑音を渡さないための前処理でもあります。

規模：そもそも入らない

もっと単純な壁もあります。100万トークンは日本語でおよそ数十万字です。

• 社内Wikiの全ページ — 入りません
• 数年分の問い合わせ履歴 — 入りません
• 製品ドキュメント全体＋過去の議事録 — 入りません

コンテキストウィンドウが10倍になっても、企業の文書量はそれ以上にあります。「全部入れる」が成立するのは、資料が最初から小さい場合だけです。

レイテンシ

100万トークンを読ませれば、最初のトークンが返るまでの時間も伸びます。対話型のUIでは体感差が大きく、キャッシュが効いていても入力の読み込みはゼロにはなりません。

ロングコンテキストが勝つ場面

公平に書くと、全部渡す方式が正解のケースは確実にあります。

• 資料が小さい — 数万トークンに収まるなら、検索基盤を組む手間のほうが高くつきます
• 一度きりの分析 — 1本の契約書、1冊の仕様書を読ませる。パイプラインを作る理由がありません
• 見落としが許されない — 「この文書のどこかにある条件を全部挙げて」のように、網羅性が要る場合。検索は拾い漏らしますが、全部渡せば漏れません
• 文書全体の構造を理解させたい — 要約や、章をまたぐ論旨の整理

「小さい・一度きり・網羅性が要る」ならロングコンテキスト、というのが実務的な線引きです。

現実的な答えはハイブリッド

現在の実装で主流になっているのは、どちらか一方ではなく組み合わせです。

1. 検索で候補を広めに拾う（20〜50件）
2. 再ランクで絞る（5〜10件）
3. 絞った資料を、長いコンテキストのモデルに渡して考えさせる

ロングコンテキストの価値は「全部入れられること」ではなく、 「絞り込みを雑にしても耐えること」 にあります。かつては上位3件まで絞らないと入りませんでしたが、いまは20件渡しても収まります。検索の精度に対する要求が下がった、という形でロングコンテキストは効いています。

つまりロングコンテキストはRAGを殺したのではなく、RAGを楽にしました。 検索工程は消えるどころか、前段として残っています。

判断の順序

1. 資料は何トークンか測る — 数万トークンで収まるなら、そのまま渡してください。RAGを組む必要はありません
2. 利用者ごとに資料が変わるか — 変わるならキャッシュは効きません。コスト差は200倍で計算してください
3. 網羅性が要るか — 要るなら検索は危険です。全部渡すか、検索の再現率を測ってください
4. どちらでも良さそうなら、まず全部渡す方式で作る — 動くものを先に作り、コストか精度が問題になってから検索を足すほうが速い

4番目が実務的には重要です。最初からRAGを組むのは、多くの場合オーバーエンジニアリングです。 全部渡す方式で試作し、実際にコストか精度の壁に当たってからRAGに移行してください。

よくある質問

Q. ロングコンテキストのモデルが出たので、RAGはもう不要ですか？ 不要にはなっていません。資料が数万トークンに収まるなら全部渡すほうが簡単ですが、量が増えるとコスト（1リクエストあたり最大200倍）と精度（中間の情報が見落とされる）の両面で成立しなくなります。

Q. プロンプトキャッシュを使えばコスト差はなくなりますか？ なくなりません。200倍が20倍程度まで縮みますが、1桁以上の差は残ります。しかも資料が固定されている必要があり、利用者ごとに資料が変わる用途では効きません。

Q. 100万トークン渡せば、その全部を理解してくれますか？ 理解の質は一様ではありません。長いコンテキストの中間に置かれた情報は見落とされやすいことが知られており、無関係な部分はノイズとして働きます。

Q. どちらから作り始めるべきですか？ まず全部渡す方式です。資料が小さいうちはそれで足り、実際にコストか精度の壁に当たってから検索を足すほうが速く進みます。

まとめ

「全部渡せばいい」は、資料が小さいうちは正しく、大きくなるとコストで約200倍（キャッシュを効かせても約20倍）、精度でも不利になります。ロングコンテキストはRAGを置き換えたのではなく、絞り込みを雑にしても耐えるようにしたという形で効いています。

判断は資料のトークン数を測るところから始めてください。生成側はモデルカタログと料金ページから選べます。仕組みの全体像はRAGとは、その中核部品はEmbeddingとはにまとめました。