大きなコンテキストウィンドウに騙されるな
コンテキストウィンドウの数値が実際の性能と相関しない問題。
LLMの注意機構は効果的なコンテキストを保つことが困難で、自動サマリーでも遅延が生じる。
有効な解決策として、プロジェクトでは小さな名付けられたアーティファクトを使用し、情報を会話外に移すことで注意の範囲を制限する方法が提案される。
AI開発者向けの記事で、大規模なコンテキストウィンドウの限界が指摘されています。筆者が感じていた不安を具体的に表現し、AIモデルの性能に影響を与える要因について解説しています。
コンテキストウィンドウの限界
AIモデルのコンテキストウィンドウは、スマートゾーンとドウブゾーンに分かれます。スマートゾーンではモデルが正確に動作しますが、ドウブゾーンでは記憶が薄れ、情報が忘れられやすくなります。この境界は約10万トークン程度で、広告で表示される数値よりも実際の有効な範囲ははるかに小さいとされています。
コードアーキテクチャの限界
コード生成アーキテクチャは機能しますが、根本的な注意機構の問題を解決していません。大規模なコンテキストウィンドウはマーケティング用の数字であり、実際の性能は広告の数値に比例しません。研究では有効なコンテキストが広告の数値の一部にすぎず、性能が徐々に低下することが示されています。
代替策と実践
アーキテクチャの改善に加えて、開発者は新しいセッションを立ち上げ、手書きの仕様書を渡す方法を採用しています。これは自動的なサマリーとは異なり、今後の重要な情報の選別が可能で、作業セッションをスマートゾーンに保つための戦略です。
まとめ
AI開発者はコンテキストウィンドウの限界を理解し、有効な情報を外部に移動させることが重要です。これにより、モデルの性能低下を防ぎ、作業効率を向上させることができます。
原文の冒頭を表示（英語・3段落のみ）
I recently watched a video that put a name on something I'd been feeling. The author splits an LLM's context window into two zones. There's the smart zone, where the model is sharp, and the dumb zone, where attention drops off and the model starts forgetting what you told it five minutes ago. The cutoff sits somewhere around 100k tokens. It doesn't matter how big the advertised context window is.
This matters because coding agents will happily walk you straight into the dumb zone. A modern agent burns through tokens fast. A few file reads, a long debug session, a sprawling test run, and you're at 100k before lunch. Meanwhile vendors keep advertising windows of 200k, 1M, even 2M, as if those numbers represented a usable working set. They don't. Studies like RULER and Chroma's report on context rot show that effective context is a fraction of the advertised number, and that performance degrades gradually as you fill the window.
Large context windows are mostly a marketing number. The architectures behind them work, but they paper over a problem the underlying attention mechanism doesn't really solve. The number on the box gets bigger every release. The usable part doesn't keep up.
※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。
Hacker News コメント
機械翻訳。HN の元スレッド ↗
文脈の腐敗を実際に対処する方法として、エージェントループをトランスポーズする関連技法を使用しています。https://alejo.ch/3jt In essence, 構造化データから動的にプロンプトを生成し、短いエージェントループを多数実行します。各ループは最終目標に向けて小さなステップを進めます。
原文
The approach we're taking to deal with this very real context rot is using a bunch of related techniques which we call transposing the agent loop: https://alejo.ch/3jtIn essence, we run many short agent loops, generating their prompts dynamically from structured data. Each loop advances the state in a small step towards the final goal.
私は基本的にAIのProduct Managerのように振る舞い、提案する各機能について短いPRDsを書かせることで、多くの成果を得ています。時間の経過にわたって全ての建設計画を記録しますが、同時にそれぞれのプロジェクトが独自の会話を持つため、安定性も保ちます。この方法は私にとって、AIが暴走することを防ぎつつ過去の決定を参照できるバランスが取れています。ただしPocockの方法には一つ大きな問題があります。即ち、深い議論を行うことで初期のやり取りの時間を無駄に消費してしまう点です。
原文
I'm getting a lot of mileage out of basically acting like the AI's Product Manager, and insisting that it writes up short PRDs for every feature we propose to build. That gives it a reference over time of everything that has been built, but also makes it less liable to drift with each one. Each one gets its own conversation. For me this is a happy medium between stopping it going off the rails but also making sure it can reference past decisions when it needs to. The one thing I dislike about Pocock's method (not to use PRDs so much but to have an in depth discussion to get alignment) first is it wastes a lot of the best window on that initial back and forth.
この現象は私がOpusを使用して以来、Anthropicが1Mトークンコンテキストウィンドウをサブスクリプションプランで提供して以降、経験したことがないです。500kトークン以上、時には800kトークン近くまでコンテキストを拡張し、この問題は発生しません。900kトークン付近やそれ以上の場合に多少見られますが、著者が指摘するほど深刻ではありません。通常、私は200kから600k程度の範囲でコンテキストを使用します。私はこの現象が全くないと言っているわけではないですが、多くの人が頻繁に経験することが不思議です。
原文
This has not been my experience with Opus since Anthropic released the 1M token context window for use under the subscription plans. I routinely push past 500k tokens, even sometimes up to around 800k tokens, and don't see this problem. I've seen it to some extent when getting truly near the limit, up around and above 900k tokens, though what I see isn't as severe as the author seems to see.(And I rarely fill the context window that far anyway when working on a single task, or a series of tasks that are related enough to warrant the same context; more typical is anywhere between 200k and 600k or so.)I'm not saying that no one ever has this experience, but it's odd to me that some people see it so often that it warrants giving it a name.
考えるべきことはエージェントの内部で起きることではなく、長くはソフトウェア開発に含まれないだろう。個人的には既にLLMsとエージェントをブラックボックスとして見ている。各機能要求を複数のLLMに与え、結果を比較する。私は手動で「セッション」を使用しない。ただし、出力結果を見る。気に入らない場合は、「git reset --hard」、プロンプトを変更し、再度機能要求を実行する。最も優れたエージェントの感覚を保つためにログを保持し、ELOスコアで各エージェントが私の要望に応えるかどうかを計算している。このスコアは私にとって重要だが、エージェントがどのように達成したかはあまり重要ではない。
原文
Considerations about what goes on in agents internally will probably not be part of software development for long.Personally, I already see LLMs and agents as blackboxes. I give each feature request to multiple LLMs and then compare the results. I don't manually use "sessions" at all. I just look at the outcome. When I dislike it, I "git reset --hard", change my prompts and restart the feature request.To have an ongoing sense of which agents perform best, I keep a log and calculate an ELO score of which agents meet my demands best. This score is imporant to me, not so much how the agent achieves it.
私はClaude Code Opus 4.8で20%のトークンコンテキスト（200k）を使用してソフトウェア開発タスク（すべての段階）に問題はありませんでした。常にコアソースファイルと現在作業中のものを前面にロードします。約20％の場合、自動的に新しいセッションの準備をし、クリアします。正直なところ、私はこの方法を用心深く行っています。これは、個人的な経験に基づくもので、長いコンテキスト劣化を避けるためです。短時間ながらFable 5にアクセスした際には、45分以上の長時間実行タスクが30-40％のゾーンで問題なく動作しました。
原文
I've had no problem with Claude Code Opus 4.8 effort max using 20% token context (200k) on software development tasks (all stages). I aways load core source files and the ones we are working on up front. Around 20%, I make it autoprepare for a new session and clear.Admittedly I have been doing this precautiously, based on anecdotal evidence, not because I had bad experiences with longer context deterioration myself.In the brief time I had access to Fable 5, it went on long running tasks (>45 mins) into the 30-40% zone without apparent context coherence problems.
以下は翻訳です。
私はエージェントループに単純な制約を適用することでコンテキストサイズの問題を回避してきました。私のやり方は、ユーザーのトップレベル会話スレッドでツールの呼び出しを一切許可しないことです。ツールの呼び出しが必要なものは全てエージェントの再帰呼び出しの中で行われ、結果は呼び出し元に返されます。私は1千万LOC超のコードベースで高レベル会話を丸一日維持することができましたが、意味のあるトークン制限には一切触れていません。50万トークンを再帰呼び出しで消費しても根の会話スレッドでは10万トークン以下です。「ナルニアに降りる」たびにエージェントを再起動する必要がありますが、これは常に全てをカバーしようとする大きなフラットコンテキストを保持するより効率的です。再帰はトークンの使用を効果的に制御しますが、深さ1以上では観測されていません。エージェントが数回試しましたが、実際のパフォーマンスに改善は見られませんでした。外部シンボリック再帰は前提モデルが訓練されたものではありません。彼らは再帰を上手く模倣しますが、トークン使用の削減を目指す場合には望ましくありません。
原文
I've been able to avoid context size issues by applying one simple constraint to my agent loop. What I do is prevent all tool calling in the user's top-level conversation thread. Anything that needs to tool call must happen in a recursive invoke of the agent, which returns whatever results to caller.I can keep the same high level conversation going for an entire day over a million LOC+ codebase without ever hitting meaningful token limits. No compaction or summarization tricks needed. I can burn 50 million tokens in recursive calls and still not touch 100k tokens in my root conversation thread.There is some rework needed to "bootstrap" the agent each time it has to descend back into Narnia, but this is still far more efficient than carrying around one big flat context that tries to cover everything all the time.Recursion is very effective at controlling token use, but it can only go so far. I've not observed any uplift for recursive depth beyond 1. I have seen the agent attempt it a few times, but the practical performance is simply not there. External symbolic recursion does not appear to be something the frontier models have been trained for. They are fantastic at emulating recursion in context, but we don't want that if we are trying to achieve a reduction in token use.
Opusの最近のバージョンは100kを超えると問題ないが、通常は200k以下に抑える。ただし、このアプローチも「メモリ」システムがモデルを愚かにする理由でもある。彼らにはメモリがない。文脈しかない。無関係な事実を文脈に押し込むと、問題の文脈は減る。余計な注意散漫さが減り、結果が良くなる。
モデルに何かを記憶させる方法は、人間の開発者がプロジェクトを他の開発者に親切にするために行うように、作業内容をドキュメント化することだ。索引ページと計画表、チェックリストを備えたコンパクトなMarkdownファイルをリポジトリにチェックインすることが、理想的なモデル用メモリであり、問題の追跡に役立つ。コードレビューも人間や別のモデルによって行うことができる。デメリットはない。
原文
Opus in recent versions is fine beyond 100k, but I usually do try to keep it under 200k.But, this is also why so-called "memory" systems are usually a mistake that make the models dumber. They don't have memory, they only have context, and every irrelevant fact you shove into the context is less context for the problem. Less distractions, better results.The way to have the agent remember things is to have it document its work, like a human developer would do if they wanted their project to be friendly to other developers working on it. Good developer docs with an index page and a good plan with checklists, in concise Markdown files, checked in to the repo is the ideal memory for models and the ideal docs you need to figure out WTF the model has been up to. Helps with code review, too, whether by humans or another model. There's no down side.
私はこの点数が文脈の質と一貫性にどれだけ依存するか疑問に思う。例えば、有用な情報で満たされた長い文脈は問題ないかもしれないし、むしろ有益かもしれない。一方、文脈に無関係な話題や矛盾した指示が含まれると害になるだろう。モデルが愚かになる要因として研究は行われているのか？文脈の長さと質のどれくらいが原因か？
原文
I wonder how much this depends on the quality and consistency of the context?For example, it may be the case that a long context full of useful information relevant to the task is completely fine, perhaps even beneficial. And if the context contains a bunch of unrelated tangents and conflicting instructions, then it will be detrimental.Have there been studies on what makes models get dumber? To what extent is context length to blame vs context quality?
LLMの文脈依存性を評価する
原文
Evaluating the Sensitivity of LLMs to Prior Contexthttps://arxiv.org/abs/2506.00069
はい、文脈管理が鍵です。私自身のフレームワークを構築し、多くの時間をデバッグに費やしていますが、問題は文脈サイズの数字そのものよりも、ウィンドウ内にゴミや誤った方向性がある確率が高く、それらが重要な事柄を覆い隠していることです。これは、LLMが直前のアプローチで失敗したことを繰り返すなどとして現れます。文脈ウィンドウの頻度は、正しいかどうかに関わらず重み付けされます。私は多くのトリックを持っており、例えばLLMに検索用のツールを与える代わりに、ツール自体を探させるなどしています。しかし、大きな解決策は、超能力のようなものでLLMを強制的にステージを進ませるプロセスで、コントロールする文脈が継続します。
原文
Yes context management is key.I do my own framework and spend a lot of time trying to debug this and it’s not so much the context size in hard numbers but rather the probability that there is debris or wrong directions in the window that are drowning out the things the user thinks are important.This manifests in the llm that keeps going back to doing the thing that failed when they tried it just before the last approach etc. The frequency of things in the context window give weight even if they are the wrong things.I have a lot of tricks like not giving the llm lots of tools but rather giving it a tool it can use to search for tools etc.But the bigger solution is in process where you use something like superpowers to force the llm through stages and you control the context that carries forward.