大きなコンテキストウィンドウを信頼するな

2026年6月14日原文(garrit.xyz)

概要

LLMの コンテキストウィンドウ には「スマートゾーン」と「ダムゾーン」が存在
100kトークン 付近で性能が大きく低下
広告される大容量ウィンドウは 実用的な作業セット とは異なる
自動要約 やアーティファクト活用で性能劣化を回避
コンテキストは予算管理 として扱うべき

LLMのコンテキストウィンドウ：スマートゾーンとダムゾーン

LLMの コンテキストウィンドウ は「スマートゾーン」と「ダムゾーン」に分割される考え方
スマートゾーン ：モデルが鋭く動作する領域
ダムゾーン ：注意力が落ち、過去の情報を忘れ始める領域
境界は 約100kトークン 付近に存在
広告される 200kや1Mトークン のウィンドウは、実際の「使える」範囲を示さない
研究（ RULER や Chroma のcontext rotレポート）でも、実効コンテキストは公称値のごく一部であることが示されている
コンテキストウィンドウの 大きな数字はマーケティング用 であり、実際の性能とは乖離

コーディングエージェントとコンテキスト管理の課題

現代の AIエージェント は大量のトークンを高速消費
複数ファイルの読み込み、長いデバッグ、広範なテストで すぐ100kトークン超え
エージェントは ダムゾーン に突入しても気づかず進行
ベンダーは大容量ウィンドウを宣伝するが、 実際の作業効率には直結しない

自動要約とアーティファクトによる対策

Claude Codeなどのツールは 自動コンパクション（要約） 機能を搭載
- セッションが長くなると履歴を要約してリフレッシュ
- ただし、 要約自体が既に劣化したモデルで生成 されるため完全ではない
より良い方法として、 新規セッション を開き、自分で書いた 仕様（spec） を渡す手法
- 手動で何が重要かを選別できるため、 自動要約より高品質な引き継ぎ
- 「パンくずリレー」方式で次のセッションや担当者がスムーズに作業継続可能

アーティファクト中心のワークフロー設計

obra/superpowers や mattpocock/skills などのプロジェクトでは、アーティファクトを基盤にしたエージェントワークフローを設計
- PRD、プラン、スキル、サブエージェントへの引き継ぎなど
- 各アーティファクトが「スマートゾーン」を維持するための情報移動手段
作業セッション内の情報をアーティファクトに移し、次のセッションで再利用 することで、注意力の低下を防止

コンテキストウィンドウの「予算管理」的活用法

コンテキストウィンドウは有限なリソース として扱うべき
実際に「効く」のは 最初のチャンク のみと仮定
ライブセッションからアーティファクトへ情報を移す ことで、注意力の配分を最適化
「使える部分」と「広告される数字」のギャップを常に意識した運用が重要

Hackerたちの意見

基本的にAIのプロダクトマネージャーみたいに振る舞って、提案する機能ごとに短いPRDを書かせることで、かなりの効果を得てるよ。そうすると、これまでに作ったものの参照ができるし、各機能がそれぞれ独立した会話になるから、ぶれにくくなるんだ。これが、AIが暴走しないようにしつつ、過去の決定を参照できるいいバランスだと思ってる。ポコックのやり方（PRDをあまり使わずに、合意を得るために深く議論する）で嫌なのは、最初のやり取りの貴重な時間を無駄にすることかな。

└

アドホックなのか、それともオープンスペックみたいなもっと構造化されたアプローチを使ってるの？自分も最初に計画を立てることが多いけど、それはセッション中のTODOとして残るから、後で参照するのが難しいんだよね。

アンソロピックが1Mトークンのコンテキストウィンドウをサブスクリプションプランで提供してから、オーパスではそんな経験はしてないよ。500kトークンを超えるのは日常茶飯事で、時には800kトークン近くまで行くこともあるけど、この問題は見たことがない。限界に近づくときに900kトークン以上で多少感じることはあるけど、著者が言うほど深刻ではないと思う。（それに、単一のタスクに取り組むときや、関連するタスクのシリーズでは、そんなにコンテキストウィンドウを埋めることはまずないし、200kから600kトークンくらいが一般的だよ。）誰もがこの経験をするわけじゃないとは言わないけど、そんなに頻繁に見る人がいるのは不思議だね。

└

フェイブルでも似たような経験があったよ。1Mのコンテキストの70%以上を使っても、まだシャープでメモリの問題もない。

└

これもこの投稿の別の問題だね。著者はクロードについて言及してるけど、どのモデルかは明確にしてないし…「ランチまでに100kトークン」ってのも自分の見解じゃない。新しいモデルは初期の探索段階ですでにそれに達するよ。

└

オーパス4.6は200kを超えると調子が良かったけど、4.7はスキップした。4.8は350kくらいまでは良かったし、フェイブルは400kを超えても素晴らしかった。自分の限られたテストでは、品質は上向きにトレンドしているように見えるね。

└

これよく言われるけど、オーパスモデルが10万トークン未満で基本的なリコールミスをするのを見ると、マジで驚くよ。個人的には、オーパスは6万トークン未満が賢いゾーンだと思ってる。4.7や4.8はトークナイザーが細かくなってるから、もっと悪化してるね。

└

ギャンブラーがポーカーのテーブルで言うように、「座った時にマークが誰かわからないなら…」

└

自分のRustプロジェクト用にカスタムビルドコマンド（yarn build:lib）を作ってるんだけど、GLMで12万、オーパスで大体20万から30万くらいの経験がある。その後はデフォルトでcargo buildになるね。

└

僕はよく30万を超えるけど、80万で働いたこともある。でもそれは明らかに問題があるね。大きなコンテキストウィンドウは問題によっては使えるけど、300k未満の小さい方が効果的だと感じるよ。

└

同意。クラウドのClaudeたちは、リリースごとにどんどん良くなってる。Opus 4.5では200kの制限に近づくとツールコールが失敗し始めて、Opus 4.6では約300kまでいけるようになって、Opus 4.7では400kまで伸ばせるようになった。Opus 4.8では、500kを超えるセッションも楽にできた。正直、Fableとは限られた時間しかなかったけど、800-900kに達するセッションもいくつかあったよ。

エージェント内部で何が起こっているかの考慮は、ソフトウェア開発の一部には長くはならないと思う。個人的には、LLMやエージェントはすでにブラックボックスだと見てる。各機能リクエストを複数のLLMに渡して、結果を比較するんだ。「セッション」を手動で使うことは全くないよ。結果だけを見る。気に入らなければ、「git reset --hard」して、プロンプトを変えて機能リクエストを再スタートさせる。どのエージェントが一番パフォーマンスが良いかを把握するために、ログを取って、どのエージェントが自分の要求を最も満たしているかをELOスコアで計算してる。このスコアは自分にとって重要で、エージェントがどうやってそれを達成するかはあまり気にしてない。

Hacker Newsで議論の続きを見る

ハクソク