Context Rot、RAG、ロングコンテキスト:2026年のLLMシステム設計指針

2Mトークンウィンドウが意味を失った年

2024年後半から2025年前半にかけて約半年間、エンジニアリングのSlackチャンネルではある馴染みの主張が飛び交っていました。「RAGはもう古い。全部プロンプトに貼ればいい」というものです。

その理屈は一見クリーンに聞こえました。AnthropicはClaude Sonnetを1Mトークンのコンテキストウィンドウで提供しました。GoogleはGemini 2.5および2.5 Proを2Mトークンまで拡張しました。MetaはLlama 4 Scoutを理論上10Mトークンまで対応すると発表しました。ナレッジベースがプロンプト1回に収まるなら、ベクターストアや埋め込みパイプライン、チャンク戦略を頑張る必要があるのか、という発想です。

そして2025年7月、Chroma Researchが「Context Rot: How Increasing Input Tokens Impacts LLM Performance」をKelly Hong、Anton Troynikov、Jeff Huberの共著で公開しました。論文は18種のフロンティアモデルで丁寧な実験を行い、マーケティングページが言わないことを示しました。ロングコンテキストウィンドウは、上限に達するはるか手前で自明でない形で劣化するという事実です。200Kトークン対応のウィンドウでも、入力50Kトークン時点で深刻な精度低下が出ることがあります。1Mトークン対応のウィンドウは、1Mトークン全体にわたって信頼できる推論ができるわけではありません。

この結果はアーキテクチャをめぐる議論の枠組みを変えました。RAGは時代遅れではありません。ロングコンテキストはタダ飯ではありません。本当に面白い問いは「どちらが勝つか」ではなく、「このデータ形状、レイテンシ予算、鮮度要件に合うパターンはどれか」になりました。

本稿はそのアーキテクチャレベルでの答えです。いつ検索すべきか、いつ全部投げ込むべきか、いつ両方やるべきかを整理します。

---

Chroma論文が実際に示したもの

Chromaの論文は見出し(「コンテキストロットは存在する」)が示すよりずっと豊かな内容を持っているので、丁寧に読む価値があります。チームはGPT-4.1、Opus 4とSonnet 4を含むClaude 4ファミリー、Gemini 2.5、Qwen3を対象に、needle-in-a-haystack(NIAH)ベンチマークの拡張版を実行しました。GitHubに公開された再現キットを使えば、自分の手元でも追試できます。

特に目を引く発見が3つあります。

Finding 1:入力長が増えるにつれて性能は一様ではない形で劣化する。 これが中核となる結果です。モデルは入力が長くなるにつれてゆっくり予測可能に悪化するわけではありません。崖のように落ちます。あるモデルは32Kでは問題なくても64Kで崩壊し、別のモデルは突然崩壊するまで持ちこたえます。文書化されたコンテキストウィンドウの大きさは、そのコンテキストを実際にどれだけうまく使えるかとは弱い相関しかありません。

Finding 2:劣化を駆動するのは長さよりも意味的類似度。 「ニードル」が周囲の「ヘイスタック」と意味的に明確に異なるとき、モデルはそれを正しく見つけられます。回答と意味的に似たディストラクタが混ざると精度は急激に落ち、長さが伸びるほどその落ち幅は悪化します。言い換えれば、回答とノイズを区別しにくいほどロングコンテキストは速く崩れます。これはLiu et al. (2024)、TACL掲載の「Lost in the Middle: How Language Models Use Long Contexts」が示したU字型の性能カーブと整合しており、ロングコンテキストの中央が体系的に軽視される傾向と一致します。

Finding 3(意外な結果):構造化された一貫性のあるテキストは、シャッフルされたテキストよりもアテンションを「より」劣化させる。 これはエンジニアの考え方を変えるべき発見です。直感的には、整理された100Kトークンのドキュメントの方が、ごちゃ混ぜの100Kトークンの塊よりもモデルは扱いやすいはずでした。データは逆を、あるいは少なくとも「常に逆ではないとは限らない」ことを示します。一貫性のあるテキストは長いシーケンス全体にアテンションを拡散的に薄く広げるのに対し、シャッフルされたテキストの方がモデルが掴みやすい局所的なシグナルを生むようです。含意は明確で、整ったきれいなPDFをモデルに渡すことは、雑然とした検索結果セットを渡すことより自動的に安全とは限らない、ということです。

Sequential-NIAHベンチマーク(arXiv 2504.04713)はこれをさらに拡張し、長いコンテキスト内の異なる場所から複数回の検索を連鎖できるかを試験しています。距離をまたいだ多段推論では、劣化はさらに急峻になります。

Hamel Husainはコンテキストロットに関するノートの中で、その実践的な含意をうまくまとめています。エンジニアリングの構えは「全部詰め込む」ではなく「質問に答えるのに最小かつ最も関連性の高いコンテキストをモデルに渡す」であるべきだ、と。

---

ロングコンテキストが失敗する仕組み

メカニズムを理解することは、どのワークロードが失敗するかを予測する助けになるので重要です。

標準的なTransformerのアテンションは、すべてのトークンペアに対してsoftmaxを取ります。シーケンス長Nが伸びると、アテンションの重みはより多くの位置に分散します。RoPE(rotary position embeddings)やALiBiのような相対位置エンコーディングを使っても、softmaxの分母は大きくなり、ある単一トークンに割り当てられる重みは小さくなります。1Mトークンの時点では、「正しい」トークンは有限のアテンション予算をめぐって他の999,999トークンと競争することになります。

位置エンコーディングは助けにはなりますが、魔法ではありません。RoPEは学習長を大きく超えて外挿するときに既知の劣化カーブを示します。32Kトークンまでで学習されたモデルを1Mトークンで運用するということは、根底の数学が完全には支えていない外挿を行っているということです。YaRN、位置補間、NTK対応スケーリングなどのトリックは使える範囲を伸ばしますが、1Mトークンを32Kトークンと同じ効率で扱えるモデルを生み出すものはありません。

学習データの問題もあります。たとえモデルが長いシーケンスで学習されていても、800Kトークン横断の推論を必要とする例は希少です。モデルは、学習データが使い方を教えた部分のコンテキストの使い方を学ぶに過ぎません。

コンテキストロットは次のリリースで直るバグではありません。アーキテクチャと学習分布の性質です。将来のモデルは限界をさらに押し広げるでしょうが、当面は基本的なパターンは続きます。

---

RAGが今でも勝つ領域

コンテキストロットを踏まえると、retrieval-augmented generationはレガシーインフラではありません。2026年でも勝ち続ける領域を以下に挙げます。

大規模なマルチドキュメントコーパス。 ナレッジベースが50,000ドキュメント・合計500Mトークンであれば、どのコンテキストウィンドウにも収まりません。検索が唯一現実的なアーキテクチャです。

鮮度と新しさ。 ベクターストアは増分更新できます。一方ロングコンテキストプロンプトは、内容が変わるたびにプロンプトを丸ごと組み直す必要があります。1時間単位で更新される文書(ニュース、カタログ、サポートチケット、コードリポジトリ)では、検索は変更を安価に処理します。

コスト。 推論コストは入力トークンに対してほぼ線形に増えます。200Kトークン送れば1Kトークン送る場合の200倍かかります。クエリの95%が5Kトークンの関連コンテキストで答えられるなら、検索は精度を落とさず40倍のコスト削減になります。

引用と出典。 検索は、表示・リンク・ランク付けできる出典ドキュメントの構造化されたリストを返してくれます。ロングコンテキストの出力は、追加の引用抽出パイプラインを足さない限り、特定のソースに紐付けるのが難しくなります。

アクセス制御とテナンシー。 コーパスにユーザーごと・テナントごと・ロールごとの可視性があるなら、全部突っ込むことはできません。検索はモデルにデータを見せる前にアクセスポリシーでフィルタします。B2Bプロダクトでは譲れません。

複数コーパス横断の推論。 答えがSlackメッセージ、Notionページ、Linearイシュー、GitHub PRを組み合わせる場合、橋渡し役は検索です。

これらのいずれかに当てはまる製品なら、RAGはオプションではありません。問いは「検索をやるかどうか」ではなく「検索をどう良くするか」になります。

---

ロングコンテキストが勝つ領域

ロングコンテキストが正解であるワークロードもあります。

単一ドキュメントの深い推論。 100ページの法務契約書を読み、条項をまたいで質問に答える。研究論文を分析する。決算カンファレンスを要約する。80ページ離れた2つの段落をつなぐ必要があるとき、検索はその接続をしばしば切ってしまいます。ロングコンテキストはそれを保ちます。

リポジトリ内のコード理解。 多くのコード推論タスクは、import、型、定義、呼び出し箇所を同時に必要とします。ファイル単位でチャンク分割するとファイル間の関係性が失われます。リポジトリ全体をコンテキストに入れ(収まるなら)、構造を保てます。

会話の連続性。 長時間動作するエージェントセッションは、フル履歴をコンテキストに持つことで恩恵を受けます。会話履歴に対する検索は脆く、必要なのは直近50ターンであって意味的に似た50ターンではないことが多いのです。

クエリが事前に決まらない探索的推論。 ドキュメントについて何を問うかが、推論を始めるまで決まらないことがあります。その場合は検索を使いにくくなります。クエリを事前に書けないからです。ロングコンテキストならモデルが資料を「ブラウズ」できます。

一貫した単位内のクロスリファレンス。 教科書の章、研究論文、法的書面はいずれも論理的に統合された単位です。チャンクして組み直すと、論証構造が失われることがよくあります。

ざっくりとしたヒューリスティック:データが1つの論理的ドキュメントで、それがコンテキストに収まるなら、ロングコンテキストの方がよりクリーンなアーキテクチャです。

---

実際に動くハイブリッド構成

本気のLLMシステムにおける2026年のデフォルトは、純粋なRAGでも純粋なロングコンテキストでもありません。ハイブリッドです。実質的だが上限つきのトークン集合を検索で取り出し、その上にロングコンテキスト推論をかけます。

正典フローはこうなります。

User query
   |
   v
[Retrieval Stage]
   - Vector search (top 100 chunks)
   - Optional keyword/BM25 search merged in (hybrid retrieval)
   - Optional reranker (cross-encoder over top 100, keep top 30)
   |
   v
[Assembly Stage]
   - Concatenate retrieved chunks
   - Add metadata, source headers, structural hints
   - Target total: 50K to 200K tokens
   |
   v
[Long-Context Reasoning Stage]
   - Send to frontier model with reasoning prompt
   - Model uses the full retrieval set as its context
   |
   v
Answer + citations

なぜこれが機能するか:各ステージが他方の失敗モードを補うからです。検索は、どのコンテキストウィンドウにも収まらない巨大コーパスを扱える集合まで絞り込みます。検索結果セットの上にかけるロングコンテキスト推論は、上位5チャンクだけ送ったときに純粋なRAGがしばしば壊してしまう、複数ドキュメント・複数チャンクにまたがる推論を取り戻します。

エンジニアリング上の鍵となる決定は、検索集合のサイズです。トークンが少なすぎるとロングコンテキストの利点を失います(古典的なtop-5 RAGと変わらなくなります)。多すぎるとコンテキストロットを引き起こします。Chromaのデータが示すのは、安全な上限はモデルの文書化された上限よりかなり下、しばしば4〜10分の1だということです。200Kウィンドウのモデルなら通常40K〜80Kまではしっかり動きます。1Mウィンドウのモデルなら、ロットを最小限に抑えつつ150K〜300Kまで扱えることが多いです。

これは2025年後半までに、規模感のあるLLM機能を出荷している多くのチームが収束したアーキテクチャパターンです。華やかではありませんが、動きます。

---

ハイブリッドのチューニング:数値とヒューリスティック

ダイヤルに数値を当てておきます。普遍の真理ではなく、多くのチームが本番で機能している出発点です。

チャンクサイズ。 散文なら1チャンクあたり500〜1,500トークン。コードなら関数単位や論理ブロック単位で200〜500。法務や学術のように1チャンク内の文脈が重要な場合は1,500〜3,000。チャンクは10〜20%オーバーラップさせます。

Top-k検索。 送るつもりより多めに引きます。top 50〜200で取得し、リランクします。リランカー(cross-encoder、Cohere Rerankやファインチューニング済みBGE rerankerのような小型の専用モデルがよく使われます)は埋め込みモデルよりペアあたりコストが高いものの、細かな関連度判定で圧倒的に精度が高いです。

リランク→コンテキスト比。 リランク後、ロングコンテキスト段に渡すのはtop 20〜100チャンク。正確な数はチャンクサイズと安全コンテキスト予算に依存します。

ハイブリッド検索。 密(ベクター)と疎(BM25、SPLADE)の検索をreciprocal rank fusionで組み合わせます。純粋な密は完全一致クエリ(SKU、エラーコード、固有名詞)を取り逃がします。純粋な疎はパラフレーズを取り逃がします。ハイブリッドは両方拾います。

安全コンテキスト予算。 自分のモデルで測定してください。複数チャンクをまたぐ推論を要する質問の小さな評価セットを作り、コンテキスト長を変えながら入力16K、32K、64K、128K、256Kで精度を測ります。精度が許容範囲内に収まる最大のサイズを採用します。それがあなたの安全予算です。本番ではそこからさらに20%引いた値で運用し、ヘッドルームを残します。

検索を完全にバイパスする。 「いまアップロードしたドキュメントを要約して」は単一ドキュメントタスクです。こうしたクエリを小さな分類器で検出し、検索をスキップします。レイテンシ削減になり、無関係なノイズを表面化させずに済みます。

要約レイヤー。 きわめて長い履歴(数ヶ月にわたる会話、巨大なコードベース)の場合は、組み立て前に古い素材を圧縮する要約ステップを挟みます。要約自体もトークンコストがかかるので、本当に役に立つかは測定してください。

トレードオフを整理した比較表は以下のとおりです。

---

エンジニアが繰り返し出してしまうアンチパターン

繰り返し発生する罠をいくつか挙げておきます。

「とにかく全部コンテキストに入れる」。 ウィンドウが倍になるリリースのたびに誘惑されます。Chromaのデータは、それが静かに劣化することを示しています。スポットチェックは通っても、横断的推論を必要とする本番クエリで失敗します。リリース前には必ず目標コンテキストサイズでの評価を回してください。

「常にRAGを使う」。 あらゆるワークロードに反射的にRAGを当てると、単一ドキュメントケースを取り逃がします。50ページのPDFをベクターインデックスに入れてtop-5チャンクを引いてくる方が、PDF丸ごとをモデルに渡すより悪い答えになることが普通です。ヒューリスティック:単一ドキュメントが安全コンテキスト予算に収まり、クエリがそのドキュメントについてのものなら、検索はスキップします。

「検索集合のトークン数を無視する」。 top-kを「収まるだけ」に設定したチームが3ヶ月後に、平均プロンプトが350Kトークンになっていて精度が静かに落ちていた、と気づきます。組み立て後のコンテキストサイズはファーストクラスのメトリクスとして追跡してください。アラートを張ります。

「文書化されたウィンドウを信じる」。 1Mトークンのウィンドウは、モデルが1Mトークン全体を等しくうまく使えることを意味しません。文書化された上限は技術的に送れるサイズです。使える上限は、モデルが品質基準を保てる範囲です。両者は別の数字で、しばしば桁が違います。

「モデルが優秀になったから評価は不要」。 フロンティアモデルのアップグレードは最適なアーキテクチャ選択を変えます。GPT-4-32KではRAGが必要だったワークロードが、Gemini 2.5 Proのロングコンテキストでうまくいくこともあります。モデルが変わったら再評価してください。

---

2026年のハードウェアが変えること

大きなウィンドウはいくつかの意思決定を実際に変えます。どれが変わるかを具体的に押さえる価値があります。

Llama 4 Scoutの10Mトークン。 使える実効コンテキストが文書化上限の半分だとしても、中規模コーパス丸ごとがプロンプト1回に収まります。1Mトークンの社内ナレッジベース上で動くシングルテナントアシスタントは検索をスキップできます。ただし経済性は別問題で、フロンティアモデルへの5Mトークン入力はクエリあたりが高価です。

Gemini 2.5 / 3 Proの2Mトークン。 プロンプトキャッシュ付きの2Mウィンドウは、同じ大規模ドキュメントセットに繰り返しクエリするワークフローの計算式を変えます。1.5Mトークンの背景コンテキストをキャッシュし、追加分のクエリだけに課金される構造になると、クエリあたりコストは検索と競争できる水準になり始めます。

Claude Sonnet 1M。 セッション状態が大きく膨らむエージェント型ワークロードで有用です。これまで自分の履歴を要約またはRAGで扱う必要があった会話エージェントが、生の履歴をより多くコンテキストに保持できるようになります。

ベンダー横断のプロンプトキャッシュ。 Anthropic、Google、OpenAIの3社とも入力キャッシュをサポートしています。安定したコンテンツに対する繰り返しクエリでは、ロングコンテキストアーキテクチャの料金がずっと安くなります。RAGのコスト優位はキャッシュが効いてくると縮みますが、消えるわけではありません。

変わっていないこと:コンテキストロットです。これらのリリースのいずれも、ウィンドウが大きくなればロット問題が解決すると示すベンチマークデータを伴っていません。ウィンドウが大きくなると天井は上がりますが、同じ形の劣化は残ります。安全予算は引き続き測定する必要があります。新鮮で、マルチテナント、マルチソースのワークロードには検索が引き続き必要です。デフォルトはハイブリッドです。

---

実際に適用できる意思決定フレームワーク

新しいLLM機能に対して上から下まで適用できるフローを示します。

ステップ1:コーパスの規模はどれくらいか?

• 合計100Kトークン未満:検索をスキップし、ロングコンテキストを直接使う。
• 100K〜1Mトークン:鮮度次第(ステップ2へ)。
• 1Mトークン超:検索は必須。

ステップ2:データはどれだけ新鮮である必要があるか?

• 1時間ごと以上に更新:検索。ロングコンテキストプロンプトは再構築に高くつきすぎます。
• 日次〜週次の更新:どちらのパターンでも機能します。
• 静的またはほぼ更新なし:プロンプトキャッシュつきのロングコンテキストが安くてクリーン。

ステップ3:クエリ形状はどうか?

• 単一ドキュメントの深い推論:ロングコンテキスト寄り。
• 複数ドキュメントの統合:ハイブリッド寄り。
• ルックアップや事実検索:古典的RAG(top-k、小さいコンテキスト)寄り。
• 探索的・オープンエンド:ドキュメント集合が有界ならロングコンテキスト、そうでなければハイブリッド。

ステップ4:引用やアクセス制御は必要か?

• どちらか1つでもYes:検索が必要(古典RAGまたはハイブリッド)。ロングコンテキストのみのアーキテクチャに後から引用やユーザーごとのフィルタを足すのは非常に難しいです。

ステップ5:レイテンシ予算はどれくらいか?

• 1秒未満:古典RAG(小さなコンテキスト、高速)。
• 1〜5秒:ハイブリッドが現実的。
• 5秒超:どのパターンでも機能します。

ステップ6:長いクエリでの精度フロアはどこか?

• 50K以上のトークンをまたぐ多段推論で高精度:リランカーつきハイブリッド。
• ベストエフォート:古典RAGで通常十分。

この6ステップを踏むと、古典top-k RAG、純粋ロングコンテキスト、ハイブリッドの3つのアーキテクチャのどれかに着地します。本気のワークロードの本番システムは多くがハイブリッドに落ち着きます。ハイブリッドが普遍的に優れているからではなく、現実のワークロードには通常、純粋ロングコンテキストを壊す制約(マルチテナント、鮮度、コスト、引用)が少なくとも1つ、純粋top-k RAGを壊す制約(単一ドキュメント推論、横断クエリ、探索)が少なくとも1つあるからです。

Chromaの論文は議論を変えました。あとから振り返ると、ロングコンテキスト対RAGの論争は少し気恥ずかしく感じるほどです。両者は競合関係ではなく、動くLLMスタックを構成する3つの要素のうちの2つで、3つめのリランクこそがハイブリッドを安定化させます。

---

よくある質問

Geminiの2MコンテキストウィンドウはRAGを殺しましたか?

いいえ。2Mトークンのウィンドウは現実ですが、Chromaの「Context Rot」論文は、ウィンドウが埋まるはるか前に性能が劣化することを示しました。2Mウィンドウのモデルにおける高精度ワークロード向けの実用的な安全予算は、150K〜400Kトークン程度に落ち着くことが多く、宣伝されている上限よりずっと少ないです。RAG(あるいは取得してから推論するハイブリッドパターン)は、大規模・マルチドキュメント・新鮮・マルチテナントなコーパスに対して引き続き正しいアーキテクチャです。

コンテキストロットを平たく言うと?

コンテキストロットとは、LLMがロングコンテキストをマーケティング資料が示唆するほどうまく使えない、という観察です。トークンを多く与えるほど、検索や推論タスクの精度は非線形に劣化します。回答と意味的に類似したディストラクタが混ざるとさらに早く悪化し、一貫性のある整理された入力でさえシャッフルされた入力よりアテンションを傷つけることがあります。結果として、1Mトークンのウィンドウを埋めても1Mトークン品質の答えが返ってくるわけではありません。

コンテキストロットが始まるまで、検索集合はどれくらい大きくしてよいですか?

自分の使うモデルでテストしてください。ざっくりの出発点として、高精度ワークロードでは文書化されたコンテキストウィンドウの20〜40%にとどめます。200Kウィンドウのモデルなら40K〜80Kトークンの検索結果、1Mウィンドウなら200K〜400Kです。多段推論クエリの小さな評価セットを作り、コンテキストサイズを変えながら精度を測ります。精度が品質レンジに収まる最大サイズを採用します。

プロンプトキャッシュは計算式を変えますか?

はい、意味のある形で変えます。プロンプトキャッシュ(Anthropic、Google、OpenAIで利用可能)は、安定したコンテンツに対するロングコンテキストクエリの限界コストを大きく下げます。大きな背景ドキュメントセットをキャッシュし、クエリあたりの差分だけに課金されるようにできるなら、静的に近いコーパスではロングコンテキストが経済的に検索と競争できるようになります。ただしキャッシュはコンテキストロットを直しません。キャッシュされたロングコンテキストはやはりロングコンテキストで、同じ精度劣化が起こります。

ロングコンテキストに送る前にリランカーを使うべきですか?

本番のハイブリッドシステムでは多くの場合Yesです。top 50〜200の検索済みチャンクに対するリランカー(クエリとドキュメントのペアを採点するcross-encoderモデル)は、ロングコンテキスト段に渡すものの関連性を劇的に改善します。リランクをスキップすると、低い精度を補うためにより多くのトークンを詰め込むことになり、結果としてロット領域に押し出されます。リランクは、ハイブリッドパイプラインに加えられる最もレバレッジの高い改善のひとつです。

---

おわりに

ウィンドウが大きくなる新モデルのリリースが毎回魅力的なのは、暗黙の約束のためです。「エンジニアリングをやめて、ただ流し込めばいい」。Chromaの論文は、その約束が果たされなかった理由に厳しい数字を当てました。そして根底の数学(softmaxの希釈、位置エンコーディングの外挿、学習分布)を見ると、コンテキストウィンドウが100Mトークンになっても、その約束がきれいに果たされる見込みは薄いと示唆されます。

残るのは、地味だが生産的な答えです。検索を構築する。チューニングする。リランカーを追加する。スペックシートを信じるのではなく測定によって安全コンテキスト予算を選ぶ。実際に答えを含む最小・最も関連性の高いトークン集合だけをモデルに送る。その上で推論させる。出典を引用する。

「AGIが来た、コードベースを貼るだけだ」と言うよりは華やかさに欠けますが、こちらは本番で動く機能を出荷できます。2026年に静かに良いLLMプロダクトを作っているチームは、ロングコンテキストの物語にもRAGの物語にも同じ懐疑を向け、結果として実際のワークロードを処理できるハイブリッドパイプラインに辿り着いたチームです。

アーキテクチャの意思決定はモデルリリースより長持ちします。そこを正しく押さえれば、次のモデルアップグレードは強制的な書き直しではなく、無償の改善になります。