自分のコンテキストを書き換える言語モデル（CLM）と、手元での試し方

エージェントに長い作業を任せると、コンテキストはいずれ上限に近づきます。今のツールの多くは一定の長さで履歴を要約する、ファイルに逃がす、必要なときに検索して戻す、のどれかで対処しています。どれも、何を残して何を捨てるかの規則を人が決めています。2026年9月29日にarXivへ公開された論文「Context Language Models」は、その判断をモデルに任せました。著者はMeta Superintelligence Labs、ワシントン大学、MIT、Trillium Labsの研究者です。コードと、手元のエージェントで試すための拡張も同時に公開されたので、論文を読むだけでなく自分の環境で試せます。

コンテキストをファイルとして編集させる#

普通の言語モデルでは、コンテキストは追記されるだけです。新しい発言やツールの結果が末尾に足され、古いものは要約や切り捨てで減らすまで残り続けます。

CLM（Context Language Model）では、モデルが次のコンテキストそのものを作ります。実装は単純で、システムプロンプトとタスクの指示より後ろの会話を1つのテキストファイルに書き出し、そのパスをシステムプロンプトで伝えるだけです。モデルはsedやpython3のような普通のコマンドでこのファイルを書き換えられ、ハーネスが形式を確かめて受け付けた編集が、次のリクエストの入力としてLLMのサーバーに送られます。書き換えなかったときは、これまでどおり末尾に追記されます。

論文のハーネスのREADMEによると、ファイルの中身は[[CTX_TURN i role=…]]で区切られた1発言ずつのブロックです。システムプロンプトとタスクの指示は固定され、ファイルには入りません。

これまでの研究も要約するタイミングをモデルに決めさせたり、退避と検索のツールを渡したりして、少しずつモデルに任せる範囲を広げてきました。それでも、使える操作は人が用意したものに限られていました。CLMは操作の種類を決めず、どこをどう書き換えるかを全てモデルに任せます。論文には、実験中にモデルが自分で作った次のような書き換えが載っています。

• 「notes」という新しい役割のブロックを作り、調べて分かったことを書き留める
• 関係のなかった検索結果を、ループで「検索した。関連なし」の1行に置き換える
• 古い結果を進捗メモへの参照に縮める関数を定義し、37回使い回す
• 複数のサブエージェントの状況を表にしたブロックを、163回その場で書き換え、コンテキストを6〜8Kトークンに保つ

計算量は減り、正答率は同じか上がった#

論文の主な数値は次のとおりです。計算量は、先頭が一致する部分のキャッシュを使い回したと仮定した理論上のFLOPsで比べています。途中を書き換えると、そこから後ろは計算し直しになるので、その分も費用に入っています。

課題	条件	結果
BrowseComp-Plus（調べもの）	Qwen3.6-27B、32Kトークン	正答率59.4%。最も強い比較手法（Codex方式の要約）より相対で11.4%高く、計算量は21.5%少ない
TerminalBench 2.1（端末でのコーディング）	同上	要約と同じ正答率で、計算量は70%
EdgeBench-10（リポジトリを12時間改善）	Qwen3.6-27B、32Kトークン	44.6点（要約は42.3点）。計算量は179 PFLOPs（要約は437）
Software World（6つのエージェントが24時間かけて6つのリポジトリを高速化）	GPT-5.6-Sol、272Kトークン	同じ費用で、高速化の幅が要約より65%大きい

追加の学習なしで、既存のモデルにファイルの場所と使い方を伝えるだけで、この結果になっています。小さいモデルほど効果が出にくい点も書かれています。TerminalBench 2.1で、Qwen3.5-9Bがコンテキストを編集したのは1課題あたり平均1.4回で、半分の課題では一度も編集しませんでした（Qwen3.6-27Bは2.6回）。そこで著者らは強化学習でQwen3.5-9Bを訓練しました。成功した試行のうち、計算量の少ないものを高く評価する方法で、BrowseComp-Plusの正答率は28.8%から42.5%に上がっています。

著者らは指示の効き方も確かめています。試した指示は次の3種類の1文です。

• コンテキストが一定の量を超えたら、約4000トークンまで縮める
• 小さな課題が終わるごとに、その材料を捨てる
• 編集の前に必ずバックアップを取る

どれもタスクの指示に足しただけで、ハーネスにもモデルにも手を加えずに、編集のしかたがそのとおりに変わりました。

ただし、どの数値も著者自身の実験によるものです。AI Weeklyは、第三者による再現はまだないと指摘しています。InfoQが紹介したX上の反応にも、決められた課題での結果にすぎないという意見があります。

手元で試す方法#

試し方は論文と同じ条件で測りたいか、普段のコーディングエージェントで使ってみたいかで分かれます。

環境	入れるもの	向いている用途	ライセンス
論文のハーネス（Harbor）	context-language-models	論文の条件での測定、ベンチマーク	CC BY-NC 4.0（非商用）
Pi	pi-clm（論文のリポジトリが案内する拡張）	普段の作業で試す	MIT
OpenCode	opencode-clm（有志による移植。著者は保守していない）	普段の作業で試す	MIT
Claude Code	なし（指示で考え方を借りる）	要約の方針を変える	なし

論文のハーネス（Harbor）#

論文の実験はエージェントの評価基盤Harborの上で動きます。Python 3.12で次のように入れます。

git clone https://github.com/facebookresearch/context-language-models.git && cd context-language-models
python3.12 -m venv .venv && . .venv/bin/activate
pip install -e .

モデルはツール呼び出しを有効にしたOpenAI互換のサーバーなら何でも使えます。論文と同じQwen3.6-27BをvLLMで動かすときの例が、READMEに載っています。サーバーのコンテキスト長は、予算（context_budget_tokens）と1回の出力の上限（max_tokens、既定は16384）の合計以上にします。

vllm serve Qwen/Qwen3.6-27B --served-model-name qwen36-27b --max-model-len 65536 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3

GPUがなければ、APIのモデルも使えます。そのときはlitellmのモデル名（anthropic/...など）を渡し、api_baseは付けません。

Harborのタスクのディレクトリを指定して、1回試行します。-e dockerはタスクをDockerのコンテナで動かす指定です。

clm-harbor trial start -p path/to/task -e docker -a clm-minimal -m openai/qwen36-27b \
  --agent-kwarg api_base=http://localhost:8000/v1 --clm-config bcp

--clm-configは、論文で使った設定をまとめて渡す指定で、bcp（調べもの向け）とedgebench（長時間の改善向け）があります。何も付けなければ、予算は32,000トークンです。主な設定は次のとおりです。

• context_budget_tokens：コンテキストの予算。実際の上限はここからcontext_budget_reserve_tokens（既定2048）を引いた値
• nudge_ratios：予算の何割で「縮めて」と知らせるか。既定は25%・50%・75%
• max_num_retry_on_limit：上限を超えたとき、直近のターンを取り消して縮めさせる回数。既定は50
• allow_edit_growth：編集を受け付ける条件。fitは上限に収まれば受け付け、shrinkは小さくなるときだけ受け付ける

試行ごとに、軌跡（trajectory.json）、編集や警告の回数（usage.json）、毎回のコンテキストの写し（context_snapshots/）が残るので、モデルがどこをどう書き換えたかを後から追えます。コンテキストの管理だけを測る診断用のベンチマークContextBenchも、Harborの1行で動かせます。

harbor jobs start --repo RulinShao/ContextBench -d contextbench \
  -a clm_contextbench:ClmStream -m openai/<model> --agent-kwarg api_base=http://localhost:8000/v1

コードのライセンスはCC BY-NC 4.0で、商用には使えません。

Pi#

コーディングエージェントPiには、論文のリポジトリが「Day 1 Support」として案内する拡張pi-clmがあります。PiはNode.js 22.19以上が必要で、macOS・Linux・Windows向けのインストーラーがあります。

curl -fsSL https://pi.dev/install.sh | sh
pi install npm:@lolipopshock/pi-clm

WindowsではPiのインストーラーをpowershell -c "irm https://pi.dev/install.ps1 | iex"で動かします。

入れたあとは、Piの中で/clmを打つと、コンテキストの大きさの推移、次のリクエストの中身、編集の前後の差分を見られます。/clm-compactは、今すぐ自分のコンテキストを縮めるようモデルに頼むコマンドで、後ろに残してほしいことを書き足せます。CLMを使っている間、Pi自身の自動の要約は止まります。手で/compactを打つと、Piが元の履歴を要約するため、モデルによる編集は残りません。

主な設定は/clm configか環境変数で変えます。

• budget（PI_CLM_BUDGET）：予算。既定はモデルのコンテキスト長
• reminders（PI_CLM_REMIND_AT）：予算の何割で知らせるか。既定は50%・75%・90%
• steering（PI_CLM_STEERING）：コンテキストの管理方針を書いたMarkdownのファイル。システムプロンプトに足される
• one-toolとtrailer：1ターンのツール呼び出しを1回に限る、ツールの結果に現在のトークン数を付ける。どちらも論文のハーネスに条件をそろえるためのもので、普段は切っておく

論文で効いた「1文の指示」を試すなら、steeringのファイルに書くのが手軽です。

OpenCode#

OpenCodeには、pi-clmを移植したopencode-clmがあります。CLMの著者は保守していないと、論文のREADMEに明記されています。

opencode plugin opencode-clm

-gを付けると全てのプロジェクトに入ります。コマンドはpi-clmとほぼ同じで、/clm、/clm-compact、/clm budget 64kのように使います。予算の既定はモデルのコンテキスト長の50%です。

比べるときに便利なのが/clm config mode notices-onlyです。予算の知らせは残したまま、コンテキストの編集だけを止めます。作者がOpenCodeで9つの課題を試したところ、1課題あたりの時間はCLMありで55.5秒、なしで91.3秒でした。ただし、編集が受け付けられたのは9回の実行で1回だけです。作者は差の多くは編集ではなく、予算を知らされたモデルがツールの呼び出しを減らしたためと見ています。手元で効果を測るときも、この設定と比べれば、編集そのものの効果を切り分けられます。なお、作者の測定はローカルのモデルだけで、ホストされたAPIでは試していないと書かれています。

Claude Code#

Claude Codeのコストのドキュメントとメモリのドキュメントを見た範囲では、会話そのものをファイルとしてモデルに書き換えさせる仕組みはありません。コンテキストを減らす主な手段は、自動の要約と/compactによる手動の要約です。ほかに、古いツールの結果の自動の消去、/clearによる新しいセッションの開始、出力の多い作業のサブエージェントへの委任がありますが、どれもモデルが会話を自由に編集するものではありません。

借りられるのは「何を残すかを指示で変えられる」という部分です。/compactの後ろに残してほしいことを書くと、要約の方針を変えられます。毎回書く代わりに、プロジェクトのCLAUDE.mdに「Compact instructions」の見出しで方針を書いておくこともできます。

# Compact instructions

要約するときは、確認済みの事実、失敗した試みとその理由、まだ試していない案、次の一手を残す。読み終えたファイルの中身と、関係のなかった検索結果は、ファイル名と1行の結論だけにする。

ただし、これは決まった規則で要約する方式（論文の比較手法の側）に方針を足しただけで、任意の時点で途中の一部だけを書き換えることはできません。

途中を書き換えると、キャッシュが効きにくくなる#

多くのLLMのサーバーやAPIは、前のリクエストと先頭が一致する部分の計算結果を使い回します。CLMがコンテキストの途中を書き換えると、そこから後ろは一致しなくなり、計算し直しになります。

論文の計算量は、この計算し直しを含めて数えた上で、要約より少なくなっています。さらに著者らは書き換えた箇所より後ろの変わらない部分の計算結果も使い回すSuffix Cache Reuseを、推論サーバーSGLangへのパッチとして公開しました。標準のSGLangと同じ性能で、サーバー側の計算を35%減らしたと報告しています。ただ、この仕組みは厳密には元の計算結果と一致しない近似です。InfoQが紹介したRedditの投稿も、キャッシュが無効になる点と、この工夫にも欠点がある点から、まだ実運用には早いと述べています。

Claude Codeのコストのドキュメントも、要約のあとはキャッシュを作り直すと説明しています。ホストされたAPIでCLMを使う場合も、モデルが何度も書き換えるほど、キャッシュが効かない分の費用が増えると考えられます。

消しすぎと、プロンプトインジェクション#

InfoQは、研究者が認める課題として3つを挙げています。論文の考察で扱っているのは、このうち2つ目の安全性です。

1つ目は、モデルが重要な情報を消し、後から取り戻せなくなることです。2つ目は安全性です。モデルが書き換えられるコンテキストは、プロンプトインジェクションや、モデル自身が書いた指示が、ターンをまたいで残る経路になり得ます。論文は、要約の中にモデルが許可されていない指示を書き込み、その後の動作に影響したというOpenAIの報告も挙げています。3つ目に、コンテキストを自由にできても、何を残すかの判断が良くなるとは限りません。

pi-clmとopencode-clmは、本物のシステムプロンプトをファイルに入れず、書き換えられないようにしています。それでも、残すべき情報をモデルが消すことまでは防げないと、どちらの説明にも書かれています。試すときは書き出したファイルの中身と編集の差分（/clmの画面やcontext_snapshots/）を見て、何が消えたかを確かめられるようにしておくのが無難です。

「今の理解」を持たせる論文との違い#

以前取り上げた信念状態の論文も、長い履歴をそのまま抱えるより、今の理解を明示して持つほうがよいという立場でした。違いは、その形を誰が決めるかです。信念状態の論文は世界の状態、目的、知識の穴、達成の穴という決まった枠を人が設計しました。CLMは枠を決めず、モデルが自分でメモの形や縮め方を作ります。実験でモデルが作った「notes」の役割や進捗表は、信念状態の論文が人の手で決めた枠に近い形になっています。