100K のコンテキストで十分：大きなウィンドウを買うのではなく、記憶を圧縮する

ウィンドウの大きさは問題じゃない

数か月おきに、どこかのラボがコンテキストウィンドウの大きいモデルを出して、会話は振り出しに戻る。20万トークン、次は100万、その次は200万。暗黙の約束はこうだ。記憶はハードウェアの問題で、誰かがずっと大きくしてくれる。

billion-context は ranxianglei による TypeScript プロジェクトで、9月下旬から星を伸ばし続けている。そのキャッチコピーは正反対の立場を取る。100K のコンテキストで十分だ。"今のところは十分"ではない。十分なのだ。会話を追記専用のログとして扱うのをやめれば。

これはコーディングエージェントとモデル API の間に挟まるプロキシだ。リクエストはここを通り、圧縮され、転送される。レスポンスは戻る途中で書き換えられる。モデル側は何も変わらない。言いたいのは、高くついていたのは決してウィンドウの大きさではなく、そこに詰め込み続けていたものだということだ。

圧縮はどう動くのか

プロキシは各リクエストを Anthropic 形式か OpenAI 形式でパースし、会話全体に圧縮カーネルを走らせ、モデル自身が呼べる4つのツールを注入する。メッセージの範囲を要約に圧縮する、正確な詳細が再び必要になったら範囲を解凍する、圧縮された要約と可視メッセージをキーワードで検索する、コンテキストの使用量を確認する、の4つだ。

重要な設計判断は、いつ圧縮するかをモデル自身が決めることで、固定のしきい値ではない点だ。ホスト内蔵の要約器はたいていウィンドウがいっぱいになった時点で発火し、カットポイントより前をすべて、取り消せない1つの要約に置き換える。billion-context は小さな範囲で圧縮し、可逆性を保ち、プレフィックスキャッシュを壊さない。

最後の点こそ気にすべきエンジニアリングの詳細だ。プレフィックスキャッシュがあるからこそ、長いエージェントセッションは手の届く価格になる。圧縮のたびに会話の先頭を書き換えたらキャッシュは外れ、履歴全体にもう一度満額を払うことになる。プロジェクトは、健全なセッションならプレフィックスキャッシュのヒット率は 95-97% を保てると主張し、圧縮自体のオーバーヘッドは 2% 以下だという。いずれも自己申告の数字で、ヒット率の低下を原因に紐づけるコマンドも同梱している。原因はたいてい上流のキャッシュ TTL 切れか、モデルの切り替えだ。

この主張を信じさせる数字

ベンダーはいつでもトークン削減をうたう。ここが珍しいのは、コードと一緒に縦断研究が付いてくることだ。4か月半、3つのホスト、174,327 回のモデル呼び出し、1つのホストで累計入力トークン 18.76B、全ホスト合計で約 24.7B。レポートによれば、最長のセッションは 8,584 回から 12,049 回の呼び出しにわたり、204,800 トークンのモデルでコンテキストウィンドウ違反はゼロだった。

効いているのは"ウィンドウ違反ゼロ"という一文だ。会話がモデルより大きくなって死んだセッションは一つもない、という意味だから。研究の他のすべては、その一文の下流にある。

これは"長いセッション"の意味も変える。ほとんどの人はコンテキスト上限を、ゆっくりした劣化として経験する。エージェントはどんどん曖昧になり、2時間前の制約を忘れ、すでに読んだファイルを読み直し始める。ウィンドウが本当に埋まるころには、セッションはたいてい前からダメになっている。常時走る圧縮が扱うのは、その劣化であって、ハードストップだけではない。

あなたのワークロードで宣伝どおりに効くかは、また別の話だ。主張は自己申告で、ベンチマークは作者自身の使い方であり、"トークン5分の1"はセッションの重複度に完全に依存する。40個のファイルを読んで3か所を直すセッションは見事に圧縮できる。巨大なファイルを1つ読んで、行ごとに推論するセッションは、畳める冗長性がずっと少ない。

日々のループがどう変わるか

実際の差は、長いタスクの中だるみの部分で出る。リファクタを進めるエージェントには3種類の記憶がある。何を決めたか、何を読んだか、何を試して捨てたか。生のトランスクリプトはこの3つを同じ解像度で保持する。だから40ファイルのリファクタが、もう関係のないスタックトレースでウィンドウを埋めてしまう。

圧縮を使えば、エージェントは決定をフル解像度で残し、証拠は要約に畳み、必要なときだけ正確な行まで戻れる。人間のやり方とほぼ同じだ。バリデーションをミドルウェアに移したことは覚えているが、最初に失敗した6回の試行は覚えていない。

失敗の仕方も人間くさい。要約が"このエンドポイントは後方互換を保つこと"という唯一重要な制約を落としたら、エージェントは40分後に朗らかにそれを壊す。圧縮レイヤーはコストを節約し、その代わりにバグを一つ置いていく。それを耐えられるものにするのが可逆性だ。解凍して、要約が実際に何と言っていたかを確認できる。

なぜ今これはカテゴリなのか

同じ問題をめぐって、少なくとも3つの異なるアプローチが競っている。ひとつはラボの答えで、もっと大きなウィンドウを作る。もうひとつはハーネスの答えで、覚えるのではなく検索し、コンテキストには作業セットだけを置く。3つ目が billion-context の代表するもので、会話を保持したまま、その場で可逆に圧縮する。

トレードオフは現実だ。大きなウィンドウは一番簡単で、一番制御できない。履歴が関係あるかどうかに関係なく、毎回の呼び出しで払う。検索は一番安いが連続性を失う。エージェントは自分が何を忘れたか分からないからだ。その場での圧縮は連続性とコストを同時に抑えようとする。代償は、リクエストパスの中に座り込むことだ。

考えるべきは最後のコストだ。間に挟まるプロキシは、すべてのプロンプトとすべての補完を見る。個人開発者なら問題ない。データの扱いに規則がある企業なら、それはコンプライアンスの会話になる。"ソースは読んだ、問題ない"と監査は同じではない。

ライセンスという小さな問題もある。技術ペーパーは MIT でリポジトリに入っている。リポジトリ自体のライセンスは標準的な OSI ライセンスではなく"Other"と報告されている。社内にデプロイするなら、この違いは必ず話題になる。

居心地の悪い含意

圧縮が十分に効いて 100K で足りるなら、コンテキストウィンドウのマーケティングの多くは、ソフトウェアでより安く解ける問題を狙っていることになる。だからといって大きなウィンドウが無用になるわけではない。400ページの文書1つはどこかに収まる必要がある。ただ"100万トークンあります"は、聞こえるほど強い売り文句ではないというだけだ。燃費ではなく、大きな燃料タンクを宣伝するようなものだ。

これはエージェントの書き方も変える。記憶が圧縮できるなら、学んだことを構造化された形で書き残すようエージェントを促すべきだ。構造化されたメモは生ログよりはるかに圧縮しやすい。"認証ミドルウェアはテナントを cookie ではなく header から読む"の一行は、スタックトレース千行に値する。圧縮レイヤーは良い記帳を報いる。ツールとしてはいい性質だ。

プロジェクトは千を超えるスター、npm の月間ダウンロードは約400,000、20以上のクライアント向けバッジを持つ。趣味の規模のインストールベースではない。痛みは本物で、広く共有されていて、人が手を伸ばしている答えはウィンドウサイズのゼロを一つ増やすことではない、ということを示している。

どのツールを使うにせよ、それが役に立つ結論だ。コンテキストは容器ではなく予算だ。そう扱うチームは1ドルあたりもっと多くを成し遂げ、大きなウィンドウを待つチームは"何が重要かを決めない特権"に払い続ける。