長いコンテキストとRAGを混ぜる前に分ける情報¶

対象 / ポイント

対象: RAGや長いコンテキストを業務に入れたいが、検索コスト、遅さ、資料分割で迷っている実務者。

ポイント:

RAGと長いコンテキストは、どちらを選ぶかではなく、どの情報をどこに置くかで決める。
毎回変わる情報はRAG、少数で読み切る情報は長いコンテキスト、何度も使う固定情報はキャッシュに寄せる。
混ぜる前に情報を3分類すると、遅さ、引用漏れ、不要なチャンク分割を減らしやすい。

公開日: 2026-06-26

会議の議事録、製品マニュアル、規程PDF、FAQ、問い合わせ履歴を、まとめてLLMに読ませたい。このとき設計が荒いと、すぐに「RAGにするか、長いコンテキストに全部入れるか」という二択になる。

その二択は早すぎる。先に分けるべきなのは技術ではなく、情報の性質である。毎回探す情報、今回だけ全文で読む情報、何度も同じ形で使う情報は、同じ置き場に入れるべきではない。

まず3つの置き場に分ける¶

RAGは、モデルが回答する前に外部知識を取得し、その取得結果を文脈として渡す設計である。 Microsoft LearnはRAGを、取得した文脈をユーザーの質問と一緒にプロンプトへ追加し、言語モデルに回答を生成させるパターンとして説明している。¹

一方、長いコンテキストは、検索せずに大量の入力をそのままモデルへ渡す設計に近い。 GoogleのGemini API資料は、長いコンテキストを 100万トークン以上のコンテキストウィンドウで実現できる作業として説明し、モデルが参照できる短期記憶のようなものとして位置づける。²

キャッシュは、その中間にある。 AnthropicのPrompt cachingは、同じ接頭辞を持つプロンプトを再利用し、繰り返しタスクの処理時間とコストを下げる用途として説明されている。³

設計時は、この3つを次の表で分ける。

情報の性質	置き場	典型例	失敗しやすい使い方
大量で、質問ごとに必要箇所が変わる	RAG	社内Wiki、FAQ、仕様書群、問い合わせ履歴	全文投入して毎回コストと遅さを増やす
少数で、今回の判断に全文の流れが必要	長いコンテキスト	1本の契約書、1回分の議事録、設計レビュー資料	無理に細かくチャンク化して文脈を壊す
何度も使い、内容がしばらく変わらない	キャッシュ	システム方針、評価ルーブリック、長い製品仕様	毎回同じ長文を新規入力として支払う

RAG、長いコンテキスト、キャッシュは排他関係ではない。同じ業務アプリケーションの中で、3つを別の層として使う方が自然である。

RAGに残す情報¶

RAGに向くのは、質問ごとに必要箇所が変わる情報だ。人事FAQ、製品仕様、障害履歴、ナレッジベースのように、全体は大きいが回答に使う部分は限られる資料群である。

RAGの強みは、必要な断片だけを取り出せる点にある。 Microsoft Learnの説明でも、RAGは取得した文脈をプロンプトに追加し、モデルがその文脈を使って回答を生成する流れとして示されている。¹

ただし、RAGは「検索できるように整える」工程を要求する。 MicrosoftのRAG設計ガイドは、RAGの構成自体は単純でも、設計、実験、評価には厳密なアプローチが必要だと説明している。⁴ 実務では、チャンク分割、メタデータ、埋め込みモデル、再ランキング、権限フィルタのどこかが弱いと、必要な根拠が上位に来ない。

RAGに残す判断基準は単純だ。

全資料を毎回読むと重い。
質問ごとに必要な資料が変わる。
更新が継続的に入る。
回答に引用や根拠位置が必要になる。

この4つが揃うなら、長いコンテキストよりRAG側に置く。

長いコンテキストに入れる情報¶

長いコンテキストに向くのは、全文の流れが答えを左右する少数の資料だ。契約書1本の例外条項、議事録1回分の意思決定、設計レビュー資料の前提と結論のように、局所的な類似検索だけでは判断しにくい情報である。

長いコンテキストの価値は、分割しないことにある。 Googleは長いコンテキストのユースケースとして、大量の非構造データや文書、動画、コードの理解を挙げる。² これは、検索結果を数個に絞るより、資料全体の構造を一度に読ませる方が自然な場面を示している。

一方で、長く入れれば常に良くなるわけではない。 AnthropicのContext windows資料は、コンテキストが増えるほど精度や想起が劣化する現象を指摘する。単純に多く入れることが自動的な改善ではない、という説明である。⁵

長いコンテキストに入れる判断基準は次の通りだ。

対象資料が少数である。
途中の文脈、順序、例外が重要である。
断片検索より全文読解の方が妥当である。
回答が一度きり、または低頻度である。

この条件なら、先にRAG化するより全文投入を試す価値がある。

キャッシュに逃がす情報¶

キャッシュに向くのは、長いが安定しており、何度も同じ形で使う情報だ。たとえば、エージェントの行動規約、記事品質ルーブリック、社内用語集、製品の共通制約、出力フォーマットが該当する。

これらを毎回RAGで検索すると、検索の揺れが入る。毎回全文で渡すと、同じ入力に何度もコストを払う。キャッシュは、この反復部分を別扱いにするための置き場である。

AnthropicのPrompt caching資料は、安定した要素を含む反復タスクで処理時間とコストを下げる用途を示している。³ GoogleのContext caching資料も、同じ入力トークンを繰り返しモデルに渡す典型的なAIワークフローで、パフォーマンスとコスト最適化に使うものとして説明している。⁶

キャッシュに置く判断基準は次の通りだ。

何度も同じ内容を使う。
内容が頻繁には変わらない。
検索で揺らしたくない。
入力が長く、再送コストが目立つ。

ここに入る情報をRAGに混ぜると、検索対象が汚れる。長いコンテキストに混ぜると、毎回の入力が太る。キャッシュは「知識検索」ではなく「毎回使う土台」の置き場である。

混ぜる前のチェックリスト¶

RAGと長いコンテキストを併用する場合、最初の設計レビューでは次の順で見る。

資料を分類する。 すべての資料に、検索、全文、キャッシュのラベルを付ける。
検索対象を削る。 毎回固定で使うルーブリックや方針は、RAGの検索対象から外す。
全文投入の対象を絞る。 1本の資料として読む意味があるものだけを長いコンテキストに入れる。
RAGの評価クエリを作る。 MicrosoftはRAG評価で、取得データ、文脈、回答の妥当性を複数指標で見る考え方を示している。⁷
失敗時の逃げ道を決める。 検索漏れならRAG改善、全文で遅いなら要約またはキャッシュ、キャッシュが古いなら更新ルールを直す。

実装前にこの表がないなら、まだRAGか長いコンテキストかを選ぶ段階ではない。先に情報の交通整理をする方が、後のチューニングが少なくなる。

よくある誤解¶

長いコンテキストがあればRAGは不要か¶

不要ではない。長いコンテキストは、今回読む量を増やす技術である。 RAGは、どの情報を読むべきかを選ぶ技術である。

資料群が常に小さく、毎回全文を読めるならRAGは過剰になり得る。しかし、資料が増え、更新され、権限が分かれ、引用が必要になると、検索と選別の層は残る。

RAGにすれば全文読解は不要か¶

不要ではない。チャンク化は便利だが、文脈を切る。 Microsoftのチャンク分割資料も、小さすぎるチャンクは問い合わせに答える十分な文脈を含めず、関連文脈が複数チャンクにまたがる場合に捕捉できない可能性を説明している。⁸

契約、議事録、設計判断のように順序と例外が重要な資料は、検索上位だけでは判断が崩れる。 RAGで候補資料を絞り、その後に対象資料を長いコンテキストで読む設計もあり得る。

キャッシュはRAGの代わりか¶

代わりではない。キャッシュは情報取得ではなく、反復入力の再利用である。検索したい情報をキャッシュに置くのではなく、毎回変わらない方針や出力契約を置く。

まとめ¶

RAGと長いコンテキストを混ぜる前に、情報を3つに分ける。

質問ごとに必要箇所が変わる情報はRAG。
少数で全文の流れが重要な情報は長いコンテキスト。
何度も同じ形で使う固定情報はキャッシュ。

この分類を先に置くと、RAG不要論にも、長文万能論にも振り回されにくい。設計判断は「どの技術が強いか」ではなく、「どの情報を、いつ、どの形で文脈に入れるか」で決まる。