コンテキストロットとは？2026年のRAG対ロングコンテキスト

LLMにおけるコンテキストロットとは何か

コンテキストロットとは、入力が長くなるにつれて大規模言語モデルの精度が下がっていく、実測された現象のことです。しかもそれは、コンテキストウィンドウが埋まるはるか手前で起こります。原因は、アテンションがより多くのトークンに分散すること、答えに似たディストラクター（紛らわしい情報）があること、そして極端に長い入力での推論を学習がめったに報いないことにあります。対策は、送る量を減らすことです。検索してリランクする、古くなったツール出力を消す、長いセッションはコンパクションするか始め直す、そしてスペックシートを信じるのではなく自分の安全予算を計測する、といったことです。

Chroma Researchは2025年7月、18のモデルを横断してこの現象に数字を与えました。この言葉はいまや広く定着し、Anthropic自身のドキュメントも「トークン数が増えるにつれて精度と再現率は低下する。これはコンテキストロットとして知られる現象である」と定義しています。広告されるウィンドウが大きくなれば、送れる量の天井は上がります。しかし、その範囲の上端でも下端と同じ精度が出ると約束しているわけではありません。

何を作るかを決める立場の人向けに、実務的な言い方をしておきます。仕様に書かれたコンテキストウィンドウは「送ってよい量」です。あなたにとっての実用ウィンドウは「モデルが品質基準を満たし続ける範囲」です。この2つは別の数字であり、後者はたいてい前者のごく一部にすぎません。

このギャップこそ、2024年後半から2025年前半にかけてエンジニアリング系のチャンネルを駆けめぐった主張、つまり「RAGはもう時代遅れだ、全部貼り付ければいい」という言い分が、早々に古びてしまった理由です。ウィンドウ自体は本当にやってきました。AnthropicはClaude Opus 5.5、Sonnet 5.5、そして新しいHaiku 5.5で1Mトークンをデフォルトにしています。OpenAIのGPT-6系のモデルは1.05Mのウィンドウを持ち、そのうち922Kを入力に使えます。GoogleのGemini 3.1 ProとGemini 3.8 Flashは、約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 Opus 4、Sonnet 4、Sonnet 3.7、Sonnet 3.5、Haiku 3.5、o3、GPT-4.1とそのmini版・nano版、GPT-4o、GPT-4 Turbo、GPT-3.5 Turbo、Gemini 2.5 Pro、2.5 Flash、2.0 Flash、そしてQwen3の3サイズです。ウィンドウや思考予算の制約から、すべてのモデルがすべての実験で試されたわけではありません。GitHubの再現キットを使えば、自分で追試できます。

アーキテクチャ上、重要な発見は4つです。

入力が増えるにつれて、性能は一様でない形で劣化する。 コンテキストロットのグラフを探してここへ来たのなら、注目すべきはその形です。曲線は1本ではありません。Chroma自身の要約によれば、モデルは「コンテキストを一様には使っていない。むしろ、入力が長くなるにつれて性能はますます当てにならなくなる」のです。どれだけ速く、どこで落ちるかはモデルとタスクによって変わります。だからこそ、あるコンテキスト長で1点だけ確認しても、別の長さでの挙動についてはほとんど何もわからないのです。Anthropicのエンジニアリングチームも、同じパターンを「明確な崖ではなく、性能の勾配」と表現しています。

落ち込みの幅は大きい。 会話型の質問応答ベンチマークであるLongMemEvalでは、306件のプロンプトに絞り込み、それぞれ2つのバージョンを比較しました。焦点を絞った版は関連する材料だけを含み、平均で約300トークンです。フル版は同じ答えを周囲の会話の中に埋め込んだもので、平均で約113Kトークンあります。フル版では、性能が一貫して劣化しました。差が最も大きかったのはClaudeのモデルで、Chromaはその多くを、回答を控えたことによるものだとしています。Claude Opus 4とSonnet 4は、推測で答えるよりも回答を控えることが多かったのです。質問も、モデルも、入力の中に置かれた答えも同じです。主に変わったのは、付いてくる無関係なテキストの量でした。

類似度が劣化の形を決める。 「針」が質問と意味的に似ていないほど、入力が増えるにつれて精度は速く落ちます（Chromaはこれを埋め込みの類似度で採点しました）。答えに似たディストラクターも性能を傷つけます。たった1つでも、針だけを置いたベースラインより性能は下がり、4つになるとさらに悪化します。一方、このタスクでは位置の影響はほとんどありませんでした。Chromaは、11通りの針の位置のあいだで目立った差を確認していません。Liu et al. (2024), "Lost in the Middle," in TACLが複数文書の質問応答で、長いコンテキストの中央部分が体系的に軽く扱われるU字カーブを見つけているにもかかわらず、です。

一貫した詰め物の方が、シャッフルした詰め物より害が大きかった。 これは、エンジニアの考え方を変えるべき結果です。直感的には、一貫した「干し草の山」の方が、ごちゃ混ぜのものより探しやすいはずです。Chromaが見つけたのは逆でした。しかも18モデルすべてで一貫していました。干し草の山の文をシャッフルして論理的な流れを壊すと、性能は上がったのです。なぜそうなるかは未解明で、Chroma自身も、入力の構造がアテンション機構の働き方に影響しうる、という以上のことは言っていません。ただ、行動に移すのにメカニズムは要りません。一貫していて話題にも沿った詰め物が、それだけで無害になるわけではない、ということです。

本番運用に持ち込むべき細部がもう1つあります。失敗の仕方はモデル固有だ、という点です。ディストラクターがある条件では、Claudeのモデルはハルシネーション率が最も低く、なかでもClaude Sonnet 4とOpus 4は特に慎重で、確信が持てないときは回答を控える傾向がありました。一方でGPTのモデルはハルシネーション率が最も高く、自信ありげに間違える傾向がありました。両者から選ぶということは、どちらの失敗をデバッグしたいかを選ぶことでもあります。

これを測っているのはChromaだけではありません。自分のワークロードに近いコンテキストロットのベンチマークを探しているなら、主なものは次のとおりです。

覚えておくべきは最後の行です。モデルが関連する一節をすべて完璧に取り出せたとしても、入力が長くなればそれだけで精度が落ちるのです。

もう少しやさしい入口が欲しければ、Hamel HusainがKelly Hongを招いて研究を解説してもらった回があり、その講演に注釈を付けた記事が公開されています。結論はレポートと同じ場所に着地します。性能はコンテキスト長に対して一様ではないこと、情報の見せ方が効くこと、そして意図的なコンテキストエンジニアリングこそがレバーであること、の3点です。

---

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

仕組みが重要なのは、どのワークロードが壊れるかを予測できるからです。

Transformerのアテンションは、トークンのペアに対してsoftmaxを取ります。系列長が伸びるほど、アテンションはより多くの位置に分散します。RoPEやALiBiのような相対位置エンコーディングを使っても、softmaxの分母は大きくなり、個々のトークンに割り当てられる重みは小さくなります。1Mトークンでは、正解のトークンが有限の予算をめぐって残り999,999個と競合することになります。Anthropicのエンジニアはこれを「アテンション予算」と呼び、「新たに加わるトークンはどれも、この予算をいくらか減らす」と述べています。

位置エンコーディングは扱える範囲を引き伸ばしますが、問題そのものを取り除くわけではありません。RoPEは学習時の長さを大きく超えて外挿すると劣化します。つまり32Kの系列で学習して1Mで運用しているモデルは、下敷きになっている数学が十分に支えていない外挿をしていることになります。たとえばMetaは、Llama 4 Scoutの事前学習と事後学習を256Kで行ったうえで、10Mのウィンドウを記載しています。256Kを超える部分は、すべて長さ方向の汎化に頼っているわけです。YaRN、位置補間（position interpolation）、NTK対応スケーリング（NTK-aware scaling）はいずれも役に立ちますが、そのどれも、32Kのときと同じ精度で1Mトークンを使えるモデルを生み出してはいません。

学習データの問題もあります。長い系列で学習していても、800Kトークンをまたいだ本物の推論を要求する事例は稀です。モデルは、学習データが使い方を教えてくれた範囲のコンテキストしか使えるようになりません。

つまりコンテキストロットは、次のリリースで直る不具合というより、アーキテクチャと学習分布の性質です。今後のモデルはフロンティアをさらに押し広げるでしょうが、劣化の形そのものは残り続けます。

---

早期終了：2026年の研究が付け加えたもの

この記事の初版以降に出た最も有用な新しい結果は、ベンチマーク研究ではなく、長期タスクを扱うエージェント研究から出てきました。

2026年6月に初版が投稿され、8月に大幅に改訂されたDiagnosing and Mitigating Context Rot in Long-horizon Searchで、Shijie Xia、Yikun Wang、Zhen Huang、Pengfei Liuの4氏は、オープンウェイトのフラッグシップモデル4つ（GLM-4.7、GLM-5.0、Qwen3.5-397B-A17B、MiniMax-M2.5）を、3つのディープサーチ系ベンチマークで調べました。BrowseComp、xbench-DeepSearch、そして固定のローカルコーパスを検索するBrowseComp-Plusです。クローズドなモデルは、推論トレースが暗号化されているため対象から外されています。改訂版は、それまでの文献が取りこぼしていた失敗モードに名前を与えました。早期終了（premature termination）です。大きなコンテキストを与えられると、モデルはウィンドウを使い切るはるか手前で探索をあきらめたり、自ら不確かだと示した誤答を返したりします。クエリの難易度を統制したうえで、著者らは早期終了の発生率がコンテキスト長とともに上昇することを見いだしました。

これは問題の捉え方を変えます。コンテキストロットという言葉は2種類の別々の失敗を覆っており、必要な対処もそれぞれ異なります。モデルが針を見つけられなくなっているなら、上げるべきは精度です。モデルが探すのをやめているなら、必要なのは探索を続けるための余地と理由です。多段階の検索を行うエージェントで両者を混同すると、数週間を無駄にします。

盗む価値があるのは2つ目の発見です。著者らは3つの系統（コンパクション、トリミング、サブエージェントによる分離）にわたる7つのコンテキスト管理手法を試し、これらは主としてテスト時スケーリングの戦略として働いていると結論づけました。早期終了率を下げることで、モデルがより多く探索できるようにしている、という説明です。どの系統が効くかは、モデルによって変わります。比較したモデルのうち、エージェントとしての能力が高い方のQwen3.5-397B-A17Bでは、作業をサブエージェントに分離する方法が最も高いスコアを出しました。弱い方のGLM-4.7では、サブエージェントは最悪の選択肢の部類に入り、最新のツール実行結果と要約だけを残す方法が、精度とコストのバランスで最も優れていました。著者らはさらに、並列サンプリング向けの挙動に基づくフィルタリング戦略を構築し、3つの集約手法にわたって平均精度を2.6〜4.9パーセントポイント引き上げています。

長時間のセッションでエージェントを走らせているなら、自分のエージェントがどれくらいの頻度で早々に切り上げているかを追跡してください。安価な指標なのに、計装している人はほとんどいません。

7月から10月初めにかけて投稿された2026年のプレプリント3本も、同じ方向を指しています。Context as an Environmentは、ツールの出力を永続的なPythonセッション内の変数として保持し、エージェントがprintで出力した内容だけをコンテキストに入れます。土台に同じQwen3.8-Maxモデルを使った比較で、LOCAベンチマークの256Kトークンにおいて86.7パーセントを記録しました。履歴を要約するエージェントは65.3パーセントでした。Stateless Language Agentsは、会話を引き継いでいく代わりに、ハーネスが保持する状態から呼び出しのたびにコンテキストを組み立て直します。カーネル最適化では、最も強いベースラインの最終性能に、84パーセント以上少ないトークンで到達しました。そしてCompactionRLは、コンパクションを後付けの機能ではなく、学習させるスキルとして扱います。そのGLM-4.5-Airモデルは、推論時にコンパクションを追加しただけの同じベースモデルより、SWE-bench Verifiedで6.6ポイント高いスコアを出しました。いずれもプレプリントですが、方向性は一致しています。作業セットを小さく保つこと、そしてそれを小さく保つのが上手なモデルにすることです。

---

エージェントとチャットツールでコンテキストロットを直す方法

効く対策はどれも同じことをしています。より少なく、より良いトークンをモデルの前に置くことです。AnthropicのエンジニアリングチームはEffective context engineering for AI agentsの中で、これを一文で言い表しています。「したがって、コンテキストは限界収益が逓減する有限の資源として扱わなければならない」。変わるのは、このルールをどこに適用するかだけです。

LLMアプリやエージェントを作っている場合：

• 送る量を減らし、中身をよく選ぶ。 検索し、リランクし、タスクに不要なものは捨てます。Googleのロングコンテキストガイドも同じことを言っています。「一般に、トークンをモデルに渡す必要がないなら、渡さないのが最善である」。
• 長い文書を先に、質問を最後に置く。 入力が20Kトークン以上になる場合、Anthropicのプロンプトガイドは文書を冒頭に、クエリを末尾に置くよう勧めており、末尾のクエリは「テストでは応答品質を最大30パーセント向上させうる」と述べています。回答の前に、関連する一節をモデルに引用させることも提案しています。GoogleもGeminiについて同じ配置を勧めています。
• 古くなったツール実行結果を消す。 古い検索結果やファイルの中身のダンプは、最も手軽に削れるトークンです。Anthropicはツール結果の消去を「最も安全で、最も軽微なコンパクションの1つ」と呼び、コンテキスト編集（context editing）として提供しています。既定では入力が100,000トークンに達すると消去を始め、直近3回分のツール使用を残します。
• ウィンドウが埋まる前にコンパクションし、要約を検証する。 AnthropicのAPIには、閾値式のコンパクション（既定のトリガーは入力150,000トークン）と、2026年9月からはオンデマンドのコンパクションがあります。OpenAIのResponses APIは、context_managementの下にcompact_thresholdを設定するとサーバー側でコンパクションを行い、単体のコンパクション用エンドポイントも公開しています。要約は情報を失うので、何が落ちたかを確認してください。Anthropicの助言は、まず再現率を最大化することから始め、そのうえで余分なものを削ることです。
• ルールと状態は要約の外に置く。 8月にarXivへ投稿されたCIKM 2026の論文The Compaction Cliff in Long-Running AI Agent Memoryは、Sonnet 4.6上でのClaude Codeのコンパクション用プロンプトが、本番のエージェント設定に含まれる安全ルールのうち、1回目で53パーセント、5回目では10パーセントしか残さなかったことを示しました。著者らの対策は、安全ルールと手順を一字一句そのまま固定し、残りを種類ごとに圧縮するもので、5回を通じて96パーセントの再現率を保ちました。ですから、ルールはエージェントが読み返す場所に固定し、進捗はチャット履歴ではなく、ノート、メモリツール、gitに残してください。
• 探索はサブエージェントに任せる。 サブエージェントは自分のコンテキストを使って探索し、Anthropicの言葉を借りれば「作業を凝縮し、蒸留した要約（多くの場合1,000〜2,000トークン）」を返します。ただし、自分のモデルで試してください。早期終了の論文では、比較した2つのモデルのうち強い方でサブエージェントが最高スコアとなり、弱い方では最悪の部類でした。サブエージェント、スキル、フックがどう組み合わさるかは、Agentic Engineeringのガイドで解説しています。
• コンテキストサイズ別に測る。 自分の評価セットを複数の入力長で採点し、早々の打ち切りを記録してください。それがなければ、ここまでの対策はすべて当て推量です。

Anthropicは、これらを組み合わせた場合の数字を公表しています。社内のエージェント型検索の評価では、メモリツールとコンテキスト編集の組み合わせでベースラインより性能が39パーセント向上し、コンテキスト編集だけでも29パーセント向上しました。100ターンのウェブ検索テストでは、コンテキスト編集によってトークン使用量が84パーセント減りました。ただし、これはベンダーが自社製品について出した数字なので、約束ではなく方向性として読んでください。

チャットアシスタントやコーディングエージェントを使っている場合：

• 1つのタスクに1つのチャット。 Claude Codeのベストプラクティスガイドはこう書いています。「より良いプロンプトで始めたクリーンなセッションは、修正が積み重なった長いセッションをほぼ常に上回る」。OpenAIのCodexガイドも同じ意見です。「一貫した作業のまとまりごとに、チャットを1つにする」。
• 修正に2回失敗したら始め直す。 これはClaude Code自身の経験則です。/clearを実行し、そこまでにわかったことを盛り込んだ、より良い最初のプロンプトを書きます。
• コンパクションは自分のタイミングで行う。 Claude Code、Codex、Cursorはいずれも、上限が近づくと自動で要約します。焦点の指示を付けて早めにコンパクションすれば（たとえば/compact Focus on the API changes）、何を残すかに自分の意思を反映できます。Claude Codeは「会話の初期に与えた詳細な指示が失われることがある」と注意しているので、恒久的なルールはチャットではなく、CLAUDE.mdのようにエージェントが読み返すファイルに置きましょう。
• メーターを見る。 Claude Codeの/contextはウィンドウを何が埋めているかを、Codexの/statusはウィンドウをどれだけ使ったかを表示します。Cursorは入力欄の横にコンテキストリングを置いており、クリックすると内訳が開きます。

コマンドや既定値はリリースごとに変わります。この表は2026年10月時点の情報として扱い、アップグレード後は使っているツールのドキュメントを確認してください。

---

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です。そして偶然ながら、後者はちょうどOpenAIやGemini 3.1 Proで課金が変わるあたりでもあります。

---

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

以下は普遍的な真理ではありません。本番でそれなりに通用する出発点です。

チャンクサイズ。 散文なら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パーセントというルールの近くに着地するはずですが、そうならない場合は、ヒューリスティックより自分の評価結果を信じてください。評価ハーネスがまだないなら、LLM Evalsスタックのガイドでツール類を解説しています。

2つ目はモデルを上げたときに何が起きるかで、2026年に多くのチームがつまずいた点です。AnthropicのトークナイザーはClaude Opus 4.7で変わり、同じテキストが内容に応じておよそ1.0〜1.35倍のトークン数になりました。Anthropic自身は「約30パーセント増」とまとめています。10月7日にリリースされたHaiku 5.5も新しいトークナイザーを使うので、Haiku 4.5から移行するパイプラインでは、同じテキストでもトークン数がおよそ30パーセント増えます。文書が増えたのではありません。予算が縮んだのです。1年前にトークン上限を固定したまま、その下のモデルを差し替えたのなら、その上限の意味は今や別物になっています。しかもログの中に、それを知らせてくれるものは何もありません。

クエリがそう言っているときは、検索を丸ごと飛ばす。 「今アップロードした文書を要約して」は単一ドキュメントのタスクです。小さな分類器で検出し、検索をスキップして、レイテンシを節約し、無関係なノイズを持ち込まないようにします。

要約と剪定のレイヤー。 非常に長い履歴では、組み立ての前に古い材料を圧縮します。要約自体もトークンを消費するので、本当に効いているかは計測してください。

---

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

名前を付けておく価値があるほど繰り返される罠が、いくつかあります。

「とりあえず全部コンテキストに突っ込む」。 ウィンドウが倍になるリリースのたびに魅力的に見えます。しかし劣化は静かに進むので、スポットチェックは通ってしまい、本番では、まさにコンテキスト横断の推論を必要としていたクエリで落ちます。出す前に、想定サイズで評価を回してください。

「とにかくRAGを使う」。 反射的に検索すると、単一ドキュメントのケースを取り逃がします。50ページのPDFをインデックスしてtop-5チャンクを引くやり方は、何もしないよりはたいてい良いものの、PDFをそのまま送るやり方には負けます。

「組み立て後のトークン数を見ない」。 top-kを「入るだけ」に設定したチームが、3か月後に平均プロンプトが350Kトークンに達し、精度が静かに落ち、誰も読んでいなかった閾値のせいで請求額が倍になっていたと気づく、という話です。組み立て後のコンテキストサイズを一級の指標として追跡し、アラートを設定してください。

「自動コンパクションに任せておく」。 自動コンパクションはセッションを生かし続けてはくれますが、正確さまでは保ってくれません。要約は指示を取りこぼしますし、Compaction Cliffの論文では、ルールの保持率がラウンドを重ねるごとに下がっていきました。何を残さなければならないかを決め、それを会話の外に保存してください。

「モデルが良くなったから評価は省く」。 モデルのアップグレードは、正しいアーキテクチャを変えますし、気づかないうちにトークンの勘定まで変えることがあります。モデルが変わったら評価をやり直してください。

「静かな失敗は安全な失敗だと思い込む」。 ディストラクターがある条件では、ハルシネーションを起こすモデルもあれば、回答を控えるモデルもあります。長期タスクでは、ただ早々に止まるものもあります。自分のモデルがどれをやるのかを把握し、そのための計装をしてください。

---

2026年に変わったこと：モデル、価格、コンパクション

以下の内容の大半は、2026年9月から10月初めにかけて変わりました。Anthropic、OpenAI、Googleがそろって新しいモデルを出した時期で、変化のすべてが同じ方向を向いているわけではありません。

モデルの顔ぶれが入れ替わった。 Anthropicは9月1日にClaude Fable 5.1、9月22日にOpus 5.5、9月28日にSonnet 5.5、10月7日にHaiku 5.5をリリースし、いずれも1Mトークンのウィンドウを備えています。OpenAIは9月3日にGPT-6 Astra、9月22日にGPT-6 SolとLuna、9月29日にGPT-6.1 Solを出し、どれも1.05Mのウィンドウと最大922Kトークンの入力を持ちます。Googleは9月2日にGemini 3.8 Flashの一般提供を開始しましたが、Gemini 3.1 Proはまだプレビュー版のモデルです。

最高の検索スコアは跳ね上がり、モデル間の差は巨大になった。 OpenAI独自の8-needleテストであるOpenAI MRCR v2で、GPT-6 Astraは512Kから1Mトークンの区間で96.3パーセントを記録したとOpenAIは報告しています。GPT-5.6 Solは73.8パーセントでした。Googleのモデルカードは、Gemini 3.1 ProをGoogle独自のMRCR v2（8-needle）で採点しています。名前は同じでも別のデータセットで、結果は128Kまでの平均で84.9パーセント、1Mでは26.3パーセントです。つまりベンダー間の差は1つのシグナルであって、直接対決の結果ではありません。どちらの数字もベンダー自身が測ったものです（OpenAIが報告しているのは、推論努力の設定を問わず最も高かったスコアです）。しかもMRCRが測っているのは正しい一節を見つけて再現する力であり、文書全体をまたいだ推論ではありません。コンテキストロットは消えていません。モデルごとに測らなければならないものになったのです。

価格の崖は、いまやベンダーごとに異なる。 OpenAIは今も入力が272Kトークンを超えるとリクエスト全体に割増料金を適用し、GPT-6系のモデルではそれが「入力とキャッシュのレートは2倍、出力は1.5倍」を意味します。GPT-6.1 Solは入力・出力100万トークンあたり$2と$10から$4と$15へ、GPT-6 Astraは$10と$50から$20と$75へ上がります。GPT-5.6 Solの$4と$20は少なくとも2026年11月21日まで続くプロモーション価格で、同じ線を超えると$8と$30になります。GoogleはGemini 3.1 Proの200K超のプロンプトを、$2と$12ではなく$4と$18で課金しますが、Gemini 3.8 Flashにはそうした料金帯がありません。AnthropicはClaude 4.6以降のモデルで1Mのウィンドウ全体を標準レートで課金しています（料金ページによれば「900kトークンのリクエストは、9kトークンのリクエストと同じトークン単価で課金される」）。例外は1つだけで、Haiku 5.5では100,000トークンを超えるプロンプトの料金が5倍になり、$0.10と$0.50ではなく$0.50と$2.50になります。

コンパクションが製品になった。 設定については、上の対策のセクションで扱いました。変わったのは、ベンダーがコンパクションを代わりに実行してくれるようになったことです。Anthropicのドキュメントは、新しいオンデマンドのコンパクションを「利用できる場合は常に」使うよう勧めています。OpenAIのResponses APIは、コンパクションしたコンテキストを、人間が読むことを想定していない不透明なアイテムとして返します。また、9月10日からパブリックベータとなっているAgents APIは、「セッションのオーケストレーション、コンテキストのコンパクション、復旧はOpenAIが担う」とうたっています。ただし、既定値には注目してください。100万トークンのウィンドウを持つベンダーが、閾値式のコンパクションを150Kで始めるのです。

キャッシュは安くなった。それでもコンテキストロットは直らない。 キャッシュ読み出しの価格は、Anthropicのほとんどのモデルで基本入力価格の10分の1、Opus 5.5とSonnet 5.5では20分の1、Fable 5.1では40分の1です。OpenAIはほとんどのモデルで10分の1、GPT-6.1 Solでは20分の1を課金し、GPT-5.6以降はキャッシュ書き込みを入力レートの1.25倍で課金しています。安定したコンテンツに対して同じクエリを繰り返す場合、キャッシュは大幅に安くなります。ただし、モデルが長い入力をどう扱うかは変わりません。しかもOpenAIでは、キャッシュされたトークンも272Kを超えると、キャッシュされていない入力と同じように価格が2倍になります。

変わっていないのは、その下にある結果の方です。より良いモデルは曲線を動かしますが、ウィンドウを大きくするだけでは何も直りません。そして鮮度が求められる、マルチテナントで、複数ソースにまたがるワークロードには、依然として検索が必要です。

これはコンテキストエンジニアリング全般に現れるのと同じ規律です。プロンプトに何を入れるかと同じくらい、何を入れないかが効きます。また、検索レイヤーが他の入力経路と同じだけの精査に値する理由でもあります。間接プロンプトインジェクションは、ユーザー経由ではなく、取得した文書を経由してやってくるからです。

---

今日から使える意思決定フレームワーク

新しい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未満、Gemini 3.1 Proなら200K未満、Claude Haiku 5.5なら100K未満、それ以外なら実測した安全予算の内側：問題ありません。
• それらの線のどれかの近くをうろついている：リランカーを足して検索セットを削ってください。たいていの場合、より良い答えとより少ない請求が同時に手に入ります。

ステップ8：長いセッションやエージェントとして動かすか。

• Yes：何を消すか（古いツール実行結果）、何をコンパクションするか、何を会話の外に置くか（ルール、進捗）、そしていつエージェントに新しく始め直させるかを、最初に決めておきます。早々の打ち切りも記録してください。
• No：単発のリクエストなら、ステップ1〜7だけで十分です。

多くの本番システムはハイブリッドに落ち着きます。現実のワークロードは、純粋なロングコンテキストを壊す制約（マルチテナンシー、鮮度、コスト、引用）を少なくとも1つ持ち、同時に純粋なtop-k RAGを壊す制約（単一ドキュメント推論、コンテキスト横断のクエリ、探索）も少なくとも1つ持っているからです。

同じスキルには、人間版もあります。推論プロセスの前に何を差し出す価値があるかを決める作業は、注意深い読み手がずっと手でやってきたことであり、ハイライトはその判断を明示的にしたものです。Glaspのウェブハイライターは、ページ全体ではなく、あなたが残す価値があると判断した一節を保持します。これは人間のリランカーを備えた検索です。その集合に自分のツールを向けたいなら、GlaspのMCPコネクタがハイライトをLLMに直接公開します。その構成についてはノートをMCPサーバーに変えるで詳しく書きました。

---

よくある質問

LLMにおけるコンテキストロットとは何ですか？

コンテキストロットとは、入力が長くなるにつれてLLMがその入力をうまく使えなくなっていく、実測された低下のことです。しかもそれは、コンテキストウィンドウが埋まるはるか手前で起こります。検索と推論の精度は一様でない形で、モデルごとに異なる幅で下がり、ディストラクターのテキストが答えに似ているほど速く下がります。Chromaは、テストした18モデルすべてで、一貫した干し草の山の方がシャッフルしたものより害が大きいことを見つけました。Anthropicのドキュメントも、いまではこの言葉を直接定義しています。「トークン数が増えるにつれて精度と再現率は低下する。これはコンテキストロットとして知られる現象である」。1Mトークンのウィンドウを埋めても、1Mトークン品質の答えが買えるわけではありません。

コンテキストロットはどう直せばよいですか？

より少なく、より良いトークンを送ることです。アプリやエージェントなら、詰め込む代わりに検索してリランクする、長い文書を質問の前に置く、古くなったツール実行結果を消す、ウィンドウが埋まる前にコンパクションする、ルールと進捗を会話の外に置く、探索をサブエージェントに任せる、ということです。チャットツールやコーディングツールなら、1つのタスクに1つのチャットを使う、修正に2回失敗したら始め直す、焦点の指示を付けて早めにコンパクションする、恒久的なルールをCLAUDE.mdのようにエージェントが読み返すファイルに置く、ということです。

Claude Opus 5.5やGPT-6のような新しいモデルなら、コンテキストロットは直りますか？

コンテキストロットを免れるモデルはありませんが、モデル間の差は大きく開いています。OpenAIは、自社の8-needle MRCRでGPT-6 Astraが512Kから1Mトークンの区間で96.3パーセントだったと報告しています。一方、Googleのモデルカードでは、Google版の同じテストでGemini 3.1 Proは1Mで26.3パーセントです。データセットは異なりますが、無視できないほど大きな差です。Anthropicのドキュメントはコンテキストロットを、入力が増えることに伴う一般的な性質として説明しており、Claude Codeのドキュメントも、性能はコンテキストが「埋まるにつれて劣化する」と書いています。実際に使うモデルを、自分の入力に似たデータで測ってください。

2026年でもRAGはまだ有効ですか？

はい。どのウィンドウにも収まらないコーパス、1時間単位で変わるデータ、テナント単位のアクセス制御、そして引用のためには、依然として検索が必要です。時代遅れになったのは、古典的なtop-5 RAGを唯一のパターンとして使うことの方です。現在のデフォルトはハイブリッド、つまり上限のある集合を検索で集め、その全体に対して推論する形です。コンテキストウィンドウの拡大が変えたのは「どれだけ取得するか」であって、「取得するかどうか」ではありません。

ロングコンテキストはRAGを置き換えますか？

一般論としては置き換えません。ChromaのContext Rotレポートは、ウィンドウが埋まるはるか前に性能が劣化することを示しました。そしてベンダーも、それに同意しているかのように製品を作っています。Anthropicの閾値式コンパクションは1Mトークンのモデルで既定150K、OpenAIは入力が272Kトークンを超えたリクエストに割増料金を適用し、GoogleはGemini 3.1 Proの200K超のプロンプトに高い料金を課します。ただし、実測した安全予算に収まる1つのまとまった文書に対しては、ロングコンテキストはRAGを置き換えます。

コンテキストロットが効き始めるまでに、検索セットはどのくらいの大きさにできますか？

自分のモデルで検証すべきですが、妥当な出発点は仕様上のウィンドウの20〜40パーセントです。200Kのモデルなら40K〜80K、1Mのモデルなら200K〜400Kです。ただし課金上の理由から、OpenAIでは272K未満、Gemini 3.1 Proでは200K未満、Claude Haiku 5.5では100K未満に収めたいところです。マルチホップの質問を集めた小さな評価セットを作り、コンテキストサイズごとに精度を測り、基準を満たす最大サイズを採用してください。

プロンプトキャッシュはコンテキストロットを解決しますか？

いいえ。キャッシュが直すのはコストであって精度ではありません。キャッシュ読み出しの価格はいまや、モデルによって通常の入力価格の10分の1から40分の1なので、安定したコンテンツに対するロングコンテキストのクエリは大幅に安くなり、RAGのコスト優位は縮みます。それでもモデルは同じ長さのコンテキストを読み、同じように劣化します。つまり、同じだけ弱い答えを安く買っているだけです。OpenAIでは、キャッシュされたトークンも272Kを超えると価格が2倍になります。

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

本番のハイブリッド構成のほとんどでは、使うべきです。取得したtop 50〜200チャンクをクロスエンコーダーで採点すると、推論段に届くものの質が大きく上がります。リランクを省くと、弱い精度を補うためにトークンを詰め込むことになりがちで、劣化ゾーンと価格の崖の両方に近づきます。ハイブリッドのパイプラインに加えられる変更の中で、最も効果の大きいものの1つです。

長いタスクでエージェントが早々に止まります。これはコンテキストロットですか？

おそらくそうですし、いまは名前も付いています。2026年の論文Diagnosing and Mitigating Context Rot in Long-horizon Searchは、これを早期終了（premature termination）と呼んでいます。コンテキストが重くなると、モデルはウィンドウを使い切る前にあきらめたり、自ら不確かだと示した誤答を返したりし、その発生率はコンテキスト長とともに上がります。コンテキスト管理（コンパクション、トリミング、サブエージェント）が効くのは主に、この率を下げてエージェントに探索を続けさせるからです。早々の打ち切りそのものを、独立した指標として計装してください。

---

おわりに

ウィンドウを大きくするリリースはどれも、同じ暗黙の約束を運んできます。「もう設計しなくていい、全部放り込め」という約束です。Chromaは、その約束がなぜ実現していないのかに確かな数字を与えました。2026年の研究は、誰も見ていなかった2つ目の失敗モードを付け加えました。そして根底にある数学（softmaxの希釈、位置の外挿、学習分布）は、100Mトークンになってもきれいには実現しないと告げています。

残るのは、退屈で生産的な答えです。検索を作る。チューニングする。リランカーを足す。モデルがもう必要としないものは消し、決して失ってはならないものは会話の外に置く。安全コンテキスト予算はスペックシートを信じるのではなく計測して決め、モデルやそのトークナイザーが変わったら測り直す。2026年9月から10月初めにかけては、Anthropic、OpenAI、Googleのいずれでもそれが起きました。答えを含む中で最も小さく、最も関連の高いトークン集合を送る。その上でモデルに推論させる。出典を引用する。

2026年ならではの妙味は、ベンダー側もあなたに同意しているかのように設計するようになったことです。OpenAIの272Kの線、GoogleがGemini 3.1 Proに引いた200Kの線、Haiku 5.5の100Kの線、そして100万トークンのClaudeモデルで150Kに置かれたコンパクションの既定値は、いずれも「実用ウィンドウは広告の一部にすぎない」という自認です。Anthropicが上位モデルで採っている、長さによらない一律の料金は、価格の崖をなくしますが、精度のコストまではなくしません。それに一律のレートでも、トークンが少なければその分だけ安く済みます。だから規律あるアーキテクチャは、同時に安いアーキテクチャでもあるのです。この2つが同じ方向を指すことは、めったにありません。

どの仕事にどのモデルを向けるかという、より広い地図が欲しければ、タスク×モデルのマトリックスにまとめてあります。アーキテクチャの判断は、モデルのリリースより長生きします。ここを正しく押さえておけば、次のアップグレードは強制的な書き直しではなく、タダで手に入る改善になります。