LLMにおけるコンテキストロットとは何か
コンテキストロットとは、入力が長くなるほど大規模言語モデルが情報をうまく使えなくなるという、実測された傾向のことです。しかもそれは、コンテキストウィンドウが埋まるはるか手前で起こります。Chroma Researchは2025年7月、18のフロンティアモデルを横断してこの現象に数字を与えました。2026年にかけての後続研究は、その結論を弱めるどころか、むしろ鋭くしています。1Mトークンをうたうモデルであっても、30Kのときと同じ品質で1Mトークン全体をまたいだ推論ができるわけではありません。
何を作るかを決める立場の人向けに、実務的な言い方をしておきます。仕様に書かれたコンテキストウィンドウは「送ってよい量」です。あなたにとっての実用ウィンドウは「モデルが品質基準を満たし続ける範囲」です。この2つは別の数字であり、後者はたいてい前者のごく一部にすぎません。
このギャップこそ、2024年後半から2025年前半にかけてエンジニアリング系のチャンネルを駆けめぐった主張、つまり「RAGはもう時代遅れだ、全部貼り付ければいい」という言い分が、うまく歳を取らなかった理由です。ウィンドウ自体は本当にやってきました。AnthropicはClaude Opus 5とClaude Sonnet 5で1Mトークンを提供しています。OpenAIのGPT-5.6ファミリーは約1.05Mを、GoogleのGemini 3.1 Proは1Mを備えています。MetaのLlama 4 Scoutは、仕様上10Mと記載しています。やってこなかったのは、その全部をうまく使えるモデルの方でした。
その結果、面白い問いは「どちらが勝つか」ではなくなり、「このデータ形状、このレイテンシ予算、この鮮度要件、この請求額に、どのパターンが合うか」に変わりました。この記事の残りは、その問いに答えるためのものです。
Chromaのコンテキストロット研究が示したこと
「コンテキストロットは存在する」という見出しは、この仕事を安く見せてしまいます。2025年7月14日に公開されたContext Rot: How Increasing Input Tokens Impacts LLM Performanceで、Kelly Hong、Anton Troynikov、Jeff Huberの3氏は18のモデルを対象に統制実験を行いました。対象にはClaude 4ファミリーに加えてClaude 3.7と3.5、o3、GPT-4.1ファミリー、GPT-4o、GPT-4 Turbo、Gemini 2.5 ProとFlash、そしてQwen3の3サイズが含まれます。GitHubの再現キットを使えば、自分で追試できます。
アーキテクチャ上、重要な発見は4つです。
入力が増えるにつれて、性能は一様でない形で劣化する。 コンテキストロットのグラフを探してここへ来たのなら、注目すべきはその形です。なだらかな直線ではありません。精度はしばらく保たれ、そこから崖のように落ち、しかも崖の位置はモデルごとに違います。プロットすると、スロープではなくギザギザの下り坂が現れます。だからこそ、あるコンテキスト長で1点だけ確認しても、別の長さでの挙動についてはほとんど何もわからないのです。
落ち込みの幅は大きい。 会話型の質問応答ベンチマークであるLongMemEvalでは、306件のプロンプトに絞り込み、それぞれ2つのバージョンを比較しました。焦点を絞った版は関連する材料だけを含み、平均で約300トークンです。フル版は同じ答えを周囲の会話の中に埋め込んだもので、平均で約113kトークンあります。モデルは焦点を絞った版をうまく処理し、フル版では一貫して劣化しました。その差はモデルによって大きく異なり、Chromaは特にClaudeファミリーで顕著だったと述べています。質問も、モデルも、入力の中に置かれた答えも同じです。変わったのは、付いてくる無関係なテキストの量だけでした。
劣化を駆動しているのは長さより意味的な類似度である。 「針」が「干し草の山」から見分けやすいとき、モデルはそれを見つけます。ディストラクター（紛らわしい情報）が意味的に答えと似ていると、精度は急激に落ち、その落ち込みは長さとともに広がります。ディストラクターが1つ入るだけで、針だけを置いたベースラインより性能は下がり、4つになるとさらに悪化します。これはLiu et al. (2024), "Lost in the Middle," in TACLとも一致します。同論文は、長いコンテキストの中央部分が体系的に軽く扱われるU字カーブを見つけています。
構造化され一貫したテキストの方が、シャッフルされたテキストよりアテンションを劣化させる。 これは、エンジニアの考え方を変えるべき結果です。直感的には、きれいに整った100Kトークンの文書の方が、バラバラの文書より推論しやすいはずです。Chromaが見つけたのは逆でした。しかも18モデルすべてで一貫していました。干し草の山をシャッフルして論理的な流れを壊すと、性能は上がったのです。なぜそうなるかは未解明で、Chroma自身も「入力の構造がアテンションの当たり方に影響しうる」という以上のことは言っていません。ただ、行動に移すのにメカニズムは要りません。整った体裁のPDFが自動的に安全な選択肢になるわけではない、ということです。
本番運用に持ち込むべき細部がもう1つあります。失敗の仕方はモデル固有だ、という点です。ディストラクターがある条件では、Claudeファミリーはハルシネーション率が最も低く、確信が持てないときは回答を控える傾向がありました。一方でGPTファミリーは最も高く、自信ありげに間違える傾向がありました。両者から選ぶということは、どちらの失敗をデバッグしたいかを選ぶことでもあります。
| 変えるもの | 精度に起きること | パイプラインにとっての意味 |
|---|---|---|
| 入力が約300から約113kトークンへ増える | LongMemEvalで一貫した劣化 | 無関係なコンテキストはタダの詰め物ではない |
| 針が干し草の山と似ている | 急激に低下し、長さとともに悪化 | トークンを足すのではなくリランクで精度を上げる |
| ディストラクターを1つ追加 | ベースラインから計測可能な低下 | 組み立て前に「惜しい候補」を削る |
| 干し草の山をシャッフル対一貫した並び | 18モデルすべてでシャッフルの方が高スコア | きれいな整形は安全マージンにならない |
| ディストラクターありでモデルを入れ替え | Claudeは回答を控え、GPTはハルシネーションを起こす | 検知できる失敗モードを選ぶ |
Sequential-NIAHベンチマーク（arXiv 2504.04713）は、同じ継ぎ目を別の角度から突いています。正しい順序で返さなければならない複数の針を、モデルが取り出せるかを試すものです。8Kから128Kまでのコンテキストで6つのLLMを比較したところ、最良のモデルでも63.5パーセントでした。距離をまたいだ多段階の検索は、単一の針を使ったデモが示唆するよりも難しいのです。
もう少しやさしい入口が欲しければ、Hamel HusainがKelly Hongを招いて研究を解説してもらった回があり、その講演に注釈を付けた記事が公開されています。結論はレポートと同じ場所に着地します。性能はコンテキスト長に対して一様ではないこと、情報の見せ方が効くこと、そして意図的なコンテキストエンジニアリングこそがレバーであること、の3点です。
ロングコンテキストが失敗する仕組み
仕組みが重要なのは、どのワークロードが壊れるかを予測できるからです。
Transformerのアテンションは、トークンのペアに対してsoftmaxを取ります。系列長が伸びるほど、アテンションはより多くの位置に分散します。RoPEやALiBiのような相対位置エンコーディングを使っても、softmaxの分母は大きくなり、個々のトークンに割り当てられる重みは小さくなります。1Mトークンでは、正解のトークンが有限の予算をめぐって残り999,999個と競合することになります。
位置エンコーディングは扱える範囲を引き伸ばしますが、問題そのものを取り除くわけではありません。RoPEは学習時の長さを大きく超えて外挿すると劣化します。つまり32Kの系列で学習して1Mで運用しているモデルは、下敷きになっている数学が十分に支えていない外挿をしていることになります。YaRN、位置補間 (position interpolation)、NTK対応スケーリング (NTK-aware scaling)はいずれも役に立ちますが、そのどれも、32Kのときと同じ精度で1Mトークンを使えるモデルを生み出してはいません。
学習データの問題もあります。長い系列で学習していても、800Kトークンをまたいだ本物の推論を要求する事例は稀です。モデルは、学習データが使い方を教えてくれた範囲のコンテキストしか使えるようになりません。
つまりコンテキストロットは、次のリリースで直る不具合というより、アーキテクチャと学習分布の性質です。今後のモデルはフロンティアをさらに押し広げるでしょうが、劣化の形そのものは残り続けます。
早期終了：2026年の研究が付け加えたもの
この記事の初版以降に出た最も有用な新しい結果は、ベンチマーク研究ではなく、長期タスクを扱うエージェント研究から出てきました。
Diagnosing and Mitigating Context Rot in Long-horizon Search（2026年6月）で、Shijie Xia、Yikun Wang、Zhen Huang、Pengfei Liuの4氏は、3つのベンチマークにまたがって4つのフラッグシップモデルを調べ、それまでの文献が取りこぼしていた失敗モードに名前を与えました。**早期終了（premature termination）**です。大きなコンテキストを与えられると、モデルはウィンドウを使い切るはるか手前で探索をあきらめたり、確信のない誤答を返したりします。クエリの難易度を統制したうえで、早期終了の発生率はコンテキスト長とともに上昇することがわかりました。
これは問題の捉え方を変えます。コンテキストロットという言葉は2種類の別々の失敗を覆っており、必要な対処は正反対です。モデルが針を見つけられなくなっているなら、上げるべきは精度です。モデルが探すのをやめているなら、必要なのは探索を続けるための余地と理由です。多段階の検索を行うエージェントで両者を混同すると、数週間を無駄にします。
盗む価値があるのは2つ目の発見です。著者らは3カテゴリにわたる7つのコンテキスト管理手法を分析し、これらは主としてテスト時スケーリングの戦略として働いていると結論づけました。早期終了率を下げることで、モデルにより多くの探索を買い与えている、という説明です。コンパクションや剪定（プルーニング）は、単なるコスト対策ではなく精度のための機能として元が取れます。著者らはさらに、並列サンプリング向けの挙動に基づくフィルタリング戦略を構築し、3つの集約手法にわたって2.6〜4.9パーセントの改善を計測しています。
長時間のセッションでエージェントを走らせているなら、自分のエージェントがどれくらいの頻度で早々に切り上げているかを追跡してください。安価な指標なのに、計装している人はほとんどいません。
RAGが今も勝つ領域
ここまでを踏まえても、検索拡張生成（RAG）の居場所はなくなりません。勝ち続けている領域を挙げます。
大規模なマルチドキュメントのコーパス。 ナレッジベースが50,000件の文書、合計500Mトークンあるなら、どのウィンドウにも収まりません。検索が唯一の現実的なアーキテクチャです。
鮮度と即時性。 ベクトルストアは差分で更新できます。ロングコンテキストのプロンプトは、内容が変わるたびに作り直しが必要です。1時間単位で更新されるもの（ニュース、カタログ、サポートチケット、コード）なら、検索は変更を安く吸収します。
コスト。 入力コストは入力トークン数に比例し、一定の閾値を超えると線形より悪く増えます。クエリの95パーセントが関連する5Kトークンで答えられるなら、検索は精度を落とさずに何倍も安く済みます。
引用と来歴。 検索は、表示・リンク・順位付けができる構造化された出典リストを返してくれます。一方、ロングコンテキストの回答を特定の出典に紐づけるには、追加の作り込みが要ります。これは、要約を残すツールよりも、本文の一節と出典を残す読書ツールの方が強い理由と同じです。Glaspで保存したものすべてを横断して質問するとき、すべての回答は、その元になったハイライトを指し示せます。
アクセス制御とテナンシー。 コーパスにユーザー単位・テナント単位・ロール単位の可視性があるなら、全部をまとめて投げ込むことはできません。検索なら、モデルが何かを見る前にポリシーで絞り込めます。B2Bではここは譲れません。
複数コーパスをまたぐ推論。 答えがSlackのスレッド、Notionのページ、Linearのイシュー、GitHubのPRにまたがっているとき、それらを橋渡しするのは検索です。
このうち1つでも当てはまるなら、RAGは選択肢ではなく必須です。問いは「やるかどうか」ではなく「検索をどう良くするか」に変わります。
ロングコンテキストが勝つ領域
ロングコンテキストが単純に正解になるワークロードもあります。
単一ドキュメントの深い推論。 100ページの契約書を読んで条項をまたいで答える。論文を分析する。決算説明会の内容を読み解く。80ページ離れた2つの段落を結びつけないと答えが出ないとき、チャンク分割はその繋がりを断ち切りがちです。
リポジトリ内のコード理解。 多くのコードタスクは、import、型、定義、呼び出し箇所を同時に必要とします。ファイル単位でチャンク分割すると、ファイル間の関係が失われます。
会話の連続性。 長いエージェントセッションは、本物の履歴があるほど良くなります。会話履歴に対する検索は脆いものです。必要なのはたいてい「直近50ターン」であって、「意味的に最も近い50ターン」ではないからです。
クエリがまだ決まっていない探索的な推論。 事前にクエリを書けないなら、検索は狙いを定めにくくなります。ロングコンテキストなら、モデルに読み回らせることができます。
一貫したまとまりの中での相互参照。 教科書の1章、論文、法律の準備書面。これらを分割して組み直すと、論の筋が失われがちです。
大まかな目安。データが論理的に1つの文書で、実測した安全予算に収まるなら、ロングコンテキストの方がきれいなアーキテクチャです。
多くのチームが行き着くハイブリッド構成
本気で作るシステムの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
それぞれの段が、もう一方の失敗モードを埋めます。検索は、どのウィンドウにも入らないコーパスを扱える大きさまで絞り込みます。取得した集合の全体に対して推論することで、古典的なtop-5 RAGが捨ててしまうチャンク横断の推論を取り戻します。
設計を左右する判断は、検索セットのサイズです。トークンが少なすぎれば、top-5 RAGを作り直しただけになります。多すぎれば劣化ゾーンに入り、より悪い答えにより多く払うことになります。次のセクションで測定に落とし込みますが、実用的な目安はこうです。安全予算を仕様上のウィンドウの20〜40パーセント程度に置き、そのうえで自分のデータで検証する。200Kウィンドウのモデルなら40K〜80K、1Mウィンドウのモデルなら200K〜400Kです。そして偶然ながら、後者はちょうど課金の変わるあたりでもあります。
ハイブリッドのチューニング：数値とヒューリスティック
以下は普遍的な真理ではありません。本番でそれなりに通用する出発点です。
チャンクサイズ。 散文なら500〜1,500トークン。コードなら関数や論理ブロック単位で200〜500。チャンク内の文脈が意味を担う法務文書や学術文書なら1,500〜3,000。オーバーラップは10〜20パーセント。
top-kの取得。 送る量より多く引いてください。top 50〜200を取得してからリランクします。クロスエンコーダーはペアあたりのコストが埋め込みモデルより高い代わりに、細かい関連性の判定が劇的に得意です。
リランク後にコンテキストへ残す比率。 リランク後は上位20〜100チャンクを残します。正確な数は、チャンクサイズと安全予算から決まります。
ハイブリッド検索。 デンス検索とスパース検索（BM25、SPLADE）を相互ランク融合 (reciprocal rank fusion)で組み合わせます。デンス単独では、SKU、エラーコード、固有名詞のような完全一致を取り逃がします。スパース単独では言い換えを取り逃がします。
このうち2つのつまみは、箇条書き以上の説明に値します。チームが気づかないうちに精度を失うのは、たいていここだからです。
1つ目は安全コンテキスト予算で、これを決める誠実な方法は計測しかありません。複数チャンクをまたいだ推論が必要な質問を集めた小さな評価セットを作り、詰め込むコンテキストを16K、32K、64K、128K、256Kと変えて精度を採点します。基準を満たす最大サイズを取り、余裕をみてその20パーセント下で運用します。この実測値は先ほどの20〜40パーセントというルールの近くに着地するはずですが、そうならない場合は、ヒューリスティックより自分の評価結果を信じてください。
2つ目はモデルを上げたときに何が起きるかで、2026年に多くのチームが噛まれた点です。AnthropicのトークナイザーはClaude Opus 4.7で変わり、同じテキストが内容に応じておよそ1.0〜1.35倍のトークン数になりました。Anthropic自身は「約30パーセント増」とまとめています。文書が増えたのではありません。予算が縮んだのです。1年前にトークン上限を固定したまま、その下のモデルを差し替えたのなら、その上限の意味は今や別物になっています。しかもログの中に、それを知らせてくれるものは何もありません。
クエリがそう言っているときは、検索を丸ごと飛ばす。 「今アップロードした文書を要約して」は単一ドキュメントのタスクです。小さな分類器で検出し、検索をスキップして、レイテンシを節約し、無関係なノイズを持ち込まないようにします。
要約と剪定のレイヤー。 非常に長い履歴では、組み立ての前に古い材料を圧縮します。要約自体もトークンを消費するので、本当に効いているかは計測してください。
| 軸 | 純粋なRAG（top-5チャンク） | 純粋なロングコンテキスト | ハイブリッド（50K〜200Kを検索して推論） |
|---|---|---|---|
| データ形状 | 多数の文書、広いコーパス | 1つの文書か小さな集合 | 多数の文書、深い推論 |
| 典型的な入力サイズ | 2K〜10Kトークン | 100K〜1Mトークン | 50K〜200Kトークン |
| レイテンシ | 速い | 遅い | 中程度 |
| クエリあたりのコスト | 低い | 高い。価格の崖を超えるとさらに悪化 | 中程度 |
| 規模が大きいときの精度 | top-kが適切なら良好 | コンテキストロットで劣化 | 複雑なクエリでは最良 |
| 鮮度 | 容易（インデックス更新） | 困難（プロンプト再構築） | 容易（インデックス更新） |
| 引用 | 標準で可能 | 追加の作業が必要 | 標準で可能（取得セット経由） |
| アクセス制御 | 標準で可能（検索時にフィルタ） | 困難 | 標準で可能 |
| 単一ドキュメント推論 | しばしば破綻 | 強い | 強い |
| ドキュメント横断推論 | 限定的（top-kのみ） | 1文書でない限り対象外 | 強い |
エンジニアが繰り返し出してしまうアンチパターン
名前を付けておく価値があるほど繰り返される罠が、いくつかあります。
「とりあえず全部コンテキストに突っ込む」。 ウィンドウが倍になるリリースのたびに魅力的に見えます。しかし劣化は静かに進むので、スポットチェックは通ってしまい、本番では、まさにコンテキスト横断の推論を必要としていたクエリで落ちます。出す前に、想定サイズで評価を回してください。
「とにかくRAGを使う」。 反射的に検索すると、単一ドキュメントのケースを取り逃がします。50ページのPDFをインデックスしてtop-5チャンクを引くやり方は、何もしないよりはたいてい良いものの、PDFをそのまま送るやり方には負けます。
「組み立て後のトークン数を見ない」。 top-kを「入るだけ」に設定したチームが、3か月後に平均プロンプトが350Kトークンに達し、精度が静かに落ち、誰も読んでいなかった閾値のせいで請求額が倍になっていたと気づく、という話です。組み立て後のコンテキストサイズを一級の指標として追跡し、アラートを設定してください。
「仕様上のウィンドウを信じる」。 仕様上の上限は「送ってよい量」です。実用上の上限は「品質が保たれる範囲」です。この2つは別の数字で、スペックシートに載っているのは片方だけです。
「モデルが良くなったから評価は省く」。 モデルのアップグレードは、正しいアーキテクチャを変えますし、気づかないうちにトークンの勘定まで変えることがあります。モデルが変わったら評価をやり直してください。
「静かな失敗は安全な失敗だと思い込む」。 ディストラクターがある条件では、ハルシネーションを起こすモデルもあれば、回答を控えるモデルもあります。長期タスクでは、ただ早々に止まるものもあります。自分のモデルがどれをやるのかを把握し、そのための計装をしてください。
2026年に変わったこと：ウィンドウ、価格、コンパクション
この記事の初版以降、2つのことが動きました。しかも両方が同じ方向に効いています。
ロングコンテキストには、2社で公表された価格の崖ができた。 OpenAIはGPT-5.6ファミリーを2つの料金体系で課金します。閾値より下では、GPT-5.6 Solは入力100万トークンあたり$4、出力100万トークンあたり$20です。閾値より上では、同じモデルが$8と$30になります。Terraは$2/$12から$4/$18へ、Lunaは$0.20/$1.20から$0.40/$1.80へ変わります。閾値は入力272Kトークンにあり、これを超えると超過分だけでなくリクエスト全体が再課金されます。272,001トークンのプロンプトは、そのすべてのトークンが高い方のレートで請求されます。うたわれている1.05Mトークンのウィンドウに対して、広告どおりの価格で使えるのはおよそ4分の1ということです。
Googleはより低い閾値で同じことをしています。Gemini 3.1 Proは200Kトークンまでのプロンプトなら入力100万トークンあたり$2、出力100万トークンあたり$12で、それを超えると$4と$18になります。入力2倍、出力1.5倍という構造は同じで、位置が72Kトークン手前にあるだけです。OpenAIの崖に合わせてパイプラインを設計したあとでベンダーを乗り換えると、コードを1行も変えていないのにGoogleの崖を軽々と越えてしまうことがあります。
独立した2社がロングコンテキストを割増で値付けしているという事実は、どちらか一方だけよりも強い証拠です。これは品質の議論を予算の議論に変えます。安全コンテキスト予算の内側に留まることは、もともと精度を守る打ち手でしたが、いまや請求が1つで済むか2つ分になるかの分かれ目でもあるのです。
ベンダーはコンテキスト管理を製品機能として出荷している。 Anthropicのコンパクションは、会話が伸びるにつれて過去のコンテキストをサーバー側で要約します。デフォルトで有効ではなくオプトインですが、いったん有効にすると、ウィンドウが1Mのモデルでもトリガー閾値の既定値は150Kトークンです。もう一度書きます。100万トークンのウィンドウを持つベンダーが、自ら既定値をその15パーセントに置いているのです。Anthropicはコンテキストの編集機能も提供しており、こちらは要約するのではなく、古いツール実行結果や思考ブロックを消去します。仕組みは2つですが、認めている中身は同じです。
本物のコストレバーはプロンプトキャッシュで、これは確かに効きます。主要な2つのAPIのどちらでも、キャッシュされた入力の読み出しは通常の入力価格のおよそ10分の1です。安定したコンテンツに対して同じクエリを繰り返す場合、キャッシュは大幅に安くなります。ただしコンテキストロットは直りませんし、OpenAIではロングコンテキストの料金帯を免除してもくれません。
| モデル | 仕様上のウィンドウ | 実務上の注意 |
|---|---|---|
| Claude Opus 5 / Sonnet 5 | 1Mトークン | 有効化するとコンパクションの既定値は150K |
| Claude Haiku 4.5 | 200Kトークン | 安全予算は40K〜80K付近に着地 |
| GPT-5.6 (Sol / Terra / Luna) | 約1.05Mトークン | 入力272K超でリクエスト全体が再課金 |
| Gemini 3.1 Pro | 1Mトークン | 200K超でリクエスト全体が再課金 |
| Llama 4 Scout | 10Mトークン（iRoPE） | 仕様上の数字であり、その深さでの実証はない |
変わっていないのは、その下にある結果の方です。これらのリリースのどれ1つとして、ウィンドウを大きくすれば劣化が直るという証拠は出していません。ウィンドウが大きくなれば天井は上がりますが、劣化の形は残ります。そして鮮度が求められる、マルチテナントで、複数ソースにまたがるワークロードには、依然として検索が必要です。
これはコンテキストエンジニアリング全般に現れるのと同じ規律です。プロンプトに何を入れるかと同じくらい、何を入れないかが効きます。また、検索レイヤーが他の入力経路と同じだけの精査に値する理由でもあります。間接プロンプトインジェクションは、ユーザー経由ではなく、取得した文書を経由してやってくるからです。
今日から使える意思決定フレームワーク
新しいLLM機能を作るときは、上から下へこの順にたどってください。
ステップ1：コーパスはどのくらいの大きさか。
- 合計100Kトークン未満：検索は省き、ロングコンテキストを使う。
- 100K〜1Mトークン：鮮度次第。ステップ2へ。
- 1Mトークン超：検索が必須。
ステップ2：データはどれくらい新しくある必要があるか。
- 1時間単位かそれより速い：検索。長いプロンプトの作り直しは高すぎます。
- 日次から週次：どちらのパターンでも成立します。
- 静的：プロンプトキャッシュ付きのロングコンテキストが安くてきれいです。
ステップ3：クエリの形はどうなっているか。
- 単一ドキュメントの深い推論：ロングコンテキスト寄り。
- 複数ドキュメントの統合：ハイブリッド寄り。
- 参照や事実の取り出し：古典的なRAG寄り。
- 探索的：文書集合に上限があるならロングコンテキスト、そうでなければハイブリッド。
ステップ4：引用やアクセス制御は必要か。
- どちらかがYes：検索が必須です。ロングコンテキストだけの設計に、後から引用とユーザー単位のフィルタリングを足すのは苦痛です。
ステップ5：レイテンシ予算はどれくらいか。
- 1秒未満：古典的なRAG。
- 1〜5秒：ハイブリッドが現実的です。
- 5秒超：どのパターンでも成立します。
ステップ6：長いクエリでの精度の下限はどこか。
- 50Kトークンを超える多段階推論で高い精度が必要：リランカー付きのハイブリッド。
- ベストエフォートでよい：古典的なRAGでたいてい十分です。
ステップ7：組み立て後のプロンプトは、価格の崖に対してどこに落ちるか。
- OpenAIなら272K未満、Googleなら200K未満、それ以外なら実測した安全予算の内側：問題ありません。
- どちらかの閾値の近くをうろついている：リランカーを足して検索セットを削ってください。たいていの場合、より良い答えとより少ない請求が同時に手に入ります。
多くの本番システムはハイブリッドに落ち着きます。現実のワークロードは、純粋なロングコンテキストを壊す制約（マルチテナンシー、鮮度、コスト、引用）を少なくとも1つ持ち、同時に純粋なtop-k RAGを壊す制約（単一ドキュメント推論、コンテキスト横断のクエリ、探索）も少なくとも1つ持っているからです。
同じスキルには、人間版もあります。推論プロセスの前に何を差し出す価値があるかを決める作業は、注意深い読み手がずっと手でやってきたことであり、ハイライトはその判断を明示的にしたものです。Glaspのウェブハイライターは、ページ全体ではなく、あなたが残す価値があると判断した一節を保持します。これは人間のリランカーを備えた検索です。その集合に自分のツールを向けたいなら、GlaspのMCPコネクタがハイライトをLLMに直接公開します。その構成についてはノートをMCPサーバーに変えるで詳しく書きました。
よくある質問
LLMにおけるコンテキストロットとは何ですか？
コンテキストロットとは、LLMがマーケティングの示唆するほどうまくロングコンテキストを使えていない、という観察のことです。トークンを増やしていくと、検索と推論の精度は非線形に劣化し、なだらかな坂を下るのではなく崖にぶつかります。ディストラクターのテキストが答えと似ているほど、悪化は速くなります。さらにChromaは、テストした18モデルすべてで、一貫して整った入力の方がシャッフルした入力よりアテンションを傷つけたことを見つけました。1Mトークンのウィンドウを埋めても、1Mトークン品質の答えが買えるわけではありません。
2026年、RAGはもう時代遅れですか？
いいえ。むしろ証拠は逆を指しています。どのウィンドウにも収まらないコーパス、1時間単位で変わるデータ、テナント単位のアクセス制御、そして引用のためには、依然として検索が必要です。時代遅れになったのは、古典的なtop-5 RAGを唯一のパターンとして使うことの方です。現在のデフォルトはハイブリッド、つまり上限のある集合を検索で集め、その全体に対して推論する形です。コンテキストウィンドウの拡大が変えたのは「どれだけ取得するか」であって、「取得するかどうか」ではありません。
ロングコンテキストはRAGを置き換えますか？
一般論としては置き換えません。ChromaのContext Rotレポートは、ウィンドウが埋まるはるか前に性能が劣化することを示しました。その後、ベンダー自身が自社製品で同じことを認めています。Anthropicのオプトイン式コンパクションは1Mトークンのモデルで既定150Kから要約を始め、OpenAIは入力272Kトークンを超えたリクエストを再課金し、Googleは200K超で同じことをします。ただし、実測した安全予算に収まる1つのまとまった文書に対しては、ロングコンテキストはRAGを置き換えます。
コンテキストロットが効き始めるまでに、検索セットはどのくらいの大きさにできますか？
自分のモデルで検証すべきですが、妥当な出発点は仕様上のウィンドウの20〜40パーセントです。200Kのモデルなら40K〜80K、1Mのモデルなら200K〜400Kです。ただしOpenAIでは課金上の理由から272K未満に、Googleでは200K未満に収めたいところです。マルチホップの質問を集めた小さな評価セットを作り、コンテキストサイズごとに精度を測り、基準を満たす最大サイズを採用してください。
プロンプトキャッシュはコンテキストロットを解決しますか？
いいえ。キャッシュが直すのはコストであって精度ではありません。キャッシュされた入力の読み出しは通常の入力価格のおよそ10分の1なので、安定したコンテンツに対するロングコンテキストのクエリは大幅に安くなり、RAGのコスト優位は縮みます。それでもモデルは同じ長さのコンテキストを読み、同じように劣化します。つまり、同じだけ弱い答えを安く買っているだけです。OpenAIでは、キャッシュを使ってもロングコンテキストの料金帯からは免除されません。
ロングコンテキストに送る前に、リランカーを使うべきですか？
本番のハイブリッド構成のほとんどでは、使うべきです。取得したtop 50〜200チャンクをクロスエンコーダーで採点すると、推論段に届くものの質が大きく上がります。リランクを省くと、弱い精度を補うためにトークンを詰め込むことになりがちで、劣化ゾーンと価格の崖の両方に近づきます。ハイブリッドのパイプラインに加えられる変更の中で、最も効果の大きいものの1つです。
長いタスクでエージェントが早々に止まります。これはコンテキストロットですか？
おそらくそうですし、いまは名前も付いています。2026年の論文Diagnosing and Mitigating Context Rot in Long-horizon Searchは、これを早期終了（premature termination）と呼んでいます。コンテキストが重くなると、モデルはウィンドウを使い切る前にあきらめたり、根拠のない自信で答えたりし、その発生率はコンテキスト長とともに上がります。コンテキスト管理が効くのは主に、この率を下げてエージェントに探索を続けさせるからです。早々の打ち切りそのものを、独立した指標として計装してください。
おわりに
ウィンドウを大きくするリリースはどれも、同じ含意を運んできます。「もう設計しなくていい、全部放り込め」という含意です。Chromaは、その約束がなぜ実現していないのかに硬い数字を与えました。2026年の研究は、誰も見ていなかった2つ目の失敗モードを付け加えました。そして根底にある数学（softmaxの希釈、位置の外挿、学習分布）は、100Mトークンになってもきれいには実現しないと告げています。
残るのは、退屈で生産的な答えです。検索を作る。チューニングする。リランカーを足す。安全コンテキスト予算はスペックシートを信じるのではなく計測して決め、モデルやそのトークナイザーが変わったら測り直す。答えを含む中で最も小さく、最も関連の高いトークン集合を送る。その上でモデルに推論させる。出典を引用する。
2026年ならではの妙味は、ベンダー側もあなたに同意しているかのように値付けし、実装するようになったことです。272Kと200Kの崖、そして150Kというコンパクションの既定値は、いずれも「実用ウィンドウは広告の一部にすぎない」という自認です。これは有り難い話です。規律あるアーキテクチャが、同時に安いアーキテクチャでもあるということだからです。この2つが同じ方向を指すことは、めったにありません。
どの仕事にどのモデルを向けるかという、より広い地図が欲しければ、タスク×モデルのマトリックスにまとめてあります。アーキテクチャの判断は、モデルのリリースより長生きします。ここを正しく押さえておけば、次のアップグレードは強制的な書き直しではなく、ただの無料の改善になります。
