コンテキスト窓は広げるものではなく、外に置くものだった

長い入力を 1 つのプロンプトへ詰め込むのをやめたら、コンテキスト窓を 1 桁超（論文 Table 1 の最長は 1100 万トークンで、GPT-5 の窓 27 万 2000 トークンの約 40 倍）上回る長さが処理できた——MIT のチームが出した Recursive Language Models（RLM）という論文を読んで、真っ先に思い浮かんだのは自分のナレッジベースの畳み方だった。RLM は長い入力をプロンプトに入れない。Python REPL 上の変数として「窓の外」に置き、モデルは変数の中身を覗き、絞り、切り出した断片へ自分自身のサブ呼び出しを立てて、答えだけを持ち帰る。長文処理のテクニックとして読み始めたのに、途中からこれは記憶の設計の話だと分かって、読む姿勢が変わった。

文脈はプロンプトから REPL に引っ越した

従来は長い入力の全文をモデルのコンテキスト窓へ流し込んでいた。RLM では、入力は Python REPL 環境の変数としてモデルの外に置かれる。root と呼ばれる本体のモデルが受け取るのは質問と「文脈が変数に入っている」という事実、そしてそのサイズだけで、全文は一度も見ない。本体はコードを書いて動く。例えば変数の先頭 2000 文字だけ覗いて構造を掴み、正規表現で関係する行を絞り、必要なら文脈をチャンクに割って、それぞれの断片を引数にサブのモデル呼び出しを立てる。断片への答えを REPL 側の変数で組み立て、最後に FINAL タグで返す。このサブ呼び出しの再帰の深さは、著者ブログの初期実験では 1 に固定されていたが、論文では深さ 0〜3 の 4 水準が評価されていて、既定は深さ 1（深さ 2 以上では sub-RLM の呼び出しも許す）。

数値も書いておく。難関の長文ベンチマーク OOLONG（131k トークン級、つまり全文が GPT-5 の窓にまだ収まる長さ）では、論文の Table 1 で素の GPT-5 が 44.0 なのに対し、RLM（root が GPT-5、サブ呼び出しは GPT-5-mini、深さ 1）は 56.0。12 ポイント、率にして約 27% 上回った。文書検索型の BrowseComp-Plus では、文書 1000 件（600 万〜1100 万トークン）を丸ごと渡す設定で GPT-5 単体が 0.0 まで崩れるのに対し、RLM（深さ 1）は 91.3 を維持した。論文全体では、GPT-5 を土台にした構成が 4 つの長文タスクの中央値で、圧縮（compaction）に対して 26%、サブ呼び出し付き CodeAct に対して 130%、Claude Code に対して 13% 上回ったと報告されている。

ここで 1 つ、混同しやすいので断っておく。再帰といっても REPL の中で本体がサブのモデル呼び出しを関数のように使うだけだ。著者ら自身は「RLM は agent でも、単なる要約でもない」と線を引く。その根拠は、agent が人間の直感にもとづいて問題を分解する足場なのに対し、RLM は文脈の分解そのものをモデルに委ねる推論方式だという点にある。ツールを持って外界を回るループの話ではなく、1 回のモデル呼び出しの内側の話だ。この記事で扱うのはそこだけ。

もう 1 つ、外部化そのものは RLM の発明でないことも書いておく。文脈を外に置き、必要な断片だけ取りに行く発想は、2020 年以降の RAG が主流にし、2023 年の MemGPT が「コンテキスト窓の外の記憶」を OS のページングに似た仕組みで管理する提案として突き詰めた、既定路線だ。そのうえで RLM が持ち込んだ差分は 3 つ読み取れる。事前に固定した retriever や embedding 索引に頼らず、文脈の分解と参照経路の構築そのものをモデルが REPL 上で即興的に行うこと。top-k 検索が上位 k 件の外を取りこぼすのに対し、REPL 変数の生テキスト全体へのアクセスが最後まで保たれること。そして取り出した断片の処理自体を、サブ呼び出しの再帰で同じ方式に畳めること。外部化は既に共有地で、この論文の新しさは「置いたものへの参照経路を、誰がいつ作るか」の答えに集中している。

窓の限界は設計選択だった

なぜ詰め込みは失敗するのか。context rot と呼ばれる現象がある。Anthropic の定義を借りれば、コンテキスト窓内のトークンが増えるほど、そこから正確に情報を思い出す能力が落ちる。ただし単純な「干し草から針を探す」型のベンチマーク（RULER 等）なら、いまのフロンティアモデルは 100 万トークン超の設定でも安定して解けてしまう、と RLM 論文自身が書いている。壊れるのはもっと日常的な場面で、セッションが長くなるほどモデルがどこか鈍くなる、あの体感のほうだ。論文の筆頭著者は最もありそうな説明として、長い系列は自然に発生することが少なくエントロピーも高いため、訓練分布の外にあることを挙げる。

この見立てに立つと、窓の限界の性格が変わる。無理をしているのは設計のほうだ。「記憶を 1 つの連続領域へ押し込み、全部を等しく視界に入れる」という選択が、統計的な無理を生んでいる。RLM の面白さは、この無理を解こうとしなかったところにある。context rot を修理する代わりに、押し込む前提のほうを外した。文脈は環境に属し、モデルに常駐するのは質問と手がかりだけ。だからどの 1 回の呼び出しも、巨大な文脈を抱えずに済む。著者らはこの性質を「明日フロンティアモデルが 1000 万トークンを普通に扱えるようになれば、RLM は 1 億トークンを扱える」と表現する。

全部を暗記して読む人はいない

これは人間が昔からやってきた読み方だ。辞書を暗記する人はいない。引けることを知っていれば足りる。分厚い資料を頭から終わりまで等速で読む人もいない。目次で当たりをつけ、索引を引き、必要な章だけ深く読む。RLM の root がやっている「覗く・絞る・部分だけ読む」は、この手つきの機械化に見える。

つまり「何を頭に置き続け、何を都度取りに行くか」という配分の問いが先にあって、コンテキスト窓の広さはその問いのパラメタでしかない。窓が 10 倍になっても配分の問いは消えない。置ける場所が広がるだけで、置くべきかどうかは別の判断だからだ。そして外に置いたものが使い物になるかは、索引の質で決まる。

自分のナレッジベースは、先に同じ形をしていた

この論文が他人事でなかったのは、手元の運用が同じ構造をしていたからだ。日々の作業ログや判断を貯めているナレッジベースは 5 つの層に分かれていて、生のログは下層に、蒸留した文脈やパターンは上層に置いてある。運用のルールは「毎回全部を読まない」。作業を始めるとき AI が読むのは薄い上層と索引だけで、下層の生ログは必要になった時に該当箇所だけを開く。

正直に書くと、この構成は一見、論文が RLM に劣ると報告した compaction の系譜に見える。蒸留、つまり要約して上層に置くという操作は、compaction がやることと同じだからだ。ただ、両者は原文の扱いで分かれる。compaction は要約で原文を置き換え、元の文脈は捨てられる。この Vault の蒸留上層は原文を置き換えない。あくまで参照経路であり、下層の生ログは破棄されず、必要になれば該当箇所がそのまま開かれる。RLM と同じ賭けをしているのは後者だ。

AI に渡す常駐指示も同じ方針で組んである。常駐部分には手順の本文を書かず、「この作業のときはこの参照ファイルを読む」という索引だけを置いて、詳細は必要時に遅延ロードさせる。そうした理由は単純で、常駐を厚くするほど個々の作業で判断が濁る感触があったからだ。関係のない指示が常に視界にある状態は、効くべき指示の効きまで薄める。RLM の論文を読んで、この経験則に理屈の背骨が通った。文脈を外部変数として置き、必要な断片だけ再帰的に取りに行く。規模も実装もまるで違うが、賭けている原理は同じだ。実際、先月この方針で常駐指示を全面的に組み直し、本文の 7 割超を外部の参照ファイル側へ移した。いま常駐に残っているのは索引と数行の原則だけだが、それで作業が回らなくなった場面には、まだ出会っていない。

何を持ち続け、何を都度取りに行くか

外に置くものは、取りに行ける形に整える。ここは RLM と人間側の運用で作り方が分かれる点でもある。RLM は事前の索引を持たない。root が先頭を覗き、正規表現を試し、参照経路をその場で即興的に組み立てることで、生のテキストのまま機能させた。人間側の運用では、その即興力を命名・目次・パス規則という事前設計で肩代わりする。どちらにせよ、参照経路が立たないままの外部化はただの置き忘れだ。

コンテキスト窓はこれからも伸び続けるだろうし、それ自体は歓迎だ。ただ「窓に入るから入れる」は疑ったほうがいい。詰め込みの上限は窓のサイズより手前に来るし、伸びた窓に何を入れるかを考え始めた時点で、問いはもう広さの話をしていない。広さの競争の外側には、置き方の設計という別のゲームがあって、RAG 以来そこで競ってきたプレイヤーは何人もいる。RLM はその中で、参照経路の構築までモデルに手渡した、いまのところ一番鮮やかな実演だと思う。

一次資料